DCT

3:24-cv-00430

Honeywell Intl Inc v. Lone Star Aerospace Inc

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 3:24-cv-00430, N.D. Tex., 03/14/2024
  • Venue Allegations: Venue is alleged to be proper in the Northern District of Texas because Defendant Lone Star has a regular and established place of business in the district and has committed alleged acts of infringement there.
  • Core Dispute: Plaintiff alleges that Defendant’s MaxUp line of predictive and prescriptive analytics software products infringes six patents related to computer system monitoring, event logging, and fault detection.
  • Technical Context: The technology at issue involves methods for collecting, analyzing, and reporting on the operational status and health of complex systems, such as vehicle fleets, energy equipment, and manufacturing assets, to enable predictive maintenance and diagnostics.
  • Key Procedural History: The complaint highlights the prosecution history of the '061 Patent's parent, the '686 patent, noting that the USPTO initially rejected claims under 35 U.S.C. § 101 (Alice) but later allowed them after Honeywell submitted arguments regarding the claims' improved technical functionality. This history may be raised by the Plaintiff to argue for the patent eligibility of the asserted claims in the '061 and '477 patents, which share the same specification.

Case Timeline

Date Event
2002-06-21 '651 Patent Priority Date
2004-06-29 '810 Patent Priority Date
2006-03-07 '651 Patent Issued
2008-10-17 '936 Patent Priority Date
2009-01-27 '810 Patent Issued
2011-01-24 '437 Patent Priority Date
2012-09-04 '936 Patent Issued
2014-11-25 '437 Patent Issued
2015-10-14 '061 and '477 Patents Priority Date
2017-09-22 Non-Final Rejection issued for parent '686 patent
2018-04-16 Final Rejection issued for parent '686 patent
2018-09-05 Notice of Allowance issued for parent '686 patent
2020-06-02 '061 Patent Issued
2021-05-25 '477 Patent Issued
2024-03-14 First Amended Complaint Filed

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

U.S. Patent No. 7,010,651 - "System And Method For Using Removable Storage For Computer Troubleshooting"

The Invention Explained

  • Problem Addressed: Prior art methods for troubleshooting complex, remote, software-intensive systems were limited by "insufficient data concerning operating parameters, operating history, and computer status" at the time a problem occurred (Compl. ¶19; ’651 Patent, col. 2:20-27).
  • The Patented Solution: The invention describes a monitoring system that logs the status of computer tasks and events, accumulates this data in a specific order, and writes it to a removable memory unit. This creates a self-contained, transportable record of the system's recent history, which can then be physically removed and analyzed on a different machine to diagnose a failure without relying on a live data connection to the troubled system (’651 Patent, Abstract; col. 2:38-57).
  • Technical Importance: This approach provided a concrete method for post-mortem failure analysis on remote systems where continuous real-time monitoring was impractical or impossible, offering "significant advantages in hardware and software diagnostic evaluation" (Compl. ¶20; ’651 Patent, col. 2:18-21).

Key Claims at a Glance

  • Independent Claim 3 is asserted (Compl. ¶122).
  • Essential elements of Claim 3 include:
    • monitoring the status of a task within a computer;
    • if the task is active, logging the status data of the task;
    • if an event occurs related to the task, logging any change in the status of the task caused by the event;
    • accumulating the status data, wherein status data is accumulated in a first-in, first-out queue; and
    • writing the status data to a memory storage coupled to the computer.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 7,483,810 - "Real Time Event Logging System"

The Invention Explained

  • Problem Addressed: Conventional real-time system monitors required the device to be stopped to measure parameters, which disrupts the very real-time process being observed and can burden the larger integrated system (Compl. ¶32; ’810 Patent, col. 1:12-24).
  • The Patented Solution: The invention proposes a method that monitors a system for a "triggering event." Upon detection, it records data about the system to a first, local memory (e.g., a buffer) for a set period. This captured data is later sent from the first memory to a second memory or an interface for retrieval and analysis, allowing the operating system to function "without delaying, stopping, or otherwise disturbing" it (’810 Patent, Abstract; col. 2:32-34).
  • Technical Importance: The invention enabled the capture of high-fidelity diagnostic data surrounding a specific anomalous event in a real-time environment, like a satellite's control system, without interrupting its critical operations (Compl. ¶33; ’810 Patent, col. 1:20-24).

