DCT

3:25-cv-01751

WebSock Global Strategies LLC v. Wrike Inc

Log In
Key Events
Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 3:25-cv-01751, N.D. Tex., 07/07/2025
  • Venue Allegations: Venue is alleged to be proper because Defendant maintains an established place of business in the district and has allegedly committed acts of infringement there.
  • Core Dispute: Plaintiff alleges that Defendant infringes a patent related to methods for achieving symmetrical, bi-directional communication over network protocols that are inherently asymmetrical, such as HTTP.
  • Technical Context: The technology addresses limitations in the standard client-server model of the internet, particularly for applications requiring peer-to-peer communication where one or more parties may be behind a firewall or Network Address Translator (NAT).
  • Key Procedural History: The asserted patent is a continuation of an earlier application filed in 2003, which may be relevant for determining the effective date for prior art purposes. The complaint makes no mention of prior litigation, licensing, or administrative proceedings involving the patent-in-suit.

Case Timeline

Date Event
2003-01-08 Priority Date for ’983 Patent (based on parent application)
2008-04-24 ’983 Patent Application Filing Date
2010-07-13 ’983 Patent Issue Date
2025-07-07 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 describes a fundamental problem in network communication: protocols like HyperText Transfer Protocol (HTTP) are inherently asymmetrical, where a "client" always initiates requests and a "server" always responds (’983 Patent, col. 2:10-21). This model prevents a server from initiating communication with a client, which is a significant obstacle for peer-to-peer applications, especially when a client is behind a firewall or Network Address Translator (NAT) that would block unsolicited incoming connections (’983 Patent, col. 2:45-51).
  • The Patented Solution: The invention proposes a method to create symmetrical, peer-to-peer style communication over an asymmetrical protocol. First, a standard connection is established (e.g., a client connects to a server) over a transport layer like TCP/IP (’983 Patent, col. 9:40-51). The parties then negotiate a "transactional role reversal." The initial HTTP session is terminated, but the underlying TCP/IP connection is preserved and kept open (’983 Patent, col. 9:52-57, col. 11:40-46). A new HTTP session is then created over this same preserved connection, but with the roles "flipped": the original server now acts as the client, and the original client acts as the server, enabling the original server to initiate requests (’983 Patent, col. 10:52-60). A flowchart in Figure 9 illustrates the client-side process of sending an "HTTP FLIP REQUEST" and creating a new session with a "reversed role" (’983 Patent, Fig. 9).
  • Technical Importance: This approach provided a way to enable persistent, bi-directional communication for web-based applications without constant, inefficient "polling" by the client, using the widely-deployed HTTP protocol in a novel way (’983 Patent, col. 3:4-15).

Key Claims at a Glance

  • The complaint asserts infringement of "one or more claims," including "exemplary method claims," but does not identify specific claims (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 (HTTP server and HTTP client);
    • terminating said asymmetric HTTP transactional session while maintaining said underlying network connection;
    • said first and second network nodes negotiating transactional role reversal; and
    • said first and second network nodes further communicating under a reversed asymmetric transactional protocol.

III. The Accused Instrumentality

Product Identification

The complaint does not identify any specific accused product, service, or method by name (Compl. ¶¶11, 13). It refers generally to "Defendant products identified in the charts" and "Exemplary Defendant Products" (Compl. ¶11). The defendant, Wrike, Inc., is known for its web-based project management and collaboration software platform (Compl. ¶3).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the functionality or market context of the accused instrumentality.

IV. Analysis of Infringement Allegations

The complaint does not contain claim charts in its body, instead incorporating by reference an "Exhibit 2" that was not publicly available with the initial filing (Compl. ¶¶13-14). The narrative allegations state 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). Without access to the specific charts or more detailed allegations, a direct element-by-element analysis is not possible.

Identified Points of Contention

