S3G Technology LLC v. Michaels Stores Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: S3G Technology LLC (California)
  • Defendant: Michaels Stores, Inc. (Delaware)
  • Plaintiff’s Counsel: Parker, Bunt & Ainsworth, P.C.
• Case Identification: 6:22-cv-00637, W.D. Tex., 06/20/2022
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district, transacts business there, and has committed alleged acts of infringement within the district.
• Core Dispute: Plaintiff alleges that Defendant’s mobile application and supporting server infrastructure infringe patents related to a method and system for efficiently modifying software applications on remote devices.
• Technical Context: The technology addresses updating distributed client-server applications by transmitting small "dialogue modules" to modify application behavior, rather than sending large, fully-recompiled application files, thereby conserving network bandwidth.
• Key Procedural History: The complaint references prior litigation involving the same patent family, S3G Tech. LLC v. Unikey Techs., Inc., in which the court construed key claim terms such as "computer-executable instructions," "code," and "dialogue module." The complaint also cites the prosecution history, quoting a Notice of Allowability that distinguished the claimed invention from the prior art based on the specific structure of an application comprising both directly executable instructions and code that requires translation.

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", Issued April 10, 2018

The Invention Explained

• Problem Addressed: The patent addresses the difficulty and inefficiency of updating software applications distributed across many remote devices, particularly over wireless networks with limited bandwidth. Transmitting entire newly compiled applications is often slow, costly, and may exceed network capacity (Compl. ¶¶13-14; ’897 Patent, col. 2:21-55).
• The Patented Solution: The invention proposes a three-entity system (update server, service provider machine, and terminal machine) that modifies applications without replacing them entirely. Instead of sending a large executable file, the system sends a small "dialogue module." This module contains "code," which is defined as information that must be translated by the application before it can be executed. This code adapts the application's behavior, such as changing a sequence of user prompts, without altering the application's underlying, directly executable instructions (Compl. ¶¶15-17; ’897 Patent, col. 4:24-31, FIG. 1). The complaint references FIG. 1 to illustrate this three-entity architecture (Compl. ¶15).
• Technical Importance: This approach is designed to reduce network bandwidth utilization, allowing for efficient modification of applications running on remote devices over capacity-constrained networks (Compl. ¶23; ’897 Patent, col. 6:51-53).

Key Claims at a Glance

• The complaint asserts independent claim 1 and reserves the right to assert dependent claims (Compl. ¶28).
• Claim 1, as described in the complaint, outlines a method comprising the following essential elements:
  • Displaying a first prompt by running a terminal application, which itself comprises first computer-executable instructions and first code.
  • Accepting a first data entry at the terminal machine.
  • Communicating information from the data entry to a service provider machine running a provider application, which comprises second computer-executable instructions and second code.
  • Storing at least a portion of the communicated 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.
  • 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, or first updated code comprises intermediate code.

U.S. Patent No. 9,081,897, "Modification of Terminal and Service Provider Machines Using an Update Server Machine", Issued July 14, 2015

The Invention Explained

• Problem Addressed: As with the related ’124 Patent, the technology targets the inefficiency of distributing large software updates to a fleet of remote devices over networks with limited data transfer capacity (Compl. ¶¶12-14; ’897 Patent, col. 2:4-29).
• The Patented Solution: The ’897 Patent claims a system architecture to solve this problem. The system comprises an update server, a terminal machine (e.g., a mobile device), and a service provider machine (e.g., a back-end server). The applications on the terminal and provider machines are specifically structured to have two parts: a set of directly "computer-executable instructions" and a set of "code" that requires translation. The update server sends "dialogue modules" that modify only the "code" portion, leaving the larger "computer-executable instructions" untouched. This allows for lightweight updates that change application functionality (Compl. ¶¶16-17; ’897 Patent, col. 7:45-50, FIG. 2). The complaint references FIG. 2 to illustrate this specific application structure (Compl. ¶16).
• Technical Importance: The claimed system structure enables targeted, efficient updates to distributed software, which is critical for managing applications on devices like mobile phones or point-of-sale terminals (Compl. ¶23; ’897 Patent, col. 2:56-58).

Key Claims at a Glance

• The complaint asserts independent claim 1 and reserves the right to assert dependent claims (Compl. ¶42).
• Claim 1, as described in the complaint, outlines a system comprising the following essential elements:
  • An update server machine operable for sending a terminal dialogue module and a provider dialogue module.
  • A terminal machine running a terminal application that comprises a first set of computer-executable instructions (able to execute directly on a terminal processor) and a first set of code (not able to execute directly).
  • A service provider machine running a provider application that comprises a second set of computer-executable instructions (able to execute directly on a provider processor) and a second set of code (not able to execute directly).
  • The terminal dialogue module modifies the first code to produce first updated code, but does not modify the first computer-executable instructions.
  • The provider dialogue module modifies the second code to produce second updated code, but does not modify the second computer-executable instructions.
  • The updated codes adapt their respective applications to use a modified dialogue sequence.

U.S. Patent No. 10,831,468, "Modification of Terminal and Service Provider Machines Using an Update Server Machine", Issued November 10, 2020

• Technology Synopsis: This patent, part of the same family, claims a method for conducting a dialogue between a terminal and service provider machine. The method involves the terminal application, comprising first computer-executable instructions and translatable first code, communicating with a provider application. The core inventive concept remains the receipt of a "third code" (analogous to a dialogue module) that replaces or supplements a portion of the first code to modify the terminal application's dialogue sequence without recompiling the entire application (Compl. ¶¶57, 60; ’468 Patent, Abstract).
• Asserted Claims: Independent claim 1 is asserted (Compl. ¶55).
• Accused Features: The complaint accuses the Michaels App's system of performing the claimed method. It alleges the app's interaction with the server for features like "favorite orders" involves receiving data (identified as "third code" in JSON format) from an update server (which may be the user's own device or the Defendant's server) that modifies the app's behavior after a trigger condition is met (Compl. ¶¶60-63).

