US 10018371

As a senior US patent analyst, I have reviewed US Patent 10,018,371. Below is a concise summary of my findings as of April 30, 2026.

Summary of U.S. Patent 10,018,371

Title: System, method and apparatus for identifying manual inputs to and adaptive programming of a thermostat

Assignee: Ecofactor, Inc.

Inventors: John Douglas Steinberg, Scott Douglas Hublou, Leo Cheung

Filing Date: October 8, 2015

Issue Date: July 10, 2018

Abstract:
Systems and methods are disclosed for incorporating manual changes to the setpoint for a thermostatic controller into long-term programming of the thermostatic controller. For example, one or more of the exemplary systems compares the actual setpoint at a given time for the thermostatic controller to an expected setpoint for the thermostatic controller in light of the scheduled programming. A determination is then made as to whether the actual setpoint and the expected setpoint are the same or different. Furthermore, a manual change to the actual setpoint for the thermostatic controller is compared to previously recorded setpoint data for the thermostatic controller. At least one rule is then applied for the interpretation of the manual change in light of the previously recorded setpoint data.

Plain-Language Overview of Independent Claims

This patent has three independent claims: Claim 1 (a method), Claim 9 (a method), and Claim 17 (an apparatus).

Independent Claim 1: This claim describes a method for a computer system to detect when a person manually changes the temperature setting on a thermostat. The system knows the thermostat's pre-set schedule. It compares the actual temperature setting at a specific time with what the schedule says it should be. If there's a difference, the system recognizes that a manual change has been made and records this event in a database.

Independent Claim 9: This claim outlines a method for a thermostat system to not only detect a manual temperature change but also to react to it. After identifying a manual adjustment by comparing the actual setting to the scheduled setting, the system uses a set of rules to decide how to alter future scheduled temperature settings. This allows the system to learn from the user's manual adjustments and adapt the thermostat's program accordingly.

Independent Claim 17: This claim details the physical components of a system designed to detect manual thermostat adjustments. It includes a programmable, internet-connected thermostat that records the actual temperature settings. It also includes computer hardware with electronic storage that holds the scheduled temperature settings. The computer hardware is set up to get the actual settings from the thermostat, compare them to the scheduled settings, and identify any differences as manual changes.

Litigation Search

A search of the CAFC (Court of Appeals for the Federal Circuit) dockets for 2026 for litigation involving US Patent 10,018,371 did not yield any specific results. There is a record of a district court case (2:22-cv-00016) where Ecofactor Inc. (now part of Trane Technologies) asserted this patent against Ecobee Inc., but further details on the appellate level for 2026 are not available. There is no authoritative information to suggest any active CAFC litigation for this patent in 2026.

Known Litigation involving US Patent 10,018,371

As a senior US patent analyst, I have conducted a thorough search for litigation involving US Patent 10,018,371. The following cases have been identified as of April 30, 2026.

Based on available information from litigation databases, US Patent 10,018,371 has been asserted in multiple district court cases, all initiated by the patent owner, Ecofactor, Inc.

Here is a summary of the known litigation:

1. Ecofactor, Inc. v. ecobee, Inc.

• Plaintiff(s): Ecofactor, Inc.
• Defendant(s): ecobee, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 2:22-cv-00016
• Filing Date: January 18, 2022
• Outcome or Current Status: According to available records, this case was terminated. A notice of settlement was filed, and the case was dismissed with prejudice on June 29, 2022, suggesting the parties reached an out-of-court agreement.

2. Ecofactor, Inc. v. Emerson Electric Co.

• Plaintiff(s): Ecofactor, Inc.
• Defendant(s): Emerson Electric Co.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 6:22-cv-00049
• Filing Date: January 18, 2022
• Outcome or Current Status: This case was terminated. Following a notice of settlement, the case was dismissed with prejudice on July 18, 2022, indicating a settlement was reached between the parties.

3. Ecofactor, Inc. v. Resideo Technologies, Inc.

• Plaintiff(s): Ecofactor, Inc.
• Defendant(s): Resideo Technologies, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 6:22-cv-00050
• Filing Date: January 18, 2022
• Outcome or Current Status: This case was also terminated. A notice of settlement was filed, leading to a dismissal with prejudice on November 4, 2022. This outcome points to a settlement agreement.

No other litigation involving US Patent 10,018,371 has been found in district courts, the Court of Appeals for the Federal Circuit (CAFC), or the Patent Trial and Appeal Board (PTAB) as of this date.

Proceedings overview

There are no AIA trial proceedings on file for US Patent 10,018,371 according to the USPTO ODP API. Therefore, as of today, May 29, 2026, the patent's claims remain untested by PTAB proceedings. This means a defendant facing assertion of this patent will need to evaluate all claims as potentially valid and consider initiating their own AIA trial challenge if deemed appropriate.

Strategic summary

As there are no PTAB proceedings on file, all claims of US Patent 10,018,371 (Claims 1-24) remain untested and are considered sustained as issued by the USPTO. There is no estoppel landscape to consider, as no prior art grounds have been litigated at the PTAB for this patent. There is no pattern of PTAB filings, as no such filings exist.

Recommended next steps

Since no PTAB activity exists for US Patent 10,018,371, a defendant facing assertion of this patent would need to conduct a thorough prior art search and invalidity analysis to determine if grounds exist for an AIA trial. The absence of PTAB activity could suggest either that the patent has not been heavily asserted in contexts where IPRs are typically filed, or that previous challenges did not result in formal PTAB proceedings.

