6:23-cv-00004
S3G Technology LLC v. Staples Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: Staples, Inc. (Delaware)
- Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
- Case Identification: 6:23-cv-00004, W.D. Tex., 01/05/2023
- Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains a regular and established place of business within the district, has transacted business involving the accused products in the district, and has allegedly committed acts of infringement there.
- Core Dispute: Plaintiff alleges that Defendant’s Staples-branded mobile applications and associated backend systems infringe three patents related to methods and systems for modifying software on remote devices using lightweight "dialogue modules."
- Technical Context: The technology addresses the efficient updating of software on networked devices, such as mobile phones, by sending small packets of interpretable code to alter application functionality, rather than transmitting large, full executable files.
- Key Procedural History: The complaint notes this case is related to active litigation against Ace Hardware Corporation and Party City Corporation. Plaintiff also heavily relies on prior litigation, S3G Technology LLC v. UniKey Tech Inc, citing claim constructions from that case for key terms. The complaint further references the prosecution history of a parent patent to argue for the non-obviousness of the claimed invention.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Priority Date for '124, '571, '774 Patents |
| 2013-10-29 | U.S. Patent No. 8,572,571 Issued |
| 2018-04-10 | U.S. Patent No. 9,940,124 Issued |
| 2019-04-16 | U.S. Patent No. 10,261,774 Issued |
| 2023-01-05 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,940,124 - “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” Issued April 10, 2018
The Invention Explained
- Problem Addressed: The patents describe the difficulty of distributing updated software applications to a large number of geographically dispersed devices, particularly over wireless networks with limited bandwidth. Transmitting an entire newly compiled application can be slow, costly, and impractical. (Compl. ¶¶13-14; ’571 Patent, col. 2:18-52).
- The Patented Solution: The invention proposes a three-entity system (terminal machine, service provider machine, and update server machine) that avoids sending full application updates. Instead, the update server sends a small "dialogue module" containing "code" to the terminal or service provider machine. This code is not directly executable but is interpreted by a platform module (like a virtual machine) already on the device. This allows for the modification of the application's "dialogue sequence"—such as the prompts shown to a user—without replacing the underlying computer-executable instructions. (Compl. ¶¶15-16, 22; ’571 Patent, col. 4:21-25). The complaint provides FIG. 1 from the patent, which illustrates the three-entity system architecture. (Compl. ¶15).
- Technical Importance: This method purports to reduce network bandwidth usage and improve the efficiency of developing and modifying applications running on remote devices. (Compl. ¶23; ’571 Patent, col. 6:47-49).
Key Claims at a Glance
- The complaint asserts independent claim 1. (Compl. ¶28).
- Essential elements of claim 1 (a method) include:
- Displaying a first prompt on a terminal machine via a terminal application, which comprises "first computer-executable instructions" and "first code."
- Accepting a first data entry.
- Communicating information to a service provider machine running a provider application, which comprises "second computer-executable instructions" and "second code."
- Receiving, at the terminal machine, a "terminal dialogue module" that updates the "first code" to produce "first updated code."
- The "first updated code" adapts the terminal application to display a second prompt.
- At least one of the "first code," "second code," or "first updated code" comprises "intermediate code."
- The complaint reserves the right to assert other claims.
U.S. Patent No. 8,572,571 - “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” Issued October 29, 2013
The Invention Explained
- Problem Addressed: As with the related '124 Patent, the invention addresses the challenges of updating software on remote devices over bandwidth-constrained networks. (Compl. ¶¶13-14; ’571 Patent, col. 2:18-52).
- The Patented Solution: The solution is a system architecture that separates an application into two parts: computer-executable instructions (a platform or runtime) and "code" (information that must be translated by the platform). An update server sends "dialogue modules" containing new or modified "code" to update the application's behavior without altering the computer-executable instructions. (Compl. ¶¶16, 22; ’571 Patent, col. 4:21-25). The complaint provides FIG. 2 from the patent, which depicts this two-part structure of a terminal application (220) comprising computer-executable instructions (224) and code (222). (Compl. ¶16).
- Technical Importance: The claimed system aims to achieve design efficiencies and reduce network utilization by enabling targeted, lightweight updates to application logic. (Compl. ¶23; ’571 Patent, col. 14:43-48).
Key Claims at a Glance
- The complaint asserts independent claim 2. (Compl. ¶42).
- Essential elements of claim 2 (a system) include:
- An "update server machine" for sending a "terminal dialogue module" and a "provider dialogue module."
- A "terminal machine" running a terminal application comprising a "first set of computer-executable instructions" and a "first set of code."
- A "service provider machine" running a provider application comprising a "second set of computer-executable instructions" and a "second set of code."
- The dialogue modules modify the respective sets of "code" to produce "updated code," adapting the application dialogue.
- The dialogue modules do not modify the sets of "computer-executable instructions."
- The complaint reserves the right to assert other claims.
U.S. Patent No. 10,261,774 - “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” Issued April 16, 2019
- Technology Synopsis: This patent, from the same family as the '124 and '571 patents, claims a method for conducting a dialogue sequence between a terminal machine and a service provider machine. The method involves modifying a "first code" on the terminal machine with a received "third code" to create an "updated code" that alters the application's subsequent prompts, separating this interpretable code from the underlying non-modified executable instructions. (Compl. ¶¶57-60; ’774 Patent, Abstract).
- Asserted Claims: The complaint asserts independent claim 1. (Compl. ¶55).
- Accused Features: The accused features are the same as those for the other asserted patents: the Staples mobile app and backend system, where data sent from the server (e.g., for wish lists) is alleged to function as the claimed "code" that modifies the app's dialogue sequence. (Compl. ¶¶57, 60).
III. The Accused Instrumentality
Product Identification
The "Accused Instrumentalities" are identified as the Staples mobile applications for Android and iOS (the "Defendant app") and the supporting systems, including servers and software, that facilitate the app's use (the "Accused System"). (Compl. ¶7).
Functionality and Market Context
- The complaint focuses on the technical architecture of the Accused System. It alleges that the Staples mobile app (a "terminal application" on a "terminal machine") communicates with a Staples server (a "service provider machine"). (Compl. ¶¶29-30).
- The core accused functionality involves features like user wish lists. The complaint alleges that when a user interacts with a wish list, information is communicated between the app and the server. It further alleges that data sent from the server to the app, such as in JSON format, functions as a "terminal dialogue module" that updates the app's "code" (identified as the app's bytecode) to display a modified dialogue sequence, such as new or updated wish lists. (Compl. ¶¶30, 32, 34).
- The complaint alleges that Staples derives a significant portion of its revenue from the use and promotion of these services. (Compl. ¶7).
IV. Analysis of Infringement Allegations
’124 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| displaying a first prompt on a terminal display of a terminal machine by running a terminal application, the terminal application comprising first computer-executable instructions and first code that conduct the terminal machine's portion of the dialogue... | The Staples app (terminal application) on a user's smartphone (terminal machine) prompts the user with wish list information. The app allegedly consists of the Android Runtime (ART) as executable instructions and the app's bytecode as code. | ¶30 | col. 15:52-60 |
| accepting a first data entry at the terminal machine... | The user interacts with the app to review, edit, or delete wish lists. | ¶31 | col. 15:61-64 |
| communicating information associated with the first data entry from the terminal machine to the service provider machine, wherein the service provider machine uses a provider application comprising second computer-executable instructions and second code... | The wish list interaction data is sent from the user's phone to a Staples server. The server allegedly runs a .Net application (provider application) comprising the Common Language Runtime (CLR) as executable instructions and the .Net program as code. | ¶32 | col. 15:65-col. 16:9 |
| receiving, at the terminal machine, a terminal dialogue module... that updates at least a portion of the first code to produce first updated code, wherein the first updated code adapts the terminal application to display a second prompt for the terminal machine's portion of a modified dialogue sequence... | The app receives data, such as JSON, from the server. This data is alleged to be a "dialogue module" that updates the app's bytecode ("first code") to produce "first updated code," which in turn causes the app to display a new or updated wish list prompt. | ¶34 | col. 16:10-21 |
| wherein at least one of the first code, the second code, and the first updated code comprise intermediate code. | The app's bytecode is alleged to be intermediate code. | ¶34 | col. 16:22-24 |
Identified Points of Contention
- Scope Questions: A central question is whether a standard data transmission format like JSON, used for displaying information, constitutes a "terminal dialogue module" as claimed. The complaint argues it does, but a defense may focus on the patent's description of a module that structurally "modifies" or "adapts" an application's code, not merely provides data for rendering. (Compl. ¶¶20, 34).
- Technical Questions: The complaint's mapping of the claimed "computer-executable instructions" and "code" onto the Android Runtime/bytecode and CLR/.Net architectures will be a key technical battleground. It raises the question of whether this distinction accurately reflects how the accused system operates, or if it is an artificial construct to fit the claim language. (Compl. ¶¶30, 32).
’571 Patent Infringement Allegations
| Claim Element (from Independent Claim 2) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| an update server machine... operable for sending a terminal dialogue module to the terminal machine and a provider dialogue module to the service provider machine... | The complaint alleges the Accused System includes an update server (e.g., the Staples server) that sends a "terminal dialogue module" (e.g., wish list data as JSON) to the user's phone and receives a "provider dialogue module" (e.g., user interactions) from the phone. | ¶44 | col. 16:51-59 |
| a terminal machine configured to run a terminal application... wherein the terminal application comprises a first set of computer-executable instructions and a first set of code... | A user's smartphone (terminal machine) runs the Staples app (terminal application), which is alleged to comprise the Android Runtime (executable instructions) and the app's bytecode (code). | ¶45 | col. 17:1-12 |
| a service provider machine configured to run a provider application... wherein the provider application comprises a second set of computer-executable instructions and a second set of code... | A Staples server (service provider machine) runs a backend application (provider application), which is alleged to comprise the .Net CLR (executable instructions) and the .Net program (code). | ¶46 | col. 17:13-24 |
| wherein the terminal dialogue module modifies the first set of code to produce a first set of updated code... and wherein the provider dialogue module modifies the second set of code to produce a second set of updated code... wherein the dialogue module does not modify the first set of computer-executable instructions and wherein the provider dialogue module does not modify the second set of computer-executable instructions. | It is alleged that the data exchanged modifies the respective bytecode/.Net code on the phone and server to adapt the dialogue, while the underlying runtime engines (ART and CLR) are not modified. | ¶¶47, 21 | col. 17:25-40 |
Identified Points of Contention
- Scope Questions: The definition of the "update server machine" appears ambiguous in the complaint, at times seeming to be the Staples server and at others the user's device accessing the system. (Compl. ¶44). This raises the question of whether the accused architecture truly embodies the claimed three-distinct-entity system.
- Technical Questions: A critical technical question is whether receiving JSON data and rendering it in an app truly "modifies the first set of code" as required by the claim. A defense may argue this is simply data processing using existing, unmodified code, not a modification of the code itself to produce "updated code" that adapts the application. (Compl. ¶47).
V. Key Claim Terms for Construction
The Term: "dialogue module"
Context and Importance: This term is the linchpin of the infringement case. Its construction will determine whether standard data packets, like the alleged JSON data, fall within the scope of the claims. Practitioners may focus on this term because the complaint's theory depends on a broad interpretation, while prior litigation cited in the complaint itself suggests the term refers to a "particular type of structure." (Compl. ¶20).
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification discloses that a "dialogue module" can contain "code or other data" and can be "communicated," which could support an argument that any communicated data packet that influences dialogue is covered. (Compl. ¶20; ’571 Patent, col. 7:6-9).
- Evidence for a Narrower Interpretation: The specification describes the module's purpose as modifying code to adapt an application, which implies more than just providing data for display. (’571 Patent, col. 8:44-52). The abstract and summary consistently frame the invention as sending "updated code" to devices, and a court in a prior case found the term refers to a "structure," not merely a "function." (Compl. ¶20).
The Term: "code" (as distinct from "computer-executable instructions")
Context and Importance: The patents' alleged inventiveness rests on this distinction. Infringement requires mapping this claimed structure onto the accused system. If the distinction is found not to apply or to be indefinite, the infringement case may fail.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation (of "code"): The specification explicitly defines "code" as "at least some information that must be translated by the software application before it can be implemented on the machine processor." (’571 Patent, col. 4:21-25). This could be argued to encompass any form of interpretable data, including app bytecode or .NET code.
- Evidence for a Narrower Interpretation (of "code"): A defendant could argue that the term, in the context of the whole patent, refers to a specific type of modifiable script within a larger application, and not to the entire body of an application's bytecode, which is a standard part of how modern applications are compiled and run.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement of infringement, stating that Defendant markets its mobile apps and encourages users to download and run them, knowing that their use in conjunction with Defendant's servers constitutes infringement. (Compl. ¶¶35, 48, 61).
- Willful Infringement: Willfulness is alleged based on Defendant having actual knowledge of the patents "at least since the filing of this complaint." (Compl. ¶¶27, 41, 54). This primarily supports a claim for enhanced damages for any post-filing infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "dialogue module," which the patent and prior litigation suggest is a specific structural component for modifying application logic, be construed to cover standard, dynamic data transmissions like JSON that are used to render content in a modern mobile app?
- A key evidentiary question will be one of technical operation: does the accused Staples system, which uses runtime environments like ART and CLR to execute application code, actually perform the claimed process of "modifying" a distinct set of "code" to create "updated code"? Or is there a fundamental mismatch, where the accused system is simply processing and displaying data using pre-existing, unmodified application logic?
- A third question concerns the system architecture: does the accused client-server system map onto the patents' three-entity structure of a "terminal machine," "service provider machine," and a distinct "update server machine," or does the complaint's theory improperly conflate these roles?