S3G Technology LLC v. Carter's Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: S3G Technology LLC (California)
  • Defendant: Carter's Inc (Delaware)
  • Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
• Case Identification: 6:23-cv-00507, W.D. Tex., 07/18/2023
• Venue Allegations: Plaintiff alleges venue is proper as Defendant is subject to personal jurisdiction in the district, maintains a regular and established place of business in Waco, Texas, and has committed the alleged acts of infringement within the district.
• Core Dispute: Plaintiff alleges that Defendant’s mobile applications for iOS and Android, along with their supporting server infrastructure, infringe three patents related to methods for efficiently modifying software applications on remote devices.
• Technical Context: The patents address the challenge of updating software on networked devices by proposing a system that sends small "dialogue modules" to alter application behavior, rather than transmitting entire, large executable files.
• Key Procedural History: The complaint notes that the asserted patents have been subject to prior litigation (S3G Technology LLC v. UniKey Tech Inc), and it incorporates claim construction rulings from that case for key terms such as “code,” “computer-executable instructions,” and “dialogue module.” The complaint also references the prosecution history of a related patent, quoting an Examiner's reasoning for allowance to support the novelty of the claimed software architecture.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

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 patent describes the technical challenge of updating software applications distributed across many remote devices, particularly over wireless networks with limited bandwidth. Transmitting an entire new, recompiled application for each update is described as inefficient, time-consuming, and potentially infeasible (Compl. ¶¶12-14; ’571 Patent, col. 2:35-52).
• The Patented Solution: The invention proposes a three-part system architecture 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" (Compl. ¶15; ’571 Patent, FIG. 1). Instead of sending a full application, the update server sends a small "dialogue module" containing "code." This "code" is defined as information that must be translated by the application before it can be executed, distinguishing it from "computer-executable instructions" which run directly on the processor and are not modified by the update. This modular update modifies the application's behavior—such as its sequence of prompts—without replacing the entire program (Compl. ¶16; ’571 Patent, col. 4:21-25).
• Technical Importance: This approach aimed to conserve network bandwidth and enable more efficient, dynamic modification of applications in an era of expanding mobile and distributed computing (Compl. ¶23; ’571 Patent, col. 6:47-49).

Key Claims at a Glance

• The complaint asserts at least dependent claim 2, which incorporates independent claim 1 (Compl. ¶28).
• The essential elements of the system claimed in independent claim 1 include:
  • An update server machine comprising a processor.
  • The update server is operable for sending a terminal dialogue module to a terminal machine.
  • The update server is also operable for sending a provider dialogue module to a service provider machine.
  • This allows the terminal and service provider machines to conduct a dialogue sequence with each other.
• The complaint explicitly notes its infringement analysis also applies to other aspects of the accused system beyond the primary example (Compl. ¶30, n.7).

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 ’124 Patent, part of the same family as the ’571 Patent, addresses the same technical problems of inefficient software updates on remote devices over bandwidth-constrained networks (Compl. ¶¶12-14).
• The Patented Solution: The patent claims a method for conducting a dialogue between a terminal machine and a service provider machine that mirrors the architecture of the ’571 Patent. The method involves displaying prompts, receiving data, and modifying the application's behavior by receiving a "terminal dialogue module" that updates a portion of the application's "first code" to produce "first updated code," thereby adapting the application to conduct a modified dialogue sequence (’124 Patent, Abstract; col. 2:53-55).
• Technical Importance: The claimed method provides a specific process for implementing the bandwidth-efficient, modular software update system described in the patent family (Compl. ¶23).

Key Claims at a Glance

• The complaint asserts at least independent claim 1 (Compl. ¶46).
• The essential elements of the method in independent claim 1 include:
  • Displaying a first prompt on a terminal machine by running 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.
  • 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 first code, second code (on the provider machine), and first updated code comprise intermediate code.
• The complaint does not explicitly reserve the right to assert dependent claims for this patent.

U.S. Patent No. 10,387,140 - "Modification of Terminal and Service Provider Machines Using an Update Server Machine"

• Issued: August 20, 2019

Technology Synopsis

As a member of the same patent family, the ’140 Patent claims a method for conducting a dialogue between a terminal machine and a service provider. The technology solves the problem of inefficiently updating remote software by using small modules of "code" to modify application behavior without replacing the entire executable file (Compl. ¶¶12-14, 22).

Asserted Claims

At least independent claim 1 (Compl. ¶65).

Accused Features

The complaint alleges that Defendant's system performs the claimed method when a user interacts with features such as the "favorite item (list)" in the Carter's mobile app, which involves displaying prompts, receiving data, communicating with a server, and receiving data (alleged to be "third code") that modifies the application's dialogue (Compl. ¶¶67-71).

III. The Accused Instrumentality

Product Identification

• Defendant's Carter's mobile applications for Android and iOS, and the associated systems, servers, and software that facilitate the use of the apps (collectively, the "Accused System") (Compl. ¶7).

Functionality and Market Context

• The accused functionality centers on features within the Carter's mobile app, such as the "favorite item (list)" (Compl. ¶30). The complaint alleges that when a user interacts with this feature—for example, by adding, editing, or viewing a favorite item—the app (the "terminal machine") communicates with Defendant's servers (the "service provider machine") (Compl. ¶¶31, 33).
• This interaction allegedly involves the app displaying prompts and the server sending back information in JSON format, which the complaint contends is a "terminal dialogue module" that modifies the app's "code" (the app's bytecode) to produce an updated dialogue sequence (e.g., displaying the updated list of favorite items) (Compl. ¶¶14, 33, 52). The user's device or the Defendant's server can function as the "update server machine" that sends these modules (Compl. ¶30). The complaint includes a diagram from the patent illustrating the three-entity system structure it alleges is mirrored by the Accused System (Compl. p. 8, FIG. 1). A second diagram shows the alleged software structure of computer-executable instructions and translatable code (Compl. p. 8, FIG. 2).

