1:21-cv-00089
Wave Linx LLC v. Masergy Communications Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Wave Linx LLC (Texas)
- Defendant: Masergy Communications, Inc. (Delaware)
- Plaintiff’s Counsel: Chong Law Firm PA; Sand, Sebolt & Wernow Co., LPA
- Case Identification: 1:21-cv-00089, D. Del., 01/27/2021
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is incorporated in Delaware and maintains a regular and established place of business in the district.
- Core Dispute: Plaintiff alleges that Defendant’s Masergy Receptionist Client, a communications service, infringes a patent related to methods for delivering real-time notifications from a telephone system to an internet-connected device.
- Technical Context: The technology addresses the convergence of traditional public switched telephone networks (PSTN) and internet protocol (IP) networks, specifically concerning the real-time display of telephony events (like an incoming call) within a standard web browser.
- Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2002-03-27 | U.S. Patent No. 8,843,549 Priority Date |
| 2014-09-23 | U.S. Patent No. 8,843,549 Issue Date |
| 2021-01-27 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,843,549 - "Streaming Method for Transmitting Telephone System Notifications to Internet Terminal Devices in Real Time"
- Patent Identification: U.S. Patent No. 8,843,549, "Streaming Method for Transmitting Telephone System Notifications to Internet Terminal Devices in Real Time," issued September 23, 2014.
The Invention Explained
- Problem Addressed: The patent addresses the technical challenge of integrating traditional telephone systems with web-based applications. Prior solutions for monitoring telephone events (e.g., incoming calls) on a computer were often proprietary, complex, and lacked interoperability, creating a poor user experience compared to standard telephone services (’549 Patent, col. 1:12-28).
- The Patented Solution: The invention proposes a method where a server maintains a persistent connection with a client's web browser using a streaming technique like HTTP streaming. When a telephone system event occurs, a notification is sent to the server. The server transforms this notification into a programming language code (e.g., JavaScript, HTML) and pushes it to the client's browser over the open connection. The browser then executes this code to display the notification in real-time without requiring the user to reload the web page or install special plugins (’549 Patent, Abstract; col. 2:40-67). Figure 1 illustrates the system architecture, showing a conference server (CtC) mediating between a telephone switch (TS) and an internet-connected PC client (PC(CC)).
- Technical Importance: This method leverages standardized web protocols (like HTTP) to create a more seamless, low-overhead bridge between telephony infrastructure and web applications, simplifying the process of building real-time, browser-based communication tools (’549 Patent, col. 2:2-8).
Key Claims at a Glance
- The complaint asserts independent claim 1 and dependent claim 4 (Compl. ¶17).
- Independent Claim 1 recites a method with the following essential elements:
- opening a connection between the client and a server;
- transmitting notification messages from the telephone switching system to the server using a networking protocol;
- transforming the notification messages at the server into a programming language code executable by the client's browser and sending it to the client;
- using an HTTP streaming mechanism for transmission through the open connection, which remains open between individual notification messages; and
- executing the programming language codes by the browser to display or output the notification messages at the client.
- The complaint does not explicitly reserve the right to assert other claims but notes its infringement theories may be modified (Compl. ¶33).
III. The Accused Instrumentality
Product Identification
- The "Masergy Receptionist Client" (the "Accused Product") (Compl. ¶18).
Functionality and Market Context
- The Accused Product is described as practicing a method for real-time notification of a client by a telephone switching system (Compl. ¶18). Specifically, it is alleged to provide notifications for incoming phone calls, originating from a "traditional phone switching network," to a user operating a web-browser based version of the client (Compl. ¶¶18, 20-21). The complaint alleges the product functions by opening a connection to a server upon user login, receiving call notifications at the server, transforming them into code, and streaming them to the user's web browser (e.g., Google Chrome) for display (Compl. ¶¶19-23).
IV. Analysis of Infringement Allegations
The complaint references an "Exhibit B" claim chart that was not attached to the publicly filed document (Compl. ¶18). The following analysis is based on the narrative allegations in the complaint body.
No probative visual evidence provided in complaint.
’549 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a) opening a connection between the client and a server; | The Accused Product opens a connection between the client and a server when a user logs into their Masergy Receptionist account. | ¶19 | col. 2:42-43 |
| b) transmitting notification messages from the telephone switching system to the server using a networking protocol; | Notification messages for calls originating from a "traditional phone switching network" are transmitted to the Masergy Receptionist Client's server using a networking protocol like IP. | ¶20 | col. 2:48-51 |
| c) transforming the notification messages at the server into a programming language code and using said networking protocol for sending the programming language code to the client, wherein the programming language code is executable by the client's browser; | At the server, incoming phone call notifications are transformed into a "markup language code such as HTML code," which is then sent to the "web-browser based version of the Masergy Receptionist Client." The complaint alleges this code is executable by the user's web browser. | ¶21 | col. 2:55-61 |
| d) using an HTTP streaming mechanism for transmission of the notification from the server to the browser through the open connection, whereby the connection...remains open in the intervening period...; | An "HTTP streaming" mechanism is used for transmission from the server to the browser (e.g., Google Chrome) through an open connection. This connection is described as "a chat or a call queue which supports transmission and storage of notifications" and remains open between messages. | ¶22 | col. 2:61-65 |
| e) executing the programming language codes by the browser whereby the respective notification messages are displayed or outputted at the client. | The browser (e.g., Google Chrome) executes the programming language codes (e.g., HTML code) to cause the notification to be displayed or a sound to be played at the client. | ¶23 | col. 2:65-67 |
- Identified Points of Contention:
- Technical Questions: The complaint alleges the use of an "HTTP streaming" mechanism, further described as "a chat or a call queue" (Compl. ¶22). A central question will be whether the specific technical implementation of this feature in the Accused Product meets the definition of an "HTTP streaming mechanism" as required by the claim. The patent describes this in the context of dynamic HTML and Java servlets that "push" data to the client to avoid page reloads (’549 Patent, col. 4:12-18, 4:50-54). Discovery will likely focus on the precise protocol and behavior of the accused "chat or a call queue."
- Scope Questions: Claim 1c requires transforming messages into a "programming language code" that is "executable by the client's browser." The complaint alleges this is met by "markup language code such as HTML code" (Compl. ¶21). This raises the question of whether HTML, a declarative markup language, qualifies as an "executable" "programming language code" in the context of the patent, which also explicitly references more functional languages like JavaScript (’549 Patent, col. 2:59-60).
V. Key Claim Terms for Construction
The Term: "HTTP streaming mechanism"
Context and Importance: This term is central to the invention's method of maintaining a persistent, low-overhead connection for real-time updates. The infringement analysis will depend on whether the Accused Product's "chat or a call queue" functionality (Compl. ¶22) falls within the scope of this term. Practitioners may focus on this term because modern web communication technologies (e.g., WebSockets, long-polling) have evolved since the patent's priority date, and the construction will determine whether these newer, analogous technologies are covered.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent suggests that the specific protocol is not rigidly fixed, stating that while HTTP is preferred, "other choices such as TCP...UDP...RMI...etc. are possible" for streaming (’549 Patent, col. 4:2-5). This could support an argument that the term encompasses any mechanism that achieves a persistent push-style connection, not just a specific "HTTP streaming" implementation.
- Evidence for a Narrower Interpretation: The specification describes the mechanism in the context of "dynamic HTML (DHTML)" and a Java servlet or "pushlet" that sends code to the client (’549 Patent, col. 4:10-15). It also discloses sending a periodic "keep alive" response to the client to ensure the connection remains open (’549 Patent, col. 4:47-52). A party could argue these details define a more specific type of mechanism than any generic long-lived HTTP connection.
The Term: "programming language code"
Context and Importance: The complaint alleges that "markup language code such as HTML code" satisfies this limitation (Compl. ¶21). The viability of the infringement claim hinges on whether HTML is considered a "programming language code" that is "executable" as required by claim 1.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification explicitly lists "JavaScript, XML, HTML or Java-serialised objects" as examples of computer code that can be executed by the client's browser (’549 Patent, col. 4:63-65). The inclusion of "HTML" in this list provides direct support for the plaintiff’s position that the patentees considered it to fall within the claim's scope.
- Evidence for a Narrower Interpretation: A defendant may argue that in the context of the patent, "executable" implies performing a function or logic, a characteristic more associated with JavaScript than HTML. The patent describes using the code to "dynamically manipulate the elements of the DOM" (’549 Patent, col. 4:21-24), a task typically performed by a scripting language like JavaScript, not by HTML itself. This could support an argument that while HTML is listed as an example, the full context requires a code with more functionality than plain markup.
VI. Other Allegations
- Indirect Infringement: The complaint includes a single count for "INFRINGEMENT OF THE '549 PATENT" and contains a conclusory statement that "Defendant directly infringed the '549 Patent" (Compl. ¶27). The complaint does not plead specific facts to support a separate theory of indirect infringement, such as allegations of providing instructions or encouragement to third parties to perform the infringing method.
- Willful Infringement: The complaint alleges Defendant had knowledge of its infringement "at least as of the service of the present Complaint" (Compl. ¶28). This allegation, if proven, would only support a claim for post-filing willfulness and does not assert pre-suit knowledge of the patent.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of claim construction: Can the term "programming language code," which the claim requires to be "executable," be construed to cover the "HTML code" allegedly generated by the accused system? While the specification lists HTML as an example, its primary function as a declarative markup language may be contrasted with the dynamic, executable nature implied by other parts of the patent.
- A second key issue will be one of technical scope: Does the accused "chat or a call queue" (Compl. ¶22) function as the "HTTP streaming mechanism" described in the patent? The court will need to determine if there is a substantive technical match or if the accused system uses a fundamentally different web communication technology that falls outside the boundaries of the claims as properly construed.
- Finally, an evidentiary question will be what proof Plaintiff can adduce to show that the accused system actually performs the "transforming" step as claimed. The complaint's allegations will need to be substantiated with evidence showing that the server receives a specific "notification message" from a "telephone switching system" and converts it into the code sent to the browser, rather than generating the code through a different process.