Key Claims at a Glance

  • Independent Claim 1 is asserted (Compl. ¶140).
  • Essential elements of Claim 1 include:
    • monitoring the system in real time for a triggering event;
    • logging data about the system to a first memory upon detection of the triggering event and for a set time after the triggering event occurs;
    • continuing the monitoring of the system and the logging of data until the first memory is filled; and
    • sending the data from the first memory to an interface for retrieval.
  • The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 8,258,936 - "Method And System For Acquiring Integrated Operational And Support Data For A Vehicle"

Technology Synopsis

The patent addresses the problem of vehicle maintenance systems being tied to fixed terminals, which increases repair times. The solution involves a method where a remote device can connect to a vehicle's interface, request and receive operational data (containing event indicators), and then retrieve corresponding support data (like repair manuals) from a stored location, thereby integrating operational and support information on a mobile platform (Compl. ¶42, ¶45, ¶46).

Asserted Claims

Independent Claim 11 is asserted (Compl. ¶157).

Accused Features

The complaint alleges that the MaxUp Fleet and MaxUp Readiness software infringe by acquiring integrated operational and support data from vehicles. This includes establishing connections with remote ODBII devices, requesting and receiving operational data, and providing fleet inventory management and readiness analysis (Compl. ¶¶158, 163-167). The complaint references a visual from the MaxUp Readiness webpage showing its module for providing "real-time configuration/capability status of managed assets" (Compl. Ex. 12, p. 23).

U.S. Patent No. 8,896,437 - "Asset-Specific Equipment Health Monitoring (EHM) For Industrial Equipment Using Standardized Asset Models"

Technology Synopsis

The technology aims to solve the problem of costly and time-consuming custom-built diagnostic models for industrial equipment. The invention provides for a system where an Equipment Health Monitoring (EHM) unit is pre-configured with an "asset-specific model" built from a combination of standard subsystem models. This unit receives sensor data, analyzes it using the model to detect a specific fault, and outputs an indicator identifying that fault (Compl. ¶55, ¶58).

Asserted Claims

Independent Claim 16 is asserted (Compl. ¶179).

Accused Features

The complaint alleges that the MaxUp Energy software, an "asset analytic solution" for Electric Submersible Pumps (ESPs), infringes by being pre-configured with an asset-specific model, receiving sensor signals (e.g., temperature), analyzing them to determine a fault, and outputting an indicator of the fault to a dashboard (Compl. ¶¶180-183).

U.S. Patent No. 10,671,061 - "Devices, Methods, And Systems For A Distributed Rule Based Automated Fault Direction"

Technology Synopsis

The patent addresses fault detection in large, distributed environments with many systems, aiming for a solution that is fault-tolerant and can run on low-cost hardware. The invention describes a method using a distributed, rule-based system that receives data from equipment in a "building environment," applies a condition to test for a fault state (even if the condition is not currently affecting the environment, suggesting predictive analysis), aggregates faults into groups, and generates a descriptive output file (Compl. ¶68, ¶71, ¶212).

Asserted Claims

Independent Claim 13 is asserted (Compl. ¶212).

Accused Features

The complaint alleges that the MaxUp Manufacturing and MaxUp Energy software infringe. For MaxUp Manufacturing, it is alleged to receive data from Rotary Screw Compressor (RSC) assets, apply conditions (e.g., "oil separator pressure drop high") to identify fault states, aggregate these faults, and generate outputs on a dashboard (Compl. ¶¶213-218). For MaxUp Energy, a similar process is alleged for ESP assets, where a condition like "voltage imbalance is above specifications" is used to identify a fault (Compl. ¶¶219-224).

U.S. Patent No. 11,016,477 - "Devices, Methods, And Systems For A Distributed Rule Based Automated Fault Direction"

Technology Synopsis

As a continuation of the '061 Patent, this patent shares the same core technology for distributed, rule-based fault detection. The asserted claim focuses on a non-transitory computer-readable medium with instructions to collect data, determine faults based on that data, aggregate the faults into groups based on equipment type, generate a fault description, and report the faults with their descriptions (Compl. ¶89, ¶195).

Asserted Claims

Independent Claim 8 is asserted (Compl. ¶195).

Accused Features

The complaint alleges the MaxUp Energy software infringes by executing instructions to collect data (e.g., current, voltage, temperature) from ESP assets, determine faults, aggregate them by equipment type (e.g., ESP cable, transformer), generate detailed descriptions, and report them on a dashboard (Compl. ¶¶196-200). A screenshot from the MaxUp Energy webpage advertises its capability to diagnose, predict, and prescribe action on up to 60 ESP failure modes (Compl. Ex. 11, p. 21).

III. The Accused Instrumentality

Product Identification

  • The accused products are Defendant’s MaxUp Fleet, MaxUp Energy, MaxUp Readiness, and MaxUp Manufacturing software solutions (collectively, the "Accused Products") (Compl. ¶102).

Functionality and Market Context

  • The complaint describes the Accused Products as a suite of predictive and prescriptive analytics software solutions designed for various industries (Compl. ¶¶107, 111, 115, 118).
    • MaxUp Fleet allegedly provides "real-time predictive and prescriptive analytics" for vehicle fleets to plan maintenance, optimize assets, and reduce costs (Compl. ¶107). A marketing visual states it provides "vehicle health insights to minimize breakdowns" (Compl. Ex. 9, p. 20).
    • MaxUp Energy allegedly provides analytics for Electric Submersible Pump (ESP) operators to "maximize uptime, extend time to failure," and predict component-level failures (Compl. ¶111).
    • MaxUp Readiness is described as an "operational analytics application" for organizations to "optimize complex processes," including holistic fleet inventory management and real-time status of managed assets (Compl. ¶115).
    • MaxUp Manufacturing allegedly provides "powerful visualizations of predictions, prescriptions, and data insights" for Rotary Screw Compressor (RSC) systems to reduce ownership costs (Compl. ¶118). A marketing visual highlights its ability to forecast utility savings (Compl. Ex. 14, p. 26).

IV. Analysis of Infringement Allegations

'651 Patent Infringement Allegations

Claim Element (from Independent Claim 3) Alleged Infringing Functionality Complaint Citation Patent Citation
monitoring the status of a task within a computer; The MaxUp Fleet software allegedly monitors tasks such as the oil temperature in a vehicle's turbocharger (Compl. ¶124). ¶124 col. 3:9-12
if the task is active, logging the status data of the task within the computer; When active, the software allegedly logs status data for the task of monitoring oil temperature (Compl. ¶125). ¶125 col. 3:13-16
if an event occurs related to the task, logging any change in the status of the task caused by the event; Upon an event, such as oil temperature exceeding a threshold, the software allegedly logs the change in status caused by that event (Compl. ¶126). ¶126 col. 3:17-21
accumulating the status data, wherein status data is accumulated in a first-in, first-out queue; and The software allegedly accumulates status data related to oil temperature changes "along with timestamps," which Plaintiff alleges constitutes a first-in, first-out queue (Compl. ¶127). ¶127 col. 4:32-40
writing the status data to a memory storage coupled to the computer. The software allegedly writes the status data to memory storage, such as in ODBII devices connected to sensors and a remote device (Compl. ¶128). ¶128 col. 4:41-45
  • Identified Points of Contention:
    • Scope Question: A central issue may be whether accumulating data "along with timestamps" (Compl. ¶127) meets the "first-in, first-out queue" limitation of Claim 3. A court will have to determine if this specific data structure is required or if a temporally ordered log is sufficient.
    • Technical Question: What evidence demonstrates that the accused software logs data upon a change in status caused by an event, as distinct from merely logging the event itself? The complaint alleges the logging of events that "exceed a threshold," which may blur the line between logging an event and logging a change in status caused by it (Compl. ¶126).

'810 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
monitoring the system in real time for a triggering event; The MaxUp Fleet software allegedly monitors vehicle sub-systems in real-time for triggering events, such as an oil overheating event in a turbocharger (Compl. ¶142). ¶142 col. 2:40-42
logging data about the system to a first memory upon detection of the triggering event and for a set time after the triggering event occurs; Upon detecting a threshold-exceeding event, a sensor allegedly logs data to its cache memory, and the logged data is displayed on a dashboard with event details and a time period for the event (Compl. ¶143). ¶143 col. 2:43-48
continuing the monitoring of the system and the logging of data until the first memory is filled; and A sensor associated with the turbocharger allegedly continues logging data to its cache memory as the temperature exceeds a threshold, with timestamps for each event, until the memory is filled, at which point logging stops (Compl. ¶144). ¶144 col. 2:48-51
sending the data from the first memory to an interface for retrieval. An ODBII device allegedly collects the logged data from the sensors and sends it for remote display on the cloud-based MaxUp Fleet product dashboard, which serves as an interface for retrieval (Compl. ¶145). ¶145 col. 2:51-54
  • Identified Points of Contention:
    • Scope Question: Does the combination of a sensor's "cache memory" and a "cloud-based...dashboard" (Compl. ¶¶143, 145) constitute the "first memory" and "interface for retrieval" as architecturally distinct elements required by the claim? The functionality seems to be alleged, but the structural mapping may be a point of dispute.
    • Technical Question: The claim requires logging data "for a set time after the triggering event occurs." The complaint alleges that logged data is displayed with a "time period for each triggering event" (Compl. ¶143). It will be a key factual question whether the accused system logs for a pre-defined duration post-event, or simply logs all data while the triggering condition (e.g., overheating) persists.

V. Key Claim Terms for Construction

  • For the '651 Patent:

    • The Term: "first-in, first-out queue" (Claim 3)
    • Context and Importance: This term defines a specific data structure. The infringement case for the '651 Patent may depend on whether Lone Star's method of accumulating data with timestamps (Compl. ¶127) is equivalent to this structure. Practitioners may focus on this term because it is a precise technical limitation that appears to be met with a more general allegation.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent does not appear to provide an explicit definition that would broaden the term beyond its well-understood meaning in computer science. A party might argue that the purpose of the queue—to preserve the order of events—is achieved by timestamping, making a timestamped log a functional equivalent.
      • Evidence for a Narrower Interpretation: The specification explicitly references a "FIFO queue 60" in its description of the preferred embodiment and its corresponding figure (FIG. 2), stating it is used to "funnel[]" data and "maintain[] in order the most recent events and state changes" (’651 Patent, col. 4:32-35, 4:1-3). This explicit reference to a specific structure in the embodiment could be used to argue for a narrower construction limited to that structure.

  • For the '810 Patent:

    • The Term: "triggering event" (Claim 1)
    • Context and Importance: The definition of what constitutes a "triggering event" is fundamental to the claim's scope. The infringement analysis hinges on whether the conditions monitored by the accused MaxUp Fleet software, such as an "oil overheating event" (Compl. ¶142), fall within the claim's scope.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification states an event "may be comprised of one or more parameters achieving a certain state or states with respect to an event definition criteria" (’810 Patent, col. 2:40-42). It further provides a detailed description of how an event can be defined using multiple logical expressions, including various comparison methods and data masks, suggesting a flexible and broad definition configurable by the user (’810 Patent, col. 5:21-36).
      • Evidence for a Narrower Interpretation: While the specification allows for flexible definitions, a party could argue that the examples provided, such as a "Built-in-Self-Test (BIT) failure" (’810 Patent, col. 6:50-53), suggest the term is limited to discrete, pre-defined system errors rather than continuous parameter monitoring that crosses a generic threshold.

VI. Other Allegations

  • Indirect Infringement: For all asserted patents, the complaint alleges both induced and contributory infringement. Inducement is based on allegations that Lone Star sells the Accused Products with instructions on how to use them in an infringing manner, with specific intent for the end-user to infringe (e.g., Compl. ¶¶131, 148). Contributory infringement is based on allegations that Lone Star knowingly provides the Accused Products, which are a material part of the invention and have no substantial non-infringing uses (e.g., Compl. ¶¶132, 149).
  • Willful Infringement: The complaint alleges that Lone Star's infringement of all asserted patents was "willful, intentional, deliberate, and/or in conscious disregard" of Honeywell's rights (e.g., Compl. ¶¶137, 154). The basis for willfulness appears to be post-suit knowledge, as the allegations of knowledge for indirect infringement are pleaded "at least as of service of the Complaint" (e.g., Compl. ¶¶130, 147).

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

  • A core issue will be one of claim construction and technical scope: Can the specific data structure "first-in, first-out queue" from the '651 Patent be interpreted to cover the accused software's alleged function of accumulating data with timestamps? Similarly, for the '810 Patent, does the system's logging of a continuous condition like overheating meet the claimed step of logging for a "set time after the triggering event occurs"?
  • A key evidentiary question will be one of functional operation: The complaint makes numerous allegations about how the accused software operates based on marketing materials and high-level descriptions. A central challenge for the Plaintiff will be to produce evidence from the accused software's source code or operation that demonstrates it performs the specific, multi-step processes recited in the asserted method claims, such as filling a memory buffer and then stopping ('810 Patent) or applying predictive conditions that are not currently affecting an environment ('061 Patent).
  • A significant legal question will concern patent eligibility under 35 U.S.C. § 101, particularly for the '061 and '477 patents. While the complaint proactively points to a favorable prosecution history of a parent patent, the claims are directed to methods of collecting, analyzing, and reporting data, a subject matter area that frequently faces Alice-based challenges. The case will likely involve a dispute over whether the claims are directed to an abstract idea or to a specific, improved technical method for fault detection in distributed systems.