WebSock Global Strategies LLC v. Securus Tech LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: Securus Technologies, LLC (Delaware)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:25-cv-00571, E.D. Tex., 05/22/2025
• Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains an established place of business in the district, has committed acts of infringement there, and Plaintiff has suffered harm in the district.
• Core Dispute: Plaintiff alleges that Defendant infringes a patent related to methods for enabling symmetrical, bi-directional communication over traditionally asymmetrical network protocols like HTTP.
• Technical Context: The technology addresses limitations in the standard client-server communication model, particularly for enabling server-initiated communication with clients located behind Network Address Translation (NAT) firewalls.
• Key Procedural History: The patent-in-suit is a continuation of a prior application, now U.S. Patent No. 7,403,995. The complaint asserts that Plaintiff is the current assignee of all rights to the patent-in-suit.

Case Timeline

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

U.S. Patent No. 7,756,983 - Symmetrical bi-directional communication

The Invention Explained

• Problem Addressed: The patent's background describes the fundamental asymmetry of the HyperText Transfer Protocol (HTTP), where communication is strictly limited to a client initiating a request and a server responding ('983 Patent, col. 2:9-13). This model prevents a server from spontaneously contacting a client, a significant hurdle for peer-to-peer applications and for communicating with devices on private networks behind firewalls or Network Address Translators (NATs) ('983 Patent, col. 2:44-53). Conventional workarounds like "polling" (a client repeatedly asking a server if it has data) are described as inefficient and wasteful of network bandwidth ('983 Patent, col. 3:4-15).
• The Patented Solution: The invention proposes a method to create symmetrical communication by "flipping" the roles of client and server within an established connection. First, a standard connection is made (e.g., from a private client to a public server) establishing an underlying TCP/IP network circuit ('983 Patent, col. 9:1-11). The two nodes then "negotiate transactional role reversal" ('983 Patent, Abstract). This involves terminating the initial HTTP-layer session while explicitly preserving the underlying TCP/IP connection ('983 Patent, col. 10:5-9). A new, "reversed" HTTP session is then created over the same preserved TCP/IP circuit, 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. 10:29-42; Fig. 10).
• Technical Importance: This method provides a mechanism to bypass the inherent one-way initiation restrictions of HTTP, enabling server-initiated or peer-to-peer communication in a way that is compatible with existing network infrastructure, including NATs and firewalls.

Key Claims at a Glance

• The complaint does not identify specific claims, referring only to the "Exemplary '983 Patent Claims" (Compl. ¶11). Independent claim 1 is representative of the core method.
• Independent Claim 1 recites a method with the following key elements:
  • First and second network nodes engage in an asymmetric HTTP transactional session over an underlying network connection, with one node acting as a client and the other as a server.
  • The asymmetric HTTP transactional session is terminated while the underlying network connection is maintained.
  • The first and second network nodes negotiate a transactional role reversal.
  • The nodes then communicate under a "reversed asymmetric transactional protocol" where each node enacts the initial role of the other.
  • The session uses a network connection that traverses "hardware enforcing asymmetric communication."
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products, methods, or services. It refers only to "the Defendant products identified in the charts incorporated into this Count below (among the “Exemplary Defendant Products”)" (Compl. ¶11) and later incorporates "the claim charts of Exhibit 2" by reference (Compl. ¶14).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality or market context, as this information is contained within an exhibit that was not filed with the complaint.

IV. Analysis of Infringement Allegations

The complaint alleges that infringement is detailed in claim charts provided in "Exhibit 2" (Compl. ¶13), which was not available for this analysis. The complaint asserts that these charts demonstrate that the "Exemplary Defendant Products practice the technology claimed by the '983 Patent" and "satisfy all elements of the Exemplary '983 Patent Claims" (Compl. ¶13).

No probative visual evidence provided in complaint.

• Identified Points of Contention:
  • Technical Questions: A primary technical question will be whether the accused products, once identified, actually perform the specific sequence recited in the claims. What evidence does the plaintiff possess that the accused system first terminates an HTTP-layer session while simultaneously and deliberately maintaining the underlying TCP network connection for the express purpose of creating a new, role-reversed session over that same connection?
  • Scope Questions: The infringement analysis may focus on the scope of the claim term "negotiating transactional role reversal." A question for the court could be whether the accused system's protocol for enabling server-to-client communication constitutes a "negotiation" as contemplated by the patent, or if it achieves a similar result through a technically distinct, non-infringing method.

V. Key Claim Terms for Construction

• The Term: "negotiating transactional role reversal"

• Context and Importance: This term is central to the invention's point of novelty. The outcome of the case may depend on whether the defendant's method for enabling bi-directional communication is found to meet this "negotiation" requirement. Practitioners may focus on this term to determine if a specific protocol exchange is required or if any method that results in role reversal suffices.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent claims do not specify a particular command or signal for negotiation, which may support a construction covering any exchange that results in the claimed role reversal.
  • Evidence for a Narrower Interpretation: The specification's embodiments describe a specific "HTTP FLIP request" sent from the client to the server to initiate the process (e.g., '983 Patent, col. 10:62-65; Fig. 9, step 504). A defendant may argue that "negotiating" should be limited to such an explicit request-and-acceptance sequence as shown in the preferred embodiments.

• The Term: "terminating said asymmetric HTTP transactional session while maintaining said underlying network connection"

• Context and Importance: This limitation defines the core technical mechanism of the invention. Proving infringement requires showing both the termination of one software layer (HTTP session) and the preservation of another (TCP connection). The distinction is subtle and will likely be a key point of technical dispute.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: A plaintiff might argue this language covers any process where a persistent channel remains open between two nodes, allowing a subsequent role-reversed communication, without requiring proof of the specific state of the TCP socket.
  • Evidence for a Narrower Interpretation: The specification is quite specific, stating the process involves "terminat[ing] the existing HTTP layer session while preserving the underlying TCP/IP network connection" ('983 Patent, col. 12:41-44) and saving "raw TCP circuit information" to create a new session on top of it ('983 Patent, col. 10:5-9). This language suggests a narrow interpretation requiring proof that the very same network circuit is consciously preserved and reused.

VI. Other Allegations

• Willful Infringement: The complaint does not contain a separate count for willful infringement. However, the prayer for relief requests a judgment that the case be "declared exceptional" and that Plaintiff be awarded its attorneys' fees, which are remedies associated with findings of willful infringement or other litigation misconduct (Compl. Prayer ¶E.i). The complaint does not allege any specific facts to support a claim of pre- or post-suit knowledge.

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

1. A core evidentiary question for the court will be whether Plaintiff can produce technical evidence demonstrating that the accused products perform the specific, multi-step process claimed in the '983 Patent—namely, terminating an HTTP application session while deliberately preserving the underlying TCP network circuit for a new, role-reversed session.
2. The case will likely involve a significant claim construction dispute over the meaning of "negotiating transactional role reversal." The resolution will turn on whether this term requires an explicit, command-based negotiation as shown in the patent's embodiments or can be construed more broadly to cover other protocols that result in bi-directional communication.
3. A foundational issue, arising from the complaint's lack of specificity, will be one of technical mapping: once the accused products and their functionalities are fully disclosed, does their method of operation align with the patent's "terminate-and-preserve" mechanism, or do they achieve bi-directional communication through an alternative architecture not covered by the claims?