DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/2/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/2/2026 was in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS is being considered by the examiner.
Response to Amendment
Claims 1, 5, 10, 14, and 19 are amended. Claims 1-20 are pending.
Response to Arguments
Applicant's arguments filed 3/2/2026 have been fully considered.
Regarding the rejections of claims 1-20 under 101 as being directed to an abstract idea without significantly more, Examiner respectfully disagrees with Applicant’s arguments for the following reasons.
Regarding Step 2A, Prong 1, on pages 8-9 of the response Applicant contends that the amendment to claim 1 characterizing the “categorizing a fault of the one or more buildings …” and “causing on-site maintenance to be performed …” as being implemented by the “fault categorization model” results in this step as not falling within the mental processing exception because the model is claimed as performing the categorization and the model is not performing a mental process on a generic computer.
Examiner acknowledges that a model implemented by one or more processors as recited in claim 1 may constitute an additional element falling outside the mental processes exception. However, the functions “categorizing a fault of the one or more buildings …” and “causing on-site maintenance to be performed …,” individually and in combination, fall within the mental processes exception because these steps may be performed via mental processes (e.g., evaluation of data and judgment).
Regarding Step 2A Prong 2, Applicant contends on page 10 that the alleged steps such as “receiving operating data for one or more pieces of building equipment” and “determining one or more building faults for the one or more pieces of building equipment based on the operating data” are fully integrated into the practical application by “Applying or using the judicial exception in some other meaningful way beyond merely linking the use of the judicial exception to a particular technological environment” (MPEP 2106.04(d)(I). In support, Applicant asserts on pages 10-11 that the combined steps of “categorizing the one or more building faults as remote fix faults or on-site fix faults by applying the operating data and the one or more building faults as inputs to a fault categorization model, the fault categorization model trained to generate a remote fix or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data," "responsive to the fault categorization model categorizing a fault of the one or more building faults as a remote fix fault, attempting to repair the fault remotely by transmitting control signals or commands...," and "responsive to the fault categorization model categorizing the fault as an on-site fix fault, the fault categorization model causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault" applies or uses the alleged abstract idea in a meaningful way to maintain operation of the building equipment.
Examiner submits that the maintenance of the building equipment constitutes a generalized purpose/intended result of the claimed system/method that itself is fundamentally characterized by the combination of steps falling within the judicial exception.
On page 11, Applicant further cites the “responsive to …” steps as including additional elements “that specify how the result of the fault classification is used to trigger responsive action for maintaining the operation of building equipment.”
Examiner submits that a broadest reasonable interpretation of “responsive to” claim 1 entails “deciding to” based on information derived from steps that themselves fall within the mental processes exception, such that the additional elements are confined to processor-implemented modeling, including the characterization that the model has been trained (no positive recitation of steps implemented by the recited system of actually training the model), and also including “attempting to repair the fault remotely by transmitting …” which themselves, individually or in combination, do not appear to characterize any particular manner of using the fault classification to trigger responsive action.
On page 11 of the response, Applicant further contends that claim 1 reflects an improvement in the technical field of maintenance of building equipment by automatically executing a maintenance or repair action that can be performed as rapidly and will little energy expenditure according to the faults which occurred and the information related to those faults. Applicant notes guidelines set forth in MPEP 2106.04(d)(1) for evaluating a claim for improvements under Step 2A Prong 2 as including a first step of evaluating the specification to determine whether the improvement is sufficiently disclosed and a second step of evaluating the claim to determine whether the claim itself includes steps/components that provide the improvement. Applicant contends on page 12 that the specification describes the technical improvement in sufficient detail in terms, for example, of “advantageously help[ing] building managers and administrators save costs by categorizing faults as ‘remote fix’ and ‘on-site fix’ before sending a technician or maintenance team on site to repair a fault so that technicians are only sent out for faults that require on-site repair.” Applicant further contends on page 12 that the claims recite features including the categorizing of the faults as remote or on-site fixes and undertaking corresponding actions depending on the categorization that reflects the improvement.
The Examiner submits that the utility of the claimed invention cited by Applicant in terms of the specification description of improved efficient, speed, and potential energy savings as reflected by the claimed elements is confined to the series of steps falling within the abstract idea in one aspect and automation (computer modeling) in a distinct aspect and does not appear derived via a meaningful integration of the processing/modeling steps into a practical application in a manner representing an improvement to technology. Instead, the utility/benefit of implementing the combination of processing steps for determining a course of remedial action is only functionally related to the additional elements in terms of program implementation (processor-implemented modeling) and insignificant post solution activity (attempting to repair) rather than, for example, having a particularized relation between the steps/sequence of steps and the manner of implementing the processing that may constitute a significant technological improvement. Applicant’s summary of the intended utility of the claimed invention on page 12 as being provided by the additional elements of “responsive to categorizing a fault … as a remote fix fault, attempting to repair the fault remotely …,” and “responsive to categorizing the fault as an on-site fault, causing on-site maintenance …” in combination with the other elements of claim 1 reflects an improvement in terms of the results that will flow from categorization decision/determination itself, not in terms of a technical improvement such as for example how applying the additional element “transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix or initiating a software or firmware update for the equipment” itself or in combination with other elements specifically improves the overall technology.
The Examiner submits that while a computer program driven execution of the recited method may be faster and more efficient, the improved efficiency and speed gained by the fundamental aspect of claim 1 (determining whether a given fault should be repaired remotely or on-site) is also attained via the steps being performed via mental processes in combination with the recited “additional elements,” such that as currently recited the additional elements, individually and/or on combination including in combination with the steps falling within the judicial exception do not appear to effectuate a significant improvement to the technical field (i.e., a technical improvement).
On page 13 of the response, Applicant cites the “trained” characterization of the model as supporting the contention that the judicial exception is integrated into a practical application. In support, Applicant contends that “the particularly configured fault categorization model ‘trained to generate a remote fix or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data’ is an improvement to the automatically responding to faults by ensuring that a proper remote-fix or on-site response is taken. The improvement is provided by the specially trained/configure categorization model.”
Examiner submits, as also noted in the grounds of rejection, that claim 1 does not positively recite the training as being implemented by the recited system. Furthermore, using historical data that tracks the function of the model (historical corrective action data) and other operating data appears to represent ordinary model training (generating instructions for implementing the model function) implemented in the foreseeably logical manner of such training (apply historical data relating to the features (operating data) and targets (corrective action options) such that no improvement in any technical field (training models and/or monitoring and remediating equipment faults) appears evident. Therefore, the use of a trained model that has been trained using historical corrective action and operating data constitutes extra solution activity that fails, individually and/or in combination with the other claim elements, to integrate the judicial exception into a practical application.
On pages 13-15 of the response, regarding Step 2B analysis, Applicant contends that the additional elements "categorizing the one or more building faults as remote fix faults or on-site fix faults by applying the operating data and the one or more building faults as inputs to a fault categorization model, the fault categorization model trained to generate a remote fix output or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data" "responsive to categorizing a fault of the one or more building faults as a remote fix fault, attempting to repair the fault remotely by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment," and "responsive to categorizing the fault as an on-site fix fault, causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault," in Claim 1 amounts to significantly more than the alleged abstract idea because it contributes to an inventive concept when considered in combination with the preceding steps of Claim 1. Applicant cites the use of a fault classification model for categorizing the faults as on-site fix or remote fix and emphasizes that the maintenance/repair actions are performed responsive to categorizing the fault and include particular actions performed based on the classification.
The Examiner submits that, as set forth in the grounds for rejecting claim 1 under 103, claim 1 does not include an inventive concept as the features of claim 1 are taught or otherwise rendered obvious in view of Razak (US 2019/0355240 A1). Furthermore, as set forth in the current grounds for rejecting claim 1 under 101, the determination to perform of the repair or maintenance actions “responsive to categorizing the fault” itself falls within the mental processes exception and the additional elements (e.g., program instructions (model) to implement the categorization, attempting to repair by transmitting control signals or commands or initiating a software/firmware update) constitute extra solution activity and some are generic and well-understood as evidenced by the disclosures of Razak and Picardi and therefore fail to result in the claim as a whole amounting to significantly more than the judicial exception.
Regarding the rejections of independent claims 1, 10, and 19 under 103, and as noted by Applicant on page 16 of the response, the amendments to claims 1, 10, and 19 include elements not previously addressed in the rejections of claims 1, 10, and 19. However, in view of further consideration, and particularly considering the grounds for rejecting claim 5, new grounds for rejecting claims 1, 10, and 19 under 103 are set forth herein.
Applicant’s arguments regarding dependent claims 2-9, 11-8, and 20 are dependent on the elements added by amendment to claim 1, 10, and 19 and therefore are also addressed by the new grounds for rejecting claims 1, 10, and 19 under 103.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention in each of these claims is directed to the abstract idea judicial exception without significantly more.
Claim 1, substantially representative also of independent claims 10 and 19, recites:
“[a] system comprising:
one or more memory devices having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving operating data for one or more pieces of building equipment;
determining one or more building faults for the one or more pieces of building equipment based on the operating data;
categorizing the one or more building faults as remote fix faults or on-site fix faults by applying the operating data and the one or more building faults as inputs to a fault categorization model, the fault categorization model trained to generate a remote fix output or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data;
responsive to the fault categorization model categorizing a fault of the one or more building faults as a remote fix fault, attempting to repair the fault remotely by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment; and
responsive to the fault categorization model categorizing the fault as an on-site fix fault, the fault categorization model causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault.”
The claim limitations considered to fall within in the abstract idea are highlighted in bold font above and the remaining features are “additional elements.”
Step 1 of the subject matter eligibility analysis entails determining whether the claimed subject matter falls within one of the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: process, machine, manufacture, or composition of matter. Claim 1 recites a system (machine), claim 10 recites a method, and claim 19 recites an article of manufacture and therefore each falls within a statutory category.
Step 2A, Prong One of the analysis entails determining whether the claim recites a judicial exception such as an abstract idea. Under a broadest reasonable interpretation, the highlighted portions of claim 1 fall within the abstract idea judicial exception. Specifically, under the 2019 Revised Patent Subject Matter Eligibility Guidance, the highlighted subject matter falls within the mental processes category (including an observation, evaluation, judgment, opinion). MPEP § 2106.04(a)(2).
The recited functions:
“receiving operating data for one or more pieces of building equipment;
determining one or more building faults for the one or more pieces of building equipment based on the operating data;”
“categorizing the one or more building faults as remote fix faults or on-site fix faults by applying the operating data and the one or more building faults as inputs,”
“responsive to” “categorizing a fault of the one or more building faults as a remote fix fault” and
“responsive to” “categorizing the fault as an on-site fix fault,” “causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault,”
may be performed as mental processes.
Receiving operating data for one or more pieces of building equipment may be performed via mental processes (e.g., observation). Determining one or more building faults for one or more pieces of building equipment based on operating data and categorizing the one or more building faults as remote fix faults or on-site fix faults by applying the operating data and the one or more building faults as inputs may also be performed via mental processes (e.g., evaluation of operating data to form judgement in terms of determining building faults for building equipment and further determining whether remote or on-site remediation is needed based on the operating data and fault data) The causal determination to attempt repair “responsive to categorizing a fault of the one or more building faults as a remote fix fault” and similarly the causal determination to cause on-site maintenance to be performed “responsive to categorizing the fault as an on-site fix fault” may be performed via mental processes (e.g., judgement in deciding to attempt repair based on remote fix determination and judgement in deciding to commence on-site repair based on on-site fix determination). Furthermore, the Examiner finds that a broadest reasonable interpretation in view of Applicant’s specification of “causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault” may itself entail mental processes (e.g., conceptualization of need for and decision to pursue on-site maintenance may be a causal factor and therefore fall within “causing on-site maintenance to be performed”).
Step 2A, Prong Two of the analysis entails determining whether the claim includes additional elements that integrate the recited judicial exception into a practical application. “A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception” (MPEP § 2106.04(d)).
MPEP § 2106.04(d) sets forth considerations to be applied in Step 2A, Prong Two for determining whether or not a claim integrates a judicial exception into a practical application. Based on the individual and collective limitations of claim 1 and applying a broadest reasonable interpretation, the most applicable of such considerations appear to include: improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); applying the judicial exception with, or by use of, a particular machine (MPEP 2106.05(b)); and effecting a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)).
Regarding improvements to the functioning of a computer or other technology, none of the “additional elements” including “one or more memory devices having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations,” applying the operating data and the one or more building faults as inputs to a “fault categorization model” that is “trained to generate a remote fix output or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data” and is used to implement the categorizing steps and also used to cause on-site maintenance to be performed, “attempting to repair the fault remotely by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment,” in any combination appear to integrate the abstract idea in a manner that technologically improves any aspect of a device or system that may be used to implement the highlighted step or a device for implementing the highlighted steps such as a signal processing device or a generic computer. Instead, execution of instructions via processor represents high-level program instruction activity for implementing the functions falling within the judicial exception and therefore constitute insignificant extra solution activity that fails to integrate the judicial exception into a practical application. Similarly, applying the operating data and the one or more building faults as inputs to a fault categorization model that is trained to generate a remote fix output or on-site fix output from the one or more building faults and the operating data using training data comprising historical corrective actions taken to resolve corresponding historical building faults and historical operating data and is used to implement the categorizing steps and also used to cause on-site maintenance to be performed represents using program instructions (model) to implement the underlying function falling within the judicial exception and therefore also constitutes extra solution activity that fails to integrate the judicial exception into a practical application. Regarding use of the model for “causing on-site maintenance to be performed…,” Examiner notes that in a broadest reasonable interpretation, the role of the model is analogous to a human actor in terms of formulating a determination of what manner of on-site maintenance activity is to be implemented as part of the causal chain of events that implements performance of the activity. Regarding the training aspect, Examiner notes that the claim does not clearly processing steps as actually including implementation of the training, instead effectively reciting use of a model that has been trained in a particular manner. Furthermore, to the extent the training characterizes the recited processing steps, the manner of training does not appear to have a particularized functional relation to the steps falling within the judicial exception in a manner representing an improvement to a technical field. Instead, the training using historical corrective action data and historical operating data appears to represent merely generating a program construct (model) in an ordinary manner to ultimately implement the steps falling within the judicial exception. A broadest reasonable interpretation in view of Applicant’s specification of attempting to repair the fault remotely by initiating a software or firmware update for the equipment, may entail implementing such “initiating” via an output message/instruction simply indicating a need for a software/firmware update, which represents routine, conventional maintenance activity having no particularized functional relation to the steps falling within the judicial exception and therefore also constitutes extra solution activity that fails to integrate the judicial exception into a practical application.
Regarding application of the judicial exception with, or by use of, a particular machine, the additional elements are configured and implemented in a conventional rather than a particularized manner of implementing fault monitoring for equipment such as building equipment.
Regarding a transformation or reduction of a particular article to a different state or thing, claim 1 does not include any such transformation or reduction. Instead, claim 1 as a whole entails receiving input information (operating data which may include fault data for building equipment), applying standard processing techniques (i.e., processor-execution of instructions such as generating and applying a model) to the information to determine building fault information and fault remediation information, and implementing further standard processing techniques that provide a high-level form of response having no particularized functional relation to the steps falling within the judicial exception (e.g., attempting to remotely repair via initiating software/firmware update or causing on-site maintenance in response to determinations that themselves fall within the judicial exception). The additional elements, individually and in any combination, fail to provide a meaningful integration of the abstract idea (determining/identifying faults based on operating data and determining a type of fault remediation based on the operating/fault data) in an application that transforms an article to a different state. Instead, the additional elements represent extra-solution activity that does not integrate the judicial exception into a practical application. In view of the various considerations encompassed by the Step 2A, Prong Two analysis, claim 1 does not include additional elements that integrate the recited abstract idea into a practical application.
Therefore, claim 1 is directed to a judicial exception and requires further analysis under Step 2B.
Regarding Step 2B, and as explained in the Step 2A Prong Two analysis, the additional elements in claim 1 constitute extra-solution activity and therefore do not result in the claim as a whole amounting to significantly more than the judicial exception. Furthermore, at least some of the additional elements appear to be generic and well understood as evidenced by the disclosures of Razak (US 2019/0355240 A1) and Picardi (US 10,845,079 B1), each of which teach substantially similar computer processing functions for processing equipment monitoring data including data modeling to determine faults and corresponding fault resolution recommendations. As set forth in the grounds for rejecting claim 1 under 103 set forth below, Razak teaches “one or more memory devices having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations,” applying the operating data and the one or more building faults as inputs to “a fault categorization model,” and performing remote fault repair and on-site maintenance action based on a categorization of the one or more building faults as remote fix faults or on-site fix faults.
Similarly, Picardi discloses a system implementing processors for implementing data processing functions (FIG. 6 control unit 610, monitoring application server 660, col. 20 lines 44-50, col. 27 line 37 through col. 28 line 5) including modeling that uses machine learning for monitoring and correcting HVAC faults (Abstract; FIG. 1 system 100 including HVAC model 101), and further includes computer processing functionality for implementing automated actions (col. 6 lines 1-5, col. 10 lines 25-27).
The Examiner notes that even if “causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault” is interpreted more narrowly to exclude at least partial implementation by mental processes, this step represents routine, conventional and high-level maintenance activity (e.g., an output by the model indicating a type of maintenance to be performed) having no particularized functional relation to the steps falling within the judicial exception and therefore would constitute extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 1 is therefore not patent eligible under 101.
Independent claims 10 and 19 include substantially the same limitations as claim 1 that constitute a judicial exception and neither includes significant additional elements that integrate the judicial exception into a practical application or result in the claim as a whole amounting to significantly more than the judicial exception.
Claims 10 and 19 are therefore also not patent eligible under 101.
Claims 2-9 depending from claim 1, claims 11-18 depending from claim 10, and claim 20 depending from claim 19 provide additional features/steps which are part of an expanded algorithm that includes the abstract idea of claim 1 (Step 2A, Prong One). None of dependent claims 2-9, 11-18, and 20 recite additional elements that integrate the abstract idea into practical application (Step 2A, Prong Two), and all fail the “significantly more” test under the step 2B for similar reasons as discussed with regards to claim 1.
For example, claim 2, representative also of claims 11 and 20, further recites “generating the fault categorization model based on one or more rules configured to categorize the one or more building faults,” which merely describes the conventional nature of data processing that requires some form of rule(s) framework for determining the manner in which data is modeled to implement the mental processes type judicial exception “categorize the one or more building faults …,” such that this limitation neither integrates the abstract idea into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 3, representative also of claim 12, further characterizes the operations are further comprising “displaying an indication of the one or more building faults and an indication of whether the one or more building faults are categorized as remote fix faults or on-site fix faults,” which constitutes conventional, routine data processing activity (outputting information via display) that neither integrates the abstract idea into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 4, representative also of claim 13, further characterizes the operations as further comprising “responsive to attempting to repair the fault remotely failing, updating the categorization of the fault to an on-site fix fault” which at least partially falls within the mental processes exception because the causal determination of the remote repair having failed as a condition for the categorization update action may be performed via mental processes (e.g., decision to update categorization based on the determined failed remote repair attempt). Updating the fault categorization to on-site fix fault also falls within the mental processes exception because it can be performed via mental processes (e.g., update/change conceptualized category of the fault as requiring on-site remediation).
Claim 5, representative also of claim 14, further recites that “the fault categorization model is a machine learning model, the operations further comprising training the machine learning model using a set of training data indicating historical building faults and historical corrective actions taken to resolve the corresponding historical building faults,” which characterizes routine, convention data processing techniques (program instructions implemented as machine learning in which the machine learning model) in which the program instructions are necessarily configured via conventional processing techniques (machine learning training) for implementing the limitation “categorize the one or more building faults …” that constitutes a judicial exception. Therefore, this limitation represents extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claims 6 and 7, representative also of claims 15 and 16, respectively, characterize the source and nature of the information used for training the model in a manner consistent with conventional machine learning model training in that the information includes correlations between outcomes (successful) and the features relating to the outcomes (corrective actions), such that this limitation constitutes further conventional processing that neither integrates the judicial exception into a practical application nor results in the claims as a whole amounting to significantly more than the judicial exception.
Claims 8 and 9, representative also of claims 17 and 18, respectively, further recite determining that the one or more building faults have been resolved, which falls within the mental processes type abstract idea judicial exception because such determination, including such determination made based on the information recited in claim 9, may be performed via mental processes (e.g., evaluation and judgement). Claim 8 further recites the additional element “display a corrective action taken to resolve the one or more building faults on a user device” in response to the determining step, which represents routine, conventional data processing activity (data output via display) that constitutes extra solution activity that neither integrates the abstract idea into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 10-12, 14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Razak (US 2019/0355240 A1).
As to claim 1, Razak teaches “[a] system (FIG. 4 building management system 400 that per [0073] may integrate system 451 in FIG. 5) comprising:
one or more memory devices having instructions stored thereon (Abstract disclosing instructions stored in memory; FIG. 4 memory 408, [0056]-[0058], FIG. 5 memory 458, [0080]-[0081]) that, when executed by one or more processors, cause the one or more processors to perform operations (Abstract disclosing processor for executing instructions stored in memory; [0056]-[0057], [0080]-[0081]) comprising:
receiving operating data for one or more pieces of building equipment (FIG. 4 FDD Layer 416 configured to receive operating data from building subsystems 428; [0059] and [0069]; FIG. 5 Alarm Analysis Module 460 configured to receive alarm event information from BAS Controller 366 and Building Subsystems 428, [0082] historical security database 492 receives the alarm event information from BMS 400 and/or building subsystems 428; [0086] event data received by alarm analysis module 460 from BMS and/or building subsystems);
determining one or more building faults for the one or more pieces of building equipment based on the operating data ([0069]-[0070] FDD Layer configured to diagnose detected faults based on input information directly and indirectly received from the building subsystems and devices; [0083]-[0084] alarm analysis module 460 determines/predicts conditions that are precursors to false alarm events (the precursor conditions constituting faulty conditions for the security system));
categorizing the one or more building faults as remote fix faults or on-site fix faults ([0090], Table 2 alarm rules associate/categorize building faults in terms of diagnosis and in terms of whether the service provider is an “onsite service” or “remote service” or “Monitoring Center” (also constitutes a form of remote service)) by applying the operating data and the one or more building faults as inputs to a fault categorization model (FIG. 5 depicting model formed by alarm analysis module 460 that includes alarm rules 462, recommendations 464, [0082] and [0086] alarm analysis module 460 (portion of model including alarm rules 462 and recommendations 464 as part of model) determines the alarm rules based on historical security data (i.e., rules formed based on operating data); [0083]-[0084] and [0090] alarm analysis module 460 monitors event data from security subsystems and applies rules for detection of anomalous behavior and/or the precursor conditions and further, per [0086], [0090] and Table 2, implements rules with respect to the event data (operating data and associated anomalous behavior) to determine/select recommended service solutions including “onsite” and/or “remote”), the fault categorization model trained to generate a remote fix output (Application of Table 2 rules indicating “remote service” for a particular event) or on-site fix output (Application of Table 2 rules indicating “onsite service” for a particular event) from the one or more building faults and the operating data ([0088] and [0092] alarm classifier 466 trained in terms of using classification tags (labels); [0087]-[0088] and Tables 1 and 2 alarm classifier 466 classifies the event data into rules) using training data ([0088] alarm event data tagged with classification tags (i.e., labeled for use in training); [0110] learning database provides data for improving classification (i.e., provides data used for training/retraining model)) comprising historical corrective actions taken to resolve corresponding historical building faults ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults; [0082] historical security database 492 stores event data and further stores corresponding results from alarm analysis module 460 and/or classification data associated with the event data that per Tables 2 and 3 and [0093]-[0094] include corrective actions that would have been undertaken) and historical operating data ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults);
responsive to the fault categorization model categorizing a fault of the one or more building faults as a remote fix fault (Application of Table 2 rules indicating “remote service” for a particular event), attempting to repair the fault remotely ([0093] and [0095] rule-based recommendations generated and delivered (generating a recommendation in a particular instance constitutes a portion of attempting to repair a fault that per Table 2 may be for remote repair)) “and
responsive to the fault categorization model categorizing the fault as an on-site fix fault (Application of Table 2 rules indicating “onsite service” for a particular event), the fault categorization model causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault ([0093] and [0095] rules applied to provide/deliver service/maintenance recommendations such as replacing communication wires).”
Razak does not explicitly teach attempting to repair the fault remotely “by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment.”
However, Razak teaches that the recommendations including remote service recommendations be implemented ([0026], [0069], and [0082]) and further teaches that a lack of programming (software/firmware) update for equipment may be the event to be addressed by “remote service” (Table 2, page 11, Rule Name “Camera Not Connecting”, Symptom “Lost connection to camera,” Diagnosis “IP, port or login may have changed onsite and was not updated” and “camera was replaced and not called in for update to programming”).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Rasak’s teaching of lack of programming (software/firmware) update of equipment as an event diagnosis with Razak’s teaching of designating a particular event as warranting remote service and generalized teaching of implementing the remote service, such that in combination the system is configured to attempt to repair the fault remotely “by initiating a software or firmware update for the equipment.”
The motivation would have been to effectuate a recommendation that is determined and provided/delivered responsive to categorizing a fault as a remote fix fault that resolves a problem in the form of a need for a software/firmware update as disclosed by Razak.
As to claim 2, Razak teaches “[t]he system of claim 1, the operations further comprising generating the fault categorization model based on one or more rules configured to categorize the one or more building faults (FIG. 5 model formed by alarm rules 462 and alarm classifier 466 generated and implemented by alarm analysis model 460, that per Table 2 categorizes false alarm precursor conditions in terms of requiring onsite or remote servicing, [0086] rules categorize events in various manners).”
As to claim 3, Razak teaches “[t]he system of claim 1, the operations further comprising displaying an indication of the one or more building faults ([0082] report generator module 494 generates graphical displays associated with BMS 400 and/or building subsystems including security subsystem and per [0082] such information may include false alarm event conditions; [0093]-[0094] remedial recommendation (recommendation related to a precursor event) from Table 3 delivered to a service provider in displayed form) and an indication of whether the one or more building faults are categorized as remote fix faults or on-site fix faults ([0094] displayed recommendation may include request by work order generation 472 that a fault is to be repaired by an onsite technician)”
As to claim 5, Razak teaches “[t]he system of claim 1, wherein the fault categorization model is a machine learning model ([0026] machine learning may be used for classifying events into corresponding rules that per table 2 may include fault categorization including onsite or remote service), the operations further comprising training the machine learning model ([0088] and [0092] alarm classifier 466 trained in terms of using classification tags (labels); [0087]-[0088] and Tables 1 and 2 alarm classifier 466 classifies the event data into rules) using a set of training data ([0088] alarm event data tagged with classification tags (i.e., labeled for use in training); [0110] learning database provides data for improving classification (i.e., provides data used for training/retraining model)) indicating historical building faults ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults) and the historical corrective actions taken to resolve the corresponding historical building faults ([0082] historical security database 492 stores event data and further stores corresponding results from alarm analysis module 460 and/or classification data associated with the event data that per Tables 2 and 3 and [0093]-[0094] include corrective actions that would have been undertaken).”
As to claim 10, Razak teaches “[a] method (method implemented by FIG. 4 building management system 400 that per [0073] may integrate system 451 in FIG. 5) comprising:
receiving, by one or more processors (Abstract disclosing processor for executing instructions stored in memory; [0056]-[0057], [0080]-[0081]), operating data for one or more pieces of building equipment (FIG. 4 FDD Layer 416 configured to receive operating data from building subsystems 428; [0059] and [0069]; FIG. 5 Alarm Analysis Module 460 configured to receive alarm event information from BAS Controller 366, [0082] historical security database 492 receives the alarm event information from BMS 400 and/or building subsystems 428; [0086] event data received by alarm analysis module 460 from BMS and/or building subsystems);
determining, by one or more processors, one or more building faults for the one or more pieces of building equipment based on the operating data ([0069]-[0070] FDD Layer configured to diagnose detected faults based on input information directed and indirectly received from the building subsystems and devices; [0083]-[0084] alarm analysis module 460 determines/predicts conditions that are precursors to false alarm events (the precursor conditions constituting faulty conditions for the security system));
categorizing, by one or more processors, the one or more building faults as remote fix faults or on-site fix faults ([0090], Table 2 alarm rules associate/categorize building faults in terms of diagnosis and in terms of whether the service provider is an “onsite service” or “remote service” or “Monitoring Center” (also constitutes a form of remote service)) by applying the operating data and the one or more building faults as inputs to a fault categorization model (FIG. 5 depicting model formed by alarm analysis module 460 that includes alarm rules 462, recommendations 464, [0082] and [0086] alarm analysis module 460 (portion of model including alarm rules 462 and recommendations 464 as part of model) determines the alarms rules based on historical security data (i.e., rules formed based on operating data); [0083]-[0084] and [0090] alarm analysis module 460 monitors event data from security subsystems and applies rules for detection of anomalous behavior and/or the precursor conditions and further, per [0086], [0090] and Table 2, implements rules with respect to the event data (operating data and anomalous behavior) to determine/select recommended service solutions including “onsite” and/or “remote”), the fault categorization model trained to generate a remote fix output (Application of Table 2 rules indicating “remote service” for a particular event) or on-site fix output (Application of Table 2 rules indicating “onsite service” for a particular event) from the one or more building faults and the operating data ([0088] and [0092] alarm classifier 466 trained in terms of using classification tags (labels); [0087]-[0088] and Tables 1 and 2 alarm classifier 466 classifies the event data into rules) using training data ([0088] alarm event data tagged with classification tags (i.e., labeled for use in training); [0110] learning database provides data for improving classification (i.e., provides data used for training/retraining model)) comprising historical corrective actions taken to resolve corresponding historical building faults ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults; [0082] historical security database 492 stores event data and further stores corresponding results from alarm analysis module 460 and/or classification data associated with the event data that per Tables 2 and 3 and [0093]-[0094] include corrective actions that would have been undertaken) and historical operating data ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults);
responsive to the fault categorization model categorizing a fault of the one or more building faults as a remote fix fault (Application of Table 2 rules indicating “remote service” for a particular event), attempting, by the one or more processors, to repair the fault remotely ([0093] and [0095] rule-based recommendations generated and delivered (generating a recommendation in a particular instance constitutes a portion of attempting to repair a fault that per Table 2 may be for remote repair))” “and
responsive to the fault categorization model categorizing the fault as an on-site fix fault (Application of Table 2 rules indicating “onsite service” for a particular event), the fault categorization model causing, by the one or more processors, on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault ([0093] and [0095] rules applied to provide/deliver service/maintenance recommendations such as replacing communication wires).
Razak does not explicitly teach attempting to repair the fault remotely “by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment.”
However, Razak teaches that the recommendations including remote service recommendations be implemented ([0026], [0069], and [0082]) and further teaches that a lack of programming (software/firmware) update for equipment may be the event to be addressed by “remote service” (Table 2, page 11, Rule Name “Camera Not Connecting”, Symptom “Lost connection to camera,” Diagnosis “IP, port or login may have changed onsite and was not updated” and “camera was replaced and not called in for update to programming”).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Rasak’s teaching of lack of programming (software/firmware) update of equipment as an event diagnosis with Razak’s teaching of designating a particular event as warranting remote service and generalized teaching of implementing the remote service, such that in combination the system is configured to attempt to repair the fault remotely “by initiating a software or firmware update for the equipment.”
The motivation would have been to effectuate a recommendation that is determined and provided/delivered responsive to categorizing a fault as a remote fix fault that resolves a problem in the form of a need for a software/firmware update as disclosed by Razak.
As to claim 11, Razak teaches “[t]he method of claim 10, further comprising generating the fault categorization model based on one or more rules configured to categorize the one or more building faults (FIG. 5 model formed by alarm rules 462 and alarm classifier 466 generated and implemented by alarm analysis model 460, that per Table 2 categorizes false alarm precursor conditions in terms of requiring onsite or remote servicing, [0086] rules categorize events in various manners).”
As to claim 12, Razak teaches “[t]he method of claim 10, further comprising displaying an indication of the one or more building faults ([0082] report generator module 494 generates graphical displays associated with BMS 400 and/or building subsystems including security subsystem and per [0082] such information may include false alarm event conditions; [0093]-[0094] remedial recommendation (recommendation related to a precursor event) from Table 3 delivered to a service provider in displayed form) and an indication of whether the one or more building faults are categorized as remote fix faults or on-site fix faults ([0094] displayed recommendation may include request by work order generation 472 that a fault is to be repaired by an onsite technician).”
As to claim 14, Razak teaches “[t]he method of claim 10, wherein the fault categorization model is a machine learning model ([0026] machine learning may be used for classifying events into corresponding rules that per table 2 may include fault categorization including onsite or remote service), the method further comprising training the machine learning model ([0088] and [0092] alarm classifier 466 trained in terms of using classification tags (labels); [0087]-[0088] and Tables 1 and 2 alarm classifier 466 classifies the event data into rules) using a set of training data ([0088] alarm event data tagged with classification tags (i.e., labeled for use in training; [0110] learning database provides data for improving classification (i.e., provides data used for training/retraining model)) indicating historical building faults ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults) and the historical corrective actions taken to resolve the corresponding historical building faults ([0082] historical security database 492 stores event data and further stores corresponding results from alarm analysis module 460 and/or classification data associated with the event data that per Tables 2 and 3 and [0093]-[0094] include corrective actions that would have been undertaken).”
As to claim 19, Razak teaches “[a] non-transitory computer-readable media comprising computer-readable instructions stored thereon (Abstract disclosing instructions stored in memory; FIG. 4 memory 408, [0056]-[0058], FIG. 5 memory 458, [0080]-[0081]) that when executed by a processor cause the processor to perform operations (Abstract disclosing processor for executing instructions stored in memory; [0056]-[0057], [0080]-[0081]) comprising:
receiving operating data for one or more pieces of building equipment (FIG. 4 FDD Layer 416 configured to receive operating data from building subsystems 428; [0059] and [0069]; FIG. 5 Alarm Analysis Module 460 configured to receive alarm event information from BAS Controller 366, [0082] historical security database 492 receives the alarm event information from BMS 400 and/or building subsystems 428; [0086] event data received by alarm analysis module 460 from BMS and/or building subsystems);
determining one or more building faults for the one or more pieces of building equipment based on the operating data ([0069]-[0070] FDD Layer configured to diagnose detected faults based on input information directed and indirectly received from the building subsystems and devices; [0083]-[0084] alarm analysis module 460 determines/predicts conditions that are precursors to false alarm events (the precursor conditions constituting faulty conditions for the security system));
categorizing the one or more building faults as remote fix faults or on-site fix faults ([0090], Table 2 alarm rules associate/categorize building faults in terms of diagnosis and in terms of whether the service provider is an “onsite service” or “remote service” or “Monitoring Center” (also constitutes a form of remote service)) by applying the operating data and the one or more building faults as inputs to a fault categorization model (FIG. 5 depicting model formed by alarm analysis module 460 that includes alarm rules 462, recommendations 464, [0082] and [0086] alarm analysis module 460 (portion of model including alarm rules 462 and recommendations 464 as part of model) determines the alarms rules based on historical security data (i.e., rules formed based on operating data); [0083]-[0084] and [0090] alarm analysis module 460 monitors event data from security subsystems and applies rules for detection of anomalous behavior and/or the precursor conditions and further, per [0086], [0090] and Table 2, implements rules with respect to the event data (operating data and anomalous behavior) to determine/select recommended service solutions including “onsite” and/or “remote”), the fault categorization model trained to generate a remote fix output (Application of Table 2 rules indicating “remote service” for a particular event) or on-site fix output (Application of Table 2 rules indicating “onsite service” for a particular event) from the one or more building faults and the operating data ([0088] and [0092] alarm classifier 466 trained in terms of using classification tags (labels); [0087]-[0088] and Tables 1 and 2 alarm classifier 466 classifies the event data into rules) using training data ([0088] alarm event data tagged with classification tags (i.e., labeled for use in training); [0110] learning database provides data for improving classification (i.e., provides data used for training/retraining model)) comprising historical corrective actions taken to resolve corresponding historical building faults ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults; [0082] historical security database 492 stores event data and further stores corresponding results from alarm analysis module 460 and/or classification data associated with the event data that per Tables 2 and 3 and [0093]-[0094] include corrective actions that would have been undertaken) and historical operating data ([0110] learning database may include historical security database 492 that per [0078] stores security system data including events that associated with faults);
responsive to the fault categorization model categorizing a fault of the one or more building faults as a remote fix fault (Application of Table 2 rules indicating “remote service” for a particular event), attempting to repair the fault remotely ([0093] and [0095] rule-based recommendations generated and delivered (generating a recommendation in a particular instance constitutes a portion of attempting to repair a fault that per Table 2 may be for remote repair))” “and
responsive to the fault categorization model categorizing the fault as an on-site fix fault (Application of Table 2 rules indicating “onsite service” for a particular event), the fault categorization model causing on-site maintenance to be performed on the equipment of the one or more pieces of building equipment affected by the on-site fix fault ([0093] and [0095] rules applied to provide/deliver service/maintenance recommendations such as replacing communication wires).”
Razak does not explicitly teach attempting to repair the fault remotely “by transmitting control signals or commands causing a change in operation of equipment of the one or more pieces of building equipment affected by the remote fix fault or initiating a software or firmware update for the equipment.”
However, Razak teaches that the recommendations including remote service recommendations be implemented ([0026], [0069], and [0082]) and further teaches that a lack of programming (software/firmware) update for equipment may be the event to be addressed by “remote service” (Table 2, page 11, Rule Name “Camera Not Connecting”, Symptom “Lost connection to camera,” Diagnosis “IP, port or login may have changed onsite and was not updated” and “camera was replaced and not called in for update to programming”).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Rasak’s teaching of lack of programming (software/firmware) update of equipment as an event diagnosis with Razak’s teaching of designating a particular event as warranting remote service and generalized teaching of implementing the remote service, such that in combination the system is configured to attempt to repair the fault remotely “by initiating a software or firmware update for the equipment.”
The motivation would have been to effectuate a recommendation that is determined and provided/delivered responsive to categorizing a fault as a remote fix fault that resolves a problem in the form of a need for a software/firmware update as disclosed by Razak.
As to claim 20, Razak teaches “[t]he non-transitory computer-readable media of claim 19, the operations further comprising generating the fault categorization model based on one or more rules configured to categorize the one or more building faults (FIG. 5 model formed by alarm rules 462 and alarm classifier 466 generated and implemented by alarm analysis model 460, that per Table 2 categorizes false alarm precursor conditions in terms of requiring onsite or remote servicing, [0086] rules categorize events in various manners).”
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Razak in view of Yang (US 2017/0205791 A1).
As to claim 4, Razak teaches “[t]he system of claim 1,” but does not appear to teach the manner of handling fault remediation when one remediation method fails and therefore does not expressly teach “responsive to attempting to repair the fault remotely failing, updating the categorization of the fault to an on-site fix fault.”
Yang discloses a system/method for remediating equipment faults in part by classifying detected faults as remote or local (FIG. 13 depicting classifications of repair methods corresponding to failures as “manual” or “remote”; FIG. 19, [0313]) and in which responsive to attempting to repair the fault remotely failing, the categorization of the fault is effectively updated to an on-site fix fault (FIG. 20 seps S831, S833, and S385; [0317]-[0318] if attempted remote repair fails, the repair is switched to a “manual” repair such as by providing repair manual instructions (per [0313] such service manual repair is implemented via self-repair by user (local, onsite) repair; [0320]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Yang’s teaching of recategorizing a fault by virtue of the recategorization of the corresponding remote repair to an on-site fix fault based on a failed remote repair attempt to the system taught by Razak in which faults are categorized in terms of “on-site” or “remote” such that in combination the system is configured for implementing responsive to attempting to repair the fault remotely failing, updating the categorization of the fault to an on-site fix fault.
The motivation would have been to provide a backup remediation technique associated with the fault in order to address a fault for which remote remediation has failed as disclosed by Yang.
As to claim 13, Razak teaches “[t]he method of claim 10,” but does not appear to teach the manner of handling fault remediation when one remediation method fails and therefore does not expressly teach “responsive to attempting to repair the fault remotely failing, updating the categorization of the fault to an on- site fix fault.”
Yang discloses a system/method for remediating equipment faults in part by classifying detected faults as remote or local (FIG. 13 depicting classifications of repair methods corresponding to failures as “manual” or “remote”; FIG. 19, [0313]) and in which responsive to attempting to repair the fault remotely failing, the categorization of the fault is effectively updated to an on-site fix fault (FIG. 20 seps S831, S833, and S385; [0317]-[0318] if attempted remote repair fails, the repair is switched to a “manual” repair such as by providing repair manual instructions (per [0313] such service manual repair is implemented via self-repair by user (local, onsite) repair; [0320]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Yang’s teaching of recategorizing a fault by virtue of the recategorization of the corresponding remote repair to an on-site fix fault based on a failed remote repair attempt to the method taught by Razak in which faults are categorized in terms of “on-site” or “remote” such that in combination the method includes implementing responsive to attempting to repair the fault remotely failing, updating the categorization of the fault to an on-site fix fault.
The motivation would have been to provide a backup remediation technique associated with the fault in order to address a fault for which remote remediation has failed as disclosed by Yang.
Claims 6-7 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Razak in view of Picardi (US 10,845,079 B1).
As to claim 6, Razak teaches “[t]he system of claim 5, wherein the training data comprises feedback from a user ([0087] and [0089] domain expert inputs alarm rules 462; [0092] domain expert defines recommendations that are involved in training), but does not appear to expressly teach that the training data feedback from a user indicates “the historical corrective actions, and whether the historical corrective actions were successful in resolving the corresponding historical building faults.”
Picardi discloses a system/method that uses machine learning for monitoring and correcting HVAC faults (Abstract; FIG. 1 system 100 including HVAC model 101) in which training data comprises feedback from a user and is provided as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults (col. 3 lines 4-8, HVAC model trained using past errors and past actions that corrected the errors; col. 18 lines 60 through col. 19 line 11 the past action data is technician activity that constitutes feedback from a user (feedback information obtained based on (from) and indicating user activity); col. 18 lines 11-25).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Picardi’s teaching of providing training data as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults to the system taught by Razak in which user feedback is an available channel for receiving training data, such that in combination the system is configured to use training data that comprises feedback from a user indicating the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.
The motivation would have been to leverage past correlations between corrective actions performed and results to improve accuracy of machine learning output that may indicate a recommended corrective action as disclosed by Picardi.
As to claim 7, Razak teaches “[t]he system of claim 5, wherein the training data comprises an updated operating data (per [0110] learning database may be historical database 492 that that per [0082] receives (is updated with) historical operating data), but does not appear to expressly teach that the updated operating data type training data indicates “the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.”
Picardi discloses a system/method that uses machine learning for monitoring for and correcting HVAC faults (Abstract; FIG. 1 system 100 including HVAC model 101) in which training data is provided as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults (col. 3 lines 4-8, HVAC model trained using past errors and past actions that corrected the errors; col. 18 lines 11-25).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Picardi’s teaching of providing training data as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults to the system taught by Razak in which updated operating data is included as training data, such that in combination the system is configured to use training data that comprises updated operating data indicating the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.
The motivation would have been to leverage past correlations between corrective actions performed and results to improve accuracy of machine learning output that may indicate a recommended corrective action as disclosed by Picardi.
As to claim 15, Razak teaches “[t]he method of claim 14, wherein the training data comprises feedback from a user ([0087] and [0089] domain expert inputs alarm rules 462; [0092] domain expert defines recommendations that are involved in training), but does not appear to expressly teach that the training data feedback from a user indicates “the historical corrective actions, and whether the historical corrective actions were successful in resolving the corresponding historical building faults.”
Picardi discloses a system/method that uses machine learning for monitoring and correcting HVAC faults (Abstract; FIG. 1 system 100 including HVAC model 101) in which training data comprises feedback from a user and is provided as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults (col. 3 lines 4-8, HVAC model trained using past errors and past actions that corrected the errors; col. 18 lines 60 through col. 19 line 11 the past action data is technician activity that constitutes feedback from a user (feedback information obtained based on (from) and indicating user activity); col. 18 lines 11-25).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Picardi’s teaching of providing training data as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults to the method taught by Razak in which user feedback is an available channel for receiving training data, such that in combination the system is configured to use training data that comprises feedback from a user indicating the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.
The motivation would have been to leverage past correlations between corrective actions performed and results to improve accuracy of machine learning output that may indicate a recommended corrective action as disclosed by Picardi.
As to claim 16, Razak teaches “[t]he method of claim 14, wherein the training data comprises an updated operating data (per [0110] learning database may be historical database 492 that that per [0082] receives (is updated with) historical operating data) but does not appear to expressly teach that the updated operating data type training data indicates “the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.”
Picardi discloses a system/method that uses machine learning for monitoring for and correcting HVAC faults (Abstract; FIG. 1 system 100 including HVAC model 101) in which training data is provided as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults (col. 3 lines 4-8, HVAC model trained using past errors and past actions that corrected the errors; col. 18 lines 11-25).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Picardi’s teaching of providing training data as historical feedback data including historical corrective actions and whether historic corrective actions were successful in resolving corresponding historical faults to the method taught by Razak in which updated operating data is included as training data, such that in combination the system is configured to use training data that comprises updated operating data indicating the historical corrective actions and whether the historical corrective actions were successful in resolving the corresponding historical building faults.
The motivation would have been to leverage past correlations between corrective actions performed and results to improve accuracy of machine learning output that may indicate a recommended corrective action as disclosed by Picardi.
Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Razak in view of Chaturvedi (US 2020/0327425 A1).
As to claim 8, Razak teaches “[t]he system of claim 1,” but does not appear to teach “the operations further comprising:
determining that the one or more building faults have been resolved; and
in response to determining that the one or more building faults have been resolved, display a corrective action taken to resolve the one or more building faults on a user device.”
Chaturvedi discloses a system/method for monitoring and resolving fault conditions (conditions warranting repair) for monitored assets (Abstract; FIGS. 4-5) and that is configured to determine that one or more fault conditions have been resolved (FIG. 6 block 606, [0106]; [0005], [0074] repair information includes indication of whether condition of the monitored asset has been resolved (inclusion of whether condition resolved in the repair information inherently requires antecedent determination of whether condition resolved) and in response to determining that the one or more faults have been resolved, display a corrective action taken to resolve the one or more faults ([0074] suggested repair information provided to a user may include a past repair performed on monitored asset and whether the repair successfully resolved the condition (whether or not the repair successfully resolved the condition is the impetus for providing the repair information to the user, such that the repair information including the repair itself is provided to the user “in response to determining that the one or more faults have been resolved”); [0075] request to user to implement repair that has been determined to be successful; [0135]) on a user device ([0059] and [0097] information regarding past performance of monitored asset and past repairs received by user via a user application 210 that displays the information).”
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Chaturvedi’s teaching of determining that one or more fault conditions have been resolved and in response to determining that the one or more faults have been resolved, display a corrective action taken to resolve the one or more faults on a user device to the system taught by Razak, such that in combination the system implements these functions with respect to building faults and therefore implements “determining that the one or more building faults have been resolved; and in response to determining that the one or more building faults have been resolved, display a corrective action taken to resolve the one or more building faults on a user device.”
The motivation would have been to provide a user with repair action information that inferentially indicates a likelihood of success to optimize the user’s selection of a repair option as disclosed by Chaturvedi.
As to claim 9, the combination of Razak and Chaturvedi teaches “[t]he system of claim 8,” and Chaturvedi further teaches wherein the determining that the one or more faults have been resolved is based on at least one of a user feedback ([0073] “repair information” includes information associated with repair (would entail information relating to whether repair successful) and is provided via user application of user device; [0097] user interface may be used for entering service information that may include repair and diagnostic information) and updated operating data for the monitored asset ([0074] data tagging unit determined whether condition of monitored asset has been corrected based on prognosis information (information indicating expected operation) for the monitored asset).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Chaturvedi’s teaching of determining fault resolution based on at least one of user feedback and updated operating data to the system taught by Razak as modified by Chaturvedi, such that in combination the system is configured to determine that the one or more building faults have been resolved based on at least one of a user feedback and the updated operating data for the one or more pieces of building equipment.
The motivation would have been to provide information sources for determining fault resolution that are contextually able to provide the necessary information by which fault resolution may be determined as disclosed by Chaturvedi.
As to claim 17, Razak teaches “[t]he method of claim 10,” but does not appear to teach “wherein the method further comprises:
determining, by the one or more processors, a fault resolution for the one or more building faults; and
displaying, by the one or more processors, the fault resolution on a user device.”
Chaturvedi discloses a system/method for monitoring and resolving fault conditions (conditions warranting repair) for monitored assets (Abstract; FIGS. 4-5) and that is configured to determine that one or more fault conditions have been resolved (FIG. 6 block 606, [0106]; [0005], [0074] repair information includes indication of whether condition of the monitored asset has been resolved (inclusion of whether condition resolved in the repair information inherently requires antecedent determination of whether condition resolved) and display a corrective action taken to resolve the one or more faults ([0074] suggested repair information provided to a user may include a past repair performed on monitored asset and whether the repair successfully resolved the condition (whether or not the repair successfully resolved the condition is the impetus for providing the repair information to the user, such that the repair information including the repair itself is provided to the user “in response to determining that the one or more faults have been resolved”); [0075] request to user to implement repair that has been determined to be successful; [0135]) on a user device ([0059] and [0097] information regarding past performance of monitored asset and past repairs received by user via a user application 210 that displays the information).”
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Chaturvedi’s teaching of determining that one or more fault conditions have been resolved and displaying a corrective action taken to resolve the one or more faults on a user device to the method taught by Razak, such that in combination the method implements these functions with respect to building faults and therefore implements “determining, by the one or more processors, a fault resolution for the one or more building faults; and displaying, by the one or more processors, the fault resolution on a user device.”
The motivation would have been to provide a user with repair action information that inferentially indicates a likelihood of success to optimize the user’s selection of a repair option as disclosed by Chaturvedi.
As to claim 18, the combination of Razak and Chaturvedi teaches “[t]he method of claim 17,” and Chaturvedi further teaches wherein the determining that the one or more faults has been resolved is based on at least one of a user feedback ([0073] “repair information” includes information associated with repair (would entail information relating to whether repair successful) and is provided via user application of user device; [0097] user interface may be used for entering service information that may include repair and diagnostic information) and operating data for the monitored asset ([0074] data tagging unit determined whether condition of monitored asset has been corrected based on prognosis information (information indicating expected operation) for the monitored asset).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Chaturvedi’s teach of determining fault resolution based on at least one of user feedback and operating data to the method taught by Razak as modified by Chaturvedi, such that in combination the method is configured to determine that the one or more building faults have been resolved based on at least one of a user feedback and the updated operating data for the one or more pieces of building equipment.
The motivation would have been to provide information sources for determining fault resolution that are contextually able to provide the necessary information by which fault resolution may be determined as disclosed by Chaturvedi.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW W BACA whose telephone number is (571)272-2507. The examiner can normally be reached Monday - Friday 8:00 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Andrew Schechter can be reached at (571) 272-2302. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW W. BACA/Examiner, Art Unit 2857
/ANDREW SCHECHTER/Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights