DCT

2:23-cv-00506

Rokiot USA LLC v. Eurotech Spa

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:23-cv-00506, E.D. Tex., 01/24/2024
  • Venue Allegations: Plaintiff alleges venue is proper because Defendant is a foreign corporation that may be sued in any judicial district. It further alleges Defendant committed acts of infringement in the district by directing sales and marketing activities to Texas and placing the accused products into the stream of commerce with the expectation of sales in the district.
  • Core Dispute: Plaintiff alleges that Defendant’s Everyware Internet-of-Things (IoT) platform infringes two patents related to modular platforms for automatically integrating heterogeneous devices, sensors, and actuators into a network.
  • Technical Context: The technology involves IoT platforms that create a unified software environment to manage and control a diverse array of physical devices, a foundational technology for "smart spaces" like automated homes, industrial control systems, and remote healthcare.
  • Key Procedural History: The complaint alleges that the parties engaged in pre-filing licensing discussions beginning on or before December 1, 2022, establishing a date of alleged pre-suit knowledge of the patents for the purpose of willfulness allegations. The patents-in-suit were originally assigned by the University of Florida to the inventors, who subsequently assigned them to Plaintiff Rokiot.

Case Timeline

Date Event
2006-02-21 Earliest Priority Date for ’257 and ’063 Patents
2011-02-22 U.S. Patent No. 7,895,257 Issues
2014-01-14 U.S. Patent No. 8,631,063 Issues
2022-12-01 Alleged date of first notice via licensing discussions
2024-01-24 Complaint Filed

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

U.S. Patent No. 7,895,257 - "Modular Platform Enabling Heterogeneous Devices, Sensors, and Actuators to Integrate Automatically into Heterogeneous Networks"

  • Patent Identification: U.S. Patent No. 7895257, "Modular Platform Enabling Heterogeneous Devices, Sensors, and Actuators to Integrate Automatically into Heterogeneous Networks," Issued February 22, 2011.

The Invention Explained

  • Problem Addressed: The patent's background describes the process of integrating new devices into smart spaces as "laborious" and the result of "massive ad-hoc system integration." (Compl. ¶26; ’257 Patent, col. 2:25-42). Prior systems required developers to have specific knowledge of each device and its communication protocols, a method that did not scale as more devices were added. (’257 Patent, col. 2:25-42).
  • The Patented Solution: The invention is a platform architecture that automatically converts disparate physical devices—like sensors and actuators—into standardized, programmable "software services." (’257 Patent, Abstract). This is achieved via a hardware platform connected to the devices and a middleware layer that handles the translation, discovery, and management of these services, as depicted in the architectural overview of Figure 1. (’257 Patent, col. 5:32-44; Fig. 1). This allows developers to build complex applications using high-level programming without needing to understand the underlying hardware complexities. (’257 Patent, col. 5:50-58).
  • Technical Importance: This service-oriented architecture aimed to solve the critical interoperability and scalability problems that limited the practical development of large-scale, pervasive computing environments. (’257 Patent, col. 4:26-30).

Key Claims at a Glance

  • The complaint asserts independent claim 1. (Compl. ¶45).
  • Essential elements of independent claim 1 include:
    • A system with a "hardware platform" connected to a first "active object" (a sensor) and a second "active object" (an actuator).
    • A "middleware module", running on the hardware platform, that generates a "software service" to represent each active object.
    • The middleware is configured to receive "raw data" from the sensor, convert it to "useable data", and pass it to an application.
    • The middleware is also configured to receive high-level commands from an application, convert them to low-level commands, and use them to control the actuator.
    • The software services are generated based on a "driver" that contains the information needed to interact with the corresponding active object.
  • The complaint reserves the right to assert numerous dependent claims. (Compl. ¶44).

U.S. Patent No. 8,631,063 - "Modular Platform Enabling Heterogeneous Devices, Sensors, and Actuators to Integrate Automatically into Heterogeneous Networks"

  • Patent Identification: U.S. Patent No. 8631063, "Modular Platform Enabling Heterogeneous Devices, Sensors, and Actuators to Integrate Automatically into Heterogeneous Networks," Issued January 14, 2014.

The Invention Explained

  • Problem Addressed: As a continuation of the application leading to the ’257 Patent, this patent addresses the same technical problem: the lack of a scalable, modular platform for integrating heterogeneous devices into smart spaces. (Compl. ¶25, fn. 2; ’063 Patent, col. 2:25-42).
  • The Patented Solution: The solution is materially the same as that described in the ’257 Patent, centering on a service-oriented architecture where a middleware layer abstracts physical hardware into standardized software services. (’063 Patent, Abstract; col. 5:32-44).
  • Technical Importance: The technical importance is identical to that of the parent ’257 Patent, focused on enabling the development of scalable pervasive computing. (’063 Patent, col. 4:26-30).

