DCT
1:25-cv-00209
Partner One Acquisitions Inc v. Whatfix Pvt Ltd
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Partner One Acquisitions Inc. (Quebec, Canada) and Assima USA LLC (Delaware)
- Defendant: WhatFix Private Limited (India) and WhatFix, Inc. (Delaware)
- Plaintiff’s Counsel: Morris James LLP
- Case Identification: 1:25-cv-00209, D. Del., 02/20/2025
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant WhatFix, Inc. is a Delaware corporation and has allegedly committed acts of infringement in the District.
- Core Dispute: Plaintiff alleges that Defendant’s WhatFix Mirror product, a software simulation platform, infringes two patents related to technology for creating and manipulating interactive software training simulations.
- Technical Context: The technology at issue enables the creation of high-fidelity, interactive "clones" of live software applications, allowing users to train in a realistic environment without the risk of altering live data.
- Key Procedural History: Plaintiff Partner One acquired Assima, the original developer of the technology, in 2019. The complaint alleges that Plaintiff provided Defendant with notice of the asserted patents on or about October 31, 2024, several months after the accused product was launched.
Case Timeline
| Date | Event |
|---|---|
| 2006-05-08 | Priority Date for U.S. Patent No. 8,087,007 |
| 2011-12-27 | Issue Date for U.S. Patent No. 8,087,007 |
| 2013-03-15 | Priority Date for U.S. Patent No. 9,285,948 |
| 2016-03-15 | Issue Date for U.S. Patent No. 9,285,948 |
| 2022-06-23 | Partner One grants Assima an exclusive license (Compl. ¶21) |
| 2024-02-14 | WhatFix launches accused "Mirror" product (Compl. ¶34) |
| 2024-10-31 | Alleged pre-suit notice of infringement (Compl. ¶24) |
| 2025-02-20 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,087,007 - "System and method for software prototype-development and validation and for automatic software simulation re-grabbing," issued December 27, 2011
The Invention Explained
- Problem Addressed: The patent describes the inefficiency in traditional software development, where there are often discrepancies between designers' specifications and the final coded product, requiring costly and time-consuming manual testing and iteration. It also notes that training simulations for software quickly become outdated when the underlying application is modified (’007 Patent, col. 1:26-2:10).
- The Patented Solution: The invention proposes a system that can "grab" a live software application's state, including its graphical user interface (GUI) objects and their properties. This information is stored in a "simulation file" which can then be used to run a fully interactive simulation of the application without executing the original program's code. This file can be modified to prototype changes or update training modules, a process the patent calls "re-grabbing" (’007 Patent, Abstract; Fig. 2).
- Technical Importance: This technology aims to bridge the gap between design, development, and training by creating a modifiable, executable specification that serves as both a prototype and a basis for up-to-date training materials (’007 Patent, col. 3:6-25).
Key Claims at a Glance
- The complaint asserts independent claims 1, 21-23, and 27 (Compl. ¶29, ¶128). The analysis focuses on claim 1.
- Essential elements of independent claim 1 include:
- During a first execution of a program, automatically identifying at least one "object class instantiation" corresponding to a displayed GUI object.
- Automatically storing a description of this instantiation in a first file.
- The stored description must be "simulatable without execution of the program."
- Modifying the first file in response to a user interaction with the simulation.
- The modified version of the program must also be simulatable based on the modified file.
U.S. Patent No. 9,285,948 - "System and method for interface display screen manipulation," issued March 15, 2016
The Invention Explained
- Problem Addressed: Modifying user interfaces for complex software applications is described as extremely "tedious and time-consuming," particularly when a common element (e.g., a menu bar) appears on thousands of different screens. A single change could require manually editing every screen on which that element appears (’948 Patent, col. 2:31-38).
- The Patented Solution: The invention solves this problem by deconstructing user interface screens into a hierarchy of reusable "screen templates." Instead of storing each screen as a unique, monolithic entity, the system stores a screen as a data structure containing pointers to various shared templates (e.g., a template for the header, another for the body). A modification to a single template is automatically propagated to every screen that instantiates it, enabling efficient, system-wide updates (’948 Patent, Abstract; col. 3:5-14).
- Technical Importance: This templating architecture dramatically reduces the manual effort required to create, maintain, and translate complex graphical user interfaces and their associated training materials (’948 Patent, col. 4:45-54).
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶30, ¶138).
- Essential elements of independent claim 1 include:
- In response to a first event, obtaining a "first instantiation data structure" that includes a pointer to a "first screen template."
- Outputting the instantiated first screen template.
- In response to a second event, obtaining a "second instantiation data structure" that points to a "second screen template."
- Crucially, the "instantiation of the second screen template includes instantiating the first screen template," indicating reuse of components.
- Outputting the instantiated second screen template, which incorporates the first.
III. The Accused Instrumentality
Product Identification
The accused instrumentality is Defendant's "WhatFix Mirror" software product (Compl. ¶34).
Functionality and Market Context
- The complaint alleges that WhatFix Mirror "creates hyper-realistic and interactive replicas of web applications for immersive training and product demonstrations" (Compl. ¶34). It is alleged to function by allowing a user to "mirror" a live web application, such as Salesforce, to create a simulation that can be interacted with "without any of the risks of live system engagement" (Compl. ¶34, ¶38). The complaint includes a screenshot from the WhatFix website showing a side-by-side comparison of a "Live Application" and a "Mirror Instance," which visually represents the product's core alleged function of creating a replica (Compl. ¶34, p.9).
- The complaint positions WhatFix Mirror as a "copycat product" brought to market to compete with Plaintiff's successful "Assima Train" product (Compl. ¶33).
IV. Analysis of Infringement Allegations
8,087,007 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| during, and based on, a first execution of a program, the first execution of the program including interaction with graphical user interface objects | WhatFix Mirror is allegedly activated while a user is operating a live software application, such as Salesforce, which the complaint identifies as the "first execution of a program" (Compl. ¶38). | ¶37-39 | col. 21:30-40 |
| automatically identifying, by a processor, at least one object class instantiation according to which a respective one of the graphical user interface objects is displayed and that is associated by the program with a program state | When a user interacts with the live application, WhatFix Mirror is alleged to automatically capture the application's screens and identify the graphical user interface objects, such as the "leads" button (Compl. ¶42). | ¶40-43 | col. 21:41-49 |
| automatically storing, by the processor, in a first file a description of the identified at least one object class instantiation, wherein at least a portion of the first execution of the program is simulatable without execution... | The captured screen, identified as "Capture 1 Home | Salesforce," is allegedly stored in a file, creating a simulation that can be run without executing the actual Salesforce program (Compl. ¶45, ¶46). | ¶44-46 | col. 21:50-59 |
| modifying the first file in response to a user interaction with a displayed one of the at least one respective graphical user interface object... a modified version of the... program is simulatable based on the modified first file. | A user is allegedly able to edit the content of the captured simulation, such as changing the text in a "lead owner" field, with the changes being reflected in the simulated environment (Compl. ¶49, ¶50). | ¶47-50 | col. 21:60-66 |
Identified Points of Contention
- Technical Question: The complaint provides screenshots of the WhatFix Mirror user interface, such as one showing a user selecting the "Mirror" option from a simulation menu to begin a capture (Compl. ¶41). However, it does not provide direct evidence of the structure of the "first file." A key question will be whether this file contains a "description of the identified at least one object class instantiation" as taught by the patent, or if it uses a different, perhaps more superficial, method of screen capture.
- Scope Question: A dispute may arise over the meaning of "object class instantiation." The court may need to determine if this term, as used in the patent, can read on the HTML DOM elements of a web application captured by a browser extension, or if it requires a deeper form of object introspection into the application's source code.
9,285,948 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| responsive to a first application triggering event... obtaining... a first instantiation data structure including a pointer to a first screen template... that identifies a first plurality of user interface graphical objects | The complaint alleges that activating WhatFix Mirror on a Salesforce page is a "triggering event" that causes the system to obtain and store the page, which is alleged to be or involve a data structure with a pointer to a screen template (Compl. ¶79, ¶80). | ¶77-80 | col. 18:1-9 |
| processing... the first instantiation data structure... and outputting... the instantiated first screen template | WhatFix Mirror is alleged to process the captured data to allow a user to preview and interact with the simulated page, which is equated with outputting the instantiated template (Compl. ¶82, ¶83). A screenshot shows the captured "Home | Salesforce" page ready for preview (Compl. ¶82). | ¶81-83 | col. 18:10-14 |
| responsive to a second application triggering event... obtaining... a second instantiation data structure including a pointer to a second screen template... | User interaction with the simulation, such as clicking the "leads" button and then the "new" button, is alleged to be a second triggering event that results in the capture and display of a second screen (the "new lead" page) (Compl. ¶84, ¶87). | ¶84-87 | col. 18:15-24 |
| wherein the instantiation of the second screen template includes instantiating the first screen template | The complaint alleges that the "leads" page is captured and stored, and that the "new" graphical user interface is displayed on the capture and associated with the "leads" page capture, but provides limited factual detail on how the second template reuses components from the first (Compl. ¶87). | ¶88 | col. 18:25-28 |
Identified Points of Contention
- Technical Question: The central inventive concept of the ’948 Patent is the reuse of templates. A key evidentiary question will be whether WhatFix Mirror actually employs a system where distinct screens are constructed from shared, reusable "screen templates." The complaint alleges this functionality but does not provide direct evidence of this underlying architectural mechanism.
- Scope Question: The infringement analysis will turn on whether the accused product's architecture satisfies the limitation that "the instantiation of the second screen template includes instantiating the first screen template." If the accused product simply captures and stores each screen as a separate, non-reusable asset, it may not fall within the scope of this claim.
V. Key Claim Terms for Construction
Term: "object class instantiation" (’007 Patent, Claim 1)
- Context and Importance: This term is fundamental to how the patented system captures and understands a live application. The patentability of the invention and the infringement analysis depend on whether this term is construed broadly to cover any discrete GUI element or narrowly to require access to the application's underlying compiled code objects. Practitioners may focus on this term because the technical difference between capturing rendered web page elements versus introspecting native software objects is significant.
- Intrinsic Evidence for a Broader Interpretation: The patent frequently refers to capturing common "graphical user interface objects" like "buttons" and "edit boxes," suggesting the invention is concerned with the functional components of the UI, not necessarily their specific implementation in a particular programming language (’007 Patent, Fig. 2; col. 6:33-35).
- Intrinsic Evidence for a Narrower Interpretation: The term "class instantiation" is a specific term of art in object-oriented programming. The specification’s discussion of handling "unrecognized instantiated component classes" could suggest the system is intended to operate at the code level, analyzing the software's actual classes (’007 Patent, col. 5:1-5).
Term: "screen template" (’948 Patent, Claim 1)
- Context and Importance: This term defines the core reusable component of the ’948 Patent's invention. The case may turn on whether the accused product's method of storing screen data meets the definition of a "template," particularly the requirement of reusability. If every screen is stored as a unique entity without shared components, infringement may be difficult to prove.
- Intrinsic Evidence for a Broader Interpretation: The specification describes a flexible hierarchy where a "parent screen template can include its own display properties... and further include pointers to child sub-screen templates," which could support a broad, modular definition of a template (’948 Patent, col. 3:35-42).
- Intrinsic Evidence for a Narrower Interpretation: The abstract and summary repeatedly emphasize that the purpose is to allow a change to a single template to affect a plurality of display screens (’948 Patent, Abstract). A construction that does not require this reusability would arguably ignore the central problem the patent claims to solve.
VI. Other Allegations
Indirect Infringement
The complaint alleges induced infringement, asserting that Defendant provides demonstrations, instructional videos, and online support documentation (e.g., a page titled "Create a Mirror") that actively encourage and instruct end-users to use the WhatFix Mirror product in an infringing manner (Compl. ¶¶54-62, ¶¶94-102).
Willful Infringement
The complaint alleges willfulness on two primary grounds. First, it alleges pre-suit knowledge based on a notice letter sent on or about October 31, 2024 (Compl. ¶57, ¶97). Second, it makes a more pointed allegation of deliberate copying, supported by screenshots showing that WhatFix's marketing materials use a similar side-by-side "Live vs. Clone" comparison as Plaintiff's, and that WhatFix maintains a webpage specifically comparing its product to Plaintiff's "Assima" product line (Compl. ¶¶116-121).
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of architectural proof: can the Plaintiff produce evidence, likely through source code review during discovery, that the WhatFix Mirror product operates on a system of shared, reusable "screen templates" as required by the '948 patent? The infringement allegation for this patent hinges entirely on this technical functionality, which is not demonstrable from the complaint's public-facing evidence.
- The dispute over the '007 patent will likely focus on a question of definitional scope: can the term "object class instantiation," which has roots in compiled, object-oriented programming, be construed to cover the HTML DOM elements of a web application as captured by a browser extension?
- A key question for willfulness and potential damages will be one of intent: does the evidence of similar marketing and direct competitive targeting on Defendant's website demonstrate a deliberate and egregious copying of Plaintiff's patented technology, or does it merely reflect standard competitive practices in the software industry?