DCT

1:24-cv-00983

WebSock Global Strategies LLC v. Autodesk Inc

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:24-cv-00983, D. Del., 08/28/2024
  • Venue Allegations: Plaintiff alleges venue is proper because Defendant has an established place of business in the District of Delaware, has committed acts of patent infringement in the district, and Plaintiff has suffered harm there.
  • Core Dispute: Plaintiff alleges that certain unidentified products of Defendant infringe a patent related to methods for enabling symmetrical, bi-directional communication over network protocols that are inherently asymmetrical.
  • Technical Context: The technology addresses limitations in standard client-server communication protocols like HTTP, aiming to allow any two network nodes to initiate communication with each other, even when one is behind a firewall or Network Address Translator (NAT).
  • Key Procedural History: U.S. Patent No. 7,756,983 is a continuation of U.S. Application No. 10/338,630, which issued as U.S. Patent No. 7,403,995. This indicates a shared specification and a priority claim dating back to the parent application's filing.

Case Timeline

Date Event
2003-01-08 ’983 Patent Priority Date (filing of parent application)
2008-04-24 ’983 Patent Application Filing Date
2010-07-13 ’983 Patent Issue Date
2024-08-28 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: Standard HyperText Transfer Protocol (HTTP) communication is fundamentally asymmetrical: a "client" initiates a request, and a "server" responds. A server cannot spontaneously initiate a connection to a client. This problem is exacerbated by Network Address Translation (NAT) and firewalls, which typically prevent external devices from initiating connections to "private" devices within a local network, effectively locking the private device into a client-only role (’983 Patent, col. 2:4-21, col. 2:45-51). The patent notes that prior solutions like "polling" (where a client repeatedly asks a server if it has data to send) are inefficient and waste network bandwidth (’983 Patent, col. 3:4-16).
  • The Patented Solution: The invention proposes a method to reverse the client/server roles over an existing, stable network connection. A client first establishes a standard connection (e.g., a TCP/IP socket) and an overlying HTTP session with a server. The client then sends a request to "flip" or reverse the roles. If the server agrees, the initial HTTP session is terminated, but the underlying TCP/IP connection is preserved. A new HTTP session is then established over the same TCP/IP connection, but with the original server now acting as the client and the original client acting as the server (’983 Patent, col. 5:15-31). This allows the node that was formerly the server to initiate data transfers. The process is illustrated in flowcharts for the client (FIG. 9) and server (FIG. 10), which detail the steps of requesting the flip, saving the underlying circuit information, terminating the old HTTP session, and creating a new one with reversed roles (’983 Patent, col. 11:1-55).
  • Technical Importance: This approach aimed to enable true peer-to-peer communication using the ubiquitous HTTP protocol, allowing applications to bypass the inherent client-server asymmetry without resorting to inefficient polling or requiring complex firewall configurations (’983 Patent, col. 3:20-24).

