DCT
6:24-cv-00229
S3G Technology LLC v. Massage Envy Franchising LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: S3G Technology LLC (California)
- Defendant: Massage Envy Franchising LLC (Delaware)
- Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
- Case Identification: 6:24-cv-00229, W.D. Tex., 05/02/2024
- 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 its mobile application to customers there, and derives significant revenue from its use.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications and associated backend systems for booking appointments infringe patents related to methods for efficiently modifying software applications on remote devices.
- Technical Context: The technology addresses the challenge of updating distributed software systems by sending small, modular updates ("dialogue modules") that alter application behavior without requiring the transmission of an entire new version of the application.
- Key Procedural History: The complaint notes numerous other lawsuits filed by Plaintiff asserting at least one of the same patents, indicating a broad assertion campaign. The complaint also relies heavily on claim constructions from a prior litigation, S3G Tech. LLC v. Unikey Techs., Inc., for key terms including "code," "computer-executable instructions," and "dialogue module," suggesting these definitions will be central to the dispute.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-23 | Priority Date for '140, '124, and '758 Patents |
| 2013-07-11 | Notice of Allowability cited from related prosecution history |
| 2016-04-05 | '758 Patent Issued |
| 2018-04-10 | '124 Patent Issued |
| 2019-08-20 | '140 Patent Issued |
| 2024-05-02 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
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, "Modification of Terminal and Service Provider Machines Using an Update Server Machine," issued August 20, 2019 (Compl. ¶9).
The Invention Explained
- Problem Addressed: The patent's background describes the difficulty and inefficiency of distributing newly compiled software updates to a large number of remote devices, particularly over wireless networks with limited bandwidth and transmission capabilities ('140 Patent, col. 2:35-67). Transmitting an entire application for a minor change is time-consuming and costly (Compl. ¶13-14).
- The Patented Solution: The invention proposes a three-entity system architecture comprising a terminal machine (e.g., a smartphone), a service provider machine (e.g., a backend server), and an update server machine ('140 Patent, FIG. 1). Instead of sending a full application replacement, the update server sends a small "dialogue module" containing "code"—defined as information that must be translated before execution—to the terminal or service provider machine (Compl. ¶15-16). This module modifies the application's behavior, such as changing user prompts or data entry sequences, without altering the core "computer-executable instructions," which can be directly executed by a processor ('140 Patent, col. 4:28-40). The complaint includes a visual from the patent, FIG. 1, illustrating this three-entity communication structure (Compl. p. 8).
- Technical Importance: This modular approach to software updates aims to reduce network bandwidth utilization and improve the efficiency of modifying applications distributed across a network of remote devices (Compl. ¶24).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 ('140 Patent, col. 41:26-42:12; Compl. ¶31).
- The essential elements of independent claim 1 include:
- Displaying a first prompt via a terminal application comprising first computer-executable instructions and first code.
- Receiving entry of first data at the prompt.
- Communicating information associated with the first data 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, third code that modifies at least a portion of the first code to produce first updated code.
- This reception of third code is performed in response to the terminal machine satisfying a trigger condition.
- The complaint states infringement of "one or more claims" and reserves the right to assert additional claims (Compl. ¶31).
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 (Compl. ¶10).
The Invention Explained
- Problem Addressed: As a member of the same patent family as the '140 Patent, the '124 Patent addresses the same technical problem of inefficiently distributing large software updates to remote, networked devices (Compl. ¶12-14).
- The Patented Solution: The '124 Patent discloses the same three-entity system where small "dialogue modules" are used to modify application behavior without replacing the entire software package, thereby conserving network bandwidth and improving update efficiency (Compl. ¶15-24).
- Technical Importance: The solution provides a method for making targeted, efficient updates to distributed software, which was technically important for managing applications on devices with constrained network connectivity (Compl. ¶22, ¶24).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶55).
- Based on the complaint's allegations, the essential elements of independent claim 1 include:
- Displaying a first prompt via a terminal application comprising first computer-executable instructions and first code.
- Accepting a first data entry associated with the prompt.
- Communicating information to a service provider machine using a provider application with 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 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 alleges infringement of "one or more claims" (Compl. ¶55).
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 (Compl. ¶11).
- Technology Synopsis: The '758 Patent, also in the same family, is directed to solving the problem of inefficiently distributing large, monolithic software updates over networks. The patented solution involves a system where small, targeted "dialogue modules" containing translatable "code" are sent to modify specific aspects of an application's user-facing dialogue, thereby avoiding the need for a full application reinstall and conserving bandwidth (Compl. ¶12-15).
- Asserted Claims: At least independent claim 1 (Compl. ¶74).
- Accused Features: The accused features include the Massage Envy app's system for displaying prompts, accepting user input related to lists (e.g., massage/therapist results), and communicating with a server that sends back data (allegedly a "dialogue module") that updates the app's dialogue flow. The complaint specifically alleges that the app's bytecode constitutes "Java Byte code," satisfying a limitation of the asserted claim (Compl. ¶76-79).
III. The Accused Instrumentality
Product Identification
- The accused instrumentalities are Defendant's "Massage Envy mobile applications for devices running the Android operating system and... for iOS," as well as the associated backend "systems, methods, computing devices, including servers, software, and non-transitory computer readable storage medium" that support the apps (collectively, the "Accused System") (Compl. ¶7).
Functionality and Market Context
- The Accused System provides functionality for users to book appointments and manage user-specific data, such as a "favorite list (massage / therapist)" (Compl. ¶33). The mobile application, which runs on a user's device (the "terminal machine"), communicates with Defendant's servers (the "service provider machine") to store and retrieve this information, making it available to the user across sessions (Compl. ¶33, ¶35).
- The complaint alleges that Defendant distributes this system to customers within the judicial district and derives a significant portion of its revenue from its use (Compl. ¶4).
IV. Analysis of Infringement Allegations
'140 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 comprising first computer-executable instructions and first code... | The Massage Envy app displays prompts for booking appointments or managing favorites. The complaint alleges the Android Runtime comprises the "first computer-executable instructions" and the app's bytecode is the "first code." | ¶33 | col. 7:56-61 |
| receiving entry of first data at the first prompt | The user edits or deletes an item from their favorite list within the app. | ¶34 | col. 11:2-3 |
| communicating information ... to a provider application ... comprising second computer-executable instructions and second code... | The app sends the user's edits to the Massage Envy server, which runs a .NET server application. The CLR engine is alleged to be the "second computer-executable instructions" and the .NET program is the "second code." | ¶35 | col. 8:1-20 |
| storing at least a portion of the information associated with the first data in memory for analysis | The server stores information about user orders (e.g., booked appointments) for analysis to provide rewards and credit. | ¶36 | col. 41:47-49 |
| 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 in JSON format from the server, which updates the on-screen favorite list. The complaint characterizes JSON as "third code" that modifies the app's bytecode ("first code"). | ¶37 | col. 8:63-9:10 |
| ...wherein receiving the third code is performed in response to the terminal machine satisfying a trigger condition | The app receives the update in response to a user action, such as accessing the app or connecting to the network. | ¶38 | col. 41:58-60 |
'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 comprising first computer-executable instructions and first code... | The app displays prompts for creating or reviewing a shopping list item (e.g., massage/therapist). The Android Runtime is alleged to be the "first computer-executable instructions" and the app's bytecode is the "first code." | ¶57 | col. 7:56-61 |
| accepting a first data entry at the terminal machine... | The system accepts user input to create, review, or edit a shopping list item. | ¶58 | col. 11:2-3 |
| communicating information ... to the service provider machine ... [using] a provider application ... comprising second computer-executable instructions and second code... | User edits to the shopping list are sent to the Defendant's server, which runs a .NET application. The complaint alleges the .NET execution environment (CLR) is the "second computer-executable instructions" and the .NET program is the "second code." | ¶59 | col. 8:1-20 |
| storing at least a portion of the information associated with the first data entry in memory for analysis | The server stores order history and shopping list data for analysis to provide rewards and make coupons available. | ¶60 | col. 11:35-40 |
| 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... | The app receives a "terminal dialogue module" (e.g., JSON data) from the server that updates the shopping list. This update is alleged to produce "first updated code" (modified bytecode) that adapts the app to display a new prompt, such as the ability to access a new shopping list item. | ¶61 | col. 8:63-9:10 |
Identified Points of Contention
- Scope Questions: The infringement theory hinges on whether standard components of modern mobile app architecture can be mapped onto the patent's specific terminology. A central question is whether an app's "bytecode" and the underlying "Android Runtime" constitute two distinct components corresponding to the patent's "code" and "computer-executable instructions." A related question is whether receiving a standard data-interchange file, such as a JSON object, to update on-screen content constitutes receiving a "dialogue module" that "modifies" the application's bytecode, as claimed.
- Technical Questions: What evidence does the complaint provide that the server-side .NET application is architected with the claimed distinction between the CLR engine (as "computer-executable instructions") and the .NET program itself (as "code")? The analysis will require a detailed examination of how these accused software components actually function and interact, versus how they are characterized in the complaint.
V. Key Claim Terms for Construction
The Term: "code"
Context and Importance: This term is foundational to the Plaintiff's infringement allegations, as it allows the classification of both the application's bytecode and server-sent JSON data as a claim element. The complaint asserts the term has been construed in prior litigation to mean "information that must be translated before it can be executed on a processor" (Compl. ¶16, n.6). Practitioners may focus on whether this construction, applied to the facts here, sweeps in technologies far removed from the patent's original context.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states, "[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" ('124 Patent, col. 4:30-40, as cited in Compl. ¶16). This language could support an interpretation where any data format requiring parsing or translation by an application, like JSON, qualifies as "code."
- Evidence for a Narrower Interpretation: The context of the patent, including the description of a design tool for creating dialogue flows (e.g., '140 Patent, FIGS. 8A-8B), suggests "code" refers to structured instructions for defining a dialogue sequence, not merely data used within that sequence. A defendant may argue that JSON is simply data, and its "translation" is just parsing, a routine function distinct from the specific translation of intermediate program code contemplated by the patent.
The Term: "dialogue module"
Context and Importance: This term's definition determines whether a JSON file received from a server can be considered the claimed updating mechanism. The Plaintiff's theory requires classifying such data transmissions as the claimed "dialogue module." The complaint notes a prior construction holding that the term refers to "a particular type of structure" that can "contain code or other data" (Compl. ¶20).
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The language that a module "can contain code or other data" may support the view that a data structure like a JSON object, which contains information, fits the definition (Compl. ¶20).
- Evidence for a Narrower Interpretation: The specification describes the purpose of the dialogue module as adapting an application to use a "second sequence of prompts" or a "modified dialogue sequence" ('140 Patent, col. 4:24-30). This suggests a structural component that alters the application's control flow, a function potentially distinct from a data file that merely populates a list within an existing, unmodified dialogue structure.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement, stating that Defendant instructs its customers to download and use the infringing app, knowing that its use in connection with Defendant's servers constitutes infringement (Compl. ¶46, ¶48, ¶65, ¶67). It also alleges contributory infringement on the basis that the Accused System is not a staple article of commerce and is especially adapted to infringe the patents (Compl. ¶49, ¶68).
- Willful Infringement: Willfulness allegations are based on Defendant's alleged knowledge of the patents "at least since the filing of this complaint," which would primarily support a claim for post-suit willful infringement (Compl. ¶30, ¶54, ¶73).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "code", defined in the context of updatable software modules as information requiring "translation," be construed to cover standard data-interchange formats like JSON, and can receiving such data be considered a "modification" of the application's own code?
- A key evidentiary question will be one of architectural mapping: does the technical relationship between a mobile operating system's runtime environment (e.g., Android Runtime) and an application's bytecode present the distinct, two-part structure of "computer-executable instructions" and "code" required by the claims, or is this an artificial characterization of a fundamentally integrated execution process?
- The case may also turn on a question of structural equivalence: does a JSON object containing list data constitute the "particular type of structure" contemplated by the term "dialogue module," or does the patent require a module that more directly alters the control flow and dialogue logic of the application itself?