S3G Technology LLC v. Party City Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: S3G Technology LLC (California)
  • Defendant: Party City Corporation (Delaware)
  • Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
• Case Identification: 6:22-cv-01166, W.D. Tex., 11/14/2022
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district, distributes its mobile application to customers in the district, and operates its mobile ordering service for stores located within the district.
• Core Dispute: Plaintiff alleges that Defendant’s mobile application and supporting server infrastructure for mobile ordering infringe three patents related to methods for efficiently modifying software applications on remote devices.
• Technical Context: The technology addresses updating and customizing applications on networked devices, such as smartphones, by transmitting small modules of code rather than entire new application files, a method intended to conserve network bandwidth.
• Key Procedural History: The complaint references prior litigation involving the asserted patents (S3G Tech. LLC v. Unikey Techs., Inc.), in which a court construed key claim terms including "code" and "dialogue module." The complaint also cites the prosecution history of a related patent, noting an Examiner's reasoning for allowance, to assert that the claimed three-part system and dual code/executable-instruction structure were unconventional at the time of invention.

Case Timeline

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, issued April 10, 2018 (Compl. ¶9).

The Invention Explained

• Problem Addressed: The patents describe the technical challenge of updating software on a large number of geographically dispersed devices (Compl. ¶13). Distributing newly compiled, complete software applications is inefficient and time-consuming, particularly over wireless networks with limited bandwidth ('140 Patent, col. 2:17-3:2).
• The Patented Solution: The invention proposes a system architecture of a terminal machine, a service provider machine, and an update server machine (Compl. ¶15; ’140 Patent, FIG. 1). Instead of sending a full application, the update server sends a small "dialogue module" to the terminal. This module contains "code," which is defined as information that must be translated by the application before execution, as distinct from directly "computer-executable instructions" ('140 Patent, col. 4:57-64; Compl. ¶16). This module updates a portion of the application to modify its behavior, such as changing a sequence of user prompts, without replacing the entire program (Compl. ¶19, ¶22). Figure 1 in the complaint depicts the three-entity system structure (Compl. ¶15, p. 7).
• Technical Importance: This approach is presented as a way to reduce network bandwidth usage and improve the efficiency of modifying applications 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).
• The essential elements of claim 1 include:
  • A method of conducting a dialogue between a terminal machine and a service provider machine.
  • Displaying a first prompt by running a terminal application that comprises both "first computer-executable instructions" and "first code."
  • Accepting a first data entry at the terminal machine.
  • Communicating information from the terminal to the service provider.
  • Storing at least a portion of that information in memory.
  • 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.
  • At least one of the first code, second code (on the provider machine), and first updated code 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, issued August 20, 2019 (Compl. ¶10).

The Invention Explained

• Problem Addressed: The '140 Patent addresses the same technical problem of inefficiently updating remote software as described for the '124 Patent (Compl. ¶12-14).
• The Patented Solution: The patented solution is also a system for modifying applications using targeted code updates rather than full application replacements. The claims of the ’140 Patent add further specificity, requiring that the update code be received from an "update server machine that is separate and distinct" from both the user's terminal and the service provider's machine, and that this reception occurs in response to a "trigger condition" being met by the terminal machine ('140 Patent, cl. 1). Figure 2 of the complaint illustrates the specific structure of applications comprising both computer-executable instructions and translatable code (Compl. ¶16, p. 7).
• Technical Importance: The claimed solution aims to create a more efficient and automated system for delivering targeted software modifications to remote devices based on specific conditions (Compl. ¶23).

Key Claims at a Glance

• The complaint asserts at least independent claim 1 (Compl. ¶42).
• The essential elements of claim 1 include:
  • A method of conducting a dialogue sequence between a terminal machine and a service provider machine.
  • Displaying a first prompt and receiving a first data entry.
  • Communicating information to a provider application.
  • Receiving, at the terminal machine, "third code" that modifies the terminal application's "first code" to produce "first updated code."
  • Receiving the "third code" is performed in response to the terminal machine satisfying a "trigger condition."
  • The "third code" is received from an "update server machine that is separate and distinct" from the terminal and service provider machines.
  • The terminal and service provider machines include different types of processors such that their respective computer-executable instructions are not cross-compatible.
  • The computer-executable 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, issued April 5, 2016 (Compl. ¶11).
• Technology Synopsis: This patent, part of the same family, addresses the inefficiency of updating software on remote devices. It discloses a method where a client-side "terminal application," comprising both executable instructions and translatable "first code," is modified by receiving a "terminal dialogue module." This module replaces a portion of the "first code" to adapt the application for a new dialogue sequence, avoiding the need to transmit an entirely new, recompiled application (Compl. ¶12-14, ¶19, ¶22).
• Asserted Claims: At least independent claim 1 (Compl. ¶61).
• Accused Features: The accused features are the Defendant's mobile application and server system. The complaint alleges the system sends data (e.g., JSON) to the mobile app, which acts as a "terminal dialogue module" to replace part of the app's bytecode (the "first code") and thereby modify the user dialogue, such as by displaying new order information (Compl. ¶62-66).

III. The Accused Instrumentality

Product Identification

The "Accused Instrumentalities" are Defendant's Party City mobile applications for Android and iOS (the "Defendant app"), along with the associated back-end servers, software, and systems that support the app's functionality (Compl. ¶7).

Functionality and Market Context

The accused system functions as a mobile e-commerce platform, allowing users to place and manage orders from Defendant's retail stores (Compl. ¶4, ¶30). The user's device running the app is characterized as the "terminal machine," which communicates with Defendant's back-end "service provider machine" (Compl. ¶29). The complaint alleges that when a user interacts with the app, data is exchanged with the server; for instance, the server sends information formatted as JSON to the app, which then displays updated content like new or common orders (Compl. ¶34, ¶48). The complaint asserts that Defendant derives a significant portion of its revenue from services using these instrumentalities (Compl. ¶7).

IV. Analysis of Infringement Allegations

9,940,124 Infringement Allegations

10,387,140 Infringement Allegations

Identified Points of Contention

• Scope Questions: A central question may be whether the routine exchange of data (e.g., JSON order information) in a standard client-server application constitutes a "terminal dialogue module" that "updates... code" as contemplated by the patents. The defense may argue this is merely dynamic content being interpreted by a static application, not a software modification. For the ’140 Patent, the scope of "update server machine that is separate and distinct" will be critical, as the complaint's broad definition (Compl. ¶50) could be viewed as inconsistent with the three-entity architecture depicted in the patent's figures.
• Technical Questions: The complaint alleges that incoming JSON data "updates at least a portion of the first code [the app's bytecode] to produce first updated code" (Compl. ¶34, ¶48). A key technical question is what evidence exists to support this mechanism. It raises the question of whether the bytecode is actually modified, or if the JSON data is simply parsed and rendered by existing, unchanged application logic—a standard and distinct technical operation.

V. Key Claim Terms for Construction

• The Term: "dialogue module" / "third code"
  • Context and Importance: The definition of these terms is fundamental. The infringement case rests on equating standard data transmissions in a mobile app (e.g., JSON data representing an order) with the patent's concept of a module that actively modifies application code. Practitioners may focus on this term because if it is construed to require a structural change to the application's translatable code, rather than just providing new data content for interpretation, the infringement theory may be challenged.
  • Evidence for a Broader Interpretation: The complaint notes a prior construction holding that a "dialogue module" can "contain code or other data and can be communicated" (Compl. ¶20, citing Ex. D at 12).
  • Evidence for a Narrower Interpretation: The patents define "code" specifically as "information that must be translated by the software application before it can be implemented" ('140 Patent, col. 4:57-64). The purpose of the module is to "update[] at least a portion of the first code to produce first updated code" in order to "adapt[] the terminal application" ('124 Patent, cl. 1). This language may support a narrower construction requiring an actual modification of the application's underlying logic or structure, not just the processing of new data.
• The Term: "update server machine that is separate and distinct from the terminal machine and the service provider machine"
  • Context and Importance: This term is dispositive for infringement of the asserted claim of the '140 Patent, which requires a three-entity system. The complaint's allegation appears to describe a two-party client-server model and offers a very broad definition for the third entity (Compl. ¶50). The case may turn on whether the accused architecture meets the "separate and distinct" requirement.
  • Evidence for a Broader Interpretation: The patent specification does not appear to offer explicit language supporting an interpretation where the "update server machine" could be another client device or conflated with the service provider machine.
  • Evidence for a Narrower Interpretation: Figure 1 of the patents clearly depicts three separate functional blocks: "UPDATE SERVER MACHINE 102," "SERVICE PROVIDER MACHINE 110," and "TERMINAL MACHINE 120" ('140 Patent, FIG. 1). The specification describes the update server communicating to both of the other machines, reinforcing its distinct architectural role ('140 Patent, col. 6:20-25).

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement based on Defendant's alleged marketing and promotion of the accused apps, with the intent that customers' use would constitute infringement (Compl. ¶35, ¶54, ¶67). It also alleges contributory infringement, asserting the products are not staple articles of commerce suitable for substantial non-infringing use and are especially adapted for infringement (Compl. ¶36, ¶55, ¶68).
• Willful Infringement: Willfulness is alleged based on Defendant's knowledge of the patents "at least since the filing of this complaint" (Compl. ¶27, ¶41, ¶60), establishing a basis for post-suit willfulness.

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

• A core issue will be one of definitional scope: can the term "dialogue module," rooted in the context of a specific software modification method, be construed to cover the routine transmission of dynamic content, such as JSON-formatted order data, within a conventional client-server architecture?
• A second key issue will be one of architectural equivalence: does the Defendant's system meet the '140 patent's requirement for an "update server machine that is separate and distinct" from both the terminal and service provider machines, or does the accused system represent a fundamentally different two-party architecture?
• A central evidentiary question will be one of functional operation: does the incoming data in the accused app actually modify the application's underlying bytecode to "produce... updated code" as claimed, or is that data simply interpreted by existing, unmodified application logic, suggesting a potential mismatch in the accused technical process versus the patented one?