US 11463470

Summary of U.S. Patent No. 11,463,470

Note on sourcing: The full patent text was provided in the query (fetched from Google Patents, 2026-09-03), and live web searches confirmed the bibliographic data (Google Patents family page). My searches for any CAFC 2026 docket activity involving "11463470" returned no results — I could not confirm whether any appeal or other proceeding exists at the Federal Circuit in 2026. Treat the absence of CAFC proceedings as unverified rather than confirmed.

Bibliographic data (confirmed)

• Patent number: US 11,463,470 B2 (application no. 17/136,883)
• Title: Network security management for a building automation system
• Assignee: Trane International Inc. (assignment recorded 2020-12-29, effective 2020-12-22; reel/frame 054769/0280)
• Inventors: Udhaya Kumar Dayalan, Brian Meyers, Mangayarkarasi Sivagnanam
• Filing date: December 29, 2020
• Issue (grant) date: October 4, 2022
• Priority date: December 29, 2020 (U.S. only; related foreign filings EP21218108.5A, CN202111646849.2A; continuation US17/937,622 → US11818162B2)
• Legal status: Active; adjusted expiration ~March 31, 2041

Abstract (paraphrased from the patent)

Methods and systems for performing an electronic security assessment of a building automation system. The system includes a controller and a network of electronic devices in electronic communication. The controller requests an electronic security scan of itself (with its data set) via a secured channel to a cloud-based service. The cloud service initiates the scan and electronically assesses security vulnerabilities of the building automation system. The controller electronically assesses security vulnerabilities of the networked electronic devices. A recommendation list for resolving the identified security vulnerabilities is then determined based on both assessments.

Independent claims — plain-language overview

Claim 1 (method): A method for performing an electronic security assessment of a building automation system having a controller and a network of electronic devices. Steps:

1. The controller requests an electronic security scan of itself, sending its data set over a secured channel to a cloud-based service.
2. The cloud service launches the scan in real-time based on that data set.
3. The cloud service assesses security vulnerabilities of the building automation system — e.g., whether the controller sits behind a firewall/network security device; validates the controller's service configuration; validates its Ethernet and Wi-Fi configuration; identifies open communication ports; checks whether routers, bridges, or broadcast devices in communication with the controller are firewall-protected; validates security certificates on open ports; and validates server communication.
4. The cloud service validates egress points of the building automation system.
5. The controller assesses vulnerabilities of the networked devices — probing the devices; determining whether they are firewall-protected; validating their Ethernet/Wi-Fi configuration; and identifying open communication ports.
6. A recommendation list for resolving the vulnerabilities is generated based on both the cloud-service assessment and the controller's peer assessment.

Claim 13 (system): A building automation system comprising a controller, a plurality of electronic devices, and a network connecting them. The controller is configured to request an electronic security scan (with its data set) over a secured channel to a cloud-based service. The cloud-based service is configured to (a) initiate the scan based on the controller's data set, (b) assess vulnerabilities of the building automation system (same categories as claim 1: firewall protection, service configuration, Ethernet/Wi-Fi config, open ports, protection of routers/bridges/broadcast devices, security certificates, server communication), and (c) validate egress points. The controller is further configured to assess vulnerabilities of the networked electronic devices (probing, firewall protection, Ethernet/Wi-Fi config, open ports) and to determine a recommendation list for resolving the vulnerabilities based on both the cloud-service assessment and the controller's device-level assessment.

Notable features (context, not claim limitations)

• Three complementary assessment modes described: passive self-assessment by the cloud (method 300), peer assessment of connected devices by the controller (method 400), and active self-assessment by the controller including password-policy analysis (method 500), plus cloud egress testing (method 600) and fleet-wide assessment across multiple building automation systems (method 700).
• Real-time cloud scans versus assessments performed independently of the scan are distinguished (dependent claims 2–3 / 14–15).
• Dependent claims also cover password-policy validation, basing recommendations on egress validation, master vs. unit controller implementations, IP-address data sets, risk-score generation and display, periodic scheduling, and BACnet protocol connectivity (claims 4–12, 16–20).

Uncertainties

• CAFC 2026 activity: No evidence located; do not infer litigation status from this summary.
• The Google Patents "Current Assignee" listing is flagged there as potentially inaccurate; however, the recorded assignment to Trane International Inc. is corroborated by the assignment record text returned in the search results.

I'll search for litigation involving US Patent No. 11463470 specifically. Let me run several searches across relevant sources.

The first search returned no results, and the second found a recent 2026 case involving Trane. I need to verify whether that case actually involves patent 11463470. Let me dig deeper.

The Portus v. Trane case appears to involve Portus's own patents (e.g., 9,961,097) asserted against Trane, not Trane's 11463470. Let me verify which patents are asserted in that case and search more specifically for 11463470 litigation.

Based on my searches, here is what I can report regarding litigation involving US Patent No. 11463470:

No known litigation directly involving US Patent 11463470

I was unable to locate any district court litigation, ITC investigation, or PTAB proceeding (IPR/PGR) specifically asserting or challenging US Patent No. 11463470 ("Network security management for a building automation system," assigned to Trane International Inc.). Searches for "11463470" litigation, "11463470" lawsuit, and "11463470" PTAB/IPR returned no hits tying that specific patent number to any case.

One cautionary near-match (not this patent)

A recently filed case that could appear in a naive search is:

• Portus Singapore PTE Ltd. & Portus PTY Ltd. v. Trane Technologies Company LLC
  • Case No. 2:26-cv-00336
  • Jurisdiction: U.S. District Court for the Eastern District of Texas (Judge Rodney Gilstrap)
  • Filing date: April 23, 2026
  • Status: Open (complaint and summons recently filed; no substantive rulings yet)
  • Plaintiffs: Portus Singapore PTE Ltd. and Portus PTY Ltd.
  • Defendant: Trane Technologies Company LLC

