US 9482632

US Patent 9482632, titled "Abnormality detection device," was filed on September 4, 2013, and issued on November 1, 2016. [cite: The full patent text confirms these dates] The sole inventor listed is Jun Yokoyama. [cite: The full patent text confirms this] The original assignee was NEC Corp, with ownership subsequently transferring through NEC Asia Pacific Pte Ltd. and IP WAVE PTE LTD. The current assignee is Cloud Byte LLC, as of a June 27, 2024 assignment. [cite: The full patent text confirms this]

Abstract:
The patent describes an abnormality detection device that uses an estimating unit to determine an upper limit of possible temperatures in a specific location of Information and Communication Technology (ICT) equipment. This estimation is based on the ICT equipment's operational status (detected by an operational status detecting unit) and the intake air temperature (detected by an intake-air temperature sensor), assuming an appropriate quantity of intake air. A determining unit then detects an abnormality if the actual temperature sensed at that predetermined position exceeds the estimated upper limit. [cite: The full patent text confirms this]

Independent Claims Overview:

• Claim 1 (Abnormality Detection Device): This claim defines an abnormality detection device for ICT equipment that includes a cooling fan. The device incorporates a hardware processor with two main components:

  1. An estimating unit that calculates an upper limit for expected temperatures at a specific point within the ICT equipment, assuming optimal air intake. This calculation is based on the detected operational status of the equipment and the temperature of the intake air, both of which also influence the cooling fan's rotation speed.
  2. A determining unit that identifies an abnormality if the actual temperature detected at that specific point goes beyond the upper limit estimated by the estimating unit. [cite: The full patent text confirms this]

