S3G Technology LLC v. Barnes & Noble Booksellers Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: S3G Technology LLC (California)
  • Defendant: Barnes & Noble Booksellers, Inc. (Delaware)
  • Plaintiff’s Counsel: PARKER, BUNT & AINSWORTH, P.C.
• Case Identification: 6:23-cv-00352, W.D. Tex., 05/15/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, transacts business there, and distributes the accused mobile application to customers within the district.
• Core Dispute: Plaintiff alleges that Defendant’s mobile application and supporting server systems infringe patents related to a method for efficiently modifying software on remote devices using lightweight "dialogue modules" rather than full application updates.
• Technical Context: The technology addresses updating applications in a client-server environment, a foundational aspect of the modern mobile app ecosystem where frequent updates and efficient data transfer are critical.
• Key Procedural History: The complaint references prior litigation involving the asserted patents, including court-issued claim construction orders for key terms such as "dialogue module" and "code," suggesting that the scope of these previously construed terms will be central to the present dispute. The complaint also cites a Notice of Allowability from a related patent's prosecution history to support the novelty of the claimed 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”

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. Distributing newly compiled, full-version updates can be slow and consume significant bandwidth, making it impractical for large-scale systems. (Compl. ¶¶12-14; ’140 Patent, col. 2:17-3:2).
• The Patented Solution: The invention proposes a three-part system architecture comprising a terminal machine (e.g., a smartphone), a service provider machine (a server), and an update server machine. Instead of sending a full application, the update server sends a small "dialogue module" containing "code" to the terminal or service provider machine. This module modifies a portion of the existing application, which is specifically structured to consist of both directly "computer-executable instructions" and "code" that must first be translated by the application before execution. This allows for dynamic changes to the application's dialogue sequence without requiring a complete reinstallation. (Compl. ¶¶15-17; ’140 Patent, col. 4:57-64). The complaint provides a diagram from the patent, Figure 1, illustrating the three-entity system communicating wirelessly (Compl. ¶15, p. 7).
• Technical Importance: This architectural approach is designed to reduce network bandwidth utilization and improve the efficiency of modifying and customizing applications running on a network of remote devices. (Compl. ¶23).

Key Claims at a Glance

• The complaint asserts at least independent claim 1. (Compl. ¶28).
• Essential elements of claim 1 (a method claim) include:
  • Displaying a first prompt by running a terminal application that comprises 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.
  • Storing at least a portion of that information in memory for analysis.
  • Receiving, at the terminal machine, a "terminal dialogue module" that updates a portion of the first code to produce first updated code, which adapts the terminal application.
• The complaint does not explicitly reserve the right to assert dependent claims but alleges infringement of "one or more claims." (Compl. ¶28).

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

The Invention Explained

• Problem Addressed: As with the related patents, the ’140 Patent addresses the technical challenges of distributing large, recompiled software updates to numerous remote devices, highlighting the drawbacks of bandwidth limitations and the time required for transmission over wireless networks. (Compl. ¶¶12-14; ’140 Patent, col. 2:17-3:2).
• The Patented Solution: The patent describes a method for modifying a client-server dialogue by sending "code" to a terminal machine. This code modifies an existing "first code" portion of a terminal application, which is distinct from the application's "first computer-executable instructions." The updated code allows the application to conduct a modified dialogue with the service provider machine, thereby achieving updates without replacing the entire application. (Compl. ¶¶15-17, 22; ’140 Patent, col. 4:57-64).
• Technical Importance: The solution purports to enable efficient modification of remote applications by transmitting small, targeted code updates rather than entire software packages, conserving network resources. (Compl. ¶23).

Key Claims at a Glance

• The complaint asserts at least independent claim 1. (Compl. ¶42).
• Essential elements of claim 1 (a method claim) include:
  • Providing a first prompt by a terminal machine running a terminal application, which comprises first computer-executable instructions and first code.
  • Receiving entry of first data at the prompt.
  • Communicating information to a provider application at a service provider machine.
  • Receiving, at the terminal machine, "third code" that modifies at least a portion of the first code to produce first updated code.
  • The claim further requires that this process occurs in a system where the terminal and service provider machines have different processor types, the instructions are fully compiled, and the machines are distinct.
• The complaint alleges infringement of "one or more claims." (Compl. ¶42).

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.
• Technology Synopsis: The patent describes a method for conducting a dialogue between a terminal machine and a service provider machine where the dialogue can be modified. This is achieved by the terminal machine receiving a "terminal dialogue module" that replaces a portion of the terminal application's "first code" to produce an "updated code," thereby adapting the application to display a new prompt or sequence. (Compl. ¶¶12-15, 66).
• Asserted Claims: At least independent claim 1. (Compl. ¶61).
• Accused Features: The complaint alleges that when a user interacts with the "Wish list" feature in the Defendant's app, the app receives information from the Defendant's server (e.g., in JSON format) that functions as a "terminal dialogue module." This module allegedly replaces a portion of the app's bytecode (the "first code") to adapt the application to display an updated wish list. (Compl. ¶¶63, 66).