Based on the asserted technology and the nature of Defendant's business, several potential points of contention can be anticipated.

  • Technical Questions: A central question will be whether any of Wrike's products actually perform the specific steps of the claimed method. For instance, what evidence demonstrates that the accused software (1) establishes an HTTP session, (2) terminates that specific session while (3) preserving the underlying TCP/IP socket, and then (4) creates a new, role-reversed HTTP session over that same socket? The patent describes this as a distinct "HTTP FLIP" process (’983 Patent, Fig. 9, 504), and the Plaintiff will need to prove the accused products perform this specific sequence.
  • Scope Questions: The dispute may turn on whether modern web communication protocols used for real-time updates (such as WebSockets or long-polling techniques), if used by Wrike, fall within the scope of the claims. This raises the question of whether achieving a similar result (bi-directional communication) through different technical means constitutes infringement of the claimed method.

V. Key Claim Terms for Construction

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

Context and Importance

This phrase is the technical core of the invention. Its construction will be critical. If "maintaining said underlying network connection" is construed narrowly to require the specific preservation of the original TCP socket for a new, role-reversed HTTP session, it may be difficult to prove infringement if the accused product uses a different mechanism. If construed more broadly, it could potentially cover a wider range of persistent connection technologies. Practitioners may focus on this term to distinguish the claimed invention from other methods of achieving bi-directional communication.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The specification discusses the general goal of enabling symmetrical communication and overcoming the limitations of the standard client-server model, which might support a construction focused on the functional outcome (’983 Patent, col. 3:18-24).
  • Evidence for a Narrower Interpretation: The detailed description and figures provide a very specific sequence of events: an initial session is established, a "FLIP" is negotiated, the HTTP layer is terminated, the TCP connection is explicitly preserved, and a new HTTP session with reversed roles is created on that same connection (’983 Patent, col. 11:40-55; Figs. 9-10). The patent distinguishes its method from "polling," suggesting the invention is a specific technical solution, not a general concept (’983 Patent, col. 3:4-10).

Term for Construction: "negotiating transactional role reversal"

Context and Importance

The infringement analysis depends on what actions constitute a "negotiation." The Plaintiff may argue this covers any process that results in role reversal, while the Defendant may argue it requires an explicit, discrete step as shown in the patent's embodiments.

Intrinsic Evidence for Interpretation

  • Evidence for a Broader Interpretation: The claim language itself is general ("negotiating"), which could support a reading that does not require a specific command or protocol flag.
  • Evidence for a Narrower Interpretation: The specification provides a specific example of this negotiation: sending an "HTTP FLIP request" from the client to the server, to which the server must accept or refuse (’983 Patent, col. 10:1-11; Fig. 9, 504; Fig. 10, 534). This specific embodiment could be used to argue for a narrower definition requiring an explicit request-and-response protocol for the role reversal.

VI. Other Allegations

Indirect Infringement

The complaint alleges only "Direct Infringement" (Compl. ¶11).

Willful Infringement

The complaint does not contain an explicit allegation of willful infringement or plead facts related to pre-suit knowledge of the patent. However, the prayer for relief requests that the case be declared "exceptional" under 35 U.S.C. § 285, which is the statutory basis for awarding attorney's fees, often in cases of willful infringement or litigation misconduct (Compl. ¶E.i).

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

  1. An Evidentiary Question of Technical Operation: The primary question is factual: what is the specific architecture of the accused Wrike product(s)? Does any accused product actually implement the claimed multi-step method of terminating an HTTP session while preserving the underlying network connection to create a new, distinct session with reversed client-server roles, or does it use an alternative technology like WebSockets to achieve real-time bi-directional communication?

  2. A Definitional Question of Claim Scope: Can the claim term "terminating said asymmetric HTTP...session while maintaining said underlying network connection," which appears to describe a specific "flip" mechanism from the early 2000s, be construed to cover modern, standardized protocols like WebSockets that establish a persistent, bi-directional connection from the outset without a "termination and reversal" step?

  3. A Question of Pleading Sufficiency: Given that the complaint makes only conclusory allegations of infringement and relies entirely on an unattached exhibit to provide the factual basis for its claims, a threshold issue may be whether the complaint provides plausible, non-conclusory factual content sufficient to meet the pleading standards set by the Supreme Court.