WebSock Global Strategies LLC v. Apollo Graph Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: Apollo Graph, Inc. (Delaware)
  • Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
• Case Identification: 1:24-cv-00975, D. Del., 08/26/2024
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has an established place of business in the District of Delaware, has committed acts of infringement in the District, and Plaintiff has suffered harm there.
• Core Dispute: Plaintiff alleges that certain unidentified products from Defendant infringe a patent related to enabling symmetrical, bi-directional communication over network protocols that are traditionally asymmetrical, such as HTTP.
• Technical Context: The technology concerns methods for allowing a network server to initiate communication with a client over a persistent connection, overcoming limitations in standard client-server protocols, particularly in environments with network address translation (NAT).
• Key Procedural History: The patent-in-suit is subject to a terminal disclaimer. No other prior litigation, licensing history, or post-grant proceedings are mentioned in the complaint.

Case Timeline

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

• Patent Identification: U.S. Patent No. 7,756,983, “Symmetrical bi-directional communication,” issued July 13, 2010.

The Invention Explained

• Problem Addressed: The patent addresses a fundamental limitation of the HyperText Transfer Protocol (HTTP), where communication is inherently asymmetric: a client must always initiate a request to a server, which can only respond (’983 Patent, col. 1:36-44, col. 2:10-21). This model prevents a server from spontaneously sending data to a client, a significant hurdle for peer-to-peer applications, especially when a client is behind a Network Address Translation (NAT) firewall which blocks unsolicited incoming connections (’983 Patent, col. 2:45-53).
• The Patented Solution: The invention proposes a method to reverse the client and server roles over an established network connection. A client first initiates a standard connection to a server, creating an underlying TCP/IP circuit (’983 Patent, col. 9:40-52). The two nodes then "negotiate transactional role reversal" (’983 Patent, col. 15:31-32). Following this negotiation, the original HTTP session is terminated, but the underlying TCP/IP connection is preserved. A new, "reversed" HTTP session is then created on the preserved connection, allowing the original server to act as a client and initiate requests to the original client, which now acts as a server (’983 Patent, col. 11:46-12:1). This process creates a symmetrical, bi-directional communication channel.
• Technical Importance: This approach enables true peer-to-peer communication using the ubiquitous HTTP protocol, allowing applications to push data from server to client without relying on inefficient techniques like constant polling (’983 Patent, col. 3:4-15).

Key Claims at a Glance

• The complaint does not identify specific asserted claims, instead referring to "Exemplary '983 Patent Claims" (Compl. ¶11). Independent claim 1 is representative of the core invention.
• Independent Claim 1:
  • first and second network nodes engaging in an asymmetric hypertext transfer protocol (HTTP) transactional session with an underlying network connection, each node enacting distinct initial transactional roles, said roles comprising either of an HTTP server that relays data and an HTTP client that initiates requests;
  • terminating said asymmetric HTTP transactional session while maintaining said underlying network connection;
  • said first and second network nodes negotiating transactional role reversal; and
  • said first and second network nodes further communicating under a reversed asymmetric transactional protocol, wherein each network node enacts the initial transactional role of the other...
• The complaint does not explicitly reserve the right to assert dependent claims, but makes a general allegation of infringement of "one or more claims" (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products, methods, or services (Compl. ¶11). It refers to "Exemplary Defendant Products" that are purportedly identified in claim charts attached as Exhibit 2; however, this exhibit was not filed with the complaint (Compl. ¶13).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the functionality or market context of the accused instrumentality.

IV. Analysis of Infringement Allegations

The complaint alleges direct infringement but provides no specific factual allegations in the body of the complaint to support its theory (Compl. ¶11-12). Instead, it states that Exhibit 2, which was not provided, contains "charts comparing the Exemplary '983 Patent Claims to the Exemplary Defendant Products" and that these charts demonstrate that the accused products "satisfy all elements of the Exemplary '983 Patent Claims" (Compl. ¶13). Without this exhibit, a detailed analysis of the infringement allegations is not possible. No probative visual evidence provided in complaint.

V. Key Claim Terms for Construction

"negotiating transactional role reversal" (from Claim 1)

• Context and Importance: This term is central to the claimed invention, as it describes the pivotal step that enables the shift from asymmetric to symmetric communication. The dispute will likely focus on whether the accused products perform an act that can be characterized as a "negotiation" resulting in a "role reversal," or if they use an alternative mechanism (e.g., a different protocol like WebSockets that is bi-directional from inception) that does not map onto this claimed step. Practitioners may focus on this term because its definition will determine whether the patent covers modern persistent-connection technologies.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent does not strictly define "negotiating," which may allow Plaintiff to argue that any protocol exchange that results in the server gaining the ability to initiate messages constitutes a negotiation. The term is used generally throughout the claims (’983 Patent, col. 15:31, 16:21).
  • Evidence for a Narrower Interpretation: The specification’s embodiment, particularly Figure 9, illustrates a specific sequence: a client sends an "HTTP FLIP REQUEST" (504), and the server can either "ACCEPT" or "REFUSE" (506). Defendant may argue that "negotiating" requires this explicit request-and-acceptance handshake, and does not cover protocols that are inherently bi-directional after an initial handshake. The use of "HTTP FLIP request" in the detailed description supports a narrower, more structured definition of the negotiation process (’983 Patent, col. 10:62-66).

"reversed asymmetric transactional protocol" (from Claim 1)

• Context and Importance: This term defines the state of the communication channel after the role reversal. The infringement analysis will depend on whether the accused system establishes a new, distinct "reversed" session that mirrors the original, or if it simply operates over a single, continuously bi-directional channel.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: Plaintiff may argue that any communication initiated by the original server over the established connection falls under a "reversed" protocol, regardless of its formal structure. The claim language is functional, focusing on the act of "communicating under" this reversed protocol (’983 Patent, col. 16:1-3).
  • Evidence for a Narrower Interpretation: The specification suggests the creation of a "new HTTP layer session" with reversed roles after the original session is terminated (’983 Patent, col. 11:51-56, FIG. 9, step 514). Defendant could argue this requires the creation of a second, formally distinct session, not merely the continuation of communication on the original channel.

VI. Other Allegations

• Indirect Infringement: The complaint does not contain allegations of indirect infringement.
• Willful Infringement: The complaint does not allege willfulness in its counts or factual allegations. However, the prayer for relief requests a judgment that the "case be declared exceptional" and seeks attorneys' fees, which is often associated with a finding of willful infringement, but no specific facts supporting pre- or post-suit knowledge are pleaded (Compl. ¶E.i).

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

This case appears to present two central questions, one procedural and one substantive, that will shape its trajectory:

1. A core issue will be one of technological scope: Can the patent’s method of terminating an initial HTTP session and creating a new "reversed" session over a preserved TCP/IP socket be construed to cover modern, persistent bi-directional communication protocols (e.g., those based on GraphQL or WebSockets), which may establish a symmetric channel from the outset without a distinct "reversal" step?

2. A key evidentiary question will be one of functional mapping: As the accused products are based on GraphQL technology, the court will need to determine whether the complex interactions within the Apollo Platform—which manages API queries and data subscriptions—perform the specific sequence claimed: a distinct "negotiation" followed by communication in a "reversed" protocol, or if they represent a fundamentally different architecture for achieving bi-directional data flow.

3. A threshold procedural issue will be the sufficiency of the pleadings. The complaint fails to identify any accused products or provide any factual basis for infringement beyond incorporating by reference an exhibit that was not filed. Defendant may challenge the complaint for failing to meet the pleading standards established by Twombly and Iqbal.