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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) mental processes – concepts performed in the human mind.
Regarding claim 1, the claim is directed to mental processes.
The limitations ‘identifying a portion of the data indicative of a defect in a software system; identifying, from stored records associated with the known defect, a solution’ are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Step 2A: Prong two
This judicial exception is not integrated into a practical application because the additional elements ‘determining, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect’ is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)). The machine learning model is recited at a high-level of generality and provides no specifics of the machine learning model besides being used to perform the ‘determining’.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements ‘receiving an event log associated with a software application, the event log including data indicative of an error event; causing at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system; and generating a defect record indicating the portion of the data, the at least part of the solution implemented, and the modification of the software system’ are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)). The ‘receiving’ is data gathering. The ‘causing’ is merely performing solution activity for correcting an error. The ‘generating’ is merely categorizing information for a defect record.
Regarding claim 2, the limitations ‘where the solution is a first solution’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)), the method further comprising: ‘receiving an additional event log associated with an additional error event’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘determining an additional defect associated with the additional event log’ – is a mental process – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion; ‘receiving an indication that the additional defect correlates to an unresolved defect identified in a defects database’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘receiving a second solution for the unresolved defect’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); and storing, in the defects database, an association between the unresolved defect and the second solution - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
Regarding claim 3, the limitation ‘generating a task to request review for the at least part of the solution implemented as indicated in the defect record’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); ‘receiving a review result’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); and ‘creating training data that includes the defect record labeled with the review result’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
Regarding claim 4, the limitations ‘generating a notification for the task; publishing the notification to a subscriber of events associated with the software application; and sending the notification to a device associated with the subscriber’ are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 5, the limitations ‘generating, by the ML model, a confidence score associated with the defect correlating to the known defect’ – is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); and ‘determining that the confidence score is greater than a threshold score, wherein the determination that the defect correlates to the known defect is based on determining that the confidence score is greater than the threshold score’ - are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Regarding claim 6, the limitations ‘storing the defect record in a defects database’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); ‘generating a user interface including a query tool for the defects database; receiving, via the query tool of the user interface, a query indicating one of an error type or an error message; and retrieving, from the defects database, one or more defect records associated with the query’ - are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 7, the limitations ‘determining, based at least in part on the event log, a developer identifier associated with the error event and a stage of development cycle associated with the software application’ – is a mental process – concept performed in the human mind by observation, evaluation, judgment, and/or opinion; and ‘providing an alert notification to a user account associated with the developer identifier’ is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 8, the limitations ‘determining, based on the stored records associated with the known defect, a count of defect records associated with the known defect; determining that the count of defect records exceeds a threshold; and based on determining that the count exceeds the threshold, increasing a priority level associated with the defect record’ are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Regarding claim 9, the limitations ‘wherein the data includes at least one of: an error type, an error message, a sequence log, a response time of a request, a sequence code, a stack trace, an exposed endpoint, an application identifier, a developer identifier, a stage of development cycle, or a severity level’ is mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion of indicating the type of data to retrieve.
Regarding claim 10, the limitations ‘receiving an additional event log associated with an additional error event’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘determining an additional defect associated with the additional event log; determining that the additional defect is correlated with the defect; and based on determining that the additional defect is correlated with the defect, associating, in a defects database, the additional defect with the defect record’ - are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Regarding claim 11, with the exception of the limitations ‘processor; and a non-transitory computer-readable media storing a plurality of software components that, when executed by the processor, causes the processor to perform operations’, the claim is directed to mental processes.
The limitations ‘identifying a portion of the data indicative of a defect in a software system; identifying, from stored records associated with the known defect, a solution’ are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Step 2A: Prong two
This judicial exception is not integrated into a practical application because the additional elements ‘a processor; and a non-transitory computer-readable media storing a plurality of software components that, when executed by the processor, causes the processor to perform operations; determining, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect’ are directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)). The machine learning model is recited at a high-level of generality and provides no specifics of the machine learning model besides being used to perform the ‘determining’.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements ‘receiving, from one or more computing devices, an event log associated with a software application, the event log including data indicative of an error event; causing at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system; and generating a defect record indicating the portion of the data, the at least part of the solution implemented, and the modification of the software system’ are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)). The ‘receiving’ is data gathering. The ‘causing’ is merely performing solution activity for correcting an error. The ‘generating’ is merely categorizing information for a defect record.
Regarding claim 12, the limitations ‘receiving an additional event log associated with an additional error event’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘determining an additional defect associated with the additional event log’ – is a mental process – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion; ‘receiving an indication that the additional defect correlates to an unresolved defect identified in a defects database’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘receiving a second solution for the unresolved defect’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); and storing, in the defects database, an association between the unresolved defect and the second solution - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
Regarding claim 13, the limitations ‘determining, based at least in part on the event log, that the error event is associated with a first development team’ - are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion; and ‘based on determining that the error event is associated with the first development team, storing the defect record in a first database associated the first development team’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
.
Regarding claim 14, the limitations ‘generating a task to request review for the at least part of the solution implemented as indicated in the defect record’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); ‘receiving a review result’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); and ‘creating training data that includes the defect record labeled with the review result’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
Regarding claim 15, the limitations ‘wherein generating the task further comprises: generating a notification for the task; publishing the notification to a subscriber of events associated with the software application; and sending the notification to a device associated with the subscriber’ are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 16, the limitations ‘storing the defect record in a defects database’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); ‘generating a user interface including a query tool for the defects database; receiving, via the query tool of the user interface, a query indicating one of an error type or an error message; and retrieving, from the defects database, one or more defect records associated with the query’ - are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 17, with the exception of the limitations ‘A tangible, non-transitory computer-readable medium storing executable instructions that, when executed by a processor of a system, cause the processor to’, the claim is directed to mental processes.
The limitations ‘identify a portion of the data indicative of a defect in a software system; identify, from stored records associated with the known defect, a solution’ are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion.
Step 2A: Prong two
This judicial exception is not integrated into a practical application because the additional elements ‘A tangible, non-transitory computer-readable medium storing executable instructions that, when executed by a processor of a system, cause the processor to; determine, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect’ are directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)). The machine learning model is recited at a high-level of generality and provides no specifics of the machine learning model besides being used to perform the ‘determining’.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements ‘receive an event log associated with a software application, the event log including data indicative of an error event; cause at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system; and generate a defect record indicating the portion of the data, the at least part of the solution implemented, and the modification of the software system’ are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)). The ‘receiving’ is data gathering. The ‘causing’ is merely performing solution activity for correcting an error. The ‘generating’ is merely categorizing information for a defect record.
Regarding claim 18, the limitations ‘receive an additional event log’ – is directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)); ‘determine that an additional defect associated with the additional event log is correlated with the defect’ - is a mental process – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion; ‘based on determining that the additional defect is correlated with defect, associating, in a defects database, the additional defect with the defect record’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)).
Regarding claim 19, the limitations ‘store the defect record in a defects database’ - is directed to generic computer components recited at a high-level of generality such that they amount to nothing more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)); ‘generate a user interface including a query tool for the defects database; receive, via the query tool of the user interface, a query indicating one of an error type or an error message; and retrieve, from the defects database, one or more defect records associated with the query’ - are directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Regarding claim 20, the limitations ‘determine, based at least in part on the event log, a developer identifier associated with the error event’ - are mental processes – concepts performed in the human mind by observation, evaluation, judgment, and/or opinion; and ‘provide an alert notification to at least a user account associated with the developer identifier’ - directed to adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) are rejected under 35 U.S.C. 103 as being unpatentable over Sachan et al. (USPN 20200293946A1) in view of Ramakrishna et al. (USPN 20180121808A1) in further view of Balasubramanian et al. (USPN 20200409825A1).
As per claim 1, Sachan et al. discloses a method, comprising: receiving an event log associated with a software application, the event log including data indicative of an error event (paragraph 0040 – analyze an issue associated with operation of an application and paragraph 0042 – determine whether the issue includes a potential to turn into an incident);
identifying a portion of the data indicative of a defect in a software system (paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
determining, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect (paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description) are known and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
causing at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system (in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g.,extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model); and
generating a defect record indicating the portion of the data (paragraph 0023 - If the incident is actionable, a machine learning based incident ticket creation and routing model may be used to generate an incident ticket associated with the incident, and determine support personnel selected from a plurality of support personnel to resolve the incident ticket. Recommendations that include an incident nature recommendation, an incident resolution recommendation, and an incident knowledge base article recommendation may be generated for the selected support personnel; storing the defect ticket in the defects database in paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.).
Sachan et al. fails to explicitly state identifying, from stored records associated with the known defect, a solution.
Sachan does disclose in paragraph 0034 – machine learning based automated
incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident
resolution recommendation that includes the resolution and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.
Ramakrishna et al. discloses identifying a solution of the resolved defect
indicated in the defects database in paragraph 0040 - The server predicts a corrective action using the one or more reported symptoms as input to a machine learning model. The machine learning model is trained using a history of observed symptoms in the network, a history of corrective actions initiated via chatbot sessions and associated with the observed symptoms, and a history of feedback regarding the corrective actions received via the chatbot sessions. The server provides the predicted corrective action to
the user interface via the particular chatbot session as a suggested corrective action, in
response to the received triage request.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include the machine learning model
predicting the corrective action taken from previous reported symptoms with associated
corrective action of Ramakrishna in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the corrective actions
are based upon similar symptoms/solutions previously experienced as disclosed in
paragraph 0063.
Sachan et al. and Ramakrishna et al. fail to explicitly state generating a defect record indicating the at least part of the solution implemented, and the modification of the software system.
Sachan does disclose in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident resolution recommendation that includes the resolution.
Balasubramanian et al. discloses generating a defect record indicating the at least part of the solution implemented, and the modification of the software system in paragraph 0165 - At step 1425, the monitoring device may update the incident/event record to indicate corrective action taken by a system administrator. The monitoring device may detect that the system administrator took certain corrective action in response to the unhealthy operating status of the monitored application or other service, and may add this corrective action in association with the event record. The corrective action may become associated with the cluster of events that corresponds to the event detected in step 1415. Additionally, and/or alternatively, the monitoring device may detect the corrective action through continuous monitoring, detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system after detection of the unhealthy status event.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include updating the incident/event record to indicate corrective action and including detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system of Balasubramanian in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the incident/event record is used to recommend similar action in future unhealthy operating status events, as disclosed in paragraph 0166.
As per claim 9, Sachan et al. discloses wherein the data includes at least one of: an error type – paragraph 0196 – issue type, an error message, a sequence log, a response time of a request, a sequence code, a stack trace, an exposed endpoint, an application identifier, a developer identifier, a stage of development cycle, or a severity level – paragraph 0024,0196 – severity of an incident.
As per claim 11, Sachan et al. discloses a system comprising: a processor (paragraph 0040 – hardware processor); and a non-transitory computer-readable media storing a plurality of software components that (paragraph 0038 – processor executable instructions stored on a non-transitory machine-readable storage medium), when executed by the processor, causes the processor to perform operations comprising: receiving, from one or more computing devices, an event log associated with a software application, the event log including data indicative of an error event (paragraph 0040 – analyze an issue associated with operation of an application and paragraph 0042 – determine whether the issue includes a potential to turn into an incident);
identifying a portion of the data indicative of a defect in a software system (paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
determining, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect (paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description) are known and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
causing at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system (in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g.,extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model); and
generating a defect record indicating the portion of the data (paragraph 0023 - If the incident is actionable, a machine learning based incident ticket creation and routing model may be used to generate an incident ticket associated with the incident, and determine support personnel selected from a plurality of support personnel to resolve the incident ticket. Recommendations that include an incident nature recommendation, an incident resolution recommendation, and an incident knowledge base article recommendation may be generated for the selected support personnel; storing the defect ticket in the defects database in paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.).
Sachan et al. fails to explicitly state identifying, from stored records associated with the known defect, a solution.
Sachan does disclose in paragraph 0034 – machine learning based automated
incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident
resolution recommendation that includes the resolution and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.
Ramakrishna et al. discloses identifying a solution of the resolved defect
indicated in the defects database in paragraph 0040 - The server predicts a corrective action using the one or more reported symptoms as input to a machine learning model. The machine learning model is trained using a history of observed symptoms in the network, a history of corrective actions initiated via chatbot sessions and associated with the observed symptoms, and a history of feedback regarding the corrective actions received via the chatbot sessions. The server provides the predicted corrective action to
the user interface via the particular chatbot session as a suggested corrective action, in
response to the received triage request.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include the machine learning model
predicting the corrective action taken from previous reported symptoms with associated
corrective action of Ramakrishna in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the corrective actions
are based upon similar symptoms/solutions previously experienced as disclosed in
paragraph 0063.
Sachan et al. and Ramakrishna et al. fail to explicitly state generating a defect record indicating the at least part of the solution implemented, and the modification of the software system.
Sachan does disclose in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident resolution recommendation that includes the resolution.
Balasubramanian et al. discloses generating a defect record indicating the at least part of the solution implemented, and the modification of the software system in paragraph 0165 - At step 1425, the monitoring device may update the incident/event record to indicate corrective action taken by a system administrator. The monitoring device may detect that the system administrator took certain corrective action in response to the unhealthy operating status of the monitored application or other service, and may add this corrective action in association with the event record. The corrective action may become associated with the cluster of events that corresponds to the event detected in step 1415. Additionally, and/or alternatively, the monitoring device may detect the corrective action through continuous monitoring, detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system after detection of the unhealthy status event.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include updating the incident/event record to indicate corrective action and including detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system of Balasubramanian in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the incident/event record is used to recommend similar action in future unhealthy operating status events, as disclosed in paragraph 0166.
receiving, from one or more computing devices, an event log associated with a software application, the event log including data indicative of an error event; identifying a portion of the data indicative of a defect in a software system; determining, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect; identifying, from stored records associated with the known defect, a solution; causing at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system; and generating a defect record indicating the portion of the data, the at least part of the solution implemented, and the modification of the software system.
As per claim 17, Sachan et al. a tangible, non-transitory computer-readable medium storing executable instructions that (paragraph 0038 – processor executable instructions stored on a non-transitory machine-readable storage medium), when executed by a processor of a system, cause the processor to: receive an event log associated with a software application, the event log including data indicative of an error event (paragraph 0040 – analyze an issue associated with operation of an application and paragraph 0042 – determine whether the issue includes a potential to turn into an incident);
identify a portion of the data indicative of a defect in a software system (paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
determine, by inputting the portion of the data into a machine learning (ML) model, that the defect correlates to a known defect (paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description) are known and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database);
cause at least a part of the solution to be implemented by the software system, wherein the implementation results in a modification of the software system (in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g.,extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model); and
generate a defect record indicating the portion of the data (paragraph 0023 - If the incident is actionable, a machine learning based incident ticket creation and routing model may be used to generate an incident ticket associated with the incident, and determine support personnel selected from a plurality of support personnel to resolve the incident ticket. Recommendations that include an incident nature recommendation, an incident resolution recommendation, and an incident knowledge base article recommendation may be generated for the selected support personnel; storing the defect ticket in the defects database in paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.).
Sachan et al. fails to explicitly state identify, from stored records associated with the known defect, a solution.
Sachan does disclose in paragraph 0034 – machine learning based automated
incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident
resolution recommendation that includes the resolution and paragraph 0117 – each time an incident is created by the issue analyzer this information may be stored in a relational database and information related to an incident, such as, description and other technical details may be stored in the relational database.
Ramakrishna et al. discloses identify a solution of the resolved defect
indicated in the defects database in paragraph 0040 - The server predicts a corrective action using the one or more reported symptoms as input to a machine learning model. The machine learning model is trained using a history of observed symptoms in the network, a history of corrective actions initiated via chatbot sessions and associated with the observed symptoms, and a history of feedback regarding the corrective actions received via the chatbot sessions. The server provides the predicted corrective action to
the user interface via the particular chatbot session as a suggested corrective action, in
response to the received triage request.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include the machine learning model
predicting the corrective action taken from previous reported symptoms with associated
corrective action of Ramakrishna in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the corrective actions
are based upon similar symptoms/solutions previously experienced as disclosed in
paragraph 0063.
Sachan et al. and Ramakrishna et al. fail to explicitly state generate a defect record indicating the at least part of the solution implemented, and the modification of the software system.
Sachan does disclose in paragraph 0034 – machine learning based automated incident resolution model predicts that the information supplied to it is a potential candidate of turning into an incident, a determination may be made as to whether automated resolution has been configured to resolve this scenario and this determination may be made on the basis of incidents whose resolution steps (e.g., extensive configuration based solution mapping based on the incident number and incident description and paragraph 0041 – the automated incident resolver implemented automated resolution by way of the machine learning based automated incident resolution model and paragraph 0141 – is an image of display data to shows an incident resolution recommendation that includes the resolution.
Balasubramanian et al. discloses generate a defect record indicating the at least part of the solution implemented, and the modification of the software system in paragraph 0165 - At step 1425, the monitoring device may update the incident/event record to indicate corrective action taken by a system administrator. The monitoring device may detect that the system administrator took certain corrective action in response to the unhealthy operating status of the monitored application or other service, and may add this corrective action in association with the event record. The corrective action may become associated with the cluster of events that corresponds to the event detected in step 1415. Additionally, and/or alternatively, the monitoring device may detect the corrective action through continuous monitoring, detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system after detection of the unhealthy status event.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include updating the incident/event record to indicate corrective action and including detecting that a change to one or more attributes of the monitored application, its dependencies, or other element in the system of Balasubramanian in the automated incident resolution model resolving
incidents by the automated incident resolver of Sachan. A person of ordinary skill in the
art would have been motivated to make the modification because the incident/event record is used to recommend similar action in future unhealthy operating status events, as disclosed in paragraph 0166.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Sachan et al. (USPN 20200293946A1) in view of Ramakrishna et al. (USPN 20180121808A1) in view of Balasubramanian et al. (USPN 20200409825A1) in further view of Golden et al. (USPN 11010233 B1).
As per claim 5, Sachan et al. fails to explicitly state wherein determining that the defect correlates to the known defect comprises: generating, by the ML model, a confidence score associated with the defect correlating to the known defect; and determining that the confidence score is greater than a threshold score, wherein the determination that the defect correlates to the known defect is based on determining that the confidence score is greater than the threshold score.
Sachan et al. does disclose matching the incident with historical incidents with
high confidence scores in paragraph 0049.
Golden et al. discloses determining that the defect correlates to the known defect comprises: generating, by the ML model, a confidence score associated with the defect correlating to the known defect; and determining that the confidence score is greater than a threshold score, wherein the determination that the defect correlates to the known defect is based on determining that the confidence score is greater than the threshold score in column 52, lines 19-33 - In some examples, supervised machine learning model 902 is configured to determine a confidence score for an anomaly represented by anomaly data 904. Supervised machine learning model 902 may compare the confidence score to a threshold associated with an issue. In some examples, the threshold may be dynamically set and adjusted by supervised machine learning model 902 as supervised machine learning model 902 is trained over time. In response to determining that the confidence score for an anomaly is greater than the threshold, supervised machine learning model 902 may classify the anomaly as being representative of an issue associated with the hardware component. Monitoring system 400 may accordingly perform any of the remedial actions described herein with respect to the anomaly.
Accordingly, it would have been obvious to one of ordinary skill in the art before
the effective filing date of the claimed invention to include the confidence scores above
a threshold determined by a machine learning model of Golden et al. in the high confidence scores of Sachan et al. A person of ordinary skill in the art would have been motivated to make the modification because the threshold indicates a known anomaly, as disclosed in column 52, lines 19-33.
There is no prior art rejection for claims 2-4,6-8,10,12-16,18-20 because either no prior art could be found or no reason to combine with prior art found.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Yolanda L Wilson whose telephone number is (571)272-3653. The examiner can normally be reached M-F (7:30 am - 4 pm).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bryce Bonzo can be reached at 571-272-3655. 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.
/Yolanda L Wilson/Primary Examiner, Art Unit 2113