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 .
Response to Amendment
This office action is in response to the amendment filed on 05/29/2026. Claims remain pending in the application. Claims 1, 9, and 17 are independent.
Specification
Applicant's amendment to specification corrects previous objections; therefore, the previous objections are withdrawn.
Claim Objections
Applicant's amendment to claims corrects previous objections; therefore, the previous objections are withdrawn. Also, according to Pages 9-10 of the Remarks regarding 112 Rejections to Claims 5, 7, 13, and 15, previous 112 Rejections to Claims 5, 7, 13, and 15 are changed to Claim Objections instead.
Claims 5, 7, 13, and 15 are objected to because of the following informalities:
in Claim 5, lines 8-9 and Claim 13, lines 9-10, "… reduced error of the second AI model from the available label information" appears to be"… reduced error of the second AI model from the available label data" according to Page 10 of Remarks that "the available label data" and "the available label information" refer to the same data;
in Claim 7, lines 3-4 and Claim 15, lines 3-4, "… wherein the reward model is configured to generate a reward for …" appears to be "wherein the reward model is configured to generate the reward for …" according to Page 10 of Remarks that this reward generated by the reward model is the same reward referenced in base claims 1 and 9, which recite fine-tuning "to maximize reward".
Appropriate correction is required.
Claim Rejections - 35 USC § 112
Applicant's amendment to claims and Clarification in the Remarks corrects some of previous rejections; therefore, some of the previous rejections are withdrawn. Also, according to Pages 9-10 of the Remarks regarding 112 Rejections to Claims 5 and 13, previous 112 Rejections to Claims 5 and 13 are changed to Claim Objections instead. Therefore, the remaining rejections are shown below.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7 and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 7 and 15 recite the limitation "… wherein error for the reward model is determined from a difference between the model predictions and the actual repairs …" in lines 1-3, which rendering these claims indefinite because (a) "… fine-tuning the second AI model … to maximize reward and minimize error" is recited in their based Claims 1 and 9 respectively; (b) "… collecting model predictions of the second Al model and actual repairs conducted during the period of time …" is recited in their based Claims 6 and 14 respectively; and (c) "error" for "the reward model" is different to "error" for "the second model" according Page 10 of Remarks, and hence how can "error for the reward model" is determined from a "difference" between "the model predictions of the second Al model" and "the actual repairs" which is commonly known as "error" for "the second model" when "error" for "the reward model" is different and unrelated to "error" for "the second model" (i.e., it is contradict to common technical knowledge at the time of filing the present application that the "error" of a "model" (e.g., "error" for a "reward model") must be determined from "differences" between "outputs/predictions" of the model (e.g., generated/predicted "rewards" of the "reward model") and "actual results" (e.g., actual "rewards")). In other words, in order for the limitation "error for the reward model is determined from a difference between the model predictions and the actual repairs" to be understood by skilled person in the art, how "error for the reward model" is related to "error for the second Al model" must be recited in the claim. Clarification is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-6, 8-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vah et al. (US 2021/0263792 A1, pub. date: 04/26/2021), hereinafter Vah in view of Malladi et al. (US 2024/0393750 A1, priority date: 05/26/2023), hereinafter Malladi and Chen et al. ("Domain Adversarial Transfer Network for Cross-Domain Fault Diagnosis of Rotary Machinery", IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 69, NO. 11, NOVEMBER 2020, pp. 8702-8712), hereinafter Chen'2020.
Independent Claims 1, 9, and 17
Vah discloses a method, comprising: training a first (Vah, ¶ [0034] with 114 in FIG. 1: the machine learning-based troubleshooting system 112 is configured to obtain information regarding a given asset to be repaired; using this information, the troubleshooting action recommendation module 114 generates a recommended troubleshooting action to be performed on the given asset; to do so, the troubleshooting action recommendation module 114 may utilize a first machine learning model (e.g., a sequence-to-sequence model where the information regarding the given asset to be repaired is passed as input to an encoder of the sequence-to-sequence model, and the recommended troubleshooting action is received as output from a decoder of the sequence-to-sequence model); ¶¶ [0049]-[0050], [0054]-[0055], and [0057]-[0058] with 200 and 202 in FIG. 2: process begins with step 200, obtaining information regarding a given asset to be repaired, wherein the information regarding the given asset to be repaired may comprise one or more symptom sets, a given one of the one or more symptom sets comprising an identifier of the given asset, a description of the given asset, a description of at least one error encountered on the given asset, and result information regarding the success or failure of one or more troubleshooting actions previously performed on the given asset; in step 202, a recommended troubleshooting action to be performed on the given asset is generated; a "first" machine learning model may be used to obtain a recommended troubleshooting action; step 202 utilizes the first machine learning model, where the obtained information regarding the given asset is provided as input to an encoder of the first machine learning model and the recommended troubleshooting action is received from a decoder of the first machine learning model; utilize machine learning to predict troubleshooting actions (e.g., diagnostic actions, repair actions, etc.) for a particular asset (e.g., a computing device such as a laptop), where the machine learning model bases predictions on correct repair decisions (e.g., where a part of the laptop or other computing device is replaced by a technician and later found to be defective in screening, or categorized as verified fault found (VFF)); the troubleshooting recommendation system utilizes a first machine learning model to generate troubleshooting action recommendations; the first machine learning model may predict troubleshooting actions using a sequence-to-sequence model that treats the troubleshooting process as a conversation, and thus may be referred to as a conversational machine learning model herein; such a conversational machine learning model is configured to preserve the context of all the steps involved in a troubleshooting scenario, and suggests the next steps (e.g., diagnostic actions, repair actions) like a human technician would; ¶ [0062] with FIG. 3A: the user in step 302 requests a troubleshooting recommendation for a particular asset (e.g., a computing device such as a laptop); a first machine learning model in step 303 generates a recommended troubleshooting action; the first machine learning model is a conversational machine learning model that treats the steps of a troubleshooting process as a conversation; however, various other types of machine learning models may be utilized to generate the recommended troubleshooting action; the workflow branches into path 2 in step 304 if the recommended troubleshooting action is a repair action or into path 3 in step 305 if the recommended troubleshooting action is a diagnostic action; ¶ [0071]: the first machine learning model provides high-level functions of generating recommended troubleshooting actions (e.g., repair actions, diagnostic actions, etc.); ¶¶ [0072]-[0077] with FIG. 4: a sequence-to-sequence model 400 suitable for use as the first machine learning model to generate recommended troubleshooting actions; the model 400 can work with both character-level inputs and word-level inputs (e.g., by using word embedding); the model 400 includes an embedding layer 401, an encoder 402, a context or state vector 403, a decoder 404, and an output layer 405, wherein each of the encoder 402 and decoder 404 may be implemented as a RNN, including a particular type of RNN such as a LSTM RNN, a Gated Recurrent Unit (GRU) RNN, etc.; symptom tiers, conditions, product platform and other information are fed into the encoder 402 (e.g., as inputs 1 through N) via the embedding layer 401; for the first machine learning model, the encoder 402 outputs a state (e.g., state N) as the context or state vector 403, which provides the input to decoder 404. The decoder 404 predicts repair actions (e.g., as outputs 1 through M) via output layer 405, which may be implemented as a softmax output layer; based at least in part on the outcome of each step in the repair process (e.g., 0 or 1 indicating failure or success, respectively), a decision is made as to whether the input "words" provided to the encoder 402 should be modified for the next step or iteration of the sequence-to-sequence model 400; for new input, the decoder output of the last step (e.g., output M) is added to the last input (e.g., input N); this process is repeated until there is a successful repair, or until the repair process is stopped (e.g., after some designated threshold number of iterations of running the model 400, manual stop by a technician, etc.); if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; adding the negation includes adding "not" to each output of the decoder 404; this indicates that the output of the previous step was a failure (e.g., replacing the output "replace commodity motherboard" of the decoder 404 with "replace_not commodity_not motherboard_not"); the sequence-to-sequence model 400 may be trained using character-level or word-level input; the model 400 may be trained on a dataset including troubleshooting log entries, historical troubleshooting logs suitably transformed into a format fit for a sequence-to-sequence model, external sources (e.g., discussions on technical communities or support forums suitably transformed into a format fit for a sequence-to-sequence model), and for unsuccessful repair and diagnostic tests, a negation (e.g., the word "_not") is added to the troubleshooting actions; ¶ [0092] with FIG. 8: the asset information repository 805 may include a database (e.g., a structured query language (SQL) database) with information ( e.g., service tag history, symptoms, latest diagnostics, etc.) for the incoming asset and assets similar to the incoming asset ( e.g., other models of a computing system with the same or similar hardware and software components); information from the asset information repository 805 is passed to a first machine learning model 807 for model training);
training a second Al model for a specific domain from the first (Vah, ¶¶ [0035]-[0036] with 116 in FIG. 1: the troubleshooting action pre-screening module 116 is configured to utilize a second machine learning model to predict the success of the recommended troubleshooting action generated by the troubleshooting action recommendation module 114; to do so, the troubleshooting action pre-screening module 116 provides the recommended troubleshooting action and the obtained information from the output of the troubleshooting action recommendation module 114 regarding the given asset as input to an encoder of the second machine learning model, and receives from a decoder of the second machine learning model a predicted success of the recommended troubleshooting action; the second machine learning model, similar to the first machine learning model, may comprise a sequence-to-sequence model; the second machine learning model, however, implements an attention mechanism that causes the decoder to focus on particular portions of the input to the encoder; the troubleshooting action pre-screening module 116 is further configured to determine whether the predicted success of the recommended troubleshooting action meets one or more designated criteria; ¶¶ [0050], [0054], [0057]-[0061], and [0068] with 204-208 in FIG. 2: the recommended troubleshooting action and the obtained information regarding the given asset are provided as input to an encoder of a machine learning model in step 204; in step 206, a predicted success of the recommended troubleshooting action is received from a decoder of the machine learning model; the machine learning model utilized in steps 204 and 206 is assumed to implement an attention mechanism that is configured to focus the decoder on one or more portions of the input to the encoder; the machine learning model utilized in steps 204 and 206 may comprise a sequence-to-sequence machine learning model that utilizes a recurrent neural network (RNN) architecture such as a long short-term memory (LSTM) model architecture; multiple machine learning models are utilized; steps 204 and 206 utilizing a "second" machine learning model; extend or complement a troubleshooting recommendation system with a machine learning model that factors both correct and incorrect troubleshooting decisions into troubleshooting recommendations produced by the troubleshooting recommendation system; the troubleshooting recommendation system is extended with a second machine learning model that factors in both correct and incorrect troubleshooting decisions into the troubleshooting action recommendations from the first machine learning model; the second machine learning model may be configured to consider various rules or policies (e.g., a rule or policy may be based on characteristics of the given asset that is being troubleshooted, wherein (a) such characteristics may include a type of the given asset (e.g., a product platform of the given asset), a priority of the given asset, an age of the given asset or components thereof, whether the given asset has been to the enterprise repair center recently (e.g., whether the given asset is categorized as repeat repair), etc., and (b) such characteristics may affect whether certain types of diagnostic or repair actions should or should not be performed), and to present warnings or other notifications to technicians performing troubleshooting as desired; the second machine learning model utilizes a RNN architecture such as a LSTM-based sequence-to-sequence model with an attention mechanism; the second machine learning model factors in KPIs (e.g., whether replaced parts are good/NFF or bad/VFF, whether diagnostic actions are effective or ineffective, etc.) into a sequence-to-sequence based model to avoid the prediction of undesirable troubleshooting actions (e.g., repair solutions resulting in replaced parts that are good/NFF, diagnostics solutions that are ineffective, etc.); the first machine learning model is thus complemented with the second machine learning model, which may comprise a sequence-to-sequence model with an attention mechanism; advantageously, the second machine learning model overcomes the limitations of the first machine learning model by considering all troubleshooting outcomes before making a troubleshooting action recommendation; the inclusion of the second machine learning model provides a pre-screening of the troubleshooting action recommendation before the troubleshooting action recommendation is provided to a technician; the pre-screening process may result in two decisions: (a) whether or not the recommended troubleshooting action provided by the first machine learning model satisfies some designated threshold prediction of success ( e.g., determined based at least in part utilizing a confidence score for the recommended troubleshooting action); and (b) whether or not the recommended troubleshooting action provided by the first machine learning model satisfies desirable outcomes based at least in part on KPIs (e.g., VFF/NFF, cumbersome/lean, complex/trivial, repair yield, RDR, etc.); if the pre-screening outcome meets both of these conditions, the recommended troubleshooting action is unchanged and is presented to the technician; ¶ [0063] with FIG. 3B: when the recommended troubleshooting action is a repair action and the system flow proceeds to path 2 in step 304, the second machine learning model is utilized to predict a confidence score for the recommended repair action in step 306; ¶ [0065] with FIG. 3C: when the recommended troubleshooting action is a diagnostic action and the system flow proceeds to path 3 in step 305, the second machine learning model is utilized to predict a confidence score for the recommended diagnostic action in step 311; ¶ [0071]: the second machine learning model takes as input information of the given asset being troubleshooted (e.g., asset description such as product platform, symptoms and error descriptions, the recommended troubleshooting action generated by the first machine learning model) and generates an output indicating whether the outcome of the recommended troubleshooting action is desirable or not as per various KPI, wherein the KPIs may include whether a repair action is likely to result in VFF or NFF, whether a diagnostic action is likely to be effective or ineffective, whether a repair or diagnostic action is complex (e.g., time-consuming, requiring special training or knowledge) or trivial, etc.; ¶¶ [0078]-[0083] with FIG. 5: a sequence-to-sequence model 500 suitable for use as the second machine learning model for pre-screening recommended troubleshooting actions (e.g., generated using the first machine learning model); the model 500 including an embedding layer 501, encoder 502, context vector 503, decoder 504, and output layer 505; the model 500, however, incorporates an attention mechanism represented by elements 506 and 507, wherein the attention mechanism enables the decoder 504 to focus on important input (e.g., highlighted input 1 506) rather than just the context vector 503; the attention mechanism helps the second machine learning model to focus on specific parts of the input to predict suitable KPI values; attention is a mechanism that forces the model 500 to focus on specific parts of the input (e.g., 506) when decoding, instead of relying only on the context vector 503; by incorporating an attention mechanism, the sequence-to-sequence model 500 is able to utilize all of the states 1 through N (e.g., states 1, 2, ... N-1 are not discarded) in order to construct the context vector 503 required by the decoder 504 to generate the output sequence; while predicting the output for a long input sequence, the decoder 504 needs to focus on a few important keywords for each output and not the whole sequence; for each output (1 through M), the decoder 504 pays "attention" to more important input states; to do so, weights are generated and assigned to denote the contribution of each intermediate state of the input encoder 502; unlike the fixed state vector used for all the decoder time steps in the case of a sequence-to-sequence model without attention, the sequence-to-sequence model 500 incorporates the attention mechanism and computes a separate state or context vector 503 for each time step by computing the attention weights at every time step; ¶¶ [0086] and [0089]: the second machine learning model takes as input various details and information in a cumulative fashion, including: a product description or product platform, symptoms and error descriptions, and diagnostic and repair actions predicted by the first machine learning model; the second machine learning model differs from the first machine learning model in that it incorporates an attention mechanism; the attention mechanism of the second machine learning model helps to focus on specific parts of the input to predict suitable KPI values for the troubleshooting actions recommended by the first machine learning model; e.g., the attention mechanism can enable the second machine learning model to pay attention to certain words in its input to predict that a repair action is likely to result in NFF; ¶¶ [0090]-[0091] with FIG. 7: training of the second machine learning model will now be described with respect to the tables 700 and 710 of FIG. 7; the table 700 shows a set of logs, including a repair identifier, a product description, a symptom set, error descriptions, error conditions, action taken, and results, wherein (a) the symptom set in table 700 is shown as a number (e.g., 1) that represents one or more symptoms encountered by an asset (in other embodiments, the symptom set may be represented as one or more columns each indicating a particular symptom encountered by an asset); (b) the error descriptions include tier 1 and tier 2 error descriptions, indicating descriptions and sub-description of errors encountered; (c) the error condition provides additional detail regarding the errors encountered; (d) the action taken field indicates the troubleshooting action or actions taken in attempt to remedy the errors encountered; and (e) the results include tier 1 and tier 2 entries or fields, where the tier 1 result field provides a high-level description of the results of the troubleshooting action taken while the tier 2 result field provides additional detail; the table 700 also has corresponding KPIs filled in (e.g., a repair KPI indicating VFF or NFF, and a diagnostic KPI of effective or ineffective); the input of table 700 is converted to training data with labels as shown in table 710; based on what the last action recommendation is (e.g., a diagnostic action or a repair action), an appropriate KPI label (e.g., the diagnostic KPI or the repair KPI) is passed to the second machine learning model; complex/trivial KPI may be used for both diagnostic and repair actions, and may be used in training of the second machine learning model as part of the label; ¶¶ [0092]-[0093] with FIG. 8: the recommendation engine 809 uses a trained or deployed instance of the first machine learning model 807, along with information passed from the asset information repository 805, to provide troubleshooting action recommendations for the incoming asset; these troubleshooting recommendations are provided from the recommendation engine 809 to a second machine learning model 811 for pre-screening); and fine-tuning the second AI model to align with preferences of the specific domain to maximize reward and minimize error (Vah, ¶¶ [0036]-[0037]: the troubleshooting action performance module 118 allows the recommended troubleshooting action responsive to determining that the predicted success of the recommended troubleshooting action meets the one or more designated criteria; responsive to determining that the predicted success of the recommended troubleshooting action does not meet the one or more designated criteria, the troubleshooting action recommendation module 114 modifies the recommended troubleshooting action; the troubleshooting action pre-screening module 116 then analyzes the modified recommended troubleshooting action; the machine learning-based troubleshooting system 112 may utilize the modules 114, 116 and 118 in an iterative process until the given asset is successfully repaired or a designated stop condition is reached (e.g., a threshold number of iterations of requesting recommended troubleshooting actions); ¶¶ [0051]-[0056] and [0061] with 208-212 in FIG. 2: process continues with step 208, determining whether the predicted success of the recommended troubleshooting action meets one or more designated criteria; step 208 may include determining whether the predicted success of the recommended troubleshooting action meets a confidence score for each of one or more key performance indicators (KPIs); when the recommended troubleshooting action comprises a diagnostic action, the one or more KPIs may comprise at least one of an effectiveness in diagnosing one or more errors encountered by the given asset, a complexity of performing the diagnostic action, and a cost of performing the diagnostic action; when the recommended troubleshooting action comprises a repair action, the one or more KPIs may comprise at least one of a likelihood of the repair action resulting in a verified fault of one or more components of the given asset, a complexity of performing the repair action, and a cost of performing the repair action; responsive to determining that the predicted success of the recommended troubleshooting action does not meet the one or more designated criteria (i.e., responsive to determining that the predicted success of the recommended troubleshooting action does not meet the confidence score for each of one or more KPIs), the recommended troubleshooting action is modified in step 212; steps 204, 206 and 208 are then repeated utilizing the modified recommended troubleshooting action; modifying the recommended troubleshooting action in step 212 may comprise providing the obtained information regarding the given asset and feedback regarding the recommended troubleshooting action as input to the first machine learning model and receiving, from the decoder of the first machine learning model, the modified recommended troubleshooting action; the machine learning model learns from correct repair decisions but not incorrect repair decisions (e.g., where a "good" part of the laptop or other computing device is needlessly replaced and categorized as no fault found (NFF)); incorporate such feedback (e.g., from both correct and incorrect repair and diagnostic decisions) to improve a system for troubleshooting computing devices or other types of assets; troubleshooting re-work costs may be measured through various key performance indicators (KPIs), in terms of labor inefficiencies, parts waste, inappropriate use of diagnostics, customer returns within some designated threshold time of repair (e.g., 28 days) also referred to as repeat dispatch rate (RDR), etc.; if the prescreening outcome does not meet one or both of these conditions, the recommended troubleshooting action may be altered or supplemented based on one or more rules or policies (e.g., the recommended troubleshooting action may be overridden with an alternate recommendation based on the rules or policies, the recommended troubleshooting action may be accepted based on the rules or policies, etc.); the rules or policies may be based on historical feedback data for previous troubleshooting processes for similar assets, based on expert knowledge, etc.; if no rules or policies are present for handling a particular recommended troubleshooting action, the recommended troubleshooting action may be presented to the technician along with a notification ( e.g., a warning) that an undesirable outcome is likely to result from implementing the recommended troubleshooting action; ¶¶ [0063]-[0064] with FIG. 3B: in step 307, a determination is made as to whether the confidence score for the recommended repair action exceeds a designated threshold confidence score; the threshold confidence score may be set as desired by a user to optimize pre-screening for reducing repair action re-work; the step 307 determination is a prediction for one or more KPIs associated with the recommended repair action; e.g., step 307 may be viewed as determining whether the recommended repair action is likely to result in VFF (e.g., proceed to step 308) or NFF (e.g., proceed to step 310); in step 309, the repair is completed and the given asset is analyzed (e.g., to determine whether the recommended repair action was successful); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); if the confidence score does not exceed the designated threshold in step 307, the system flow proceeds to step 310; ¶¶ [0065]-[0067] with FIG. 3C: in step 312, a determination is made as to whether the confidence score for the recommended diagnostic action exceeds a designated threshold confidence score; the threshold confidence score may be set as desired by a user to optimize pre-screening for reducing repair action re-work; the step 312 determination is a prediction for one or more KPIs associated with the recommended diagnostic action; e.g., step 312 may be viewed as determining whether the recommended diagnostic action is likely to be effective (e.g., proceed to step 313) or ineffective (e.g., proceed to step 310); the threshold confidence score utilized in step 312 may be different than the threshold confidence score utilized in step 307; these threshold levels are based on confidence scores from respective machine learning models; in step 314, the diagnosis for the given asset is confirmed (e.g., the diagnostic results are analyzed to determine if the problem with the given asset has been successfully diagnosed); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); if the confidence score does not exceed the designated threshold in step 312, the system flow proceeds to step 310; ¶¶ [0068]-[0070] with FIG.3D: if a rule or policy exists in step 310, that rule or policy is applied and feedback is generated regarding the recommended repair or diagnostic action in step 316; such feedback is provided to the expert troubleshooting system 301 in path 1 (e.g., to the first machine learning model used in step 303); such feedback may also be utilized to create new rules or policies, or modify existing rules or policies, for future recommended troubleshooting actions; ¶ [0075] with FIG. 4: in case the outcome of the repair or diagnostic action is 1 (e.g., indicating success), then there is no change in the input words provided to the encoder 402 based at least in part on the output vocabulary of the decoder 404; if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; adding the negation includes adding "not" to each output of the decoder 404; this indicates that the output of the previous step was a failure (e.g., replacing the output "replace commodity motherboard" of the decoder 404 with "replace_not commodity_not motherboard_not"); ¶¶ [0085]-[0089] with FIG. 6: the table 600 includes entries of logs of symptom sets, diagnostics and repair actions for a product platform "LAT-7480", wherein each row of the table 600 is assumed to correspond to output of the first machine learning model, which is supplemented with feedback from the second machine learning model; the second machine learning model output indicates whether the outcome of the diagnostic or repair action recommended by the first machine learning model is desirable or not, as measured using one or more KPIs (e.g., VFF or NFF, effective or ineffective diagnostic, complex or trivial diagnostics or repairs, etc.); feedback is then routed to the input of the first machine learning model, where the feedback may be "replace commodity memory-NFF"; in a second iteration, the first machine learning model, uses feedback from the first iteration, and provides a new recommended repair action of "reseat commodity memory"; the second machine learning model predicts that this recommended repair action will result in VFF (e.g., the electrical interconnects are cleaned during the re-seat of the memory, solving the symptom set); accordingly, the repair action of "reseat commodity memory" is flagged as desirable (e.g., likely to result in VFF); the technician will perform the recommended repair action, which is assumed to result in a successful outcome; feedback is then routed to the input of the first machine learning model (e.g., model 400), where the feedback may be "reseat commodity memory-VFF"; ¶¶ [0093]-[0097] with FIG. 8: in block 813, a determination is made as to whether the recommended troubleshooting action meets a confidence score (e.g., that the recommended troubleshooting action is likely to be successful); if the result of block 813 is yes, feedback is provided to the recommendation engine 809 to initiate application of the recommended troubleshooting action; if the result of block 813 is no, the flow moves to block 815 where a determination is made as to whether any rule or policy exists to cover the recommended troubleshooting action for the incoming asset; if the result of block 815 is yes, then appropriate feedback is provided to the recommendation engine 809; this feedback may cause the recommendation engine 809 to re-invoke the first machine learning model 807 to obtain a new recommended troubleshooting action without applying the previous recommended troubleshooting action; the feedback will vary based on the particular rule or policy being applied; if the result of block 815 is no, the flow may proceed to displaying a warning or other notification via a guidance interface 817; in block 823, it is determined whether the asset is fixed by the repair action performed in block 821; if the result of the block 823 determination is yes, the troubleshooting is complete and the incoming asset 801 is converted to an outgoing asset 825 that leaves the repair depot (e.g., the asset is returned to the customer or other end-user); feedback may also be provided to the first machine learning model 807 and second machine learning model 811 via the recommendation engine 809; if the result of the block 823 determination is no, feedback is provided to the guidance interface 817 for technician analysis 827; the guidance interface 817 is used by the technician performing troubleshooting of the asset to log the repair action taken, to report results of the repair action, to provide instruction to the technician on how to perform the repair action, etc.; the feedback may also be provided by the guidance interface 817 to the first machine learning model 807 and the second machine learning model 811 via the recommendation engine 809; if the result of the block 819 determination is no (e.g., the recommended troubleshooting action is a diagnostic action), the diagnostic action is performed on the asset (e.g., automatically such as by running test software on the asset, manually by a technician inspecting parts, etc.); the results of the diagnostic action are then analyzed by the technician in block 827; the technician may utilize the guidance interface 817 to log the diagnostic action taken, report results of the diagnostic action, etc.; the guidance interface 817 provides feedback to the first machine learning model 807 and second machine learning model 811 regarding the diagnostic actions via the recommendation engine 809).
Vah further discloses a non-transitory computer readable medium, storing instructions for executing a process described above (Vah, ¶¶ [0109], [0111], and [0118] with 1012 in FIG. 10: the processing device 1002-1 in the processing platform 1000 comprises a processor 1010 coupled to a memory 1012, wherein the memory 1012 and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as "processor-readable storage media" storing executable program code of one or more software programs; one or more software programs stored in memory and executed by a processor of a processing device).
Vah also discloses an apparatus, comprising: a processor, configured to perform the method described above (Vah, ¶¶ [0109]-[0110] and [0118]: the processing device 1002-1 in the processing platform 1000 comprises a processor 1010, wherein the processor 1010 may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a central processing unit (CPU), a graphical processing unit (GPU), a tensor processing unit (TPU), a video processing unit (VPU) or other type of processing circuitry, as well as portions or combinations of such circuitry elements; one or more software programs stored in memory and executed by a processor of a processing device).
Vah fails to explicitly disclose wherein (1) the first AI model includes the first generative AI model; and (2) training a second Al model for a specific domain from the first AI model through transfer learning, wherein learned representations of the standard information components from the first Al model are transferred to initialize the second Al model.
Malladi teaches a system and a method for providing recommendation (Malladi, ABSTRACT), wherein (1) the first AI model includes the first generative AI model ; and (2) training a second Al model for a specific domain from the first AI model through transfer learning (Malladi, ¶¶ [0005]-[0010]: recommending an action for the building responsive to a user query and predicting a plurality of entities affected by the action; the plurality of entities are associated with a plurality of separate domain systems that use a plurality of different data formats; generating, using at least one generative AI model, a plurality of control outputs in the plurality of different data formats and affecting operations of the plurality of separate domain systems by providing the plurality of control outputs in the plurality of different data formats to the plurality of separate domain systems; the user query is provided as a freeform textual or audio input; the plurality of separate domain systems can include two or more of an HVAC system, a work order system, a room reservation system, an access control system, a security system, a fire system, a medical device system, an energy system, a building management system, a lighting system, an elevator system, a manufacturing system, an inventory system, and a parking system; augmenting the at least one generative AI model using training data relating to the plurality of separate domain systems; predicting the plurality of entities affected by the action includes generating an indication of the plurality of entities using the at least one generative AI model; ¶¶ [0022]-[0033]: virtual assistance for supporting technicians responding to service requests; generating technical reports corresponding to service requests; facilitating diagnostics and troubleshooting procedures; recommendations of services to be performed; and/or recommendations for products or tools to use or install as part of service operations; use machine learning models, including LLMs and other generative AI systems, to capture data, including but not limited to unstructured knowledge from various data sources, and process the data to accurately generate outputs, such as completions responsive to prompts, including in structured data formats for various applications and use cases; perform root cause prediction by being trained using data that includes indications of root causes of faults or errors, where the indications are labels for or otherwise associated with (unstructured or structure) data such as service requests, service reports, service calls, etc.; receive, from a service technician in the field evaluating the issue with the equipment, feedback regarding the accuracy of the root cause predictions, as well as feedback regarding how the service technician evaluated information about the equipment (e.g., what data did they evaluate; what did they inspect; did the root cause prediction or instructions for finding the root cause accurately match the type of equipment, etc.), which can be used to update the root cause prediction model; a platform for fault detection and servicing processes in which a machine learning model is configured based on connecting or relating unstructured data and/or semantic data, such as human feedback and written/spoken reports, with time-series product data regarding items of equipment, so that the machine learning model can more accurately detect causes of alarms or other events that may trigger service responses; leverage the efficiency of language models (e.g., GPT-based models or other pre-trained LLMs) in extracting semantic information (e.g., semantic information identifying faults, causes of faults, and other accurate expert knowledge regarding equipment servicing) from the unstructured data in order to use both the unstructured data and the data relating to equipment operation to generate more accurate outputs regarding equipment servicing; take advantage of the causal/semantic associations between the unstructured data and the data relating to equipment operation, and the language models can allow these systems to more efficiently extract these relationships in order to more accurately predict targeted, useful information for servicing applications at inference-time/runtime; using generative AI models such as transformers and/or GANs; enable a generative AI-based service wizard interface; e.g., the interface can include user interface and/or user experience features configured to provide a question/answer-based input/output format, such as a conversational interface, that directs users through providing targeted information for accurately generating predictions of root cause, presenting solutions, or presenting instructions for repairing or inspecting the equipment to identify information that the system can use to detect root causes or other issues; a plurality of machine learning models that may be configured using integrated or disparate data source; facilitate more integrated user experiences or more specialized (and/or lower computational usage for) data processing and output generation; outputs from one or more first systems, such as one or more first algorithms or machine learning models, can be provided at least as part of inputs to one or more second systems, such as one or more second algorithms or machine learning models; e.g., a first language model can be configured to process unstructured inputs (e.g., text, speech, images, etc.) into a structure output format compatible for use by a second system, such as a root cause prediction algorithm or equipment configuration model; automate interventions for equipment operation, servicing, fault detection and diagnostics (FDD), and alerting operations; e.g., perform operations such as root cause prediction, the system can monitor data regarding equipment to predict events associated with faults and trigger responses such as alerts, service scheduling, and initiating FDD or modifications to configuration of the equipment; present to a technician or manager of the equipment a report regarding the intervention (e.g., action taken responsive to predicting a fault or root cause condition) and requesting feedback regarding the accuracy of the intervention, which can be used to update the machine learning models to more accurately generate interventions; provide a copilot for a building manager, facilitating a building manager in controlling multiple domain systems for a building; the domain systems can include building management systems, HVAC systems, lighting systems, access control systems, ticketing systems (e.g., for stadiums, theaters, etc.), security systems, elevator systems, escalator systems, fire protection systems, energy systems ( e.g., metering and management systems, on-site power generation systems such as solar energy systems, geothermal systems, wind power systems, microreactors, fossil-fuel-based generators, etc.), work order systems ( e g, maintenance systems), and systems relating to type/purpose of the building (e.g., a healthcare system such as a medical device system, nurse call system, patient monitoring system, electronic medical records system, etc. for a hospital or clinic; a manufacturing system such as a smart manufacturing management system for a factory; an inventory system for a warehouse or retail facility; a room reservation system for an office facility; a server management system for a data center; connected kitchen equipment for a restaurant, etc.); ¶¶ [0034]-[0036] and [0039]-[0080] with FIG. 1: configuring (e.g., training, updating, modifying, transfer learning, fine-tuning, etc.) and/or operating various AI and/or ML systems, such as neural networks of LLMs or other generative AI systems to implement various generative AI-based building equipment servicing operations; one or more first models 104 include one or more neural networks, including neural networks configured as generative models); e.g., the first model 104 can predict or generate new data (e.g., artificial data; synthetic data; data not explicitly represented in data used for configuring the first model 104); the first model 104 can generate any of a variety of modalities of data, such as text, speech, audio, images, and/or video data; the first model 104 can include one or more language models, LLMs, attention-based neural networks, transformer-based neural networks, generative pretrained transformer (GPT) models, bidirectional encoder representations from transformers (BERT) models, encoder/decoder models, sequence to sequence models, autoencoder models, generative adversarial networks (GANs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), diffusion models ( e.g., denoising diffusion probabilistic models (DDPMs)), or various combinations thereof; the first model 104 can include at least one diffusion model, which can be used to generate image and/or video data; e.g., the diffusional model can include a denoising neural network and/or a denoising diffusion probabilistic model neural network; the first model 104 includes a plurality of generative models, such as GPT and diffusion models, that can be trained separately or jointly to facilitate generating multi-modal outputs, such as technical documents (e.g., service guides) that include both text and image/video information; the first model 104 can be configured using various unsupervised and/or supervised training operations; the first model 104 can be configured using training data from various domain-agnostic and/or domain-specific data sources; the training data can include a plurality of training data elements (e.g., training data instances); each training data element can be arranged in structured or unstructured formats; e.g., the training data element can include an example output mapped to an example input, such as a query representing a service request or one or more portions of a service request, and a response representing data provided responsive to the query; the training data includes data relating to building management systems; e.g., the training data can include examples of HVAC-R data, such as operating manuals, technical data sheets, configuration settings, operating setpoints, diagnostic guides, troubleshooting guides, user reports, technician reports; configure the first model 104 to determine one or more second models 116; a model updater 108 that configures (e.g., trains, updates, modifies, fine-tunes, etc.) the first model 104 to determine the one or more second models 116; the second model 116 can be used to provide application-specific outputs, such as outputs having greater precision, accuracy, or other metrics, relative to the first model, for targeted applications; the model updater 108 can provide training data to the first model 104, via the API, to determine the second model 116 based on the first model 104 and the training data; the model updater 108 can determine the second model 116 using data from one or more data sources 112; determine the second model 116 by modifying the first model 104 using data from the one or more data sources 112; using the first model 104 and/or second model 116 to process the data can allow the system 100 to extract useful information from data in a variety of formats, including unstructured/freeform formats, which can allow service technicians to input information in less burdensome formats; the data sources 112 can include engineering data regarding one or more items of equipment, which can include (a) manuals, such as installation manuals, instruction manuals, or operating procedure guides; (b) specifications or other information regarding operation of items of equipment; and (c) engineering drawings, process flow diagrams, refrigeration cycle parameters (e.g., temperatures, pressures), or various other information relating to structures and functions of items of equipment; the equipment can be associated a variety of different domains associated with a building; the data sources 112 can include operational data regarding one or more items of equipment, which can represent detected information regarding items of equipment, such as meter data, sensor data, logged data, user reports, or technician reports; the operational data can include service tickets generated responsive to requests for service, work orders, data from digital twin data structures maintained by an entity of the item of equipment, outputs or other information from equipment operation models (e.g., chiller vibration models), equipment settings, or various combinations thereof; identify and diagnose performance issues with equipment, determine interrelationships between equipment, predict effects of different actions on various different domains and equipment, etc.; the data sources 112 can include warranty data which can include warranty documents or agreements that indicate conditions under which various entities associated with items of equipment are to provide service, repair, or other actions corresponding to items of equipment, such as actions corresponding to service requests; the warranty data can be associated with different domain systems and can different service providers; the data sources 112 can include service data which can include data from any of various service providers, such as service reports; the service data can indicate service procedures performed, including associated service procedures with initial service requests and/or sensor data related conditions to trigger service and/or sensor data measured during service processes' the service data can be related to service on different domain systems, for example by different service providers and with service reports in multiple different formats; the data sources 112 can include parts data, including parts usage and sales data; e.g., the data sources 112 can indicate various parts associated with installation or repair of items of equipment; the data sources 112 can indicate tools for performing service and/or installing parts; the parts can be associated with multiple different domain systems, for example parts for HVAC equipment, parts for lighting equipment, parts for an elevator system, etc.; the data sources 112 can include domain system data which can include data relating to the configuration, operation, activation, scope, etc. of various domain systems; e.g., the domain system data can identify the domain systems present at a building, data formats (e.g., protocols, data objects, templates, input requirements, output formats, etc.) used by the domain systems, information relating to application programming interfaces (APIs) used by the domain systems, etc.; domain system data can include logged data of actions taken in different domain systems, for example in a manner such that the data sources 112 can reflect actions taken concurrently in multiple domain systems such that the system 100 can extract information relating to correlation between operations of the domain systems; domain system data can include data in a variety of different formats and relating to various types of information depending on the particular different domain systems included; the system 100 can include labels to facilitate cross-reference between items of data that may relate to common items of equipment, sites, service technicians, customers, or various combinations thereof; the data sources 112 can include data can be particular to specific or similar items of equipment, buildings, equipment configurations, environmental states, or various combinations thereof; the data includes labels or identifiers of such information, such as to indicate locations, weather conditions, timing information, uses of the items of equipment or the buildings or sites at which the items of equipment are present, etc.; this can enable the models 104, 116 to detect patterns of usage (e.g., spikes; troughs; seasonal or other temporal patterns) or other information that may be useful for determining causes of issues or causes of service requests, or predict future issues, such as to allow the models 104, 116 to be trained using information indicative of causes of issues across multiple items of equipment (which may have the same or similar causes even if the data regarding the items of equipment is not identical; configure the models 104, 116 to determine a high likelihood of issues occurring before events associated with high usage (e.g., gala, major exhibit opening), and can generate recommendations to perform diagnostics or servicing prior to the events; the model updater 108 can perform various machine learning model configuration/training operations to determine the second models 116 using the data from the data sources 112; e.g., the model updater 108 can perform various updating, optimization, retraining, reconfiguration, fine-tuning, or transfer learning operations, or various combinations thereof, to determine the second models 116; the model updater 108 can configure the second models 116, using the data sources 112, to generate outputs (e.g., completions) in response to receiving inputs (e.g., prompts), where the inputs and outputs can be analogous to data of the data sources 112; the model updater 108 can select at least a subset of the identified one or parameters to maintain according to various criteria, such as user input or other instructions indicative of an extent to which the first model 104 is to be modified to determine the second model 116; the model updater 108 can evaluate a convergence condition to modify the candidate second model 116 based at least on the one or more candidate outputs and the training data applied as input to the candidate second model 116; the model updater 108 can use any of a variety of optimization algorithms (e.g., gradient descent, stochastic descent, Adam optimization, etc.) to modify one or more parameters ( e.g., weights or biases of the layer( s) of the candidate second model 116 that are not frozen) of the candidate second model 116 according to the evaluation of the objective function; the model updater 108 can select the training data from the data of the data sources 112 to apply as the input based at least on a particular application of the plurality of applications 120 (e.g., product/service recommendation generator application) for which the second model 116 is to be used for; each application 120 is coupled with a corresponding second model 116 that is specifically configured to generate outputs for use by the application 120; use the second model 116 (which can be trained to cross-reference metadata in different portions of inputs and relate together data elements) to generate output reports (e.g., the second model 116, having been configured with data that includes time information, can use timestamps of input from dictation and timestamps of when an image is taken, and place the image in the report in a target position or label based on time correlation); the diagnostics and troubleshooting application 120 can receive inputs including at least one of a service request or information regarding the item of equipment to be serviced, such as information identified by a service technician; the diagnostics and troubleshooting application 120 can provide the inputs to a corresponding second model 116 to cause the second model 116 to generate outputs such as indications of potential items to be checked regarding the item of equipment, modifications or fixes to make to perform the service, or values or ranges of values of parameters of the item of equipment that may be indicative of specific issues to for the service technician to address or repair; the service recommendation generator application 120 can receive inputs such as a service request or information regarding the item of equipment to be serviced, and provide the inputs to the second model 116 to cause the second model 116 to generate outputs for presenting service recommendations, such as actions to perform to address the service request; the product recommendation generator application 120 can process inputs such as information regarding the item of equipment or the service request, using one or more second models 116 (e.g., models trained using parts data from the data sources 112), to determine a recommendation of a part or product to replace or otherwise use for repairing the item of equipment; a copilot application 120 which uses the one or more second models 116 can help guide a user (e.g., building manager, occupant, technician) in coordinating operations of multiple separate domain systems that serve a building; the copilot application 120 can provide a conversational interface between a user and the building, autonomously generating outputs, control signals, instructions, etc. for the different domain systems in different data formats (protocols, structures, etc.) suitable for the different domain systems while insulating the user from such complexities; the copilot application 120 can thereby provide a unified, easy-to-use conversational interaction between a user and various domain systems serving the building, including in a manner which provides for coordinated operation of multiple domain systems in accordance with recommendations generated by the copilot application 120 in response to unstructured (e.g., freeform, natural language, textual, spoken) inputs from a user; use the feedback trainer 128 to increase the precision and/or accuracy of the outputs generated by the second models 116 according to feedback provided by users of the system 100 and/or the applications 120; feedback, received from users regarding output presented by the applications 120, include, e.g., (a) indications of binary feedback regarding the outputs (e.g., good/bad feedback; feedback indicating the outputs do or do not meet the user's criteria, such as criteria regarding technical accuracy or precision); (b) indications of multiple levels of feedback (e.g., scoring the outputs on a predetermined scale, such as a 1-5 scale or 1-10 scale); (c) freeform feedback (e.g., text or audio feedback); or (d) various combinations thereof; the feedback trainer 128 can update the one or more second models 116 using the feedback; the feedback trainer 128 can perform various configuration operations (e.g., retraining, fine-tuning, transfer learning, etc.) on the second models 116 using the feedback from the feedback repository 124; the second model 116 can be coupled with one or more third models, functions, or algorithms for training/configuration and/or runtime operations; the second model 116 can be used to process unstructured information regarding items of equipment into predefined template formats compatible with various third models, such that outputs of the second model 116 can be provided as inputs to the third models; allow more accurate training of the third models, more training data to be generated for the third models, and/or more data available for use by the third models; use at least one of the first model 104 or the second model 116 to determine, based on processing information regarding service operations for items of equipment relative to completion criteria for the service operation, particular characteristics of service operations such as experience parameters of scheduled service technicians, identifiers of parts provided for the service operations, geographical data, types of customers, types of problems, or information content provided to the service technicians to facilitate the service operation, where such characteristics correspond to the completion criteria being satisfied (e.g., where such characteristics correspond to an increase in likelihood of the completion criteria being satisfied relative to other characteristics for service technicians, parts, information content, etc.); ¶¶ [0141]-[0156] with FIGS. 9-10: providing a building copilot that uses at least one AI model (e.g., generative AI model) to coordinate operations of multiple building domain systems based on conversational input from a user; the copilot 902 includes a recommender 918, effect predictor 920, and output generator 922 which can be implemented using at least one AI model (e.g., separate model(s) for each of the recommender 918, effect predictor 920, and output generator 922, a unified model or set of models that integrally provides the recommender 918, effect predictor 920, and output generator 922, etc.); one or more generative AI models according to the teachings herein can be used to provide the operations of the recommender 918, the effect predictor 920, and the output generator 922; a large language model is augmented with additional models, pre-processing algorithms, post-processing algorithms, feature generation algorithms, etc. in order to provide an augmented model tuned to provide the features of the copilot 902; the recommender 918 can use at least one AI model (e.g., generative AI model) to generate an action to be taken responsive to the user query (e.g., a change in settings to reduce energy consumption, a particular maintenance task to perform, a control decision to prepare a space for an event, a message to be provided to occupants, etc.); the effector predictor 920 can generate an indication of effects on other domain systems (e.g., an HVAC system, an access control system, a room reservation system) that may be indirectly affected by the action (e.g., conducting equipment maintenance can involve providing a technician with access to a space, HVAC equipment may be maintained as part of the maintenance action and/or may need to operate to enable the maintenance or compensate for equipment being off-line during maintenance, a room reserved for occupant use may become uncomfortable while maintenance is performed or may be needed by the technician, etc.); the effect predictor 920 can use generative artificial intelligence according to the teachings above to predict ( e.g., generate) a list of other domain systems that will be affected by the recommended action and identify such effects, consequences, etc. of the recommended action; the output generator 922 is configured generate, using at least one generative AI model, control outputs (control signals, prompts, instructions, control logic, computer code, etc.) for the multiple domain systems for implementing the recommended action and for proactively accounting for the effects of the recommended action determined by operation of the recommender 918 and the effect predictor 920; the recommender 918 can use at least one generative AI model to determine an action to be taken in domain system A 906 to address the user's query; the effect predictor 920 can then use the at least one generative AI model to predict that the domain system B 908 and the domain system 910 will be impacted by the action to be taken in domain system A 906 and/or otherwise indirectly, tangentially, or also are involved in fully responding to the user query; the output generator 922 can then use the at least one generative AI model to generate a first control output for domain system A 906 in a first data format compatible with API A 912, a second control output for domain system B 908 in a second data format compatible with API B 914, and a third control output for domain system Ω in a third data format compatible with API Ω 916; by use of at least one generative AI model as described above, the copilot 902 can be automatically adaptive to learning, from the data lake 924, interrelationships between domain systems 906-910 and desired user interoperation of domain systems 906-910 to provide an easily-deployable, flexible, scalable, seamless (from a user's perspective) copilot 902 to assist users (e.g., occupants, building managers, etc.) in achieving desired building outcomes (e.g., behaviors, conditions, consumption goals, emissions targets, etc.) without requiring such users to reach separately into multiple domain systems).
Vah and Malladi are analogous art because they are from the same field of endeavor, a system and a method for providing recommendation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply the teaching of Malladi to Vah. Motivation for doing so would more accurately predict targeted information for servicing application by allowing more accurate training of the second models, more training data to be generated for the second models, and/or more data available for use by the second models (Malladi, ¶¶ [0029] and [0079]).
Vah in view of Malladi fails to explicitly disclose wherein learned representations of the standard information components from the first Al model are transferred to initialize the second Al model.
Chen'2020 teaches a system and a method relating to using AI models (Chen'2020, ABSTRACT), wherein learned representations of the standard information components from the first Al model are transferred to initialize the second Al model (Chen'2020, ABSTRACT of Page 8702: transfer learning provides a promising tool for handling the cross-domain diagnosis problems by leveraging knowledge from the source domain to help learning in the target domain; most existing studies attempt to learn both domain features in a common feature space to reduce the domain shift, which are not optimal on specific discriminative tasks and can be limited to small shifts; this article proposes a novel domain adversarial transfer network (DATN), exploiting task-specific feature learning networks and domain adversarial training techniques for handling large distribution discrepancy across domains; first, two asymmetric encoder networks integrating deep convolutional neural networks are designed for learning hierarchical representations from the source domain and target domain; then, the network weights learned in source tasks are transferred to improve training on target tasks; finally, domain adversarial training with inverted label loss is introduced to minimize the difference between source and target distributions; to validate the effectiveness and superiority of the proposed method in the presence of large domain shifts, two fault data sets from different test rigs are investigated, and different fault severities, compound faults, and data contaminated by noise are considered; Section III with FIG. 2 of Pages 8704-8707: the proposed fault diagnosis framework is presented in FIG. 2, which consists of three stages: a) the feature encoder; b) the weight transfer; and c) the domain adversarial training; the main objective is to learn feature encoder models and a discriminative model, which can correctly recognize the corresponding K fault categories in the target domain; to learn high-level feature representations for the source domain and the target domain, the feature encoder network is first introduced, which includes a generator G and a classifier C; the generator G is used to encoder input data to obtain high-level discriminative representation and classifier C will conduct the final classification for the source and the target tasks; for the source-domain data xs and the target-domain data xt, two CNNs are separately adopted as the feature extractors of Gs and Gt to capture the specific domain features; the two CNNs, which share the same network structure, are forced to learn the feature distributions; then the two encoder networks map the input data xs and xt to the outputs Gs(xs) and Gt(xt), respectively; in order to reduce the data distribution discrepancy between Gs(xs) and Gt(xt), a discriminator D is used to implement the domain adversarial training; in the discriminator D, a multilayer fully connected network is designed for discriminating the features from the source task or the target task; in the DA stage, a discriminative model D is constructed to implement the two player games; the fully connected outputs of Gs and Gt are input into D to obtain the probability score, which estimates the likelihood that the input is drawn from a true data distribution; the Adam optimizer is used to optimize the parameters of the proposed DATN; weight transfer is commonly used to transform a pretrained deep network into a new network to improve the classification performance; several studies have found that DNN can learn transferable features, which are changed from general to specific along the networks, which can enable the training of a large target network with small overfitting risk; the transfer strategy has been successfully applied to intelligent fault diagnosis to improve the training speed and classification accuracy by further fine-tuning the pretrained network using a small set of labeled target training samples; in the proposed network, since the target-domain data are unlabeled, the weights of the encoder network that are trained on source task are used to initialize that of the target network; this transfer strategy can be regarded as satisfactory initialization of the target network, which typically enables higher feature learning performance and more stable training; after the weight transfer to the target network from the pretrained source network, the parameters of Gt can be further adjusted to adapt to the target task by optimizing an adversarial objective with respect to a domain discriminator; encoder networks are used to learn the deep features of the source-domain and target-domain tasks; the optimization of the DATN can be divided into two stages: learning the source mapping Gs and the classifier C on the source data set and implementing adversarial training on the target mapping Gt and the discriminator D; after completing the training of the Gs and the C, the parameters of the deep model can be transferred to the target network, which are used for the prediction on the target-domain data set; if the source and target domains are highly similar, the pretrained network that was trained on source will perform well on the target domain; however, if a domain shift occurs, it will lead to a reduced performance at test stage; therefore, the parameters of generator Gt should be further optimized to minimize the distance between the source domain and the target domain using adversarial training; DA with adversarial training aims at reducing the data discrepancy between the source domain and the target domain; a typical adversarial adaptive solution is to minimize the mapping distance between Gs and Gt by using a discriminator D; then, the optimized object loss according to Eqn. (1) of GAN can be expressed as shown in Eqn. (11); in order to reduce the gradient vanishing and to improve the learning performance, an object loss with an inverted label GAN loss is adopted; the complete fault diagnosis procedure of the proposed DATN can be summarized as follows: a) the labeled source-domain data {xs, ys} and unlabeled target data xt are collected from different mechanical fault diagnosis test rigs and the samples are further divided into training and testing samples; b) given the source data {xs, ys}, supervised training is implemented to update the generator Gs and the classifier C by minimizing (10) with respect of the parameters θs; then the pretrained weights of Gs are further transferred to initialize the target generator Gt to enhance the feature learning capability; c) given the source-domain and target-domain unlabeled data, D and Gt are alternatively updated by optimizing corresponding objective function from (14) and (15); d) training progress of step 3) is repeated and Gt gradually produces consistent data distributions between the source domain and the target domain until it reaches a threshold of number of iterations or a threshold of loss errors; and e) In the test stage, the target-domain testing data can be fed into Gt for deep feature extraction and the C can be directly used for fault classification)
Vah in view of Malladi, and Chen'2020are analogous art because they are from the same field of endeavor, a system and a method relating to using AI models. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply the teaching of Chen'2020 to Vah in view of Malladi. Motivation for doing so would enable higher feature learning performance and more stable training (Chen'2020, Section III.B in Pages 8705-8706).
Claims 2 and 10
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 1 and 9 respectively and further discloses wherein the first generative AI model is configured to output a first repair recommendation for the general domain, wherein the second AI model is configured to output a second repair recommendation for the specific domain (Vah, ¶¶ [0034]-[0037] with FIG. 1: the troubleshooting action recommendation module 114 generates a recommended troubleshooting action to be performed on the given asset; to do so, the troubleshooting action recommendation module 114 may utilize a first machine learning model (e.g., a sequence-to-sequence model where the information regarding the given asset to be repaired is passed as input to an encoder of the sequence-to-sequence model, and the recommended troubleshooting action is received as output from a decoder of the sequence-to-sequence model); the troubleshooting action pre-screening module 116 is configured to utilize a second machine learning model to predict the success of the recommended troubleshooting action generated by the troubleshooting action recommendation module 114; to do so, the troubleshooting action pre-screening module 116 provides the recommended troubleshooting action and the obtained information from the output of the troubleshooting action recommendation module 114 regarding the given asset as input to an encoder of the second machine learning model, and receives from a decoder of the second machine learning model a predicted success of the recommended troubleshooting action; the second machine learning model, similar to the first machine learning model, may comprise a sequence-to-sequence model; the second machine learning model, however, implements an attention mechanism that causes the decoder to focus on particular portions of the input to the encoder; the troubleshooting action pre-screening module 116 is further configured to determine whether the predicted success of the recommended troubleshooting action meets one or more designated criteria; the troubleshooting action performance module 118 allows the recommended troubleshooting action responsive to determining that the predicted success of the recommended troubleshooting action meets the one or more designated criteria; responsive to determining that the predicted success of the recommended troubleshooting action does not meet the one or more designated criteria, the troubleshooting action recommendation module 114 modifies the recommended troubleshooting action; the troubleshooting action pre-screening module 116 then analyzes the modified recommended troubleshooting action; the machine learning-based troubleshooting system 112 may utilize the modules 114, 116 and 118 in an iterative process until the given asset is successfully repaired or a designated stop condition is reached (e.g., a threshold number of iterations of requesting recommended troubleshooting actions); ¶¶ [0054]-[0061] with FIG.2: a "first" machine learning model may be used to obtain a recommended troubleshooting action, with steps 204 and 206 utilizing a "second" machine learning model; step 202 utilizes the first machine learning model (e.g., different than the second machine learning model utilized in steps 204 and 206), where the obtained information regarding the given asset is provided as input to an encoder of the first machine learning model and the recommended troubleshooting action is received from a decoder of the first machine learning model; modifying the recommended troubleshooting action in step 212 may comprise providing the obtained information regarding the given asset and feedback regarding the recommended troubleshooting action as input to the first machine learning model and receiving, from the decoder of the first machine learning model, the modified recommended troubleshooting action; troubleshooting re-work costs may be measured through various key performance indicators (KPIs), in terms of labor inefficiencies, parts waste, inappropriate use of diagnostics, customer returns within some designated threshold time of repair (e.g., 28 days) also referred to as repeat dispatch rate (RDR), etc.; troubleshooting action recommendations may be optimized or improved to reduce the amount of troubleshooting re-work; the troubleshooting recommendation system utilizes a first machine learning model to generate troubleshooting action recommendations, and that the troubleshooting recommendation system is extended with a second machine learning model that factors in both correct and incorrect troubleshooting decisions into the troubleshooting action recommendations from the first machine learning model; the first machine learning model may predict troubleshooting actions using a sequence-to-sequence model that treats the troubleshooting process as a conversation, and thus may be referred to as a conversational machine learning model herein; the second machine learning model factors in KPIs (e.g., whether replaced parts are good/NFF or bad/VFF, whether diagnostic actions are effective or ineffective, etc.) into a sequence-to-sequence based model to avoid the prediction of undesirable troubleshooting actions ( e.g., repair solutions resulting in replaced parts that are good/NFF, diagnostics solutions that are ineffective, etc.); the first machine learning model is thus complemented with the second machine learning model, which may comprise a sequence-to-sequence model with an attention mechanism; advantageously, the second machine learning model overcomes the limitations of the first machine learning model by considering all troubleshooting outcomes before making a troubleshooting action recommendation; the inclusion of the second machine learning model provides a pre-screening of the troubleshooting action recommendation before the troubleshooting action recommendation is provided to a technician; if the pre-screening outcome meets both of these conditions, the recommended troubleshooting action is unchanged and is presented to the technician; if the prescreening outcome does not meet one or both of these conditions, the recommended troubleshooting action may be altered or supplemented based on one or more rules or policies (e.g., the recommended troubleshooting action may be overridden with an alternate recommendation based on the rules or policies, the recommended troubleshooting action may be accepted based on the rules or policies, etc.); ¶ [0071]: the first machine learning model provides high-level functions of generating recommended troubleshooting actions (e.g., repair actions, diagnostic actions, etc.); the second machine learning model takes as input information of the given asset being troubleshooted (e.g., asset description such as product platform, symptoms and error descriptions, the recommended troubleshooting action generated by the first machine learning model) and generates an output indicating whether the outcome of the recommended troubleshooting action is desirable or not as per various KPIs, wherein the KPIs may include whether a repair action is likely to result in VFF or NFF, whether a diagnostic action is likely to be effective or ineffective, whether a repair or diagnostic action is complex (e.g., time-consuming, requiring special training or knowledge) or trivial, etc.).
Claims 3 and 11
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 2 and 10 respectively and further discloses wherein the first repair recommendation and the second repair recommendation comprise a sequence of repair activities, each repair activity of the sequence of repair activities comprising a location for a repair and a repair action (Vah, ¶¶ [0021], [0027]-[0029], and [0045] with FIG. 1: the information relating to the assets of the enterprise system 110 may include information such as past errors encountered on the assets and troubleshooting actions used to resolve such encountered errors; each error or problem may include symptom sets as well as a set of diagnostic, repair and other troubleshooting actions taken in attempt to resolve the encountered symptom sets; a given one of the client devices 104 may be operated by a mobile technician that travels to a physical location of an asset to be repaired in the enterprise system 110 (e.g., an office, a data center, etc. of the enterprise system 110); the given client device 104 may be used by the repair technician to access a graphical user interface (GUI) provided by the machine learning-based troubleshooting system 112 to input symptom sets and other information regarding the asset to be repaired, and to receive recommendations for troubleshooting actions to be performed on the asset to be repaired; "repair" should be construed broadly, and includes various types of actions taken to remedy a particular error or other symptoms encountered on an asset; the repair may include changing settings of the assets, modifying (e.g., removing, installing, upgrading, etc.) software on the asset, modifying (e.g., removing, installing, replacing, etc.) hardware on the asset, etc.; the client devices 104 may implement host agents that are configured for automated transmission of information regarding assets to be repaired to the machine learning-based troubleshooting system 112, and to automatically receive recommendations for troubleshooting actions to be performed on the assets to be repaired; in some cases, the troubleshooting actions to be performed may be fully automated, such as by initiating certain diagnostic tests, software component modifications, etc.; in other cases, the troubleshooting actions to be performed may require manual input, such as in replacing hardware components of an asset to be repaired; distributed implementations of the system 100 are possible, in which certain components of the system reside in one data center in a first geographic location while other components of the system reside in one or more other data centers in one or more other geographic locations that are potentially remote from the first geographic location).
Claims 4 and 12
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 1 and 9 respectively and further discloses wherein the training the first generative AI model for the general domain comprises: inputting partial information from known information of the standard information components of the general domain; outputting a prediction of remaining information of the known information from the partial information with the first generative AI model; and utilizing unsupervised learning to reduce error between the predicted remaining information and the known information (Malladi, ¶¶ [0022]-[0033]: virtual assistance for supporting technicians responding to service requests; generating technical reports corresponding to service requests; facilitating diagnostics and troubleshooting procedures; recommendations of services to be performed; and/or recommendations for products or tools to use or install as part of service operations; LLMs, can be used to generate text data and data of other modalities in a more responsive manner to real-time conditions, including generating strings of text data that may not be provided in the same manner in existing documents, yet may still meet criteria for useful text information, such as relevance, style, and coherence; e.g., LLMs can predict text data based at least on inputted prompts and by being configured (e.g., trained, modified, updated, fine-tuned) according to training data representative of the text data to predict or otherwise generate; use machine learning models, including LLMs and other generative AI systems, to capture data, including but not limited to unstructured knowledge from various data sources, and process the data to accurately generate outputs, such as completions responsive to prompts, including in structured data formats for various applications and use cases; implement various automated and/or expert-based thresholds and data quality management processes to improve the accuracy and quality of generated outputs and update training of the machine learning models accordingly; facilitate automated, flexible customer report generation, such as by processing information received from service technicians and other users into a standardized format, which can reduce the constraints on how the user submits data while improving resulting reports; couple unstructured service data to other input/output data sources and analytics, such as to relate unstructured data with outputs of timeseries data from equipment (e.g., sensor data; report logs) and/or outputs from models or algorithms of equipment operation, which can facilitate more accurate analytics, prediction services, diagnostics, and/or fault detection; leverage the efficiency of language models (e.g., GPT-based models or other pre-trained LLMs) in extracting semantic information (e.g., semantic information identifying faults, causes of faults, and other accurate expert knowledge regarding equipment servicing) from the unstructured data in order to use both the unstructured data and the data relating to equipment operation to generate more accurate outputs regarding equipment servicing; take advantage of the causal/semantic associations between the unstructured data and the data relating to equipment operation, and the language models can allow these systems to more efficiently extract these relationships in order to more accurately predict targeted, useful information for servicing applications at inference-time/runtime; using generative AI models such as transformers and/or GANs; enable a generative AI-based service wizard interface; e.g., the interface can include user interface and/or user experience features configured to provide a question/answer-based input/output format, such as a conversational interface, that directs users through providing targeted information for accurately generating predictions of root cause, presenting solutions, or presenting instructions for repairing or inspecting the equipment to identify information that the system can use to detect root causes or other issues; a plurality of machine learning models that may be configured using integrated or disparate data source; facilitate more integrated user experiences or more specialized (and/or lower computational usage for) data processing and output generation; outputs from one or more first systems, such as one or more first algorithms or machine learning models, can be provided at least as part of inputs to one or more second systems, such as one or more second algorithms or machine learning models; e.g., a first language model can be configured to process unstructured inputs (e.g., text, speech, images, etc.) into a structure output format compatible for use by a second system, such as a root cause prediction algorithm or equipment configuration model; ¶¶ [0034]-[0036] and [0039]-[0048] with FIG. 1: configuring (e.g., training, updating, modifying, transfer learning, fine-tuning, etc.) and/or operating various AI and/or ML systems, such as neural networks of LLMs or other generative AI systems to implement various generative AI-based building equipment servicing operations; one or more first models 104 include one or more neural networks, including neural networks configured as generative models); e.g., the first model 104 can predict or generate new data (e.g., artificial data; synthetic data; data not explicitly represented in data used for configuring the first model 104); the first model 104 can generate any of a variety of modalities of data, such as text, speech, audio, images, and/or video data; the parameters of the nodes in the neural network can be configured by various learning or training operations, such as unsupervised learning, weakly supervised learning, semi-supervised learning, or supervised learning; the first model 104 can include one or more language models, LLMs, attention-based neural networks, transformer-based neural networks, generative pretrained transformer (GPT) models, bidirectional encoder representations from transformers (BERT) models, encoder/decoder models, sequence to sequence models, autoencoder models, generative adversarial networks (GANs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), diffusion models ( e.g., denoising diffusion probabilistic models (DDPMs)), or various combinations thereof; the first model 104 can include at least one diffusion model, which can be used to generate image and/or video data; e.g., the diffusional model can include a denoising neural network and/or a denoising diffusion probabilistic model neural network; the denoising neural network can be configured by applying noise to one or more training data elements (e.g., images, video frames) to generate noised data, providing the noised data as input to a candidate denoising neural network, causing the candidate denoising neural network to modify the noised data according to a denoising schedule, evaluating a convergence condition based on comparing the modified noised data with the training data instances, and modifying the candidate denoising neural network according to the convergence condition ( e.g., modifying weights and/or biases of one or more layers of the neural network); the first model 104 includes a plurality of generative models, such as GPT and diffusion models, that can be trained separately or jointly to facilitate generating multi-modal outputs, such as technical documents (e.g., service guides) that include both text and image/video information; the first model 104 can be configured using various unsupervised and/or supervised training operations; the first model 104 can be configured using training data from various domain-agnostic and/or domain-specific data sources; the training data can include a plurality of training data elements (e.g., training data instances); each training data element can be arranged in structured or unstructured formats; e.g., the training data element can include an example output mapped to an example input, such as a query representing a service request or one or more portions of a service request, and a response representing data provided responsive to the query; the training data can include data that is not separated into input and output subsets (e.g., for configuring the first model 104 to perform clustering, classification, or other unsupervised ML operations); the training data includes data relating to building management systems; e.g., the training data can include examples of HVAC-R data, such as operating manuals, technical data sheets, configuration settings, operating setpoints, diagnostic guides, troubleshooting guides, user reports, technician reports; configure the first model 104 to determine one or more second models 116; a model updater 108 that configures (e.g., trains, updates, modifies, fine-tunes, etc.) the first model 104 to determine the one or more second models 116; the second model 116 can be used to provide application-specific outputs, such as outputs having greater precision, accuracy, or other metrics, relative to the first model, for targeted applications; the model updater 108 can provide training data to the first model 104, via the API, to determine the second model 116 based on the first model 104 and the training data; determine relations between data from different sources, such as by using timeseries information and identifiers of the sites or buildings at which items of equipment are present to detect relationships between various different data relating to the items of equipment (e.g., to train the models 104, 116 using both timeseries data ( e.g., sensor data; outputs of algorithms or models, etc.) regarding a given item of equipment and freeform natural language reports regarding the given item of equipment); ¶¶ [0058]-[0063] and [0079] with FIG. 1: the model updater 108 can perform various machine learning model configuration/training operations to determine the second models 116 using the data from the data sources 112; e.g., the model updater 108 can perform various updating, optimization, retraining, reconfiguration, fine-tuning, or transfer learning operations, or various combinations thereof, to determine the second models 116; the model updater 108 can configure the second models 116, using the data sources 112, to generate outputs (e.g., completions) in response to receiving inputs (e.g., prompts), where the inputs and outputs can be analogous to data of the data sources 112; the model updater 108 can select at least a subset of the identified one or parameters to maintain according to various criteria, such as user input or other instructions indicative of an extent to which the first model 104 is to be modified to determine the second model 116; the model updater 108 can evaluate a convergence condition to modify the candidate second model 116 based at least on the one or more candidate outputs and the training data applied as input to the candidate second model 116; the model updater 108 can use any of a variety of optimization algorithms (e.g., gradient descent, stochastic descent, Adam optimization, etc.) to modify one or more parameters (e.g., weights or biases of the layer(s) of the candidate second model 116 that are not frozen) of the candidate second model 116 according to the evaluation of the objective function; the model updater 108 can select the training data from the data of the data sources 112 to apply as the input based at least on a particular application of the plurality of applications 120 (e.g., product/service recommendation generator application) for which the second model 116 is to be used for; the second model 116 can be coupled with one or more third models, functions, or algorithms for training/configuration and/or runtime operations; the second model 116 can be used to process unstructured information regarding items of equipment into predefined template formats compatible with various third models, such that outputs of the second model 116 can be provided as inputs to the third models; allow more accurate training of the third models, more training data to be generated for the third models, and/or more data available for use by the third models) (Vah, ¶¶ [0072]-[0077] with FIG. 4: a sequence-to-sequence model 400 suitable for use as the first machine learning model to generate recommended troubleshooting actions; the model 400 can work with both character-level inputs and word-level inputs (e.g., by using word embedding); the model 400 includes an embedding layer 401, an encoder 402, a context or state vector 403, a decoder 404, and an output layer 405, wherein each of the encoder 402 and decoder 404 may be implemented as a RNN, including a particular type of RNN such as a LSTM RNN, a Gated Recurrent Unit (GRU) RNN, etc.; symptom tiers, conditions, product platform and other information are fed into the encoder 402 (e.g., as inputs 1 through N) via the embedding layer 401; for the first machine learning model, the encoder 402 outputs a state (e.g., state N) as the context or state vector 403, which provides the input to decoder 404. The decoder 404 predicts repair actions (e.g., as outputs 1 through M) via output layer 405, which may be implemented as a softmax output layer; based at least in part on the outcome of each step in the repair process (e.g., 0 or 1 indicating failure or success, respectively), a decision is made as to whether the input "words" provided to the encoder 402 should be modified for the next step or iteration of the sequence-to-sequence model 400; for new input, the decoder output of the last step (e.g., output M) is added to the last input (e.g., input N); this process is repeated until there is a successful repair, or until the repair process is stopped (e.g., after some designated threshold number of iterations of running the model 400, manual stop by a technician, etc.); if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; adding the negation includes adding "not" to each output of the decoder 404; this indicates that the output of the previous step was a failure (e.g., replacing the output "replace commodity motherboard" of the decoder 404 with "replace_not commodity_not motherboard_not"); the sequence-to-sequence model 400 may be trained using character-level or word-level input; for character-level input, the output of the model 400 is character by character; the model 400 may be trained on a dataset including troubleshooting log entries, historical troubleshooting logs suitably transformed into a format fit for a sequence-to-sequence model, external sources (e.g., discussions on technical communities or support forums suitably transformed into a format fit for a sequence-to-sequence model), and for unsuccessful repair and diagnostic tests, a negation (e.g., the word "_not") is added to the troubleshooting actions; for word-level input, the output of the model 400 is word by word and in this case "word vectors" or "word embeddings" are created by training on the same information as noted above; ¶ [0085] with FIG. 6: the table 600 includes entries of logs of symptom sets, diagnostics and repair actions for a product platform "LAT-7480"; each row of the table 600 is assumed to correspond to output of the first machine learning model, which is supplemented with feedback from the second machine learning model; ¶ [0092] with FIG. 8: the asset information repository 805 may include a database (e.g., a structured query language (SQL) database) with information ( e.g., service tag history, symptoms, latest diagnostics, etc.) for the incoming asset and assets similar to the incoming asset ( e.g., other models of a computing system with the same or similar hardware and software components); information from the asset information repository 805 is passed to a first machine learning model 807 for model training).
Claims 5 and 13
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 1 and 9 respectively and further discloses wherein the training the second AI model for the specific domain from the first generative AI model comprises: executing feature engineering on the non-standard information components of the specific domain; encoding features of the non-standard information components; combining the first generative AI model and the encoded non-standard information components using the available label data to generate the second AI model; and using supervised learning to reduced error of the second Al model from the available label information (Vah, ¶ [0071]: the second machine learning model takes as input information of the given asset being troubleshooted (e.g., asset description such as product platform, symptoms and error descriptions, the recommended troubleshooting action generated by the first machine learning model) and generates an output indicating whether the outcome of the recommended troubleshooting action is desirable or not as per various KPI, wherein the KPIs may include whether a repair action is likely to result in VFF or NFF, whether a diagnostic action is likely to be effective or ineffective, whether a repair or diagnostic action is complex (e.g., time-consuming, requiring special training or knowledge) or trivial, etc.; ¶¶ [0072]-[0077] with FIG. 4: a sequence-to-sequence model 400 suitable for use as the first machine learning model to generate recommended troubleshooting actions; the model 400 can work with both character-level inputs and word-level inputs (e.g., by using word embedding); the model 400 includes an embedding layer 401, an encoder 402, a context or state vector 403, a decoder 404, and an output layer 405, wherein each of the encoder 402 and decoder 404 may be implemented as a RNN, including a particular type of RNN such as a LSTM RNN, a Gated Recurrent Unit (GRU) RNN, etc.; symptom tiers, conditions, product platform and other information are fed into the encoder 402 (e.g., as inputs 1 through N) via the embedding layer 401; for the first machine learning model, the encoder 402 outputs a state (e.g., state N) as the context or state vector 403, which provides the input to decoder 404. The decoder 404 predicts repair actions (e.g., as outputs 1 through M) via output layer 405, which may be implemented as a softmax output layer; based at least in part on the outcome of each step in the repair process (e.g., 0 or 1 indicating failure or success, respectively), a decision is made as to whether the input "words" provided to the encoder 402 should be modified for the next step or iteration of the sequence-to-sequence model 400; for new input, the decoder output of the last step (e.g., output M) is added to the last input (e.g., input N); this process is repeated until there is a successful repair, or until the repair process is stopped (e.g., after some designated threshold number of iterations of running the model 400, manual stop by a technician, etc.); if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; adding the negation includes adding "not" to each output of the decoder 404; this indicates that the output of the previous step was a failure (e.g., replacing the output "replace commodity motherboard" of the decoder 404 with "replace_not commodity_not motherboard_not"); the sequence-to-sequence model 400 may be trained using character-level or word-level input; for character-level input, the output of the model 400 is character by character; the model 400 may be trained on a dataset including troubleshooting log entries, historical troubleshooting logs suitably transformed into a format fit for a sequence-to-sequence model, external sources (e.g., discussions on technical communities or support forums suitably transformed into a format fit for a sequence-to-sequence model), and for unsuccessful repair and diagnostic tests, a negation (e.g., the word "_not") is added to the troubleshooting actions; for word-level input, the output of the model 400 is word by word and in this case "word vectors" or "word embeddings" are created by training on the same information as noted above; ¶¶ [0078]-[0083] with FIG. 5: a sequence-to-sequence model 500 suitable for use as the second machine learning model for pre-screening recommended troubleshooting actions (e.g., generated using the first machine learning model); the model 500 including an embedding layer 501, encoder 502, context vector 503, decoder 504, and output layer 505; the model 500, however, incorporates an attention mechanism represented by elements 506 and 507, wherein the attention mechanism enables the decoder 504 to focus on important input (e.g., highlighted input 1 506) rather than just the context vector 503; the attention mechanism helps the second machine learning model to focus on specific parts of the input to predict suitable KPI values; attention is a mechanism that forces the model 500 to focus on specific parts of the input (e.g., 506) when decoding, instead of relying only on the context vector 503; by incorporating an attention mechanism, the sequence-to-sequence model 500 is able to utilize all of the states 1 through N (e.g., states 1, 2, ... N-1 are not discarded) in order to construct the context vector 503 required by the decoder 504 to generate the output sequence; while predicting the output for a long input sequence, the decoder 504 needs to focus on a few important keywords for each output and not the whole sequence; for each output (1 through M), the decoder 504 pays "attention" to more important input states; to do so, weights are generated and assigned to denote the contribution of each intermediate state of the input encoder 502; unlike the fixed state vector used for all the decoder time steps in the case of a sequence-to-sequence model without attention, the sequence-to-sequence model 500 incorporates the attention mechanism and computes a separate state or context vector 503 for each time step by computing the attention weights at every time step; ¶¶ [0086] and [0089]: the second machine learning model takes as input various details and information in a cumulative fashion, including: a product description or product platform, symptoms and error descriptions, and diagnostic and repair actions predicted by the first machine learning model; the second machine learning model differs from the first machine learning model in that it incorporates an attention mechanism; the attention mechanism of the second machine learning model helps to focus on specific parts of the input to predict suitable KPI values for the troubleshooting actions recommended by the first machine learning model; e.g., the attention mechanism can enable the second machine learning model to pay attention to certain words in its input to predict that a repair action is likely to result in NFF; ¶¶ [0090]-[0091] with FIG. 7: training of the second machine learning model will now be described with respect to the tables 700 and 710 of FIG. 7; the table 700 shows a set of logs, including a repair identifier, a product description, a symptom set, error descriptions, error conditions, action taken, and results, wherein (a) the symptom set in table 700 is shown as a number (e.g., 1) that represents one or more symptoms encountered by an asset (in other embodiments, the symptom set may be represented as one or more columns each indicating a particular symptom encountered by an asset); (b) the error descriptions include tier 1 and tier 2 error descriptions, indicating descriptions and sub-description of errors encountered; (c) the error condition provides additional detail regarding the errors encountered; (d) the action taken field indicates the troubleshooting action or actions taken in attempt to remedy the errors encountered; and (e) the results include tier 1 and tier 2 entries or fields, where the tier 1 result field provides a high-level description of the results of the troubleshooting action taken while the tier 2 result field provides additional detail; the table 700 also has corresponding KPIs filled in (e.g., a repair KPI indicating VFF or NFF, and a diagnostic KPI of effective or ineffective); the input of table 700 is converted to training data with labels as shown in table 710; based on what the last action recommendation is (e.g., a diagnostic action or a repair action), an appropriate KPI label (e.g., the diagnostic KPI or the repair KPI) is passed to the second machine learning model; complex/trivial KPI may be used for both diagnostic and repair actions, and may be used in training of the second machine learning model as part of the label; ¶¶ [0092]-[0093] with FIG. 8: the recommendation engine 809 uses a trained or deployed instance of the first machine learning model 807, along with information passed from the asset information repository 805, to provide troubleshooting action recommendations for the incoming asset; these troubleshooting recommendations are provided from the recommendation engine 809 to a second machine learning model 811 for pre-screening; ¶¶ [0098]-[0099]: various troubleshooting optimizations may be incorporated in machine learning model training, such as considering the quantity of troubleshooting steps versus the total time to resolution (e.g., cases where more troubleshooting steps are needed due to platform or asset complexity, available symptoms, platform to platform feature sets, etc.); additional optimizations may be provided by considering the order and sequence of troubleshooting steps, including identifying critical troubleshooting steps as needed. In addition, erroneous or incomplete troubleshooting steps should be identified to avoid causing errors in machine learning model training) (Malladi, ¶ [0007]: augmenting the at least one generative AI model using training data relating to the plurality of separate domain systems; ¶ [0027]: perform root cause prediction by being trained using data that includes indications of root causes of faults or errors, where the indications are labels for or otherwise associated with (unstructured or structure) data such as service requests, service reports, service calls, etc.; the system can receive, from a service technician in the field evaluating the issue with the equipment, feedback regarding the accuracy of the root cause predictions, as well as feedback regarding how the service technician evaluated information about the equipment (e.g., what data did they evaluate; what did they inspect; did the root cause prediction or instructions for finding the root cause accurately match the type of equipment, etc.), which can be used to update the root cause prediction model; ¶¶ [0045]-[0048] and [0055]-[0057] with FIG. 1: configure the first model 104 to determine one or more second models 116; a model updater 108 that configures (e.g., trains, updates, modifies, fine-tunes, etc.) the first model 104 to determine the one or more second models 116; the second model 116 can be used to provide application-specific outputs, such as outputs having greater precision, accuracy, or other metrics, relative to the first model, for targeted applications; the model updater 108 can provide training data to the first model 104, via the API, to determine the second model 116 based on the first model 104 and the training data; determine relations between data from different sources, such as by using timeseries information and identifiers of the sites or buildings at which items of equipment are present to detect relationships between various different data relating to the items of equipment (e.g., to train the models 104, 116 using both timeseries data ( e.g., sensor data; outputs of algorithms or models, etc.) regarding a given item of equipment and freeform natural language reports regarding the given item of equipment); the data sources 112 can include domain system data which include data relating to the configuration, operation, activation, scope, etc. of various domain systems; e.g. the domain system data can identify the domain systems present at a building, data formats (e.g., protocols, data objects, templates, input requirements, output formats, etc.) used by the domain systems, information relating to application programming interfaces (APIs) used by the domain systems, etc.; domain system data can include logged data of actions taken in different domain systems, for example in a manner such that the data sources 112 can reflect actions taken concurrently in multiple domain systems such that the system 100 can extract information relating to correlation between operations of the domain systems; domain system data can include data in a variety of different formats and relating to various types of information depending on the particular different domain systems included; the system 100 can include, with the data of the data sources 112, labels to facilitate cross-reference between items of data that may relate to common items of equipment, sites, service technicians, customers, or various combinations thereof; e.g., data from disparate sources may be labeled with time data, which can allow the system 100 (e.g., by configuring the models 104, 116) to increase a likelihood of associating information from the disparate sources due to the information being detected or recorded (e.g., as service reports, as actions in a domain system) at the same time or near in time; the data sources 112 can include data that can be particular to specific or similar items of equipment, buildings, equipment configurations, environmental states, or various combinations thereof; the data includes labels or identifiers of such information, such as to indicate locations, weather conditions, timing information, uses of the items of equipment or the buildings or sites at which the items of equipment are present, etc.; this can enable the models 104, 116 to detect patterns of usage (e.g., spikes; troughs; seasonal or other temporal patterns) or other information that may be useful for determining causes of issues or causes of service requests, or predict future issues, such as to allow the models 104, 116 to be trained using information indicative of causes of issues across multiple items of equipment (which may have the same or similar causes even if the data regarding the items of equipment is not identical); e.g., an item of equipment may be at a site that is a museum, and by relating site usage or occupancy data with data regarding the item of equipment, such as sensor data and service reports, the system 100 can configure the models 104, 116 to determine a high likelihood of issues occurring before events associated with high usage (e.g., gala, major exhibit opening), and can generate recommendations to perform diagnostics or servicing prior to the events; ¶¶ [0058]-[0063] and [0065] with FIG. 1: the model updater 108 can perform various machine learning model configuration/ training operations to determine the second models 116 using the data from the data sources 112; e.g., the model updater 108 can perform various updating, optimization, retraining, reconfiguration, fine-tuning, or transfer learning operations, or various combinations thereof, to determine the second models 116; the model updater 108 can configure the second models 116, using the data sources 112, to generate outputs (e.g., completions) in response to receiving inputs (e.g., prompts), where the inputs and outputs can be analogous to data of the data sources 112; the model updater 108 can select at least a subset of the identified one or parameters to maintain according to various criteria, such as user input or other instructions indicative of an extent to which the first model 104 is to be modified to determine the second model 116; responsive to selecting the one or more parameters to maintain, the model updater 108 can apply, as input to the second model 116 (e.g., to a candidate second model 116, such as the modified first model 104, such as the first model 104 having the identified parameters maintained as the identified values), training data from the data sources 112; e.g., the model updater 108 can apply the training data as input to the second model 116 to cause the second model 116 to generate one or more candidate outputs; the model updater 108 can evaluate a convergence condition to modify the candidate second model 116 based at least on the one or more candidate outputs and the training data applied as input to the candidate second model 116; e.g., the model updater 108 can evaluate an objective function of the convergence condition, such as a loss function (e.g., L1 loss, L2 loss, root mean square error, cross-entropy or log loss, etc.) based on the one or more candidate outputs and the training data, which can indicate how closely the candidate outputs generated by the candidate second model 116 correspond to the ground truth represented by the training data; the model updater 108 can use any of a variety of optimization algorithms (e.g., gradient descent, stochastic descent, Adam optimization, etc.) to modify one or more parameters (e.g., weights or biases of the layer( s) of the candidate second model 116 that are not frozen) of the candidate second model 116 according to the evaluation of the objective function; the model updater 108 can use various hyperparameters to evaluate the convergence condition and/or perform the configuration of the candidate second model 116 to determine the second model 116, including hyperparameters such as learning rates, numbers of iterations or epochs of training, etc.; the model updater 108 can select the training data from the data of the data sources 112 to apply as the input based at least on a particular application of the plurality of applications 120 (e.g., the product recommendation generator application, or the service recommendation generator application) for which the second model 116 is to be used for; the system 100 can use classifiers associated with the data, such as identifiers of the item of equipment, a type of the item of equipment, a type of entity operating the item of equipment, a site at which the item of equipment is provided, or a history of issues at the site, to condition the training of the second model 116; the system 100 combine (e.g., concatenate) various such classifiers with the data for inputting to the second model 116 during training, for at least a subset of the data used to configure the second model 116, which can enable the second model 116 to be responsive to analogous information for runtime/inference time operations; use the second model 116 (which can be trained to cross-reference metadata in different portions of inputs and relate together data elements) to generate output reports (e.g., the second model 116, having been configured with data that includes time information, can use timestamps of input from dictation and timestamps of when an image is taken, and place the image in the report in a target position or label based on time correlation); ¶¶ [0074]-[0079] with FIG. 1: use the feedback trainer 128 to increase the precision and/or accuracy of the outputs generated by the second models 116 according to feedback provided by users of the system 100 and/or the applications 120; the feedback trainer 128 can update the one or more second models 116 using the feedback; the feedback trainer 128 can be similar to the model updater 108; the feedback trainer 128 can perform various configuration operations (e.g., retraining, fine-tuning, transfer learning, etc.) on the second models 116 using the feedback from the feedback repository 124; the feedback trainer 128 identifies one or more first parameters of the second model 116 to maintain as having predetermined values (e.g., freeze the weights and/or biases of one or more first layers of the second model 116), and performs a training process, such as a fine tuning process, to configure parameters of one or more second parameters of the second model 116 using the feedback (e.g., one or more second layers of the second model 116, such as output layers or output heads of the second model 116); the second model 116 can be coupled with one or more third models, functions, or algorithms for training/configuration and/or runtime operations; the third models can include any of various models relating to items of equipment, such as energy usage models, sustainability models, carbon models, air quality models, or occupant comfort models; e.g., the second model 116 can be used to process unstructured information regarding items of equipment into predefined template formats compatible with various third models, such that outputs of the second model 116 can be provided as inputs to the third models; this can allow more accurate training of the third models, more training data to be generated for the third models, and/or more data available for use by the third models; the second model 116 can receive inputs from one or more third models, which can provide greater data to the second model 116 for processing; ¶¶ [0089]-[0095] with FIGS. 1 and 2: the training management system 240 can include one or more rules, heuristics, logic, policies, algorithms, functions, machine learning models, neural networks, scripts, or various combinations thereof to perform operations including controlling training of machine learning models, including performing fine tuning and/or transfer learning operations; the training management system 240 can include a training manager 244 which can incorporate features of at least one of the model updater 108 or the feedback trainer 128; e.g., the training manager 244 can provide training data including a plurality of training data elements (e.g., prompts and corresponding completions) to the model system 260 as described further herein to facilitate training machine learning models; apply training data (e.g., prompts 248 and corresponding completions) to the machine learning models 268 to configure ( e.g., train, modify, update, fine-tune, etc.) the machine learning models 268; ¶¶ [0103]-[0108] with FIGS. 1-2 and 4: a feedback system 400, such as a feedback aggregator, can include one or more rules, heuristics, logic, policies, algorithms, functions, machine learning models, neural networks, scripts, or various combinations thereof to perform operations including preparing data for updating and/or updating the machine learning models 268 using feedback corresponding to the application sessions 308, such as feedback received as user input associated with outputs presented by the application sessions 308; The feedback system 400 can incorporate features of the feedback repository 124 and/or feedback trainer 128; the pre-processor 400 can perform any of various operations to modify the feedback for further processing; the bias checker 408 can evaluate the feedback using various bias criteria, and control inclusion of the feedback in a feedback database 416 (e.g., a feedback database 416 of the data repository 204 as depicted in FIG. 4) according to the evaluation; the feedback system 400 can include a feedback encoder 412 which process the feedback (e.g., responsive to bias checking by the bias checker 408) for inclusion in the feedback database 416; e.g., the feedback encoder 412 can encode the feedback as values corresponding to outputs scoring determined by the model system 260 while generating completions (e.g., where the feedback indicates that the completion presented via the application session 308 was acceptable, the feedback encoder 412 can encode the feedback by associating the feedback with the completion and assigning a relatively high score to the completion); the feedback can be used by the prompt management system 228 and training management system 240 to further update one or more machine learning models 268; the prompt management system 228 can retrieve at least one feedback (and corresponding prompt and completion data) from the feedback database 416, and process the at least one feedback to determine a feedback prompt and feedback completion to provide to the training management system 240 (e.g., using pre-processor 232 and/or prompt generator 236, and assigning a score corresponding to the feedback to the feedback completion); the training manager 244 can provide instructions to the model system 260 to update the machine learning models 268 using the feedback prompt and the feedback completion, such as to perform a fine-tuning process using the feedback prompt and the feedback completion; the training management system 240 performs a batch process of feedback-based fine tuning by using the prompt management system 228 to generate a plurality of feedback prompts and a plurality of feedback completion, and providing instructions to the model system 260 to perform the fine-tuning process using the plurality of feedback prompts and the plurality of feedback completions; ¶¶ [0141]-[0156] with FIGS. 9-10: providing a building copilot that uses at least one AI model (e.g., generative AI model) to coordinate operations of multiple building domain systems based on conversational input from a user; the copilot 902 includes a recommender 918, effect predictor 920, and output generator 922 which can be implemented using at least one AI model (e.g., separate model(s) for each of the recommender 918, effect predictor 920, and output generator 922, a unified model or set of models that integrally provides the recommender 918, effect predictor 920, and output generator 922, etc.); one or more generative AI models according to the teachings herein can be used to provide the operations of the recommender 918, the effect predictor 920, and the output generator 922; a large language model is augmented with additional models, pre-processing algorithms, post-processing algorithms, feature generation algorithms, etc. in order to provide an augmented model tuned to provide the features of the copilot 902; the recommender 918 can use at least one AI model (e.g., generative AI model) to generate an action to be taken responsive to the user query (e.g., a change in settings to reduce energy consumption, a particular maintenance task to perform, a control decision to prepare a space for an event, a message to be provided to occupants, etc.); the effector predictor 920 can generate an indication of effects on other domain systems (e.g., an HVAC system, an access control system, a room reservation system) that may be indirectly affected by the action (e.g., conducting equipment maintenance can involve providing a technician with access to a space, HVAC equipment may be maintained as part of the maintenance action and/or may need to operate to enable the maintenance or compensate for equipment being off-line during maintenance, a room reserved for occupant use may become uncomfortable while maintenance is performed or may be needed by the technician, etc.); the effect predictor 920 can use generative artificial intelligence according to the teachings above to predict ( e.g., generate) a list of other domain systems that will be affected by the recommended action and identify such effects, consequences, etc. of the recommended action; the output generator 922 is configured generate, using at least one generative AI model, control outputs (control signals, prompts, instructions, control logic, computer code, etc.) for the multiple domain systems for implementing the recommended action and for proactively accounting for the effects of the recommended action determined by operation of the recommender 918 and the effect predictor 920; the recommender 918 can use at least one generative AI model to determine an action to be taken in domain system A 906 to address the user's query; the effect predictor 920 can then use the at least one generative AI model to predict that the domain system B 908 and the domain system 910 will be impacted by the action to be taken in domain system A 906 and/or otherwise indirectly, tangentially, or also are involved in fully responding to the user query; the output generator 922 can then use the at least one generative AI model to generate a first control output for domain system A 906 in a first data format compatible with API A 912, a second control output for domain system B 908 in a second data format compatible with API B 914, and a third control output for domain system Ω in a third data format compatible with API Ω 916; by use of at least one generative AI model as described above, the copilot 902 can be automatically adaptive to learning, from the data lake 924, interrelationships between domain systems 906-910 and desired user interoperation of domain systems 906-910 to provide an easily-deployable, flexible, scalable, seamless (from a user's perspective) copilot 902 to assist users (e.g., occupants, building managers, etc.) in achieving desired building outcomes (e.g., behaviors, conditions, consumption goals, emissions targets, etc.) without requiring such users to reach separately into multiple domain systems).
Claims 6 and 14
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 1 and 9 respectively and further discloses wherein the fine-tuning the second AI model comprises: deploying the second Al model for a period of time; collecting model predictions of the second Al model and actual repairs conducted during the period of time; determining preference attributes of the specific domain from the actual repairs; training a reward model using the model predictions, the actual repairs conducted, and the preference attributes; and fine-tuning the second Al model from the reward generated from the reward model (Vah, ¶¶ [0052]-[0061] with 212 in FIG. 2: responsive to determining that the recommended troubleshooting action is associated with at least one policy from the policy database, at least one policy is applied to determine whether to perform the recommended troubleshooting action (e.g., proceed to step 210) or modify the recommended troubleshooting action (e.g., proceed to step 212)); responsive to determining that the predicted success of the recommended troubleshooting action does not meet the one or more designated criteria; ria, the recommended troubleshooting action is modified in step 212; modifying the recommended troubleshooting action in step 212 may comprise providing the obtained information regarding the given asset and feedback regarding the recommended troubleshooting action as input to the first machine learning model and receiving, from the decoder of the first machine learning model, the modified recommended troubleshooting action; utilize machine learning to predict troubleshooting actions (e.g., diagnostic actions, repair actions, etc.) for a particular asset (e.g., a computing device such as a laptop), where the machine learning model bases predictions on correct repair decisions (e.g., where a part of the laptop or other computing device is replaced by a technician and later found to be defective in screening, or categorized as verified fault found (VFF)); in this manner, the machine learning model learns from correct repair decisions but not incorrect repair decisions (e.g., where a "good" part of the laptop or other computing device is needlessly replaced and categorized as no fault found (NFF)); incorporate such feedback (e.g., from both correct and incorrect repair and diagnostic decisions) to improve a system for troubleshooting computing devices or other types of assets; troubleshooting re-work may be a result of waste (e.g., from replacing good parts unnecessarily), incorrect troubleshooting, etc.; such troubleshooting re-work can be a significant cost to an enterprise, in terms of time consumed, money spent, etc. ; troubleshooting re-work costs may be measured through various key performance indicators (KPIs), in terms of labor inefficiencies, parts waste, inappropriate use of diagnostics, customer returns within some designated threshold time of repair (e.g., 28 days) also referred to as repeat dispatch rate (RDR), etc.; link troubleshooting action predictions from a machine learning model with various KPIs (e.g., percentage of screened parts resulting in VFF /NFF, percentage of most effective diagnostics, percentage of assets returned to a repair center within a designated time period such as 28 days, etc.); in this way, troubleshooting action recommendations may be optimized or improved to reduce the amount of troubleshooting re-work; extend or complement a troubleshooting recommendation system with a machine learning model that factors both correct and incorrect troubleshooting decisions into troubleshooting recommendations produced by the troubleshooting recommendation system; the troubleshooting recommendation system utilizes a first machine learning model to generate troubleshooting action recommendations, and that the troubleshooting recommendation system is extended with a second machine learning model that factors in both correct and incorrect troubleshooting decisions into the troubleshooting action recommendations from the first machine learning model; advantageously, the second machine learning model may be configured to consider various rules or policies, and to present warnings or other notifications to technicians performing troubleshooting as desired; the second machine learning model utilizes a RNN architecture such as a LSTM-based sequence-to-sequence model with an attention mechanism; the second machine learning model factors in KPIs (e.g., whether replaced parts are good/NFF or bad/VFF, whether diagnostic actions are effective or ineffective, etc.) into a sequence-to-sequence based model to avoid the prediction of undesirable troubleshooting actions (e.g., repair solutions resulting in replaced parts that are good/NFF, diagnostics solutions that are ineffective, etc.); the pre-screening process may result in two decisions: (a) whether or not the recommended troubleshooting action provided by the first machine learning model satisfies some designated threshold prediction of success (e.g., determined based at least in part utilizing a confidence score for the recommended troubleshooting action); and (b) whether or not the recommended troubleshooting action provided by the first machine learning model satisfies desirable outcomes based at least in part on KPIs (e.g., VFF/NFF, cumbersome/lean, complex/trivial, repair yield, RDR, etc.); if the prescreening outcome does not meet one or both of these conditions, the recommended troubleshooting action may be altered or supplemented based on one or more rules or policies (e.g., the recommended troubleshooting action may be overridden with an alternate recommendation based on the rules or policies, the recommended troubleshooting action may be accepted based on the rules or policies, etc.); the rules or policies may be based on historical feedback data for previous troubleshooting processes for similar assets, based on expert knowledge, etc.; if no rules or policies are present for handling a particular recommended troubleshooting action, the recommended troubleshooting action may be presented to the technician along with a notification (e.g., a warning) that an undesirable outcome is likely to result from implementing the recommended troubleshooting action; ¶¶ [0062]-[0071] with FIGS. 3A-D: the step 307 determination is a prediction for one or more KPIs associated with the recommended repair action; e.g., step 307 may be viewed as determining whether the recommended repair action is likely to result in VFF (e.g., proceed to step 308) or NFF (e.g., proceed to step 310); the step 312 determination is a prediction for one or more KPIs associated with the recommended diagnostic action; e.g., step 312 may be viewed as determining whether the recommended diagnostic action is likely to be effective (e.g., proceed to step 313) or ineffective (e.g., proceed to step 310); in step 314, the diagnosis for the given asset is confirmed (e.g., the diagnostic results are analyzed to determine if the problem with the given asset has been successfully diagnosed); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); in step 309, the repair is completed and the given asset is analyzed (e.g., to determine whether the recommended repair action was successful); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); in step 310, a determination is made as to whether any rule or policy exists for the recommended repair or diagnostic action; various types of rules or policies may be used; e.g., a rule or policy may be based on characteristics of the given asset that is being troubleshooted; such characteristics may include a type of the given asset (e.g., a product platform of the given asset), a priority of the given asset, an age of the given asset or components thereof, whether the given asset has been to the enterprise repair center recently (e.g., whether the given asset is categorized as repeat repair), etc.; such characteristics may affect whether certain types of diagnostic or repair actions should or should not be performed; e.g., (a) if a storage device of a given asset is old (e.g., as defined by some threshold age), it may be determined that it is more cost-effective to replace the storage device rather than run lengthy diagnostic tests to confirm failure of the storage device; and (b) if a repair action recommends replacing a comparatively expensive part of a computing device such as the motherboard and the motherboard is new (e.g., as defined by some threshold age), it may be determined that it is more cost-effective to run additional diagnostics than to replace the motherboard; if no rule or policy exists in step 310, a notification is generated in step 315 indicating that the recommended repair or diagnostic action is likely to result in an undesirable outcome (e.g., that the predicted success of the recommended repair or diagnostic action is below a designated threshold); this notification may be provided to the user that requested the recommended troubleshooting action in step 302 or alternatively be provided to various other users; e.g., the user requesting the recommended troubleshooting action in step 302 may be a technician, and the notification may be sent to the technician as well as to a supervisor of that technician, or to quality control staff of a repair center responsible for analyzing the efficiency of troubleshooting actions, wherein the technician, supervisor or quality control staff utilizes the notification to create new rules or policies, or modify existing rules or policies, for future recommended troubleshooting actions (e.g., to create a new rule or policy, or modify an existing rule or policy, when the recommended troubleshooting action ultimately ends up being successful); if a rule or policy exists in step 310, that rule or policy is applied and feedback is generated regarding the recommended repair or diagnostic action in step 316; such feedback is provided to the expert troubleshooting system 301 in path 1 (e.g., to the first machine learning model used in step 303); such feedback may also be utilized to create new rules or policies, or modify existing rules or policies, for future recommended troubleshooting actions; the first machine learning model provides high-level functions of generating recommended troubleshooting actions (e.g., repair actions, diagnostic actions, etc.); the second machine learning model takes as input information of the given asset being troubleshooted (e.g., asset description such as product platform, symptoms and error descriptions, the recommended troubleshooting action generated by the first machine learning model) and generates an output indicating whether the outcome of the recommended troubleshooting action is desirable or not as per various KPIs, wherein the KPIs may include whether a repair action is likely to result in VFF or NFF, whether a diagnostic action is likely to be effective or ineffective, whether a repair or diagnostic action is complex (e.g., time-consuming, requiring special training or knowledge) or trivial, etc.; ¶ [0085]-[0091] with FIGS. 6-7: the table 600 includes entries of logs of symptom sets, diagnostics and repair actions for a product platform "LAT-7480"; each row of the table 600 is assumed to correspond to output of the first machine learning model, which is supplemented with feedback from the second machine learning model; the second machine learning model takes as input various details and information in a cumulative fashion, including: a product description or product platform, symptoms and error descriptions, and diagnostic and repair actions predicted by the first machine learning model; the second machine learning model output indicates whether the outcome of the diagnostic or repair action recommended by the first machine learning model is desirable or not, as measured using one or more KPIs (e.g., VFF or NFF, effective or ineffective diagnostic, complex or trivial diagnostics or repairs, etc.); in a first iteration, the first machine learning model (e.g., model 400) outputs the recommended repair action of "replace commodity memory" and the second machine learning model (e.g., model 500) predicts that the recommended repair action will result in NFF; accordingly, the repair action of "replace commodity memory" is flagged as undesirable (e.g., likely to result in NFF); it is further assumed in this example that there is no rule or policy available, and thus the system may (but is not required) to display a warning or notification to the technician indicating that the recommended repair action is not likely to be successful; feedback is then routed to the input of the first machine learning model (e.g., model 400), where the feedback may be "replace commodity memory-NFF"; in a second iteration, the first machine learning model (e.g., model 400), uses feedback from the first iteration, and provides a new recommended repair action of "reseat commodity memory"; the second machine learning model (e.g., model 500) predicts that this recommended repair action will result in VFF (e.g., the electrical interconnects are cleaned during the re-seat of the memory, solving the symptom set); accordingly, the repair action of "reseat commodity memory" is flagged as desirable (e.g., likely to result in VFF); the technician will perform the recommended repair action, which is assumed to result in a successful outcome; feedback is then routed to the input of the first machine learning model (e.g., model 400), where the feedback may be "reseat commodity memory-VFF"; the attention mechanism of the second machine learning model helps to focus on specific parts of the input to predict suitable KPI values for the troubleshooting actions recommended by the first machine learning model; as the input can become lengthy in some cases (e.g., where multiple diagnostic and repairs steps are involved in troubleshooting an asset), the attention mechanism focuses the input; e.g., the attention mechanism can enable the second machine learning model to pay attention to certain words in its input to predict that a repair action is likely to result in NFF; training of the second machine learning model will now be described with respect to the tables 700 and 710 of FIG. 7; the table 700 shows a set of logs, including a repair identifier, a product description, a symptom set, error descriptions, error conditions, action taken, and results, wherein (a) the symptom set in table 700 is shown as a number (e.g., 1) that represents one or more symptoms encountered by an asset or the symptom set may be represented as one or more columns each indicating a particular symptom encountered by an asset; (b) the error descriptions include tier 1 and tier 2 error descriptions, where the tier 1 and tier 2 may indicate descriptions and sub-description of errors encountered; (c) the error condition provides additional detail regarding the errors encountered; (d) the action taken field indicates the troubleshooting action or actions taken in attempt to remedy the errors encountered; and (e) the results, similar to the error descriptions, include tier 1 and tier 2 entries or fields, where the tier 1 result field provides a high-level description of the results of the troubleshooting action taken while the tier 2 result field provides additional detail; the table 700 also has corresponding KPIs filled in (e.g., a repair KPI indicating VFF or NFF, and a diagnostic KPI of effective or ineffective); the input of table 700 is converted to training data with labels as shown in table 710; based on what the last action recommendation is (e.g., a diagnostic action or a repair action), an appropriate KPI label (e.g., the diagnostic KPI or the repair KPI) is passed to the second machine learning model; multiple KPIs may be used for one or both of diagnostic and repair actions; e.g., an additional KPI may be whether the recommended troubleshooting action is complex or trivial (e.g., in terms of skill required to implement, time required to implement, combinations thereof, etc.); this complex/trivial KPI may be used for both diagnostic and repair actions, and may be used in training of the second machine learning model as part of the label; ¶¶ [0092]-[0097] with FIG. 8: in block 813, a determination is made as to whether the recommended troubleshooting action meets a confidence score (e.g., that the recommended troubleshooting action is likely to be successful); if the result of block 813 is yes, feedback is provided to the recommendation engine 809 to initiate application of the recommended troubleshooting action; if the result of block 813 is no, the flow moves to block 815 where a determination is made as to whether any rule or policy exists to cover the recommended troubleshooting action for the incoming asset; if the result of block 815 is yes, then appropriate feedback is provided to the recommendation engine 809; this feedback may cause the recommendation engine 809 to re-invoke the first machine learning model 807 to obtain a new recommended troubleshooting action without applying the previous recommended troubleshooting action; this feedback may alternatively cause the recommendation engine 809 to initiate application of the recommended troubleshooting action; the feedback will vary based on the particular rule or policy being applied; e.g., a rule or policy may specify that the recommended troubleshooting action will be applied if it is an inexpensive diagnostic action, but that a new recommendation should be received if the recommended troubleshooting action is an expensive repair action (e.g., where expensive and inexpensive may be determined according to various thresholds, such as time, skill or expertise needed to implement, cost of parts, etc.); if the result of block 815 is no, the flow may proceed to displaying a warning or other notification via a guidance interface 817 (e.g., which may provide a graphical user interface) that is invoked by a technician at the repair depot (e.g., to obtain recommended troubleshooting actions, to input or log results of troubleshooting actions that are taken, to receive instructions for performing troubleshooting actions, etc.); if the result of block 819 determination is yes, the repair action is performed in block 821; in block 823, it is determined whether the asset is fixed by the repair action performed in block 821; if the result of the block 823 determination is yes, the troubleshooting is complete and the incoming asset 801 is converted to an outgoing asset 825 that leaves the repair depot (e.g., the asset is returned to the customer or other end-user); feedback may also be provided to the first machine learning model 807 and second machine learning model 811 via the recommendation engine 809; if the result of the block 823 determination is no, feedback is provided to the guidance interface 817 for technician analysis 827; the guidance interface 817 is used by the technician performing troubleshooting of the asset to log the repair action taken, to report results of the repair action, to provide instruction to the technician on how to perform the repair action, etc.; the feedback may also be provided by the guidance interface 817 to the first machine learning model 807 and the second machine learning model 811 via the recommendation engine 809; if the result of the block 819 determination is no (e.g., the recommended troubleshooting action is a diagnostic action), the diagnostic action is performed on the asset (e.g., automatically such as by running test software on the asset, manually by a technician inspecting parts, etc.); the results of the diagnostic action are then analyzed by the technician in block 827; the technician may utilize the guidance interface 817 to log the diagnostic action taken, report results of the diagnostic action, etc.; the guidance interface 817 provides feedback to the first machine learning model 807 and second machine learning model 811 regarding the diagnostic actions via the recommendation engine 809; such diagnostic action feedback, as well as the repair action feedback discussed above, may also be stored in the asset information repository 805) (Malladi, ¶¶ [0027]-[0028] and [0032]: perform root cause prediction by being trained using data that includes indications of root causes of faults or errors, where the indications are labels for or otherwise associated with (unstructured or structure) data such as service requests, service reports, service calls, etc.; the system can receive, from a service technician in the field evaluating the issue with the equipment, feedback regarding the accuracy of the root cause predictions, as well as feedback regarding how the service technician evaluated information about the equipment (e.g., what data did they evaluate; what did they inspect; did the root cause prediction or instructions for finding the root cause accurately match the type of equipment, etc.), which can be used to update the root cause prediction model; a platform for fault detection and servicing processes in which a machine learning model is configured based on connecting or relating unstructured data and/or semantic data, such as human feedback and written/spoken reports, with time-series product data regarding items of equipment, so that the machine learning model can more accurately detect causes of alarms or other events that may trigger service responses; e.g., responsive to an alarm for a chiller, the system can more accurately detect a cause of the alarm, and generate a prescription (e.g., for a service technician) for responding to the alarm; the system can request feedback from the service technician regarding the prescription, such as whether the prescription correctly identified the cause of the alarm and/or actions to perform to respond to the cause, as well as the information that the service technician used to evaluate the correctness or accuracy of the prescription; the system can use this feedback to modify the machine learning models, which can increase the accuracy of the machine learning models; the system can be used to automate interventions for equipment operation, servicing, fault detection and diagnostics (FDD), and alerting operations; e.g., by being configured to perform operations such as root cause prediction, the system can monitor data regarding equipment to predict events associated with faults and trigger responses such as alerts, service scheduling, and initiating FDD or modifications to configuration of the equipment; the system can present to a technician or manager of the equipment a report regarding the intervention (e.g., action taken responsive to predicting a fault or root cause condition) and requesting feedback regarding the accuracy of the intervention, which can be used to update the machine learning models to more accurately generate interventions; ¶¶ [0034] and [0043]-[0047] with FIG. 1: configuring (e.g., training, updating, modifying, transfer learning, fine-tuning, etc.) and/or operating various AI and/or ML systems, such as neural networks of LLMs or other generative AI systems; the training data can include human-labeled information, including but not limited to feedback regarding outputs of the models 104, 116, which can allow the system 100 to generate more human-like outputs; a model updater 108 configures (e.g., trains, updates, modifies, fine-tunes, etc.) the first model 104 to determine the one or more second models 116; the second model 116 can be used to provide application-specific outputs, such as outputs having greater precision, accuracy, or other metrics, relative to the first model, for targeted applications; the model updater 108 can perform operations on at least one of the first model 104 or the second model 116 via one or more interfaces, such as application programming interfaces (APIs); e.g., the model updater 108 can provide training data to the first model 104, via the API, to determine the second model 116 based on the first model 104 and the training data; the model updater 108 can control various training parameters or hyperparameters (e.g., learning rates, etc.) by providing instructions via the API to manage configuring the second model 116 using the first model 104; ¶¶ [0074]-[0078] with FIG. 1: use the feedback trainer 128 to increase the precision and/or accuracy of the outputs generated by the second models 116 according to feedback provided by users of the system 100 and/or the applications 120; present one or more user input elements for receiving feedback regarding the outputs; the user input elements can include, e.g., (a) indications of binary feedback regarding the outputs (e.g., good/bad feedback; feedback indicating the outputs do or do not meet the user's criteria, such as criteria regarding technical accuracy or precision); (b) indications of multiple levels of feedback (e.g., scoring the outputs on a predetermined scale, such as a 1-5 scale or 1-10 scale); and (c) freeform feedback (e.g., text or audio feedback); or various combinations thereof; stores the feedback with one or more data elements associated with the feedback, including the outputs for which the feedback was received, the second model(s) 116 used to generate the outputs, and/or input information used by the second models 116 to generate the outputs (e.g., service request information; information captured by the user regarding the item of equipment); the feedback trainer 128 can update the one or more second models 116 using the feedback; the feedback trainer 128 can be similar to the model updater 108; the model updater 108 can include or be coupled with the feedback trainer 128; the feedback trainer 128 can perform various configuration operations ( e.g., retraining, fine-tuning, transfer learning, etc.) on the second models 116 using the feedback from the feedback repository 124; the feedback trainer 128 identifies one or more first parameters of the second model 116 to maintain as having predetermined values (e.g., freeze the weights and/or biases of one or more first layers of the second model 116), and performs a training process, such as a fine tuning process, to configure parameters of one or more second parameters of the second model 116 using the feedback (e.g., one or more second layers of the second model 116, such as output layers or output heads of the second model 116); ¶¶ [0103]-[0108] and [0112] with FIGS. 1-2 and 4: a feedback system 400, such as a feedback aggregator, can include one or more rules, heuristics, logic, policies, algorithms, functions, machine learning models, neural networks, scripts, or various combinations thereof to perform operations including preparing data for updating and/or updating the machine learning models 268 using feedback corresponding to the application sessions 308, such as feedback received as user input associated with outputs presented by the application sessions 308; the feedback system 400 can receive feedback (e.g., from the client device 304) in various formats; e.g., the feedback can include any of text, speech, audio, image, and/or video data; the feedback can be associated (e.g., in a data structure generated by the application session 308) with the outputs of the machine learning models 268 for which the feedback is provided; the feedback can be received or extracted from various forms of data, including external data sources such as manuals, service reports, or Wikipedia-type documentation; the pre-processor 400 can perform any of various operations to modify the feedback for further processing; e.g., the pre-processor 400 can incorporate features of, or be implemented by, the pre-processor 232, such as to perform operations including filtering, compression, tokenizing, or translation operations ( e.g., translation into a common language of the data of the data repository 204); the bias checker 408 can evaluate the feedback using various bias criteria, and control inclusion of the feedback in a feedback database 416 (e.g., a feedback database 416 of the data repository 204 as depicted in FIG. 4) according to the evaluation; the bias criteria can include criteria regarding qualitative and/or quantitative differences between a range or statistic measure of the feedback relative to actual, expected, or validated values; the feedback system 400 can include a feedback encoder 412. The feedback encoder 412 can process the feedback (e.g., responsive to bias checking by the bias checker 408) for inclusion in the feedback database 416; e.g., the feedback encoder 412 can encode the feedback as values corresponding to outputs scoring determined by the model system 260 while generating completions (e.g., where the feedback indicates that the completion presented via the application session 308 was acceptable, the feedback encoder 412 can encode the feedback by associating the feedback with the completion and assigning a relatively high score to the completion); the feedback can be used by the prompt management system 228 and training management system 240 to further update one or more machine learning models 268; e.g., the prompt management system 228 can retrieve at least one feedback (and corresponding prompt and completion data) from the feedback database 416, and process the at least one feedback to determine a feedback prompt and feedback completion to provide to the training management system 240 (e.g., using pre-processor 232 and/or prompt generator 236, and assigning a score corresponding to the feedback to the feedback completion); the training manager 244 can provide instructions to the model system 260 to update the machine learning models 268 using the feedback prompt and the feedback completion, such as to perform a fine-tuning process using the feedback prompt and the feedback completion; the training management system 240 performs a batch process of feedback-based fine tuning by using the prompt management system 228 to generate a plurality of feedback prompts and a plurality of feedback completion, and providing instructions to the model system 260 to perform the fine-tuning process using the plurality of feedback prompts and the plurality of feedback completions; the system 200 can determine the thresholds using the feedback system 400 and/or the client device 304, such as by providing a request for feedback that includes a request for a corresponding threshold associated with the completion and/or prompt presented by the application session 308; e.g., the system 200 can use the feedback to identify realistic thresholds, such as by using feedback regarding data generated by the machine learning models 268 for ranges, setpoints, and/or start-up or operating sequences regarding items of equipment (and which can thus be validated by human experts); the system 200 selectively requests feedback indicative of thresholds based on an identifier of a user of the application session 308, such as to selectively request feedback from users having predetermined levels of expertise and/or assign weights to feedback according to criteria such as levels of expertise; ¶¶ [0123]-[0125] with FIGS. 2 and 7: an expert filter collision system 700 ("expert system" 700) can facilitate providing feedback and providing more accurate and/or precise data and completions to a user via the application session 308; via the expert session 708, the expert session 700 can enable functions such as receiving inputs for a human expert to provide feedback to a user of the client device 304; a human expert to guide the user through the data (e.g., completions) provided to the client device 304, such as reports, insights, and action items; a human expert to review and/or provide feedback for revising insights, guidance, and recommendations before being presented by the application session 308; a human expert to adjust and/or validate insights or recommendations before they are viewed or used for actions by the user; or various combinations thereof; the expert system 700 can use feedback received via the expert session as inputs to update the machine learning models 268 (e.g., to perform fine-tuning); the expert system 700 retrieves data to be provided to the application session 308, such as completions generated by the machine learning models 268; the expert system 700 can present the data via the expert session 708, such as to request feedback regarding the data from the client device 704; e.g., the expert system 700 can receive feedback regarding the data for modifying or validating the data (e.g., editing or validating completions). In some implementations, the expert system 700 requests at least one of an identifier or a credential of a user of the client device 704 prior to providing the data to the client device 704 and/or requesting feedback regarding the data from the expert session 708; e.g., the expert system 700 can request the feedback responsive to determining that the at least one of the identifier or the credential satisfies a target value for the data; this can allow the expert system 708 to selectively identify experts to use for monitoring and validating the data; the expert session 700, responsive to detecting presentation of the data via the application session 308, can request feedback regarding the data (e.g., user input via the application session 308 for feedback regarding the data), and provide the feedback to the client device 704 to present via the expert session 708; the expert session 708 can receive expert feedback regarding at least one of the data or the feedback from the user to provide to the application session 308; allow the expert system 700 to provide a platform for a user receiving the data (e.g., customer or field technician) to receive expert feedback from a user of the client device 704 (e.g., expert technician)).
Claims 8 and 16
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 1 and 9 respectively and further discloses wherein the available label data comprises repair codes indicative of a system to be repaired and a repair action associated with the system to be repaired (Vah, ¶¶ [0085]-[0091] with FIGS. 6-7: the table 600 includes entries of logs of symptom sets, diagnostics and repair actions for a product platform "LAT-7480"; each row of the table 600 is assumed to correspond to output of the first machine learning model, which is supplemented with feedback from the second machine learning model; the second machine learning model takes as input various details and information in a cumulative fashion, including: a product description or product platform, symptoms and error descriptions, and diagnostic and repair actions predicted by the first machine learning model; the second machine learning model output indicates whether the outcome of the diagnostic or repair action recommended by the first machine learning model is desirable or not, as measured using one or more KPIs (e.g., VFF or NFF, effective or ineffective diagnostic, complex or trivial diagnostics or repairs, etc.); the attention mechanism of the second machine learning model helps to focus on specific parts of the input to predict suitable KPI values for the troubleshooting actions recommended by the first machine learning model; training of the second machine learning model will now be described with respect to the tables 700 and 710 of FIG. 7; the table 700 shows a set of logs, including a repair identifier, a product description, a symptom set, error descriptions, error conditions, action taken, and results, wherein (a) the symptom set in table 700 is shown as a number (e.g., 1) that represents one or more symptoms encountered by an asset (in other embodiments, the symptom set may be represented as one or more columns each indicating a particular symptom encountered by an asset); (b) the error descriptions include tier 1 and tier 2 error descriptions, indicating descriptions and sub-description of errors encountered; (c) the error condition provides additional detail regarding the errors encountered; (d) the action taken field indicates the troubleshooting action or actions taken in attempt to remedy the errors encountered; and (e) the results include tier 1 and tier 2 entries or fields, where the tier 1 result field provides a high-level description of the results of the troubleshooting action taken while the tier 2 result field provides additional detail; the table 700 also has corresponding KPIs filled in (e.g., a repair KPI indicating VFF or NFF, and a diagnostic KPI of effective or ineffective); the input of table 700 is converted to training data with labels as shown in table 710; based on what the last action recommendation is (e.g., a diagnostic action or a repair action), an appropriate KPI label (e.g., the diagnostic KPI or the repair KPI) is passed to the second machine learning model; complex/trivial KPI may be used for both diagnostic and repair actions, and may be used in training of the second machine learning model as part of the label).
Claim 18
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claim 1 and further discloses wherein the standard information components comprise fault codes following industry standards (Vah, ¶ [0071]: the second machine learning model takes as input information of the given asset being troubleshooted (e.g., asset description such as product platform, symptoms and error descriptions/codes, the recommended troubleshooting action generated by the first machine learning model); ¶ [0085] with FIG. 6: the table 600 includes entries of logs of symptom sets, diagnostics and repair actions for a product platform "LAT-7480.") (Chen'2020, Section IV with FIGS. 3 and 5 and Tables II-III and VI-VII of Pages 87078711: bearing test rig and related fault types are shown in Fig. 3; three bearing rotating speeds of 800 rpm, 1100 rpm, and 1400 rpm are used to simulate different running conditions; there are a total of three types of bearing health condition set: a) the health condition; b) the inner race fault condition; and c) the outer race fault condition; all the bearing faults are generated using an electro-discharge machine with defect diameters of 0.5 and 2 mm; therefore, five bearing conditions under three speeds are used for experimental evaluation; details on the data set are presented in Table II; from the transfer tasks, it can be found that the target tasks not only cover different operating conditions but also contain different fault severity levels; therefore, it is a challenge to implement DA across domains and conduct fault classification of different health conditions; a gearbox data set has been collected from a five-shift automobile transmission gearbox, shown in Fig. 5; three different shaft speeds, namely, 750 rpm, 1000 rpm, and 1250 rpm are implemented; gear faults and bearing inner race faults have been introduced using electro-discharge machining; a total of six health conditions have been generated to simulate various fault types: the normal condition, the minor chipped tooth, the missing tooth, the bearing inner race fault with 0.2-mm defect, and two compound faults combining gears and bearings; the detailed information on the gearbox data set is presented in Table VI)
Claim 19
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claim 1 and further discloses wherein the first generative AI model is trained continuously based on a schedule and availability of new information from new instances, wherein the standard information components are collected from a plurality of customers (Vah, ¶¶ [0054]-[0055]: modifying the recommended troubleshooting action in step 212 may comprise providing the obtained information regarding the given asset and feedback regarding the recommended troubleshooting action as input to the first machine learning model and receiving, from the decoder of the first machine learning model, the modified recommended troubleshooting action; incorporate such feedback (e.g., from both correct and incorrect repair and diagnostic decisions) to improve a system for troubleshooting computing devices or other types of assets; ¶ [0061]: the rules or policies may be based on historical feedback data for previous troubleshooting processes for similar assets, based on expert knowledge, etc.; ¶¶ [0064] and [0067]-[0071] with FIGS. 3B-D: in step 309, the repair is completed and the given asset is analyzed (e.g., to determine whether the recommended repair action was successful); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); if the confidence score does not exceed the designated threshold in step 307, the system flow proceeds to step 310; in step 314, the diagnosis for the given asset is confirmed (e.g., the diagnostic results are analyzed to determine if the problem with the given asset has been successfully diagnosed); such results are provided as feedback to the troubleshooting system in path 1 (e.g., the results are provided as feedback or additional training data for the first machine learning model utilized in step 303); if the confidence score does not exceed the designated threshold in step 312, the system flow proceeds to step 310; if no rule or policy exists in step 310, a notification is generated in step 315 indicating that the recommended repair or diagnostic action is likely to result in an undesirable outcome (e.g., that the predicted success of the recommended repair or diagnostic action is below a designated threshold); the technician, supervisor or quality control staff, utilizes the notification to create new rules or policies, or modify existing rules or policies, for future recommended troubleshooting actions ( e.g., to create a new rule or policy, or modify an existing rule or policy, when the recommended troubleshooting action ultimately ends up being successful); if a rule or policy exists in step 310, that rule or policy is applied and feedback is generated regarding the recommended repair or diagnostic action in step 316; such feedback is provided to the expert troubleshooting system 301 in path 1 (e.g., to the first machine learning model used in step 303); such feedback may also be utilized to create new rules or policies, or modify existing rules or policies, for future recommended troubleshooting actions; ¶¶ [0074]-[0077]: for new input, the decoder output of the last step (e.g., output M) is added to the last input ( e.g., input N); this process is repeated until there is a successful repair, or until the repair process is stopped (e.g., after some designated threshold number of iterations of running the model 400, manual stop by a technician, etc.); in case the outcome of the repair or diagnostic action is 1 (e.g., indicating success), then there is no change in the input words provided to the encoder 402 based at least in part on the output vocabulary of the decoder 404; if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; the model 400 may be trained on a dataset including troubleshooting log entries, historical troubleshooting logs suitably transformed into a format fit for a sequence-to-sequence model, external sources (e.g., discussions on technical communities or support forums suitably transformed into a format fit for a sequence-to-sequence model), and for unsuccessful repair and diagnostic tests, a negation ( e.g., the word "_not") is added to the troubleshooting actions; ¶¶ [0085]-[0089] with FIG. 6: each row of the table 600 is assumed to correspond to output of the first machine learning model, which is supplemented with feedback from the second machine learning model; when there is no rule or policy available, the system may to display a warning or notification to the technician indicating that the recommended repair action is not likely to be successful; feedback is then routed to the input of the first machine learning model (e.g., model 400), where the feedback may be "replace commodity memory-NFF"; in a second iteration, the first machine learning model (e.g., model 400), uses feedback from the first iteration, and provides a new recommended repair action of "reseat commodity memory"; the second machine learning model (e.g., model 500) predicts that this recommended repair action will result in VFF (e.g., the electrical interconnects are cleaned during the reseat of the memory, solving the symptom set); the repair action of "reseat commodity memory" is flagged as desirable (e.g., likely to result in VFF); the technician will perform the recommended repair action, which is assumed to result in a successful outcome; feedback is then routed to the input of the first machine learning model (e.g., model 400), where the feedback may be "reseat commodity memory-VFF"; ¶¶ [0094]-[0097] with FIG. 8: if the result of block 815 is yes, then appropriate feedback is provided to the recommendation engine 809. This feedback may cause the recommendation engine 809 to re-invoke the first machine learning model 807 to obtain a new recommended troubleshooting action without applying the previous recommended troubleshooting action; if the result of block 815 is no, the flow may proceed to displaying a warning or other notification via a guidance interface 817 ( e.g., which may provide a graphical user interface) that is invoked by a technician at the repair depot (e.g., to obtain recommended troubleshooting actions, to input or log results of troubleshooting actions that are taken, to receive instructions for performing troubleshooting actions, etc.); if the result of the block 823 determination is no, feedback is provided to the guidance interface 817 for technician analysis 827; the guidance interface 817 provides feedback to the first machine learning model 807 and second machine learning model 811 regarding the diagnostic actions via the recommendation engine 809. Such diagnostic action feedback, as well as the repair action feedback discussed above, may also be stored in the asset information repository 805) (Malladi, ¶¶ [0027]-[0028]: detection operations to facilitate more timely assignment of technicians, scheduling of technicians based on expected times for jobs, and provisioning of trucks, tools, and/or parts; receive, from a service technician in the field evaluating the issue with the equipment, feedback regarding the accuracy of the root cause predictions, as well as feedback regarding how the service technician evaluated information about the equipment (e.g., what data did they evaluate; what did they inspect; did the root cause prediction or instructions for finding the root cause accurately match the type of equipment, etc.), which can be used to update the root cause prediction model; the system can request feedback from the service technician regarding the prescription, such as whether the prescription correctly identified the cause of the alarm and/or actions to perform to respond to the cause, as well as the information that the service technician used to evaluate the correctness or accuracy of the prescription; the system can use this feedback to modify the machine learning models, which can increase the accuracy of the machine learning models; ¶ [0032]: perform operations such as root cause prediction, the system can monitor data regarding equipment to predict events associated with faults and trigger responses such as alerts, service scheduling, and initiating FDD or modifications to configuration of the equipment; ¶[0042]: the denoising neural network can be configured by applying noise to one or more training data elements (e.g., images, video frames) to generate noised data, providing the noised data as input to a candidate denoising neural network, causing the candidate denoising neural network to modify the noised data according to a denoising schedule, evaluating a convergence condition based on comparing the modified noised data with the training data instances, and modifying the candidate denoising neural network according to the convergence condition; ¶ [0080]: automate operations for scheduling, provisioning, and deploying service technicians and resources for service technicians to perform service operation; use at least one of the first model 104 or the second model 116 to determine, based on processing information regarding service operations for items of equipment relative to completion criteria for the service operation, particular characteristics of service operations such as experience parameters of scheduled service technicians, identifiers of parts provided for the service operations, geographical data, types of customers, types of problems, or information content provided to the service technicians to facilitate the service operation, where such characteristics correspond to the completion criteria being satisfied ( e.g., where such characteristics correspond to an increase in likelihood of the completion criteria being satisfied relative to other characteristics for service technicians, parts, information content, etc.); the system 100 can use timing information to perform batch scheduling for multiple service operations and/or multiple technicians for the same or multiple service operations; ¶¶[0136]-[0137]: scheduling of deployment of at least one of a service technician or one or more parts identified by the prescription can be performed; ¶[0145]: the recommender 918 can use at least one AI model ( e.g., generative AI model) to generate an action to be taken responsive to the user query ( e.g., a change in settings to reduce energy consumption, a particular maintenance task to perform, a control decision to prepare a space for an event, a message to be provided to occupants, etc.); the recommendation can be based on data from one or more domain systems 906-910, for example data relating to operating status, settings, schedules, etc.; operating data of equipment; fault information or performance metrics output by domain systems; etc., in various embodiments, such that the recommender 918 uses live information relating to a particular building in addition to general learning by the at least one AI model relating to user queries and suitable recommendations).
Claim 20
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claim 1 and further discloses wherein the preference attributes comprise at least one of a cost of incorrect repair or a safety aspect of incorrect repair (Vah, ¶ [0056]: troubleshooting re-work may be a result of waste (e.g., from replacing good parts unnecessarily), incorrect troubleshooting, etc. Such troubleshooting re-work can be a significant cost to an enterprise, in terms of time consumed, money spent, etc.; troubleshooting re-work costs may be measured through various key performance indicators (KPIs), in terms of labor inefficiencies, parts waste, inappropriate use of diagnostics, customer returns within some designated threshold time of repair (e.g., 28 days) also referred to as repeat dispatch rate (RDR), etc.; troubleshooting action recommendations may be optimized or improved to reduce the amount of troubleshooting re-work)
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Vah in view of Malladi and Chen'2020 as applied to Claims 6 and 14 respectively above, and further in view of Chen et al., ("User-Specific Adaptive Fine-Tuning for Cross-Domain Recommendations", IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 35, NO. 3, Feb. 3, 2023, pp. 3239-3252), hereinafter Chen'2023 and Wu et al. ("Partially Observable Reinforcement Learning for Dialog-based Interactive Recommendation", 15th ACM Conference on Recommender Systems (RecSys21), Sep. 27 - Oct 01, 2021, pp. 241-25), hereinafter Wu.
Claims 7 and 15
Vah in view of Malladi and Chen'2020 discloses all the elements as stated in Claims 6 and 14 respectively and further discloses wherein error for the reward model is determined from a difference between the model predictions and the actual repairs, and wherein the reward model is configured (Vah, ¶ [0055]-[0061] utilize machine learning to predict troubleshooting actions (e.g., diagnostic actions, repair actions, etc.) for a particular asset (e.g., a computing device such as a laptop), where the machine learning model bases predictions on correct repair decisions (e.g., where a part of the laptop or other computing device is replaced by a technician and later found to be defective in screening, or categorized as verified fault found (VFF)); in this manner, the machine learning model learns from correct repair decisions but not incorrect repair decisions (e.g., where a "good" part of the laptop or other computing device is needlessly replaced and categorized as no fault found (NFF)); incorporate such feedback (e.g., from both correct and incorrect repair and diagnostic decisions) to improve a system for troubleshooting computing devices or other types of assets; troubleshooting re-work may be a result of waste (e.g., from replacing good parts unnecessarily), incorrect troubleshooting, etc.; such troubleshooting re-work can be a significant cost to an enterprise, in terms of time consumed, money spent, etc.; troubleshooting re-work costs may be measured through various key performance indicators (KPIs), in terms of labor inefficiencies, parts waste, inappropriate use of diagnostics, customer returns within some designated threshold time of repair (e.g., 28 days) also referred to as repeat dispatch rate (RDR), etc.; illustrative embodiments link troubleshooting action predictions from a machine learning model with various KPIs (e.g., percentage of screened parts resulting in VFF /NFF, percentage of most effective diagnostics, percentage of assets returned to a repair center within a designated time period such as 28 days, etc.); in this way, troubleshooting action recommendations may be optimized or improved to reduce the amount of troubleshooting re-work; extend or complement a troubleshooting recommendation system with a machine learning model that factors both correct and incorrect troubleshooting decisions into troubleshooting recommendations produced by the troubleshooting recommendation system; the troubleshooting recommendation system utilizes a first machine learning model to generate troubleshooting action recommendations, and that the troubleshooting recommendation system is extended with a second machine learning model that factors in both correct and incorrect troubleshooting decisions into the troubleshooting action recommendations from the first machine learning model; the second machine learning model factors in KPIs (e.g., whether replaced parts are good/NFF or bad/VFF, whether diagnostic actions are effective or ineffective, etc.) into a sequence-to-sequence based model to avoid the prediction of undesirable troubleshooting actions ( e.g., repair solutions resulting in replaced parts that are good/NFF, diagnostics solutions that are ineffective, etc.); ¶¶ [0037], [0074]-[0075], and [0086]-[0088]: the machine learning-based troubleshooting system 112 may utilize the modules 114, 116 and 118 in an iterative process until the given asset is successfully repaired or a designated stop condition is reached (e.g., a threshold number of iterations of requesting recommended troubleshooting actions); based at least in part on the outcome of each step in the repair process (e.g., 0 or 1 indicating failure or success, respectively), a decision is made as to whether the input "words" provided to the encoder 402 should be modified for the next step or iteration of the sequence-to-sequence model 400; for new input, the decoder output of the last step ( e.g., output M) is added to the last input (e.g., input N); this process is repeated until there is a successful repair, or until the repair process is stopped (e.g., after some designated threshold number of iterations of running the model 400, manual stop by a technician, etc.); if the outcome is 0 (e.g., indicating failure), then a negation of the output vocabulary of the decoder is appended or augmented to the input provided to the encoder in a next step or iteration; in each iteration, the second machine learning model takes as input various details and information in a cumulative fashion, including: a product description or product platform, symptoms and error descriptions, and diagnostic and repair actions predicted by the first machine learning model. The second machine learning model output indicates whether the outcome of the diagnostic or repair action recommended by the first machine learning model is desirable or not, as measured using one or more KPIs (e.g., VFF or NFF, effective or ineffective diagnostic, complex or trivial diagnostics or repairs, etc.)) (Malladi, ¶¶ [0027]-[0028]: perform root cause prediction by being trained using data that includes indications of root causes of faults or errors, where the indications are labels for or otherwise associated with (unstructured or structure) data such as service requests, service reports, service calls, etc.; receive, from a service technician in the field evaluating the issue with the equipment, feedback regarding the accuracy of the root cause predictions, as well as feedback regarding how the service technician evaluated information about the equipment (e.g., what data did they evaluate; what did they inspect; did the root cause prediction or instructions for finding the root cause accurately match the type of equipment, etc.), which can be used to update the root cause prediction model; provide a platform for fault detection and servicing processes in which a machine learning model is configured based on connecting or relating unstructured data and/or semantic data, such as human feedback and written/spoken reports, with time-series product data regarding items of equipment, so that the machine learning model can more accurately detect causes of alarms or other events that may trigger service responses; e.g., responsive to an alarm for a chiller, the system can more accurately detect a cause of the alarm, and generate a prescription (e.g., for a service technician) for responding to the alarm; the system can request feedback from the service technician regarding the prescription, such as whether the prescription correctly identified the cause of the alarm and/or actions to perform to respond to the cause, as well as the information that the service technician used to evaluate the correctness or accuracy of the prescription; the system can use this feedback to modify the machine learning models, which can increase the accuracy of the machine learning models; ¶ [0061] with FIG. 1: the model updater 108 can select at least a subset of the identified one or parameters to maintain according to various criteria, such as user input or other instructions indicative of an extent to which the first model 104 is to be modified to determine the second model 116; the model updater 108 can evaluate a convergence condition to modify the candidate second model 116 based at least on the one or more candidate outputs and the training data applied as input to the candidate second model 116; e.g., the model updater 108 can evaluate an objective function of the convergence condition, such as a loss function (e.g., L1 loss, L2 loss, root mean square error, cross-entropy or log loss, etc.) based on the one or more candidate outputs and the training data; this evaluation can indicate how closely the candidate outputs generated by the candidate second model 116 correspond to the ground truth represented by the training data; the model updater 108 can use any of a variety of optimization algorithms (e.g., gradient descent, stochastic descent, Adam optimization, etc.) to modify one or more parameters (e.g., weights or biases of the layer(s) of the candidate second model 116 that are not frozen) of the candidate second model 116 according to the evaluation of the objective function); ¶¶ [0070]-[0072] with FIG.1: the diagnostics and troubleshooting application 120 can provide the inputs to a corresponding second model 116 to cause the second model 116 to generate outputs such as indications of potential items to be checked regarding the item of equipment, modifications or fixes to make to perform the service, or values or ranges of values of parameters of the item of equipment that may be indicative of specific issues to for the service technician to address or repair; the service recommendation generator application 120 can receive inputs such as a service request or information regarding the item of equipment to be serviced, and provide the inputs to the second model 116 to cause the second model 116 to generate outputs for presenting service recommendations, such as actions to perform to address the service request; the product recommendation generator application 120 can process inputs such as information regarding the item of equipment or the service request, using one or more second models 116 (e.g., models trained using parts data from the data sources 112), to determine a recommendation of a part or product to replace or otherwise use for repairing the item of equipment; ¶¶ [0129]-[0140] with FIG. 8: at 805, a fault condition of an item of equipment can be detected; at 810, the fault condition can be validated; at 815, a cause of the fault condition can be identified, such as by performing a root cause analysis; at 820, a prescription is generated based on the cause of the fault condition; e.g., one or more of the cause of the fault condition, the fault condition, and an identifier of the equipment can be provided to a language model to cause the language model to generate the prescription; the prescription can have a natural language format, which can indicate one or more actions for a service technician to perform to verify, service, and/or repair the fault condition, such as instructions for tools and/or parts to use for the item of equipment; at 825, a warranty is evaluated based on one or more items e.g., the equipment, parts or tools for servicing the equipment) identified by the prescription; at 830, scheduling of deployment of at least one of a service technician or one or more parts identified by the prescription can be performed; at 835, an application session for a service operation corresponding to the service request (and the prescription) can be provided; at 840, operation of the item of equipment can be updated responsive to one or more actions performed by the service technician).
Vah in view of Malladi and Chen'2020 is fails to explicitly disclose the reward model is configured to generate a reward for when a model prediction is same as an actual repair/result, and wherein the fine-tuning the second AI model from the reward generated from the reward model is performed to personalize and align the second AI model to customer preferences.
Chen'2023 teaches a system and a method for providing recommendation (ABSTRACT), wherein the reward model is configured to generate a reward for when a model prediction is same as an actual result, and wherein the fine-tuning the second AI model from the reward generated from the reward model is performed to reduce cost and preserve accuracy (Chen'2023, Section 3.3.2 in Pages 3244-3245: learn the policy network by employing the reinforcement learning (RL) algorithm (called UAF-RL) which is a popular technique for solving the non-differentiable problem; the main idea is to learn the policy network that outputs the posterior probabilities of all the binary decisions for freezing or fine-tuning each block in the fine-tuning network; the policy network is trained using curriculum learning to maximize a reward that incentivizes the use of as few blocks to fine-tune as possible while preserving the prediction accuracy; consider the potential trade-offs between computational cost and prediction accuracy; model the UAF-RL method as a Markov decision process (MDP); the state is represented by the user representation which is obtained by modeling the interaction sequence through the policy network; the action is represented by the fine-tuning strategy derived by the UAF-RL with the user representation; design the reward function based on the following considerations: (i) enabling the policy network to control the finetuning network so as to generate well-recommended items in target domain; (ii) achieving a significant computational cost reduction to meet the requirement of online service; when taking the corresponding actions, compute the rewards and optimize the entire model to maximize the expectations of the cumulative rewards; define the reward function as the formula (11), where
l
∙
is an indicator function,
A
l
represents the freezing or fine-tuning policy applied on the l-th block, γ is a hyperparameter to penalize the wrong policy; specifically,
∑
l
l
A
l
/
N
2
measures the percentage of blocks that are fine-tuned; when a correct recommendation is produced (i.e., model prediction is same as an actual result), incentivize block freezing by giving a larger reward to a policy that uses fewer blocks to fine-tune; in addition, penalize incorrect recommendations with γ, which controls the trade-off between efficiency and effectiveness γ is simply set to 1 in this paper; to optimize the policy network, adopt self-critical sequence training (SCST), which is a form of the popular REINFORCE algorithm, for model training; rather than estimating a “baseline” to normalize the rewards and reduce variance, SCST applies the output of its own test-time inference algorithm to normalize the rewards it experiences).
Vah in view of Malladi and Chen'2020, and Chen'2023 are analogous art because they are from the same field of endeavor, a system and a method for providing recommendation . Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply the teaching of Chen'2023 to Vah in view of Malladi and Chen'2020. Motivation for doing so would improve the performance of the model (Malladi, Section 3.3.2 in Pages 3244-3245).
Vah in view of Malladi, Chen'2020, and Chen'2023 fails to explicitly disclose wherein the fine-tuning the second AI model from the reward generated from the reward model is performed to personalize and align the second AI model to customer preferences.
Wu teaches a system and a method for providing recommendation (Wu, ABSTRACT), wherein the fine-tuning the second AI model from the reward generated from the reward model is performed to personalize and align the second AI model to customer preferences (Wu, ABSTRACT of Page 241: propose a novel dialog-based recommendation model, the Estimator-Generator-Evaluator (EGE) model, with Q-learning for POMDP, to effectively incorporate the users’ preferences over time; specifically, leverage an Estimator to track and estimate users’ preferences, a Generator to match the estimated preferences with the candidate items to rank the next recommendations, and an Evaluator to judge the quality of the estimated preferences considering the users’ historical feedback; Section I of Pages 241-243: an interactive recommendation task has been formulated and modelled using reinforcement learning (RL) approaches; in the reinforcement learning framework, the interactive recommendation task is usually formulated as a Markov decision process (MDP) with an assumption that the environment’s states (i.e. the users’ preferences) are fully observable; such RL-based interactive recommender systems have demonstrated their benefits in fitting the users’ dynamic preferences and maximizing the expected long-term cumulative rewards from users when achieving the optimal strategies; by taking the Q-learning layer as a regulariser to introduce reward-driven properties (such as long-term user engagement [39]) to the recommendation process; formulate the dialog-based interactive recommendation task as a partially observable Markov decision process (POMDP) to simulate the interactions between a partially observable environment (i.e. a user) and an agent (i.e. a recommender system); to correctly estimate the users’ preferences from such partially observable situations, extend the SQN framework from a MDP to a POMDP and judge/optimise the quality of the estimated users’ preferences with the Q-learning layer (also called an Evaluator); to this end, propose a novel dialog-based interactive recommendation model, called the Estimator-Generator-Evaluator (EGE) model named after its three distinctive functional components, which apply partially observable reinforcement learning (i.e. Q-learning for POMDP) for dialog-based interactive recommendation to effectively incorporate the users’ preferences over time; specifically, leverage an Estimator to track and estimate the users’ preferences, a Generator to match the estimated preferences with the candidate items to rank the next recommendations, and an Evaluator to judge the quality of the estimated preferences considering the users’ historical feedback; to mitigate the impact of repeated recommendations, a post-filter is adopted to remove the repeated recommended items from the ranking list based on the recommendation history).
Vah in view of Malladi, Chen'2020, and Chen'2023, and Wu are analogous art because they are from the same field of endeavor, a system and a method for providing recommendation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply the teaching of Wu to Vah in view of Malladi, Chen'2020, and Chen'2023. Motivation for doing so would better incorporate the users’ accurate preferences over time with the partial observable preferences from the users’ natural-language feedback (Wu, Section 4 in Pages 245-246).
Response to Arguments
Applicant’s arguments filed 05/29/2026 with respect to Claims 1, 9, and 17 have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
ZHAO et al. (CN 114218402 A, pub. date: 03/22/2022) discloses in ABSTRACT, ¶¶ [0003]-[0022] and [0031]-[0042] with FIG. 1 that (1) a method for recommending replacement spare parts for computer hardware failures based on ensemble learning and knowledge graphs, which comprises the following steps: (a) perform preliminary data cleaning on the work order data, perform value verification on key fields, and remove abnormal data such as null values, garbled characters, and special symbols; (b) remove stop words from the customer fault descriptions in the work orders and perform secondary data cleaning; (c) generating feature phrases by performing word segmentation on the customer fault description; (d) combine feature phrases with computer models as feature groups, ensuring that the features of the fault and the semantics of the customer's description are correlated with the computer model, providing more explicit data for subsequent model training; (e) extract text features using a bag-of-words model with a counting vectorizer, wherein the counting vectorizer converts feature groups into vectors by counting; (f) feed the obtained word vectors as X input and standard fault codes as y labels into a random forest model for training, and save the model after training; (g) generate standard fault codes from the customer's fault description using the model, wherein call the trained random forest model based on the customer's fault description, input the customer's description of the computer hardware fault into the model, and the model generates a standard fault code when the repair customer service center receives an online customer inquiry; (h) classify the information related to standard fault codes, fault phenomena/symptoms, replacement spare parts, and computer model from the cleaned work order data to form a knowledge graph, wherein each category corresponds to a different type of node in the knowledge graph, and the weight value of the relationship between nodes is equal to the cumulative frequency value of the relationship between the categories to which each node belongs in the maintenance work order; and (h) take the standard fault codes generated by the random forest as conditions and input them into the knowledge graph to retrieve all the associated replacement parts corresponding to the standard fault code, sort the nodes according to the weight values of the relationship between the standard fault code nodes and the replacement spare parts nodes in descending order, and thus complete the recommendation of replacement spare parts for computer hardware failures; (2) this invention selects the random forest model in ensemble learning; (3) by using the continuously enriched historical work orders of computer hardware repair in an incremental manner as training samples, the performance of random forest classification is continuously improved by the huge corpus; (4) in this way, even when faced with the same fault type, the ever-changing language descriptions of customers can be efficiently identified and effectively converted into standard fault codes; (5) overcome the shortcomings of existing technologies and provide maintenance and customer service centers with a computer hardware fault replacement part recommendation method based on ensemble learning and knowledge graphs; (6) by selecting random forest from the ensemble learning category, it is possible to organically combine multiple prediction results obtained from multiple single learning models, thereby obtaining more accurate, stable and robust final results, making the generalization of this component better; (7) in real-world scenarios, when a computer malfunctions, customers often struggle to pinpoint the problem; (8) remote repair center engineers, not being on-site, cannot immediately determine the necessary replacement parts; (9) in such cases, by communicating with the customer and utilizing a random forest model, information can be quickly extracted from the customer's description of the malfunction, accurately identifying the corresponding fault code and rapidly locating the fault; and (10) then, knowledge graph technology can be used to retrieve the necessary replacement parts in real time, allowing repair service stations to prepare them in advance, which improves customer satisfaction and provides efficient support for repair service centers with extremely high real-time requirements.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HWEI-MIN LU whose telephone number is (313)446-4913. The examiner can normally be reached Mon - Fri: 9:00 AM - 6:00 PM EST.
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, Mariela D. Reyes can be reached at (571) 270-1006. 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.
/HWEI-MIN LU/Primary Examiner, Art Unit 2142
Prosecution Insights