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 .
The information disclosure statement (IDS) was submitted on February 15, 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
The Incident Validation and Classification Module (IVCM), Generative Al Inference Module (GAIM), Problem Probability Calculation Module, Incident Resolution Validation Module (IRVM), and Problem Prevention Recommendation Module defined in claim 1, and further references in dependent claims 2-14.
The user interface module defined in claim 9.
The Incident Validation and Classification Module, Generative Al Inference Module, Problem Probability Calculation Module, Incident Resolution Validation Module, and Problem Prevention Recommendation Module defined in claim 15, and further references in dependent claims 16-19.
The Incident Validation and Classification Module, Generative Al Inference Module, Problem Probability Calculation Module, Incident Resolution Validation Module, and Problem Prevention Recommendation Module defined in claim 15, and further references in dependent claims 16-19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
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 1-14 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.
Claim 1 recites the limitations:
"a quantitative probability score that reflects a likelihood of the incident evolving into a more significant problem"
“validating, by an Incident Resolution Validation Module (IRVM), effectiveness and compliance of resolution actions taken for the incident”
There is insufficient antecedent basis for these limitations in the claim. It is unclear whether “the incident” is referring to the aforementioned “IT service incident” defined in claim 1. For the purposes of examination, the Examiner has interpreted these instances and all subsequent instances in the dependent claims as the IT service incident.
Claim(s) 2-14 are rejected for at least the same reasons as claim 1 since they depend on claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-20 are rejected under 35 U.S.C. 101 because the claims are directed towards an abstract idea without significantly more.
Regarding Claim 1:
Subject Matter Eligibility Analysis Step 1:
Claim 1 recites a method and is thus a process, one of the four statutory categories of patentable subject matter.
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 1 recites:
validating and classifying…the incident data into categories based on predefined criteria utilizing advanced natural language processing (NLP) techniques (This limitation is a mental process as it encompasses a human mentally validating and classifying data and is thus an evaluation.)
analyzes severity and urgency of the IT service incident by comparing the incident data against historical incident patterns and historical classifications (This limitation is a mental process as it encompasses a human mentally analyzing severity of incidents and is thus an evaluation.)
generating…predictive insights regarding potential causes, impacts, and resolution strategies for the IT service incident as classified (This limitation is a mental process as it encompasses a human mentally generating insights and is thus an evaluation.)
to synthesize data from various sources including incident logs, resolution databases, and external knowledge bases to produce comprehensive inferences (This limitation is a mental process as it encompasses a human mentally synthesizing data and is thus an evaluation.)
calculating…a quantitative probability score that reflects a likelihood of the incident evolving into a more significant problem (This limitation is a mental process as it encompasses a human mentally calculating a score and is thus an evaluation.)
wherein the calculation is based on an incident classification type, severity, impacted IT services, and historical incident resolution success rates (This limitation is a mental process as it encompasses a human mentally calculating a score and is thus an evaluation.)
validating…effectiveness and compliance of resolution actions taken for the incident (This limitation is a mental process as it encompasses a human mentally validating actions and is thus an evaluation.)
assess resolution documentation, action effectiveness, and adherence to best practices and regulatory standards (This limitation is a mental process as it encompasses a human mentally assessing documentation, action effectiveness, and adherence to standards and is thus an evaluation.)
recommending…recommended preventive actions aimed at mitigating risk of future incidents of a similar nature (This limitation is a mental process as it encompasses a human mentally recommending actions and is thus an evaluation.)
wherein the recommended preventive actions are derived from an analysis of root causes of the IT service incident, the quantitative probability score, and effectiveness of past preventive measures (This limitation is a mental process as it encompasses a human mentally recommending actions and is thus an evaluation.)
Therefore, claim 1 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 1 further recites additional elements of:
A computer-implemented method for managing and mitigating information technology (IT) service incidents, the method comprising the steps of (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
receiving, by a system comprising a processor and memory, incident data related to an IT service incident (This element does not integrate the abstract idea into a practical application because it recites generic computing components on which to perform the abstract idea (see MPEP 2106.05(f)).)
by an Incident Validation and Classification Module (IVCM) executed by the processor (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
wherein the IVCM further (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
by a Generative Al Inference Module (GAIM) (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
wherein the GAIM applies machine learning (ML) algorithms and large language models (LLMs) (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
by a Problem Probability Calculation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
by an Incident Resolution Validation Module (IRVM) (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
wherein the IRVM employs criteria-based evaluation algorithms to (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
by a Problem Prevention Recommendation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
and updating, by the system, a dynamic knowledge database with a validated classification for the IT service incident, generated inferences, probability scores, validation outcomes, and preventive recommendations to continuously refine and improve the IT service incident and problem management process (This element does not integrate the abstract idea into a practical application because it recites the insignificant extra-solution activity of updating data (see MPEP 2106.05(g)).)
Therefore, claim 1 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 1 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
A computer-implemented method for managing and mitigating information technology (IT) service incidents, the method comprising the steps of uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
receiving, by a system comprising a processor and memory, incident data related to an IT service incident uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
by an Incident Validation and Classification Module (IVCM) executed by the processor uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
wherein the IVCM further uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
by a Generative Al Inference Module (GAIM) uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
wherein the GAIM applies machine learning (ML) algorithms and large language models (LLMs) uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
by a Problem Probability Calculation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
by an Incident Resolution Validation Module (IRVM)
wherein the IRVM employs criteria-based evaluation algorithms to uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
by a Problem Prevention Recommendation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
and updating, by the system, a dynamic knowledge database with a validated classification for the IT service incident, generated inferences, probability scores, validation outcomes, and preventive recommendations to continuously refine and improve the IT service incident and problem management process is the well understood, routine, and conventional activity of "transmitting or receiving data over a network" (see MPEP 2106.05(d)(II); OIP Techs., Inc., V. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network)).
Therefore, claim 1 is subject-matter ineligible.
Regarding Claim 2:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 2 recites:
further comprising prioritizing the incident data based on severity and urgency classifications determined by the IVCM, wherein prioritization influences an order in which incidents are addressed by the system (This limitation is a mental process as it encompasses a human mentally prioritizing data and is thus an evaluation.)
Therefore, claim 2 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 2 does not further recite any additional elements. Therefore, claim 2 is not
integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
Since there are no additional elements, claim 2 does not provide significantly more than
the abstract idea itself, taken alone and in combination. Therefore, claim 2 is subject-matter
ineligible.
Regarding Claim 3:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 3 recites the same abstract idea as claim 2. Therefore, claim 3 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 3 further recites additional elements of:
wherein the GAIM further customizes the predictive insights based on the prioritization, employing machine learning models tailored to handle high- priority incidents with enhanced urgency and accuracy (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 3 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 3 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the GAIM further customizes the predictive insights based on the prioritization, employing machine learning models tailored to handle high- priority incidents with enhanced urgency and accuracy uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 3 is subject-matter ineligible.
Regarding Claim 4:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 4 recites:
incorporates real-time data analytics to dynamically adjust the quantitative probability score as new incident data is received, ensuring the quantitative probability score reflects most current information and trends (This limitation is a mental process as it encompasses a human mentally adjusting a probability score and is thus an evaluation.)
Therefore, claim 4 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 4 further recites additional elements of:
wherein the Problem Probability Calculation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 4 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 4 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the Problem Probability Calculation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 4 is subject-matter ineligible.
Regarding Claim 5:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 5 recites:
further comprising adjusting the recommended preventive actions… based on feedback received from implementation of previous recommendations, thereby creating a feedback loop that continuously refines the effectiveness of the preventive measures (This limitation is a mental process as it encompasses a human mentally adjusting preventative actions and is thus an evaluation.)
Therefore, claim 5 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 5 further recites additional elements of:
by the Problem Prevention Recommendation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 5 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 5 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
by the Problem Prevention Recommendation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 5 is subject-matter ineligible.
Regarding Claim 6:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 6 recites the same abstract idea as claim 5. Therefore, claim 6 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 6 further recites additional elements of:
wherein the IRVM includes a component for automatic generation of compliance reports that document a resolution process, effectiveness of actions taken, and any deviations from established resolution standards (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 6 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 6 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the IRVM includes a component for automatic generation of compliance reports that document a resolution process, effectiveness of actions taken, and any deviations from established resolution standards uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 6 is subject-matter ineligible.
Regarding Claim 7:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 7 recites the same abstract idea as claim 6. Therefore, claim 7 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 7 further recites additional elements of:
further comprising a step where the system sends notifications to relevant stakeholders, including a summary of the IT service incident, the quantitative probability score, and the recommended preventive actions (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 7 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 7 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
further comprising a step where the system sends notifications to relevant stakeholders, including a summary of the IT service incident, the quantitative probability score, and the recommended preventive actions uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 7 is subject-matter ineligible.
Regarding Claim 8:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 8 recites the same abstract idea as claim 7. Therefore, claim 8 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 8 further recites additional elements of:
wherein the system integrates with external databases and incident management tools to enrich incident data analysis, leveraging external sources of information to enhance accuracy of the classification, the inference generation, and the quantitative probability score (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 8 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 8 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the system integrates with external databases and incident management tools to enrich incident data analysis, leveraging external sources of information to enhance accuracy of the classification, the inference generation, and the quantitative probability score uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 8 is subject-matter ineligible.
Regarding Claim 9:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 9 recites the same abstract idea as claim 8. Therefore, claim 9 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 9 further recites additional elements of:
further comprising a user interface module that allows users to manually review and adjust the classifications, probability scores, and recommendations generated by the system, ensuring that human judgment can be applied for supervision (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 9 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 9 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
further comprising a user interface module that allows users to manually review and adjust the classifications, probability scores, and recommendations generated by the system, ensuring that human judgment can be applied for supervision uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 9 is subject-matter ineligible.
Regarding Claim 10:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 10 recites the same abstract idea as claim 9. Therefore, claim 10 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 10 further recites additional elements of:
wherein the system employs advanced encryption and security measures to protect integrity and confidentiality of the incident data, ensuring that data processing and communications are secure from unauthorized access (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 10 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 10 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the system employs advanced encryption and security measures to protect integrity and confidentiality of the incident data, ensuring that data processing and communications are secure from unauthorized access uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 10 is subject-matter ineligible.
Regarding Claim 11:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 11 recites:
to identify patterns and correlations in the incident data that were previously unrecognized, thereby enhancing predictive capabilities of the system over time through continuous learning (This limitation is a mental process as it encompasses a human mentally identifying patterns and correlations and is thus an evaluation.)
Therefore, claim 11 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 11 further recites additional elements of:
further comprising utilizing machine learning algorithms within the GAIM (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 11 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 11 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
further comprising utilizing machine learning algorithms within the GAIM uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 11 is subject-matter ineligible.
Regarding Claim 12:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 12 recites:
compares the effectiveness of the incident resolution and preventive measures against industry standards and metrics, facilitating ongoing improvement and adherence to best practices (This limitation is a mental process as it encompasses a human mentally comparing effectiveness and is thus an evaluation.)
Therefore, claim 12 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 12 further recites additional elements of:
including a benchmarking step where the system (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 12 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 12 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
including a benchmarking step where the system uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 12 is subject-matter ineligible.
Regarding Claim 13:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 13 recites the same abstract idea as claim 12. Therefore, claim 13 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 13 further recites additional elements of:
wherein the IVCM is further configured to automatically update classification criteria based on evolving IT service landscapes and emerging threat vectors, ensuring that the module remains effective in identifying and categorizing incidents (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 13 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 13 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the IVCM is further configured to automatically update classification criteria based on evolving IT service landscapes and emerging threat vectors, ensuring that the module remains effective in identifying and categorizing incidents uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 13 is subject-matter ineligible.
Regarding Claim 14:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 14 recites the same abstract idea as claim 13. Therefore, claim 14 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 14 further recites additional elements of:
wherein the system incorporates an analytics dashboard that provides visualizations of key metrics including incident frequency, resolution times, effectiveness of preventive actions, and trends in the probability scores (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 14 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 14 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the system incorporates an analytics dashboard that provides visualizations of key metrics including incident frequency, resolution times, effectiveness of preventive actions, and trends in the probability scores uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 14 is subject-matter ineligible.
Regarding Claim 15:
Subject Matter Eligibility Analysis Step 1:
Claim 15 recites a system and is thus a machine, one of the four statutory categories of patentable subject matter.
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 15 recites:
to validate and classify incidents (This limitation is a mental process as it encompasses a human mentally validating and classifying incidents and is thus an evaluation.)
generating insights (This limitation is a mental process as it encompasses a human mentally generating insights and is thus an evaluation.)
compute incident escalation likelihood (This limitation is a mental process as it encompasses a human mentally computing a likelihood and is thus an evaluation.)
resolution effectiveness assessment (This limitation is a mental process as it encompasses a human mentally assessing effectiveness and is thus an evaluation.)
Therefore, claim 15 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 15 further recites additional elements of:
A system for managing and mitigating information technology (IT) service incidents, comprising: a processor and a memory storing instructions that, when executed by the processor, enable the system to perform operations including (This element does not integrate the abstract idea into a practical application because it recites generic computing components on which to perform the abstract idea (see MPEP 2106.05(f)).)
receiving incident data (This element does not integrate the abstract idea into a practical application because it recites the insignificant extra-solution activity of receiving data (see MPEP 2106.05(g)).)
utilizing an Incident Validation and Classification Module with natural language processing capabilities (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
employing a Generative Al Inference Module that leverages large language models for (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
using a Problem Probability Calculation Module to (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
implementing an Incident Resolution Validation Module for (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
engaging a Problem Prevention Recommendation Module for actionable preventive measures (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
and updating a knowledge database with incident insights and recommendations (This element does not integrate the abstract idea into a practical application because it recites the insignificant extra-solution activity of updating data (see MPEP 2106.05(g)).)
Therefore, claim 15 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 15 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
A system for managing and mitigating information technology (IT) service incidents, comprising: a processor and a memory storing instructions that, when executed by the processor, enable the system to perform operations including uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
receiving incident data is the well understood, routine, and conventional activity of "transmitting or receiving data over a network" (see MPEP 2106.05(d)(II); OIP Techs., Inc., V. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network)).
utilizing an Incident Validation and Classification Module with natural language processing capabilities uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
employing a Generative Al Inference Module that leverages large language models for uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
using a Problem Probability Calculation Module to uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
implementing an Incident Resolution Validation Module for uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
engaging a Problem Prevention Recommendation Module for actionable preventive measures uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
and updating a knowledge database with incident insights and recommendations is the well understood, routine, and conventional activity of "transmitting or receiving data over a network" (see MPEP 2106.05(d)(II); OIP Techs., Inc., V. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network)).
Therefore, claim 15 is subject-matter ineligible.
Regarding Claim 16:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 16 recites:
further configured to prioritize incident handling based on severity and urgency determined by the Incident Validation and Classification Module (This limitation is a mental process as it encompasses a human mentally prioritizing incident handling and is thus an evaluation.)
Therefore, claim 16 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 16 further recites additional elements of:
wherein a prioritization algorithm dynamically adjusts resource allocation and response times to ensure critical incidents are addressed promptly (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 16 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 16 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein a prioritization algorithm dynamically adjusts resource allocation and response times to ensure critical incidents are addressed promptly uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 16 is subject-matter ineligible.
Regarding Claim 17:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 17 recites the same abstract idea as claim 16. Therefore, claim 17 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 17 further recites additional elements of:
wherein the Generative Al Inference Module integrates external data sources including cybersecurity threat intelligence feeds and IT service management logs, to enrich predictive insights with context-specific information, enhancing accuracy and relevance of the generated inferences (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 17 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 17 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
wherein the Generative Al Inference Module integrates external data sources including cybersecurity threat intelligence feeds and IT service management logs, to enrich predictive insights with context-specific information, enhancing accuracy and relevance of the generated inferences uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 17 is subject-matter ineligible.
Regarding Claim 18:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 18 recites:
wherein the feedback is utilized by the Problem Prevention Recommendation Module to refine and personalize future preventive actions, ensuring continuous improvement in incident prevention strategies (This limitation is a mental process as it encompasses a human mentally refining and personalizing actions and is thus an evaluation.)
Therefore, claim 18 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 18 further recites additional elements of:
further comprising a feedback mechanism that captures user feedback on resolution outcomes and preventive recommendations (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 18 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 18 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
further comprising a feedback mechanism that captures user feedback on resolution outcomes and preventive recommendations uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 18 is subject-matter ineligible.
Regarding Claim 19:
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 19 recites the same abstract idea as claim 18. Therefore, claim 19 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 19 further recites additional elements of:
equipped with a user interface that provides administrators and IT personnel with real-time dashboards, incident reports, and actionable analytics, enabling efficient monitoring, management, and decision-making based on the insights generated (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
Therefore, claim 19 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 19 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
equipped with a user interface that provides administrators and IT personnel with real-time dashboards, incident reports, and actionable analytics, enabling efficient monitoring, management, and decision-making based on the insights generated uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
Therefore, claim 19 is subject-matter ineligible.
Regarding Claim 20:
Subject Matter Eligibility Analysis Step 1:
Claim 20 recites a method and is thus a process, one of the four statutory categories of patentable subject matter.
Subject Matter Eligibility Analysis Step 2A Prong 1:
Claim 20 recites:
analyzing the incident data (This limitation is a mental process as it encompasses a human mentally analyzing data and is thus an evaluation.)
to validate and classify the incident based on predefined criteria (This limitation is a mental process as it encompasses a human mentally validating and classifying incidents and is thus an evaluation.)
wherein the classification includes determining a type and severity of the incident (This limitation is a mental process as it encompasses a human mentally determining a type and severity and is thus an evaluation.)
generating…insights and inferences based on the classified incident data (This limitation is a mental process as it encompasses a human mentally generating insights and inferences and is thus an evaluation.)
calculating…a probability score indicating the likelihood of the incident escalating into a significant problem based on the generated insights and historical incident data (This limitation is a mental process as it encompasses a human mentally calculating a probability score and is thus an evaluation.)
validating…resolution actions taken for the incident against established resolution standards and the generated insights (This limitation is a mental process as it encompasses a human mentally validating actions and is thus an evaluation.)
including verifying completeness and accuracy of resolution documentation (This limitation is a mental process as it encompasses a human mentally verifying completeness and accuracy of documentation and is thus an evaluation.)
recommending…preventive actions to mitigate the risk of future incidents based on the calculated probability score, the validated resolution actions, and the insights generated by the Generative Al Inference Module (This limitation is a mental process as it encompasses a human mentally recommending actions and is thus an evaluation.)
Therefore, claim 20 recites an abstract idea.
Subject Matter Eligibility Analysis Step 2A Prong 2:
Claim 20 further recites additional elements of:
A computer-implemented method for managing information technology service incidents and problems comprising (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
receiving incident data related to an information technology service incident (This element does not integrate the abstract idea into a practical application because it recites the insignificant extra-solution activity of receiving data (see MPEP 2106.05(g)).)
using an Incident Validation and Classification Module configured with natural language processing (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
with a Generative Al Inference Module employing large language models (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
wherein the insights include potential causes and impacts of the incident (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
with a Problem Probability Calculation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
with an Incident Resolution Validation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
with a Problem Prevention Recommendation Module (This element does not integrate the abstract idea into a practical application because it amounts to mere “apply it on a computer” (see MPEP 2106.05(f)).)
and updating a knowledge database with the classified incident data, the generated insights, the probability score, the validated resolution actions, and the recommended preventive actions to enhance future incident and problem management processes (This element does not integrate the abstract idea into a practical application because it recites the insignificant extra-solution activity of updating data (see MPEP 2106.05(g)).)
Therefore, claim 20 is not integrated into a practical application.
Subject Matter Eligibility Analysis Step 2B:
The additional elements of claim 20 do not provide significantly more than the abstract
idea itself, taken alone and in combination because
A computer-implemented method for managing information technology service incidents and problems comprising uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
receiving incident data related to an information technology service incident is the well understood, routine, and conventional activity of "transmitting or receiving data over a network" (see MPEP 2106.05(d)(II); OIP Techs., Inc., V. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network)).
using an Incident Validation and Classification Module configured with natural language processing uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
with a Generative Al Inference Module employing large language models uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
wherein the insights include potential causes and impacts of the incident uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
with a Problem Probability Calculation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
with an Incident Resolution Validation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
with a Problem Prevention Recommendation Module uses a computer as a tool to perform the abstract idea and cannot provide significantly more (see MPEP 2106.05(f)).
and updating a knowledge database with the classified incident data, the generated insights, the probability score, the validated resolution actions, and the recommended preventive actions to enhance future incident and problem management processes is the well understood, routine, and conventional activity of "transmitting or receiving data over a network" (see MPEP 2106.05(d)(II); OIP Techs., Inc., V. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network)).
Therefore, claim 20 is subject-matter ineligible.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (“Empowering Practical Root Cause Analysis by Large Language Models for Cloud Incidents”) in view of Saka et al. (“GPT Models in Construction Industry: Opportunities, Limitations, and a Use Case Validation”) and further in view of Zhang et al. (“A novel network security situation assessment model based on multiple strategies whale optimization algorithm and bidirectional GRU”) and further in view of Peshave et al. (“Empowering Practical Root Cause Analysis by Large Language Models for Cloud Incidents”).
Regarding claim 1, Chen teaches
A computer-implemented method for managing and mitigating information technology (IT) service incidents, the method comprising the steps of: receiving, by a system comprising a processor and memory, incident data related to an IT service incident (Chen, page 10, “All experiments are performed on the server with Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz, 32.0 GB physical memory, and Intel UHD Graphics 630. The OS of the server is Windows 11 Enterprise.” Chen, page 1, “We evaluate RCA Copilot using a real-world dataset consisting of a year’s worth of incidents from Transport service in Microsoft.” Examiner notes the model uses and thus receives a dataset of incident data related to IT incidents.)
validating and classifying, by an Incident Validation and Classification Module (IVCM) executed by the processor, the incident data into categories based on predefined criteria utilizing advanced natural language processing (NLP) techniques (Chen, pages 9-10, “RCACopilot achieves 0.766 and 0.533 for Micro-F1 and Macro-F1 separately when predicting the root cause category of cloud incidents, outperforming all our baselines with a low running overhead (4.205 seconds). RCACopilot is also able to generate new root cause category labels for unseen incidents with explanations.” Chen, page 4, “Specifically, each incident was carefully reviewed and categorized based on the characteristics of the problem, the source of the issue, and the impact on the system by our experienced OCEs.” Examiner notes the incident data is carefully reviewed and categorized based on a variety of predefined criteria.)
wherein the IVCM further analyzes…the IT service incident (Chen, page 2, “In this paper, we introduce RCACopilot, a novel approach to cloud incident root cause analysis that shifts away from the traditional reliance on TSGs.”)
generating, by a Generative Al Inference Module (GAIM), predictive insights regarding potential causes, impacts, and resolution strategies for the IT service incident as classified (Chen, page 2, “We introduce the integration of a large language model within RCACopilot that autonomously analyzes the collected diagnostic data to predict incident root cause categories and generate explanations, demonstrating the potential of the large language model in enhancing RCA.” Chen, page 6, “Root cause prediction stage: Once the diagnostic information is collected, RCACopilot transitions into the root cause prediction stage. In this phase, RCACopilot applies its predictive module to determine the likely root cause category of the incident.” Chen, page 7, “For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 7, “Mitigation action: This action refers to the strategic steps suggested to alleviate an incident, such as “restart service” or “engage other teams”, as depicted in Figure 5.”)
wherein the GAIM applies machine learning (ML) algorithms and large language models (LLMs) to synthesize data from various sources including incident logs, resolution databases, and external knowledge bases to produce comprehensive inferences (Chen, page 1, “In this paper, we introduce RCACopilot, an innovative on-call system empowered by the Large Language Model for automating RCA of cloud incidents.” Chen, page 7, “For instance, as illustrated in Figure 6, RCACopilot can assimilate diverse data such as error logs, exception stack traces, and socket metrics related to a specific incident.” Chen, page 9, “After the new handler has been constructed, it will be stored in the database, and OCEs can modify it by creating new action nodes or deleting old nodes.” Examiner notes that a database of incident handlers is used by a large language model in the proposed algorithm, as well as error logs.)
and updating, by the system, a dynamic knowledge database with a validated classification for the IT service incident, generated inferences, probability scores, validation outcomes, and preventive recommendations to continuously refine and improve the IT service incident and problem management process (Chen, page 6, “Diagnostic information collection stage: This is the initial stage, where the incident is parsed and matched to the pre-defined incident handler. Each handler is tailored to a specific alert type. Upon matching the incident with the appropriate handler, RCACopilot proceeds to collect relevant diagnostic data from a variety of sources.” Chen, page 6, “The handler includes three distinct actions: scope switching action, query action, and mitigation action.” Chen, page 7, “Query action: Query action can query data from different sources and output the query result as a key-value pair table. This type of action can also be hooked to executing a specific script with pre-defined parameters. Usually, scripts are internal automatic investigation tools for a service, and only the service team has access to the tools. For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 10, “RCACopilot is also able to generate new root cause category labels for unseen incidents with explanations.” Chen, page 9, “To facilitate the building of the RCACopilot incident handler, we have implemented RCACopilot’s handler construction as a web application. To support a new type of alert in RCACopilot, OCEs only need to add a new handler in the handler construction GUI according to her expertise (see Appendix A). After the new handler has been constructed, it will be stored in the database, and OCEs can modify it by creating new action nodes or deleting old nodes.” Examiner notes that incident handlers are updated by the system into a dynamic database to be used by the model, and an incident handler consists of an incident classification (alert type), generated inferences (generated root causes by the model), validation outcomes (query actions, which validate if the incident is a known issue), and preventive recommendations (mitigation actions)).
Chen does not, but Saka teaches
wherein the IVCM further analyzes severity and urgency…by comparing the incident data against historical incident patterns and historical classifications (Saka, page 31, “GPT models have the potential to analyze various risk factors and provide more accurate and objective assessments by leveraging their advanced NLP and ML capabilities. The training data may encompass demolition project records, structural characteristics, historical accident data, and safety guidelines.” Examiner notes that the historical accident data is the historical data.)
validating, by an Incident Resolution Validation Module (IRVM), effectiveness and compliance of resolution actions taken for the incident (Saka, page 19, “GPT models can be leveraged to automate regulatory compliance in the construction industry through their NLP and understanding capabilities. These models have the ability to analyze and extract information from construction regulatory textual documents, transforming them into logic clauses that can be used for automated reasoning.” Saka, page 17, “GPT models can be provided with information on standards, regulations, passive design principles, building facades optimization and renewable energy systems for it to be leveraged for improving energy efficiency analysis. As such, GPT models can provide guidance on selection of simulation tools, interpretation of results, identify opportunities for improvement (such as optimizing building orientation, insulation, energy systems) and analysing cost-effectiveness of proposed solutions.” Examiner notes GPT models are leveraged to automate regulatory compliance and cost effectiveness of proposed solutions, wherein the proposed solutions are the generated resolution actions taken for the incident. )
wherein the IRVM employs criteria-based evaluation algorithms to assess resolution documentation, action effectiveness, and adherence to best practices and regulatory standards (Saka, page 19, “GPT models can be leveraged to automate regulatory compliance in the construction industry through their NLP and understanding capabilities. These models have the ability to analyze and extract information from construction regulatory textual documents, transforming them into logic clauses that can be used for automated reasoning.” Saka, page 25, “GPT models can be trained with relevant compliance documents, guidelines, and reporting requirements to capture patterns and embedded knowledge. These models can be used in compliance evaluation of facility management activities by comparing new inputs with regulatory requirements to identify non-compliance issues. Similarly, the GPT models can be employed in documentation by highlighting non-compliance issues, providing recommendations, and creating standardized reports to save time and ensure consistency as shown in Figure 8.” Examiner notes that GPT models utilize evaluation algorithms to generate an output.)
Chen and Saka both utilize large language models to generate insights on real-world incident data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen to analyze severity of the incident like Saka. Doing so would have been advantageous because “This enables the models to identify high-risk areas, predict potential failure modes, and recommend appropriate control measures to mitigate risks” (Saka, page 31).
It would also have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen to validate compliance of resolution actions and adherence to regulatory standards like Saka. Doing so would have been advantageous because “by automating the compliance checking process, GPT models can significantly reduce the time and effort required for regulatory compliance assessment and serve as an assistant in automated regulatory compliance” (Saka, page 19), and furthermore “by automating the analysis of regulatory requirements, GPT models can reduce the potential for errors and ensure a higher level of accuracy in compliance” (Saka, page 29).
calculating, by a Problem Probability Calculation Module, a quantitative probability score that reflects a likelihood of the incident evolving into a more significant problem (Zhang, page 10, “Threat: The threat level refers to various external factors that pose a threat to the network system itself. The most significant impact on network security is typically from external threats, leading to service interruptions or data loss. External threats usually encompass various forms of network attack activities and triggered network security incidents. Therefore, in this study, the main indicators selected under the primary indicator of threat level are the severity level of attack types, the number of alerts, and the likelihood of security incidents occurring. The formula is as follows:
PNG
media_image1.png
71
150
media_image1.png
Greyscale
where T represents the threat score.” Examiner notes the quantitative probability score is the threat score, wherein an attack with a higher threat level has a higher likelihood of it evolving into a more significant problem.)
wherein the calculation is based on an incident classification type, severity, impacted IT services, and historical incident resolution success rates (Zhang, page 10, “The formula is as follows:
PNG
media_image1.png
71
150
media_image1.png
Greyscale
where T represents the threat score, n is the total number of hosts in the network system, k is the number of attack types, M is the number of all attacks detected in a period, and Dij is the attack when the i-th host receives the j-th attack the hazard level corresponding to the type, Qi is the importance of the i-th host, and Cij is the number of times the i-th host receives the attack j.”) Zhang, page 24, “The gate recurrent unit (GRU) is a variant of the LSTM network. Moreover, the GRU network is more straightforward in structure than the LSTM network. GRU network controls information updating through gating method. Unlike LSTM, GRU does not introduce additional memory cells. The update gate is an important part of the GRU network. The update gate can control how much information the current evaluation status obtains from the historical evaluation status.” Examiner notes the classification type is the attack type, the severity is the importance of the host (the more important the host that is being attacked is, the more severe the attack is), the impacted IT services are the number of hosts, and the historical incident resolution success rates are the historical evaluation status, which is the past information that the network retains to make up the ‘memory’ of the network, and thus is used to calculate threat level by the network.)
Chen and Saka utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka to adjust the probability score dynamically like Zhang. Doing so would have been advantageous because having a quantitative assessment of incident severity would allow for more effective prioritization and management of incidents, increasing the efficiency of the system.
Chen, Saka, and Zhang do not, but Peshave teaches
recommending, by a Problem Prevention Recommendation Module, recommended preventive actions aimed at mitigating risk of future incidents of a similar nature (Peshave, page 1, “We can accelerate maintenance processes and reduce human effort by automating maintenance recommendation generation using state-of-the-art Technical Language Processing (TLP) methods that analyze large volumes of historical maintenance case data.” Peshave, page 1, “Enhanced methods of remote monitoring and health management-based maintenance optimization have been recognized as key elements to reduce preventive and corrective maintenance costs.” Examiner notes that maintenance recommendations are a form of preventative actions as they reduce future preventative and corrective costs.)
wherein the recommended preventive actions are derived from an analysis of root causes of the IT service incident, the quantitative probability score, and effectiveness of past preventive measures (Peshave, page 3, Figure 1, steps 4-6. Peshave, page 4, “Finally, in Step 6, feedback is sent back to APM to inform if the recommended action helped the customer get to the root cause of the problem, mitigate, and disposition the issue correctly.” Examiner notes that the recommended actions are the recommendations in step 4. Examiner further notes that feedback of the root cause of the problem as well as whether or not the recommended action helped the customer are given back to the model, and thus the model uses root causes of the incident and effectiveness of past measures to derive recommended actions.)
Chen, Saka, and Peshave all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka and Zhang to recommend preventative actions like Peshave. Doing so would have been advantageous because it would “reduce preventive and corrective maintenance costs” (Peshave, page 1) of the system.
Claim(s) 2-5, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Peshave and further in view of Saka and further in view of Zhang and further in view of Bansal et al. (“DeCaf: Diagnosing and Triaging Performance Issues in Large-Scale Cloud Services”).
Regarding claim 2, Chen, Saka, Zhang, and Peshave teach the method of claim 1. Chen, Saka, Zhang, and Peshave do not, but Bansal teaches
further comprising prioritizing the incident data based on severity and urgency classifications determined by the IVCM (Bansal, page 201, “In this paper, we present the design, implementation and experience from building and deploying DeCaf, a system for automated diagnosis and triaging of KPI issues using service logs.” Bansal, page 202, “Triaging is the process of prioritizing and determining which issue should be investigated and subsequently fixed. This is critical since it can take anywhere from hours to days to root cause and fix an issue. DevOps engineers consider various factors while triaging issues: (a) What is the impact of the issue? How many customers or requests are being impacted? (b) Is the issue localized or global? (c) Is it a known issue? If yes, has the impact increased? (d) Has this issue occurred in the past? Triaging performance issues is non-trivial because engineers have to estimate the scope and impact of issues by taking into account historical data.” Examiner notes that the issues are prioritized based on impact of the issue and thus are prioritized based on severity and urgency.)
wherein prioritization influences an order in which incidents are addressed by the system (Bansal, page 202, “Triaging is the process of prioritizing and determining which issue should be investigated and subsequently fixed.”)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, and Peshave to implement incident prioritization like Bansal. Doing so would have been advantageous because prioritization “is critical since it can take anywhere from hours to days to root cause and fix an issue” (Bansal, page 202) and thus doing so would “minimize the time and manual effort in diagnosing and triaging such issues to reduce customer impact” (Bansal, page 201).
Regarding claim 3, Chen, Saka, Zhang, Peshave, and Bansal teach the method of claim 2. Bansal further teaches
wherein the GAIM further customizes the predictive insights based on the prioritization, employing machine learning models tailored to handle high- priority incidents with enhanced urgency and accuracy (Bansal, page 201, “In this paper, we present the design, implementation and experience from building and deploying DeCaf, a system for automated diagnosis and triaging of KPI issues using service logs. It uses ma chine learning along with pattern mining to help service owners automatically root cause and triage performance issues.” Bansal, page 202, “Triaging is the process of prioritizing and determining which issue should be investigated and subsequently fixed.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, and Peshave to implement incident prioritization like Bansal. Doing so would have been advantageous because prioritization “is critical since it can take anywhere from hours to days to root cause and fix an issue” (Bansal, page 202) and thus doing so would “minimize the time and manual effort in diagnosing and triaging such issues to reduce customer impact” (Bansal, page 201).
Regarding claim 4, Chen, Saka, Zhang, Peshave, and Bansal teach the method of claim 3. Chen further teaches
wherein the Problem Probability Calculation Module incorporates real-time data analytics to dynamically adjust…as new incident data is received, ensuring the quantitative probability score reflects most current information and trends (Chen, page 6, “RCACopilot’s incident handlers can be updated and modified dynamically by OCEs, allowing them to stay abreast with the most recent system changes and newly discovered root causes. For instance, when a new metric is introduced into the system, OCEs only need to construct a new action to collect the relevant data and incorporate it into the corresponding incident handler, which can ensure timely adaptation.”)
Zhang further teaches
wherein the Problem Probability Calculation Module incorporates real-time data analytics to dynamically adjust the quantitative probability score (Zhang, page 10, “Threat: The threat level refers to various external factors that pose a threat to the network system itself. The most significant impact on network security is typically from external threats, leading to service interruptions or data loss. External threats usually encompass various forms of network attack activities and triggered network security incidents. Therefore, in this study, the main indicators selected under the primary indicator of threat level are the severity level of attack types, the number of alerts, and the likelihood of security incidents occurring. The formula is as follows:
PNG
media_image1.png
71
150
media_image1.png
Greyscale
where T represents the threat score.” Examiner notes the quantitative probability score is the threat score, and the threat score is dynamically adjusted for each sample by the system depending on the incoming data in real-time during training.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Peshave, and Bansal to adjust the probability score dynamically like Zhang. Doing so would have been advantageous because having a quantitative assessment of incident severity would allow for more effective prioritization and management of incidents, increasing the efficiency of the system.
Regarding claim 5, Chen in view of Saka, Zhang, Peshave, and Bansal teach the method of claim 4. Peshave further teaches
further comprising adjusting the recommended preventive actions by the Problem Prevention Recommendation Module based on feedback received from implementation of previous recommendations, thereby creating a feedback loop that continuously refines the effectiveness of the preventive measures (Pehshave, page 1, “We can accelerate maintenance processes and reduce human effort by automating maintenance recommendation generation using state-of-the-art Technical Language Processing (TLP) methods that analyze large volumes of historical maintenance case data.” Peshave, page 1, “Enhanced methods of remote monitoring and health management-based maintenance optimization have been recognized as key elements to reduce preventive and corrective maintenance costs.” Peshave, page 3, Figure 1. Peshave, page 4, “In Step 5 of the workflow, customers at the plant would then generate a work order to review, investigate, and perform any corrective actions. Finally, in Step 6, feedback is sent back to APM to inform if the recommended action helped the customer get to the root cause of the problem, mitigate, and disposition the issue correctly.” Examiner notes that maintenance recommendations are a form of preventative actions as they reduce future preventative and corrective costs.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, and Bansal to recommend preventative actions based on feedback from previous recommendations like Peshave. Doing so would have been advantageous because it would “reduce preventive and corrective maintenance costs” (Peshave, page 1) of the system. Regarding feedback, “learning from past resolutions and automating analysis of incoming cases to generate recommendations is an ongoing effort in PHM. While a large number of analytical models are employed for heath assessment and alert generation, the disposition of alerts and subsequent maintenance decision-making is performed largely manually at Remote Monitoring Centers (RMCs)” (Peshave, page 2). Therefore, being able to automate assessment by using past incident resolutions would speed up the process and reduce if not completely remove manual workload by humans.
Regarding claim 20, Chen teaches
A computer-implemented method for managing information technology service incidents and problems comprising: receiving incident data related to an information technology service incident (Chen, page 1, “We evaluate RCA Copilot using a real-world dataset consisting of a year’s worth of incidents from Transport service in Microsoft.”)
analyzing the incident data using an Incident Validation and Classification Module configured with natural language processing to validate and classify the incident based on predefined criteria, wherein the classification includes determining a type…of the incident
(Chen, pages 9-10, “RCACopilot achieves 0.766 and 0.533 for Micro-F1 and Macro-F1 separately when predicting the root cause category of cloud incidents, outperforming all our baselines with a low running overhead (4.205 seconds). RCACopilot is also able to generate new root cause category labels for unseen incidents with explanations.”)
generating, with a Generative Al Inference Module employing large language models, insights and inferences based on the classified incident data, wherein the insights include potential causes… of the incident (Chen, page 2, “We introduce the integration of a large language model within RCACopilot that autonomously analyzes the collected diagnostic data to predict incident root cause categories and generate explanations, demonstrating the potential of the large language model in enhancing RCA.” Chen, page 6, “Root cause prediction stage: Once the diagnostic information is collected, RCACopilot transitions into the root cause prediction stage. In this phase, RCACopilot applies its predictive module to determine the likely root cause category of the incident.”)
and updating a knowledge database with the classified incident data, the generated insights, the probability score, the validated resolution actions, and the recommended preventive actions to enhance future incident and problem management processes (Chen, page 6, “Diagnostic information collection stage: This is the initial stage, where the incident is parsed and matched to the pre-defined incident handler. Each handler is tailored to a specific alert type. Upon matching the incident with the appropriate handler, RCACopilot proceeds to collect relevant diagnostic data from a variety of sources.” Chen, page 6, “The handler includes three distinct actions: scope switching action, query action, and mitigation action.” Chen, page 7, “Query action: Query action can query data from different sources and output the query result as a key-value pair table. This type of action can also be hooked to executing a specific script with pre-defined parameters. Usually, scripts are internal automatic investigation tools for a service, and only the service team has access to the tools. For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 10, “RCACopilot is also able to generate new root cause category labels for unseen incidents with explanations.” Chen, page 9, “To facilitate the building of the RCACopilot incident handler, we have implemented RCACopilot’s handler construction as a web application. To support a new type of alert in RCACopilot, OCEs only need to add a new handler in the handler construction GUI according to her expertise (see Appendix A). After the new handler has been constructed, it will be stored in the database, and OCEs can modify it by creating new action nodes or deleting old nodes.” Examiner notes that incident handlers are updated by the system into a dynamic database to be used by the model, and an incident handler consists of an incident classification (alert type), generated inferences (generated root causes by the model), validation outcomes (query actions, which validate if the incident is a known issue), and preventive recommendations (mitigation actions)).
Chen does not, but Bansal teaches
wherein the classification includes determining a…severity of the incident
(Bansal, page 204, “Goal: With DeCaf, our goal was to build a system which can automatically help the DevOps engineers narrow down a performance regression to a subset of requests. So, for each identified issue, it outputs a root-cause which consist of a set of predicates along with impact metrics and a triage category. These predicates help narrow down a regression to a subset of log rows and columns which can then be further used for mitigation of the issue.” Bansal, page 206, “For each of the nodes, we also compute the following metrics: (1) Row count: Number of training samples in a node. (2) Anomaly probability (Classification trees): Probability of a training sample belonging to the positive (anomalous) class. (3) Predicted value (Regression trees): Average value of the target variable for the samples in a node. As we discuss in the next step, these metrics are used for ranking and triaging the results.” Examiner notes that the severity of the incident are the impact metrics calculated by the model, which is used for ranking and triaging the incidents.)
wherein the insights include potential… impacts of the incident
(Bansal, page 204, “Goal: With DeCaf, our goal was to build a system which can automatically help the DevOps engineers narrow down a performance regression to a subset of requests. So, for each identified issue, it outputs a root-cause which consist of a set of predicates along with impact metrics and a triage category. These predicates help narrow down a regression to a subset of log rows and columns which can then be further used for mitigation of the issue.” Bansal, page 206, “For each of the nodes, we also compute the following metrics: (1) Row count: Number of training samples in a node. (2) Anomaly probability (Classification trees): Probability of a training sample belonging to the positive (anomalous) class. (3) Predicted value (Regression trees): Average value of the target variable for the samples in a node. As we discuss in the next step, these metrics are used for ranking and triaging the results.” Examiner notes that the incident escalation likelihood are the impact metrics calculated by the model, which is used for ranking and triaging the incidents.)
Chen and Bansal utilize models to generate insights on IT incident data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen to implement computing potential impacts and severity of incidents like Bansal. Doing so would have been advantageous because this allows for ranking the incident, which can lead to incident prioritization which “is critical since it can take anywhere from hours to days to root cause and fix an issue” (Bansal, page 202) and thus doing so would “minimize the time and manual effort in diagnosing and triaging such issues to reduce customer impact” (Bansal, page 201).
Chen and Bansal do not, but Saka teaches
validating, with an Incident Resolution Validation Module, resolution actions taken for the incident against established resolution standards and the generated insights (Saka, page 19, “GPT models can be leveraged to automate regulatory compliance in the construction industry through their NLP and understanding capabilities. These models have the ability to analyze and extract information from construction regulatory textual documents, transforming them into logic clauses that can be used for automated reasoning.”)
including verifying completeness and accuracy of resolution documentation (Saka, page 19, “GPT models can be leveraged to automate regulatory compliance in the construction industry through their NLP and understanding capabilities. These models have the ability to analyze and extract information from construction regulatory textual documents, transforming them into logic clauses that can be used for automated reasoning.” Saka, page 25, “GPT models can be trained with relevant compliance documents, guidelines, and reporting requirements to capture patterns and embedded knowledge. These models can be used in compliance evaluation of facility management activities by comparing new inputs with regulatory requirements to identify non-compliance issues. Similarly, the GPT models can be employed in documentation by highlighting non-compliance issues, providing recommendations, and creating standardized reports to save time and ensure consistency as shown in Figure 8.” Examiner notes that GPT models utilize evaluation algorithms to generate an output.)
Chen, Bansal, and Saka utilize large language models to generate insights on real-world incident data and thus are analogous to the claimed invention. It would also have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen and Bansal to validate compliance of resolution actions and adherence to regulatory standards like Saka. Doing so would have been advantageous because “by automating the compliance checking process, GPT models can significantly reduce the time and effort required for regulatory compliance assessment and serve as an assistant in automated regulatory compliance” (Saka, page 19). Furthermore, “by automating the analysis of regulatory requirements, GPT models can reduce the potential for errors and ensure a higher level of accuracy in compliance” (Saka, page 29).
Chen, Bansal, and Saka do not, but Zhang teaches
calculating, with a Problem Probability Calculation Module, a probability score indicating the likelihood of the incident escalating into a significant problem based on the generated insights and historical incident data, wherein the calculation is based on an incident classification type, severity, impacted IT services, and historical incident resolution success rates (Zhang, page 10, “The formula is as follows:
PNG
media_image1.png
71
150
media_image1.png
Greyscale
where T represents the threat score, n is the total number of hosts in the network system, k is the number of attack types, M is the number of all attacks detected in a period, and Dij is the attack when the i-th host receives the j-th attack the hazard level corresponding to the type, Qi is the importance of the i-th host, and Cij is the number of times the i-th host receives the attack j.”) Zhang, page 24, “The gate recurrent unit (GRU) is a variant of the LSTM network. Moreover, the GRU network is more straightforward in structure than the LSTM network. GRU network controls information updating through gating method. Unlike LSTM, GRU does not introduce additional memory cells. The update gate is an important part of the GRU network. The update gate can control how much information the current evaluation status obtains from the historical evaluation status.” Examiner notes the quantitative probability score is the threat score, wherein an attack with a higher threat level has a higher likelihood of it evolving into a more significant problem. Examiner further notes the generated insights are the attack type, importance of the host, number of hosts. Examiner further notes the historical incident resolution success rates are the historical evaluation status, which is the past information that the network retains to make up the ‘memory’ of the network, and thus is used to calculate threat level by the network.)
Chen, Saka, and Bansal utilize large language models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka and Bansal to calculate and utilize a probability score that represents the likelihood of an incident evolving into a more significant problem like Zhang. Doing so would have been advantageous because having a quantitative assessment of incident severity would allow for more effective prioritization and management of incidents, increasing the efficiency of the system.
Chen, Bansal, Saka, and Zhang do not, but Peshave teaches
recommending, with a Problem Prevention Recommendation Module, preventive actions to mitigate the risk of future incidents based on the calculated probability score, the validated resolution actions, and the insights generated by the Generative Al Inference Module
(Peshave, page 1, “We can accelerate maintenance processes and reduce human effort by automating maintenance recommendation generation using state-of-the-art Technical Language Processing (TLP) methods that analyze large volumes of historical maintenance case data.” Peshave, page 1, “Enhanced methods of remote monitoring and health management-based maintenance optimization have been recognized as key elements to reduce preventive and corrective maintenance costs.” Peshave, page 3, Figure 1, steps 3-6. Peshave, page 4, “Finally, in Step 6, feedback is sent back to APM to inform if the recommended action helped the customer get to the root cause of the problem, mitigate, and disposition the issue correctly.” Examiner notes that maintenance recommendations are a form of preventative actions as they reduce future preventative and corrective costs. Examiner further notes that the recommended actions are the recommendations given in step 4. Examiner further notes that the insights and scores are the alerts generated in step 3, and the validated resolution actions include the feedback of the incident resolution in step 6 given back to the model.)
Chen, Bansal, Saka, and Peshave all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Bansal, and Zhang to recommend preventative actions for incident prevention like Peshave. Doing so would have been advantageous because it would “reduce preventive and corrective maintenance costs” (Peshave, page 1) of the system.
Claim(s) 6-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Peshave and further in view of Saka and further in view of Zhang and further in view of Bansal and further in view of Thompson (US20230388324).
Regarding claim 6, Chen in view of Saka, Zhang, Peshave, and Bansal teach The method of claim 5.
Chen in view of Saka, Zhang, Peshave, and Bansal do not, but Thompson teaches
wherein the IRVM includes a component for automatic generation of compliance reports that document a resolution process, effectiveness of actions taken, and any deviations from established resolution standards (Thompson, paragraph 0256, “In some arrangements, the processing circuits can also provide valuable analytics and reporting capabilities. For example, the processing circuits can track the performance of the cybersecurity protection plans, measure their impact on the entity's security posture, and generate reports that provide insights into the entity's cybersecurity progress.” Thompson, paragraph 0256, “These analytics and reporting capabilities can be particularly valuable in demonstrating the entity's compliance with regulatory requirements or industry standards, as well as in building trust with stakeholders such as customers, partners, or investors.” Examiner notes that demonstrating the compliance with regulatory requirements and industry standards would include deviations from resolution standards.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, and Peshave to automatically generate compliance reports documenting incident details like Thompson. Doing so would have been advantageous because it “can help the entity understand the effectiveness of its…efforts, identify areas for improvement, and make informed decisions about its future…strategy” (Thompson, paragraph 0256).
Regarding claim 7, Chen, Saka, Zhang, Peshave, Bansal, and Thompson teach The method of claim 6. Thompson further teaches
further comprising a step where the system sends notifications to relevant stakeholders, including a summary of the IT service incident, the quantitative probability score, and the recommended preventive actions (Thompson, 0290, “Furthermore, upon completion of the new cybersecurity incident, the processing circuits can generate an incident summary. The summary can include a report that provides an overview of the incident from origination to resolution. It includes performance metrics such as the time to detect the incident, time to respond, time to contain, and time to recover. These metrics can provide insights into the effectiveness and efficiency of the entity's incident response process. Origination details can provide information about the source of the incident, its nature, and how it infiltrated the entity's defenses, which can be crucial for future prevention strategies. The incident timeline can be a chronological representation of the incident's progression and the response activities, providing a clear picture of the incident's lifecycle. The incident summary can be provided to the entity and relevant stakeholders, serving as a valuable resource for post-incident reviews, improvement of security strategies, and compliance reporting.” Thompson, paragraph 0264, “In the event of a potential incident, the processing circuits can alert the entity and the vendor, providing detailed information about the incident's nature, scope, and potential impact.” Examiner notes the quantitative probability score is the incident scope/impact. Examiner further notes the summary includes response activities, which are the recommended preventive actions.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, and Peshave to send notifications regarding incident details to stakeholders like Thompson. Doing so would have been advantageous because it can “streamline the incident response process and enable better collaboration between all stakeholders” (Thompson, paragraph 0044).
Regarding claim 8, Chen, Saka, Zhang, Peshave, Bansal, and Thompson teach The method of claim 7. Saka further teaches
wherein the system integrates with external databases and incident management tools to enrich incident data analysis, leveraging external sources of information to enhance accuracy of the classification, the inference generation, and the quantitative probability score (Saka, page 30, “In this context, GPT models offer promising opportunities to streamline and enhance environmental impact assessment and management processes. These models have the capability to analyze vast amounts of data from diverse sources, including environmental databases, scientific literature, and historical project data.”)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, Peshave, and Thompson to integrate external databases and other sources of information like Saka. Doing so would have been advantageous because leveraging external databases allows the model to access specialized knowledge on the domain without breaching company privacy. Furthermore, “progress reports or status updates can be easily generated based on the extracted data from the project documentation” (Saka, page 22).
Regarding claim 9, Chen, Saka, Zhang, Peshave, and Bansal teach The method of claim 8. Chen further teaches
further comprising a user interface module that allows users to manually review and adjust the classifications, probability scores, and recommendations generated by the system, ensuring that human judgment can be applied for supervision (Chen, page 6, “Driven by Insight-1 in Section 3, RCACopilot aims to collect multi-source data for RCA. Specifically, for each alert type, an incident handler is constructed, comprising a series of actions to collect diagnostic information. Alert types are used to categorize alerts based on specific monitors and thresholds. Incidents sharing the same alert type exhibit similar symptoms, though they may stem from different root causes. The RCACopilot incident handler is a workflow that consists of a series of actions. Each action is a function that can be executed to collect specific diagnostic information from a target data source. OCEs can build and modify these handlers based on their expertise. The handler includes three distinct actions: scope switching action, query action, and mitigation action, which will be explained in Section 4.1.2. Each action generates an output, guiding the control flow of the incident handler.” Chen, page 6, “RCACopilot’s incident handlers can be updated and modified dynamically by OCEs, allowing them to stay abreast with the most recent system changes and newly discovered root causes. For instance, when a new metric is introduced into the system, OCEs only need to construct a new action to collect the relevant data and incorporate it into the corresponding incident handler, which can ensure timely adaptation.” Examiner notes that incident handlers are the data sources used by the model, and contain relevant details including the type (classification) and mitigation actions (recommendations) for each incident. Examiner further notes that the users are the OCEs, which are on-call engineers that can modify the handlers.)
Claim(s) 10-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Peshave and further in view of Saka and further in view of Zhang and further in view of Bansal and further in view of Thompson and further in view of Huang et al. (“FirewaLLM: A Portable Data Protection and Recovery Framework for LLM Services”).
Regarding claim 10, Chen, Saka, Zhang, Peshave, Bansal, and Thompson teach The method of claim 9.
Chen, Saka, Zhang, Peshave, Bansal, and Thompson do not, but Huang teaches wherein the system employs advanced encryption and security measures to protect integrity and confidentiality of the incident data, ensuring that data processing and communications are secure from unauthorized access (Huang, page 19, “since big language models are trained on massive textual data [26], these data may contain a variety of sensitive information, such as personal identities, health conditions, financial accounts, and so on. If this information is leaked or misused, it may bring serious privacy damages and legal risks to users [8].” Huang, page 19, “In response to these problems, there are already some technologies and methods that are being explored and applied, such as multi-party secure computing, homomorphic encryption, differential privacy, etc. [5]. They can perform computation and analysis without exposing the original data, or increasing the randomness and untraceability of data while ensuring data availability.” Examiner notes that the advanced encryption is the homomorphic encryption.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. Huang encrypts and secures data from real-world sources in a neural network environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, Peshave, and Thompson to encrypt and secure the incident data like Huang. Doing so would have been advantageous because “since big language models are trained on massive textual data [26], these data may contain a variety of sensitive information, such as personal identities, health conditions, financial accounts, and so on. If this information is leaked or misused, it may bring serious privacy damages and legal risks to users [8]” (Huang, page 19), and therefore encrypting data would lead to “improving the security and privacy of data and models” (Huang, page 19).
Regarding claim 11, Chen, Saka, Zhang, Peshave, Bansal, and Huang teach The method of claim 10. Chen further teaches
further comprising utilizing machine learning algorithms within the GAIM to identify patterns and correlations in the incident data that were previously unrecognized, thereby enhancing predictive capabilities of the system over time through continuous learning (Chen, page 3, “Data Analysis: The collected data is then analyzed to identify patterns, anomalies, or correlations that can possibly provide clues about the root cause of the incident.”)
Regarding claim 12, Chen, Saka, Zhang, Peshave, Bansal, and Huang teach The method of claim 11. Saka further teaches
including a benchmarking step where the system compares the effectiveness of the incident resolution and preventive measures against industry standards and metrics, facilitating ongoing improvement and adherence to best practices (Saka, page 21, “Quality control and assurance ensure that the quality of project is in tandem with objectives and established standards whilst also mitigating errors and defects. GPT models can be employed in planning and organizing inspection and testing activities based on defined project requirements and familiarization with principles (quality control and assurance in the construction industry). GPT can be used to identify anomalies in quality data, suggest best practices standards for preventive and corrective actions and assist in quality documentation (management, technical and general procedure manual and policy manual).”)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. Huang encrypts and secures data from real-world sources in a neural network environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, Peshave, Thompson, and Huang to compare the effectiveness of the incident resolution against industry standards and metrics like Saka. Doing so would have been advantageous because “by automating the compliance checking process, GPT models can significantly reduce the time and effort required for regulatory compliance assessment and serve as an assistant in automated regulatory compliance” (Saka, page 19), and furthermore “by automating the analysis of regulatory requirements, GPT models can reduce the potential for errors and ensure a higher level of accuracy in compliance” (Saka, page 29).
Regarding claim 13, Chen, Saka, Zhang, Peshave, Bansal, Thompson, and Huang teach The method of claim 12. Chen further teaches
wherein the IVCM is further configured to automatically update classification criteria based on evolving IT service landscapes and emerging threat vectors, ensuring that the module remains effective in identifying and categorizing incidents (Chen, page 9, “By drawing inspiration from this concept, we can view the summarized diagnostic information and the labeled root cause categories as questions and reasoning, so finding the nearest incident neighbor is the automatic reasoning chain construction, aligning with the CoT prompting context well. We construct the prompt like Figure 9 to ask the LLM to choose the most likely incident that has the same root cause as the current incident, and also we explicitly push the LLM to reason by using “give your explanation” indications in the prompt” Chen, page 9, “To facilitate the building of the RCACopilot incident handler, we have implemented RCACopilot’s handler construction as a web application. To support a new type of alert in RCACopilot, OCEs only need to add a new handler in the handler construction GUI according to her expertise (see Appendix A). After the new handler has been constructed, it will be stored in the database, and OCEs can modify it by creating new action nodes or deleting old nodes.” Examiner notes that incidents are categorized by the LLM based on the nearest incident neighbor in the model database, and the model database is updated by new incident handlers to account for new emerging threats, so the model automatically updates classification criteria via new handlers in the database after each update.)
Regarding claim 14, Chen, Saka, Zhang, Peshave, Bansal, Thompson, and Huang teach The method of claim 13. Thompson further teaches
wherein the system incorporates an analytics dashboard that provides visualizations of key metrics including incident frequency, resolution times, effectiveness of preventive actions, and trends in the probability scores. (Thompson, paragraph 0225, “Referring now to FIG. 17, an incident summary dashboard 1700 that includes an overview of incidents of the entity. The dashboard 1700 includes various graphical representations 1702, illustrating metrics such as the total number of cases handled, the cumulative cost of remediation, and the percentage of incidents involving ransom payments.” Thompson, Fig. 17. Examiner notes incident frequency is the Cases by Root Cause section on the left of Fig. 17, which show each type of case and how many times they have occurred. Frequency can further be found by the graph at the top which shows dates and months of the year in which incidents have occurred. Examiner further notes that resolution times are the Remediation Times on the right of Fig. 17, effectiveness of preventative actions could be inferred by the number and remediation time of incidents, as more effective preventative actions would lead to less incidents and quicker resolutions of that type. Examiner further notes that trends in the probability scores are shown by the Total Case Cost graph at the top of Fig. 17, where the probability scores are the case costs, which directly correlate to how severe an incident is.)
Chen, Saka, Peshave, and Bansal all utilize models to generate insights on real-world incident data and thus are analogous to the claimed invention. Zhang uses a neural network to assess security levels in an IT environment and thus is also analogous to the claimed invention. Thompson utilizes a system for generating incident details gathered from a real-world environment and thus is also analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Saka, Zhang, Bansal, and Peshave to utilize a visual dashboard that allow the user to view key metrics like Thompson. Doing so would have been advantageous because “These metrics provide a high-level overview of the entity's cybersecurity incident history, enabling a quick evaluation of the overall situation” (Thompson, paragraph 0225). Furthermore, the summary “can be provided to the entity and relevant stakeholders, serving as a valuable resource for post-incident reviews, improvement of security strategies, and compliance reporting” (Thompson, paragraph 0290).
Claim(s) 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Bansal.
Regarding claim 15, Chen teaches
A system for managing and mitigating information technology (IT) service incidents, comprising: a processor and a memory storing instructions that, when executed by the processor, enable the system to perform operations including (Chen, page 10, “All experiments are performed on the server with Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz, 32.0 GB physical memory, and Intel UHD Graphics 630. The OS of the server is Windows 11 Enterprise.”)
receiving incident data (Chen, page 1, “We evaluate RCA Copilot using a real-world dataset consisting of a year’s worth of incidents from Transport service in Microsoft.”)
utilizing an Incident Validation and Classification Module with natural language processing capabilities to validate and classify incidents (Chen, pages 9-10, “RCACopilot achieves 0.766 and 0.533 for Micro-F1 and Macro-F1 separately when predicting the root cause category of cloud incidents, outperforming all our baselines with a low running overhead (4.205 seconds). RCACopilot is also able to generate new root cause category labels for unseen incidents with explanations.” Chen, page 4, “Specifically, each incident was carefully reviewed and categorized based on the characteristics of the problem, the source of the issue, and the impact on the system by our experienced OCEs.” Examiner notes the incident data is carefully reviewed and categorized based on a variety of predefined criteria.)
employing a Generative Al Inference Module that leverages large language models for generating insights (Chen, page 2, “We introduce the integration of a large language model within RCACopilot that autonomously analyzes the collected diagnostic data to predict incident root cause categories and generate explanations, demonstrating the potential of the large language model in enhancing RCA.” Chen, page 6, “Root cause prediction stage: Once the diagnostic information is collected, RCACopilot transitions into the root cause prediction stage. In this phase, RCACopilot applies its predictive module to determine the likely root cause category of the incident.” Chen, page 7, “For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 7, “Mitigation action: This action refers to the strategic steps suggested to alleviate an incident, such as “restart service” or “engage other teams”, as depicted in Figure 5.”)
implementing an Incident Resolution Validation Module for resolution effectiveness assessment (Chen, page 12, “We conducted three rounds of experiments to evaluate RCACopilot’s effectiveness.”)
engaging a Problem Prevention Recommendation Module for actionable preventive measures (Chen, page 7, “For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 7, “Mitigation action: This action refers to the strategic steps suggested to alleviate an incident, such as “restart service” or “engage other teams”, as depicted in Figure 5.” Examiner notes the model gives mitigation actions, which could fall under actionable preventive measures.
and updating a knowledge database with incident insights and recommendations (Chen, page 6, “Diagnostic information collection stage: This is the initial stage, where the incident is parsed and matched to the pre-defined incident handler. Each handler is tailored to a specific alert type. Upon matching the incident with the appropriate handler, RCACopilot proceeds to collect relevant diagnostic data from a variety of sources.” Chen, page 6, “The handler includes three distinct actions: scope switching action, query action, and mitigation action.” Chen, page 7, “Query action: Query action can query data from different sources and output the query result as a key-value pair table. This type of action can also be hooked to executing a specific script with pre-defined parameters. Usually, scripts are internal automatic investigation tools for a service, and only the service team has access to the tools. For instance, in Figure 5, the “Known issue?” action node queries the database to see whether the current incident is a known one or not based on its alert messages. If it is a known issue, execution flow will enter the “True” branch to give mitigation actions directly.” Chen, page 9, “To facilitate the building of the RCACopilot incident handler, we have implemented RCACopilot’s handler construction as a web application. To support a new type of alert in RCACopilot, OCEs only need to add a new handler in the handler construction GUI according to her expertise (see Appendix A). After the new handler has been constructed, it will be stored in the database, and OCEs can modify it by creating new action nodes or deleting old nodes.” Examiner notes that incident handlers are updated by the system into a dynamic database to be used by the model, and an incident handler consists of generated inferences (insights) and mitigation actions (recommendations)).
Chen does not, but Bansal teaches
using a Problem Probability Calculation Module to compute incident escalation likelihood (Bansal, page 204, “Goal: With DeCaf, our goal was to build a system which can automatically help the DevOps engineers narrow down a performance regression to a subset of requests. So, for each identified issue, it outputs a root-cause which consist of a set of predicates along with impact metrics and a triage category. These predicates help narrow down a regression to a subset of log rows and columns which can then be further used for mitigation of the issue.” Bansal, page 206, “For each of the nodes, we also compute the following metrics: (1) Row count: Number of training samples in a node. (2) Anomaly probability (Classification trees): Probability of a training sample belonging to the positive (anomalous) class. (3) Predicted value (Regression trees): Average value of the target variable for the samples in a node. As we discuss in the next step, these metrics are used for ranking and triaging the results.” Examiner notes that the incident escalation likelihood are the impact metrics calculated by the model, which is used for ranking and triaging the incidents.)
Chen and Bansal utilize models to generate insights on IT incident data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen to implement computing an incident escalation likelihood like Bansal. Doing so would have been advantageous because this allows for ranking the incident, which can lead to incident prioritization which “is critical since it can take anywhere from hours to days to root cause and fix an issue” (Bansal, page 202) and thus doing so would “minimize the time and manual effort in diagnosing and triaging such issues to reduce customer impact” (Bansal, page 201).
Regarding claim 16, Chen and Bansal teach The system of claim 15. Bansal further teaches
further configured to prioritize incident handling based on severity and urgency determined by the Incident Validation and Classification Module (Bansal, page 201, “In this paper, we present the design, implementation and experience from building and deploying DeCaf, a system for automated diagnosis and triaging of KPI issues using service logs.” Bansal, page 202, “Triaging is the process of prioritizing and determining which issue should be investigated and subsequently fixed. This is critical since it can take anywhere from hours to days to root cause and fix an issue. DevOps engineers consider various factors while triaging issues: (a) What is the impact of the issue? How many customers or requests are being impacted? (b) Is the issue localized or global? (c) Is it a known issue? If yes, has the impact increased? (d) Has this issue occurred in the past? Triaging performance issues is non-trivial because engineers have to estimate the scope and impact of issues by taking into account historical data.” Examiner notes that the issues are prioritized based on impact of the issue and thus are prioritized based on severity and urgency.)
wherein a prioritization algorithm dynamically adjusts resource allocation and response times to ensure critical incidents are addressed promptly (Bansal, page 202, “Triaging is the process of prioritizing and determining which issue should be investigated and subsequently fixed.” Examiner notes response times are quicker for more critical incidents because they are prioritized first.)
Chen and Bansal utilize models to generate insights on IT incident data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen to implement incident prioritization like Bansal. Doing so would have been advantageous because prioritization “is critical since it can take anywhere from hours to days to root cause and fix an issue” (Bansal, page 202) and thus doing so would “minimize the time and manual effort in diagnosing and triaging such issues to reduce customer impact” (Bansal, page 201).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Bansal and further in view of Thompson.
Regarding claim 17, Chen and Bansal teach The system of claim 16. Chen and Bansal do not, but Thompson teaches
The system of claim 16, wherein the Generative Al Inference Module integrates external data sources including cybersecurity threat intelligence feeds (Thompson, paragraph 0267, “In addition to the aforementioned capabilities, some arrangements may leverage generative artificial intelligence (AI) algorithms to enhance the security posture analysis. Generative AI algorithms can analyze large volumes of data from various sources, such as threat intelligence feeds, incident reports, and security best practices, to identify patterns, trends, and potential vulnerabilities that human analysts may not have detected.”
and IT service management logs, to enrich predictive insights with context-specific information, enhancing accuracy and relevance of the generated inferences (Thompson, paragraph 0121, “In some implementations, the IRC system 138 can collect and aggregate relevant data. This can include gathering information from various sources such as incident reports, security logs, system alerts, and user-generated data. The IRC system 138 employs data collection mechanisms to capture and centralize this information, ensuring that incident responders have a comprehensive and consolidated view of the incident landscape.”)
Chen, Bansal, and Thompson utilize models to generate insights on IT incident data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen and Bansal to use external data sources including threat intelligence feeds and IT management logs like Thompson. Doing so would have been advantageous because “By monitoring this data, the processing circuits can maintain an updated understanding of the entity's cybersecurity status” (Thompson, paragraph 0279).
Regarding claim 18, Chen, Bansal, and Thompson teach The system of claim 17. Chen and Bansal, and Thompson do not, but Peshave teaches
further comprising a feedback mechanism that captures user feedback on resolution outcomes and preventive recommendations, wherein the feedback is utilized by the Problem Prevention Recommendation Module to refine and personalize future preventive actions, ensuring continuous improvement in incident prevention strategies (Peshave, page 1, “We can accelerate maintenance processes and reduce human effort by automating maintenance recommendation generation using state-of-the-art Technical Language Processing (TLP) methods that analyze large volumes of historical maintenance case data.” Peshave, page 1, “Enhanced methods of remote monitoring and health management-based maintenance optimization have been recognized as key elements to reduce preventive and corrective maintenance costs.” Peshave, page 3, Figure 1. Peshave, page 4, “In Step 5 of the workflow, customers at the plant would then generate a work order to review, investigate, and perform any corrective actions. Finally, in Step 6, feedback is sent back to APM to inform if the recommended action helped the customer get to the root cause of the problem, mitigate, and disposition the issue correctly.” Examiner notes that maintenance recommendations are a form of preventative actions as they reduce future preventative and corrective costs. Examiner further notes the feedback that is sent back to the model is based on whether the customer was able to successfully resolve the incident and thus is user feedback.)
Chen, Bansal, Thompson, and Peshave all utilize models to generate insights on real-world data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Bansal and Thompson to recommend preventative actions like Peshave based on user feedback. Doing so would have been advantageous because it would “reduce preventive and corrective maintenance costs” (Peshave, page 1) of the system.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Bansal and further in view of Thompson and further in view of Peshave.
Regarding claim 19, Chen, Bansal, Thompson, and Peshave teach The system of claim 18. Thompson further teaches
equipped with a user interface that provides administrators and IT personnel with real-time dashboards, incident reports, and actionable analytics, enabling efficient monitoring, management, and decision-making based on the insights generated. (Thompson, paragraph 0225, “Referring now to FIG. 17, an incident summary dashboard 1700 that includes an overview of incidents of the entity. The dashboard 1700 includes various graphical representations 1702, illustrating metrics such as the total number of cases handled, the cumulative cost of remediation, and the percentage of incidents involving ransom payments.” Thompson, Fig. 17.)
Chen, Bansal, Thompson, and Peshave all utilize models to generate insights on real-world data and thus are analogous to the claimed invention. It would have been obvious to one having ordinary skill in the art prior to the effective filing date of the application to have modified Chen in view of Bansal and Peshave to utilize an user interface for viewing incident reports and analytics like Thompson. Doing so would have been advantageous because it “offers real-time (or near real-time) status tracking of policy aligned tasks to status updates provided for incident response, enabling users to quickly and easily see how their incident response plan is progressing” (Thompson, paragraph 0042). Furthermore, it can “enable users to identify areas for improvement in their incident response plan and make changes as necessary” (Thompson, paragraph 0042).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ahmed et al. (“Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models”) generates root cause and mitigation/resolution steps for cloud incidents using large language models.
Mashhadi et al. (“Method-Level Bug Severity Prediction using Source Code Metrics and LLMs”) predicts incident and bug severity levels using LLMs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zared O. Cohen whose telephone number is (571)270-0531. The examiner can normally be reached M-Th, 8am to 5pm ET.
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, Michelle Bechtold can be reached at (571) 431-0762. 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.
/Z.O.C./Examiner, Art Unit 2148 /MICHELLE T BECHTOLD/Supervisory Patent Examiner, Art Unit 2148
Prosecution Insights