DCT

5:23-cv-00086

S3G Technology LLC v. Gap Inc

Key Events
Complaint
complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 5:23-cv-00086, E.D. Tex., 08/11/2023
  • Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district (a retail store in Texarkana, TX) and conducts business related to the accused instrumentalities within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s mobile e-commerce applications and associated server systems for its various brands infringe three patents related to methods for efficiently modifying software on remote devices.
  • Technical Context: The technology concerns a client-server architecture designed to update application functionality by sending small "dialogue modules" rather than replacing the entire application, which aims to conserve network bandwidth and improve efficiency.
  • Key Procedural History: The complaint notes that the asserted patents were previously litigated in S3G Tech. LLC v. Unikey Techs., Inc. in the Eastern District of Texas, which resulted in court-adopted constructions for key claim terms such as "code," "computer-executable instructions," and "dialogue module." The complaint also references the prosecution history, noting that claims were allowed by the patent examiner based on the unique three-entity system structure, which was allegedly absent from the prior art.

Case Timeline

Date Event
2009-07-23 Earliest Priority Date for ’124, ’571, and ’758 Patents
2013-07-11 ’571 Patent Notice of Allowability Issued
2013-10-29 U.S. Patent No. 8,572,571 Issued
2016-04-05 U.S. Patent No. 9,304,758 Issued
2017-11-01 Claim constructions adopted in prior S3G v. Unikey litigation
2018-04-10 U.S. Patent No. 9,940,124 Issued
2023-08-09 "Last Updated" date for accused The Gap Android and iOS applications
2023-08-11 Complaint Filed

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"

  • Patent Identification: U.S. Patent No. 9,940,124, issued April 10, 2018.

