WebSock Global Strategies LLC v. Teamworkers Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: Teamworkers Inc. (Delaware)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 1:25-cv-02390, D. Colo., 08/04/2025
• Venue Allegations: Venue is asserted based on the defendant maintaining an established place of business in the District of Colorado.
• Core Dispute: Plaintiff alleges that Defendant’s products infringe a patent related to methods for enabling symmetrical, bi-directional communication between network nodes using the Hypertext Transfer Protocol (HTTP).
• Technical Context: The technology addresses limitations in standard network protocols that typically prevent peer-to-peer communication between devices separated by firewalls or Network Address Translation (NAT) systems.
• Key Procedural History: The patent-in-suit is a continuation of a parent application that issued as U.S. Patent No. 7,403,995, which may be relevant for establishing the effective priority date of the asserted claims.

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’s background section describes a fundamental problem in network communication: the Hypertext Transfer Protocol (HTTP) is inherently asymmetrical. A “client” node initiates a request, and a “server” node responds; the server cannot initiate communication with the client. This asymmetry creates significant obstacles for peer-to-peer applications, particularly when one node is behind a Network Address Translation (NAT) firewall, which blocks unsolicited incoming connections. (’983 Patent, col. 2:5-21, 2:44-51). Conventional workarounds like frequent “polling” by the client are described as inefficient and wasteful of network bandwidth. (’983 Patent, col. 3:3-7).
• The Patented Solution: The invention proposes a method to create symmetrical, two-way communication over an established network connection. Initially, a client establishes a standard, asymmetric HTTP session with a server over an underlying transport layer like TCP/IP. The two nodes then "negotiate transactional role reversal." Following this negotiation, the initial HTTP-layer session is terminated, but the underlying TCP/IP network connection is preserved. A new, "reversed" HTTP session is then created over 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. 5:15-28, col. 9:12-34; Fig. 9).
• Technical Importance: This technique enables applications to conduct true, bi-directional peer-to-peer communication using the ubiquitous and firewall-friendly HTTP protocol, bypassing the traditional limitations imposed by NATs and protocol asymmetry. (’983 Patent, col. 3:17-24).

Key Claims at a Glance

• The complaint does not specify which claims are asserted, referring generally to the "Exemplary '983 Patent Claims" identified in an exhibit not attached to the publicly filed complaint (Compl. ¶11, ¶13). Independent method claim 1 is representative of the core technology.
• Independent Claim 1 requires:
  • First and second network nodes engaging in an asymmetric hypertext transfer protocol (HTTP) transactional session with an underlying network connection.
  • Terminating the asymmetric HTTP transactional session while maintaining the underlying network connection.
  • The first and second network nodes negotiating transactional role reversal.
  • The first and second network nodes further communicating under a reversed asymmetric transactional protocol.
• The complaint does not explicitly reserve the right to assert dependent claims, but infringement of "one or more claims" is alleged (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not identify any specific accused products or services by name. It refers generically to "Exemplary Defendant Products" which it states are identified in charts contained in Exhibit 2. (Compl. ¶11, ¶13).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality. It makes a conclusory allegation that the "Exemplary Defendant Products practice the technology claimed by the '983 Patent" but offers no factual description of how they operate. (Compl. ¶13). No allegations regarding market context or commercial importance are provided.

IV. Analysis of Infringement Allegations

The complaint alleges direct infringement but incorporates its substantive allegations by reference to claim charts in an external exhibit (Exhibit 2), which was not provided with the filed complaint. The narrative allegations state that Defendant's "Exemplary Defendant Products" infringe by practicing the claimed technology and satisfying all elements of the asserted claims. (Compl. ¶11, ¶13). Without the referenced exhibit, a detailed analysis of the infringement theory is not possible based on the complaint alone.

No probative visual evidence provided in complaint.

Identified Points of Contention

Based on the asserted technology, the infringement analysis will likely focus on several key technical and legal questions:

• Technical Questions: What evidence demonstrates that the accused products perform the specific sequence of terminating a higher-level protocol session (e.g., HTTP) while explicitly preserving the underlying network transport connection (e.g., a TCP socket)? The mechanism of "negotiating transactional role reversal" will be a central factual dispute. The plaintiff would need to show evidence of a specific protocol exchange or state change that constitutes such a negotiation.
• Scope Questions: Do the communication protocols used by the accused products qualify as "asymmetric hypertext transfer protocol (HTTP) transactional session[s]" as the term is used in the patent? The analysis may hinge on whether Defendant's proprietary protocols fall within the scope of "HTTP" as construed from the patent's specification.

V. Key Claim Terms for Construction

The Term: "negotiating transactional role reversal"

• Context and Importance: This phrase captures the core inventive act. The outcome of the case may depend on whether the accused products perform an act that can be defined as "negotiating." Practitioners may focus on this term because it implies a specific, multi-party process of agreement, which may or may not be present in the accused functionality.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language itself is general and does not require a specific type of negotiation. The summary of the invention also refers to negotiation in general terms, which a plaintiff may argue supports a construction that covers any process by which roles are reversed by mutual operation. (’983 Patent, col. 3:30-34).
  • Evidence for a Narrower Interpretation: The detailed description and flowcharts explicitly depict this step as sending an "HTTP FLIP request" from a client to a server, which the server can then "ACCEPT" or "REFUSE." (’983 Patent, Fig. 9, blocks 504 & 506; Fig. 10, blocks 534 & 536; col. 10:60-66). A defendant may argue this disclosure limits the scope of "negotiating" to a specific, explicit request-and-response message sequence.

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

• Context and Importance: This limitation defines a critical technical step that distinguishes the invention from simply opening two separate connections. Proving infringement requires showing that two distinct events—termination of the HTTP layer and preservation of the transport layer—occur as a single, coordinated action.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language is functional. A plaintiff could argue that any technical implementation that achieves the outcome of ending the initial set of protocol rules while keeping the underlying data pipe open meets this limitation, regardless of the specific software architecture.
  • Evidence for a Narrower Interpretation: The specification consistently distinguishes between the "HTTP layer or session" and the underlying "TCP/IP network connection" or "socket." (’983 Patent, col. 5:18-28, col. 9:16-21). A defendant could argue this requires proof of a distinct and separable termination of the HTTP application layer while the TCP socket state is explicitly preserved, potentially excluding integrated protocols where such layers are not distinct.

VI. Other Allegations

The complaint alleges only direct infringement and does not contain factual allegations to support claims for indirect or willful infringement. (Compl. ¶11).

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

1. A central issue will be one of technical mechanism: Does the accused product's communication protocol perform the specific, multi-step process recited in the claims—establishing an HTTP session, "negotiating" a role reversal, terminating that HTTP session while preserving the underlying network connection, and then communicating in a reversed-role state—or does it achieve bi-directional communication through a different technical pathway?
2. The case will also present a key evidentiary question: Given the complaint's lack of specific factual allegations, what discovery evidence will the Plaintiff be able to produce to demonstrate that the accused product's internal operations and protocol exchanges map directly onto each element of the asserted claims, particularly the "negotiating" and "terminating while maintaining" steps?