6:23-cv-00752
S3G Technology LLC v. AutoZone Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: AutoZone, Inc. (Nevada)
- Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
- Case Identification: 6:23-cv-00752, W.D. Tex., 11/07/2023
- Venue Allegations: Venue is alleged to be proper in the Western District of Texas because AutoZone is subject to personal jurisdiction and has a regular and established place of business in the district, specifically a store located in Waco, Texas.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications and supporting server infrastructure infringe patents related to a system for dynamically modifying software applications on remote devices.
- Technical Context: The technology addresses methods for updating client-server applications by sending small packets of interpretable "code" to modify application behavior, avoiding the need to transmit and reinstall a full new version of the software.
- Key Procedural History: Plaintiff has engaged in a significant litigation campaign, with the complaint listing numerous related cases against other defendants. The complaint also heavily relies on claim construction rulings from a prior case, S3G Tech. LLC v. Unikey Techs., Inc., to support its interpretation of key patent terms. The complaint further notes that a Patent Examiner allowed related claims based on the uniqueness of the claimed structure.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Priority Date for ’124, ’571, and ’774 Patents |
| 2013-10-29 | Issue Date for U.S. Patent No. 8,572,571 |
| 2017-07-07 | Unikey Claim Construction Order Issued |
| 2018-04-10 | Issue Date for U.S. Patent No. 9,940,124 |
| 2019-04-16 | Issue Date for U.S. Patent No. 10,261,774 |
| 2023-09-13 | AutoZonePro Android App Last Updated |
| 2023-09-14 | AutoZonePro iOS App Last Updated |
| 2023-10-16 | AutoZone Android App Last Updated |
| 2023-10-17 | AutoZone iOS App Last Updated |
| 2023-11-07 | 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 updating software applications distributed across many remote devices, particularly over wireless networks. Transmitting an entire recompiled application can be slow, costly, and bandwidth-intensive (Compl. ¶¶ 12-14; ’571 Patent, col. 2:18-52).
- The Patented Solution: The invention proposes a three-part system architecture comprising a terminal machine (e.g., a mobile device), a service provider machine (e.g., a server), and an update server machine (Compl. ¶15; ’571 Patent, Fig. 1). Instead of sending a whole new application, the update server sends small “dialogue modules” to the terminal and provider machines. These modules contain “code,” which is distinct from the application’s underlying computer-executable instructions. This “code” is information that must be translated or interpreted by the application to modify its behavior, such as changing the sequence of user prompts (Compl. ¶16; ’571 Patent, col. 4:21-25). This architectural distinction is illustrated in Figure 2 of the patent, which shows an application composed of both computer-executable instructions (224) and separate "code" (222) (Compl. ¶16).
- Technical Importance: This approach is presented as a way to achieve greater efficiency by reducing network bandwidth utilization and enabling rapid, lightweight modifications to distributed applications without full reinstallations (Compl. ¶23; ’571 Patent, col. 6:47-49).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶28).
- Claim 1 is a method claim with the following essential steps:
- Displaying a first prompt on a terminal machine via a terminal application, where the application comprises "first computer-executable instructions" and "first code".
- Accepting a first data entry from the user.
- Communicating information from the terminal machine to a service provider machine, which runs a provider application comprising "second computer-executable instructions" and "second code".
- Receiving, at the terminal machine, a "terminal dialogue module" that updates a portion of the "first code" to produce "first updated code".
- Using the "first updated code" to adapt the terminal application to display a second prompt for a modified dialogue sequence.
- Wherein at least one of the "first code", "second code", or "first updated code" comprises "intermediate code".
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
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 a parent to the ’124 Patent, the ’571 Patent addresses the same technical problem of inefficiently updating software on numerous, geographically dispersed remote devices (Compl. ¶¶ 12-14; ’571 Patent, col. 2:18-52).
- The Patented Solution: The solution is the same three-entity architecture (terminal, service provider, update server) described for the ’124 Patent. The core concept is the use of “dialogue modules” containing interpretable “code” to modify application behavior without replacing the application’s non-modifiable, computer-executable instruction set (Compl. ¶¶ 15-19; ’571 Patent, col. 4:21-25). The complaint references Figure 1 from the patent to illustrate the three-machine system communicating via wireless transceivers (Compl. ¶15).
- Technical Importance: This system is intended to provide computing resource and network utilization benefits by enabling lightweight application updates (Compl. ¶20; ’571 Patent, col. 6:47-49).
Key Claims at a Glance
- The complaint asserts at least claim 2 (Compl. ¶47). Claim 2 depends on independent claim 1.
- Independent Claim 1 is a system claim comprising the following key components:
- 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, which comprises a "first set of computer-executable instructions" and a "first set of code".
- A "service provider machine" configured to run a provider application, which comprises a "second set of computer-executable instructions" and a "second set of code".
- Wherein the "terminal dialogue module" modifies the "first set of code" and the "provider dialogue module" modifies the "second set of code".
- Wherein the dialogue modules do not modify the first or second sets of "computer-executable instructions".
- The complaint does not explicitly reserve the right to assert other 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
Multi-Patent Capsule
- Technology Synopsis: As a continuation of the other asserted patents, the ’774 Patent addresses the same challenge of efficiently updating remote software applications. It discloses the same three-machine architecture that uses lightweight "dialogue modules" to deliver interpretable "code," which modifies application functionality without altering the underlying executable instructions (Compl. ¶¶ 12-15).
- Asserted Claims: At least independent claim 1 (Compl. ¶65).
- Accused Features: The accused features are the AutoZone mobile applications and backend servers. The complaint alleges that functions like updating a user's list of saved vehicles involve the server sending data (a "dialogue module") to the app to modify its behavior ("code") (Compl. ¶¶ 67-70).
III. The Accused Instrumentality
Product Identification
- The "Accused System" includes Defendant's "AutoZone – Auto Parts & Repair" and "AutoZonePro" mobile applications for Android and iOS operating systems, as well as the supporting backend systems, servers, and software (Compl. ¶7).
Functionality and Market Context
- The Accused System provides a client-server platform where a user's mobile device (the "terminal machine") runs an application that communicates with AutoZone's servers (the "service provider machine") (Compl. ¶29). The complaint focuses on functionality such as a user saving a vehicle to their profile ("My Garage"). It alleges that information about the saved vehicle is sent from the server to the app in a format like JSON, which is then stored on the device to allow future access (Compl. ¶¶ 30, 34). This downloaded information is alleged to be the claimed "terminal dialogue module" that modifies the app's "code" (allegedly the app's bytecode) to produce an updated application state and a modified user dialogue (Compl. ¶¶ 34, 52). Plaintiff alleges that Defendant derives a "significant portion of its revenue" from 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 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 sequence | The AutoZone app (terminal application) prompts a user to interact with saved vehicles. The app is alleged to comprise the Android Runtime (ART) as "computer-executable instructions" and the app's bytecode as "code". | ¶30 | col. 7:40-45 |
| accepting a first data entry at the terminal machine, wherein the first data entry is associated with the first prompt | The user makes a selection related to a saved vehicle, such as adding or editing one. | ¶31 | col. 11:36-40 |
| communicating information associated with the first data entry from the terminal machine to the service provider machine... | The app communicates the user's input regarding the saved vehicle to AutoZone's server. | ¶32 | col. 12:49-54 |
| 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 app receives information from the server (e.g., in JSON format) related to the saved vehicle. This is alleged to be a "terminal dialogue module" that updates the app's bytecode ("first code") to create an updated state ("first updated code"). | ¶34 | col. 8:44-52 |
| 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 app can now display new prompts, such as showing the newly saved vehicle in a list or offering options to order parts for it. | ¶34 | col. 17:1-3 |
| 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 "intermediate code". | ¶34 | col. 2:59-63 |
’571 Patent 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... and a provider dialogue module... | The complaint alleges that either the user's device or the Defendant's server acts as the "update server machine", sending dialogue modules (e.g., saved vehicle data) between the client and server. | ¶49 | col. 4:55-67 |
| a terminal machine configured to run a terminal application... comprising a first set of computer-executable instructions and a first set of code... | The user's smartphone running the AutoZone app, which allegedly comprises the Android Runtime (ART) as the "computer-executable instructions" and the app's bytecode as the "code". | ¶50, ¶51 | col. 7:40-45 |
| 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 Defendant's server running a .Net application, which allegedly comprises the Common Language Runtime (CLR) as the "computer-executable instructions" and the .Net program as the "code". | ¶51, ¶52 | col. 7:27-39 |
| wherein the terminal dialogue module modifies the first set of code... and wherein the provider dialogue module modifies the second set of code... | Information sent from the server (e.g., saved vehicle data) allegedly modifies the app's bytecode, and information sent from the app modifies the state on the server. | ¶52, ¶23 of '774 allegations | col. 8:44-52 |
| wherein the terminal dialogue module does not modify the first set of computer-executable instructions... | The complaint alleges the dialogue modules do not modify the ART on the user's device or the CLR on the server. | ¶24 of '774 allegations | col. 8:53-56 |
Identified Points of Contention
- Scope Questions: A central dispute will concern whether a standard client-server data exchange (e.g., an app fetching JSON data via an API call) falls within the patent's specific definitions. Does fetching data to update an application's content equate to receiving a "dialogue module" that "modifies... code" as claimed, or is it merely the normal operation of a data-driven application? The complaint's theory hinges on this broad interpretation.
- Technical Questions: The complaint's infringement theory maps the patent's architectural components onto modern software stacks: "computer-executable instructions" are equated with runtimes like ART and CLR, while "code" is equated with application-level bytecode and data (Compl. ¶¶ 30, 51). The viability of this mapping will be a key technical question. It raises the further question of whether receiving data that alters an application's in-memory state constitutes a "modification" of its "code" in the manner contemplated by the patent.
V. Key Claim Terms for Construction
The complaint references prior claim construction, signaling that the definitions of the following terms are central to the dispute.
The Term: "code"
Context and Importance: The distinction between non-modifiable "computer-executable instructions" and modifiable "code" is the foundation of the patented invention. Infringement hinges on whether the accused data (e.g., JSON payloads) and application bytecode satisfy the definition of "code".
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification identifies "Java Byte Code" as an example of "intermediary code," which may support Plaintiff's analogy to the accused apps' bytecode (’571 Patent, col. 1:55-59).
- Evidence for a Narrower Interpretation: The complaint cites a prior construction defining "code" as “information that must be translated before it can be executed on a processor” (Compl. ¶16, fn. 5). A defendant may argue that data like JSON is merely interpreted as values, not "translated" and "executed" in the manner of bytecode or instructions, creating a potential mismatch.
The Term: "dialogue module"
Context and Importance: This term defines the mechanism for delivering the "code". The complaint equates data packets containing "a terminal machine portion of a saved vehicle" with a "terminal dialogue module" (Compl. ¶¶ 34, 49). The validity of this comparison is critical.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The complaint notes a prior judicial finding that a "dialogue module" can "contain code or other data" (Compl. ¶20, emphasis added), which may support the inclusion of data-only packets.
- Evidence for a Narrower Interpretation: The same finding states that "module" is used to "refer to a particular type of structure rather than to any structure for performing a function" (Compl. ¶20). A defendant could argue that a standard JSON object is a generic data structure, not the "particular type of structure" claimed.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement by claiming Defendant markets its mobile apps and provides instructions that encourage users to download and operate them in a manner that allegedly practices the patented methods (Compl. ¶¶ 40, 58, 76). Contributory infringement is alleged on the basis that the Accused Instrumentalities are not staple articles of commerce and are especially made to infringe (Compl. ¶¶ 41, 59, 77).
- Willful Infringement: Willfulness is alleged based on Defendant having actual knowledge of the patents "at least since the filing of this complaint" (Compl. ¶¶ 27, 46, 64).
VII. Analyst’s Conclusion: Key Questions for the Case
A central issue will be one of definitional scope and claim construction: Can the patent term "code"—defined in prior litigation as "information that must be translated before it can be executed"—be construed to encompass both an application's bytecode and the dynamic data (e.g., JSON) it receives from a server? The outcome of the infringement analysis depends heavily on whether this specific, two-part software architecture described in the patent can be mapped onto the components of a modern, standard client-server application.
A key evidentiary question will be one of technical mechanism: Does the accused system's function of fetching data from a server to update application content constitute "modifying" the "code" as required by the claims? The case may turn on whether the court views this as a fundamental alteration of the application's logic, as the patent appears to describe, or as the routine operation of a data-driven program whose underlying code remains unchanged.