WebSock Global Strategies LLC v. Pusher Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: Pusher Ltd. (United Kingdom)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 6:23-cv-00748, W.D. Tex., 11/02/2023
• Venue Allegations: Venue is asserted on the basis that Defendant is a foreign corporation and has allegedly committed acts of patent infringement within the district.
• Core Dispute: Plaintiff alleges that Defendant’s products and services infringe a patent related to methods for enabling symmetrical, bi-directional communication between network nodes over standard protocols like HTTP.
• Technical Context: The technology addresses limitations in standard client-server network protocols to enable peer-to-peer style communication, which is crucial for real-time web applications, especially when a device is behind a network firewall.
• Key Procedural History: The asserted patent is subject to a terminal disclaimer, which may tie its enforceable term to that of its parent patent, U.S. Patent No. 7,403,995. The prosecution history of the parent patent may therefore be relevant for claim construction.

Case Timeline

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

U.S. Patent No. 7,756,983 - "Symmetrical bi-directional communication", issued July 13, 2010

The Invention Explained

• Problem Addressed: The patent addresses the inherent asymmetry of the HyperText Transfer Protocol (HTTP), where a "client" node must initiate all communication with a "server" node. This model prevents a server from spontaneously sending data to a client, a significant limitation for peer-to-peer applications, particularly when the client is on a private network behind a Network Address Translator (NAT) or firewall (’983 Patent, col. 2:5-21).
• The Patented Solution: The invention describes a method where two nodes first establish a standard, client-initiated HTTP session over an underlying network connection (e.g., TCP/IP). The nodes then negotiate a "transactional role reversal." Following this negotiation, the initial application-level HTTP session is terminated, but the underlying TCP/IP connection is preserved. A new HTTP session is then created over the preserved connection, but with the roles inverted: the original server can now act as a client to initiate requests to the original client, which now acts as a server. This enables bi-directional, peer-like communication using standard protocols (’983 Patent, col. 9:12-38; FIG. 9).
• Technical Importance: This method provides a way to circumvent the structural limitations of HTTP to build more dynamic, real-time applications without resorting to inefficient workarounds like constant client polling (’983 Patent, col. 3:4-17).

Key Claims at a Glance

• The complaint asserts "one or more claims" and refers to an un-provided exhibit for specifics (Compl. ¶11, ¶13). Independent claim 1 is representative of the core invention.
• Independent Claim 1 requires:
  • First and second network nodes engaging in an asymmetric HTTP transactional session over an underlying network connection, with distinct initial client and server roles.
  • Terminating the asymmetric HTTP session while maintaining the underlying network connection.
  • The nodes negotiating a transactional role reversal.
  • The nodes communicating under a reversed asymmetric protocol where the initial client is now the server, and vice-versa.
  • The session uses a network connection that traverses hardware enforcing asymmetric communication (e.g., a NAT router).
• The complaint notes infringement may be literal or under the doctrine of equivalents and reserves the right to assert other claims (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not specifically name any accused products, instead referring to "Exemplary Defendant Products" in "the charts of Exhibit 2" (Compl. ¶13). This exhibit was not filed with the complaint.

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's specific functionality or market position. It alleges in a conclusory manner that the unidentified products "practice the technology claimed by the '983 Patent" (Compl. ¶13).

IV. Analysis of Infringement Allegations

The complaint alleges that infringement is detailed in claim charts provided in Exhibit 2; however, this exhibit is not publicly available (Compl. ¶13, ¶14). The complaint’s narrative theory is that Defendant's products directly infringe by implementing the patented method for reversing client-server roles to achieve bi-directional communication (Compl. ¶11, ¶13). Without the claim charts, a detailed element-by-element analysis is not possible.

No probative visual evidence provided in complaint.

• Identified Points of Contention:
  • Technical Questions: A primary question will be whether Defendant’s products, which may use modern protocols like WebSockets, perform the specific sequence claimed in the patent. For instance, does the "upgrade" from an HTTP connection to a WebSocket connection constitute "terminating said asymmetric HTTP transactional session" and then creating a "reversed asymmetric transactional protocol," or is it a distinct technical process?
  • Scope Questions: The case may turn on whether the patent’s claims, which describe a sequence of distinct HTTP sessions, can be construed to read on protocols that establish a single, persistent, full-duplex connection. Another question is what evidence demonstrates that the accused products perform an explicit "negotiating transactional role reversal" as detailed in the patent specification ('983 Patent, FIG. 9, step 504), rather than a standard protocol handshake.

V. Key Claim Terms for Construction

The Term: "terminating said asymmetric HTTP transactional session while maintaining said underlying network connection" (’983 Patent, col. 15:20-22)

• Context and Importance: This term is central to the claimed process. The distinction between terminating an application-layer session and preserving the transport-layer connection is the core of the invention. Defendant may argue its technology (e.g., a WebSocket upgrade) does not "terminate" the HTTP session in the manner claimed. Practitioners may focus on this term because its construction will determine whether modern real-time protocols fall within the claim scope.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification describes the process as terminating the "HTTP layer session" while "preserving TCP connection" (’983 Patent, col. 9:51-53; FIG. 9, step 512). Plaintiff may argue this covers any mechanism that ends the standard HTTP request-response paradigm to enable bi-directional communication over the same underlying socket.
  • Evidence for a Narrower Interpretation: The flowcharts explicitly show terminating the existing session as a distinct step, followed by creating a "new HTTP layer session" with reversed roles (’983 Patent, col. 9:53-56; FIG. 9, step 514). Defendant may argue this requires a discrete stop-and-start of two separate HTTP sessions, not a protocol "upgrade."

The Term: "negotiating transactional role reversal" (’983 Patent, col. 15:23-24)

• Context and Importance: This limitation requires an affirmative act of negotiation. The infringement analysis will depend on whether the evidence shows a specific negotiation for role reversal, as opposed to a standard handshake for establishing a different type of connection.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: Plaintiff could argue that any handshake mechanism where a client requests a persistent, bi-directional connection that the server accepts constitutes a "negotiation" for a reversal of the traditional, client-only initiation model.
  • Evidence for a Narrower Interpretation: The specification discloses an explicit "HTTP FLIP request" sent from the client to the server to initiate the role reversal (’983 Patent, col. 10:61-63). Defendant could argue that the claim requires this specific type of request, not just a generic protocol upgrade request.

VI. Other Allegations

Willful Infringement

The complaint does not explicitly allege willful infringement. However, in its prayer for relief, it requests that the case be "declared exceptional within the meaning of 35 U.S.C. § 285" to recover attorney's fees, but does not plead specific facts (such as pre-suit knowledge of the patent) to support such a finding (Compl. p. 4, ¶E.i).

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

• A core issue will be one of technical mapping: does the functionality of modern real-time communication protocols, such as the "upgrade" from HTTP to a persistent WebSocket connection, align with the patent’s specific, sequential claim limitations of "terminating" an initial HTTP session and "creating" a new, "reversed" session over the same underlying connection?
• A key evidentiary question will be one of functional proof: what evidence will Plaintiff produce from discovery to demonstrate that the accused products perform the explicit "negotiating transactional role reversal" required by the claims, as opposed to a standard protocol handshake that results in a bi-directional communication channel? The outcome will likely depend on whether the accused functionality can be shown to be equivalent to the specific "HTTP FLIP" process detailed in the patent’s specification.