DCT
2:24-cv-00126
S3G Technology LLC v. Kroger Co
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: THE KROGER CO. (Ohio)
- Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
- Case Identification: 2:24-cv-00126, E.D. Tex., 02/22/2024
- Venue Allegations: Venue is alleged to be proper based on Defendant THE KROGER CO. having a regular and established place of business within the Eastern District of Texas, specifically identifying a store location in Marshall, Texas, and distributing the accused mobile applications to customers in the district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile e-commerce platform, including the Kroger mobile app and associated backend systems, infringes three patents related to a method for efficiently modifying software on remote devices.
- Technical Context: The technology addresses the challenge of updating distributed software systems, such as mobile applications, by transmitting small "dialogue modules" to alter application behavior without requiring a full, large-scale reinstallation of the application's executable files.
- Key Procedural History: The complaint notes that key terms from the asserted patents were previously construed by the Eastern District of Texas in a case involving the same plaintiff, S3G Tech. LLC v. Unikey Techs., Inc. It also references the prosecution history of a related patent, where the U.S. Patent Examiner allegedly found the claimed structure to be non-obvious over the prior art.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Earliest Priority Date for ’897, ’124, and ’758 Patents |
| 2015-07-14 | U.S. Patent No. 9,081,897 Issues |
| 2016-04-05 | U.S. Patent No. 9,304,758 Issues |
| 2018-04-10 | U.S. Patent No. 9,940,124 Issues |
| 2024-02-06 | Kroger iOS App Last Updated (per complaint) |
| 2024-02-07 | Kroger Android App Last Updated (per complaint) |
| 2024-02-22 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,081,897 - "Modification of Terminal and Service Provider Machines Using an Update Server Machine"
- Issued: July 14, 2015 (’897 Patent)
The Invention Explained
- Problem Addressed: The patent’s background describes the difficulty of updating software applications on a large number of geographically dispersed devices (’897 Patent, col. 2:21-28). Traditional methods require recompiling and distributing an entire updated application, which can be slow and consume significant network bandwidth, particularly over wireless networks (Compl. ¶¶13-14; ’897 Patent, col. 2:39-48).
- The Patented Solution: The invention proposes a three-part system architecture: a "terminal machine" (e.g., a user's device), a "service provider machine" (e.g., a backend server), and an "update server machine" (’897 Patent, FIG. 1). The update server sends small "dialogue modules" to the other machines. These modules contain "code" (e.g., intermediate code) that is interpreted by the existing application software, thereby modifying the application's dialogue or functionality without replacing its underlying "computer-executable instructions" (’897 Patent, col. 4:25-40). This allows for lightweight, efficient updates.
- Technical Importance: This architectural approach claims to enable efficient modification of remote applications by reducing network bandwidth utilization and development overhead compared to distributing full application updates (Compl. ¶24).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶31).
- Claim 1 (System):
- An update server machine operable for sending a terminal dialogue module and a provider dialogue module.
- A terminal machine running a terminal application, which comprises a first set of computer-executable instructions (able to execute directly on a processor) and a first set of code (not able to execute directly).
- A service provider machine running a provider application, which comprises a second set of computer-executable instructions and a second set of code with corresponding properties.
- The terminal dialogue module modifies the first set of code (but not the first set of computer-executable instructions) to produce updated code.
- The provider dialogue module modifies the second set of code (but not the second set of computer-executable instructions) to produce updated code.
- The updated code adapts the respective applications to use a modified dialogue sequence.
- The complaint reserves the right to assert other claims (Compl. ¶31).
U.S. Patent No. 9,940,124 - "Modification of Terminal and Service Provider Machines Using an Update Server Machine"
- Issued: April 10, 2018 (’124 Patent)
The Invention Explained
- Problem Addressed: The patent addresses the same technical problem of inefficiently updating remote software applications as the ’897 Patent (Compl. ¶¶12-14; ’124 Patent, col. 2:12-28).
- The Patented Solution: This patent claims a method of conducting a dialogue between a terminal and service provider machine. The method involves the terminal application (comprising directly executable instructions and interpretable code) displaying a prompt and accepting data. The core inventive step is receiving a "terminal dialogue module" that updates a portion of the application's interpretable "code" to produce "first updated code," which in turn adapts the application to display a new prompt for a modified dialogue sequence (’124 Patent, Abstract; col. 8:36-43). The patent specifies that at least one of the code sets must be "intermediate code" (’124 Patent, Claim 1).
- Technical Importance: The method provides a specific process for dynamically altering an application's behavior on a client device through small, targeted code updates, thereby conserving network resources (Compl. ¶24).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶49).
- Claim 1 (Method):
- Displaying a first prompt on a terminal machine by running a terminal application comprising first computer-executable instructions and first code.
- Accepting a first data entry at the terminal machine.
- Communicating information associated with the data entry to a service provider machine running a provider application.
- Receiving, at the terminal machine, a terminal dialogue module that updates at least a portion of the first code to produce first updated code.
- The first updated code adapts the terminal application to display a second prompt for a modified dialogue sequence.
- At least one of the first code, second code, and first updated code must comprise intermediate code.
- The complaint reserves the right to assert other claims (Compl. ¶49).
U.S. Patent No. 9,304,758 - "Modification of Terminal and Service Provider Machines Using an Update Server Machine"
- Patent Identification: U.S. Patent No. 9,304,758, issued April 5, 2016 (’758 Patent).
- Technology Synopsis: This patent claims a method for conducting a dialogue between a terminal and a service provider machine, similar to the ’124 Patent. The method's distinguishing feature is the step of receiving a terminal dialogue module that replaces (rather than generally updates) at least a portion of the application's interpretable "first code" to produce an updated code set, which then adapts the application for a modified dialogue sequence (’758 Patent, Claim 1).
- Asserted Claims: At least independent claim 1 (Compl. ¶68).
- Accused Features: The complaint alleges that the Kroger mobile app and backend system perform this method, for example, when information (e.g., JSON data) is sent from a Kroger server to the user's device, which then replaces existing shopping list data and modifies the user interface (Compl. ¶¶70, 73).
III. The Accused Instrumentality
Product Identification
The accused instrumentalities are the "Kroger mobile applications for devices running the Android operating system and Kroger mobile applications for iOS," along with the associated backend systems, servers, and software that support them. The complaint also includes mobile applications for Kroger-owned brands such as Smiths, Ralphs, and Food 4 Less (Compl. ¶7, fn 3).
Functionality and Market Context
- The accused system provides mobile e-commerce functionality, allowing users to create and manage shopping lists, receive rewards and coupons, place orders, and view purchase history (Compl. ¶13, fn 8). The complaint alleges that this functionality involves a "dialogue sequence" between the user's mobile device (the "terminal machine") and Kroger's backend servers (the "service provider machine") (Compl. ¶34). Information is allegedly sent from the servers to the mobile app to modify its content and behavior, such as by adding new items to a shopping list visible to the user (Compl. ¶¶17, 36).
- The complaint alleges that the Defendant derives a significant portion of its revenue from the promotion, sale, and distribution of its services through the accused mobile applications (Compl. ¶4).
IV. Analysis of Infringement Allegations
’897 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| one or more update server machines comprising a processor and operable for sending a terminal dialogue module . . . and a provider dialogue module | The Accused System includes one or more update server machines (e.g., a smartphone accessing the system or a Defendant server) that send dialogue modules (e.g., shopping list item data) to the terminal and service provider machines. | ¶33 | col. 4:49-53 |
| wherein the terminal machine is configured to run a terminal application . . . compris[ing] a first set of computer-executable instructions and a first set of code | The user’s mobile device runs the Defendant app, which allegedly comprises computer-executable instructions (e.g., the Android Runtime) and code (e.g., the app's bytecode) that is not directly executable. The complaint points to its embedded version of patent Figure 2 as depicting this required application structure (Compl. ¶16). | ¶34 | col. 7:44-61 |
| wherein the service provider machine is configured to run a provider application . . . compris[ing] a second set of computer-executable instructions and a second set of code | The Defendant's server runs a provider application (allegedly a .Net application) which comprises computer-executable instructions (e.g., the .Net Common Language Runtime) and code (e.g., the .Net program) that is not directly executable. | ¶35 | col. 7:5-24 |
| wherein the terminal dialogue module modifies the first set of code to produce a first set of updated code . . . [and] does not modify the first set of computer-executable instructions | The "terminal dialogue module" (e.g., data for a shopping list item) allegedly modifies the app's bytecode to produce updated code, without modifying the underlying Android Runtime. | ¶¶36, 18 | col. 8:44-55 |
| wherein the first set of updated code adapts the terminal application to use a modified dialogue sequence with the service provider machine | The updated code adapts the mobile app to use a new sequence of prompts and data entries, such as when new items are added to a shopping list and appear on the user's device. | ¶¶17, 36 | col. 8:63-9:3 |
’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 . . . by running a terminal application . . . compris[ing] first computer-executable instructions and first code | The Kroger app on a user’s device (terminal machine) displays prompts for a user to, for example, create or review a shopping list. The app is alleged to comprise executable instructions (Android Runtime) and code (app bytecode). | ¶51 | col. 10:41-43 |
| accepting a first data entry at the terminal machine | The user interacts with the app to create or edit a shopping list item, which constitutes accepting a data entry. | ¶52 | col. 10:43-44 |
| communicating information associated with the first data entry from the terminal machine to the service provider machine | This shopping list information is communicated to the Defendant's server to be stored for future access. | ¶53 | col. 10:49-53 |
| receiving, at the terminal machine, a terminal dialogue module that updates at least a portion of the first code to produce first updated code | The user's device receives information (allegedly a "dialogue module" in JSON format) from the server that updates the app's code (bytecode) to produce updated code, such as by reflecting a new item in the shopping list. | ¶55 | col. 8:36-43 |
| 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 updated code causes the app to display a new or modified view, such as the ability to access a new shopping list, which represents a second prompt in a modified dialogue. | ¶55 | col. 8:63-67 |
| wherein at least one of the first code, the second code, and the first updated code comprise intermediate code | The complaint alleges that the app's bytecode constitutes the required "intermediate code." | ¶55 | col. 7:30-31 |
Identified Points of Contention
- Scope Questions: The complaint alleges that the "update server machine" can be the user's own device or one of the Defendant's servers (Compl. ¶33). This raises the question of whether the accused architecture truly embodies the distinct three-entity structure recited in system claim 1 of the ’897 Patent, or if it is a more conventional two-party client-server system.
- Technical Questions: A primary question is whether the data packets (e.g., JSON payloads) sent to the Kroger app constitute "code" that is "translated" by the application, as required by the patent and the prior claim construction from the Unikey case (Compl. ¶16). The defense may argue this is merely data being rendered by the application, not interpretable code that modifies the application's logic in the manner claimed. The plaintiff's mapping of Android bytecode to "code" and the Android Runtime to "computer-executable instructions" will be a central technical issue for the court to resolve (Compl. ¶34).
V. Key Claim Terms for Construction
The Term: "code"
- Context and Importance: This term is foundational, as the patents distinguish between directly-executable "instructions" and interpretable "code." The infringement theory depends on mapping data like Android bytecode or JSON payloads to this term. Practitioners may focus on this term because its application to the accused technology is the linchpin of the infringement case, and it was previously construed in S3G v. Unikey as "information that must be translated before it can be executed on a processor" (Compl. ¶16, fn 6).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification provides a functional definition, stating "[t]he code represents at least some information that must be translated by the software application before it can be implemented on the machine processor," which is not limited to a specific format (’897 Patent, col. 4:30-34).
- Evidence for a Narrower Interpretation: The specification frequently uses "Java Byte Code" as an exemplary form of "intermediate code" (’897 Patent, col. 7:30-31), which could be used to argue that the term requires a compiled, machine-like format rather than a structured data format like JSON.
The Term: "dialogue module"
- Context and Importance: The infringement allegations characterize data transmissions, such as shopping list updates, as "dialogue modules" (Compl. ¶33). The definition of this term is critical to determining if these routine data packets meet the structural requirements of the claims. The Unikey court held that the claim language demonstrates the term "refers to a particular type of structure rather than to any structure for performing a function" (Compl. ¶20).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the module as containing "portions of code and/or instructions" and notes that in a preferred embodiment it "is less than 1 Mb," suggesting it is a discrete, transportable data package (’897 Patent, col. 6:51-53, 6:61-63).
- Evidence for a Narrower Interpretation: The patent depicts a "Design Tool" (FIGS. 8A-8B) for creating dialogue modules, which may imply a specifically authored and structured file designed for application modification, rather than a generic data payload generated automatically by a server in response to a user action (’897 Patent, col. 14:24-52).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement by asserting that Kroger provides the mobile app and actively encourages and instructs customers to use it in a manner that infringes the patents (Compl. ¶¶42, 61, 79). It alleges contributory infringement on the basis that the accused system is not a staple article of commerce suitable for substantial non-infringing use and is especially made to infringe (Compl. ¶¶43, 62, 80).
- Willful Infringement: The complaint alleges willful infringement based on Defendant's knowledge of the patents "at least since the filing of this complaint" (Compl. ¶¶30, 48, 67). No specific facts supporting pre-suit knowledge of the patents are alleged.
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of technical characterization: does the data transmitted to the Kroger app, such as a JSON payload containing shopping list information, meet the structural and functional requirements of "code" within a "dialogue module" as that term has been previously construed, or is it merely conventional data rendered by the application?
- A key question of structural correspondence will be whether the accused client-server architecture, involving a user's device and backend servers, can be mapped onto the distinct three-part "terminal machine," "service provider machine," and "update server machine" system required by claim 1 of the ’897 patent.
- An underlying evidentiary question will be one of operational function: can Plaintiff demonstrate that the accused app's bytecode is truly "modified" or "replaced" by incoming server data in the manner claimed, rather than the app's executable instructions simply processing that data to update a display?