III. The Accused Instrumentality

• Product Identification: The accused instrumentalities are the "Defendant App" (mobile applications for Android and iOS) and its supporting systems, servers, and software (Compl. ¶7).
• Functionality and Market Context: The Defendant App is a mobile ordering application that allows users to interact with Defendant's services. The complaint focuses on the "favorite orders" feature, which allows a user to review, edit, delete, and place orders based on saved preferences (Compl. ¶30). This functionality allegedly requires communication between the user's device (the terminal machine) and Defendant's server (the service provider machine). The complaint alleges that when a user manages favorite orders, information in JSON format is sent from the server to the app, which is then stored and used to update the user interface and available actions (Compl. ¶34). The complaint alleges Defendant derives significant revenue from the use of these instrumentalities (Compl. ¶4).

IV. Analysis of Infringement Allegations

’124 Patent Infringement Allegations

’897 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: A primary question will be whether the patents' distinction between "computer-executable instructions" and "code" accurately maps onto a standard mobile architecture like the Android Runtime and app bytecode. A defense may argue that bytecode is also a form of executable instruction, collapsing the claimed two-part structure. A related question is whether a data payload, such as a JSON file describing a "favorite order," can be considered "code" and a "dialogue module" as those terms are used in the patents.
• Technical Questions: The analysis may turn on what it means to "update" code. The complaint alleges that receiving and storing a JSON file constitutes updating the app's bytecode (Compl. ¶34). The court will have to determine if processing new data is equivalent to modifying the application's underlying logic or instructions, as required by the claim language "updates at least a portion of the first code to produce first updated code."

V. Key Claim Terms for Construction

• The Term: "code"

  • Context and Importance: This term's construction is fundamental. The patents' core concept rests on distinguishing "code" (which is modified) from "computer-executable instructions" (which are not). If "code" is construed narrowly, the infringement theory may fail.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The complaint cites the specification defining code as "information that must be translated by the software application before it can be implemented on the machine processor" (’897 Patent, col. 4:24-31; Compl. ¶16). It also cites a prior court construction adopting this definition (Compl. ¶16, fn. 5). This broad definition could potentially encompass interpreted data formats like JSON.
    • Evidence for a Narrower Interpretation: The specification also refers to Java Byte Code as an example of "intermediary code" (’897 Patent, col. 2:67). A defendant may argue this context limits "code" to compiled intermediate languages, not simple data structures.

• The Term: "dialogue module"

  • Context and Importance: The infringement allegation hinges on casting a JSON data payload as a "dialogue module." The definition of this term will determine if that characterization is viable. Practitioners may focus on this term because it appears to require a specific structure.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The complaint cites a prior construction as "code or instructions related to a dialogue sequence" (Compl. ¶18). It also cites the prior court's finding that the term refers to "a particular type of structure rather than to any structure for performing a function" (Compl. ¶20). Plaintiff will likely argue a JSON object is a "structure" containing "instructions" (e.g., item names, prices) "related to a dialogue sequence" (managing favorite orders).
    • Evidence for a Narrower Interpretation: The abstract of the '897 patent describes the module as containing "a first and second set of updated code." This may suggest a module is more than just data; it is a package containing executable or interpretable logic itself.

• The Term: "updates at least a portion of the first code to produce first updated code"

  • Context and Importance: This phrase is the central action of the alleged infringement. Its construction will determine whether receiving and processing data constitutes the claimed "update."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification states the module "adapts the terminal application to use a second sequence of prompts" (’897 Patent, col. 4:31-34). An argument could be made that when an application's behavior (the sequence of prompts) changes based on new data, the underlying "code" that generates this behavior has been functionally "updated."
    • Evidence for a Narrower Interpretation: The common technical meaning of "updating code" involves altering the instructions or logic of a program, for example by replacing a file or modifying it in memory. A defendant may argue that simply providing new data for an existing, unchanged program to process does not meet this limitation, and that the specification's discussion of replacing or supplementing code supports this narrower view (’897 Patent, col. 9:43-52).

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement by Defendant marketing and promoting its mobile applications for users to download and run, allegedly knowing that this use, in conjunction with Defendant's servers, would infringe the patents-in-suit (Compl. ¶¶35, 48, 67).
• Willful Infringement: The complaint alleges Defendant has had "actual knowledge" of the patents "[a]t least since the filing of the original complaint" or "this complaint" (Compl. ¶¶27, 41, 54). This appears to be a claim for post-suit willful infringement.

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 patent as "information that must be translated," be construed broadly enough to read on structured application data, such as a JSON file, or is it limited to forms of intermediate programming language like bytecode?
• A related and central question will be one of technical mechanism: does an application's act of receiving, storing, and processing a data file to alter its user interface constitute "updating" the application's "code to produce...updated code" as claimed, or is this a fundamental mischaracterization of the distinction between program logic and the data upon which it operates?
• A key evidentiary question will be one of architectural equivalence: does the accused system's separation of a runtime environment (e.g., ART) from an application package (e.g., Android bytecode) map onto the patents' claimed two-part structure of "computer-executable instructions" and "code," or will this be seen as an artificial framing of a standard software architecture?