Unwired Global Systems LLC v. US LED Ltd

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Unwired Global Systems LLC (Delaware)
  • Defendant: US LED, Ltd. (Texas)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:24-cv-872, S.D. Tex., 10/29/2024
• Venue Allegations: Plaintiff alleges venue is proper because Defendant is a foreign corporation, has committed acts of patent infringement in the district, and has caused harm there.
• Core Dispute: Plaintiff alleges that certain of Defendant's products infringe a patent related to a middleware interface for translating data between different communication protocols in an area network.
• Technical Context: The technology addresses the challenge of interoperability in "smart home" or Internet of Things (IoT) environments, where devices using diverse, low-power protocols must communicate with systems using standard network protocols like TCP/IP.
• Key Procedural History: The complaint alleges that Plaintiff is the assignee of the patent-in-suit. No other prior litigation, licensing, or administrative proceedings are mentioned.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,488,624 - “Method and apparatus for providing an area network middleware interface”

The Invention Explained

• Problem Addressed: The patent addresses the technical problem of integrating household devices that use various, often incompatible, communication protocols (e.g., ZigBee, Bluetooth) with home networks that typically use TCP/IP. Directly bridging these systems requires significant programming overhead and computing power, as developers must create and manage multiple protocol stacks (’624 Patent, col. 1:30-57).
• The Patented Solution: The invention proposes a "protocol-neutral middleware interface" that acts as a universal translator (’624 Patent, Abstract). A central "frame engine" receives a data packet in a "first communication protocol," decodes it into a set of "platform independent data objects" by using a "machine-readable set of protocol frame definitions," and can then re-encode those objects for a "second communication protocol" (’624 Patent, col. 11:8-21). This middleware abstracts the specific protocol details, allowing applications to interact with diverse devices in a standardized way (’624 Patent, col. 4:39-44).
• Technical Importance: This approach aimed to simplify the development of "smart home" applications by providing a single, unified interface, thereby reducing the need for substantial computing capability and complex, protocol-specific driver programming (’624 Patent, col. 1:55-62).

Key Claims at a Glance

• The complaint asserts infringement of one or more "Exemplary '624 Patent Claims" without specifying them (Compl. ¶11). The patent contains two independent claims, Claim 1 (method) and Claim 8 (apparatus).
• Independent Claim 1 (Method):
  • receiving one or more data packets encoded in a first communication protocol;
  • decoding the data packets into a set of data objects wherein the data packets are decoded in accordance with a machine-readable set of protocol frame definitions containing one or more sub-fields for parsing of the data packets; and
  • encoding the data objects into a second communication protocol wherein the data objects are encoded in accordance with the machine-readable set of protocol frame definitions.
• Independent Claim 8 (Apparatus):
  • A computer apparatus with a processor, support circuit, and storage device storing instructions for:
  • a frame engine to receive and decode a data packet from a first communication protocol;
  • a machine-readable set of protocol frame definitions with sub-fields for decoding the packet into a set of data objects; and
  • a second machine-readable set of protocol frame definitions for encoding the data objects into a second communication protocol.
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

• The complaint does not name specific accused products. It refers to "Exemplary Defendant Products" that are identified in charts within an Exhibit 2, which was not provided for this analysis (Compl. ¶11, ¶16).

Functionality and Market Context

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

IV. Analysis of Infringement Allegations

The complaint incorporates by reference claim charts from an attached Exhibit 2, which was not provided with the complaint materials for this analysis (Compl. ¶17). Therefore, a claim-chart summary cannot be constructed. The complaint's infringement theory rests on the general allegation that the "Exemplary Defendant Products practice the technology claimed by the '624 Patent" (Compl. ¶16).

• Identified Points of Contention:
  • Scope Questions: A central question will concern the scope of "machine-readable set of protocol frame definitions." The dispute may focus on whether the accused products' internal data structures and translation rules, whatever their format, meet this claimed limitation, or if the term is limited to the specific file-based, hierarchical structures described in the patent's embodiments (’624 Patent, col. 8:35-44).
  • Technical Questions: Evidentiary questions will arise as to whether the accused products perform the distinct steps of "decoding" data from a first protocol into a protocol-neutral format and then "encoding" that data for a second protocol, as required by the claims (’624 Patent, col. 11:12-21). The analysis will require evidence of the accused software's internal architecture and data-handling processes.

No probative visual evidence provided in complaint.

V. Key Claim Terms for Construction

• The Term: "machine-readable set of protocol frame definitions" (Claim 1, 8)
• Context and Importance: This term describes the core mechanism of the invention: the set of rules used to translate data between protocols. Its construction will be critical to the infringement analysis, as it will determine what types of software architectures and data structures fall within the claim scope. Practitioners may focus on this term because the infringement case depends on whether the accused products' method for handling data interoperability can be characterized as using such "definitions."
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification suggests these definitions can be configured from various sources, including "XML metadata," an "API," a "relational database," or a "web server," which could support a broad interpretation covering any organized set of rules for data parsing and encoding, regardless of its specific format (’624 Patent, col. 8:27-34, col. 8:50-54).
  • Evidence for a Narrower Interpretation: The patent provides detailed embodiments that use a specific, hierarchical file structure (e.g., "frames\spi2\AF_INCOMING_MSG.xml") and explicit XML tags to define fields and their properties (’624 Patent, col. 8:35-44; col. 10:45-48). A party could argue that the term should be limited to such structured, file-based definition systems, particularly given the claim's requirement for "one or more sub-fields" (’624 Patent, col. 11:16-17).

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, asserting that since being served with the complaint, Defendant has had knowledge of the ’624 Patent (Compl. ¶15). The allegedly inducing acts include selling the accused products and distributing "product literature and website materials" that instruct end-users on how to use the products in an infringing manner (Compl. ¶14-15).
• Willful Infringement: The complaint does not use the word "willful" but alleges facts that could support such a claim. It asserts that service of the complaint provides Defendant with "actual knowledge of infringement" and that Defendant continues to infringe despite this knowledge (Compl. ¶13-14). The prayer for relief seeks enhanced damages under 35 U.S.C. § 284 (Compl. Prayer for Relief ¶D).

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

• A core issue will be one of definitional scope: How broadly will the court construe the term "machine-readable set of protocol frame definitions"? Will it be limited to the specific XML-based, hierarchical file structures shown in the patent's embodiments, or can it encompass any set of software rules that governs data translation between protocols?
• A key evidentiary question will be one of technical implementation: Assuming a claim construction is established, what evidence will Plaintiff be able to produce from the accused products' source code and technical documentation to demonstrate that they actually perform the claimed "decoding" and "encoding" using a structure that meets the court's definition of "protocol frame definitions"? The case will likely turn on a technical comparison of the patent's disclosed architecture and the accused systems' internal operations.