DCT
5:23-cv-00095
S3G Technology LLC v. Advance Auto Parts Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: Advance Auto Parts, Inc. (Delaware)
- Plaintiff’s Counsel: Parker, Bunt & Ainsworth, P.C.
- Case Identification: 5:23-cv-00095, E.D. Tex., 09/21/2023
- Venue Allegations: Plaintiff alleges venue is proper because Defendant has a "regular and established place of business" in the district, specifically citing a store location in Texarkana, Texas, and has transacted business within the district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications and the supporting server infrastructure infringe patents related to a system and method for efficiently modifying software applications on remote devices.
- Technical Context: The technology addresses updating distributed software, such as mobile apps, by sending small "dialogue modules" that change application behavior without requiring a full application reinstall, thereby saving bandwidth and resources.
- Key Procedural History: The complaint references prior litigation involving the same patents (S3G Tech. LLC v. Unikey Techs., Inc.), citing specific claim constructions adopted by the court in that case for key terms such as "code," "computer-executable instructions," and "dialogue module." The complaint also cites the Examiner's Reasons for Allowance during the prosecution of the '897 patent, noting the claimed structure was considered novel and non-obvious over the prior art.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Earliest Priority Date for '897, '124, and '774 Patents |
| 2013-07-11 | Notice of Allowability Issued for '897 Patent Family |
| 2015-07-14 | U.S. Patent No. 9,081,897 Issues |
| 2018-04-10 | U.S. Patent No. 9,940,124 Issues |
| 2019-04-16 | U.S. Patent No. 10,261,774 Issues |
| 2023-08-23 | Last Update to Accused Advance Auto Parts Android App |
| 2023-08-24 | Last Update to Accused Advance Auto Parts iOS App |
| 2023-09-21 | 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
The Invention Explained
- Problem Addressed: The patent addresses the inefficiency of updating software applications across a large number of geographically dispersed devices (Compl. ¶13). Transmitting entire newly compiled applications consumes significant time and network bandwidth, particularly over wireless networks ('897 Patent, col. 2:30-47).
- The Patented Solution: The invention proposes a three-entity architecture: a "terminal machine" (e.g., a user's device), a "service provider machine" (e.g., a central server), and an "update server machine" (Compl. ¶15, FIG. 1). The core innovation is splitting the application software into two parts: a stable set of "computer-executable instructions" (like a runtime engine) and a dynamic set of "code" (which is not directly executable but is translated by the engine). The update server sends small "dialogue modules" that modify only the "code" portion, allowing for efficient updates to the application's functionality and user interface without altering the underlying executable instructions ('897 Patent, col. 4:24-31).
- Technical Importance: This architectural approach was designed to reduce network bandwidth utilization, improve design efficiency, and enable flexible modification of applications on remote devices with limited connectivity (Compl. ¶19; '897 Patent, col. 6:51-53).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶28).
- Claim 1 is a system claim comprising:
- An update server machine operable for sending a terminal dialogue module and a provider dialogue module.
- A terminal machine running an application that comprises a "first set of computer-executable instructions" (able to execute directly) and a "first set of code" (not able to execute directly).
- A service provider machine running an application that comprises a "second set of computer-executable instructions" and a "second set of code."
- The terminal dialogue module modifies the first set of code (but not the executable instructions) to produce updated code.
- The provider dialogue module modifies the second set of code (but not the executable instructions) to produce updated code.
- The updated code adapts the respective applications to use a modified dialogue sequence.
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
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: Similar to the '897 patent, this patent addresses the challenge of efficiently updating and customizing user interaction sequences (dialogues) on remote devices (Compl. ¶¶12-14).
- The Patented Solution: The '124 patent claims a method for conducting a dialogue between a terminal and service provider machine. The method involves the terminal application displaying prompts, accepting user data, and communicating that data to the service provider. Crucially, the method includes the terminal receiving a "terminal dialogue module" that updates a portion of its "first code" to produce "first updated code." This updated code then adapts the terminal application to display a new prompt in a modified dialogue sequence. The patent specifies that at least one of the code sets comprises "intermediate code" ('124 Patent, Abstract; Compl. ¶¶48, 52).
- Technical Importance: This method provides a specific process for dynamically altering application behavior on the fly, enabling customized user experiences without requiring large software downloads ('124 Patent, col. 2:53-61).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶46).
- Claim 1 is a method claim comprising the steps of:
- Displaying a first prompt on a terminal display via 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.
- Storing at least a portion of the information in memory 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 code sets (first, second, or first updated) comprises "intermediate code."
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
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
The '774 patent, a continuation of the same family, claims a method for conducting a dialogue sequence between a terminal and service provider machine. It focuses on the steps of displaying prompts, accepting user input, communicating that input, and then receiving "third code" at the terminal machine that modifies the existing "first code" to produce updated code, which in turn adapts the application for a modified dialogue sequence ('774 Patent, Abstract; Compl. ¶¶66-70).
Asserted Claims
At least independent claim 1 (Compl. ¶65).
Accused Features
The infringement allegations target the functionality of the Defendant's mobile application, specifically how it handles interactions with "saved vehicles." This includes displaying prompts to the user, accepting user selections (e.g., to order parts for a vehicle), communicating with Defendant's servers, and receiving data that dynamically updates the user interface with new prompts or information (Compl. ¶¶67-70).
III. The Accused Instrumentality
Product Identification
The "Accused Instrumentalities" or "Accused System" are identified as the Advance Auto Parts (AAP) mobile applications for Android and iOS, along with the backend systems, servers, and software that support them (Compl. ¶7).
Functionality and Market Context
- The accused functionality centers on the interaction between a user's device running the AAP app (the alleged "terminal machine") and Defendant's backend servers (the alleged "service provider machine") (Compl. ¶¶29-32). The complaint focuses on the "saved vehicle" feature, where a user can manage a list of their vehicles. The complaint alleges that when a user interacts with this feature, the app and server exchange data that constitutes a "dialogue sequence." This data, alleged to be a "dialogue module," dynamically modifies the app's code to present updated prompts and options to the user, such as ordering parts for a newly added vehicle (Compl. ¶¶30, 33, 48).
- The complaint includes a diagram from the patent illustrating the claimed three-entity computer system structure, which it alleges is mirrored by the Accused System (Compl. ¶15, FIG. 1). A second diagram from the patent shows the claimed software structure, which the complaint alleges is also found in the Accused System (Compl. ¶16, FIG. 2).
- The complaint alleges Defendant derives a "significant portion of its revenue" from the products and services facilitated by the Accused System, positioning it as a commercially important part of Defendant's business (Compl. ¶7).
IV. Analysis of Infringement Allegations
'897 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| ...an update server machine... operable for sending a terminal dialogue module to a respective terminal machine and a provider dialogue module to a respective service provider machine... | The Accused System's servers and/or user devices send a "terminal dialogue module" (e.g., data for a saved vehicle) to the user's app and a "provider dialogue module" to the Defendant's server to enable a dialogue sequence. | ¶30 | col. 5:53-67 |
| ...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... | The user's device (terminal machine) runs the Defendant's app. The "computer-executable instructions" are alleged to be the Android Runtime (ART), while the "code" is the app's bytecode, which is not directly executed by the processor. | ¶31 | col. 7:45-50 |
| ...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... | The Defendant's server (service provider machine) runs a .Net application. The "computer-executable instructions" are alleged to be the .Net execution environment (CLR), while the "code" is the .Net program itself. | ¶32 | col. 8:13-20 |
| ...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 modified dialogue sequence... | The data for a "saved vehicle" (terminal dialogue module) modifies the app's bytecode (first set of code) to produce updated code. This updated code enables a modified dialogue, such as displaying new prompts for ordering parts based on the saved vehicle. The complaint alleges the ART itself is not modified. | ¶33, 16-17 | col. 8:50-58 |
Identified Points of Contention
- Scope Questions: A central question will be whether the data exchanged to manage a "saved vehicle" in the accused app constitutes a "terminal dialogue module" as defined by the patent. The defense may argue that this is standard client-server communication (e.g., sending JSON data) and not the specific, code-modifying "dialogue module" structure described in the patent specification.
- Technical Questions: The infringement theory maps the patent's distinction between "computer-executable instructions" and "code" to the relationship between a modern operating system's runtime environment (ART/.NET) and the application bytecode that runs on it. The court will need to determine if this mapping is consistent with the patent's disclosure and the meaning of those terms as construed in prior litigation, or if it describes a generic feature of all modern mobile applications rather than the specific invention.
V. Key Claim Terms for Construction
The Term: "dialogue module"
- Context and Importance: This term is the central component of the claimed invention. The outcome of the case may depend on whether the data packets used by the Accused System (e.g., to update "saved vehicle" information) fall within the scope of this term. Practitioners may focus on this term because the complaint highlights its prior construction as a "particular type of structure" containing "code or instructions related to a dialogue sequence" (Compl. ¶¶19-20).
- Intrinsic Evidence for a Broader Interpretation: The complaint notes a prior court finding that the specification discloses that a "dialogue module" can "contain code or other data and can be communicated," which may support an argument that it is not limited to a specific format (Compl. ¶20).
- Intrinsic Evidence for a Narrower Interpretation: The specification describes the "dialogue module" as containing "code" that "must be translated by the software application before it can be implemented" and states that in a preferred embodiment it is "less than 1 Mb to facilitate communication over a network with limited data transfer capacity," suggesting a specific, lightweight, non-executable format designed to solve the bandwidth problem ('897 Patent, col. 4:24-31, col. 6:51-53).
The Term: "code"
- Context and Importance: The patents create a critical distinction between directly executable instructions and "code" that requires translation. The infringement theory depends on mapping application bytecode to this definition of "code." Practitioners may focus on this term because the complaint relies on a prior construction defining it as "information that must be translated before it can be executed on a processor" (Compl. ¶8, footnote 5).
- Intrinsic Evidence for a Broader Interpretation: The general definition of "information that must be translated" could be argued to encompass any high-level or intermediate language, including the .Net and Android app code alleged to infringe (Compl. ¶¶31-32).
- Intrinsic Evidence for a Narrower Interpretation: The patent specification frequently uses "Java Byte Code" as the primary example of "intermediate code" that is translated by a virtual machine, which could support an argument that the term is limited to that specific technological context and does not broadly cover all modern application programs running on an operating system runtime ('897 Patent, col. 1:63-65).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement by asserting that Defendant instructs customers to download and use the infringing applications, thereby intending for them to perform the infringing methods (Compl. ¶39). It also pleads contributory infringement, alleging the Accused Instrumentalities are not staple articles of commerce and are especially adapted to infringe the patents (Compl. ¶40).
- Willful Infringement: Willfulness is alleged based on Defendant's knowledge of the patents "at least since the filing of this Complaint" (Compl. ¶¶27, 39, 45). The complaint does not allege any pre-suit knowledge.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural equivalence: does the standard client-server architecture of the accused Advance Auto Parts system—a modern mobile app communicating with a backend web service—embody the specific three-machine structure and the unique two-part software distinction (directly executable instructions vs. translatable "code") claimed and previously construed in the patents-in-suit?
- A key evidentiary question will be one of functional scope: do the standard data packets, such as JSON, allegedly used to update the "saved vehicle" feature in the accused app, perform the function of and possess the specific structure of a "dialogue module" as contemplated by the patent, or is this a generic label applied to conventional data exchange?