This case does NOT involve US Patent 11463470. The available docket information and related sources indicate Portus (a non-practicing entity) is the plaintiff asserting its own patents against Trane as a defendant. Unified Patents and related coverage describe Portus asserting its U.S. Patent No. 9,961,097 ("the '097 Patent," titled "System for Remote Access of a User Premises") and U.S. Patent No. 8,914,526 ("the '526 Patent") against multiple defendants including Trane, Samsung, ADI, Whirlpool, LG, Lennox, and others. In other words, Trane is the accused infringer in the Portus cases — the patents-in-suit belong to Portus, not Trane. Patent 11463470 is a Trane-owned patent and is not identified in that litigation.

Bottom line

As of April 26, 2026, based on available public docket and litigation database searches, no litigation is known to involve US Patent 11463470. The only Trane-related patent case surfaced by these searches (Portus v. Trane, 2:26-cv-00336) concerns Portus's own security-related patents, not 11463470. If you want, I can attempt a deeper docket-level review (e.g., via PACER/RPX/CourtListener for the specific case numbers) to confirm whether Trane has filed any counterclaim asserting 11463470 in that or any other matter, but nothing in the current record indicates one.

Proceedings overview

Zero AIA trial proceedings are on file for US 11463470. The USPTO Open Data Portal ingest returns no IPR/PGR/CBM activity, and web searches (USPTO PTAB, Google Patents, FreePatentsOnline, CourtListener-adjacent coverage) surfaced no petition, institution decision, settlement, or Federal Circuit appeal naming this patent. Breakdown by status: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied. The bottom-line defensive posture for a defendant: there is no PTAB track record at all — the patent is untested in AIA trials, which cuts both ways: no claim has ever been canceled (so prior art attacks remain entirely unproven), but equally no petitioner has ever tried, so the art landscape is wide open for a first mover.

No individual proceeding write-ups follow — there are no proceedings. Per the operating rules I will not invent proceeding numbers, APJ panels, grounds, or decisions.

Strategic summary

Claims: CANCELED vs. SUSTAINED vs. UNTESTED. Because no AIA petition has ever been filed on US 11463470, all twenty claims (independent claims 1 and 13, plus dependent claims 2–12 and 14–20, per the claim listing) remain UNTESTED — none have been canceled, and none have been affirmatively sustained in a Final Written Decision. The patent issued 2022-10-04 from an application filed 2020-12-29 (adjusted expiration 2041-03-31), is assigned to Trane International Inc., and remains Active. There is also a continuation in the family — US 11818162 B2 (filed 2022-10-03) — and an earlier-filed family member, US 11811813 B2 (filed 2018-12-28, published as US 2020/0213344 A1), which the '470 specification expressly incorporates by reference. A challenger evaluating the family should decide which member(s) to target; PTAB challenges could land on any of them.

Estoppel landscape. With no IPR/PGR/CBM ever instituted, there is no § 315(e)(2) estoppel running against anyone, and no petitioner/privy is barred from raising any ground. For a defendant facing assertion today, all prior-art grounds under §§ 102 and 103 remain available — but the statutory timing bar in § 315(b) still applies: any IPR petition must be filed within one year of the defendant being served with a complaint alleging infringement of this patent. If a defendant is already more than a year into litigation on '470, an IPR by that defendant (or a real-party-in-interest/privy) is time-barred, and the practical alternatives are a different defendant filing, a Unified Patents–style third-party petition (Unified and similar aggregators are not typically subject to the same litigation-driven bar because they are not sued), or ex parte reexamination / district-court § 101 or § 112 defenses. No evidence surfaced that Unified Patents, RPX, or any defensive aggregator has touched this patent family.

Pattern signals. There are none to read: no repeat petitioner, no patent-owner PTAB litigation history, no settlements. The absence of activity is itself the notable data point. This is a young (granted ~4 years ago), commercially narrow patent in the HVACR/building-automation space, owned by a large operating company (Trane) that appears to use it defensively or as part of a product-security story rather than as an aggressive assertion vehicle — well-asserted patents of this vintage against meaningful targets typically attract IPR challenges within the first few years of grant. None having appeared suggests either low assertion activity or that disputes, if any, have been resolved outside the PTAB.

Recommended next steps

If you are a defendant and no PTAB activity exists, say so plainly — and treat the absence as informative, not exculpatory. Concretely:

