Derivative works

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.