1:23-cv-01170
Unwired Global Systems LLC v. Rigado Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Unwired Global Systems LLC (Delaware)
- Defendant: Rigado Inc. (Delaware)
- Plaintiff’s Counsel: Phillips, McLaughlin & Hall, P.A.; Rabicoff Law LLC
- Case Identification: 1:23-cv-01170, D. Del., 10/17/2023
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is incorporated in Delaware and maintains an established place of business in the District.
- Core Dispute: Plaintiff alleges that Defendant’s networking products infringe a patent related to a middleware interface for translating data between different communication protocols.
- Technical Context: The technology addresses the challenge of interoperability in the Internet of Things (IoT) and home automation fields, where numerous devices using disparate, low-power protocols must communicate with systems on standard IP-based networks.
- Key Procedural History: The complaint is the initial pleading in this litigation. It does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2009-09-23 | '624' Patent Priority Date |
| 2013-07-16 | '624 Patent Issue Date |
| 2023-10-17 | Complaint Filing Date |
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"
- Issued: July 16, 2013
The Invention Explained
- Problem Addressed: The patent describes the difficulty of integrating household devices that use various specialized, low-power communication protocols (such as ZigBee or Bluetooth) with general-purpose computer networks that typically use TCP/IP. Creating software drivers to translate between these different protocols for each device is complex, requiring significant programming overhead and computing capability on a central hub or computer ('624 Patent, col. 1:30-53).
- The Patented Solution: The invention proposes a "protocol-neutral middleware interface" centered on a "frame engine." This engine receives a data packet from a device using a first protocol. It then uses a "machine-readable set of protocol frame definitions"—essentially a metadata map—to decode the protocol-specific data into a standardized, "platform independent data object" ('624 Patent, Abstract; col. 4:18-24). This standardized object can then be easily accessed by software applications or encoded into a second communication protocol for transmission on a different network, abstracting away the underlying protocol complexities ('624 Patent, col. 3:11-20).
- Technical Importance: This approach aims to simplify the development of applications for the home automation and IoT markets by creating a common translation layer, reducing the need for custom drivers for every new device protocol ('624 Patent, col. 1:53-63).
Key Claims at a Glance
The complaint does not specify which claims it asserts, referring only to the "Exemplary '624 Patent Claims" identified in a non-proffered exhibit (Compl. ¶11). Independent apparatus claim 8 is representative of the patented system.
- Independent Claim 8:
- A computer apparatus comprising a processor, support circuit, and a storage device storing processor-executable instructions.
- The instructions include a "frame engine" to receive and decode a data packet transmitted in a first communication protocol.
- The instructions also include a "machine-readable set of protocol frame definitions" with sub-fields for decoding the packet into a set of data objects.
- A second set of frame definitions is included for encoding the data objects into a second communication protocol.
III. The Accused Instrumentality
Product Identification
The complaint does not identify any specific accused products by name in the main pleading. It refers generally to "Exemplary Defendant Products" that are purportedly identified in claim charts attached as Exhibit 2 (Compl. ¶11). This exhibit was not included with the public filing.
Functionality and Market Context
The complaint alleges that the accused products "practice the technology claimed by the '624 Patent" (Compl. ¶16). Based on this allegation, the accused instrumentalities are networking hardware and/or software that receive data in one communication format and make it available for use in another, consistent with the middleware interface technology of the patent. The complaint does not provide further detail on the specific functionality or market positioning of the accused products.
IV. Analysis of Infringement Allegations
The complaint’s substantive infringement allegations are made by incorporating by reference an external document, "Exhibit 2," which purportedly contains "charts comparing the Exemplary '624 Patent Claims to the Exemplary Defendant Products" (Compl. ¶¶ 16-17). As this exhibit was not provided, the complaint itself contains no specific factual allegations mapping features of the accused products to the limitations of any asserted patent claim.
Identified Points of Contention
- Pleading Sufficiency: A primary procedural question is whether a complaint that contains no factual infringement theory in its body and relies entirely on an external, unprovided exhibit meets the plausibility pleading standards required by Federal Rule of Civil Procedure 8, as interpreted by the Supreme Court in Bell Atlantic Corp. v. Twombly and Ashcroft v. Iqbal. The court will have to determine if the complaint provides the defendant with fair notice of the infringement claims against it.
- Technical Evidence: A central evidentiary question, once the specific allegations are presented, will be whether Plaintiff can demonstrate that the architecture of Defendant’s products embodies the specific "frame engine" and "machine-readable...protocol frame definitions" structure required by the claims, or if the products operate on a fundamentally different technical principle.
V. Key Claim Terms for Construction
Key Term: "frame engine"
- Context and Importance: This term, recited in claim 8 and central to the specification, appears to be the core software component that performs the claimed decoding and encoding. Its construction will be critical to determining infringement, as the dispute may turn on whether the accused software architecture includes a component that meets the structural and functional requirements of a "frame engine."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states that the frame engine's basic function is to provide access to a data packet using a "frame" data structure and that it can be implemented as part of a larger network routing program or as a separate application, suggesting it is not limited to one specific implementation ('624 Patent, col. 4:47-60).
- Evidence for a Narrower Interpretation: The specification describes the frame engine as executing specific operations, such as performing a dynamic lookup to translate offsets into an identifier and using that identifier to decode data, and "chaining" decoders for nested data structures ('624 Patent, col. 5:57-62; col. 9:40-44). A party could argue these specific operations are required features of a "frame engine."
Key Term: "machine-readable set of protocol frame definitions"
- Context and Importance: This term defines the data structure or metadata that the "frame engine" uses to perform the protocol translation. The infringement analysis will depend on whether the method used by the accused products to store and access translation rules qualifies as this claimed set of "definitions."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent suggests these definitions can come from various sources, including a "relational database, a file 'resource' inside of a JAVA Archive (jar) file, or from a web server," which may support a broader interpretation not tied to a single format ('624 Patent, col. 6:50-54).
- Evidence for a Narrower Interpretation: The specification provides detailed examples where the definitions are configured from XML metadata, stored in specific directory structures, and contain nested fields, sub-fields, and decoder references ('624 Patent, col. 6:30-44; col. 7:12-34). An argument could be made that the term requires this level of structured, hierarchical complexity.
VI. Other Allegations
Indirect Infringement
The complaint alleges induced infringement, stating that Defendant sells its products to customers and distributes "product literature and website materials" that instruct end users to use the products in an infringing manner (Compl. ¶¶ 14-15).
Willful Infringement
The complaint alleges that Defendant has had "actual knowledge of infringement" since being served with the complaint and corresponding claim charts (Compl. ¶¶ 13, 15). This allegation appears to be aimed at establishing a basis for post-filing willful infringement rather than pre-suit willfulness.
VII. Analyst’s Conclusion: Key Questions for the Case
- A Threshold Procedural Question: Does a complaint that outsources all factual allegations of infringement to an external, unprovided exhibit satisfy the federal pleading standard under Twombly/Iqbal, or does it fail to provide the defendant with fair notice of the claims?
- A Core Definitional Question: What are the precise structural and functional requirements of the claimed "frame engine" and its associated "machine-readable set of protocol frame definitions"? The case will likely depend on whether the architecture of the accused products can be mapped onto the patent’s specific middleware structure or if they achieve a similar result through a non-infringing design.
- An Evidentiary Question of Operation: Assuming the complaint survives any initial motion to dismiss, a key question will be one of technical evidence: what proof can Plaintiff offer to show that the accused products actually perform the step-by-step decoding and encoding processes as claimed, particularly the use of named, hierarchical "frame definitions" to translate data into a "platform independent data object"?