1:25-cv-00945
Unwired Global Systems LLC v. Lockly Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Unwired Global Systems LLC (Delaware)
- Defendant: Lockly Inc. (Delaware)
- Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
- Case Identification: 1:25-cv-00945, D. Del., 07/29/2025
- Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is incorporated in Delaware, has an established place of business in the District, has committed acts of alleged patent infringement in the District, and caused harm to the Plaintiff in the District.
- Core Dispute: Plaintiff alleges that Defendant’s unspecified products infringe a patent related to a middleware interface for translating data between different communication protocols in a network environment.
- Technical Context: The technology concerns methods for allowing devices using disparate network protocols (e.g., smart home devices) to communicate with each other and with central servers by translating their data into a common, platform-independent format.
- 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 |
|---|---|
| 2009-09-23 | ’624 Patent Priority Date |
| 2010-09-22 | ’624 Patent Application Filing Date |
| 2013-07-16 | ’624 Patent Issue Date |
| 2025-07-29 | 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 addresses the problem of integrating household devices that use various, often low-power, communication protocols (like ZigBee or Bluetooth) with home networks that typically use a different protocol like TCP/IP (’624 Patent, col. 1:30-41). Directly connecting these devices requires significant programming overhead and computing power to manage multiple protocol stacks, which is inefficient (’624 Patent, col. 1:47-59).
- The Patented Solution: The invention proposes a middleware system, termed a "frame engine," that acts as a universal translator (’624 Patent, Fig. 1). This engine receives a data packet in a device's native protocol, uses a set of "protocol frame definitions" and "field classes" to decode it into a "platform independent data object," and can then re-encode that object for transmission using a different protocol (’624 Patent, col. 2:1-12; col. 3:11-20). This decouples the application logic from the specific communication protocols of the end devices.
- Technical Importance: This approach aimed to simplify the development of "smart home" or Internet of Things (IoT) applications by creating a standardized interface, allowing a single driver program to communicate with a wide variety of devices without needing to understand the specifics of each device's native communication protocol (’624 Patent, col. 1:55-63).
Key Claims at a Glance
- The complaint asserts infringement of "one or more claims" without specifying which ones (Compl. ¶11). The patent contains three independent claims: 1 (a method), 8 (a computer apparatus), and 12 (a computer network).
- 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.
- The complaint does not explicitly reserve the right to assert dependent claims, but the broad allegation of infringing "one or more claims" suggests this possibility.
III. The Accused Instrumentality
Product Identification
The complaint does not identify any specific accused products by name. It refers generally to "Exemplary Defendant Products" and "numerous other devices" made, used, or sold by Defendant (Compl. ¶11).
Functionality and Market Context
The complaint alleges that the "Exemplary Defendant Products" practice the technology claimed by the ’624 Patent (Compl. ¶16). Based on the nature of the patent, the accused functionality would involve products or systems that receive data from networked devices (such as smart locks), process or translate that data, and communicate it over another network (e.g., to a user's smartphone app via the internet). The complaint does not provide sufficient detail for analysis of the accused products' specific functionality, technical operation, or market context.
IV. Analysis of Infringement Allegations
The complaint does not contain an embedded claim chart or provide the referenced "Exhibit 2," which allegedly contains charts comparing the patent claims to the accused products (Compl. ¶16-17). The complaint's infringement theory is therefore based on conclusory allegations that the "Exemplary Defendant Products" practice the claimed technology and "satisfy all elements of the Exemplary '624 Patent Claims" (Compl. ¶16). Without access to the specific product details or the claim charts in Exhibit 2, a detailed element-by-element analysis of the infringement allegations is not possible based on the provided documents.
- Identified Points of Contention:
- Scope Questions: A central question will be how the accused products perform the claimed "decoding" and "encoding" steps. The dispute may focus on whether the accused systems use a "machine-readable set of protocol frame definitions" as described in the patent, or if they use a different, less structured method for data translation.
- Technical Questions: What evidence does Plaintiff possess that Defendant's products contain a component that functions as the claimed "frame engine" and utilize "platform independent data objects"? The case may turn on whether Defendant's internal software architecture maps onto the specific structures required by the claims, such as the use of "field classes" to define data types (’624 Patent, col. 4:21-34).
No probative visual evidence provided in complaint.
V. Key Claim Terms for Construction
The Term: "machine-readable set of protocol frame definitions" (Claim 1)
Context and Importance: This term is the core of the claimed invention's mechanism for translating data. The outcome of the case may depend on whether Defendant's method for data translation falls within the scope of this term. Practitioners may focus on this term because its construction will determine whether a simple data map or a more complex, structured definition file is required to infringe.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent suggests the definitions can be configured from various sources, including "XML metadata," an "API," or even "embedded inside cluster definition files," which may support a broader interpretation that is not limited to a specific file format (’624 Patent, col. 7:28-35).
- Evidence for a Narrower Interpretation: The specification provides detailed examples where definitions are located in specific files (e.g.,
C:\glue-1.0.0\frames\zcl\header.xml) and are parsed using a specific algorithm, which could support a narrower construction requiring a hierarchical file structure or an XML-based implementation (’624 Patent, col. 6:36-44).
The Term: "platform independent data objects" (Claim 1)
Context and Importance: This term describes the intermediate state of the data after it has been decoded from its native protocol. Infringement will depend on whether the data objects in the accused system are truly "platform independent."
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent abstract describes them simply as "a set of platform independent data objects," which could be argued to cover any data representation not tied to a specific hardware architecture (’624 Patent, Abstract).
- Evidence for a Narrower Interpretation: The specification repeatedly uses JAVA as the exemplary "native language" for these objects, stating that "the platform independence of the data representation is due to the platform independence of Java's data representation" (’624 Patent, col. 4:63-66). This could be used to argue that the term requires a data representation with properties similar to those provided by the Java Virtual Machine.
VI. Other Allegations
- Indirect Infringement: Plaintiff alleges induced infringement, stating that Defendant distributes "product literature and website materials" that instruct end users on how to use the products in a manner that infringes the ’624 Patent (Compl. ¶14-15).
- Willful Infringement: Willfulness is alleged based on knowledge of the patent gained "at least since being served by this Complaint" (Compl. ¶15). This is a claim of post-filing willfulness, as no pre-suit knowledge is alleged.
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of definitional scope: does the accused system's method for translating data between protocols meet the specific structural requirements of a "machine-readable set of protocol frame definitions" as taught in the patent, or does it operate on a different principle?
- A key evidentiary question will be one of architectural mapping: can Plaintiff demonstrate, through discovery and technical analysis, that the software architecture of Lockly’s products contains distinct components that function as the claimed "frame engine" and that it processes data into "platform independent data objects", as opposed to using a more monolithic or integrated data processing pipeline?
- Given the complaint's lack of specificity, a threshold question will be identification: which specific Lockly products, services, and software versions are accused of infringement, and what is the direct evidence of their internal operation?