IV. Analysis of Infringement Allegations

8,572,571 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: A central question may be whether sending data, such as a JSON file representing a user's list of favorite items, constitutes "sending a terminal dialogue module" that "modifies the first set of code." The defense may argue this is merely a data update that populates a user interface, not a modification of the application's underlying code or dialogue structure as contemplated by the patent.
• Technical Questions: The complaint's theory hinges on mapping the Android/iOS software stack to the patent's specific architectural division. A key technical question will be whether the app's "bytecode" functions as "code" (information that must be translated) and the Android Runtime (ART) functions as "computer-executable instructions" (which execute directly) in the manner required by the claims.

9,940,124 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: As with the '571 Patent, a primary issue will be whether receiving and processing a JSON data file constitutes "receiving...a terminal dialogue module that updates...first code to produce first updated code." The analysis may focus on whether this action changes the application's functional logic or merely its displayed data.
• Technical Questions: The complaint alleges that bytecode is "intermediate code" as required by the claim (Compl. ¶52). The court may need to determine if this characterization is technically accurate and consistent with the patent's use of the term, which refers to code that is "interpreted by a platform module portion of the terminal application" (’571 Patent, col. 9:55-58).

V. Key Claim Terms for Construction

The Term: "code"

Context and Importance

This term is the technological core of the asserted patents. Its definition distinguishes the part of the software that is modified (the "code") from the part that is not (the "computer-executable instructions"). The complaint's infringement theory depends on mapping the accused apps' bytecode to this term.

Intrinsic Evidence for Interpretation

• Evidence for a Broader 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, n.5). The specification states the 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), which could be read broadly to cover various forms of interpreted data or scripts.
• Evidence for a Narrower Interpretation: The specification provides Java Byte Code as an example of "intermediate code" (’571 Patent, col. 7:13-15). A defendant may argue that the term should be limited to such compiled intermediate languages that represent program logic, and not extend to simple data-interchange formats like JSON, which primarily represent structured data rather than executable logic.

The Term: "computer-executable instructions"

Context and Importance

This term is the counterpart to "code" and defines the stable, unmodified portion of the patented application architecture. The complaint maps this to the Android Runtime (ART) and the .NET Common Language Runtime (CLR) (Compl. ¶¶31, 32). The viability of this mapping is crucial to the infringement case.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The patent describes these instructions as able to be "read and executed by a computer processor without additional translation or adaptation" (’571 Patent, col. 3:45-48). This could be interpreted to encompass any native machine code or runtime environment that directly executes instructions on the CPU.
• Evidence for a Narrower Interpretation: The patent distinguishes these instructions from the "platform module" which interprets the "code" (’571 Patent, col. 7:5-10). A defendant could argue that in a modern virtual machine environment like ART, the runtime itself is a complex software layer and not simply "computer-executable instructions" in the direct sense contemplated by the patent, blurring the sharp line the patent attempts to draw.

The Term: "dialogue module"

Context and Importance

This is the vehicle for the inventive update process. The complaint's theory identifies the JSON data for a "favorite item (list)" as the "dialogue module" (Compl. ¶30). The case may turn on whether a data object can be considered a structural "module" that modifies an application's dialogue sequence.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The specification states a dialogue module "can contain code or other data and can be communicated" (Compl. ¶20, citing Ex. D). This language suggests a module is not limited to pure code and can include data, potentially supporting the plaintiff's theory.
• Evidence for a Narrower Interpretation: The complaint also cites a court holding that the term refers to "a particular type of structure rather than to any structure for performing a function" (Compl. ¶20). A defendant may argue that a JSON object is fundamentally data for performing a function (displaying a list) rather than a structural module that alters the application's dialogue logic itself.

VI. Other Allegations

Indirect Infringement

• The complaint alleges inducement by Defendant instructing customers to download and install the Carter's app, allegedly knowing its use would infringe (Compl. ¶¶37, 39, 58). It also alleges contributory infringement, asserting that the Accused System is not a staple article of commerce and is especially adapted to infringe the patents (Compl. ¶¶40, 59).

Willful Infringement

• The complaint does not plead facts supporting pre-suit knowledge of the patents. It alleges knowledge "at least since the filing of this complaint" for each patent (Compl. ¶¶27, 45, 64). This allegation may support a claim for willful infringement based on conduct occurring after the lawsuit was filed. The prayer for relief explicitly requests a finding that infringement is willful (Compl. p. 35, ¶C).

VII. Analyst’s Conclusion: Key Questions for the Case

• A core issue will be one of definitional scope: can the patent's specific two-part software architecture—a stable set of "computer-executable instructions" and a modifiable set of "code" requiring translation—be mapped onto the modern, multi-layered software stack of the accused Android and iOS applications? The dispute may focus on whether concepts like "bytecode" and "runtime environment" fit the patent's narrower definitions.
• A key evidentiary question will be one of functional operation: does updating a data file (e.g., a JSON list of favorite items) that changes the content displayed by an application constitute "modifying...code to produce...updated code" that "adapts the terminal application to use a second sequence of prompts," as required by the claims? Or is this a fundamental mismatch, where the accused system performs a routine data update while the patent claims a more structural modification of the application's logical flow?