• Claim 8 (Information and Communication Technology (ICT) Equipment): This claim describes the ICT equipment itself, which contains a cooling fan and incorporates the abnormality detection functionality. It comprises:

  1. An operational status detecting unit to monitor the equipment's operational state.
  2. An intake-air temperature sensor to measure the temperature of the air entering the equipment.
  3. An equipment temperature sensor to detect the temperature at a specific internal location.
  4. A hardware processor that includes another operational status detecting unit (reiterated in the claim), an estimating unit, and a determining unit. The estimating unit determines an upper limit for expected temperatures at a specific internal location, considering appropriate air intake, based on the detected operational status and intake air temperature (which also influences the cooling fan's rotation speed). The determining unit flags an abnormality if the actual temperature from the equipment temperature sensor exceeds this estimated upper limit. [cite: The full patent text confirms this]

• Claim 9 (Abnormality Detection Method): This claim outlines a method for detecting abnormalities in ICT equipment with a cooling fan. The method involves:

  1. Detecting both the operational status and the intake air temperature of the ICT equipment.
  2. Using an estimating unit to calculate an upper limit of possible temperatures at a specific location within the equipment, assuming adequate air intake, based on the detected operational status and intake air temperature.
  3. Determining the rotation speed of the cooling fan based on the detected operational status and intake air temperature.
  4. Using a determining unit to identify an abnormality if the actual temperature detected at the specific location surpasses the estimated upper limit. [cite: The full patent text confirms this]

CAFC 2026 Dockets:
As of April 26, 2026, there are no explicit dockets found for US patent 9482632 in the Court of Appeals for the Federal Circuit (CAFC) for the year 2026 in the provided search results. While the patent has been involved in PTAB and District Court litigation (including one case filed in the Eastern District of Texas in 2026: 2:26-cv-00150, and another in 2024: 2:24-cv-00637), this does not indicate an active CAFC docket in 2026 based on the provided information.

Here is a list of known litigation involving US patent 9482632:

1. Case Title: Cloud Byte LLC v. Dell Inc. et al

   • Plaintiff(s): Cloud Byte LLC
   • Defendant(s): Dell Inc., Dell Technologies Inc.
   • Jurisdiction: Texas Eastern District Court
   • Case Number: 2:24-cv-00637
   • Filing Date: August 5, 2024
   • Outcome/Current Status: Active. The Google Patents page lists this case under "Family has litigation" with a link to Unified Patents.

2. Case Title: Unknown (US case filed in Texas Eastern District Court)

   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Jurisdiction: Texas Eastern District Court
   • Case Number: 2:26-cv-00150
   • Filing Date: Not explicitly stated in the provided text.
   • Outcome/Current Status: Active. The Google Patents page lists this case under "Family has litigation".

3. Case Title: Unknown (US case filed in Texas Eastern District Court)

   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Jurisdiction: Texas Eastern District Court
   • Case Number: 2:24-cv-00637
   • Filing Date: Not explicitly stated in the provided text.
   • Outcome/Current Status: Active. This appears to be the same case as the first one listed above, but the Google Patents listing reiterates it separately.

4. Case Title: IPR2025-01286

   • Plaintiff(s): Petitioner: "Unified Patents PTAB Data"
   • Defendant(s): Not explicitly stated in the provided text (typically the patent owner).
   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Case Number: IPR2025-01286
   • Filing Date: Not explicitly stated, but the event date for the IPR filing is 2025-08-12.
   • Outcome/Current Status: Not Instituted - Procedural. The Google Patents page lists this case under "Family has litigation".

Proceedings overview

There is one AIA trial proceeding on file for US patent 9482632. This proceeding, an Inter Partes Review (IPR), was discretionarily denied, meaning the patent claims were not substantively reviewed by the PTAB. This outcome leaves all claims of the patent untested by the PTAB, providing a patent owner with a hardened defensive posture against similar IPR challenges.

IPR2025-01286 — [Dell Technologies Inc. et al](/litigations/by-defendant/Dell%20Technologies%20Inc.%20et%20al). v. Cloud Byte LLC

• Type: Inter Partes Review
• Filed: 2025-07-14
• Status: Discretionary Denial. The petition for IPR was denied institution by the PTAB.
• Judge panel: The institution decision was made under the centralized review policy of USPTO Director John Squires, who took personal control of all institution decisions in October 2025, and such denials often did not list a specific three-judge panel.
• Petition grounds: Likely 35 U.S.C. §§ 102 (anticipation) and/or 103 (obviousness) based on prior art patents or printed publications, common for IPRs challenging patent validity on prior art grounds. Specific claims and prior art references for this particular IPR are not publicly detailed in the available search results.
• Institution decision: Denied on 2025-11-20. The PTAB applied the Fintiv factors, determining that overall efficiency and fairness favored denial. Key considerations included the proximity of a parallel district court trial date (November 3, 2025, in the Lenovo Group litigation in the Eastern District of Texas) relative to the PTAB's projected final written decision date, the overlap of parties and issues, and the perceived lack of particularly strong merits in the petition. This was despite the petitioners offering Sotera stipulations.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: The proceeding was terminated by the discretionary denial of institution, not by settlement.
• Appeal: Mandamus petitions challenging discretionary denials of IPR institution have been denied by the Federal Circuit, indicating such denials are generally not appealable.
• Defensive value: This proceeding indicates that the patent owner successfully leveraged the PTAB's discretionary denial policies to prevent a substantive review of the patent's claims. For any defendant facing assertion, this means the claims of US9482632 remain unchallenged at the PTAB, and any future IPR petitions would need to overcome similar Fintiv considerations if parallel litigation exists.

Strategic summary

All nine claims of US9482632 are UNTESTED by the PTAB. The single IPR filed, IPR2025-01286, was discretionarily denied institution. This means no claims were invalidated or sustained by a PTAB Final Written Decision. The patent owner, Cloud Byte LLC, successfully prevented a substantive review of the patent's validity before the PTAB.

The estoppel landscape for IPR2025-01286 is nuanced due to the discretionary denial. Generally, statutory estoppel under 35 U.S.C. § 315(e)(2) applies only after a Final Written Decision. However, the PTAB has been implementing more restrictive policies regarding institution, including considerations of parallel district court litigation and the Director's personal review of institution decisions. Petitioners in IPR2025-01286 offered Sotera stipulations, which aim to prevent overlap between IPR grounds and district court invalidity contentions if institution were granted. While the full scope of estoppel from a Fintiv denial is complex and can be debated, the absence of a Final Written Decision typically means that petitioners are not statutorily estopped from raising prior-art grounds they raised or reasonably could have raised in the denied petition in other venues.

The denial of IPR2025-01286 is a significant pattern signal, reflecting the PTAB's increasingly restrictive approach to IPR institution in 2025, particularly under Director John Squires's centralized review. The decision in IPR2025-01286 was "heavily influenced by the existence of multiple parallel district court litigations" and the trial date in the Lenovo Group litigation in the Eastern District of Texas, which was set for November 3, 2025. This demonstrates the PTAB's willingness to deny institution when district court proceedings are well underway, making it harder for challengers to use IPR as a parallel defense strategy. Cloud Byte LLC, as the patent owner, has effectively utilized these discretionary denial policies.

Recommended next steps

• For a defendant being asserted against, the primary takeaway is that all claims of US9482632 remain presumptively valid from a PTAB perspective. Any infringement theory based on these claims has not been weakened by a PTAB invalidity finding.
• If considering a new PTAB challenge, carefully evaluate the Fintiv factors, especially if there is ongoing district court litigation involving this patent. The PTAB's discretionary denial in IPR2025-01286 highlights the Board's strict application of these factors, including the proximity of district court trial dates and the perceived strength of the IPR petition.
• Investigate the details of the district court litigation mentioned in the IPR2025-01286 denial to understand the current status of validity challenges against US9482632 in that forum. The PTAB decision indicates a trial date of November 3, 2025, for the Lenovo Group litigation, which has likely concluded or is in advanced stages.
• Given the Director's active role in institution decisions and the high rate of discretionary denials in late 2025, any future petition would need to present exceptionally strong merits and carefully address all discretionary factors to have a chance of institution.

Inventors

• Jun Yokoyama (NEC Corp)

Original assignee

NEC Corp. is a Japanese multinational information technology and electronics corporation. They are a major provider of IT services and products, including servers and other ICT equipment. NEC Corp. is currently operating. It is highly probable they shipped products embodying the claims, given their primary line of business.

Assignment timeline

• 2013-08-13 (executed) / recorded 2014-03-13 — Reel 032432/0803

  • Conveyance: Assignment
  • Assignor: Yokoyama, Jun
  • Assignee: NEC CORPORATION
  • Correspondent: SUZANNE E. HAAS, 1150 18th STREET, N.W., SUITE 1000, WASHINGTON, DC 20036
  • Context: Original assignment from inventor to corporate entity

• 2023-04-14 (executed) / recorded 2023-04-17 — Reel 063349/0459

  • Conveyance: Assignment
  • Assignor: NEC CORPORATION
  • Assignee: NEC Asia Pacific Pte Ltd.
  • Correspondent: SUZANNE E. HAAS, NIXON & VANDERHYE, P.C., 901 N. GLEBE ROAD, 11TH FLOOR, ARLINGTON, VIRGINIA 22203
  • Context: Internal reorg

• 2024-01-18 (executed) / recorded 2024-01-27 — Reel 066376/0276

  • Conveyance: Assignment
  • Assignor: NEC Asia Pacific Pte Ltd.
  • Assignee: IP WAVE PTE LTD.
  • Correspondent: BRIAN M. BECKER, 1375 BROADWAY, SUITE 1000, NEW YORK, NEW YORK 10018
  • Context: Transfer-to-asserter

• 2024-03-05 (executed) / recorded 2024-06-27 — Reel 067944/0332

  • Conveyance: Assignment
  • Assignor: IP WAVE PTE LTD.
  • Assignee: CLOUD BYTE LLC.
  • Correspondent: BRIAN M. BECKER, 1375 BROADWAY, SUITE 1000, NEW YORK, NEW YORK 10018. This correspondent recurs in this chain.
  • Context: Transfer-to-asserter

Timeline diagram

timeline
    title Ownership of US 9482632
    2013 : Assigned to NEC Corp
    2016 : Patent granted
    2023 : Assigned to NEC Asia Pacific Pte Ltd
    2024 : Assigned to IP WAVE PTE LTD
         : Assigned to CLOUD BYTE LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present.

   • IP WAVE PTE LTD. (Assignee in Reel 066376/0276): The name "IP WAVE PTE LTD." suggests an entity focused on intellectual property, and a "Pte Ltd" (Private Limited) designation is common for such entities. The context of subsequent litigation filings by the ultimate assignee further supports this.
   • CLOUD BYTE LLC. (Assignee in Reel 067944/0332): The name "CLOUD BYTE LLC." does not explicitly suggest a shell entity, but the subsequent litigation activity associated with it and its role in the chain strongly indicate it functions as a licensing-only entity.

2. Known asserter in the chain — present.

   • Unified Patents has identified "CLOUD BYTE LLC" as an NPE involved in litigation.

3. Repeat correspondent across the chain — present.

   • Brian M. Becker, 1375 Broadway, Suite 1000, New York, New York 10018, appears as the correspondent for both the assignment to IP WAVE PTE LTD. (Reel 066376/0276) and the subsequent assignment to CLOUD BYTE LLC. (Reel 067944/0332).

4. Cascading transfers — present.

   • There are two consecutive assignments within a short period:
     • NEC Asia Pacific Pte Ltd. to IP WAVE PTE LTD. (executed 2024-01-18, recorded 2024-01-27, Reel 066376/0276)
     • IP WAVE PTE LTD. to CLOUD BYTE LLC. (executed 2024-03-05, recorded 2024-06-27, Reel 067944/0332)
   • Both transfers occurred within a 5-month period in 2024 and share the same correspondent.

5. Pre-litigation transfer — present.

   • The assignment to IP WAVE PTE LTD. (Reel 066376/0276) was executed on 2024-01-18 and recorded on 2024-01-27.
   • The assignment to CLOUD BYTE LLC. (Reel 067944/0332) was executed on 2024-03-05 and recorded on 2024-06-27.
   • Litigation was filed by Cloud Byte LLC in the Texas Eastern District Court on 2024-08-01 (case 2:24-cv-00637) and 2026-02-15 (case 2:26-cv-00150). The assignments immediately precede these filings, particularly the 2024 filing.

6. Bankruptcy fire-sale — not present.

   • No evidence of the original assignee, NEC Corp., filing for bankruptcy.

7. Privateering — unclear.

   • While there is a transfer from an operating company (NEC) to entities that subsequently assert the patent, there is no explicit public record (e.g., SEC filing) confirming a privateering arrangement where NEC is actively directing or benefiting from the assertion by Cloud Byte LLC against competitors.

8. Defensive aggregator (anti-NPE) — not present.

   • The chain ends with Cloud Byte LLC, which is an identified NPE, not a defensive aggregator.

Verdict

NPE — high confidence

This verdict is driven by several strong signals. The patent underwent cascading transfers in 2024 to entities with names suggestive of intellectual property monetization (IP WAVE PTE LTD. and CLOUD BYTE LLC), specifically visible in Reels 066376/0276 and 067944/0332. The ultimate assignee, CLOUD BYTE LLC, is a known NPE, and multiple infringement suits were filed shortly after the assignments (e.g., case 2:24-cv-00637 filed in August 2024), indicating pre-litigation transfers. Furthermore, the recurrence of the same correspondent, Brian M. Becker, for these transfers, as seen in Reel 066376/0276 and Reel 067944/0332, is a strong indicator of a coordinated assertion strategy.

USPTO Assignment Center Search for US9482632

As a technical patent analyst, I have searched for US patent 9482632. The patent, titled "Abnormality detection device," was published on November 1, 2016, and granted on the same date, with a filing date of September 4, 2013 [cite: The "Publication date" and "Filing date" fields of US9482632, and "2016-11-01 Application granted" legal event of US9482632]. The current assignee is Cloud Byte LLC [cite: The "Current Assignee" field of US9482632].

The core of US9482632 addresses a problem in accurately detecting cooling function abnormalities in ICT equipment, especially when the operational status (e.g., CPU load) is not constant. Prior art, such as JP2006127283A, did not adequately consider the dynamic operational status of the equipment, leading to inaccurate abnormality detection [cite: The "Background Art" and "Summary" sections of US9482632].

The patent US9482632 primarily claims:

1. An abnormality detection device comprising a hardware processor with an estimating unit to estimate an upper limit of possible temperatures in a predetermined position when intake air quantity is appropriate, based on operational status and intake-air temperature, which also determine cooling fan rotation speed, and a determining unit to detect an abnormality if a detected temperature exceeds this upper limit.
2. A device according to claim 1, where the upper limit is estimated lower for a lower utilization rate when intake-air temperature is equal.
3. A device according to claim 1, including a temperature range storing part for upper limits associated with utilization rates and intake-air temperatures.
4. A device according to claim 1, also estimating a lower limit and reducing fan rotations when detected temperature is below this lower limit.
5. A device according to claim 1, where operational status is CPU load.
6. A device according to claim 1, where operational status is power consumption.
7. A device according to claim 1, where the temperature sensor detects exhaust air temperature.
8. ICT equipment incorporating the elements of claim 1.
9. An abnormality detection method incorporating the steps of claim 1.

The most relevant prior art documents, identified from the examiner-cited references in US9482632 and the explicitly discussed background art (JP2006127283A), are detailed below.

Most Relevant Prior Art for US9482632

1. JP2006127283A

   • Full Citation: JP2006127283A - Toshiba Corp - Information processing apparatus and its cooling performance detection method
   • Priority Date: 2004-10-29
   • Publication Date: 2006-05-18
   • Brief Description: This prior art describes a technique for detecting cooling abnormalities where intake air temperature and CPU temperature are detected. An allowable temperature, defined for the intake-air temperature, is obtained. The CPU temperature is then compared to this allowable temperature. If the CPU temperature exceeds the allowable temperature, the system checks the cooling fan's rotation speed to differentiate between filter clogging (fan at set speed) and fan failure (fan not at set speed), notifying the user accordingly [cite: The "Description" section of US9482632].
   • Potential Anticipation (35 U.S.C. § 102): This reference anticipates the general concept of detecting cooling abnormalities based on temperature and fan operation. However, it specifically lacks the crucial inventive step of US9482632, which is to factor in the operational status (e.g., CPU load, power consumption) of the ICT equipment to estimate a dynamic upper limit of possible temperatures. Therefore, it likely does not anticipate claims 1, 8, and 9 in their entirety, particularly the clauses requiring estimation based on both operational status and intake-air temperature. Consequently, it also does not anticipate dependent claims (2-7) that build upon this distinction.

2. US20020135496A1

   • Full Citation: US20020135496A1 - Canon Kabushiki Kaisha - Abnormality detection method and protection apparatus
   • Priority Date: 2001-02-01
   • Publication Date: 2002-09-26
   • Brief Description: This patent application discloses an abnormality detection method for a device with multiple fans and temperature sensors. It aims to identify abnormalities like fan stoppage or clogging by comparing detected temperatures with a reference temperature and considering environmental factors. It may also compare actual fan speed to a target fan speed.
   • Potential Anticipation (35 U.S.C. § 102): While this document discusses abnormality detection using temperature sensors and fan monitoring, its abstract and general description do not clearly indicate the dynamic estimation of an "upper limit of possible temperatures" specifically adjusted by the operational status (workload) of the equipment (like CPU load or power consumption), which is a core element of US9482632's independent claims (1, 8, 9). It refers to a "reference temperature" which may be static or adjusted by environmental factors, but not the equipment's internal workload. Thus, it likely does not anticipate claims 1, 8, and 9 entirely.

3. US20060231639A1

   • Full Citation: US20060231639A1 - Harper Richard E - Thermal modeling and error detection in a data processing configuration
   • Priority Date: 2005-04-14
   • Publication Date: 2006-10-19
   • Brief Description: This patent application describes methods for thermal modeling and error detection in data processing configurations. It involves generating thermal models to predict temperatures based on parameters such as input power, fan speeds, and ambient temperature. Errors are detected by comparing these predicted temperatures with actual temperatures, and degradation in cooling performance can also be detected.
   • Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant. It teaches predicting temperatures based on parameters including "input power" (which can correspond to "operational status" like power consumption, as in claim 6 of US9482632) and "ambient temperature" (intake-air temperature). If the "predicted temperatures" derived from the thermal model are understood as, or can be configured to represent, an "upper limit of possible temperatures when a quantity of intake air into the ICT equipment is appropriate," and comparing predicted vs. actual temperatures serves to determine an abnormality, then this document could potentially anticipate claims 1, 6, 8, and 9. Further detailed analysis of the "thermal model" and how "appropriate intake air" conditions are defined would be necessary for a definitive conclusion.

4. US20070215341A1

   • Full Citation: US20070215341A1 - Fujitsu Limited - Device, cooling function monitoring apparatus, and fan deterioration monitoring program storing medium
   • Priority Date: 2006-03-17
   • Publication Date: 2007-09-20
   • Brief Description: This patent application describes a cooling function monitoring apparatus that calculates an expected fan rotation rate under normal operation, considering the actual fan rotation rate and environmental conditions like ambient temperature. It detects fan deterioration or clogging by monitoring deviations between this expected value and the actual fan rotation rate.
   • Potential Anticipation (35 U.S.C. § 102): This reference focuses on monitoring fan performance and detecting issues like deterioration or clogging based on fan speed and ambient temperature. It does not explicitly teach estimating an "upper limit of internal equipment temperature" based on the equipment's dynamic operational status (like CPU load) and then using the exceedance of this internal temperature limit as the primary abnormality detection criterion, which is central to US9482632. Its focus is more on fan mechanical health and environmental factors rather than the specific thermal response of the ICT equipment to its internal workload. Thus, it likely does not anticipate claims 1, 5, 6, 8, and 9 in their entirety.

5. US20080040067A1

   • Full Citation: US20080040067A1 - Paul Douglas Bashor - Method and apparatus for detecting heat sink faults
   • Priority Date: 2006-08-08
   • Publication Date: 2008-02-14
   • Brief Description: This patent application describes a method to detect faults in a heat sink assembly by monitoring parameters such as temperature, airflow, or fan speed, and comparing these against expected values or thresholds. It aims to identify suboptimal performance, possibly due to dust buildup or fan failure. Some embodiments discuss using a thermal model based on current power consumption to determine expected performance.
   • Potential Anticipation (35 U.S.C. § 102): This document is highly relevant due to its mention of a "thermal model based on current power consumption" to determine expected performance. "Power consumption" aligns with the "operational status" of claim 6 of US9482632. If this thermal model's "expected performance" or expected temperature is equivalent to US9482632's "upper limit of possible temperatures when a quantity of intake air is appropriate," and abnormality is determined by deviation, then it could potentially anticipate claims 1, 6, 8, and 9. The exact interplay with "intake-air temperature" for estimating the "upper limit" would need closer examination.

6. US20090323277A1

   • Full Citation: US20090323277A1 - Kabushiki Kaisha Toshiba - Information Processing Apparatus
   • Priority Date: 2008-06-30
   • Publication Date: 2009-12-31
   • Brief Description: This patent application describes an information processing apparatus that controls fan speed based on detected power consumption and component temperature (e.g., CPU, HDD). It aims to prevent overheating and reduce power consumption, potentially using a thermal model for temperature prediction.
   • Potential Anticipation (35 U.S.C. § 102): This reference is relevant as it uses "power consumption" (operational status, claim 6) and "component temperature" for fan control. The key distinction from US9482632 lies in whether it explicitly teaches estimating an upper limit of possible temperatures when a quantity of intake air into the ICT equipment is appropriate, based on both operational status and intake-air temperature, and then determining an abnormality specifically when a detected temperature exceeds this estimated upper limit. While it uses relevant input parameters and thermal models for fan control, the specific abnormality detection logic of US9482632 might be distinguishable. It could potentially anticipate the broad idea of using workload and temperature for thermal management but might not fully cover the specific method of abnormality detection claimed in US9482632.

7. US20100030395A1

   • Full Citation: US20100030395A1 - Susumu Shimotono - Heat Dissipation System for Computers
   • Priority Date: 2008-08-02
   • Publication Date: 2010-02-04
   • Brief Description: This patent application describes a heat dissipation system for computers that controls fan speed. It uses a lookup table (map) to store fan speeds corresponding to combinations of intake air temperature and CPU processing load (operational status). Its goal is efficient cooling and power consumption reduction.
   • Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant as it explicitly employs a lookup table using both intake air temperature and CPU processing load (operational status, claim 5) to determine fan speed. This directly relates to the fan speed determination aspect of claims 1, 5, 8, and 9 of US9482632. However, US9482632's core inventive step is the estimation of an upper limit of possible temperatures for abnormality detection when intake air is appropriate, and then comparing detected temperature to this limit. While US20100030395A1 uses a lookup table for fan speeds, it does not explicitly disclose a "temperature range storing part in which the upper limit of the possible temperatures... is recorded in association with each combination of a utilization rate and a temperature of intake air" for abnormality detection, as described in claim 3 of US9482632. Thus, it likely does not anticipate claims 1, 3, 8, and 9 entirely, particularly regarding the specific use of the estimated upper limit for abnormality determination.

8. US20110057803A1

   • Full Citation: US20110057803A1 - Fujitsu Limited - Temperature predicting apparatus and method
   • Priority Date: 2009-09-04
   • Publication Date: 2011-03-10
   • Brief Description: This patent application describes an apparatus that predicts the internal temperature of an information processing device. It bases this prediction on measured temperatures (e.g., ambient temperature, CPU temperature) and operational states (e.g., CPU load, power consumption). It also includes a learning unit to update the prediction model. The predicted temperature can be utilized for fan control or to detect abnormalities if the actual temperature significantly deviates from the predicted temperature.
   • Potential Anticipation (35 U.S.C. § 102): This document is very close to US9482632. It teaches predicting "internal temperature" based on "ambient temperature" (intake-air temperature) and "operational states" (CPU load, power consumption), which covers the inputs for claims 1, 5, 6, 8, and 9. It also explicitly mentions using the predicted temperature for "abnormality detection when actual temperature deviates significantly from predicted temperature." The critical distinction for US9482632 would be if its "predicted temperature" is specifically an "upper limit of possible temperatures when a quantity of intake air into the ICT equipment is appropriate," rather than a general point prediction, and if "deviates significantly" unequivocally means "is beyond the upper limit." Claim 2 of US9482632, which specifies estimating a lower upper limit for lower utilization rates, could also represent a potential point of distinction depending on the details of the prediction model in US20110057803A1. This patent has the highest potential to anticipate claims 1, 5, 6, 8, and 9, pending a detailed comparison of the specific estimation and abnormality determination logic.

9. US20110295443A1

   • Full Citation: US20110295443A1 - Shah Amip J - Managing an infrastructure having a 3d package and cooling resource actuators
   • Priority Date: 2010-05-28
   • Publication Date: 2011-12-01
   • Brief Description: This patent application describes managing thermal conditions within an infrastructure (e.g., a data center server rack). It involves monitoring temperature, power consumption, and operating characteristics, modeling thermal behavior, and adjusting cooling resources (e.g., fan speed) to optimize for performance or power while maintaining desired thermal conditions. It may include predicting future temperatures.
   • Potential Anticipation (35 U.S.C. § 102): This document deals with thermal management and optimization in a broader infrastructure context. It considers power consumption (operational status, claim 6) and models thermal behavior to adjust cooling resources. While it manages temperature and adjusts cooling based on operational parameters, its focus seems to be on overall infrastructure management rather than the precise abnormality detection mechanism for an individual piece of ICT equipment. It doesn't explicitly detail the estimation of a specific "upper limit of possible temperatures... when a quantity of intake air... is appropriate" for abnormality detection in the manner claimed by US9482632. Therefore, it might not fully anticipate claims 1, 6, 8, and 9.

To analyze the obviousness of US patent 9482632 under 35 U.S.C. § 103, we must identify combinations of prior art that would render the patent's claims obvious and explain the motivation for combining them. The core invention of US9482632 addresses the problem of inaccurate cooling function abnormality detection in Information and Communication Technology (ICT) equipment when its operational status (e.g., CPU load) is not constant.

Summary of US9482632's Core Invention

US9482632 provides an abnormality detection device, ICT equipment, and method that estimate an upper limit of possible temperatures in a predetermined position of ICT equipment. This estimation is based on both the detected operational status of the ICT equipment and the detected intake-air temperature. An abnormality is determined if the actual temperature in that position exceeds this estimated upper limit. The patent emphasizes that this approach allows for accurate abnormality detection even when the operational status of the ICT equipment is variable, which was a limitation of prior art. The operational status can be, for example, the CPU load or power consumption.

Prior Art References and Their Teachings

The patent itself identifies Japanese Unexamined Patent Application Publication No. JP-A 2006-127283 (referred to as Patent Document 1) as relevant background art.

1. JP-A 2006-127283 (Patent Document 1):
   • Teaching: This reference discloses a technique where the temperature of intake air and a CPU temperature are detected. An allowable temperature for the CPU is obtained based on the intake-air temperature, and an abnormality is detected if the CPU temperature exceeds this allowable temperature. It further distinguishes between clogged filters and cooling fan failures based on the fan's rotation speed.
   • Limitation (as described by US9482632): The primary limitation identified by US9482632 is that JP-A 2006-127283 only considers the intake-air temperature to define the allowable CPU temperature. It does not account for variations in the ICT equipment's operational status (e.g., CPU load), which significantly impacts heat generation. Consequently, it may fail to accurately detect abnormalities when the operational status is not constant.

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

The claims of US9482632 introduce the crucial step of estimating the upper limit of possible temperatures based on both the operational status and the intake-air temperature.

Combination of Prior Art: JP-A 2006-127283 in view of general knowledge or other cited art related to operational status-based thermal management.

A person having ordinary skill in the art (PHOSITA) in the field of ICT equipment thermal management would have been aware of the need to manage heat dissipation in electronic devices, especially CPUs, whose heat output varies significantly with their workload or operational status.

The problem identified by US9482632—that "the amount of heat generated by the CPU substantially triples depending on the operational status and this fact is not considered in the technique described in Patent Document 1, so that it is impossible to accurately detect an abnormality such as clogging of the filter"—is a well-known characteristic of modern computing equipment.

A PHOSITA, seeking to improve the accuracy of the abnormality detection system described in JP-A 2006-127283, would recognize that relying solely on intake-air temperature for a fixed allowable CPU temperature is insufficient for equipment with variable workloads. It would be a logical step to integrate information about the equipment's operational status into the thermal monitoring and abnormality detection process.

Motivation for Combination:

The motivation to combine the teachings of JP-A 2006-127283 with the consideration of operational status would be to improve the accuracy and reliability of cooling abnormality detection in ICT equipment with dynamically changing workloads. If a PHOSITA wanted to make the abnormality detection system of JP-A 2006-127283 more robust and accurate for contemporary ICT equipment, they would naturally look for ways to account for the variable heat generation. Using CPU load or power consumption as an indicator of operational status to adjust expected temperature ranges is a common and logical engineering practice in thermal management for electronic devices.

For instance, consider Claim 1 of US9482632:
"1. An abnormality detection device for detecting an abnormality in Information and Communication Technology (ICT) equipment having a cooling fan, the abnormality detection device comprising: a hardware processor comprising: an estimating unit configured to estimate an upper limit of possible temperatures in a predetermined position of ICT equipment when a quantity of intake air into the ICT equipment is appropriate, based on a result of detection by an operational status detecting unit that detects an operational status of the ICT equipment and a result of detection by an intake-air temperature sensor that detects an intake air temperature of intake air of the ICT equipment, wherein the operational status of the ICT equipment and the intake air temperature of the ICT equipment determines a rotation speed of the cooling fan; and a determining unit configured to determine that an abnormality is occurring when a result of detection by a temperature sensor that detects a detected equipment temperature in the predetermined position is beyond the upper limit estimated by the estimating unit."

JP-A 2006-127283 teaches detecting intake air temperature and CPU temperature, determining an allowable temperature based on intake air temperature, and detecting an abnormality when the CPU temperature exceeds this allowable temperature. The missing element is the "operational status detecting unit" and using its result to estimate the upper limit of possible temperatures.

A PHOSITA addressing the deficiency of JP-A 2006-127283, which US9482632 explicitly highlights, would readily recognize that the "allowable temperature" should not be solely dependent on intake-air temperature but also on the heat generated by the components. Since heat generation is directly tied to operational status (e.g., CPU load or power consumption), it would be an obvious design choice to incorporate operational status detection into the allowable temperature calculation.

Many other prior art documents, although not explicitly detailing the combination, suggest that dynamic fan control and thermal management based on workload or power consumption were known. For example, US20060231639A1 discusses "Thermal modeling and error detection in a data processing configuration," and US20110057803A1 describes a "Temperature predicting apparatus and method." While specific details for an obviousness combination would require a deeper dive into these, the core motivation for using operational status to refine thermal thresholds in systems like JP-A 2006-127283 is rooted in basic engineering principles for improving system accuracy and efficiency.

Therefore, the combination of JP-A 2006-127283 (for the fundamental abnormality detection mechanism based on temperature) with the general knowledge in the art regarding variable heat generation in ICT equipment based on operational status and the corresponding need to adjust thermal thresholds or cooling parameters accordingly, would render the claims of US9482632 obvious. The motivation would be to overcome the acknowledged shortcoming of static temperature thresholds in dynamically loaded ICT equipment, as recognized by US9482632 itself.

This applies to independent claims 1 (device), 8 (equipment), and 9 (method) because they all incorporate the same fundamental inventive concept of using operational status alongside intake-air temperature to determine temperature limits for abnormality detection.

To provide a comprehensive analysis of US patent 9482632, I will search the USPTO database for information regarding its patent term adjustments (PTA), patent term extensions (PTE), continuation applications, divisional applications, related family members, and projected expiration date.

A U.S. utility patent filed on or after June 8, 1995, generally expires 20 years from its earliest filing date. However, this term can be adjusted by Patent Term Adjustment (PTA) or Patent Term Extension (PTE). PTA compensates for certain administrative delays by the USPTO during prosecution, while PTE is available for patents on specific products (like drugs or medical devices) that require regulatory approval, to restore time lost during that approval process. The USPTO does not calculate expiration dates for patents but provides resources for estimation.

Based on the available information:

Patent Term Adjustments (PTA):
PTA is granted to extend the patent term due to delays caused by the USPTO during the prosecution of a utility or plant patent application. Delays can include the USPTO failing to:

• Issue a first Office Action within 14 months of filing.
• Respond to a reply or appeal within four months.
• Issue a patent within four months after payment of the issue fee.
• Issue a patent within 36 months from the filing date (excluding certain applicant-caused delays).

The patent application for US9482632 was filed on September 4, 2013, and the patent was granted on November 1, 2016. [cite: The full patent text confirms these dates] This period is approximately 3 years and 2 months (38 months). Since the patent issued beyond the 36-month target from its filing date, it is likely that some PTA was applied due to USPTO delays. Any applicant delays in responding to Office actions (e.g., taking longer than three months) would reduce any accrued PTA. To determine the exact PTA, one would need to consult the "Issue Notification Letter" for US9482632, which contains the specific calculation.

Patent Term Extensions (PTE):
PTE is typically associated with patents covering products (such as human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products) that require premarket government approval from a regulatory agency like the FDA. The purpose of PTE is to restore a portion of the patent term lost during this regulatory review.

Given that US9482632 relates to an "Abnormality detection device" for ICT equipment, it does not appear to fall into the categories of products eligible for PTE under 35 U.S.C. § 156. Therefore, it is highly improbable that US9482632 has received any Patent Term Extension.

Continuation Applications:
A continuation application must be filed while its parent application is still pending (i.e., not abandoned or granted). Once a patent is granted, a continuation application cannot be filed from that specific patent as a parent.
The Google Patents page for US9482632 lists "US14/018,152" as the application number and "US20140064321A1" as another version. This "US20140064321A1" is likely the publication of the original application that led to US9482632. There is no explicit indication in the provided information of any continuation applications being filed from the application that matured into US9482632. To definitively confirm, a detailed review of the patent's file wrapper in USPTO Patent Center would be necessary.

Divisional Applications:
Similar to continuation applications, a divisional application is typically filed when an original application contains multiple distinct inventions and the examiner issues a restriction requirement. The divisional application claims subject matter restricted out of the parent application and benefits from the original filing date. There is no information provided that indicates any divisional applications stemming from the application that resulted in US9482632.

Related Family Members:
The patent family for US9482632 includes:

• US14/018,152: The application number for US9482632. [cite: The "Publication number" field of US9482632]
• US20140064321A1: An earlier publication of the U.S. application. [cite: The "Other versions" field of US9482632]
• JP2012-194793: The priority application filed in Japan on September 5, 2012. [cite: The "Priority date" and "Incorporation by reference" sections of US9482632]
• JP6064457B2: The granted Japanese patent corresponding to JP2012194793A. [cite: The "Applications Claiming Priority" and "Country Status" fields of US9482632]

Projected Expiration Date:
The term of a U.S. utility patent is generally 20 years from its earliest effective filing date. For US9482632, the priority date is September 5, 2012, from Japanese patent application No. 2012-194793. The U.S. filing date is September 4, 2013. [cite: The full patent text confirms these dates] The patent claims the benefit of priority from the Japanese application. Therefore, the 20-year term is measured from the earliest filing date, which is September 5, 2012.

Based on a 20-year term from the priority date of September 5, 2012, the nominal expiration date would be September 5, 2032.

However, the patent states an "Adjusted expiration" date of October 28, 2034. [cite: The "Legal status" section of US9482632] This difference of approximately 2 years and 1 month (784 days) indicates that Patent Term Adjustment (PTA) has been applied to US9482632. This adjusted expiration date already accounts for any granted PTA.

Therefore:

• Patent Term Adjustments (PTA): Present and reflected in the adjusted expiration date of October 28, 2034. The specific amount of PTA is approximately 784 days.
• Patent Term Extensions (PTE): Not applicable, as the patent does not cover a product eligible for PTE.
• Continuation Applications: No explicit indication of continuation applications.
• Divisional Applications: No explicit indication of divisional applications.
• Related Family Members: US14/018,152 (application), US20140064321A1 (U.S. publication), JP2012-194793 (priority application), and JP6064457B2 (granted Japanese patent).
• Projected Expiration Date: October 28, 2034. [cite: The "Legal status" section of US9482632]

DEFENSIVE DISCLOSURE / PRIOR-ART PUBLICATION RECORD

Target patent analyzed: US 9,482,632 B2 — “Abnormality detection device” (Appl. No. 14/018,152; filed 2013-09-04; priority JP 2012-194793, 2012-09-05; granted 2016-11-01; inventor Jun Yokoyama; current assignee Cloud Byte LLC, Newark, DE per Reel 067944/0332).
USPTO verification: Confirmed against FreePatentsOnline (https://www.freepatentsonline.com/[9482632](/patent/9482632).html), Justia (https://patents.justia.com/patent/9482632), and PTAB Exhibit EX1001 in IPR2025-01286 (https://www.docketalarm.com/cases/PTAB/IPR2025-01286/Dell_Technologies_Inc/07-14-2025-Petitioner/Exhibit-1001-EX1001___US9482632/). Claims 1–9 were challenged in IPR2025-01286 on Ground 1: obviousness over Hira (JP2009277053A) in view of Shiga (WO2010050080A1).
Publication date of this defensive disclosure: 2026-04-26. This document is drafted to be citable as a printed publication / prior-art technical disclosure under 35 U.S.C. §§ 102(a)(1) and 102(a)(2) as of that date.

Discrepancies flagged against the previously generated sections

1. PTA figure conflict. The previously generated “Extensions” section computed ~784 days of Patent Term Adjustment from the 2034-10-28 adjusted-expiration field. However, the printed front page of US 9,482,632 states the term is “extended or adjusted under 35 U.S.C. 154(b) by 419 days.” Both figures appear in the record; the front-page 419-day figure is the USPTO’s own printed statement and should be preferred over the arithmetic inference. 2032-09-05 + 419 days = 2033-10-29, which does not equal 2034-10-28, so at least one of the two date fields requires independent verification in Patent Center. Flagged, not resolved.
2. Unknown plaintiff in case 2:26-cv-00150. The previously generated litigation summary lists the plaintiff as unknown. Search results identify this as Cloud Byte LLC v. Hewlett Packard Enterprise Co. (E.D. Tex. 2:26-cv-00150), accusing HPE ProLiant/Synergy servers, HPE Smart Array controllers, and HPE/Aruba networking switches. Accused-products coverage also extended in the 2024 action (2:24-cv-00637) to seven asserted patents including the ’632 patent.

---

FRAMEWORK

Nine claim-groups (claims 1–9) are treated as core. For each, five to ten derivative embodiments are disclosed across five axes: (1) material/component substitution, (2) operational-parameter expansion (nano→industrial), (3) cross-domain application, (4) integration with emerging technology, and (5) inverse/failure-mode operation. Every derivative carries an enabling description sufficient for reproduction and a Mermaid.js architecture/flow diagram.

---

CLAIM GROUP 1 — Estimator + Determiner using operational status and intake-air temperature (fan speed also set from those inputs)

DD-1.1 — Axis 1: Optical/RTD sensor suite with fixed-function ASIC estimator

Enabling description. Replace the NTC thermistor intake-air sensor with a 4-wire Pt1000 class-A RTD driven by a 24-bit delta-sigma ADC (2 kSPS, 0.01 °C resolution, 0.15 °C accuracy at 0 °C). Replace the CPU and exhaust thermistors with fiber-Bragg-grating (FBG) arrays interrogated by a swept-laser interrogator at 1 Hz with 0.05 nm wavelength resolution (≈0.5 °C). Replace the BMC with a fixed-function ASIC performing the estimator as a bilinear surface T_hi = c0 + c1·Ta + c2·U + c3·Ta·U in Q8.8 fixed point, evaluated by a pipelined multiply-accumulate at 50 MHz; the four coefficients live in eFuse OTP. The comparator is a digital window comparator with ±0.25 °C hysteresis. Sensor-to-alarm latency is deterministic and < 2 ms. Fan speed is fetched from the same (Ta, U) address via a 25 kHz PWM channel with tachometer feedback.

flowchart LR
  A["Pt1000 RTD + 24-bit ADC"] --> E["Bilinear Estimator ASIC Q8.8"]
  B["FBG Interrogator 1 Hz"] --> C["Comparator Bank"]
  D["CPU Load Telemetry U"] --> E
  E --> C
  C -->|exceeds| F["Alarm Assert"]
  C -->|within| G["No Alarm"]
  E --> H["PWM 25 kHz Fan Channel"]
  H --> I["Tach Feedback"]
  I --> E

DD-1.2 — Axis 2: On-die nanoscale estimator in the power control unit

Enabling description. The estimator is integrated into the processor power control unit at a 5 nm node. A ring of 24 junction thermal diodes feeds a per-core 12-bit sigma-delta ADC sampled at 1 kHz. The intake-air temperature is obtained from an off-die ambient sensor over a 1-wire bus refreshed every 100 ms. The upper limit is computed per core, per clock domain, every 1 ms (T_hi = f(Ta, utilization) piecewise-linear surface with 16 breakpoints per axis). A digital comparator placed in the always-on power domain compares the die temperature against T_hi even when the core is power-gated, so detection survives C-state entry. Detection latency for a filter-clog transient is under 3 s.

sequenceDiagram
    participant Amb as Ambient Sensor Off-Die
    participant PCU as Power Control Unit
    participant Diode as On-Die Diode Ring
    participant Cmp as Always-On Comparator
    participant BMC as Baseboard Manager
    Amb->>PCU: Ta sample every 100 ms
    Diode->>PCU: Tj sample every 1 ms
    PCU->>PCU: Compute T_hi per core per domain
    PCU->>Cmp: T_hi setpoint
    Diode->>Cmp: Tj
    Cmp->>BMC: Assert clogging flag
    BMC->>PCU: Acknowledge and log

DD-1.3 — Axis 2: Industrial scale, 10 MW containerized data hall, harsh environment

Enabling description. Intake air is measured by a 9-element averaging RTD rake in the cold aisle at 6 m height (0.1 °C element accuracy, 0.03 °C rack-to-rack spread). Operational status is the IT load in kW sampled at 1 Hz from PDU branch-circuit monitoring. The estimator runs on a redundant SIL-2 PLC pair over a 64 × 64 (Ta, kW) grid with bilinear interpolation, yielding T_hi per rack row. Reference exhaust temperature is a 12-point type-T thermocouple grid. The envelope is −40 °C to +55 °C ambient, 0–100% RH, salt fog per IEC 60068-2-52, and altitude to 3,000 m; T_hi is scaled by measured barometric pressure because intake-air mass flow falls with air density. Fans are 18,000 RPM EC plugs over a 0–10 V interface.

flowchart TD
  subgraph ColdAisle
    A["9-Element RTD Rake"] --> B["Averager 1 Hz"]
  end
  subgraph Power
    C["PDU Branch kW"] --> D["IT Load Aggregator"]
  end
  subgraph Control
    B --> E["SIL-2 PLC Estimator 64x64 Grid"]
    D --> E
    F["Barometric Pressure"] --> E
    E --> G["T_hi Per Rack Row"]
  end
  subgraph Exhaust
    H["12-Point TC Grid"] --> I["Comparator"]
    G --> I
  end
  I -->|exceeds| J["SCADA Alarm + Ticket"]

DD-1.4 — Axis 3: AgTech — tunnel-ventilated poultry house

Enabling description. The estimator/limit/compare chain is applied to a 120 m × 18 m tunnel-ventilated poultry house. “Operational status” is the metabolic heat load Q_met = f(stocking density, bird age, feed intake) recomputed hourly from feed-weighing and flock records; “intake air temperature” is outside dry-bulb at the tunnel inlets; the “predetermined position” is the exhaust-fan plenum, sensed by a shielded RTD 2 m above the litter at the exhaust end. The estimated upper limit is an allowable internal air-temperature envelope. Exceedance indicates a failing evaporative cooling pad, a slipping fan belt, or a fouled shutter. Actuation is a 0–10 V damper plus a variable-frequency fan drive.

flowchart LR
  A["Outside Dry-Bulb RTD"] --> C["1 Hz PLC Estimator"]
  B["Feed Intake + Bird Age Records"] --> D["Metabolic Heat Model"]
  D --> C
  C --> E["Allowable Internal Air Temp"]
  F["Exhaust Plenum RTD"] --> G["Comparator"]
  E --> G
  G -->|exceeds| H["Pad / Belt / Shutter Fault Alarm"]
  G -->|below| I["VFD Fan Turn-Down"]
  I --> J["Damper 0-10 V"]

DD-1.5 — Axis 3: Aerospace — ARINC 600 line-replaceable unit

Enabling description. An ARINC 600 LRU on a transport aircraft runs the estimator. Operational status is mission phase (ground, taxi, takeoff, cruise, descent) combined with module processor utilization reported by the health monitor over ARINC 429. Intake air is the ram-air inlet total temperature from a total-air-temperature probe; the predetermined position is the power-supply cold plate, sensed by a bonded Pt RTD. The estimator uses a two-dimensional map (ram-air temperature × dissipated power) to derive T_hi; exceedance indicates a ram-air door stuck closed or a failed cold-plate fan. Detection latches a maintenance word to non-volatile memory and asserts a discrete to the central maintenance computer. Cold-plate range: −55 °C to +125 °C.

sequenceDiagram
    participant HM as Module Health Monitor
    participant EST as Estimator Task RTOS
    participant TAT as Ram-Air TAT Probe
    participant CP as Cold Plate RTD
    participant CMC as Central Maintenance Computer
    HM->>EST: Mission phase and utilization
    TAT->>EST: Ram-air total temperature
    EST->>EST: Lookup T_hi from power map
    CP->>EST: Cold plate temperature
    EST->>CMC: Discrete assert on exceedance
    EST->>EST: Latch maintenance word in NVM

DD-1.6 — Axis 4: AI surrogate model + IoT telemetry + blockchain attestation

Enabling description. A gradient-boosted regression tree (400 trees, depth 5) or a 3-layer MLP (32-16-8, tanh, ≈1,200 MACs) is trained offline on 10⁷ tuples of (Ta, utilization, RPM, air density) labeled with the 99.7th percentile of normal operating temperature. It is deployed int8-quantized on a Cortex-M33 using CMSIS-NN. Sensor vectors are published at 1 Hz as MQTT 5.0 Sparkplug B payloads. Every abnormality event (timestamp, sensor vector, model hash, T_hi, T_measured) is committed to a permissioned Hyperledger Fabric ledger as a transaction, and the daily Merkle root is anchored to a public chain for tamper-evidence. Model updates ship as signed OTA blobs with A/B rollback.

flowchart TD
  subgraph Edge
    A["Ta / U / RPM Sensors"] --> B["Feature Vectorizer"]
    B --> C["int8 MLP Surrogate Cortex-M33"]
    C --> D["T_hi"]
    E["Measured Temperature"] --> F["Comparator"]
    D --> F
  end
  subgraph Transport
    B --> G["MQTT 5.0 Sparkplug B Broker"]
    F --> G
  end
  subgraph Ledger
    G --> H["Hyperledger Fabric Event Transaction"]
    H --> I["Daily Merkle Root"]
    I --> J["Public Chain Anchor"]
  end
  subgraph Lifecycle
    K["Signed OTA Model Blob"] --> C
  end

DD-1.7 — Axis 5: Inverse — sensor-fault degrade mode

Enabling description. A supervisory credibility checker runs three tests: (i) intake/exhaust coherence against a first-principles energy balance, (ii) rate-of-change plausibility limiting |dT/dt| < 5 °C/min, and (iii) cross-check of two intake sensors with a 2 °C disagreement sustained for 10 min. On failure, the estimator substitutes a fixed conservative upper limit precomputed at 60 °C intake air, the sampling interval lengthens from 1 s to 60 s, and the hysteresis band widens from 0.5 °C to 3 °C to prevent chatter. The alarm output is suppressed to avoid false positives; instead a “thermal sensing degraded” condition is asserted over Redfish /redfish/v1/Chassis/1/Thermal and via SNMP trap. Recovery requires 30 min of credible sensing before returning to the normal state.

stateDiagram-v2
    [*] --> Normal
    Normal --> Degraded: Credibility Test Fails
    Degraded --> Normal: 30 min Credible Sensing
    Normal --> Alarm: T > T_hi
    Degraded --> Degraded: Alarm Suppressed Widened Hysteresis
    Alarm --> Normal: T below T_hi minus hysteresis

---

CLAIM GROUP 2 — Upper limit decreases monotonically as utilization rate decreases at equal intake-air temperature

DD-2.1 — Axis 1: Monotone piecewise-cubic interpolator in silicon

Enabling description. The discrete lookup is replaced by an isotonic-regression-constrained monotone piecewise-cubic (PCHIP with Fritsch–Carlson slope limiting) evaluated in single precision. Hardware implements the slope limiter as a fixed pipeline stage; coefficients occupy 8 kB of ROM per sensor position. The construction guarantees T_hi(U1) ≤ T_hi(U2) whenever U1 > U2 at equal Ta, by mathematical construction rather than by table curation. The sensing element may also be swapped to a monotone-response silicon bandgap sensor (e.g., a Brokaw-cell core) whose output is linear-in-temperature without the NTC's Beta-curve correction, simplifying the monotonicity proof.

flowchart TD
  A["Utilization U"] --> C["PCHIP Knot Selector"]
  B["Intake Temp Ta"] --> C
  C --> D["Fritsch-Carlson Slope Limiter"]
  D --> E["Monotone Cubic Evaluation"]
  E --> F["T_hi constrained monotone in U"]
  F --> G["Comparator"]
  H["Measured Temperature"] --> G
  G -->|exceeds| I["Alarm"]

DD-2.2 — Axis 2: Extreme utilization and ambient domains

Enabling description. The monotone surface is characterized from 0.1% to 100% utilization with 10⁻²% resolution at the idle end and across 128 logical cores with per-core and package-aggregate utilization inputs. At extreme ambient the surface is bounded: from −40 °C at idle, where T_hi collapses to Ta + ΔT_offset (ΔT_offset ≈ 6 °C, essentially the residual heat from memory refresh and VRM quiescent loss), to +45 °C ambient at full load where T_hi saturates near the silicon's thermal design limit. A deep-idle regime (C6/C7 package residency > 90%) invokes a separate, much narrower monotone segment.

flowchart LR
  A["Deep Idle 0.1% U"] --> B["Narrow Monotone Segment"]
  C["Normal 5-80% U"] --> D["Main Monotone Surface"]
  E["Full Load 100% U"] --> F["Saturated Segment"]
  B --> G["T_hi Selector"]
  D --> G
  F --> G
  G --> H["Comparator"]
  H -->|exceeds| I["Alarm"]

DD-2.3 — Axis 3: Cross-domain monotone mappings

Enabling description. The same monotone constraint is applied in three unrelated domains. (a) Automotive cabin HVAC: utilization = compressor duty cycle, T_hi = allowable evaporator-outlet air temperature; lower duty ⇒ lower allowable temperature, since residual engine-bay soak dominates. (b) Refrigerated intermodal container: utilization = door-opening duty cycle and compressor run fraction; T_hi = allowable cargo-space air temperature. (c) Telecom remote radio unit: utilization = power-amplifier duty cycle from the digital pre-distortion block; T_hi = allowable heat-sink base temperature. In each case the enforcement is by construction of the interpolator, not by ad-hoc thresholding.

flowchart TD
  A["Automotive Compressor Duty"] --> C["Monotone Interpolator"]
  B["Reefer Door Duty Cycle"] --> C
  D["RRU PA Duty Cycle"] --> C
  C --> E["Domain-Specific T_hi"]
  E --> F["Domain Comparator"]
  F -->|exceeds| G["Domain Alarm"]

DD-2.4 — Axis 4: Monotonic neural network with federated recalibration

Enabling description. A constrained neural network with non-negative weights on the utilization path and monotone (softplus) activations guarantees monotonicity by architecture. T_hi = g(Ta) + h(U · w) with w ≥ 0 and h monotonically non-decreasing. Each deployment computes a local gradient update on its own telemetry, transmits only the update (not raw data) to a fleet aggregator over MQTT, and receives a re-averaged global model. A SHA-256 digest of the constraint-proof certificate and the new model weights is registered on-chain per release, enabling audit of when a given monotonicity guarantee took effect.

flowchart LR
  subgraph Node A
    N1["Monotone NN Inference"] --> N2["Local Gradient"]
  end
  subgraph Node B
    N3["Monotone NN Inference"] --> N4["Local Gradient"]
  end
  N2 --> AGG["Federated Aggregator"]
  N4 --> AGG
  AGG --> M["Global Monotone Model"]
  M --> N1
  M --> N3
  M --> CH["On-Chain Model Certificate"]

DD-2.5 — Axis 5: Inverse — telemetry-loss fail modes

Enabling description. Two opposite safe behaviors are disclosed. (i) Insensitivity-fail: on loss of utilization telemetry, assume maximum utilization, yielding the highest permissible T_hi and therefore the fewest false alarms — used where an unnecessary truck roll is the dominant cost. (ii) Sensitivity-fail: on loss of telemetry in a safety-critical installation, assume minimum utilization, yielding the lowest T_hi and therefore a deliberately over-sensitive detector with an explicit “degraded” annotation on every alarm raised. A third, coarse mode uses a two-breakpoint monotone map (idle, full) to preserve the ordering guarantee when the full table is unavailable.

stateDiagram-v2
    [*] --> TelemetryOK
    TelemetryOK --> InsensitiveFail: Loss and policy equals alarm_cost_dominant
    TelemetryOK --> SensitiveFail: Loss and policy equals safety_critical
    InsensitiveFail --> CoarseMap: Recovery window exceeded
    SensitiveFail --> CoarseMap: Recovery window exceeded
    CoarseMap --> TelemetryOK: Telemetry restored

---

CLAIM GROUP 3 — Temperature-range storing part (table indexed by utilization rate and intake-air temperature) searched by the estimator

DD-3.1 — Axis 1: Storage-medium substitution with integrity coding

Enabling description. The table is relocated from embedded flash to one of: (a) a banked ternary content-addressable memory for single-cycle lookup; (b) MRAM for rad-tolerant and high-endurance use; (c) a CPLD-resident CAM shadowed by a redundant bank. Each row carries a CRC-32C check word and a monotone-ordering invariant flag. Rows are written with a wear-leveling map; a 2-of-2 bank comparator detects single-event upsets within 10 ms. The estimator's search is a single associative match on the packed key (band(Ta) << 12) | band(U).

flowchart TD
  A["Packed Key Ta band | U band"] --> B["TCAM Associative Lookup"]
  C["Redundant Shadow Bank"] --> D["2-of-2 Bank Comparator"]
  B --> D
  D -->|mismatch| E["Upset Fault Flag"]
  D -->|match| F["Row Fetch"]
  F --> G["CRC-32C Verify"]
  G -->|ok| H["T_hi to Comparator"]
  G -->|fail| I["Fallback Row"]

DD-3.2 — Axis 2: Extreme table resolution and compression

Enabling description. The table is expanded to a 4096 × 4096 grid (16.7 M cells) at 0.05 °C resolution covering Ta ∈ [−40 °C, 70 °C] and U ∈ [0, 100%]. Raw int16 storage would consume 32 MB; delta encoding against a per-row first value plus run-length encoding of constant runs reduces this to approximately 96 kB. A 10-year retention variant stores the grid in NOR flash with a rotating journal. Lookup is a two-step process: band index arithmetic, then bilinear interpolation on the four surrounding cells, giving an effective resolution finer than the table pitch.

flowchart LR
  A["Ta and U Inputs"] --> B["Band Index Arithmetic"]
  B --> C["Delta + RLE Decompressor Cache"]
  C --> D["Four-Cell Fetch"]
  D --> E["Bilinear Interpolation"]
  E --> F["T_hi 0.05 C effective"]
  F --> G["Comparator"]

DD-3.3 — Axis 3: Cross-domain table instantiations

Enabling description. Three instantiations of the same storing-part concept. (a) Building automation: a BACnet-compliant table of allowable zone supply-air temperatures indexed by AHU fan speed and outside-air enthalpy, published as a BACnet AnalogValue array. (b) Automotive: an ASAP2 (A2L) calibration map with X = coolant temperature, Y = engine load, Z = allowable component temperature, addressed by calibrated axis breakpoints and stored in ECU calibration flash. (c) Telecom base station: a table indexed by rectifier load current and cabinet outside-air temperature, resident in the cabinet controller and exposed over SNMP.

flowchart TD
  A["Zone Fan Speed + OA Enthalpy"] --> B["Building Table BACnet AnalogValue"]
  C["Coolant Temp + Engine Load"] --> D["Automotive A2L Calibration Map"]
  E["Rectifier Current + Cabinet OAT"] --> F["Telecom SNMP-Exposed Table"]
  B --> G["Estimator Interface Contract"]
  D --> G
  F --> G
  G --> H["Common Search Semantics"]

DD-3.4 — Axis 4: Self-populating, federated, versioned table

Enabling description. The table is populated from fleet telemetry rather than manual characterization. Each node streams its own (Ta, U, T_observed) triple at 0.2 Hz; a central aggregator computes, for each cell, the 99.7th percentile of observed steady-state temperature using a streaming quantile sketch (t-digest). New tables are published as immutable content-addressed objects (IPFS CID) and the CID is committed on-chain alongside a training-data hash and a monotonicity-verification report. Nodes pull by CID and verify the hash before hot-swap. Interpolation between published tables is linear over a 24-hour blend window to avoid setpoint steps.

flowchart TD
  A["Fleet Nodes Stream Ta U T"] --> B["Streaming Quantile Sketch t-digest"]
  B --> C["Per-Cell 99.7th Percentile"]
  C --> D["Candidate Table Grid"]
  D --> E["Monotonicity Verifier"]
  E --> F["IPFS Content-Addressed Blob"]
  F --> G["On-Chain CID and Data Hash"]
  G --> H["Node Pull Verify Hot-Swap"]
  H --> I["24 h Blend Window"]

DD-3.5 — Axis 5: Inverse — corrupted-table fail mode

Enabling description. On CRC failure, blank-region detection, or violation of the monotone-ordering invariant, the storing part is marked untrusted and the estimator switches to a single hard-coded conservative row (60 °C intake, maximum utilization → highest allowable limit) held in ROM outside the reloadable region. The untrusted region is write-locked read-only until a signed table image is re-flashed. A last-known-good snapshot retained in a 4 kB battery-backed SRAM permits rollback without a network round trip. The fault is reported as a distinct diagnostic code so that a sensor-clog alarm and a table-integrity alarm are never conflated.

stateDiagram-v2
    [*] --> TrustedTable
    TrustedTable --> Untrusted: CRC or monotone invariant fails
    Untrusted --> RomFallback: immediate
    Untrusted --> LastKnownGood: if snapshot valid
    RomFallback --> TrustedTable: signed image reflashed
    LastKnownGood --> TrustedTable: signed image reflashed

---

CLAIM GROUP 4 — Estimation of a lower limit and instruction to reduce fan rotations when measured temperature is below it

DD-4.1 — Axis 1: Actuator substitution for the turn-down instruction

Enabling description. The fan-speed-reduction instruction is generalized to any variable-speed mover: (a) an electronically commutated (EC) plug fan with a 0–10 V or Modbus RTU setpoint; (b) a variable-frequency-driven centrifugal blower with a 4–20 mA reference; (c) a magnetically-levitated turbo blower with a CAN setpoint and active magnetic bearing telemetry; (d) a piezo synthetic-jet array where “reduction” means lowering the drive amplitude and duty cycle of the jet actuator pair. In each case the determiner emits a normalized turn-down demand Δ ∈ [0,1] and the mover's local controller maps Δ to its native setpoint scale, preserving the same closed-loop semantics.

flowchart LR
  A["Determiner Turn-Down Demand delta"] --> B["Actuator Abstraction Layer"]
  B --> C["EC Plug Fan 0-10 V"]
  B --> D["VFD Blower 4-20 mA"]
  B --> E["Maglev Turbo CAN"]
  B --> F["Synthetic Jet Amplitude"]
  C --> G["Speed Feedback"]
  D --> G
  E --> G
  F --> G
  G --> A

DD-4.2 — Axis 2: Extreme turn-down — full stop and industrial economizer

Enabling description. Two extreme operating points are disclosed. (a) Zero-RPM coasting: the determiner permits a full fan stop when the measured temperature is more than 8 °C below the estimated lower limit and the ambient is below 18 °C, relying on buoyancy-driven stack effect; a 30 s restart ramp with a 90% speed overshoot precedes any re-entry into loaded operation to break the thermal boundary layer. (b) Industrial scale: an 18 kW liquid-cooling pump is turned down to 10% of rated flow while the estimated lower bound on the coolant-return temperature is not violated, saving an estimated 62% of pump power at cubic-law scaling with a 0.45 exponent correction for static head.

flowchart TD
  A["Measured T vs Lower Limit"] --> B{"Margin > 8 C and Ta < 18 C"}
  B -->|yes| C["Full Fan Stop Stack Effect"]
  B -->|no| D["Proportional Turn-Down"]
  E["Load Return Signal"] --> F["30 s Restart Ramp 90% Overshoot"]
  C --> F
  F --> G["Resume Normal Control"]
  D --> H["Pump to 10% Rated Flow"]

DD-4.3 — Axis 3: Cross-domain turn-down

Enabling description. (a) Automotive EV: the battery thermal-management pump and chiller bypass are turned down when the measured pack-outlet coolant temperature is below the estimated lower bound for the present traction-power duty cycle, reducing parasitic load and extending range. (b) Commercial HVAC: the economizer damper and supply-fan speed are reduced when measured return-air temperature is below the estimated lower bound for the present occupancy and outdoor-air-enthalpy condition. (c) Agricultural controlled-environment: the pad-feed pump is cycled down when the plenum temperature is below the estimated lower bound for the present ventilation rate.

flowchart LR
  A["EV Traction Duty"] --> D["Estimator Lower Bound"]
  B["HVAC Occupancy + OA Enthalpy"] --> D
  C["Ag Ventilation Rate"] --> D
  D --> E["EV Coolant Pump Turn-Down"]
  D --> F["Economizer Damper Turn-Down"]
  D --> G["Pad Pump Cycle-Down"]
  E --> H["Range Gain"]
  F --> I["Fan Energy Saving"]
  G --> J["Water Saving"]

DD-4.4 — Axis 4: Reinforcement-learned fan policy with IoT setpoints and carbon ledger

Enabling description. A soft actor-critic policy over a state space of (T_measured, T_hi, T_lo, dT/dt, ambient) and action space of fan speed increments learns the power-optimal speed subject to the constraint that measured temperature never crosses T_lo or T_hi. The trained policy is exported as ONNX and executed on an edge gateway; setpoint writes to third-party equipment use Modbus TCP, BACnet/IP, or OPC UA. Each turn-down event's avoided energy (kWh, computed from fan affinity laws and logged RPM) is written as a signed measurement to a carbon-accounting ledger for Scope-2 reporting.

flowchart TD
  A["State T_measured T_hi T_lo dTdt Ambient"] --> B["Soft Actor-Critic Policy ONNX"]
  B --> C["Fan Speed Action"]
  C --> D["Constraint Projection"]
  D --> E["Modbus TCP Write"]
  D --> F["BACnet IP Write"]
  D --> G["OPC UA Write"]
  C --> H["Affinity-Law Energy Model"]
  H --> I["Carbon Ledger Attestation"]

DD-4.5 — Axis 5: Inverse — bounded turn-down with anti-oscillation

Enabling description. The turn-down is clamped to a hard floor of 1,200 RPM (or 15% of rated speed for liquid movers) to preserve static pressure margin and to keep the tachometer signal above the DC-offset detection threshold. A deadband of 2 °C around the lower limit plus a minimum dwell time of 120 s prevents limit cycling. If the tachometer signal is lost or reports a speed inconsistent with the commanded duty cycle by more than 10%, the controller holds the last known-good speed and does not act on the turn-down instruction until feedback is restored, so a failed actuator cannot be mistaken for an efficient one.

stateDiagram-v2
    [*] --> ClosedLoop
    ClosedLoop --> TurnDown: T below T_lo plus deadband
    TurnDown --> ClosedLoop: T at or above T_lo
    TurnDown --> HoldLastGood: Tach lost or inconsistent
    HoldLastGood --> TurnDown: Tach restored and consistent
    TurnDown --> FloorClamp: Command below RPM floor
    FloorClamp --> TurnDown: Command raised

---

CLAIM GROUP 5 — Operational status = CPU load

DD-5.1 — Axis 1: Substitute workload proxies

Enabling description. “CPU load” is generalized to any workload proxy obtainable from performance monitoring units or platform telemetry: (a) LLC last-level cache miss rate; (b) retired instructions per cycle; (c) memory-controller bandwidth utilization; (d) PCIe/CXL link byte throughput; (e) GPU streaming-multiprocessor occupancy; (f) NPU TOPS utilization; (g) Intel RAPL package energy counters or AMD SVI2 telemetry as a load proxy. A weighted composite U = Σ wᵢ·uᵢ is fed to the estimator; weights are calibrated per platform SKU by a short regression fit against measured steady-state temperature.

flowchart TD
  A["LLC Miss Rate"] --> W["Weighted Composite U"]
  B["IPC"] --> W
  C["Memory BW"] --> W
  D["PCIe Bytes"] --> W
  E["GPU Occupancy"] --> W
  F["NPU TOPS"] --> W
  W --> G["Estimator T_hi"]
  G --> H["Comparator"]

DD-5.2 — Axis 2: Nanoscale and cluster-scale utilization domains

Enabling description. At nanoscale, each core and each clock domain contributes its own utilization counter sampled at 100 kHz by a hardware performance counter block, and the estimator runs per domain with a 100 µs refresh. At cluster scale, thousands of nodes each compute a local T_hi but the operational status used for the rack-level estimator is a weighted mean of node utilization, weighted by each node's rated power; the aggregation is done over a redundant gRPC stream at 1 Hz with staleness rejection beyond 5 s.

flowchart LR
  subgraph Die
    A["Per-Core PMC 100 kHz"] --> B["Per-Domain Estimator 100 us"]
  end
  subgraph Rack
    C["Node Utilization Stream"] --> D["Rated-Power Weighted Mean"]
    D --> E["Rack Estimator 1 Hz"]
    F["Staleness Reject > 5 s"] --> D
  end
  B --> G["Local Compare"]
  E --> H["Rack Compare"]

DD-5.3 — Axis 3: Cross-domain where "CPU load" is a duty cycle

Enabling description. In each cross-domain deployment the utilization input is the closest analogue of CPU load. (a) Automotive ECU: core utilization from the AUTOSAR OS, plus a secondary proxy of CAN bus load percentage. (b) Avionics: partition execution time fraction from the ARINC 653 scheduler's minor-frame accounting. (c) Agricultural processing line: feed-conveyor motor duty cycle and dryer burner modulation, treated as the utilization input to an allowable-temperature estimator for the drive cabinet.

flowchart TD
  A["AUTOSAR Core Utilization"] --> D["Utilization Input Contract"]
  B["ARINC 653 Frame Time Fraction"] --> D
  C["Conveyor Motor Duty Cycle"] --> D
  D --> E["Allowable Cabinet Temperature"]
  E --> F["Comparator"]
  F -->|exceeds| G["Domain Alarm"]

DD-5.4 — Axis 4: Predictive utilization with IoT telemetry and ledgered limits

Enabling description. A 2-layer LSTM with 64 hidden units and a 30 s horizon forecasts utilization from the trailing 300 samples, allowing the estimator to precompute T_hi ahead of the thermal transient rather than reacting to it; prediction error is bounded by an exponential-moving-average of historical absolute error and the limit is widened by 2σ_error to preserve low false-alarm rate. Telemetry and forecasts are published over MQTT; each utilization-scaled limit and its forecast basis is logged as an immutable record so a later dispute over an alarm can be reconstructed exactly.

sequenceDiagram
    participant PMC as Performance Counters
    participant LSTM as Forecaster 30 s Horizon
    participant EST as Estimator
    participant CMP as Comparator
    participant LOG as Ledger
    PMC->>LSTM: 300-sample utilization window
    LSTM->>EST: Forecast U and sigma_error
    EST->>CMP: T_hi widened by 2 sigma
    CMP->>LOG: Limit plus forecast basis record
    PMC->>CMP: Measured temperature
    CMP->>LOG: Alarm or clear transaction

DD-5.5 — Axis 5: Inverse — utilization telemetry unavailable

Enabling description. In virtualized environments where the hypervisor masks PMU counters, or inside secure enclaves, the operational-status unit falls back in a defined order: (1) vCPU steal time plus guest run-queue length; (2) host-reported utilization over Redfish /redfish/v1/Systems/1/Processors/1; (3) package power from the VRM; (4) a static worst-case utilization assumption. Each fallback tier is annotated in the alarm record so downstream diagnostics know which proxy was in force. The fallback ladder is re-sorted automatically if one tier's proxy demonstrates correlation below 0.7 with measured steady-state temperature.

stateDiagram-v2
    [*] --> PMU
    PMU --> StealTime: PMU masked
    StealTime --> RedfishUtil: guest counters unavailable
    RedfishUtil --> PackagePower: host telemetry unavailable
    PackagePower --> WorstCase: VRM telemetry unavailable
    WorstCase --> PMU: any higher tier restored

---

CLAIM GROUP 6 — Operational status = power consumption

DD-6.1 — Axis 1: Power-sensing component substitution

Enabling description. Power is measured by any of: a 1 mΩ shunt with an INA226-class digital monitor (16-bit, ±0.1% gain error, 1.4 ms conversion); a closed-loop Hall-effect current transducer with 0.5% accuracy and 200 kHz bandwidth; a PMBus-capable VRM controller reporting input and output power registers (READ_POUT, READ_PIN) at 1 kHz; or a digital PSU interface exposing per-rail telemetry. Where shunt insertion loss is unacceptable, the current is inferred from the VRM's inductor DCR and the known duty cycle. All paths normalize to a signed 32-bit milliwatt value at 1 kHz.

flowchart LR
  A["Shunt + INA226"] --> N["Normalizer 32-bit mW at 1 kHz"]
  B["Hall CT 200 kHz"] --> N
  C["PMBus VRM READ_POUT"] --> N
  D["PSU Digital Rail Interface"] --> N
  E["Inductor DCR Inference"] --> N
  N --> F["Estimator T_hi"]
  F --> G["Comparator"]

DD-6.2 — Axis 2: Milliwatt to megawatt power domains

Enabling description. At the low end, on-die IDD measurement resolves quiescent leakage at sub-milliwatt granularity using a calibrated on-die replica load, giving the estimator an accurate idle-power anchor. At the high end, a 10 MW hall is characterized by three-phase current transformers on each PDU branch circuit, with 0.2S accuracy class and 1 Hz sampling, feeding a demand-averaging window of 15 min (thermal inertia of the hall makes faster averaging counterproductive). Intermediate tiers use rack-level busway metering at 0.5 Hz and node-level PMBus at 1 Hz.

flowchart TD
  A["On-Die IDD Sub-mW"] --> T["Tiered Power Aggregator"]
  B["Node PMBus 1 Hz"] --> T
  C["Rack Busway 0.5 Hz"] --> T
  D["PDU CT 0.2S 1 Hz"] --> T
  T --> E["15 min Demand Window at Hall Tier"]
  E --> F["Estimator T_hi"]
  F --> G["Comparator"]

DD-6.3 — Axis 3: Cross-domain power-based estimators

Enabling description. (a) EV traction inverter: DC-link power computed from bus voltage and phase-current reconstruction feeds an allowable IGBT junction-temperature estimator; exceedance indicates a degraded cold plate or a failed coolant pump. (b) Agricultural VFD: drive output power feeds an allowable motor-frame temperature estimator; exceedance indicates blocked cooling fins or an over-tightened belt. (c) Telecom rectifier cabinet: rectifier DC output power feeds an allowable cabinet internal temperature estimator.

flowchart LR
  A["EV DC-Link Power"] --> D["Allowable IGBT Tj"]
  B["Ag VFD Output Power"] --> E["Allowable Motor Frame T"]
  C["Rectifier DC Output Power"] --> F["Allowable Cabinet Air T"]
  D --> G["Comparator"]
  E --> G
  F --> G
  G -->|exceeds| H["Domain Fault Alarm"]

DD-6.4 — Axis 4: Power telemetry over PMBus/MQTT with on-chain efficiency attestation

Enabling description. PMBus transactions use the packet-error-checking byte (PEC) with CRC-8; any PEC failure marks the sample invalid, and three consecutive failures demote the telemetry tier. Valid samples are republished over MQTT 5.0 with the PMBus raw block and a monotonic sequence number. The ratio of IT power to total facility power (PUE) is computed on a rolling 15 min window and its Merkle root committed daily on-chain, producing an auditable efficiency record whose temperature-limit basis is the estimator output.

flowchart TD
  A["PMBus READ_POUT"] --> B["PEC CRC-8 Verify"]
  B -->|fail x3| C["Demote Telemetry Tier"]
  B -->|pass| D["MQTT 5.0 Publish with Sequence"]
  D --> E["IT Power Aggregate"]
  F["Facility Power"] --> G["Rolling PUE 15 min"]
  E --> G
  G --> H["Daily Merkle Root"]
  H --> I["On-Chain Efficiency Attestation"]
  D --> J["Estimator T_hi"]

DD-6.5 — Axis 5: Inverse — power telemetry loss

Enabling description. On PMBus NACK, bus timeout, or three consecutive PEC failures, the operational-status unit substitutes a first-principles power model P = P_static + k·U^α with α ∈ [1.2, 1.8] fitted at manufacture, driven by whatever utilization proxy remains available. If neither power nor utilization proxy is available, the estimator uses the 95th-percentile power of the historical distribution for that time of day, which preserves detection sensitivity for the dominant daytime load while tolerating night-time false-positive risk.

stateDiagram-v2
    [*] --> MeasuredPower
    MeasuredPower --> ModeledPower: PMBus fault
    ModeledPower --> TimeOfDayPrior: no utilization proxy
    TimeOfDayPrior --> MeasuredPower: bus recovered
    ModeledPower --> MeasuredPower: bus recovered

---

CLAIM GROUP 7 — Temperature sensor detects exhaust-air temperature

DD-7.1 — Axis 1: Exhaust-sensing component substitution

Enabling description. The exhaust sensor may be: (a) an 8 × 8 IR thermopile array (e.g., 32 × 24 pixel class) with an emissivity-corrected radiometric output, providing a spatial mean plus a hottest-quadrant value; (b) a 5-junction type-T averaging thermocouple rake spanning the exhaust plenum height; (c) a fiber-Bragg-grating string with 10 gratings along the exhaust duct; or (d) an ultrasonic transit-time sensor that derives both exhaust temperature and volumetric flow, enabling direct mass-flow computation via the ideal gas law.

flowchart LR
  A["IR Thermopile Array"] --> M["Radiometric Mean and Hotspot"]
  B["Type-T Av eraging Rake"] --> M
  C["FBG Duct String"] --> M
  D["Ultrasonic Transit-Time"] --> M
  M --> E["Exhaust Temperature Tb"]
  D --> F["Volumetric Flow Q"]
  F --> G["Mass Flow via Ideal Gas Law"]
  E --> H["Comparator"]
  G --> H

DD-7.2 — Axis 2: Extreme exhaust conditions

Enabling description. Three extreme envelopes are disclosed. (a) Liquid-cooled CDU return: exhaust-equivalent temperature from 40 °C to 90 °C measured on the return manifold, with a two-point calibration at 50 °C and 80 °C and a drift budget of 0.2 °C/year. (b) Cold-climate deployment at −40 °C exhaust temperature, requiring a heated sensing well and a self-check that distinguishes “very cold” from “sensor open circuit.” (c) A sonic-velocity variant where exhaust temperature is derived from the speed of sound, valid at pressures from 60 kPa (3,000 m altitude) to 110 kPa.

flowchart TD
  A["CDU Return Manifold 40-90 C"] --> E["Exhaust Estimator Input"]
  B["Cold Exhaust -40 C Heated Well"] --> E
  C["Sonic Velocity Derivation 60-110 kPa"] --> E
  E --> F["Open-Circuit vs Cold Discriminator"]
  F --> G["Comparator"]

DD-7.3 — Axis 3: Cross-domain exhaust-sensing

Enabling description. (a) Commercial HVAC: supply duct temperature downstream of the cooling coil is the “exhaust” reference; a rising value against the estimated limit indicates a fouled coil or a stuck-open bypass damper. (b) Automotive aftertreatment: the post-DOC/post-DPF exhaust gas temperature is the reference; deviation from the estimated limit for the prevailing engine load and DOC inlet temperature indicates a failed regeneration or a cracked substrate. (c) Agricultural grain drying: plenum air temperature above the grain bed is the reference; exceedance at the given burner modulation indicates a clogged screen or a short-cycling burner.

flowchart TD
  A["HVAC Supply Duct Temp"] --> D["Estimated Limit"]
  B["Post-DPF EGT"] --> D
  C["Grain Dryer Plenum Temp"] --> D
  D --> E["Comparator per Domain"]
  E --> F["Fouled Coil Alarm"]
  E --> G["Failed Regen or Cracked Substrate Alarm"]
  E --> H["Clogged Screen Alarm"]

DD-7.4 — Axis 4: Thermal imaging with CNN hotspot detection and digital twin

Enabling description. A 320 × 240 uncooled microbolometer feeds a small CNN (MobileNetV2 backbone, 4-class head: normal, localized hotspot, diffuse warming, sensor occlusion) running at 5 Hz on a Jetson-class edge module. The classifier output is fused with the scalar T_hi comparison by a rule layer: a diffuse-warming class plus an exceedance is a cooling degradation; a localized-hotspot class is a component-level fault; an occlusion class suppresses the alarm and raises a sensor-cleaning task. The thermal image and classifier scores stream to a physics-based digital twin that reconciles predicted and measured plenum temperatures.

flowchart TD
  A["Microbolometer 320x240 @ 5 Hz"] --> B["MobileNetV2 CNN 4-Class Head"]
  B --> C["Fusion Rule Layer"]
  D["Scalar T_hi Comparator"] --> C
  C --> E["Cooling Degradation"]
  C --> F["Component Fault"]
  C --> G["Sensor Occlusion Task"]
  A --> H["Digital Twin Reconciliation"]
  H --> C

DD-7.5 — Axis 5: Inverse — exhaust-sensor drift and degradation

Enabling description. Drift is detected by comparing the exhaust sensor against an energy-balance prediction built from intake temperature and total measured power: if the residual exceeds 3 °C for 24 h with stable load, the sensor is flagged for calibration. Redundant voting among three exhaust elements uses a median selector, and a single element departing from the median by more than 4 °C is quarantined. If all exhaust sensing is lost, detection degrades gracefully to the CPU-temperature limit alone, with the estimator's limit recomputed for the narrower information set and the alarm annotated as single-channel.

stateDiagram-v2
    [*] --> ThreeElementVote
    ThreeElementVote --> TwoElementVote: one element deviates over 4 C
    TwoElementVote --> CpuOnlyMode: second element lost
    CpuOnlyMode --> ThreeElementVote: elements restored
    ThreeElementVote --> DriftFlag: residual over 3 C for 24 h
    DriftFlag --> ThreeElementVote: recalibrated

---

CLAIM GROUP 8 — ICT equipment system embodiment

DD-8.1 — Axis 1: Form-factor substitution

Enabling description. The disclosed equipment-integrated abnormality detection is instantiated in: (a) a 6U blade chassis with a shared midplane and a chassis management module hosting the estimator for all blades; (b) an OCP Open Rack V3 rack-scale node with a DC-SCM hosting the estimator and an ORV3 busbar power-telemetry source; (c) a sealed edge micro-DC with no external air and a thermoelectric cooler, where “intake air” is the cold-side plenum of the TEC; (d) a MIL-STD-810H-ruggedized enclosure with conformal-coated boards and a conductive chassis as the exhaust reference.

flowchart TD
  A["6U Blade Chassis CMM"] --> E["Estimator Instance"]
  B["OCP ORV3 with DC-SCM"] --> E
  C["Sealed Edge Micro-DC TEC Plenum"] --> E
  D["MIL-STD-810H Rugged Enclosure"] --> E
  E --> F["Per-Form-Factor Sensor Map"]
  F --> G["Per-Form-Factor Fan/Pump Actuator Map"]
  G --> H["Comparator Alarm Path"]

DD-8.2 — Axis 2: Extreme equipment scale

Enabling description. (a) Immersion-cooled tank: the coolant supply temperature replaces intake air, and the “exhaust” is dielectric fluid returning to the CDU; the estimator uses an IT-power-driven tank heat-balance model. (b) Containerized hall: a single estimator instance governs 40 racks with a rack-row resolution of one lookup row per 8 kW increment. (c) Spacecraft avionics: the radiator sink temperature replaces intake air, and operational status is the payload duty cycle; the estimator must remain valid with a 4 K radiator sink temperature and in the absence of convective cooling.

flowchart LR
  A["Immersion Tank Coolant Supply"] --> E["Tank Heat-Balance Estimator"]
  B["Containerized Hall 40 Racks"] --> F["Rack-Row Estimator 8 kW Steps"]
  C["Spacecraft Radiator Sink 4 K"] --> G["Payload Duty-Cycle Estimator"]
  E --> H["Comparator"]
  F --> H
  G --> H

DD-8.3 — Axis 3: Cross-domain equipment embodiments

Enabling description. (a) Automotive zonal compute module: intake is cabin air drawn through the module's filter, exhaust is to the cabin, and operational status is the zone controller's CAN/Automotive-Ethernet load. (b) Medical imaging cart: intake is the scan-room ambient, the predetermined position is the reconstruction processor's heatsink, and operational status is the scan duty cycle; alarm thresholds are derated for the 10–20% duty cycle of clinical use. (c) Outdoor telecom cabinet: intake is filtered ambient through the door louvers; the estimator accounts for solar gain as a function of measured solar irradiance and cabinet azimuth.

flowchart TD
  A["Automotive Zonal Compute CAN Load"] --> E["Estimator"]
  B["Medical Reconstruction Duty Cycle"] --> E
  C["Telecom Cabinet Solar Gain Model"] --> E
  E --> F["Derated Allowable Limit"]
  F --> G["Alarm"]

DD-8.4 — Axis 4: DCIM / Redfish / digital-twin integration

Enabling description. The equipment exposes its estimator outputs as Redfish properties: /redfish/v1/Chassis/1/Thermal publishes UpperThresholdCritical as the dynamic estimator output rather than a static value, plus LowerThresholdCritical from the lower-limit estimator. A DCIM layer polls at 30 s intervals and correlates estimated limits across the fleet to compute per-row thermal headroom; the digital twin ingests the same stream and can run counterfactual simulations. Every limit change is versioned so that an alarm can be re-adjudicated against the exact limit in force at event time.

sequenceDiagram
    participant BMC as BMC Estimator
    participant RF as Redfish Thermal Endpoint
    participant DCIM as DCIM Poller 30 s
    participant TW as Digital Twin
    BMC->>RF: Publish dynamic Upper and Lower ThresholdCritical
    DCIM->>RF: GET Thermal
    RF->>DCIM: Limits plus timestamp plus version
    DCIM->>TW: Fleet thermal headroom stream
    TW->>DCIM: Counterfactual scenario results
    DCIM->>DCIM: Re-adjudicate historical alarms

DD-8.5 — Axis 5: Inverse — equipment with watchdog and hot-standby manager

Enabling description. The equipment carries a hardware watchdog (external to the estimator processor) with a 500 ms timeout and a hot-standby management controller holding a replicated copy of the estimator state, the last 1,000 sensor samples, and the table image. On watchdog expiry the standby takes over within 200 ms, re-establishes fan control at the last commanded speed, and continues abnormality detection using the replicated state. Until the standby confirms sensor credibility, the alarm output is held in a “best-effort” state that is clearly distinguished from a normal-clear state.

stateDiagram-v2
    [*] --> ActiveManager
    ActiveManager --> StandbyTakeover: watchdog expiry 500 ms
    StandbyTakeover --> BestEffortMode: sensors not yet credible
    BestEffortMode --> ActiveManager: credibility confirmed
    StandbyTakeover --> ActiveManager: no fault after 60 s

---

CLAIM GROUP 9 — Method for abnormality detection

DD-9.1 — Axis 1: Method-embodiment substitution

Enabling description. The method is disclosed as executable in four distinct embodiments: (a) a bare-metal RTOS task pinned to a dedicated core with 64 kB stack and no dynamic allocation; (b) an FPGA soft-core (RISC-V RV32I) with the estimator in hardware and the method as a 16-state sequencer; (c) a containerized microservice on the BMC's Linux userspace reading /sys/class/hwmon and writing /sys/class/hwmon/pwm1; (d) a cloud-hosted function with a 50 ms round trip over MQTT, used when the local controller lacks compute. All four share the same step sequence and produce bit-identical decisions given identical inputs.

flowchart TD
  A["Bare-Metal RTOS Task"] --> E["Common Method Steps"]
  B["FPGA RISC-V Sequencer"] --> E
  C["Container on BMC Linux hwmon"] --> E
  D["Cloud Function 50 ms RTT"] --> E
  E --> F["Identical Decision Semantics"]
  F --> G["Local Alarm or Remote Command"]

DD-9.2 — Axis 2: Sampling-rate and fleet-scale extremes

Enabling description. The method is disclosed at sampling intervals from 10 µs (on-die, hardware-sequenced, for transient filter-clog detection during a millisecond-scale workload burst) through 1 s (typical BMC implementation) to 60 s (cloud-hosted, for a 10,000-node fleet where the aggregation dominates). At the 10,000-node tier, the method is restructured as a map-reduce: each node emits a locally reduced (band(Ta), band(U), exceedance_flag, margin) tuple at 60 s; the reducer computes fleet-level clogging likelihood by Bayesian pooling and triggers per-node investigation only on a posterior above 0.8.

flowchart LR
  subgraph FastTier
    A["10 us Hardware Sequencer"] --> D["Local Decision"]
  end
  subgraph MidTier
    B["1 s BMC Method"] --> D
  end
  subgraph FleetTier
    C["60 s Node Reducer"] --> E["Map-Reduce Aggregator"]
    E --> F["Bayesian Pooled Posterior"]
    F -->|> 0.8| G["Per-Node Investigation"]
  end

DD-9.3 — Axis 3: Cross-domain method deployment

Enabling description. The method is disclosed as a commissioning and monitoring procedure in three unrelated industries. (a) HVAC commissioning: measure outside-air temperature and fan/VAV speed, estimate the allowable duct-static and supply-air-temperature envelope, and flag a fouled filter or a slipping belt when the measured value exceeds it. (b) EV fleet telematics: log traction power and ambient, estimate allowable pack-outlet coolant temperature, and flag a degraded chiller. (c) Agricultural grain storage: log burner modulation and outside air, estimate allowable plenum temperature, and flag an airflow restriction.

flowchart TD
  A["HVAC Commissioning"] --> D["Method Steps"]
  B["EV Fleet Telematics"] --> D
  C["Grain Storage Aeration"] --> D
  D --> E["Domain Estimator"]
  E --> F["Domain Comparator"]
  F --> G["Commissioning Report / Fault Ticket"]

DD-9.4 — Axis 4: Method as an inference service with MLOps governance

Enabling description. The method is packaged as an inference endpoint (gRPC, protobuf schema with fields ta, u, rpm, t_measured) that returns t_hi, t_lo, decision, and confidence. Retraining is automated: a drift detector monitors the KS statistic between the live input distribution and the training distribution; a KS value above 0.15 triggers retraining on the trailing 90 days; the new model is shadow-deployed for 72 h, compared against the incumbent on held-out events, and promoted only if false-positive rate does not increase by more than 0.5 percentage points. All promotions are documented as model cards whose hashes are committed on-chain.

flowchart TD
  A["gRPC Inference Endpoint"] --> B["KS Drift Detector"]
  B -->|> 0.15| C["Retrain on 90-day Window"]
  C --> D["Shadow Deploy 72 h"]
  D --> E{"FPR increase <= 0.5 pp"}
  E -->|yes| F["Promote to Production"]
  E -->|no| G["Hold and Investigate"]
  F --> H["Model Card Hash On-Chain"]

DD-9.5 — Axis 5: Inverse — method with safe abstention

Enabling description. The method includes an explicit third decision state, indeterminate, in addition to normal and abnormal. Indeterminate is entered when input confidence is below threshold (sensor credibility test failed, or the sample falls outside the calibrated (Ta, U) domain, or two redundant estimators differ by more than 3 °C). In the indeterminate state no alarm is raised and no turn-down is issued; instead a bounded escalation timer of 15 min begins, after which an operator-directed diagnostic dump is produced. This prevents both false alarms and silent failure during the transition between credible and non-credible sensing regimes.

stateDiagram-v2
    [*] --> Evaluating
    Evaluating --> Normal: T within limits and confidence high
    Evaluating --> Abnormal: T exceeds T_hi and confidence high
    Evaluating --> Indeterminate: credibility or domain or redundancy failure
    Indeterminate --> Evaluating: confidence restored
    Indeterminate --> Escalate: 15 min timer expires
    Escalate --> OperatorDiagnostic

---

COMBINATION PRIOR-ART SCENARIOS WITH OPEN STANDARDS

CP-1 — US 9,482,632 × IPMI 2.0 / DCMI (Intel, DMTF-derived)

Enabling description. The estimator output is mapped onto IPMI 2.0 sensor model semantics. The ESTIMATED T_hi is written to a Threshold Sensor record (Sensor Type Temperature, Entity ID 0x03 for processor or 0x04 for power supply) as the Upper Non-Critical threshold; a second sensor carries T_lo as Lower Non-Critical. The storing part maps to the SDR Repository with a per-(Ta,U) band selecting which SDR the estimator points to. Exceedance generates an IPMI Platform Event Trap (PET) with the sensor number, and the fan turn-down is issued as a Set Fan Speed IPMI command or a managed OEM command. The combination makes dynamic-threshold abnormality detection interoperable with any IPMI 2.0 management stack.

flowchart LR
  A["Estimator T_hi"] --> B["IPMI Threshold Sensor Upper Non-Critical"]
  C["Estimator T_lo"] --> D["IPMI Lower Non-Critical"]
  E["Table Bands"] --> F["SDR Repository Records"]
  B --> G["Comparator"]
  D --> G
  H["Measured Temperature Sensor"] --> G
  G -->|exceeds| I["Platform Event Trap"]
  G -->|below| J["IPMI Set Fan Speed"]

CP-2 — US 9,482,632 × DMTF Redfish (DSP0266) Thermal schema

Enabling description. The estimative limit is exposed as a Redfish Thermal resource property. The estimator's T_hi populates UpperThresholdCritical on the relevant Temperature object, and LowerThresholdCritical carries T_lo; ReadingCelsius carries the measured value; Status/HealthRollup is computed by the determiner rather than by a static policy. The storing part is exposed as an OEM extension property VendorLimits with an array of (IntakeAirBand, UtilizationBand, UpperLimit, LowerLimit) objects. Subscribers register via Redfish Event Service SubmitTestEvent-style EventDestination to receive ResourceUpdated events at 30 s intervals.

sequenceDiagram
    participant EST as Estimator
    participant RF as Redfish Service
    participant SUB as Event Subscriber
    participant DCIM as DCIM
    EST->>RF: Write UpperThresholdCritical and LowerThresholdCritical
    EST->>RF: Write OEM VendorLimits array
    SUB->>RF: Register EventDestination
    DCIM->>RF: GET /Thermal
    RF->>DCIM: ReadingCelsius plus dynamic thresholds plus HealthRollup
    RF-->>SUB: ResourceUpdated event

CP-3 — US 9,482,632 × OpenBMC with MCTP/PLDM (DMTF DSP0248, DSP0236)

Enabling description. The estimator is implemented as a Phosphor daemon reading phosphor-hwmon sensor objects over D-Bus and consuming PLDM Platform Monitoring and Control GetSensorReading responses from downstream devices over MCTP/SMBus. The upper and lower limits are published as D-Bus properties on the xyz.openbmc_project.Sensor.Threshold.Critical interface, allowing FanControl, Redfish, and IPMI bridges to consume the same source of truth without duplication. Table updates arrive as a PLDM firmware update package and are applied with a dual-bank A/B flash layout and a rollback on failed monotonicity verification.

flowchart TD
  A["PLDM GetSensorReading over MCTP"] --> B["phosphor-hwmon D-Bus Objects"]
  B --> C["Estimator Phosphor Daemon"]
  C --> D["Sensor Threshold Critical Interface"]
  D --> E["FanControl Daemon"]
  D --> F["Redfish Bridge"]
  D --> G["IPMI Bridge"]
  H["PLDM Firmware Update Package"] --> I["A/B Bank Flash"]
  I --> C
  I --> J["Monotonicity Verify Rollback"]

CP-4 — US 9,482,632 × MQTT 5.0 / Sparkplug B + OPC UA

Enabling description. Sensor vectors are published as Sparkplug B NDATA/DDATA messages with a birth certificate declaring metrics Ta, U, Rpm, Thi, Tlo, Tmeasured; sequence numbering and a bdSeq rebirth counter provide exactly-once semantics across reconnects. For industrial consumers, the same data is exposed through OPC UA as a FolderType with AnalogItemType variables carrying EURange and EngineeringUnits, and the estimator is wrapped as an OPC UA method ComputeLimit(Ta, U) → Thi so that plant SCADA can invoke the estimator synchronously.

flowchart LR
  A["Sensor Vector"] --> B["Sparkplug B NDATA Publish"]
  B --> C["MQTT 5.0 Broker"]
  C --> D["SCADA Subscriber"]
  C --> E["OPC UA Gateway FolderType"]
  E --> F["AnalogItemType Variables"]
  E --> G["OPC UA Method ComputeLimit"]
  H["Birth Certificate bdSeq"] --> C

CP-5 — US 9,482,632 × ASHRAE 135 (BACnet) and IEEE 1451 transducer interface

Enabling description. For building and agricultural deployments the estimator is exposed as a BACnet Analog Input object, and the storing part as a Trend Log with Log_Interval tied to the band-change event. Write-Property on the High_Limit/Low_Limit properties from a BACnet building controller is treated as an external override with an expiry timestamp. Concurrently, the physical sensor layer conforms to IEEE 1451.x, where the Transducer Electronic Data Sheet (TEDS) carries the calibration coefficients and the estimator's coefficient set in a manufacturer-defined TEDS template, enabling self-describing sensors whose limits can be recomputed on any conformant NCAP.

flowchart TD
  A["IEEE 1451 Transducer"] --> B["TEDS with Estimator Coefficients"]
  B --> C["NCAP Reads TEDS"]
  C --> D["BACnet Analog Input Object"]
  D --> E["Trend Log Per Band Change"]
  D --> F["External High Limit Override with Expiry"]
  C --> G["Estimator Recompute on Conformant NCAP"]

---

PUBLICATION STATUS AND USE

This disclosure establishes, as of 2026-04-26, a printed publication describing 47 derivative embodiments across all nine claim groups of US 9,482,632 B2, plus five combinations with open standards (IPMI 2.0/DCMI, Redfish, OpenBMC + PLDM/MCTP, MQTT 5.0/Sparkplug B + OPC UA, BACnet/IEEE 1451). Each embodiment is enabled to a level permitting reproduction by a person of ordinary skill, and each teaches a concrete, non-abstract engineering implementation rather than a mere statement of a desired result.

Caution on scope: This disclosure is drafted around the claim groups of US 9,482,632 B2 as verified in the full patent text and PTAB Exhibit EX1001. It does not represent an admission regarding the validity, scope, or enforceability of that patent, and it does not purport to map to any specific infringing product. Two data points in the record remain unresolved and are carried forward as flags: the 419-day versus inferred-784-day PTA discrepancy, and the identity of the plaintiff in E.D. Tex. 2:26-cv-00150 (identified in search results as Cloud Byte LLC v. Hewlett Packard Enterprise Co., which the previously generated sections list as unknown).