Key Claims at a Glance

  • The complaint asserts independent claim 16. (Compl. ¶57).
  • Essential elements of independent claim 16, a method stored on a non-transitory medium, include:
    • Receiving a "driver" for an "active object" (which can be a sensor, actuator, or both).
    • Generating a "software service" based on the driver to represent the object.
    • Receiving high-level commands via the software service, converting them to low-level commands, and transmitting them to the object.
    • Where the object includes a sensor, the method includes receiving "raw data", converting it to "usable data", and passing it to a second software service for use by a high-level application.
    • The software service is generated by a "middleware module".
  • The complaint reserves the right to assert numerous dependent claims. (Compl. ¶56).

III. The Accused Instrumentality

Product Identification

  • The accused instrumentalities are collectively referred to as the "Eurotech Everyware IoT" platform, which includes the "EveryWare Cloud," "EveryWare Software Framework," and "IoT Edge Gateways." (Compl. ¶¶ Intro, 32).

Functionality and Market Context

  • The complaint describes the accused products as an "IoT Integration Platform" that provides services for managing IoT gateways and devices, collecting data from the field, and integrating that data into downstream applications and business processes. (Compl. ¶32).
  • The system is alleged to include a "hardware platform" (edge gateways) and a "middleware module" (servers, cloud infrastructure) that intermediates between physical devices and software applications. (Compl. ¶38).
  • The middleware allegedly generates software representations of the physical devices, which Eurotech calls "assets" or "digital twins." (Compl. ¶39). These "digital twins" are allegedly based on drivers and allow high-level applications to communicate with low-level devices via APIs, with the middleware performing the necessary command and data translation. (Compl. ¶¶39-40).
  • The complaint alleges the system is commercially significant, with partners including IBM, RedHat, Microsoft, and Amazon, and that nearly 40% of Eurotech's revenue originates from U.S. end-users. (Compl. ¶8).

IV. Analysis of Infringement Allegations

No probative visual evidence provided in complaint.

'257 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A system comprising: a hardware platform, wherein the hardware platform is adapted to be communicably connected to an active object; The Eurotech IoT System includes a hardware platform, such as edge and gateway infrastructure, that connects to active objects like sensors and actuators. ¶38 col. 9:11-14
a middleware module, wherein at least a portion of the middleware module resides in and/or is executed on the hardware platform; The system includes a middleware module, comprising servers and cloud infrastructure, which is in or executed on the hardware platform. ¶38 col. 13:17-21
at least one software service generated by the middleware module, wherein each of the at least one software service represents the active object... wherein the active object is a device comprising a sensor and wherein the hardware platform is configured to receive raw data... and the middleware module is configured to convert the raw data into useable data... The middleware generates software services, called "assets" or "digital twins," to represent active objects (field devices). The middleware converts "raw data" from a sensor object into "useable data" for applications. ¶¶39-40 col. 17:60-65
further comprising one or more applications written in a higher level language, wherein at least one of the one or more applications is configured to receive the useable data from one or more of the at least one software service, The system includes applications configured to receive useable data from the "digital twin" or asset. ¶40 col. 8:27-34
wherein the at least one additional active object comprises one or more devices comprising an actuator, wherein the middleware module is configured to: receive commands... convert the commands into low-level commands... and transmit the low-level commands... The system connects to actuators. The middleware is alleged to receive high-level commands, convert them into low-level commands understood by the actuator, and transmit them to control the actuator. ¶¶38, 40 col. 18:19-31
wherein the middleware module is configured to generate each of the at least one software service based on a driver... The software services (assets/digital twins) are alleged to be based on a driver that includes the information and behavioral components of the active objects. ¶39 col. 18:32-49
  • Identified Points of Contention:
    • Scope Questions: A central question may be whether the patent’s "hardware platform," which is depicted and described as a discrete, modular node (’257 Patent, Fig. 3), can be interpreted to cover the accused "edge, gateway, and platform infrastructure," which may be a more distributed and less physically unified system. (Compl. ¶38).
    • Technical Questions: The complaint alleges infringement "jointly (with, for example, its customers and partners)." (Compl. ¶43). This raises the issue of divided infringement. A key factual dispute will likely concern which entity performs each claimed step and whether Eurotech "directs or controls" the actions of its customers to the extent necessary to attribute their conduct to Eurotech for infringement purposes. (Compl. ¶49).

'063 Patent Infringement Allegations

