WebSock Global Strategies LLC v. Mondaycom Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: WebSock Global Strategies LLC (Delaware)
  • Defendant: Monday.com Ltd. (Israel)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:25-cv-00761, E.D. Tex., 08/04/2025
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant has an established place of business in the District, has committed acts of patent infringement in the District, and Plaintiff has suffered harm there.
• Core Dispute: Plaintiff alleges that Defendant’s unnamed products and services infringe a patent related to methods for symmetrical, bi-directional communication over computer networks.
• Technical Context: The technology addresses inherent asymmetries in the Hypertext Transfer Protocol (HTTP), where communication is typically initiated only by a "client," to enable a "server" to initiate communication, facilitating more peer-to-peer style interactions.
• Key Procedural History: The patent-in-suit is a continuation of an earlier application that issued as U.S. Patent No. 7,403,995. The complaint itself does not mention any other prior litigation, licensing, or administrative proceedings related to the patent.

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 addresses a "fundamental problem" in network communications where standard HTTP protocol enforces rigid, asymmetric roles: a "client" initiates requests, and a "server" responds ('983 Patent, col. 2:6-12). This structure prevents a server from initiating spontaneous communication with a client, which is a significant limitation for peer-to-peer applications, especially when network address translation (NAT) or firewalls are involved ('983 Patent, col. 2:44-51). Polling, where a client repeatedly asks a server if it has data, is described as an inefficient solution that "wastes network bandwidth" ('983 Patent, col. 3:4-6).
• The Patented Solution: The invention proposes a method where two network nodes first establish a standard HTTP session over an underlying network connection (e.g., TCP/IP) ('983 Patent, col. 5:16-24). The nodes then "negotiate transactional role reversal." This negotiation terminates the initial HTTP session but, crucially, preserves the underlying TCP/IP connection ('983 Patent, col. 9:11-21). A new, "flipped" HTTP session is then created over that same preserved connection, where the original server now acts as a client, and the original client acts as a server, enabling the original server to initiate communication ('983 Patent, Abstract; col. 10:25-40). Figure 9 illustrates this process, showing a client sending an "HTTP FLIP REQUEST" (504) and, after negotiation, creating a new session with a "REVERSED ROLE" (514).
• Technical Importance: This method was designed to enable true peer-to-peer communication using the ubiquitous and firewall-friendly HTTP protocol, overcoming its inherent client-server asymmetry without resorting to inefficient polling techniques ('983 Patent, col. 3:20-24).

Key Claims at a Glance

• The complaint alleges infringement of one or more claims without specifying them, referring to "the Exemplary '983 Patent Claims" (Compl. ¶11). Independent claim 1 is representative of the core invention.
• Essential elements of Independent Claim 1 (Method):
  • First and second network nodes engaging in an asymmetric HTTP transactional session with an underlying network connection, with each node having distinct initial roles (HTTP server or client).
  • Terminating the asymmetric HTTP transactional session while maintaining the underlying network connection.
  • The first and second network nodes negotiating transactional role reversal.
  • The nodes further communicating under a reversed asymmetric transactional protocol where each node enacts the initial transactional role of the other.
  • The session uses a network connection that traverses hardware enforcing asymmetric communication.

III. The Accused Instrumentality

Product Identification

• The complaint does not name any specific accused product or service (Compl. ¶11, 13). It refers generally to "Defendant products identified in the charts incorporated into this Count below" and "Exemplary Defendant Products" (Compl. ¶11, 13). The referenced charts are not included in the provided complaint document.

Functionality and Market Context

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

IV. Analysis of Infringement Allegations

The complaint alleges 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). It states that claim charts are included in an "Exhibit 2," which is incorporated by reference but was not filed with the complaint (Compl. ¶13, 14). Without these charts or more specific allegations, a detailed infringement analysis is not possible.

No probative visual evidence provided in complaint.

Identified Points of Contention

Based on the technology and the nature of modern web platforms, several points of contention may arise.

• Technical Questions: A primary factual question will be whether the accused products, once identified, actually perform the claimed steps of terminating an initial HTTP session, explicitly "negotiating" a role reversal, and then creating a new "reversed" session while preserving the original underlying TCP connection. Modern technologies like WebSockets or long-polling achieve bi-directional communication, and a key issue will be whether their operation maps to the specific sequence of steps required by the claims.
• Scope Questions: The case may turn on whether the accused products' communication protocols fall within the scope of the claims. For instance, does a persistent connection that allows for server-pushed data, without the explicit termination and role-reversal negotiation described in the patent, constitute "negotiating transactional role reversal" as claimed?

V. Key Claim Terms for Construction

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

Context and Importance

This term is the central inventive step of the method. Its definition will determine whether modern bi-directional communication protocols, which may not use the explicit "FLIP" mechanism described in the patent, can be found to infringe. Practitioners may focus on this term to dispute whether the accused functionality constitutes "negotiating" a "reversal" or is simply a different, non-infringing method for bi-directional data flow.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: The claim language itself does not specify a particular mechanism for negotiation. Plaintiff may argue that any protocol exchange that results in the original server gaining the ability to initiate communication constitutes "negotiating transactional role reversal."
• Evidence for a Narrower Interpretation: The specification repeatedly describes a specific process, illustrated in Figures 9 and 10, involving an explicit "HTTP FLIP REQUEST" sent from the client (col. 10:61-64; Fig. 9, step 504) and a decision to "ACCEPT" by the server (Fig. 10, step 536). Defendant may argue that "negotiating" requires this specific, disclosed request-and-acceptance handshake, and that the term should be limited to such embodiments.

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 creating two independent connections. The infringement analysis will depend on whether an accused product can be shown to perform this specific two-part step: ending the application-layer (HTTP) session while consciously preserving the transport-layer (TCP) connection for reuse in a reversed role.

Intrinsic Evidence for Interpretation

• Evidence for a Broader Interpretation: Plaintiff could argue that any technical process where the initial client-request/server-response state is concluded, and the underlying socket is repurposed for server-initiated messages, meets this limitation, regardless of the specific commands used.
• Evidence for a Narrower Interpretation: The detailed description states that "nodes 112a and 112b terminate, let terminate, or other wise abandon session 150 of HTTP layer 116 ... [but] maintain, however, the underlying network connection" (col. 9:14-18). The flowcharts also show this as a distinct step (e.g., Fig. 9, step 512). Defendant may argue this requires an explicit act of termination at the HTTP layer, distinct from protocols that might keep the HTTP session technically "open" but dormant.

VI. Other Allegations

Indirect Infringement

• The complaint does not contain any factual allegations to support a claim for indirect infringement (e.g., inducement or contributory infringement). It alleges only direct infringement (Compl. ¶11, 12).

Willful Infringement

• The complaint does not allege facts to support willfulness, such as pre-suit knowledge of the patent. The prayer for relief includes a request for a finding that the case is "exceptional" and for an award of attorneys' fees, which is often associated with willfulness, but the complaint body lacks the necessary factual predicate (Compl., Prayer for Relief ¶E.i).

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

1. An Evidentiary Question of Operation: The central issue will be factual: once the "Exemplary Defendant Products" are identified, what is the specific network communication protocol they employ? Does that protocol involve the discrete, sequential steps of terminating an initial HTTP session, negotiating a role reversal, and establishing a new, reversed HTTP session over the preserved underlying connection, as required by the patent?
2. A Definitional Question of Scope: The case will likely depend heavily on claim construction. Can the term "negotiating transactional role reversal" be construed broadly enough to read on modern bi-directional web technologies like WebSockets or long-polling, or is it limited by the specification's embodiments to an explicit "FLIP" request-and-acceptance protocol?
3. A Pleading Sufficiency Question: Given the complaint’s lack of specificity regarding the accused products and the mechanism of infringement (relying on an unfiled exhibit), an initial question for the court may be whether the complaint meets the pleading standards articulated by the Supreme Court in Iqbal and Twombly.