Key Claims at a Glance

  • The complaint alleges infringement of one or more "exemplary method claims" without specifying claim numbers (Compl. ¶11). Independent claim 1 is a representative method claim.
  • Independent Claim 1:
    • first and second network nodes engaging in an asymmetric hypertext transfer protocol (HTTP) transactional session with an underlying network connection, each node enacting distinct initial transactional roles
    • terminating said asymmetric HTTP transactional session while maintaining said underlying network connection
    • said first and second network nodes negotiating transactional role reversal
    • said 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 refers generally to "one or more claims" (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products. It refers to "Exemplary Defendant Products" that are purportedly identified in "charts incorporated into this Count" via Exhibit 2 (Compl. ¶11, ¶13). However, Exhibit 2 was not attached to the publicly filed complaint.

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused products' functionality or market context. It makes only a general allegation that the unnamed products "practice the technology claimed by the '983 Patent" (Compl. ¶13).

IV. Analysis of Infringement Allegations

The complaint alleges direct infringement through claim charts contained in an external "Exhibit 2," which is incorporated by reference but not provided with the complaint (Compl. ¶13-14). The narrative infringement theory is that Defendant's "Exemplary Defendant Products" practice the claimed technology and "satisfy all elements of the Exemplary '983 Patent Claims" (Compl. ¶13). Without the referenced exhibit or identification of the accused products, a detailed element-by-element analysis is not possible.

Identified Points of Contention

  • Evidentiary Question: A threshold issue will be for Plaintiff to identify the specific accused products and provide evidence of their internal operation. The court will need to determine if these products in fact perform the specific steps recited in the claims.
  • Technical Question: Does the accused functionality, once revealed, actually involve terminating an initial HTTP session while preserving the underlying network connection (e.g., a TCP socket) to create a new, reversed-role session? Or does it achieve bi-directional communication through an alternative mechanism, such as using two separate, parallel connections, or a different protocol like WebSockets?
  • Scope Question: How will the term "negotiating transactional role reversal" be construed? The patent describes an explicit "FLIP" request (’983 Patent, col. 10:61-66). A dispute may arise over whether the accused products perform an equivalent "negotiation" if they do not use such an explicit command, or if the role reversal is established through a different sequence of operations.

V. Key Claim Terms for Construction

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

  • Context and Importance: This term is the central inventive concept. Its definition will determine what specific actions between two nodes are required to infringe. The dispute will likely center on whether this requires an explicit, discrete negotiation step as described in the patent's embodiments, or if it can cover any process that results in reversed roles.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The claim language itself is broad, using the general term "negotiating" without further qualification. Parties favoring a broader view may argue this covers any exchange of information that results in an agreement to reverse roles, regardless of the specific format.
    • Evidence for a Narrower Interpretation: The specification repeatedly describes a specific implementation where the client sends an "HTTP FLIP request" and the server decides whether to "accept the new 'flipped' connection" (’983 Patent, col. 10:14-16, col. 10:59-62). The detailed flowcharts in FIGS. 9 and 10 also depict a discrete "SEND HTTP FLIP REQUEST TO SERVER" step (504), which may support a narrower construction tied to this explicit mechanism.

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 a new, second connection in the reverse direction. Infringement requires performing two distinct actions: ending the application-layer session while keeping the transport-layer connection alive. Practitioners may focus on this term because it creates a high technical bar for infringement.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent states that the parties "terminate, let terminate, or otherwise abandon session 150 of HTTP layer 116" but "maintain, however, the underlying network connection" (’983 Patent, col. 9:15-19). An argument for a broader reading might focus on the functional outcome rather than the precise technical command used to achieve it.
    • Evidence for a Narrower Interpretation: The specification provides a detailed technical sequence: "terminate the existing HTTP layer session while preserving the underlying TCP/IP network connection" (’983 Patent, col. 11:40-45). A defendant could argue that this requires a specific software operation that formally closes the HTTP session object without closing the underlying TCP socket, and that their system does not perform this exact sequence.

VI. Other Allegations

Willful Infringement

The complaint does not contain a specific count for willful infringement or allege any facts to support a finding of willfulness, such as pre-suit knowledge of the patent or objective recklessness. The prayer for relief includes a request that the case be declared exceptional under 35 U.S.C. § 285, but this is not supported by factual allegations in the body of the complaint (Compl. Prayer E.i).

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

  • A central issue will be one of technical proof: Can the Plaintiff produce evidence demonstrating that specific, identified Autodesk products perform the patented method of reversing client-server roles by terminating an HTTP-layer session while simultaneously preserving the underlying transport-layer connection for reuse? The current complaint provides no such evidence.
  • The case will also turn on claim construction: Can the term "negotiating transactional role reversal" be construed broadly to cover modern bi-directional communication protocols, or will it be limited by the court to the specific "HTTP FLIP" mechanism described in the patent's preferred embodiments?
  • A key question for the court will be one of technological distinction: Does the accused functionality, once disclosed, represent a fundamentally different and non-infringing approach to bi-directional communication (such as WebSockets or other full-duplex protocols that post-date the patent's priority date) rather than the specific role-reversal method claimed by the ’983 patent?