Claim Element (from Independent Claim 16) Alleged Infringing Functionality Complaint Citation Patent Citation
A non-transitory media storage device having machine-readable instructions stored thereon for performing a method for... receiving a driver, wherein the driver comprises information and behavioral components required to interact with an active object... The Eurotech IoT System provides and uses drivers that contain the necessary information to interact with active objects (sensors and actuators). These instructions are stored on hardware within the system. ¶¶38-39 col. 19:38-49
generating based on the driver a software service to represent the active object; The system's middleware generates software services, termed "assets" or "digital twins," based on the drivers to represent the active objects. ¶39 col. 19:46-50
receiving via the software service one or more commands from an application written in a higher level language; converting the... commands into... low-level commands... transmitting the low-level commands to the active object via the hardware platform; The middleware receives high-level commands via the software service (e.g., through APIs), converts them to low-level commands, and transmits them to the active object. ¶40 col. 19:51-57
generating a second software service, wherein the second software service represents the active object... wherein the active object is a device comprising both a sensor and an actuator; receiving raw data... converting the raw data into usable data; and passing the usable data... The system handles devices that are both sensors and actuators. It is alleged to generate corresponding software services, receive raw data from the sensor function, convert it to usable data, and pass it to a software service for use by a high-level application. ¶¶38, 40 col. 19:58-65
  • Identified Points of Contention:
    • Scope Questions: Claim 16 is directed to a "non-transitory media storage device." The infringement analysis will require identifying which specific component of the distributed "Eurotech IoT System" constitutes the claimed storage device (e.g., server hard drives, gateway flash memory).
    • Technical Questions: As with the ’257 Patent, the method claim raises questions of divided infringement. The court will need to determine whether all steps of the claimed method are performed or controlled by Eurotech, or if some are performed independently by its customers, potentially avoiding liability under current law. (Compl. ¶¶ 55, 60-61).

V. Key Claim Terms for Construction

  • The Term: "active object"
    • Context and Importance: This term defines the universe of devices the patented system is designed to manage. It is distinguished in the patent from "passive objects" and is further defined as comprising "sensors" and "actuators." (’257 Patent, col. 6:30-49). The complaint alleges this term reads on Eurotech's "field devices" and their corresponding "digital twins." (Compl. ¶¶38-39). The construction of this term will determine whether the claims cover the full range of devices integrated by the accused system.
    • Evidence for a Broader Interpretation: The specification provides an extensive and non-limiting list of exemplary active objects, including smart mailboxes, doors, window coverings, and even smart closets and bathrooms, suggesting the term is intended to be interpreted broadly. (’257 Patent, col. 6:51–col. 7:20).
    • Evidence for a Narrower Interpretation: The specification consistently describes the "active object" as a physical entity that is communicably connected to the "hardware platform." A party could argue the term requires a discrete physical apparatus and does not extend to purely logical or virtual entities that might exist within a modern IoT platform.
  • The Term: "middleware module"
    • Context and Importance: This is the core functional component of the invention, responsible for generating software services and translating data and commands. The complaint alleges this is met by a combination of "servers, cloud-server infrastructure, IoT gateways, hubs, middleware, [and] software." (Compl. ¶38). Whether such a distributed, multi-component system constitutes a single "middleware module" will be a critical issue.
    • Evidence for a Broader Interpretation: The specification contemplates that the middleware may be distributed, describing a "hierarchical grouping of middleware servers" where different servers connect to different platform nodes. (’257 Patent, col. 15:40-44). This suggests the "module" is not required to be a monolithic software application on a single machine.
    • Evidence for a Narrower Interpretation: The patent repeatedly references the Open Services Gateway initiative (OSGi) as a suitable framework. (’257 Patent, col. 13:22-28). A defendant may argue that the term "middleware module" should be limited to a system that incorporates the specific architectural principles or structure of an OSGi framework, rather than any general collection of server-side software.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges induced infringement, stating that Eurotech encourages and instructs its customers and developers to use the accused systems in an infringing manner by providing "user guides, instruction materials and customer support." (Compl. ¶¶ 50, 62). The complaint further alleges that Eurotech "dictates the manner and timing of performance" via APIs and SDKs, which provides a factual basis for a theory of infringement by direction or control. (Compl. ¶¶ 49, 61).
  • Willful Infringement: Willfulness is alleged based on pre-suit notice. The complaint asserts that Eurotech has known of the patents and their alleged infringement since "at least December 1, 2022," as a result of "pre-filing licensing discussions" between the parties. (Compl. ¶¶ 46, 58).

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

  • A core issue will be one of architectural scope: can the patents' claims, which describe a system centered on a discrete, modular "hardware platform" and a "middleware module," be construed to read on the accused "Eurotech IoT System," which is alleged to be a distributed, cloud-based platform of gateways, servers, and software-defined "digital twins"?
  • A key evidentiary question will be one of attribution: does the evidence show that Eurotech, by itself, performs every step of the asserted claims, or does infringement depend on the actions of its customers? The case may turn on whether Eurotech’s provision of an integrated platform, APIs, and user guides constitutes sufficient "direction or control" to hold it responsible for the combined actions of the entire system.