The Invention Explained

  • Problem Addressed: The patents describe the difficulty of distributing newly compiled software updates to a large number of geographically dispersed devices, especially over wireless networks with limited bandwidth (Compl. ¶12-14, citing ’571 Patent, col. 2:1-52). Sending a full application update can be slow, costly, and difficult to manage across different application versions (Compl. ¶14; ’571 Patent, col. 2:26-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, an update server sends small "dialogue modules" containing "code" to the terminal and service provider machines (Compl. ¶15). This "code" is not directly executable machine code but rather information that must be translated or interpreted by the existing application to modify its behavior and dialogue sequence with the user (Compl. ¶16; ’571 Patent, col. 4:21-25). Figure 2 from the asserted patents, which illustrates the claimed three-entity computer system structure and the components of the terminal and service provider applications, is referenced in the complaint to explain this architecture (Compl. p. 7).
  • Technical Importance: This method is intended to reduce network bandwidth utilization, enabling more efficient and rapid modification of applications running on remote devices (Compl. ¶23; ’571 Patent, col. 6:47-49).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1 (Compl. ¶28).
  • Essential elements of claim 1 include:
    • A method of conducting a dialogue between a terminal machine and a service provider machine.
    • Displaying a first prompt by running a terminal application that comprises first computer-executable instructions and first code.
    • Communicating information from the terminal to the service provider machine, which runs a provider application comprising second computer-executable instructions and second code.
    • Storing at least a portion of the information for analysis.
    • 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 comprises intermediate code.
  • The complaint does not explicitly reserve the right to assert dependent claims but makes general allegations of infringement.

U.S. Patent No. 8,572,571 - "Modification of Terminal and Service Provider Machines Using an Update Server Machine"

  • Patent Identification: U.S. Patent No. 8,572,571, issued October 29, 2013.

The Invention Explained

  • Problem Addressed: The patent identifies the technical challenge of efficiently updating software applications on remote devices, particularly when systems are distributed over large areas or rely on wireless networks where bandwidth is a constraint (’571 Patent, col. 2:18-44).
  • The Patented Solution: The patent discloses a system architecture comprising an update server, a terminal machine, and a service provider machine. The update server transmits "dialogue modules" containing "code" (e.g., Java Byte Code) to the terminal and provider machines to modify their respective applications without replacing the underlying computer-executable instructions (’571 Patent, Abstract; col. 4:21-34). This allows for dynamic changes to the application's interactive "dialogue protocol" (’571 Patent, col. 4:8-16).
  • Technical Importance: This architecture allows for lightweight, efficient updates to distributed software, conserving computing resources and network bandwidth while improving design flexibility (’571 Patent, col. 14:43-48).

Key Claims at a Glance

  • The complaint asserts at least independent claim 2 (Compl. ¶47).
  • Essential elements of claim 2 include:
    • A system with an update server machine, a terminal machine, and a service provider machine.
    • The update server machine is operable for sending a terminal dialogue module and a provider dialogue module.
    • The terminal machine is configured to run a terminal application with a first set of computer-executable instructions and a first set of code, where the instructions are directly executable but the code is not.
    • The service provider machine is configured to run a provider application with a second set of computer-executable instructions and a second set of code, with a similar distinction.
    • The terminal dialogue module modifies the first set of code to produce updated code, adapting the terminal application to use a second sequence of prompts.
  • The complaint does not explicitly reserve the right to assert dependent claims.

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.
  • Technology Synopsis: This patent, from the same family as the ’124 and ’571 patents, addresses the problem of inefficiently updating software on remote devices. It discloses a three-part system (update server, terminal, service provider) that uses small "dialogue modules" containing non-directly-executable "code" to modify application behavior, thereby avoiding the need to transmit large, fully-compiled application updates.
  • Asserted Claims: The complaint asserts at least independent claim 1 (Compl. ¶65).
  • Accused Features: The complaint alleges that the Defendant's mobile app (terminal) and server (service provider) system infringes. Specifically, it alleges that when a user interacts with a feature like "Favorite address," the system sends information (e.g., JSON data) from the server to the app, which functions as a "dialogue module" to replace a portion of the app's "first code" (bytecode) and modify the subsequent user dialogue (Compl. ¶67-70).

III. The Accused Instrumentality

Product Identification

  • The "Accused System" includes the mobile applications for The Gap, Old Navy, Banana Republic, and Athleta on Android and iOS devices, along with the associated backend server systems, software, and computing devices that support them (Compl. ¶7, fn. 3).

Functionality and Market Context

  • The complaint describes the Accused System as a client-server architecture where the user's mobile device runs the "Defendant app" (the "terminal machine") and communicates with Defendant's servers (the "service provider machine") (Compl. ¶29-30). The functionality cited as infringing involves a user managing "favorite address" information (Compl. ¶30, ¶49).
  • In this process, the server allegedly sends information in JSON format to the user's app. The complaint alleges this JSON data constitutes a "terminal dialogue module" that "updates" a portion of the app's code (identified as the app's bytecode) to produce "updated code." This updated code then adapts the application to display a new or modified sequence of prompts to the user, such as the ability to access a new favorite address (Compl. ¶34, ¶52).
  • The complaint alleges Defendant is an "omni-channel retailer" using the Accused Instrumentalities in connection with its retail sales across its major brands (Compl. ¶7).

IV. Analysis of Infringement Allegations

’124 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
a method comprising displaying a first prompt on a terminal display of the 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 Defendant app prompts a user to review or edit favorite address information. The app's directly executable instructions (e.g., Android Runtime) and non-directly-executable code (e.g., bytecode) conduct this dialogue. ¶30 col. 16:19-27
communicating information...from the terminal machine to the service provider machine...the service provider machine using a provider application, the provider application comprising second computer-executable instructions and second code that conduct the service provider machine's portion of the dialogue User data, such as an edited favorite address, is sent from the app to the Defendant server. The server runs a .NET application (provider application) with directly executable instructions (CLR engine) and non-directly-executable code (.NET code). ¶32 col. 16:28-39
storing at least a portion of the information associated with the first data entry in memory for analysis The server stores user data, such as an order for a favorite address, for analysis to make rewards available to the user. ¶33 col. 16:44-46
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 at least one of the first code, the second code, and the first updated code comprise intermediate code The app receives a "terminal dialogue module" (e.g., a JSON object) from the server. This module updates the app's bytecode ("first code") to produce "first updated code." The bytecode is identified as intermediate code. ¶34 col. 16:47-52, 63-65
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 with the service provider machine The updated bytecode allows the app to display a "second prompt," such as the ability to access a newly added favorite address, which constitutes a modified dialogue sequence. ¶34 col. 16:53-58

’571 Patent Infringement Allegations

Claim Element (from Independent Claim 2) Alleged Infringing Functionality Complaint Citation Patent Citation
an update server machine comprising a processor and operable for sending a terminal dialogue module to the terminal machine and a provider dialogue module to the service provider machine The user's device or the Defendant's server acts as the update server, sending dialogue modules (e.g., favorite address data in JSON format) to the terminal (app) and provider (server) machines. ¶49 col. 17:51-57
wherein the terminal machine is configured to run a terminal application...comprises a first set of computer-executable instructions...and a first set of code, wherein the first set of computer-executable instructions are able to execute directly...and wherein the first set of code is not able to execute directly The user's device (terminal machine) runs the Defendant app. The Android Runtime (ART) comprises the executable instructions, while the app's bytecode comprises the code that cannot be executed directly. ¶50 col. 17:58-67
wherein the service provider machine is configured to run a provider application...comprises a second set of computer-executable instructions...and a second set of code, wherein the second set of computer-executable instructions are able to execute directly...and wherein the second set of code is not able to execute directly The Defendant server (service provider machine) runs a .NET application. The CLR engine comprises the executable instructions, while the .NET program comprises the code that cannot be executed directly. ¶51 col. 18:14-23
wherein the terminal dialogue module modifies the first set of code to produce a first set of updated code...wherein the first set of updated code adapts the terminal application to use a second sequence of prompts...for the terminal machine's portion of a modified dialogue sequence The dialogue module (e.g., favorite address data) modifies the app's bytecode ("first set of code") to produce updated code. This updated code adapts the app to display a new sequence of prompts, such as when new favorite addresses are added and appear on the device. ¶52 col. 18:24-34
  • Identified Points of Contention:
    • Scope Questions: A primary question will be whether a data format like JSON, as alleged by the complaint, meets the patent's definition of "code," which has been construed as "information that must be translated before it can be executed on a processor" (Compl. ¶16, fn. 5). The defense may argue that JSON is merely data interpreted by an application, not "code" that is "translated for execution."
    • Scope Questions: The complaint alleges that the "update server machine" can be the user's own smartphone or the Defendant's server (Compl. ¶49). A point of contention may be whether the patent's disclosure supports one of the primary transaction participants (the terminal or service provider machine) also acting as the distinct third entity ("update server machine") required by the claims.
    • Technical Questions: A core technical question will be what evidence supports the allegation that the accused "dialogue module" (JSON data) actually "updates" or "modifies" the "first code" (the app's bytecode) (Compl. ¶34, ¶52). The defense will likely question whether the bytecode is altered at all, or if it merely remains static while interpreting the incoming JSON data to render a user interface, which may be a fundamentally different and non-infringing operation.

V. Key Claim Terms for Construction

  • The Term: "code"

  • Context and Importance: This term is central to the entire infringement theory. The viability of the case may depend on whether data-interchange formats like JSON fall within the scope of "code" as used in the patents. Practitioners will focus on this term because the complaint's allegations rely on an interpretation where JSON data is equated with the patent's concept of "code" that is distinct from "computer-executable instructions."

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The patent specification distinguishes "code" from directly executable instructions and notes it can be "intermediate code, such as Java Byte Code," which is "interpreted" by a virtual machine (’571 Patent, col. 8:53-56; col. 2:45-54). Plaintiff may argue this supports a functional definition where any information that is not directly executable but must be interpreted or translated by the application to alter its behavior, like JSON, qualifies as "code."
    • Evidence for a Narrower Interpretation: The specification repeatedly uses "Java Byte Code" as its primary example of intermediate code (’571 Patent, col. 8:55). A defendant may argue that the term "code" should be limited to such compiled, procedural instruction sets and does not extend to declarative data structures like JSON, which are consumed as data by an application rather than being "translated" for "execution."
  • The Term: "updates at least a portion of the first code" / "modifies the first set of code"

  • Context and Importance: The infringement allegation hinges on the claim that receiving JSON data "updates" or "modifies" the mobile application's bytecode. The definition of this action is critical.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The patents describe the outcome of this action as adapting the application "to use a second sequence of prompts" (’571 Patent, col. 18:31-32). Plaintiff may argue that any action by the dialogue module that causes the application to exhibit a new behavior or dialogue path constitutes a functional "update" or "modification" of the code's behavior, regardless of the underlying mechanism.
    • Evidence for a Narrower Interpretation: The specification discusses the dialogue module replacing or supplementing existing code saved on the machine (’571 Patent, col. 8:44-52). A defendant may argue this implies a direct alteration of the stored code file itself, not merely providing new data for the existing, unchanged code to process.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges induced infringement, stating that Defendant instructs customers to download and use the accused apps in a manner that practices the patented methods (Compl. ¶40, ¶58, ¶76). It also alleges contributory infringement on the basis that the accused apps are not staple articles of commerce and are especially adapted to infringe the patents (Compl. ¶41, ¶59, ¶77).
  • Willful Infringement: Willfulness is alleged based on Defendant's "actual knowledge" of the asserted patents, which the complaint claims exists "at least since the filing of the original complaint" (Compl. ¶27, ¶46, ¶64). This suggests an allegation of post-filing willfulness.

VII. Analyst’s Conclusion: Key Questions for the Case

  • A core issue will be one of definitional scope: can the term "code", which the patent distinguishes from directly executable instructions and which a prior court construed as "information that must be translated before it can be executed," be interpreted to cover modern, declarative data-interchange formats like JSON, or is its meaning confined to intermediate compiled languages like Java Bytecode as exemplified in the specification?
  • A key evidentiary question will be one of technical mechanism: does the accused system's process—where an application receives a JSON data object and interprets it to alter the user interface—constitute "updating" or "modifying" the application's underlying bytecode as required by the claims? Or, is this a fundamentally different technical operation where the code remains static while consuming new data, which may not meet the claim limitations?
  • A final question will concern divided infringement: given that the accused method involves actions by both the Defendant's server and the end-user's device, the court will have to analyze whether the Defendant "directs or controls" the users' actions to such a degree that all steps of the claimed methods can be attributed to the Defendant for the purposes of establishing direct infringement (Compl. ¶37-38).