WebSock Global Strategies LLC v. Taskus

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: TaskUs (Jurisdiction N/A)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 7:25-cv-00243, W.D. Tex., 05/22/2025
• Venue Allegations: Venue is asserted based on Defendant maintaining an established place of business within the Western District of Texas.
• Core Dispute: Plaintiff alleges that unspecified products or services from Defendant infringe a patent related to methods for enabling symmetrical, bi-directional communication over inherently asymmetrical network protocols such as HTTP.
• Technical Context: The technology addresses a fundamental limitation in client-server network architecture, where a server cannot typically initiate communication, a significant hurdle for peer-to-peer applications or for reaching devices behind firewalls.
• Key Procedural History: The asserted patent is a continuation of an earlier application filed in 2003 and is subject to a terminal disclaimer, which may limit its enforceable term. The complaint does not mention any other prior litigation or administrative proceedings involving the patent.

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 addresses the inherent 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:10-15). This model prevents a server from spontaneously sending data to a client and is inefficient for peer-to-peer applications, particularly when one node is on a private network behind a Network Address Translation (NAT) device, making it difficult to contact directly ('983 Patent, col. 2:45-50). The common workaround, frequent "polling" by the client to check for new data, is described as undesirable and wasteful of network bandwidth ('983 Patent, col. 3:4-8).
• The Patented Solution: The invention proposes a method to create a symmetrical communication channel over the asymmetric HTTP protocol. It begins with a standard client-server HTTP session. The nodes then "negotiate" a reversal of their transactional roles. Crucially, the initial HTTP session is terminated, but the underlying TCP/IP network connection (the "socket") is preserved ('983 Patent, col. 9:11-22). A new HTTP session is then created over this same preserved connection, but with the roles "flipped," 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. 9:31-47; Fig. 9).
• Technical Importance: This technique allowed applications to achieve true bi-directional, peer-to-peer communication using the ubiquitous and firewall-friendly HTTP protocol, overcoming the structural limitations of its client-server model ('983 Patent, col. 3:18-24).

Key Claims at a Glance

• The complaint asserts infringement of "one or more claims" without specifying them (Compl. ¶11). The first independent claim, Claim 1, is representative.
• The essential elements of Claim 1 include:
  • First and second network nodes engaging in an initial asymmetric HTTP transactional session over an underlying network connection.
  • Terminating the asymmetric HTTP session while maintaining the underlying network connection.
  • The nodes negotiating a transactional role reversal.
  • The nodes communicating further 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 (e.g., a NAT router).
• The complaint reserves the right to assert other claims (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint refers to "Exemplary Defendant Products" but does not name them (Compl. ¶11). It states these products are identified in "charts incorporated into this Count" and in an "Exhibit 2" (Compl. ¶11, ¶13). However, no charts are included in the body of the complaint, and no exhibits were provided with the filed document.

Functionality and Market Context

The complaint does not provide any specific details about the technical functionality, operation, or market context of the accused products. It makes only the conclusory allegation that the products "practice the technology claimed by the '983 Patent" (Compl. ¶13).

IV. Analysis of Infringement Allegations

The complaint references claim charts in an Exhibit 2 to support its infringement allegations, but this exhibit was not provided (Compl. ¶13, ¶14). The pleading itself contains no specific factual allegations mapping claim elements to accused product features. It states only that the "Exemplary Defendant Products incorporated in these charts satisfy all elements of the Exemplary '983 Patent Claims" (Compl. ¶13). Due to the lack of specific allegations or an accompanying claim chart, a detailed tabular analysis is not possible.

No probative visual evidence provided in complaint.

Identified Points of Contention

Given the absence of specific infringement allegations, any analysis of potential disputes must be based on the claim language itself and the nature of the technology.

• Technical Questions: A central evidentiary question will be whether the accused products actually perform the specific sequence required by the claims. What evidence shows that an initial HTTP session is terminated while the underlying network socket is maintained for a new, reversed-role session? Does the accused system use this specific "terminate-preserve-recreate" method, or does it achieve bi-directional communication through an alternative mechanism, such as opening two separate connections or using a different protocol (e.g., WebSockets) that provides a persistent, full-duplex connection from the outset?
• Scope Questions: The case will likely involve debate over the meaning of "negotiating transactional role reversal." What actions by the accused products constitute a "negotiation"? Does a simple, one-way command from one node to the other suffice, or does the term imply a more interactive, multi-step exchange as depicted in the patent's flowcharts?

V. Key Claim Terms for Construction

• The Term: "negotiating transactional role reversal" (Claim 1)

• Context and Importance: This phrase captures the core inventive concept. Whether the accused products' behavior falls within the scope of this term will be critical. Practitioners may focus on this term because its definition determines whether a wide range of modern bi-directional communication protocols, or only a specific implementation, is covered by the patent.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent does not explicitly define "negotiating." A party could argue that any exchange of messages that results in a role flip meets the definition. The specification describes sending an "HTTP FLIP request" and receiving a simple "OK" response, which could be characterized as a minimal but sufficient negotiation ('983 Patent, Fig. 9, 504; Fig. 10, 534, 544).
  • Evidence for a Narrower Interpretation: A party could argue that "negotiating" requires a more formal, multi-step process as detailed in the flowcharts of Figures 9 and 10, which show a sequence of request, reply, extraction of TCP information, and creation of a new session ('983 Patent, col. 10:53-66). Language describing the specific "HTTP FLIP request" could be used to argue that the term is tied to the disclosed embodiment.

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

• Context and Importance: This term describes the key technical mechanism enabling the role reversal. The infringement analysis will depend on whether the accused products perform this exact sequence.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification uses flexible language, stating the nodes "terminate, let terminate, or otherwise abandon session 150 of HTTP layer 116" while maintaining the underlying connection ('983 Patent, col. 9:14-18). This could be argued to cover any method that ends the state of the first session before starting the second.
  • Evidence for a Narrower Interpretation: The flowcharts show "TERMINATE EXISTING HTTP LAYER SESSION" as a discrete, explicit step ('983 Patent, Fig. 9, 512; Fig. 10, 546). A party could argue this requires a formal teardown of the application-layer state machine, not merely a cessation of communication in one direction. If an accused product simply repurposes an open HTTP connection without this explicit termination step, it might be argued not to infringe.

VI. Other Allegations

• Indirect Infringement: The complaint contains a count for "Direct Infringement" but does not allege facts to support, or make a claim for, indirect infringement (Compl. ¶11).
• Willful Infringement: The complaint does not contain specific factual allegations regarding pre- or post-suit knowledge to support a claim for willful infringement. The prayer for relief asks that the case be declared "exceptional" and for an award of attorneys' fees, but the pleading currently lacks a formal willfulness count (Compl. p. 4, ¶E.i).

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

1. A core issue will be one of evidentiary proof: As the complaint lacks specific factual allegations, a primary question is what evidence Plaintiff will introduce to demonstrate that the accused products perform the precise multi-step process recited in Claim 1—specifically, terminating an HTTP session while preserving the underlying network socket for a new, reversed-role session.

2. The case will likely turn on a question of claim scope: How broadly will the court construe the term "negotiating transactional role reversal"? The resolution of this issue will determine whether the patent covers a wide range of modern bi-directional communication techniques or is limited to the specific "HTTP FLIP request" protocol detailed in the patent's embodiments.