DCT
6:23-cv-00721
S3G Technology LLC v. Vitamin Shoppe Inc
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: Vitamin Shoppe, Inc. (New Jersey)
- Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
- Case Identification: 6:23-cv-00721, W.D. Tex., 10/18/2023
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Defendant maintains a regular and established place of business in the district, distributes the accused mobile application to customers there, and derives significant revenue from its activities within the district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile application and associated server infrastructure infringe three patents related to methods for efficiently modifying software applications on remote devices.
- Technical Context: The technology concerns updating distributed software, such as mobile apps, by sending small "dialogue modules" to alter application behavior, rather than transmitting a complete new version of the application, thereby saving network bandwidth and improving efficiency.
- Key Procedural History: The complaint references an extensive history of prior litigation involving the same patent family, including a case against Unikey Technologies, Inc. where key terms such as "code," "computer-executable instructions," and "dialogue module" were construed by the court. The complaint also cites a Notice of Allowability from the prosecution of a related patent, arguing that the claimed technology was deemed non-obvious over the prior art.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Earliest Priority Date for ’124, ’140, and ’758 Patents |
| 2016-04-05 | ’758 Patent Issue Date |
| 2018-04-10 | ’124 Patent Issue Date |
| 2019-08-20 | ’140 Patent Issue Date |
| 2023-08-31 | Accused Android App Last Updated |
| 2023-09-17 | Accused iOS App Last Updated |
| 2023-10-18 | 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”
- Patent Identification: U.S. Patent No. 9,940,124, entitled “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” issued April 10, 2018 (Compl. ¶9).
The Invention Explained
- Problem Addressed: The patents describe the technical challenge of updating software applications distributed across a large number of remote devices. Transmitting a complete, newly compiled application to each device is inefficient, consuming significant time and network bandwidth, particularly over wireless networks (Compl. ¶¶ 12-14; ’140 Patent, col. 2:17-3:2).
- The Patented Solution: The invention proposes a three-entity system comprising a terminal machine (e.g., a user's device), a service provider machine (e.g., a back-end server), and an update server machine. Instead of sending a full application update, the update server transmits small "dialogue modules" containing "code" to the terminal and provider machines. This "code" is defined as information that must be translated by the application before execution, distinguishing it from directly executable instructions. These modules modify the application's dialogue flow without replacing the entire executable file, enabling more efficient updates (Compl. ¶¶ 15-19; ’140 Patent, FIG. 1; ’140 Patent, col. 4:57-64).
- Technical Importance: This architectural approach is presented as a solution that reduces network bandwidth utilization, allowing for the efficient modification of applications running on remote devices (Compl. ¶23; ’140 Patent, col. 7:31-33).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶28).
- Essential elements of independent claim 1 include:
- A method of conducting a dialogue between a terminal machine and a service provider machine.
- Displaying a first prompt via a terminal application comprising first computer-executable instructions and first code.
- Accepting a first data entry and communicating information to a provider application comprising second computer-executable instructions and second code.
- 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, which in turn adapts the terminal application to display a second prompt.
- The first code, second code, and/or first updated code must comprise intermediate code.
U.S. Patent No. 10,387,140 - “Modification of Terminal and Service Provider Machines Using an Update Server Machine”
- Patent Identification: U.S. Patent No. 10,387,140, entitled “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” issued August 20, 2019 (Compl. ¶10).
The Invention Explained
- Problem Addressed: The technology addresses the same technical problem of inefficiently updating software on distributed remote devices, as described for the ’124 Patent (Compl. ¶¶ 12-14; ’140 Patent, col. 2:17-3:2).
- The Patented Solution: The patented solution is the same three-entity architecture that uses "dialogue modules" containing translatable "code" to modify application behavior without a full reinstall, as detailed for the ’124 Patent (Compl. ¶¶ 15-19; ’140 Patent, FIG. 1; ’140 Patent, col. 4:57-64).
- Technical Importance: The invention is framed as a way to reduce network bandwidth consumption and enable more efficient remote software modification (Compl. ¶23; ’140 Patent, col. 7:31-33).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (’140 Patent, col. 42:27-55; Compl. ¶47).
- Essential elements of independent claim 1 include:
- A method of conducting a dialogue sequence between a terminal machine and a service provider machine.
- Providing a first prompt via a terminal application comprising first computer-executable instructions and first code.
- Receiving entry of first data and communicating it to a provider application comprising second computer-executable instructions and second code.
- Receiving, at the terminal machine, third code that modifies at least a portion of the first code to produce first updated code, adapting the terminal application to conduct a modified dialogue sequence.
- Claim 1 further requires that receiving the third code is performed in response to a trigger condition; the third code is received from a separate update server; the terminal and provider machines use different processor types making their executable instructions non-interchangeable; and the instructions are fully compiled.
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, entitled “Modification of Terminal and Service Provider Machines Using an Update Server Machine,” issued April 5, 2016 (Compl. ¶11).
Technology Synopsis
This patent addresses the inefficiency of updating software applications on distributed remote devices. It discloses a system where smaller "dialogue modules" containing "code"—data that must be translated before execution—are sent to modify an application's dialogue flow, avoiding the need to transmit an entire new executable file and thus saving bandwidth (Compl. ¶¶ 12-15, 22).
Asserted Claims
At least independent claim 1 (Compl. ¶71).
Accused Features
The complaint alleges that the Defendant's mobile app ("terminal application") and server ("provider application") infringe by conducting a dialogue where the app is updated by receiving a "terminal dialogue module" (e.g., saved address information in JSON format) that modifies the app's "first code" (the app's bytecode) to display a new prompt or dialogue sequence (Compl. ¶¶ 73-76).
III. The Accused Instrumentality
Product Identification
The accused products are Defendant's mobile applications for Android and iOS devices ("Defendant app") and the supporting server systems and software, collectively identified as the "Accused Instrumentalities" (Compl. ¶7).
Functionality and Market Context
The Accused Instrumentalities provide a system for users to interact with Defendant's services, including creating, reviewing, and editing saved address information (Compl. ¶30). This functionality requires communication between the user's mobile device (the "terminal machine") and Defendant's servers (the "service provider machine") (Compl. ¶32). The complaint alleges the terminal application consists of directly executable instructions (e.g., the Android Runtime) and translatable "code" (e.g., the application's bytecode), while the server application consists of a .NET program ("code") running on the CLR engine (executable instructions) (Compl. ¶¶ 30, 32). Information, such as saved addresses, is allegedly sent from the server to the app in JSON format to be displayed to the user (Compl. ¶¶ 34, 53). The complaint asserts that Defendant derives significant revenue from services provided via these instrumentalities, which allow customers to purchase products remotely (Compl. ¶¶ 7, 37). The complaint explains the patented three-entity system architecture with a diagram from the patents. This diagram illustrates communication among an update server machine, a service provider machine, and a terminal machine (Compl. ¶15, referencing FIG. 1).
IV. Analysis of Infringement Allegations
9,940,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, the terminal application comprising first computer-executable instructions and first code... | The Defendant's app displays prompts for users to manage saved addresses. The app allegedly comprises the Android Runtime (first computer-executable instructions) and the app's bytecode (first code). | ¶30 | col. 22:31-36 |
| communicating information... to the service provider machine, wherein the service provider machine uses a provider application comprising second computer-executable instructions and second code... | User-edited information is sent to Defendant's server, which runs a .NET application (second code) on a CLR engine (second computer-executable instructions). | ¶32 | col. 22:40-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... | The app receives a saved address from the server in JSON format. This JSON data is alleged to be the "terminal dialogue module" that updates the app's bytecode (first code). | ¶34 | col. 22:50-53 |
| ...wherein at least one of the first code, the second code, and the first updated code comprise intermediate code. | The app's bytecode is identified as the first code and first updated code, which is alleged to be intermediate code. | ¶34 | col. 22:58-61 |
Identified Points of Contention
- Scope Questions: A central point of contention may be whether a data packet, such as a JSON object containing a saved address, constitutes a "terminal dialogue module" that "updates... code" as contemplated by the patent. The defense may argue that rendering data sent from a server is a standard client-server function, distinct from the claimed method of modifying an application's underlying dialogue structure to avoid a full software update.
- Technical Questions: The complaint alleges that receiving JSON data updates the app's bytecode. A key technical question will be what evidence supports this assertion. The analysis will likely focus on whether displaying server-provided data constitutes "updating code" or is merely data rendering performed by the pre-existing, unchanged application code.
10,387,140 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| providing a first prompt by a terminal machine by running a terminal application, the terminal application comprising first computer-executable instructions and first code... | The Defendant's app displays prompts and allegedly comprises the Android Runtime (first computer-executable instructions) and its bytecode (first code). | ¶49 | col. 42:30-36 |
| receiving, at the terminal machine, third code that modifies at least a portion of the first code to produce first updated code... | The app receives data (e.g., a saved address) from the server in JSON format. The complaint alleges this JSON data constitutes the "third code" that modifies the app's bytecode (first code). | ¶53 | col. 42:47-50 |
| receiving the third code from an update server machine that is separate and distinct from the terminal machine... and the service provider machine... | The "update server machine" is alleged to be the user's own device (e.g., smartphone) when accessing the system, which is asserted to be separate from the terminal machine (the app running on the device) and the service provider machine (Defendant's server). | ¶55 | col. 42:27-55 |
| the first computer-executable instructions are not able to be executed on the service provider machine and the second computer-executable instructions are not able to be executed on the terminal machine. | The terminal machine (e.g., a mobile phone with a Snapdragon processor) and the service provider machine (e.g., a server with an x86 processor) allegedly use different processor architectures (ARM vs. CISC), making their respective executable instructions incompatible. | ¶56 | col. 42:27-55 |
Identified Points of Contention
- Scope Questions: The infringement theory for the '140 Patent raises the question of whether a single physical device (a user's smartphone) can simultaneously embody two distinct, claimed entities: the "terminal machine" (the app running on the phone) and the "update server machine" (the phone itself accessing the system). This interpretation may be challenged as inconsistent with the patent's described three-entity architecture, which is illustrated as structurally distinct components (Compl. ¶16, referencing FIG. 2).
- Technical Questions: As with the ’124 Patent, a core technical question will be whether the process of an application receiving, translating, and displaying JSON data constitutes "modifying... code" in the manner claimed by the patent. The complaint's footnote suggests that the necessary translation of JSON into a format the Android app can use is key to this theory (Compl. ¶53, fn 8).
V. Key Claim Terms for Construction
The Term: "code"
Context and Importance: The distinction between directly executable "computer-executable instructions" and translatable "code" is fundamental to the patents' claimed inventive concept. The infringement theory depends on mapping application components like bytecode or .NET programs to this definition of "code." Practitioners may focus on this term because its construction will determine whether standard application data formats fall within the claim scope.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification provides a functional definition: "The code represents at least some information that must be translated by the software application before it can be implemented on the machine processor" (’140 Patent, col. 4:59-62). This could be interpreted broadly to cover any data that requires parsing or translation before use, such as JSON.
- Evidence for a Narrower Interpretation: The problem solved by the invention is the inefficiency of transmitting entire compiled applications (’140 Patent, col. 2:17-33). This context may suggest "code" refers to a more substantial set of instructions for modifying application logic, rather than simple data for display. The complaint notes a prior construction of this term as “information that must be translated before it can be executed on a processor” (Compl. ¶17, fn 5).
The Term: "dialogue module"
Context and Importance: The infringement allegations equate a JSON data object with a "dialogue module." The viability of the case hinges on whether this interpretation is sustainable. The dispute will likely center on whether a "dialogue module" is simply any data structure or if it must have specific structural or functional properties related to modifying an application's core logic.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patents do not provide a rigid structural definition for a "dialogue module," referring to it as containing "code or other data" (Compl. ¶20, citing prior litigation). This could support an argument that any data structure that influences the application's dialogue flow qualifies.
- Evidence for a Narrower Interpretation: The complaint references a prior court holding that the term refers to "a particular type of structure rather than to any structure for performing a function" (Compl. ¶20). This suggests a structural requirement beyond just being a container for data. The purpose of the module is to "modify and/or update software applications" (Compl. ¶22), which may imply a function more significant than merely providing data to be rendered by an existing, unmodified application.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement based on Defendant allegedly providing its app and instructions to customers, knowing that their use of the app as intended would constitute infringement (Compl. ¶¶ 40, 64, 82). Contributory infringement is alleged on the basis that the Accused Instrumentalities are not staple articles of commerce and are especially adapted for an infringing use (Compl. ¶¶ 41, 65, 83).
- Willful Infringement: Willfulness allegations are based on Defendant's knowledge of the patents "at least since the filing of this complaint," indicating a theory of post-filing willfulness rather than pre-suit knowledge (Compl. ¶¶ 27, 46, 70).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of technical and definitional scope: can standard client-server data exchange, where a mobile app receives and displays data (allegedly JSON) from a server, be construed as "receiving... a... module that... modifies... code" as claimed? This question merges claim construction with the technical reality of how the accused system functions and whether that function is equivalent to the patented method of avoiding full application updates.
- A key structural question, particularly for the ’140 Patent, will be one of entity distinction: can a single physical device, a user's smartphone, simultaneously embody both the "terminal machine" and the "update server machine," two entities that the patent figures and description appear to treat as distinct components of a three-part system?
- An underlying evidentiary question will be one of functional proof: what evidence will be presented to demonstrate that the accused application's bytecode is actually "modified" or "updated" by the receipt of JSON data, as opposed to the bytecode simply processing the JSON as input data according to its pre-existing, unmodified logic?