DCT

6:24-cv-00256

WebSock Global Strategies LLC v. Akamai Tech Inc

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 6:24-cv-00256, W.D. Tex., 05/14/2024
  • Venue Allegations: Venue is alleged to be proper based on Defendant maintaining an established place of business in the district and committing alleged acts of infringement within the district.
  • Core Dispute: Plaintiff alleges that certain unidentified products of Defendant infringe a patent related to methods for establishing symmetrical, bi-directional communication over network protocols that are traditionally asymmetrical, such as HTTP.
  • Technical Context: The technology addresses limitations in client-server network protocols, enabling a server to initiate communication with a client, which is typically blocked by network address translators (NATs) or firewalls.
  • Key Procedural History: The complaint does not allege any prior litigation, licensing history, or other significant procedural events.

Case Timeline

Date Event
2003-01-08 '983 Patent Priority Date
2010-07-13 '983 Patent Issue Date
2024-05-14 Complaint Filing Date

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 a "fundamental problem" in network communications where protocols like HTTP enforce rigid, asymmetric roles ('983 Patent, col. 2:7-13). A "client" can initiate requests, but a "server" cannot, preventing functional peer-to-peer communication, particularly when a node is on a private network behind a Network Address Translation (NAT) device ('983 Patent, col. 2:13-21, col. 7:15-20). The patent notes that using "polling" by the client to check for server messages is an inefficient solution that "undesirably wastes network bandwidth" ('983 Patent, col. 3:4-5).
  • The Patented Solution: The invention enables symmetrical communication by first establishing a standard, asymmetric HTTP session over an underlying network connection (e.g., TCP/IP). The two nodes then "negotiate transactional role reversal" ('983 Patent, Abstract). This involves terminating the initial HTTP session while preserving the underlying TCP/IP connection. A new HTTP session is then created over the preserved connection, but with the roles reversed—the original server now acts as a client, capable of initiating requests to the original client, which now acts as a server ('983 Patent, col. 5:16-29; Fig. 9).
  • Technical Importance: This method allows applications to achieve true bi-directional, peer-to-peer functionality while still using the ubiquitous and firewall-friendly HTTP protocol, avoiding the drawbacks of polling-based approaches ('983 Patent, col. 4:26-32).

Key Claims at a Glance

The complaint asserts infringement of "one or more claims," referencing "Exemplary '983 Patent Claims" in an unprovided exhibit (Compl. ¶11, ¶13). The patent’s independent claims form the core of the invention.

  • Independent Claim 1:

    • Engaging in an asymmetric HTTP transactional session with an underlying network connection, where nodes have distinct client/server roles.
    • Terminating the HTTP session while maintaining the underlying network connection.
    • Negotiating a transactional role reversal.
    • Communicating further under a reversed asymmetric protocol where each node enacts the other's initial role.
    • The session uses a "network connection traversing hardware enforcing asymmetric communication."

  • Independent Claim 5:

    • Concurrently executing both client and server programming on first and second nodes.
    • Establishing a network connection and creating a first HTTP session (first node as client, second as server).
    • Terminating the first HTTP session while maintaining the underlying connection.
    • Creating a second HTTP session (second node as client, first as server).
    • Conducting transactions in both directions.
    • The connection traverses "hardware that enforces an asymmetric communication."

III. The Accused Instrumentality

The complaint does not identify any specific accused products, methods, or services by name in the body of the complaint (Compl. ¶¶1-16). It refers to "Exemplary Defendant Products" that are purportedly identified in an exhibit that was not filed with the complaint (Compl. ¶11, ¶13). The complaint therefore does not provide sufficient detail for analysis of the accused instrumentality.

IV. Analysis of Infringement Allegations

No probative visual evidence provided in complaint.

The complaint’s infringement allegations are conclusory and incorporate by reference an unprovided document, stating that "Exhibit 2 includes charts comparing the Exemplary '983 Patent Claims to the Exemplary Defendant Products" (Compl. ¶13). Without this exhibit or a narrative description of the alleged infringement in the complaint itself, a detailed analysis is not possible.

  • Identified Points of Contention:
    Based on the patent's claims, any future infringement analysis would likely focus on several key technical questions:
    • Scope Questions: What specific hardware qualifies as "hardware enforcing asymmetric communication" as required by the claims? Does this limitation require a device like a traditional NAT, or could it read on other network components?
    • Technical Questions: What evidence demonstrates that the accused system performs the specific sequence of (1) establishing a first HTTP session, (2) terminating it while maintaining the underlying TCP connection, and (3) creating a new HTTP session with reversed roles on that same preserved connection? The distinction between this multi-step process and other methods for bi-directional communication, such as tunneling data over a single, persistent HTTP session, will be a central technical issue.

V. Key Claim Terms for Construction

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

    • Context and Importance: This term is central to the inventive concept of actively and cooperatively flipping the client/server relationship. The definition will determine whether a specific, explicit messaging protocol is required or if a more general change in communication patterns suffices.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Narrower Interpretation: The specification describes a specific implementation where the client sends an "HTTP FLIP request" and the server responds with an "OK" or "REFUSE" ('983 Patent, Fig. 9, block 504; Fig. 10, block 534). The patent also shows a specific TACT:DFLIP header in a sample HTTP exchange, suggesting a defined protocol ('983 Patent, Fig. 13).
      • Evidence for a Broader Interpretation: The term "negotiating" itself is not explicitly defined, which could support an argument that any protocol exchange that results in an agreed-upon role reversal meets the limitation, even if it does not use the exact "FLIP request" embodiment.

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

    • Context and Importance: This limitation distinguishes the invention from simply opening two independent connections. The infringement analysis will depend on whether an accused system is found to "terminate" one session and reuse its "underlying connection" for a new one. Practitioners may focus on this term because it requires a specific interaction between the application (HTTP) and transport (TCP) layers.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Narrower Interpretation: The flowcharts detail a specific process of "extract[ing] raw TCP circuit information," "sav[ing] TCP circuit information in data structure," and then "terminat[ing] existing HTTP layer session while preserving TCP connection" ('983 Patent, Fig. 9, blocks 508-512). This suggests a deliberate, multi-step preservation process.
      • Evidence for a Broader Interpretation: The claim language itself does not recite the specific steps of extracting and saving circuit information, which may support a construction that does not require those specific implementation details, so long as the underlying connection is, in fact, maintained and reused.

VI. Other Allegations

  • Willful Infringement: The complaint does not contain a specific count for willful infringement or allege facts that would typically support such a claim, such as pre-suit knowledge of the patent. However, the prayer for relief requests that the case be "declared exceptional" and for an award of attorneys' fees (Compl. p. 4, ¶E.i).

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

  1. An Evidentiary Question of Specificity: The complaint is a "bare-bones" filing that defers all substantive infringement allegations to an unprovided exhibit. A threshold issue for the case will be whether the plaintiff can produce specific, factual evidence linking the detailed, multi-step processes of the patent’s claims to the actual operation of identified Akamai products.

  2. A Claim Construction Question of Mechanism: The case will likely turn on the construction of key functional terms. A core issue will be one of definitional scope: can "negotiating transactional role reversal" be met by any process that results in bi-directional communication, or does it require an explicit, discrete messaging protocol as detailed in the patent’s preferred embodiments?

  3. A Technical Question of Equivalence: A key dispute may be one of technical implementation: assuming a product is identified that allows bi-directional communication, does it operate by terminating an initial HTTP session and creating a new one on the same preserved TCP socket, as claimed, or does it achieve a similar result through a fundamentally different, non-infringing mechanism, such as WebSocket or long-polling within a single, ongoing HTTP session?