III. The Accused Instrumentality

Product Identification

The "Accused Instrumentalities" are Defendant's mobile applications for Android and iOS (the "Defendant app"), along with the supporting server systems and software. (Compl. ¶7).

Functionality and Market Context

The accused functionality centers on features like the "wish list," which involve a dialogue between the user's mobile device and Defendant's servers. (Compl. ¶30, 44). The complaint alleges that the mobile app on a user's device (the "terminal machine") runs a terminal application composed of directly executable instructions (e.g., the Android Runtime) and translatable code (the app's bytecode). (Compl. ¶30). The Defendant's server (the "service provider machine") runs a corresponding provider application (e.g., a .NET program). (Compl. ¶32). When a user interacts with their wish list, information is sent to the server, which in turn communicates data back to the app (allegedly in JSON format) to update the wish list display. The complaint frames this data transmission from the server as the "terminal dialogue module" that modifies the app's bytecode. (Compl. ¶34, 48).

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 standard data interchange formats like JSON, transmitted from a server to a mobile app in response to user activity, constitute a "terminal dialogue module" or "third code" within the meaning of the claims. The complaint relies on a prior court construction defining "dialogue module" as a "particular type of structure" (Compl. ¶20), which raises the question of whether simple data payloads meet this structural requirement or if a more specific, self-contained module is required.
• Technical Questions: The infringement theory hinges on mapping the architecture of a modern mobile app (e.g., Android app bytecode executed by the ART virtual machine) to the claimed two-part structure of "computer-executable instructions" and a separate, modifiable "code." A key technical question will be what evidence supports the assertion that the app's bytecode is "code...not able to execute directly on the terminal processor" (Compl. ¶24, Exhibit F) in the specific manner envisioned by the patent, as distinct from the runtime environment itself.

V. Key Claim Terms for Construction

• The Term: "terminal dialogue module"

• Context and Importance: This term is the core of the asserted invention. Plaintiff's infringement case depends on construing this term to read on the data (allegedly JSON) sent from Defendant's server to its mobile app. Practitioners may focus on this term because its definition will likely determine whether routine client-server communication in a mobile app can be considered an infringing act.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The complaint notes a prior construction as "code or instructions related to a dialogue sequence" (Compl. ¶18). This language could potentially encompass any structured data, like JSON, that dictates the content and flow of a user dialogue.
  • Evidence for a Narrower Interpretation: The complaint also cites a judicial finding that the term refers to "a particular type of structure rather than to any structure for performing a function" (Compl. ¶20). The specification's description of the module as being small (e.g., less than 1 Mb) to facilitate communication over limited networks may also support an interpretation requiring a specific, lightweight, and self-contained package rather than a simple data stream. (’140 Patent, col. 7:31-33).

• The Term: "code"

• Context and Importance: The patents claim a novel application structure comprising executable instructions and a separate "code." For the accused app to infringe, its bytecode must be found to be this claimed "code." The viability of the infringement allegation rests on this characterization.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent defines "code" as "information that must be translated by the software application before it can be implemented on the machine processor." (’140 Patent, col. 4:57-64; Compl. ¶16). This appears to align with the technical reality of how bytecode is processed by a virtual machine or runtime like Android's ART.
  • Evidence for a Narrower Interpretation: The patents consistently distinguish between "computer-executable instructions" and "code." (’140 Patent, Abstract). A party could argue that this implies a sharper distinction than that between a runtime environment and the bytecode it executes, potentially requiring a scripting language or other interpreted format that is more clearly separate from the application's primary compiled form.

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement based on Defendant's promotion of its mobile apps, intending for customers to download and use them in a manner that connects to Defendant's servers, thereby completing the infringing system. (Compl. ¶¶35, 54, 67). It also alleges contributory infringement, asserting the accused apps are not staple articles of commerce and are especially adapted to infringe. (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," which provides a basis for post-suit willful infringement. (Compl. ¶¶27, 41, 60). The prayer for relief requests a finding of willfulness. (Compl. p. 27).

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

• A core issue will be one of definitional scope: can the term "dialogue module," construed in prior litigation as a "particular type of structure," be interpreted to cover standard, server-sent data payloads like JSON in a modern mobile application, or does the patent claim a more distinct, self-contained software component?
• A key technical question will be one of architectural mapping: does the common structure of a mobile application—consisting of bytecode executed by a runtime environment like ART—embody the specific two-part structure of "computer-executable instructions" and a separate, modifiable "code" as claimed by the patents, or is there a fundamental mismatch in the technical architecture?