DCT

1:23-cv-08335

Unwired Global Systems LLC v. Belden Inc

Key Events
Complaint
complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:23-cv-08335, E.D.N.Y., 11/09/2023
  • Venue Allegations: Venue is asserted based on Defendant having an established place of business in the district.
  • Core Dispute: Plaintiff alleges that unspecified products made by Defendant infringe a patent related to a middleware interface for translating data between different communication protocols in a network.
  • Technical Context: The technology addresses the problem of enabling devices using different communication protocols (e.g., ZigBee, Bluetooth) to communicate with a central computer or network that uses a different protocol (e.g., TCP/IP), particularly in home automation networks.
  • Key Procedural History: The complaint does not mention any prior litigation, 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
2023-11-09 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 low-power household devices (using protocols like ZigBee or Bluetooth) with home networks that typically run on TCP/IP. Connecting these disparate systems requires significant programming overhead and computing power, as a driver program must execute an additional, device-specific protocol stack to communicate ('624 Patent, col. 1:29-58).
  • The Patented Solution: The invention proposes a "protocol-neutral middleware interface" that acts as a universal translator. A "frame engine" on a routing computer receives a data packet in a device's native protocol, uses a "machine-readable set of protocol frame definitions" to decode it into a standardized, "platform independent data object," and can then encode that object into a different protocol for transmission elsewhere ('624 Patent, col. 2:1-13; Fig. 1). This abstracts the protocol-specific details, allowing applications to interact with device data in a uniform way without needing to understand the underlying communication method ('624 Patent, col. 4:38-50).
  • Technical Importance: This middleware approach sought to simplify the development of "smart home" or "Internet of Things" applications by creating a common software layer, reducing the need for custom drivers for each new type of device or protocol ('624 Patent, col. 1:55-63).

Key Claims at a Glance

  • The complaint asserts "exemplary claims" identified in a non-provided exhibit (Compl. ¶11). Independent claim 1 is representative.
  • Independent Claim 1: A method for implementing a network interface, comprising the steps of:
    • 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 refers generally to infringement of "one or more claims" (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

  • The complaint does not identify any specific accused products by name. It refers to "Defendant products identified in the charts incorporated into this Count" and "Exemplary Defendant Products" (Compl. ¶11). These charts are part of Exhibit 2, which was not filed with the complaint.

Functionality and Market Context

  • The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality or market context. No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint alleges direct and indirect infringement but relies entirely on claim charts in an unprovided "Exhibit 2" to substantiate these claims (Compl. ¶¶ 16, 17). The body of the complaint itself contains no factual allegations describing how any specific feature of a Belden product meets any specific limitation of the asserted patent claims. Therefore, a claim chart summary cannot be constructed and an analysis of the specific infringement theory is not possible based on the provided documents.

  • Identified Points of Contention: Lacking specific infringement allegations, any analysis is speculative. However, a dispute would likely center on the following questions:
    • Scope Questions: Do the accused products, in fact, perform both decoding from a first protocol and encoding into a second protocol as required by claim 1? A system that only receives and processes data in a single protocol may not meet all claim limitations.
    • Technical Questions: Do the accused products utilize a "machine-readable set of protocol frame definitions" that contain "sub-fields for parsing"? The infringement analysis will depend on whether the defendant's software architecture can be characterized as matching the patent's specific "frame engine" and "field class" structure ('624 Patent, col. 7:12-34), or if it uses a technically distinct method for protocol translation.

V. Key Claim Terms for Construction

  • The Term: "machine-readable set of protocol frame definitions"

    • Context and Importance: This term is the core of the claimed invention, representing the "translation key" or rule set used by the frame engine. The case will likely hinge on whether the accused products' internal data structures or configuration files meet this definition. Practitioners may focus on this term because its scope determines whether the claim covers only the specific XML-based metadata structure described in the patent or a broader class of protocol translation rule sets.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The claim language itself is broad, not limiting the "definitions" to a specific format. The specification states that while embodiments are configured from XML, definitions "can also be configured via API" ('624 Patent, col. 7:29-31), suggesting the form is not strictly limited.
      • Evidence for a Narrower Interpretation: The detailed description repeatedly and consistently describes these definitions as being derived from "XML metadata" and organized into files within specific directory structures (e.g., "frames" and "clusters" directories) ('624 Patent, col. 7:31-35; col. 8:40-49). This could support a narrower construction tied to this specific implementation.
  • The Term: "platform independent data objects"

    • Context and Importance: This term describes the output of the decoding step and the input for the encoding step. Infringement requires that the accused system creates this specific type of intermediate data structure. The dispute will be whether the defendant's internal data representation qualifies as "platform independent."
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The term itself implies a functional quality—that the data object is not tied to a specific hardware architecture or operating system. An argument could be made that any standardized, intermediate data format meets this limitation.
      • Evidence for a Narrower Interpretation: The specification explicitly ties the concept to the Java language, stating, "the platform independence of the data representation is due to the platform independence of Java's data representation" and notes that in other languages, the "working' data representation...would not necessarily be platform independent" ('624 Patent, col. 4:62-67). This provides a strong basis for arguing the term requires a Java-like level of platform independence.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges inducement based on Defendant distributing "product literature and website materials inducing end users...to use its products in the customary and intended manner that infringes the '624 Patent" (Compl. ¶14). The alleged inducement is based on knowledge acquired "at least since being served by this Complaint" (Compl. ¶15).
  • Willful Infringement: The complaint does not use the word "willful" but pleads the legal equivalent. It alleges that Defendant has "actual knowledge" of infringement from the service of the complaint and attached claim charts, and that despite this knowledge, it "continues to make, use, test, sell, offer for sale, market, and/or import" infringing products (Compl. ¶¶ 13, 14). This forms a basis for post-suit enhanced damages.

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

  1. Evidentiary Sufficiency: The primary initial question is whether the complaint, which relies solely on an unprovided exhibit for its factual basis for infringement, can survive a motion to dismiss. The court will have to assess if merely referencing external (and unavailable) claim charts satisfies pleading standards.
  2. Definitional Scope: Assuming the case proceeds, a central issue will be one of claim construction: how broadly will the court define "machine-readable set of protocol frame definitions"? The outcome may depend on whether the term is construed narrowly to cover the patent's specific XML-based file structure or more broadly to encompass any rule-based system for protocol translation.
  3. Technical Equivalence: A key factual question will be one of operational function: do the accused Belden products actually create an intermediate "platform independent data object" as a distinct step between receiving data in one protocol and transmitting it in another, or do they employ a different, more direct translation architecture that falls outside the scope of the claims?