DCT
5:23-cv-00014
S3G Technology LLC v. Torrid LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: Torrid LLC (California)
- Plaintiff’s Counsel: Parker, Bunt & Ainsworth, P.C.
- Case Identification: 5:23-cv-00014, E.D. Tex., 05/31/2023
- Venue Allegations: Plaintiff alleges venue is proper based on Defendant having a "regular and established place of business" in the district, specifically a retail store in Texarkana, Texas, and deriving substantial revenue from the district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile e-commerce applications and associated backend server systems infringe patents related to a method for efficiently modifying distributed software applications using small, translatable "dialogue modules."
- Technical Context: The technology addresses challenges in updating software on numerous remote devices, particularly over bandwidth-constrained networks, by avoiding the need to redeploy large, fully compiled application files.
- Key Procedural History: The complaint notes that in prior litigation involving the asserted patents (S3G Tech. LLC v. Unikey Techs., Inc.), a court construed key claim terms, including "code" and "dialogue module." The complaint also cites the patent examiner's statement of reasons for allowance during prosecution, noting the claimed structure was found to be non-obvious over the prior art.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Earliest Priority Date for ’124, ’571, and ’758 Patents |
| 2013-07-11 | Notice of Allowability for patent in ’571 Patent family |
| 2013-10-29 | U.S. Patent No. 8,572,571 Issued |
| 2016-04-05 | U.S. Patent No. 9,304,758 Issued |
| 2018-04-10 | U.S. Patent No. 9,940,124 Issued |
| 2023-05-08 | Accused Torrid Android App Updated |
| 2023-05-10 | Accused Torrid iOS App Updated |
| 2023-05-31 | Amended 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, "Modification of Terminal and Service Provider Machines Using an Update Server Machine," Issued April 10, 2018.
The Invention Explained
- Problem Addressed: The patent addresses the difficulty and inefficiency of updating software applications distributed across a large number of devices, particularly when those devices are geographically dispersed and connected via wireless networks with limited bandwidth (Compl. ¶¶13-14; ’124 Patent, col. 2:18-44). Transmitting a full, newly compiled application to each device is time-consuming and may exceed network capacity (Compl. ¶14; ’124 Patent, col. 2:26-32).
- The Patented Solution: The invention proposes a three-entity system architecture: a "terminal machine" (e.g., a mobile device), a "service provider machine" (e.g., a backend server), and an "update server machine" (Compl. ¶15). Instead of sending a full application, the update server sends a small "dialogue module" containing "code" to the terminal or service provider machine. This "code" is defined as information that must be translated by the application before execution (e.g., bytecode), as distinct from the application's native, directly-executable instructions (Compl. ¶¶16-17; ’124 Patent, col. 4:21-25). This module modifies the application's behavior—such as the sequence of user prompts in a dialogue—without replacing the underlying executable file, thereby enabling efficient updates (Compl. ¶19; ’124 Patent, Abstract).
- Technical Importance: This method of partial, modular updates using interpreted code sought to reduce network bandwidth usage and improve the efficiency of maintaining and customizing applications on remote devices (Compl. ¶23).
Key Claims at a Glance
- The complaint asserts at least independent method claim 1 (Compl. ¶28).
- The essential steps of independent claim 1 include:
- Displaying a first prompt via a terminal application that comprises first computer-executable instructions and a first set of code.
- Accepting a first data entry.
- Communicating information to a service provider machine running 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.
- The complaint does not explicitly reserve the right to assert other claims but makes general allegations of infringement of "one or more claims" (Compl. ¶28).
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, "Modification of Terminal and Service Provider Machines Using an Update Server Machine," Issued October 29, 2013.
The Invention Explained
- Problem Addressed: The '571 Patent, part of the same family as the ’124 Patent, addresses the same technical problem of inefficiently updating software on geographically distributed devices over limited-bandwidth networks (Compl. ¶¶12-14; ’571 Patent, col. 2:18-44).
- The Patented Solution: The patent describes the same three-entity system architecture (terminal, service provider, update server) seen in the ’124 Patent. The complaint includes Figure 1 from the patent, which depicts the claimed three-entity computer system structure involving an update server machine, a service provider machine, and a terminal machine (Compl. ¶15, p. 7). The solution centers on using "dialogue modules" sent from the update server to modify a distinct "code" portion of an application, leaving the "computer-executable instructions" portion of the application unmodified (’571 Patent, Abstract, col. 8:44-52). The complaint provides Figure 2 from the patent, which illustrates the specific application structure comprising separate computer-executable instructions and translatable code on both the terminal and service provider machines (Compl. ¶16, p. 7).
- Technical Importance: The system architecture was designed to provide a more efficient and scalable method for deploying software modifications compared to traditional full-application replacement (Compl. ¶9, ¶23).
Key Claims at a Glance
- The complaint asserts at least independent system claim 2 (Compl. ¶47).
- The essential elements of independent claim 2 include:
- An update server machine operable for sending a terminal dialogue module and a provider dialogue module.
- A terminal machine configured to run a terminal application comprising a first set of computer-executable instructions and a first set of code.
- A service provider machine configured to run a provider application comprising a second set of computer-executable instructions and a second set of code.
- The terminal dialogue module modifies the first set of code to produce updated code, and the provider dialogue module modifies the second set of code to produce updated code.
- The dialogue modules do not modify the computer-executable instructions.
- The updated code adapts the respective applications to use a second sequence of prompts and data entries.
- The complaint makes general allegations of infringement of "one or more claims" (Compl. ¶47).
Multi-Patent Capsule: 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, "Modification of Terminal and Service Provider Machines Using an Update Server Machine," Issued April 5, 2016.
- Technology Synopsis: As a member of the same patent family, the ’758 Patent addresses the problem of inefficient software updates on remote devices. It claims a method of conducting a dialogue between a terminal machine and a service provider machine where a "terminal dialogue module" is received by the terminal machine to replace a portion of its "first code" (e.g., Java Byte code) to produce "first updated code," thereby adapting the application to a modified dialogue sequence without recompiling its executable instructions (Compl. ¶¶12-15, 70; ’758 Patent, Abstract).
- Asserted Claims: At least independent method claim 1 (Compl. ¶65).
- Accused Features: The complaint alleges that the Accused System's method of operation infringes, where the Defendant's server sends a "terminal dialogue module" (e.g., a JSON file with wish list data) to the Torrid mobile app, which allegedly replaces a portion of the app's bytecode to display updated wish list prompts (Compl. ¶¶67-70).
III. The Accused Instrumentality
Product Identification
- The "Accused Instrumentalities" or "Accused System" are identified as Defendant Torrid's mobile applications for Android and iOS (the "Defendant app"), along with the backend systems, servers, and software that support them (Compl. ¶¶7-8).
Functionality and Market Context
- The Accused System is an e-commerce platform that allows users to browse products, manage account information, and make purchases. The complaint focuses specifically on the "wish list" functionality (Compl. ¶30). In this context, the user's mobile device running the Torrid app acts as the "terminal machine," and Defendant's backend servers act as the "service provider machine" (Compl. ¶¶30, 32). The complaint alleges that when a user interacts with their wish list, the app communicates with the server, and the server sends back information, allegedly in the form of a "dialogue module" (e.g., a JSON data file), which updates how the wish list is displayed and interacted with on the app (Compl. ¶¶34, 49). The complaint asserts that Defendant derives significant revenue from services provided through this system (Compl. ¶4).
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...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 Torrid app (terminal application) on an Android device displays prompts to the user (e.g., to review a wish list). The app is alleged to comprise directly-executable instructions (the Android Runtime, ART) and "first code" (the app's bytecode) (Compl. ¶30). | ¶30 | col. 15:15-24 |
| accepting a first data entry...associated with the first prompt | The Torrid app accepts user input, such as selections to review, edit, or delete a wish list (Compl. ¶30). | ¶31 | col. 15:25-28 |
| communicating information...from the terminal machine to the service provider machine...the service provider machine using a provider application...comprising second computer-executable instructions and second code | Information from user wish list edits on the app is communicated to Defendant's server. The server application is alleged to comprise executable instructions (CLR engine) and "second code" (.NET code) (Compl. ¶32). | ¶32 | col. 15:29-39 |
| storing at least a portion of the information associated with the first data entry in memory for analysis | The service provider (Defendant's server) stores wish list order information for analysis to make rewards available to the user (Compl. ¶33). | ¶33 | col. 15:40-42 |
| 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 Torrid app receives a "terminal dialogue module" (allegedly JSON data) from the server. This module is alleged to update the app's bytecode ("first code") to produce "first updated code," which adapts the app to display a new prompt (e.g., the ability to access a new wish list) (Compl. ¶34). | ¶34 | col. 15:43-52 |
'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 Accused System includes an "update server machine" (identified as either the user's device or the Defendant's server) that sends a "terminal dialogue module" (wish list data) to the app and a "provider dialogue module" to the server (Compl. ¶49). | ¶49 | col. 16:51-58 |
| 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 code is not able to execute directly on the terminal processor | The terminal machine (user's device) runs the Torrid app. The app comprises computer-executable instructions (Android Runtime) and a "first set of code" (the app's bytecode), which cannot be directly executed by the processor (Compl. ¶50). | ¶50 | col. 17:1-9 |
| 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 code is not able to execute directly on the provider processor | The service provider machine (Defendant's server) runs a server application. This application comprises computer-executable instructions (CLR engine) and a "second set of code" (the .NET program), which is not directly executed by the processor (Compl. ¶51). | ¶51 | col. 17:11-23 |
| 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 | The terminal dialogue module (wish list data) allegedly modifies the app's bytecode to produce updated code for a new dialogue sequence (e.g., new wish list items appearing on the device). The provider dialogue module allegedly modifies the server's .NET code to produce updated code for the server's portion of the dialogue (Compl. ¶52). | ¶52 | col. 17:24-41 |
| wherein the terminal 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 | The complaint alleges that the dialogue modules do not modify the underlying executable instructions (ART on the device, CLR engine on the server), as is readily understood by one of ordinary skill (Compl. ¶52). | ¶52 | col. 17:29-33 |
- Identified Points of Contention:
- Scope Questions: A central question will be whether the term "dialogue module," which the patent describes as containing "code," can be fairly construed to read on the JSON data files that the complaint alleges are used in the Accused System (Compl. ¶34, ¶49). Resolution will depend on the construction of "dialogue module" and "code."
- Technical Questions: The infringement theory hinges on whether the accused system performs the step of the dialogue module "modify[ing] the first set of code to produce... updated code" (Compl. ¶34, ¶52). A key factual dispute may arise over whether the accused app's bytecode is actually modified, or if the existing, unmodified bytecode simply processes the incoming JSON data to render a new display. The complaint does not detail the technical mechanism for the alleged modification.
- Scope Questions: The complaint's identification of the "update server machine" appears to be ambiguous, alternately suggesting it could be the user's own device or the Defendant's server (Compl. ¶49). This ambiguity raises the question of whether the accused system maps onto the claimed three-entity architecture or is a conventional two-entity client-server system.
V. Key Claim Terms for Construction
The Term: "code"
Context and Importance: This term is foundational to the patent's claimed point of novelty: the distinction between an application's directly-executable instructions and a separate, modifiable "code" component. The infringement case rests on equating application "bytecode" (e.g., Android or .NET) with this claimed "code."
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states that "[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" (’571 Patent, col. 4:21-25). The complaint also cites a prior judicial construction as "information that must be translated before it can be executed on a processor" (Compl. ¶16, fn. 5). This language could support encompassing various forms of interpreted or just-in-time compiled code.
- Evidence for a Narrower Interpretation: The specification provides "Java Byte Code" as a specific example of "intermediary code" (’571 Patent, col. 2:49-50). A defendant may argue the term is limited to such intermediate compiled languages and does not cover any data structure that is merely processed by an application.
The Term: "dialogue module"
Context and Importance: The infringement allegations identify JSON data files as the "dialogue module" (Compl. ¶34, ¶49). The viability of the infringement case depends on this characterization.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The complaint cites a prior court finding based on the specification that a dialogue module "can contain code or other data and can be communicated" (Compl. ¶20, Ex. D at 12). This suggests flexibility in its content.
- Evidence for a Narrower Interpretation: The same court finding, also cited in the complaint, held that "the claim uses the term ‘module’ to refer to a particular type of structure rather than to any structure for performing a function" (Compl. ¶20, Ex. D at 12). A party could argue that a simple JSON data object is not the specific "structure" contemplated, which is depicted as containing distinct "terminal code" and "service provider code" components (’571 Patent, Fig. 2).
The Term: "modifies the first set of code to produce a first set of updated code"
Context and Importance: This active limitation is the central mechanism of the invention. Practitioners may focus on this term because the factual basis for infringement turns on whether receiving and processing a JSON data file constitutes "modifying" an app's bytecode to "produce" new, "updated" code.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party might argue that "modifies" should be understood functionally. By providing new data and instructions within the dialogue module, the behavior of the "first set of code" is altered, and its execution results in a new dialogue sequence, which is the functional equivalent of "updated code" (’571 Patent, col. 8:44-52).
- Evidence for a Narrower Interpretation: A party could argue that "modifies" requires a direct alteration of the instructions in the "first set of code" itself, not merely providing new data inputs for the existing, unchanged code to process. The claim language distinguishes this modification of "code" from the modification of a "dialogue sequence," suggesting two different concepts (’124 Patent, cl. 1).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement of infringement, stating Defendant encourages users to download and use the infringing applications through marketing and promotion, and provides instructions for their use, allegedly intending for users to infringe (Compl. ¶¶40, 58). It also alleges contributory infringement, asserting the Accused Instrumentalities are not staple articles of commerce and are especially adapted for infringement (Compl. ¶¶41, 59).
- Willful Infringement: The willfulness allegation is based on Defendant's alleged knowledge of the patents "at least since the filing of the original complaint" (Compl. ¶¶27, 40, 46). This frames the allegation as being based on post-suit conduct.
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 specification describes as a structural element containing translatable "code," be construed to cover the JSON data files allegedly exchanged between the accused mobile app and server? The outcome of this claim construction dispute will be critical.
- A key evidentiary question will be one of technical operation: does the accused system's process of using its existing, unmodified application logic to parse a JSON data file and render a display meet the claim requirement that the dialogue module "modifies the... code to produce... updated code"? The case may turn on whether the plaintiff can prove an actual modification of the app's bytecode, versus the more common operation of an application simply processing new data.
- A third central question will concern architectural mapping: can the plaintiff's infringement theory successfully map the accused client-server system onto the patents' three-entity architecture (terminal, service provider, and a distinct update server), particularly given the complaint's apparent ambiguity in identifying the "update server machine"?