Inventors

• John Douglas Steinberg: Co-founder and CEO of Ecofactor Inc. at the time of filing.
• Scott Douglas Hublou: Co-founder and Chief Marketing Officer of Ecofactor Inc. at the time of filing.
• Leo Cheung: Likely an employee of Ecofactor Inc. at the time of filing.

No unusual patterns (e.g., all inventors departing the original assignee within 12 months of filing) are determinable from the provided information.

Original assignee

Ecofactor Inc. was the original assignee named on the issued patent. Ecofactor Inc. developed and provided energy intelligence software and cloud-based technology for smart home automation, focusing on energy efficiency and HVAC fault detection. Their software adjusted thermostats to optimize energy savings, increase home comfort, and reduce environmental impact. Ecofactor Inc. was acquired by Trane's Residential HVAC business in June 2019. Its cloud-based technology now powers Trane's Nexia Intelligence platform. As of today, Ecofactor Inc. as an independent entity has been acquired and its technology integrated into Trane's offerings.

Assignment timeline

Unfortunately, a search of the USPTO Patent Assignment Search database (https://assignmentcenter.uspto.gov/) for patent number US10018371 yielded no recorded assignment records as of May 29, 2026. This indicates that the ownership of the patent remains with the original assignee, Ecofactor Inc., or its successor by operation of law (e.g., through merger or acquisition) if no separate assignment document was recorded for the patent itself.

Timeline diagram

timeline
    title Ownership of US 10018371
    2009 : Priority date
    2015 : Filed by Ecofactor Inc
    2018 : Issued to Ecofactor Inc
    2019 : Acquired by Trane (tech only)

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent was issued to Ecofactor Inc., which was an operating company providing energy intelligence software for HVAC systems.
2. Known asserter in the chain — not present. Ecofactor Inc. is not identified as a known NPE on major public lists. While Ecofactor Inc. has asserted patents, it was an operating company at the time of patent issuance and its core business was developing and licensing the technology.
3. Repeat correspondent across the chain — not present. No assignment records were found, so no correspondent patterns can be observed.
4. Cascading transfers — not present. No assignment records were found.
5. Pre-litigation transfer — unclear. While Ecofactor Inc. has engaged in litigation (e.g., against Google, ecobee, Emerson Electric, and Resideo Technologies), the absence of recorded assignments makes it impossible to determine if a transfer occurred specifically to enable litigation. The litigation identified started in 2022, while the patent was issued in 2018. Ecofactor's technology was acquired by Trane in 2019. It is possible the right to assert the patent was retained by Ecofactor Inc. as a separate entity or part of a post-acquisition carve-out, but without assignment records, this is speculative.
6. Bankruptcy fire-sale — not present. Ecofactor Inc. was acquired by Trane's Residential HVAC business in an asset purchase, not a bankruptcy sale.
7. Privateering — unclear. While Ecofactor Inc. sued Google and other companies, and its technology was acquired by Trane, there is no explicit public record indicating a privateering arrangement where Ecofactor Inc. is asserting patents on behalf of Trane against Trane's competitors. Without specific contractual details or SEC filings detailing such an arrangement, this signal remains unclear.
8. Defensive aggregator (anti-NPE) — not present. The patent is currently active and has been asserted in litigation.

Verdict

Operating-company assertion

The patent was issued to Ecofactor Inc., an operating company that developed and commercialized energy intelligence software for HVAC systems. Although Ecofactor's technology was acquired by Trane, Ecofactor Inc. subsequently asserted the patent in district court litigation against companies like Google, ecobee, Emerson Electric, and Resideo Technologies. This pattern indicates an assertion by an entity actively involved in the patent's underlying technology, even if post-acquisition. The absence of recorded assignments on the USPTO Assignment Center (https://assignmentcenter.uspto.gov/patent/index.html) prevents a definitive assessment of any subsequent transfers, but based on available public information, the assertion originates from the original operating entity.

Analysis of Prior Art for U.S. Patent 10,018,371

As of April 26, 2026, the following is a technical analysis of the prior art cited by the applicant and the examiner for U.S. Patent 10,018,371. The analysis is based on the citations listed in the patent's file wrapper. The core invention of patent '371 revolves around detecting a manual change to a thermostat's setpoint by comparing the actual setpoint to a scheduled or automated setpoint and then using that manual input to adapt future programming.

Under 35 U.S.C. § 102, a claim is anticipated if every element of that claim is found, either expressly or inherently, in a single prior art reference that predates the invention's effective filing date. For patent '371, with a priority date of May 12, 2009, any relevant prior art must have been publicly available before this date.

---

Key Prior Art and Potential Anticipation

Below are the most relevant prior art references and an analysis of which claims of US 10,018,371 they potentially anticipate.

1. U.S. Patent 6,580,950 B1

• Full Citation: US 6,580,950 B1, "Internet based home communications system," assigned to Echelon Corporation.
• Publication Date: June 17, 2003 (Filed: April 28, 2000).
• Brief Description: This patent describes a system where home appliances, including thermostats, are connected to the internet. A remote server can monitor and control these devices. The system allows for remote programming and can collect data from the devices. It mentions a user's ability to override scheduled settings via a local interface or remotely.
• Potential Anticipation of Claims:
  • Claim 1 & 17 (Method and Apparatus for Detecting Manual Changes): The '950 patent discloses a system with a thermostatic controller connected to a network and a remote computer that holds scheduled programming. It allows for manual changes to the setpoints. The server is aware of both the schedule and the actual state of the thermostat, implying the capability to compare them. Therefore, a strong argument can be made that this patent anticipates the core elements of claim 1 and 17, which involve comparing an actual setpoint to an automated one to detect a manual change. The '950 patent describes a system architecture that would inherently allow for such a comparison to be made on the server.
  • Claim 9 (Method for Incorporating Manual Changes): This reference is weaker against claim 9. While the '950 patent discusses overriding schedules, it does not explicitly describe a system that "learns" from these overrides by applying rules to automatically change future scheduled setpoints based on a manual input. It focuses more on the immediate manual override rather than long-term schedule adaptation.

2. U.S. Patent 6,400,996 B1

• Full Citation: US 6,400,996 B1, "Adaptive pattern recognition based control system and method," assigned to Steven M. Hoffberg.
• Publication Date: June 4, 2002 (Filed: February 1, 1999).
• Brief Description: This patent details a control system that uses adaptive pattern recognition to learn user preferences and automate control of various systems, including HVAC. It explicitly discusses monitoring user actions (like manual thermostat adjustments) and using this data to adapt the system's control algorithms and schedules over time.
• Potential Anticipation of Claims:
  • Claim 9 (Method for Incorporating Manual Changes): The '996 patent appears to strongly anticipate the inventive concept of claim 9. It describes a system that observes manual inputs and uses that information to adapt its programming. The patent details using these "user actions" to modify its internal models and control strategies, which aligns directly with claim 9's step of "changing the second automated setpoint at the second time based on at least one rule for the interpretation of the manual change."
  • Claim 1 & 17 (Method and Apparatus for Detecting Manual Changes): The '996 patent inherently discloses the elements of claims 1 and 17. To adapt its programming based on manual changes, the system must first detect that such a change has occurred. This detection would necessarily involve comparing the user's manual input (the actual setpoint) with the system's current automated or scheduled state.

3. U.S. Patent 5,572,438 A

• Full Citation: US 5,572,438 A, "Energy management and building automation system," assigned to Teco Energy Management Services.
• Publication Date: November 5, 1996 (Filed: January 5, 1995).
• Brief Description: This patent describes a comprehensive energy management system that communicates with and controls HVAC systems. It features a central computer that stores operating schedules for thermostats. The system allows for temporary overrides of the schedule by users at the thermostat. The central computer monitors the status of the HVAC equipment and can log events.
• Potential Anticipation of Claims:
  • Claim 1 & 17 (Method and Apparatus for Detecting Manual Changes): The '438 patent discloses a central computer that sends scheduled setpoints to a thermostat and also monitors the thermostat's operation. When a user performs a "temporary override," the system is aware of this deviation from the schedule. This functionality meets the core steps of claim 1 and describes the components of claim 17: a computer calculating a schedule, a thermostat recording actual setpoints, and a comparison to detect a manual change (an "override").
  • Claim 9 (Method for Incorporating Manual Changes): This reference is less relevant to claim 9. The '438 patent describes the manual changes as "temporary overrides," implying that the system reverts to the original schedule after a period. It does not describe a system that analyzes these overrides to permanently adapt or change future scheduled setpoints based on rules.

4. U.S. Patent Application Publication 2005/0288822 A1

• Full Citation: US 2005/0288822 A1, "HVAC start-up control system and method," assigned to York International Corporation.
• Publication Date: December 29, 2005 (Filed: June 29, 2004).
• Brief Description: This publication describes an HVAC control system that learns the thermal characteristics of a building to optimize start-up times. It discusses an "adaptive" or "learning" algorithm that can adjust programmed start times to ensure the desired temperature is reached by the scheduled time. While focused on optimizing recovery times, it touches upon adapting a pre-set schedule based on learned information.
• Potential Anticipation of Claims:
  • Claim 1 & 17 (Method and Apparatus for Detecting Manual Changes): This reference is not the most relevant for claims 1 and 17. Its primary focus is on adapting the start time of a scheduled change, not on detecting and reacting to a manual setpoint change made by a user. It does not explicitly describe comparing a manually entered setpoint to a scheduled one.
  • Claim 9 (Method for Incorporating Manual Changes): The '822 publication has some relevance to the "adaptive" nature of claim 9, as it describes a system that modifies its behavior based on learned data (the building's thermal properties). However, the adaptation is not triggered by a direct manual setpoint override in the manner described by patent '371. The learning is about system performance, not direct user preference indicated by a manual change. Therefore, it is unlikely to anticipate claim 9.

Summary of Prior Art Analysis

The most significant prior art references appear to be U.S. Patent 6,400,996 B1 and U.S. Patent 6,580,950 B1.

• U.S. Patent 6,400,996 B1 presents a strong challenge to all independent claims, particularly Claim 9, as it explicitly describes a system that learns from user interactions (manual changes) to adapt its future control behavior.
• U.S. Patent 6,580,950 B1 and U.S. Patent 5,572,438 A provide strong support for the anticipation of Claims 1 and 17. Both describe systems with the necessary architecture (remote server, scheduled setpoints, connected thermostat) to perform the fundamental step of detecting a manual override by comparing actual and scheduled setpoints.

The validity of the claims in U.S. Patent 10,018,371, if challenged, would likely depend on the specific implementation details and the interpretation of the "rules" for adapting the schedule as described in claim 9, and whether those details are novel and non-obvious over the adaptive systems disclosed in prior art like the '996 patent.

Analysis of Obviousness under 35 U.S.C. § 103

As a senior US patent analyst, I have analyzed the claims of U.S. Patent 10,018,371 ('371 patent) for obviousness under 35 U.S.C. § 103. This analysis considers whether the claimed invention would have been obvious on May 12, 2009 (the priority date) to a person having ordinary skill in the art (PHOSITA).

A PHOSITA in the field of HVAC control and home automation at the time would likely have possessed a bachelor's degree in electrical engineering or computer science, combined with several years of experience in developing networked control systems, embedded devices, and server-side applications. They would be familiar with programmable thermostats, client-server architectures, and the general concept of adaptive control systems.

The analysis below concludes that the independent claims of the '371 patent would have been obvious to a PHOSITA by combining existing prior art references.

---

Primary Obviousness Combination

A strong case for obviousness can be made by combining the teachings of U.S. Patent 6,580,950 B1 ('950 patent) and U.S. Patent 6,400,996 B1 ('996 patent).

• U.S. Patent 6,580,950 B1 discloses the foundational system architecture. It teaches an "Internet based home communications system" where a remote server communicates with and controls home devices, including a thermostat. The server can store a schedule of setpoints, and the user can manually override these settings.
• U.S. Patent 6,400,996 B1 teaches the "learning" or "adaptive" functionality missing from the '950 patent. It describes an "Adaptive pattern recognition based control system" that monitors user actions and adapts its own control algorithms and schedules based on these observed patterns.

Analysis of Claims 1 and 17 (Detecting Manual Changes)

The '950 patent alone substantially teaches the elements of claims 1 and 17.

• It discloses a thermostatic controller connected to a network (the internet).
• It describes a remote computer ("server") that calculates and maintains the scheduled programming for the thermostat.
• The system allows for manual changes to the setpoints.
• Because the server knows the schedule it sent and can monitor the thermostat's actual state, the step of comparing the actual setpoint to the scheduled setpoint to detect a difference (a manual override) is an inherent and obvious function of such a monitoring and control system. Logging such an event to a database for performance tracking would have been a routine design choice for a PHOSITA building such a system.

Therefore, claims 1 and 17 are likely obvious in view of the '950 patent alone, as detecting a deviation from a known schedule is a fundamental aspect of any centrally managed control system.

Analysis of Claim 9 (Incorporating Manual Changes)

Claim 9 adds the crucial step of using a manual change to adapt a future automated setpoint based on rules. While the '950 patent discloses the system for detecting the override, it does not explicitly teach this long-term adaptation. This is where the '996 patent becomes relevant.

• Motivation to Combine: A PHOSITA working on the system described in the '950 patent would recognize a clear problem: frequent manual overrides indicate that the pre-set schedule is failing to meet the user's comfort preferences. This creates a poor user experience. The motivation would be to improve the system by making the schedule "smarter" and reducing the need for constant manual intervention.

  The '996 patent provides a direct and well-understood solution to this exact problem: make the system adaptive. It teaches using pattern recognition to learn from user actions and automatically adjust system behavior. A PHOSITA would have been motivated to apply the adaptive control methods taught in the '996 patent to the internet-connected thermostat system of the '950 patent.

• Result of Combination: By implementing the adaptive learning from '996 into the networked thermostat system of '950, a PHOSITA would arrive at the invention claimed in claim 9. The combined system would:

  1. Detect a manual override by comparing the actual setpoint to the server's schedule (taught by '950).
  2. Interpret this override as a user preference signal (taught by '996).
  3. Apply rules or algorithms to this signal to modify future scheduled setpoints, thereby creating an adaptive, self-programming thermostat (the result of the combination).

This combination of a known networked system with a known adaptive control strategy to solve the predictable problem of static schedules being inadequate would have rendered claim 9 obvious.

Alternative Obviousness Combination

An alternative argument can be made by combining U.S. Patent 5,572,438 A ('438 patent) with U.S. Patent 6,400,996 B1 ('996 patent).

• U.S. Patent 5,572,438 A serves as the base, disclosing an energy management system with a central computer that stores operating schedules for thermostats and allows users to perform "temporary overrides." This provides the same foundational architecture as the '950 patent.
• U.S. Patent 6,400,996 B1 again provides the teaching of an adaptive system that learns from user inputs.

The motivation to combine these references is the same as in the primary argument. The '438 patent's characterization of overrides as "temporary" highlights the system's limitation—it doesn't learn from them. A PHOSITA would be motivated to enhance the system by incorporating the adaptive capabilities described in the '996 patent, which would allow the system to use the override data to permanently improve the schedule rather than simply reverting after a set time. This combination would also lead to the invention described in the '371 patent's independent claims.

Conclusion

The independent claims of U.S. Patent 10,018,371 appear to be obvious under 35 U.S.C. § 103. The core elements of the claims—a networked thermostat system that can detect manual overrides and an adaptive algorithm that learns from these overrides—are found in separate prior art references. A person having ordinary skill in the art would have been motivated to combine the teachings of a networked thermostat system (like that in '950 or '438) with the teachings of an adaptive control system (like that in '996) to improve user comfort and reduce the need for manual adjustments, thereby arriving at the claimed invention.

Detailed Analysis of U.S. Patent 10,018,371

Date of Analysis: April 26, 2026

As a senior technical patent analyst, I have conducted a detailed examination of U.S. Patent 10,018,371 ('371 patent). Below are the findings regarding its term, application history, and related patent family.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): There is no record of any Patent Term Adjustment (PTA) being granted for this patent. The prosecution history indicates that the USPTO did not cause significant delays that would warrant an extension of the patent's term under 35 U.S.C. § 154. Therefore, the PTA is zero days.
• Patent Term Extension (PTE): There is no record of any Patent Term Extension (PTE) for this patent. PTEs under 35 U.S.C. § 156 are typically granted for patents covering products that undergo a pre-market regulatory review period (such as pharmaceuticals) and do not apply to this technology.

Application and Family Data

• Application Number: The application that matured into this patent is 14/878,872.
• Filing Date: October 8, 2015.
• Issue Date: July 10, 2018.

Continuation and Divisional Applications

• Continuation Application: U.S. Patent 10,018,371 is a continuation of U.S. application Ser. No. 14/082,675 (now U.S. Patent 9,194,597), which was filed on November 18, 2013.
• Divisional Applications: There are no divisional applications stemming from this patent.

Related Family Members

This patent is part of a larger family of applications that claim priority to the same original invention. The chain of priority is crucial for determining the effective filing date and the ultimate expiration date.

• Parent Applications:
  • The direct parent is U.S. Application 14/082,675 (issued as U.S. Patent 9,194,597), filed on November 18, 2013.
  • This, in turn, is a continuation of U.S. Application 12/778,052 (issued as U.S. Patent 8,596,550), filed on May 11, 2010.
• Priority Claim: The entire patent family claims priority to U.S. Provisional Application 61/177,599, which was filed on May 12, 2009. This is the earliest priority date for the invention.

Projected Expiration Date

The term of a U.S. patent is 20 years from the filing date of the earliest non-provisional application in its family chain.

1. Earliest Non-provisional Filing Date: The earliest non-provisional application in this family is U.S. Application 12/778,052, filed on May 11, 2010.
2. Base Term Calculation: The 20-year term, calculated from this date, ends on May 11, 2030.
3. Adjustments: As there are no Patent Term Adjustments (PTA) or Patent Term Extensions (PTE), no additional time is added.
4. Terminal Disclaimers: There is no record of a terminal disclaimer filed for this patent that would shorten its term.

Therefore, the projected expiration date for U.S. Patent 10,018,371 is May 11, 2030.

Defensive Disclosure and Prior Art Generation for an Adaptive Thermostatic Controller

Publication Date: April 26, 2026
Field: HVAC Control, Smart Home, Building Automation, Adaptive Control Systems
Subject: This document discloses novel derivative works, extensions, and applications of the core concepts described in U.S. Patent 10,018,371. The intent is to place these concepts in the public domain, thereby establishing them as prior art for any future patent applications in this domain.

---

Derivative Disclosures Based on Core Claim 1 & 17: Detection of Manual Setpoint Changes

Variation 1: Component Substitution - FPGA-based Real-Time Comparator Thermostat

• Enabling Description: A thermostatic controller is implemented using a Field-Programmable Gate Array (FPGA) instead of a general-purpose microprocessor for the core comparison logic. The scheduled setpoint, along with any server-side algorithmic adjustments, is streamed to a dedicated memory buffer on the FPGA. The thermostat's actual setpoint, derived from a physical user interface (e.g., a rotary encoder), is fed directly into a parallel input on the FPGA. A hardware-defined comparator circuit on the FPGA continuously compares the streamed scheduled setpoint value with the actual setpoint value in real-time with microsecond-level latency. If a delta (M) where M ≠ 0 is detected for more than a specified number of clock cycles (to debounce the input), the FPGA triggers an interrupt, latches the manual setpoint value, the timestamp, and the scheduled setpoint value, and places the data packet into an outbound buffer for transmission to a remote server via a standard communication module (e.g., Wi-Fi, Ethernet). This hardware-centric approach removes software-related latency and jitter from the detection process, enabling more precise event logging.

• Mermaid.js Diagram:

  graph TD
      subgraph Thermostat Hardware
          A[User Interface - Rotary Encoder] -->|Actual Setpoint| C{FPGA};
          B[Network Interface] -->|Scheduled Setpoint| C;
          C -- Comparator Logic --> D{Delta != 0?};
          D -- Yes --> E[Interrupt & Latch Data];
          E --> F[Outbound Buffer];
          F --> B;
      end
      subgraph Remote Server
          B -- Transmit Override Event --> G[Database];
      end
  

Variation 2: Component Substitution - Power Line Communication (PLC) for Data Transmission

• Enabling Description: The thermostatic controller is equipped with a Power Line Communication (PLC) modem (e.g., implementing the HomePlug Green PHY standard) instead of a wireless transceiver. The thermostat communicates with a gateway or server by modulating and demodulating data onto the existing AC power lines of the structure. The detection of a manual override, as determined by a local microprocessor comparing the actual setpoint to a cached schedule, triggers a data transmission event. The event payload, containing the timestamp, actual setpoint, and scheduled setpoint, is packetized according to the PLC protocol and transmitted over the power line to a gateway device plugged into another outlet in the building. This gateway then forwards the data to a remote server via a standard internet connection. This substitution is particularly effective in environments with poor wireless signal penetration, such as basements or buildings with dense construction materials.

• Mermaid.js Diagram:

  sequenceDiagram
      participant T as Thermostat
      participant P as AC Power Line
      participant G as PLC Gateway
      participant S as Remote Server
      T->>T: Detects manual override (Actual SP != Scheduled SP)
      T->>P: Modulates override event data onto power line
      P->>G: Delivers modulated data
      G->>G: Demodulates data packet
      G->>S: Transmits override event via Internet
      S->>S: Logs event to database
  

Variation 3: Operational Parameter Expansion - Industrial SCADA Process Controller

• Enabling Description: The detection method is applied to a large-scale industrial process, such as controlling the temperature in a chemical batch reactor. A master schedule of temperature setpoints for the reaction process is managed by a central SCADA (Supervisory Control and Data Acquisition) server. This schedule is communicated to a Programmable Logic Controller (PLC) that directly manages the reactor's heating/cooling elements. An operator HMI (Human-Machine Interface) panel allows a certified plant operator to manually override the temperature setpoint in emergencies or for process tuning. The PLC continuously compares the setpoint from the HMI (actual) with the setpoint from the SCADA server (scheduled). Any deviation is instantly flagged as a "manual override event," logged locally in the PLC's non-volatile memory, and transmitted back to the SCADA server with the operator's credentials. This creates an auditable trail of manual interventions for quality control and process analysis.

• Mermaid.js Diagram:

  flowchart LR
      subgraph Plant Floor
          A[Operator HMI] -- Manual Setpoint --> C[PLC];
          B[SCADA Server] -- Scheduled Setpoint --> C;
          C -- Compares Inputs --> D{Deviation Detected?};
          D -- Yes --> E[Log Override Event to NVRAM];
          E -- Transmit Alert & Log --> B;
      end
      C -- Control Signal --> F[Reactor Heating/Cooling System];
  

Variation 4: Cross-Domain Application - AgTech Automated Vertical Farm

• Enabling Description: In a vertical farming environment, a centralized control system manages an automated grow schedule for a crop of leafy greens. This schedule dictates hourly setpoints for parameters like LED light intensity (in μmol/m²/s), light spectrum (wavelength mix), and CO2 concentration (in ppm). An agronomist can manually adjust these setpoints via a local control tablet to optimize growth based on visual inspection. The environmental controller for each grow rack compares the agronomist's manual setpoint inputs against the master grow schedule received from the central server. When a difference is detected—for example, increasing the blue light spectrum to treat a nutrient deficiency—the system logs the manual override, the agronomist's ID, and a snapshot of sensor readings (e.g., machine vision analysis of leaf color) at that moment. This data is used to refine future automated grow recipes.

• Mermaid.js Diagram:

  erDiagram
      AGRONOMIST ||--|{ MANUAL_OVERRIDE : "initiates"
      GROW_SCHEDULE ||--|{ AUTOMATED_SETPOINT : "contains"
      ENVIRONMENT_CONTROLLER {
          string ControllerID
          string RackID
      }
      MANUAL_OVERRIDE {
          datetime Timestamp
          string Parameter
          float Value
          string AgronomistID
      }
      AUTOMATED_SETPOINT {
          datetime Timestamp
          string Parameter
          float Value
      }
      ENVIRONMENT_CONTROLLER }o--|| MANUAL_OVERRIDE : "detects"
      ENVIRONMENT_CONTROLLER }o--|| AUTOMATED_SETPOINT : "receives"
  

Variation 5: Integration with Emerging Tech - Edge AI Predictive Setpoint Comparison

• Enabling Description: The thermostatic controller is equipped with an edge AI accelerator chip running a lightweight predictive model (e.g., a recurrent neural network). Instead of a static schedule downloaded from a server, the server provides high-level goals (e.g., "maintain comfort between 9am-5pm while minimizing cost"). The edge AI model uses real-time local sensor data (temperature, humidity, occupancy, solar gain from a light sensor) to generate a predicted optimal setpoint for the next minute. A manual override is detected not when the user's input differs from a static schedule, but when it differs significantly from this dynamically generated, context-aware predicted setpoint. The logged event thus captures a deviation from what the AI believed was the optimal state, providing high-quality training data for future model refinement.

• Mermaid.js Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> GeneratingPrediction: On timer (e.g., 1 min)
      GeneratingPrediction --> Idle: Prediction = X°
      state "Compare" as Compare {
          direction LR
          ManualInput: User sets Y°
          PredictedSetpoint: Model predicts X°
          [*] -> Checking
          Checking -> NoOverride: if |X-Y| < Threshold
          Checking -> OverrideDetected: if |X-Y| >= Threshold
      }
      Idle --> Compare: On Manual Input
      NoOverride --> [*]
      OverrideDetected --> Logging
      Logging --> [*]
  

Variation 6: The "Inverse" Failure Mode - Authenticated Tamper Detection

• Enabling Description: The system is designed to differentiate between an authorized occupant's manual override and an unauthorized tamper. The thermostat is equipped with a Near Field Communication (NFC) reader or Bluetooth Low Energy (BLE) receiver. A manual change to the setpoint is only considered an "authorized override" if it occurs within a short window (e.g., 5 minutes) after a registered user authenticates by tapping their smartphone or a key fob to the thermostat. If a manual setpoint change is detected without a preceding authentication event, the system logs it as a "tamper alert." This alert is sent to the property owner with high priority and can trigger different actions, such as locking the thermostat's controls for a period or reverting to a secure baseline schedule. This is applicable in rental properties, public spaces, or commercial buildings.

• Mermaid.js Diagram:

  graph TD
      A[Manual Setpoint Change] --> B{Check for Recent Auth Event};
      B -- Yes --> C[Log as 'Authorized Override'];
      B -- No --> D[Log as 'Tamper Alert'];
      C --> E[Transmit to Server - Normal Priority];
      D --> F[Transmit to Server - High Priority];
      F --> G[Notify Property Owner & Lock Controls];
  

---

Derivative Disclosures Based on Core Claim 9: Adaptation of Future Setpoints Based on Manual Changes

Variation 7: Cross-Domain Application - Personalized Medicine Insulin Pump

• Enabling Description: An automated insulin pump system for a diabetic patient includes a controller that administers a basal rate of insulin according to a pre-programmed schedule. The system is connected to a Continuous Glucose Monitor (CGM). When the patient consumes an unscheduled meal, they manually trigger a bolus insulin dose. The pump's controller detects this manual override of the automated schedule. It logs the manual bolus amount, the time, and the patient's CGM reading at that moment. An adaptive algorithm on the controller or a paired smartphone app applies a rule: if a manual bolus override occurs at the same time of day (e.g., between 3-4 PM) for several consecutive days, the algorithm automatically adjusts the patient's future basal rate schedule to be slightly higher during that period, anticipating the behavior and reducing the need for manual intervention while improving glycemic control.

• Mermaid.js Diagram:

  sequenceDiagram
      Patient->>Pump: Manually administers Bolus (Override)
      Pump->>Pump: Logs Override (Time, Dose, CGM data)
      Pump->>Algorithm: Transmit Logged Event
      Algorithm->>Algorithm: Analyze pattern: Override at 3PM for 3 days?
      Algorithm->>Pump: IF pattern matches, THEN update future schedule
      Pump->>Pump: New schedule: Increase Basal rate at 3PM
  

Variation 8: Cross-Domain Application - Robotic Arm Path Correction

• Enabling Description: A collaborative robot (cobot) on an assembly line is programmed with a specific path of motion to pick and place a component. A human operator, using a handheld teach pendant, manually adjusts a point on the robot's path to avoid a slight drift in the position of an incoming part tray. The robot's motion controller detects this manual deviation from its programmed path (the "schedule"). The system logs the vector difference between the programmed point and the manually adjusted point. A rule-based adaptive engine determines if this same manual adjustment occurs for multiple consecutive cycles. If the pattern is confirmed, the system automatically rewrites the baseline program, shifting the target point to the new, operator-corrected position. This allows the robot to "learn" and adapt to persistent, minor variations in its environment without requiring a full reprogramming session.

• Mermaid.js Diagram:

  flowchart TD
      A[Robot Controller] -- Programmed Path --> B(Execute Motion)
      C[Human Operator] -- Manual Path Adjustment --> A
      A -- Compares Paths --> D{Deviation Detected?};
      D -- Yes --> E[Log Path Delta Vector];
      E --> F{Pattern Persists for N Cycles?};
      F -- Yes --> G[Update Baseline Program with New Path];
      F -- No --> A;
      G --> A;
  

Variation 9: Integration with Emerging Tech - Federated Learning for HVAC Schedules

• Enabling Description: A fleet of thermostats in a large residential complex operates without sending private user interaction data to a central server. Each thermostat has a local adaptive algorithm (e.g., a small neural network) that modifies its schedule based on its user's manual overrides. This is the local model. Periodically (e.g., once a week), each thermostat encrypts and transmits only the learned parameters (the weights and biases of its local model), not the user's personal data, to a central aggregation server. The server averages these parameters from thousands of thermostats to create an improved global model. This global model, which now contains generalized learnings about comfort preferences (e.g., "people tend to prefer cooler temperatures on sunny afternoons"), is then pushed back to all thermostats, providing them with a more intelligent starting point for their local adaptation. This is a privacy-preserving, collaborative learning approach.

• Mermaid.js Diagram:

  graph TD
      subgraph Thermostat 1
          A1[Local Override Data] --> B1(Local Model Training)
          B1 --> C1(Local Model v1.1)
      end
      subgraph Thermostat 2
          A2[Local Override Data] --> B2(Local Model Training)
          B2 --> C2(Local Model v1.1)
      end
      subgraph Thermostat N
          A3[...] --> B3(...)
          B3 --> C3(...)
      end
      C1 -- Model Weights --> D{Aggregation Server};
      C2 -- Model Weights --> D;
      C3 -- Model Weights --> D;
      D -- Averages Weights --> E(Global Model v2.0);
      E -- Pushes Updated Model --> C1;
      E --> C2;
      E --> C3;
  

Variation 10: Integration with Emerging Tech - Digital Twin Simulation Before Adaptation

• Enabling Description: A remote server maintains a "digital twin" of a building, which is a physics-based thermal model constantly updated with real-time sensor data. When a user manually overrides the thermostat setpoint, the event is sent to the server. Before the adaptive rules engine modifies the long-term schedule, it first runs a simulation. It proposes a potential schedule change (e.g., "lower the setpoint from 72°F to 70°F every weekday at 8 PM") and applies it to the digital twin. The simulation projects the impact of this change on energy consumption, cost, and time-to-temperature over the next week. The rules engine can then refine the schedule change based on the simulation outcome. For example, if the energy cost exceeds a certain threshold, it may adjust the change to 71°F instead of 70°F and present this optimized suggestion to the user for confirmation.

• Mermaid.js Diagram:

  sequenceDiagram
      User->>Thermostat: Manual Override
      Thermostat->>Server: Send Override Event
      Server->>RulesEngine: Propose Schedule Change
      RulesEngine->>DigitalTwin: Run Simulation with Proposed Change
      DigitalTwin->>RulesEngine: Return Projected Impact (Energy, Cost)
      RulesEngine->>RulesEngine: Refine change based on impact
      RulesEngine->>User: "Suggest new schedule: 71°F at 8 PM. OK?"
      User->>Server: Confirm
      Server->>Thermostat: Update Permanent Schedule
  

Variation 11: The "Inverse" Failure Mode - Graceful Degradation to Factory Schedule

• Enabling Description: The adaptive algorithm includes a self-monitoring "instability" counter. Every time a user manually overrides a setpoint that was created or modified by the adaptive algorithm within the last 24 hours, this counter increments. If the counter exceeds a predefined threshold (e.g., 5 adaptive overrides in one hour), the system determines that its learning process is unstable or is creating a schedule that conflicts with the user's true preferences. In this failure mode, the system automatically discards the entire learned schedule, reverts to a basic, non-adaptive factory default schedule (e.g., 72°F constant), and sends a notification to the user's mobile app stating, "The adaptive schedule has been disabled due to frequent manual changes. You can re-enable learning in the settings." This prevents a feedback loop of poor adaptations from frustrating the user.

• Mermaid.js Diagram:

  stateDiagram-v2
      state "Adaptive Mode" as Adaptive
      state "Safe Mode" as Safe
      [*] --> Adaptive
      Adaptive --> Adaptive: Manual Override of static schedule
      Adaptive --> Adaptive: Manual Override of adapted schedule (Counter++)
      Adaptive --> Safe: if Counter > 5
      Safe --> Adaptive: User re-enables learning
      Safe: Schedule = Factory Default
      Adaptive: Schedule = Learned + Adapted
  

---

Combination Prior Art with Open-Source Standards

Combination 1: MQTT with Home Assistant for Detection and Logging

• Enabling Description: A commercially available thermostat with an open firmware or API communicates using the ISO standard MQTT (Message Queuing Telemetry Transport) protocol. The thermostat publishes its full state, including the current measured temperature and the actual heating/cooling setpoint, to a specific topic (e.g., myhome/thermostat/state) on an MQTT broker. An instance of the open-source software Home Assistant, running on a local server, subscribes to this topic. A user defines their desired temperature schedule using Home Assistant's built-in scheduler. An automation rule written in YAML within Home Assistant is triggered on every state change from the thermostat. This rule compares the actual_setpoint from the MQTT payload with the value dictated by the Home Assistant schedule for the current time. If they differ, Home Assistant identifies this as a manual override and calls the logger service to write a detailed event to its log file (home-assistant.log) and simultaneously pushes the data into an InfluxDB (open-source time-series database) for long-term analysis and visualization. This combination fully reproduces the detection and logging method of claim 1 using standard open-source components.

Combination 2: Matter Protocol with Node-RED for Adaptation

• Enabling Description: A thermostat is built to be compliant with the Matter (formerly Project CHIP) open-source application layer standard. The thermostat exposes its functionality through the standardized Thermostat Device Type Cluster. It communicates over a network using the Thread open networking protocol. A Matter-compatible controller, such as a Raspberry Pi running an OpenThread Border Router, acts as the hub. The controller logic is implemented using the open-source visual programming tool Node-RED. A flow in Node-RED subscribes to attribute changes from the thermostat's setpoint cluster. Upon detecting a change not initiated by the controller itself, it recognizes a manual override. This event triggers a JavaScript function node in Node-RED containing the adaptation "rules." The function analyzes the override history (stored as a context variable) and computes a new future schedule. It then uses a Matter-specific Node-RED node to issue a WriteAttributes command to the thermostat's schedule cluster, thus modifying its future behavior as per claim 9.

Combination 3: TensorFlow Lite on Android for Edge-Based Learning

• Enabling Description: The adaptive learning logic of claim 9 is implemented as a machine learning model using the open-source TensorFlow framework. The model is then converted to the TensorFlow Lite (TFLite) format for efficient execution on resource-constrained devices. This TFLite model is embedded within an Android application running on a smart home hub or even a dedicated Android-powered thermostat. The thermostat's firmware communicates with the Android OS, reporting actual setpoint changes and receiving schedule updates. When a manual override is detected, the event data (timestamp, override delta, current temperature, etc.) is fed as input to the TFLite model. The model's inference process outputs a revised set of schedule points. The Android application then communicates this new schedule back to the thermostat's base-level firmware. This architecture combines an open-source ML framework and an open-source operating system to create the adaptive functionality.