1. Confirm the record yourself before relying on this memo. The ODP ingest can lag; run the patent number (11463470) through USPTO PTAB E2E (https://ptab.uspto.gov) and the Unified Patents docket to double-check for a petition filed within the last few weeks that has not yet been indexed.
2. Check the family, not just the '470. If a demand letter cites US 11463470, verify whether it also implicates the continuation US 11818162 B2 or the earlier US 11811813 B2. An IPR strategy may need to address multiple members, and the earliest effective filing date (2018-12-28 for the 11811813 line) determines which prior art qualifies as § 102(e)/§ 103 art.
3. Mind the § 315(b) clock. If you were served more than one year ago, you personally are likely time-barred from filing an IPR on '470; consider whether a co-defendant or a third party (e.g., Unified Patents) can carry the petition, or pivot to ex parte reexam and district-court validity defenses (§ 101/§ 112, plus § 103 with art that is not subject to the IPR bar).
4. Scope the art search now. The silver lining of a zero-proceeding docket is that no ground has been consumed. The most promising prior art will be building-automation security assessment and remote-diagnostic systems predating 2018–2020 (the '470 family claims cloud-service-triggered external security scanning of BAS controllers, firewall/port/certificate/egress validation, and peer-device probing — target vendors' remote-service portals, BAS cybersecurity audit tools, and NIST-style network scanning products).
5. There are no PTAB milestones to track because no proceeding is pending — no institution decision deadline, no oral hearing, no FWD due date. Re-check quarterly; the first IPR on this patent, if it comes, will be a significant event that materially changes the defensive calculus.

Caveat on sourcing: I located no PTAB docket, FWD, or CAFC opinion citing US 11463470 as of 2026-09-05. All statements above about the patent's claims, status, and family come from the Google Patents record supplied in the prompt; the "no proceedings" finding comes from the USPTO ODP block plus web searches that returned no PTAB references. If a petition was filed very recently and not yet indexed, this memo would not capture it — hence step 1 above.

Inventors

• Udhaya Kumar Dayalan — assignor on the recorded assignment to Trane International Inc.; employer at filing determinable as Trane (the assignment records him as an assignor to the company that filed the application).
• Brian Meyers — same: assignor on the recorded assignment to Trane International Inc.
• Mangayarkarasi Sivagnanam — same; additionally appears as an inventor on the earlier family member US 2020/0213344 A1 (→ US 11,811,813 B2, filed 2018-12-28), which the '470 specification expressly incorporates by reference. That co-authorship across the family line corroborates continuous Trane employment rather than an inventor-for-hire of convenience.

Pattern note: No unusual pattern. No evidence that any inventor departed Trane within 12 months of filing, and no inventor-side retention of rights is indicated (all three assigned their interest to Trane International Inc. at filing).

Original assignee

• Trane International Inc. (a Trane Technologies company), named on the issued patent and the current recorded owner.
• Line of business: HVACR equipment and building-automation/control systems (Trane is an operating company in the building HVAC and BAS market; the claims cover network security management features for BAS controllers — consistent with Trane's Tracer/Symbio-class controller product lines).
• Product embodiment: High confidence — the specification describes a security-assessment workflow launched from a controller's own user interface at installation time, which is a product feature Trane sells as part of its BAS controller offering rather than a paper invention.
• Current status: Operating. Parent Trane Technologies plc is a public operating company; no bankruptcy, dissolution, or acquisition of Trane International Inc. is indicated.

Assignment timeline

The USPTO Assignment Center record (as surfaced via Google Patents legal events) contains one recorded assignment only — the standard inventors-to-employer assignment made at filing. I could not retrieve the correspondent-of-record field from the assignment record text within this session, so the correspondent is reported as unavailable rather than guessed.

• 2020-12-22 (executed) / recorded 2020-12-29 — Reel 054769 / Frame 0280
  • Conveyance: Assignment of Assignors' Interest (see document for details)
  • Assignor: Udhaya Kumar Dayalan, Brian Meyers, Mangayarkarasi Sivagnanam (the three named inventors)
  • Assignee: Trane International Inc.
  • Correspondent: Not available in the data retrieved — the USPTO assignment record text was not reachable in this session, so no correspondent recurrence analysis is possible.
  • Context: Standard employee-inventor assignment to the operating company that filed and owns the application. No consideration beyond employment is indicated; this is an internal, at-filing conveyance, not an acquisition.

No post-issuance assignments exist in the record. No transfer to any LLC, holding company, NPE, or defensive aggregator appears. Google Patents legal events for the '470 (and the related EP4024758A1 / CN114697069A filings) show no further reassignment events after the 2020-12-29 record.

Timeline diagram

timeline
    title Ownership of US 11463470
    2020 : Filed by Trane International Inc
         : Inventors assign rights to Trane
    2022 : Patent issued to Trane
    2026 : Trane remains recorded owner

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only recorded conveyance (Reel 054769/0280, recorded 2020-12-29) runs from the three inventors to Trane International Inc., a product-selling operating company. No "IP/Patents/Holdings/Ventures" LLC appears anywhere in the chain.
2. Known asserter in the chain — not present. Neither the assignee (Trane International Inc.) nor any predecessor matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Round Rock, or any Unified Patents / RPX-listed high-frequency plaintiff. Trane is a large operating HVAC company, not on NPE directories.
3. Repeat correspondent across the chain — unclear / no data. There is only one recorded assignment, and I could not retrieve its correspondent-of-record field. A single link provides no basis for a recurrence finding; do not infer one.
4. Cascading transfers — not present. One assignment, dated at filing. No chained LLCs, no rapid-fire conveyances.
5. Pre-litigation transfer — not present. The sole assignment (2020-12-29) predates issuance (2022-10-04), and the separate litigation summary found no infringement suit naming US 11463470 as of the search date. There is no transfer timed to enable assertion.
6. Bankruptcy fire-sale — not present. Trane International Inc. / Trane Technologies is not and has not been in Chapter 7 or 11; no court-supervised patent sale.
7. Privateering — not present. No evidence Trane transferred rights to an NPE to assert against competitors; no SEC or press coverage of such an arrangement.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN — it terminates at the original operating assignee, Trane International Inc.

Verdict

Insufficient data (only the original assignment exists in the record; no post-issuance chain to analyze).

The complete recorded history is a single inventors-to-employer assignment (Reel 054769/0280, executed 2020-12-22, recorded 2020-12-29) to Trane International Inc., which remains the current owner. Every NPE signal is either not present or — in the single case of the correspondent field — unverifiable because the record was not retrievable this session, and no litigation naming this patent was found. This is the profile of a patent retained by its original operating-company owner for product/defensive use, not a troll vehicle; the "Insufficient data" verdict reflects that the ownership record contains nothing beyond the at-filing assignment rather than any affirmative NPE finding.

Verify at the USPTO Assignment Center: https://assignmentcenter.uspto.gov/ — search patent number 11463470 (or application 17/136,883); the single record should return Reel 054769/Frame 0280.

Based on the searches performed, I can provide the following prior-art analysis. I must first flag an important sourcing limitation (see below), then identify each reference.

Sourcing caveat (important)

I was able to retrieve the citation list associated with US 11,463,470 B2's patent family (as rendered by Google Patents for the related EPO filing EP4024758A1 — the "Family Cites Families (4)" list). I was not able, within this session, to pull the USPTO examiner's formal "References Cited" (the face-of-the-patent list in USPTO PatentCenter/PAIR) or any Non-Patent Literature (NPL) citations for the '470 file history. The searches returned no NPL entries and no CAFC 2026 docket activity. Treat the list below as the family-level cited art — likely overlapping with, but not guaranteed identical to, the formal USPTO citation list. The claim-anticipation assessments are preliminary and should be confirmed against full reference texts and the prosecution history.

Family-cited references found (4):

1. US 9,699,209 B2 — Cyence Inc.
2. US 10,999,307 B2 — Infinite Group, Inc.
3. US 11,258,817 B2 — Tenable, Inc.
4. US 11,811,813 B2 / US 2020/0213344 A1 — Trane International Inc. (same assignee as '470)

Reference-by-reference analysis (35 U.S.C. § 102, AIA)

Relevant effective filing date of the '470 for § 102 purposes: December 29, 2020 (Google Patents lists no earlier U.S. priority claim for application 17/136,883).

1. US 2020/0213344 A1 (published) → US 11,811,813 B2 (issued)

• Full citation: Trane International Inc., "Network security management for a building automation system," inventors Fletcher, Gasmen, Holst, Sivagnanam. US Patent Application Publication US 2020/0213344 A1, published July 2, 2020 (application filed December 28, 2018); issued as US 11,811,813 B2 on November 7, 2023.
• Prior-art status: § 102(a)(1) (publication more than one year before... actually before the '470 filing date) and § 102(a)(2) (filed 2018, before the '470's December 29, 2020 effective filing date; published July 2, 2020). Note: commonly owned with the '470, but common ownership does not defeat § 102 prior-art status for anticipation (a § 103(c)-type exemption could apply to obviousness rejections, not anticipation).
• Brief description: The closest known art. Discloses a building automation system controller that performs an electronic security self-assessment (firewall/network-security-device protection check; open communication-port identification; Ethernet and Wi-Fi configuration validation; determination whether routers communicating with the controller are firewall-protected; software/firmware version currency; installed-application listing), calculates a risk score and recommendation list, performs a peer assessment of devices on the same network (probing, firewall check, Ethernet/Wi-Fi check, open-port check), supports scheduled/periodic scans, and discloses a cloud-based electronic security assessment across multiple system control units. The '470 specification expressly incorporates the '344 publication by reference.
• Potential § 102 anticipation: Because it is the direct predecessor disclosure, it is the strongest candidate for anticipating the non-cloud limitations of claims 1 and 13 (firewall-protection determination, service/Ethernet/Wi-Fi validation, open-port determination, router/bridge/broadcast-device checks, peer probing of networked devices, risk score, recommendation list, periodic scheduling — mirrored in dependent claims 2–12 and 14–20, e.g., master/system-control-unit controller per claims 6/18, BACnet per claim 12, risk score per claims 9/20). However, the '470's independent claims 1 and 13 add limitations not evident in the '344 abstract/disclosure: (i) the controller requests the scan via a secured channel to a cloud-based service; (ii) the cloud-based service (not the controller) initiates the real-time scan based on the controller's data set and performs the external vulnerability assessment; and (iii) the cloud service validates egress points of the building automation system. Unless the full '344 text discloses a secured-channel, controller-initiated, cloud-performed real-time external scan plus cloud egress validation, '344 does not fully anticipate claims 1 or 13; it would instead be primary art for obviousness under § 103 and potentially anticipatory of certain dependent claims only if their base claim is met.

2. US 9,699,209 B2 (Cyence Inc.)

• Full citation: Cyence Inc., "Cyber vulnerability scan analyses with actionable feedback," filed December 29, 2014; published July 4, 2017.
• Prior-art status: § 102(a)(1) and § 102(a)(2) — well before December 29, 2020.
• Brief description: Methods/systems for scanning networks or computer systems to identify cyber vulnerabilities, computing risk scores, and producing actionable feedback/recommendations to remediate identified exposures.
• Potential § 102 anticipation: Not a building-automation disclosure. It covers generic cyber-vulnerability scanning, risk scoring, and actionable recommendations. It could overlap with the risk-score/recommendation concepts (dependent claims 9, 10, 20) only if combined with the full method/system of claim 1 or 13 — which a single-reference § 102 analysis cannot do. In my assessment it likely does not anticipate any single independent or dependent claim standing alone, because it lacks the BAS controller + cloud-service architecture, the secured-channel request, the real-time cloud-initiated scan, egress-point validation, and the controller peer-assessment of networked building devices.

3. US 10,999,307 B2 (Infinite Group, Inc.)

• Full citation: Infinite Group, Inc., "Network assessment systems and methods thereof," filed May 19, 2016; published May 4, 2021.
• Prior-art status: § 102(a)(2) — application filed before December 29, 2020, though issued/published after the '470's effective filing date. (If it published before the '470 filing date in some form, it could also qualify under § 102(a)(1); the 2021-05-04 issue date shown means the § 102(a)(2) route is the operative one.)
• Brief description: Systems and methods for assessing networks — probing/scanning networked assets, identifying exposures, and reporting assessment results.
• Potential § 102 anticipation: Similar to Cyence, it is a general network-assessment disclosure. It lacks the building-automation-system controller context and the specific cloud-service external-scan/egress-validation division of claims 1 and 13. Likely not anticipatory of the independent claims; at most it might inform obviousness combinations. No single claim of the '470 appears fully met by this reference based on available information.

4. US 11,258,817 B2 (Tenable, Inc.)

• Full citation: Tenable, Inc., "Rule-based assignment of criticality scores to assets and generation of a criticality rules table," filed October 26, 2018; published February 22, 2022.
• Prior-art status: § 102(a)(2) — filed before December 29, 2020; issued after the '470's effective filing date.
• Brief description: Techniques for rule-based assignment of criticality scores to assets (e.g., in a vulnerability-management platform) and generation of a criticality rules table used to prioritize remediation.
• Potential § 102 anticipation: Relevant principally to the risk-score/criticality concepts in dependent claims 9 and 20 (risk-score determination) and possibly the recommendation-list prioritization. Because claims 9 and 20 depend from independent claims 1 and 13 respectively, Tenable alone cannot anticipate those dependent claims without also disclosing the full independent-claim combination, which (as a general IT-asset scoring tool) it does not appear to do. It is best characterized as secondary art for § 103 combinations rather than a § 102 anticipatory reference.

Bottom line

• Closest prior art / most relevant: US 2020/0213344 A1 (Trane; → US 11,811,813 B2) — same title, same assignee, incorporated by reference into the '470. It plausibly anticipates much of the assessment subject matter in claims 1 and 13 and their dependent claims, except the independent claims' cloud-side limitations (secured-channel request; cloud-initiated real-time scan based on the controller data set; cloud validation of egress points), which appear to be the examiner-allowed points of distinction.
• Secondary art: Cyence (US 9,699,209 B2), Infinite Group (US 10,999,307 B2), and Tenable (US 11,258,817 B2) are generic vulnerability-scanning/risk-scoring references; none appears, standing alone, to anticipate any full claim of the '470, based on the abstract-level information retrievable in this session.
• Unverified items I cannot state with confidence: (1) the complete USPTO examiner's "References Cited" list and any NPL on the face of the '470; (2) whether the '470 file history contains an IDS adding further art (e.g., the EP search report for EP4024758A1 may cite additional documents); (3) full-text confirmation of whether the '344 discloses secured-channel cloud scanning and egress validation. Full-text review of US 2020/0213344 A1 and the '470 file wrapper is needed before asserting a § 102 anticipation position with confidence.

§ 103 Obviousness Analysis — U.S. Patent No. 11,463,470 B2 (Trane International Inc.)

Scope, sources, and caveats

This memorandum analyzes whether the claims of US 11,463,470 B2 ("the '470 patent") would have been obvious under 35 U.S.C. § 103 to a person of ordinary skill in the art ("POSITA") as of the patent's effective filing date (December 29, 2020). It builds on the prior-art work product previously generated for this matter and uses the four family-level references identified there:

Sourcing caveat carried forward: the formal USPTO "References Cited" list and file history for the '470 were not retrieved in this session; the four references above are the family-level citations (via EP 4,024,758 A1). The analysis below is therefore preliminary in the same sense flagged in the prior-art section and should be confirmed against full texts and the prosecution history before being relied upon in a pleading. In addition, live searches this session confirmed key disclosure details of each reference (quoted/paraphrased below), and no CAFC or PTAB activity involving the '470 was located (consistent with the prior sections).

One contradiction with the prior work product is flagged up front (see § 5): the earlier prior-art memo states that common ownership of R1 "does not defeat § 102 prior-art status for anticipation." Under the AIA, that statement is incomplete. 35 U.S.C. § 102(b)(2)(C) excludes a disclosure from § 102(a)(2) prior art where the subject matter disclosed and the claimed invention were commonly owned (or under an obligation of assignment to the same person) as of the effective filing date — and R1 and the '470 were both Trane International Inc. property on December 29, 2020. R1's § 102(a)(1) availability is also complicated by the one-year grace period (§ 102(b)(1)) and by overlapping inventorship (Mangayarkarasi Sivagnanam is named on both R1 and the '470). R1's usability as prior art is therefore a genuine, fact-intensive exposure that any challenger must resolve before betting the case on R1 (§ 5).

1. Legal framework

Under § 103, a patent claim is invalid if the differences between the claimed invention and the prior art are such that the claimed subject matter as a whole would have been obvious at the time the invention was made to a POSITA. Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966), requires: (1) the scope and content of the prior art; (2) differences between the prior art and the claims; (3) the level of ordinary skill; and (4) objective indicia of non-obviousness. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007), instructs that obviousness is a flexible inquiry; a court may rely on "ordinary creativity," design incentives, "obvious to try," and the predictable use of known techniques to solve known problems, and need not find a precise teaching, suggestion, or motivation in the references. A combination of familiar elements "according to known methods" that yields "no more than one would expect from such an arrangement" is typically obvious. Id. at 416.

The relevant prior art is the same for § 103 as for § 102, subject to the availability caveats in § 5. No AIA trial has ever been instituted on the '470, so no ground is estopped or consumed, and all § 102/§ 103 grounds remain available to a first challenger (see PTAB section).

2. The claims and the POSITA

Independent claims 1 (method) and 13 (system) require, in substance:

1. Controller-side request: the BAS controller requests an electronic security scan of itself, transmitting a data set of the controller over a secured channel to a cloud-based service;
2. Cloud-side initiation: the cloud service initiates the scan in real time based on that data set;
3. Cloud-side vulnerability assessment of the building automation system (firewall/network-security-device protection; service configuration; Ethernet and Wi-Fi configuration; open communication ports; protection of routers/bridges/broadcast devices; security certificates on open ports; server communication);
4. Cloud-side egress-point validation;
5. Controller-side peer assessment of the networked electronic devices (probing; firewall protection; Ethernet/Wi-Fi configuration; open ports);
6. Recommendation list generated based on both the cloud assessment and the controller's peer assessment.

Dependent claims 2–12 / 14–20 add, among other things: real-time execution of specific checks during the scan (2/14); checks performed independently of the scan (3/15); password-policy validation (4/16); recommendations based on egress validation (5/17); master vs. unit controller (6–7/18); IP-address data sets (8/19); risk-score determination (9/20); on-screen reporting (10); periodic scheduling (11); BACnet connectivity (12).

POSITA profile: a designer/engineer with (i) a bachelor's degree (or equivalent experience) in computer science, computer/electrical engineering, or controls; (ii) several years' experience in building automation / HVACR controls (BACnet, LonTalk, Modbus, TCP/IP); and (iii) working familiarity with network security practice — firewalls, TLS/SSL configuration and certificates, port scanning, vulnerability scanners, and cloud/web services. A POSITA would routinely consult both BAS-controls literature (ASHRAE BACnet standards) and IT-security literature (NIST guidance, SANS, vulnerability-management vendor materials).

3. What the references actually disclose (confirmed this session)

R1 — Trane '344 (US 2020/0213344 A1)

The '470's own specification states that "different embodiments of network security management for a building automation system are described in US 2020/0213344, incorporated by reference in its entirety." R1 is the direct predecessor of the '470 and discloses, in the BAS context:

• a controller ("system control unit") performing an electronic security self-assessment: whether the controller is behind a firewall (with an "IP Range Check" distinguishing private IP 10.28.28.136 behind the firewall from public IP 164.101.185.82 exposed to the Internet), open communication ports ("Port 8022 … open and accessible via the Internet"), Ethernet and Wi-Fi configuration, routers connected to the controller, software/firmware currency, installed applications, and cipher strength ("moderate cipher setting — recommend … a stronger cipher configuration");
• password security testing (the R1 report shows "Password: Brute force testing was unsuccessful");
• a peer assessment of devices connected to the controller on the same network (R1 FIG. 4);
• a risk score and recommendation list;
• periodic scheduling and remote initiation;
• cloud connectivity and cloud-based assessment: "the system control unit can be connected to the cloud"; "a cloud-based electronic security assessment can … analyze system control units (even those not corresponding to a same building automation system) for security vulnerabilities" (R1 ¶ [0008]–[0010], FIG. 6); and the R1 report itself recommends "Enable cloud services for additional reporting and functionality."

R1 does not (on the available text) disclose: the controller transmitting its data set over a secured channel to a cloud service that then performs the external scan in real time; or cloud-side egress-point validation. Those are the apparent points of distinction that the examiner allowed.

R2 — Cyence '209 (US 9,699,209 B2)

A cloud/server-based ("system 105 comprises a server or cloud-based computing device") cyber-vulnerability platform that: determines an entity's external infrastructure (cyber assets), collects infrastructure information about those assets, performs passive cyber-security vulnerability testing from the external network vantage point, assesses vulnerabilities, calculates an association score, and automatically recommends computer network changes to reduce the assessed vulnerabilities. Discloses GUIs/dashboards. This is precisely the "scan from outside as the Internet sees it, score it, recommend fixes" paradigm, albeit in a general-IT/insurance-analytics context rather than BAS.

R3 — Infinite Group '307 (US 10,999,307 B2)

Architecturally the closest of the non-Trane references to the '470's division of labor:

• a network scanning appliance 14 plugged into an internal-network Ethernet port that inventories hosts (ARP to every subnet address every minute), fingerprints hosts, and runs vulnerability scans every ~2 minutes;
• a network assessment computing device 12 that "is an external scanner in a cloud with a secure cloud hosting provider [that] processes information obtained by the network scanning appliance" — i.e., an on-premises scanner + cloud-side external assessment engine;
• assessment of "internal and external security protection and health of a network environment," with a firewall 26 separating the internal and external networks;
• vulnerability checks that include TLS/SSL cipher validation ("Check for SSL Weak Ciphers," CVE-2016-2183/"Sweet32," "SSL Certificate Signed Using A Weak Signature Algorithm");
• per-device "NodeScore" risk levels, "actionable items," and rich GUIs (node health, vulnerabilities found, risk level).

R4 — Tenable '817 (US 11,258,817 B2)

An asset-centric vulnerability management system that rule-based assigns criticality scores to assets from a criticality rules table mapping asset attributes (IP, MAC, FQDN, etc.) to risk scores, then determines vulnerability characteristics and prioritizes remediation from those scores. Relevant to the risk-score and recommendation-prioritization claims.

4. The obviousness case, claim by claim

4.1 Combination A (primary): R1 + R3 (+ R2 and/or R4 as supporting)

The combination: Take R1's BAS controller self-assessment + peer assessment + risk score + recommendations, and implement R1's already-contemplated "cloud-based electronic security assessment" (R1 ¶ [0010], FIG. 6) using the known architecture of R3 — an on-premises scanner that probes the local network devices plus a cloud-hosted external scanner that receives data from the premises side and performs the external assessment in (near-)real time — while adding R3's TLS/SSL cipher- and certificate-validation checks to the cloud-side port validation.

Element-by-element (independent claims 1 and 13; bracketed numbers track the claim language):

Reasoning and motivation (KSR): A POSITA reading R1 — which (a) discloses controller-side firewall/port/cipher assessment, (b) discloses peer assessment of the controller's network neighbors, (c) discloses a risk score and recommendation list, (d) expressly contemplates a cloud-based electronic security assessment of system control units, and (e) in its own report recommends "enable cloud services" — would understand that R1's remaining design problem is who runs the scan and from where. R3 supplies the textbook answer already proven in the general network-security field: a lightweight on-premises scanner that inventories and probes internal hosts, feeding a cloud-hosted external scanner that performs assessment from the Internet side in near-real time and reports node scores and actionable items. Substituting R1's BAS controller for R3's appliance, and R1's cloud-enabled controller for R3's cloud assessment computing device, uses each element for its known function (scan/probe on the inside; assess from the outside; report and recommend) with a predictable result. That is the core KSR combination analysis. The "secured channel" is the conventional TLS/VPN transport that any cloud-service deployment used in 2020, and R3's own "secure cloud hosting provider" context points to it.

4.2 Combination B: R1 + R2 (+ R3 optional)

Cyence '209 independently supplies the cloud-side external-scan engine: determining an entity's external infrastructure, collecting infrastructure information about the assets (including network devices, ports, and firewall-related attributes), performing passive vulnerability testing from the outside, computing a score, and automatically recommending network changes. Adding R2 to R1 addresses the same cloud-side gaps as R3 but with an explicit "external scanning of the entity's Internet-facing assets" disclosure and an explicit auto-recommendation loop tied to a score — directly supporting the cloud-initiated external scan, the cloud-side firewall/open-port assessment, and the "recommendation list based on the [cloud] assessment" limitations. R2's passive (non-intrusive) scanning is also a natural fit for the '470's stated desire to "reduce public exposure … by a reduced security scan frequency," because passive/lightweight external testing is less invasive than aggressive scanning. Motivation: R1 says "connect the controller to the cloud and run cloud-based security assessment of system control units"; R2 shows an operating cloud system that already performs exactly that kind of external assessment with scoring and recommendations on general IT assets; adapting it to BAS controllers is applying a known tool to a new-but-analogous environment, which KSR treats as obvious when a POSITA would have reason to do so (securing Internet-connected building controllers was a recognized problem — R1's own background describes controllers "prone to various types of cyberattacks" and exposed to "Internet searches").

4.3 Combination C: R1 + R4 (risk-score claims 9/20, and recommendation weighting)

Claims 9 and 20 require determining a risk score based on the assessed vulnerabilities. R1 already discloses a risk score. R4 adds the specific, rule-based implementation: a criticality rules table mapping asset attributes (including IP addresses) to criticality scores indicating risk if compromised, used to prioritize remediation. Combining R4's rule-based scoring with R1's vulnerability assessment (or with the Combination A/B cloud architecture) is an obvious refinement: the POSITA seeking a defensible, repeatable risk score would adopt R4's table-driven criticality assignment. Same field (vulnerability management); same purpose (prioritize fixes); predictable result.

4.4 Dependent claims

• Claims 2/14 (firewall-protection check, Ethernet/Wi-Fi validation, open-port determination performed by the cloud service in real time during the scan): R3 performs vulnerability scans continuously (every ~2 minutes) and describes real-time/near-real-time assessment of internal and external protection; R2 passively tests external assets on an ongoing basis. Making the cloud-side checks concurrent with the initiated scan is the default mode of R3/R2 — no independent inventive step.
• Claims 3/15 (service configuration, router/bridge/broadcast-device protection, certificate validation, server communication performed independently of the scan): R1 already performs router and cipher checks locally; R3 validates SSL/TLS certificates and weak ciphers; splitting "validate configuration" from "run the live scan" is a scheduling choice within the ordinary skill — the '470 itself describes the split as merely a design option (Aspects 2–3).
• Claims 4/16 (password policy): R1's own report demonstrates password brute-force testing ("Password: Brute force testing was unsuccessful"); R3's vulnerability set likewise includes credential/weakness checks. Obvious.
• Claims 6/18 and 7 (master/system control unit vs. unit controller): R1 is built around the "system control unit," and the '470's own specification equates it with the master controller; applying the assessment to a unit controller is the same method at a different node on the same network — obvious.
• Claims 8/19 (data set includes IP addresses): R3 obtains "device information for one or more devices each with an Internet Protocol address"; R2 collects infrastructure information about cyber assets; R4 identifies assets by IP. Trivial.
• Claims 9/20 (risk score): see Combination C; also R1 (risk score), R2 (association score), R3 (NodeScore).
• Claim 10 (send risk score/recommendations to a display): R1's FIG. 7 report GUI, R3's node-health GUIs, R2's dashboards. Routine.
• Claim 11 (periodic scheduling): R1 expressly discloses periodic assessment; R3 runs continuously. Obvious.
• Claim 12 (BACnet): supplied by R1 (BAS/BACnet context). If R1 is unavailable (see § 5), this claim is the hardest to reach with R2–R4 alone and would require a separate BAS/BACnet reference.

5. Availability caveat for R1 (common ownership / overlapping inventorship) — flagged contradiction

The prior-art section states R1 is § 102(a)(1)/(a)(2) art and that common ownership does not defeat anticipation. As noted above, this is incomplete under the AIA and must be flagged:

• § 102(a)(2): R1 was effectively filed 2018-12-28 (before the '470's December 29, 2020 effective filing date) and names inventors. Under § 102(b)(2)(C), R1 is not § 102(a)(2) prior art if R1's subject matter and the '470 were owned by the same person (Trane) not later than the '470's effective filing date — which they were. R1 may therefore be unavailable as § 102(a)(2) art unless the challenger can show the exception does not apply (e.g., differing inventive entities and no qualifying common ownership chain — here the assignment records show Trane for both, so this is a real hurdle).
• § 102(a)(1): R1 published 2020-07-02, within one year of the '470's filing. Under § 102(b)(1), an within-grace-period disclosure is not prior art if made by a joint inventor of the '470 or by one who obtained the subject matter from a joint inventor. Inventor Sivagnanam is named on both R1 and the '470; whether R1's disclosure is attributable to her (as a joint inventor of the '470) or whether the portions contributed by R1's other three inventors (Fletcher, Gasmen, Holst) were independently developed and therefore remain prior art is a fact question that a patent owner would litigate.
• Practical consequence: any § 103 strategy should be built to survive R1's exclusion. Combinations relying only on R2–R4 (§ 4.5 below) are therefore important, as is identifying independent BAS/BACnet prior art outside this four-reference set (see § 7).

The analysis in § 4 assumes R1 is available (as the prior-art section directed); the caveat is that its availability is genuinely contested.

4.5 Fallback combination: R2 + R3 + R4, without R1

If R1 is excluded, the challenger's strongest fallback is R3 as the architectural anchor + R2 as the external-scan/scoring engine + R4 for rule-based risk scoring:

• R3 supplies: on-premises scanner probing all internal hosts (host inventory, fingerprinting, port and vulnerability scans, SSL/TLS cipher/certificate checks); a cloud-hosted external scanner that processes premise-obtained data and assesses internal and external network protection across a firewall boundary; node scores and actionable items.
• R2 supplies: cloud-side external-infrastructure discovery and passive vulnerability testing of Internet-facing assets, association scoring, and automatic remediation recommendations.
• R4 supplies: rule-based criticality scoring of assets.

Together, R2–R4 cover the full architecture of claims 1 and 13 — inside probing (R3), cloud-side external scan initiated from supplied device data (R3/R2), firewall/port/certificate/cipher checks (R2/R3), risk scoring (R2/R3/R4), and recommendation lists (R2/R3). What they lack is the BAS-specific frame (a "building automation system," "controller," BACnet) and the explicit "secured channel" request and egress limitations. A challenger would argue the BAS frame is a routine application of general vulnerability-management to a known class of networked controllers (the problem of securing Internet-connected building controllers was notorious by 2020 — Shodan-indexed HVAC/BAS devices were a documented attack surface), making substitution obvious. That argument is moderately weaker than Combination A because R2–R4 do not themselves mention building automation, and "field-of-art" disputes are likelier. This is why locating a BAS-specific reference (R1 or otherwise) materially strengthens the case.

6. The egress limitation — candid risk assessment

"Validating, by the cloud service, egress points of the building automation system" appears in both independent claims, and claim 5/17 ties the recommendation list to it. Of all limitations, this is the least supported by explicit disclosure in R1–R4:

• R3's firewall (26) sits between internal and external networks, and R3 assesses "internal and external security protection and health," which plausibly encompasses testing the firewall's filtering behavior; but the available text does not explicitly say "egress."
• R2 validates external infrastructure from outside; R4 manages vulnerability data. Neither is egress-specific.
• Egress filtering itself is conventional, well-documented security practice (the '470's own specification defines "egress"/"egress filtering" as a known concept — monitoring and restricting outbound flows at a router/firewall edge). The '470's method 600 explains the reason to check egress: a device with a private IP can still be exposed if the firewall forwards inbound traffic, and a public-IP device can be protected if egress rules are sound.

A § 103 challenger can argue, under KSR, that a POSITA implementing an external security scan of a BAS would, as a matter of ordinary skill and standard hardening practice, verify the edge device's filtering configuration (including outbound/egress rules and any port-forwarding/NAT that would defeat a private-IP assessment) — the '470's own dependent-claim split shows the egress check is conceptually part of the same firewall/edge validation R1 and R3 already teach. But candor requires noting: if a court requires an explicit teaching of "egress validation," none of the four references provides it, and this limitation may be the examiner's principal allowance basis. A robust invalidity position should add a firewall-auditing/egress-filtering reference (e.g., firewall-rule auditing and egress-filtering literature, SANS/NIST guidance predating 2020, or a vendor patent on firewall configuration validation) to Combinations A/B. This is flagged as a genuine weak point, not a formality.

7. Motivation and reasonable expectation of success (synthesis)

Why a POSITA would combine these references — articulated independently of hindsight:

1. Same problem, same solution space. R1, R2, and R3 all address the same problem: assessing networked devices' exposure to Internet attack and telling a user what to fix. R1 frames it for BAS controllers; R2 and R3 frame it for general networks with cloud-based scanning engines. The analogous-art inquiry (same field of endeavor or reasonably pertinent to the problem) is easily satisfied between network vulnerability assessment (R2/R3/R4) and securing a BAS network (R1) because R1's own background identifies the BAS problem as a network-exposure problem ("controllers … prone to various types of cyberattacks," exposed open ports, routers, servers). A POSITA securing a BAS would look to standard vulnerability-management tools — the same tools R2/R3/R4 describe.

2. Design incentives documented in the art. R1's report literally instructs the user to "Enable cloud services for additional reporting and functionality," and R1 ¶ [0008]–[0010] contemplates connecting the controller to the cloud and running cloud-based electronic security assessments across system control units. R1 thus supplies the incentive to push assessment into the cloud; R3 (and R2) supply the mechanism (cloud-hosted external scanner receiving premise-side data). The '470's own justification — give the installer a real-time report before leaving the site, without burdening a resource-limited controller — is precisely the value proposition R3's appliance-plus-cloud design already delivers (continuous scanning by a lightweight on-prem device, processing in the cloud). Taking a known architecture from the general field and pointing it at the BAS controllers R1 already taught to connect to the cloud is the paradigm KSR calls obvious ("the improvement is no more than the predictable use of prior art elements according to their established functions").

3. Resource constraints make offloading obvious. The '470's controller has "a relatively limited amount of storage" and its primary job is running the BAS. A POSITA reading R1 (controller-executed scans) would recognize that heavy external scanning and certificate/cipher validation consume controller resources; R3's division — light on-prem scanning + cloud processing — is the textbook answer, and R2's passive external testing is the non-intrusive answer. Both are known alternatives with predictable tradeoffs.

4. Interchangeability of known check-types. Firewall-protection checks (public vs. private IP), open-port discovery, TLS cipher/certificate validation, and "recommend closing port X / upgrading cipher Y" are staple outputs of commercial scanners; R1 shows them for BAS and R3 shows them (including SSL weak-cipher and weak-certificate-signature findings) for general networks. Combining check-sets is additive, not synergistic.

5. Reasonable expectation of success is high. Every element is a known, functioning component: a BAS controller that can reach the cloud (R1), an on-premises network prober (R1 peer assessment; R3 appliance), a cloud-hosted external scanner (R3; R2), certificate/cipher validation (R3), scoring (R1/R2/R3/R4), and recommendations (R1/R2/R3). Assembling them along R3's proven data flow (premise → cloud → report) presents no technical obstacle a POSITA could not predictably overcome.

6. Objective indicia: none were identified (no long-felt-need, commercial-success, or licensing evidence located). The absence of any PTAB challenge to date is consistent with either low assertion activity or weak claims; it is not itself an indicium of non-obviousness. If the patent owner proffers unexpected results or industry skepticism, those would need to be tested against the record.

8. Bottom line

• With R1 available: Combination A (R1 + R3), optionally reinforced by R2 and R4, renders independent claims 1 and 13 obvious, and the dependent claims (2–12, 14–20) obvious as well — except that the cloud-side egress-validation limitation (claims 1, 13, 5, 17) rests more on common knowledge and ordinary hardening practice than on an explicit reference teaching, making it the single most defensible limitation for the patent owner.
• With R1 excluded (the § 102(b)(2)(C)/§ 102(b)(1) common-ownership and overlapping-inventorship issues being resolved against the challenger), R2 + R3 + R4 still supply the full architecture but not the BAS/BACnet frame; the case weakens and depends on a successful "application of general vulnerability management to known BAS controllers" argument plus common knowledge for egress.
• Recommended next steps: (1) pull the USPTO file history and formal References Cited for the '470 to see what the examiner actually allowed over and whether R1 was the basis of allowance; (2) obtain full texts of R1–R4 and confirm the egress and secured-channel gaps; (3) resolve R1's prior-art availability (ownership/inventorship analysis); and (4) add at least one dedicated egress/firewall-rule-auditing reference and one independent BAS/BACnet security reference predating December 29, 2020, to shore up the two weak limitations.

Prepared April 26, 2026. All citation and status statements are subject to the sourcing caveats in the prior-art section (formal examiner citations and NPL not retrieved; no PTAB/CAFC activity located as of the search date).