DETAILED ACTION
Claims 1-20 are pending. Claim 1, 8, and 15 are in independent form.
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 § 103
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.
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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2020/0372367 to Ha et al. (“Ha”) in view of U.S. Publication No. 2004/0120250 to Langevin et al. ("Langevin") and further in view of U.S. Publication No. 2017/0315980 to Devin (“Devin”) and further in view of U.S. Publication No. US 2025/0328442 to Metimath et al. (“Metimath”).
Regarding claim 1, Ha teaches:
A method, comprising:
obtaining, by the production agent from a content management system, a system document that includes an event list (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “The metric module 416 may perform “health checks” on the cloud service 404 (e.g., request information, metrics, etc. related to the status, operation, etc. of the cloud service) and receive such information (e.g., related to failures, incidents, etc.) from the cloud service 404”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
providing the event list along with the system event logs to an Artificial Intelligence (AI) engine for analysis (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
in response to the event list and the system event logs, generating, by the AI engine, an AI diagnosis result (Ha: Paragraph [0028], “As such, in some embodiments, the methods and/or systems described herein may utilize a “neural network,” “cognitive analysis,” “cognitive system,” “machine learning,” “cognitive modeling,” “predictive analytics,” and/or “data analytics,” as is commonly understood by one skilled in the art. Generally, these processes may include, for example, receiving and/or retrieving multiple sets of inputs, and the associated outputs, of one or more systems and processing the data (e.g., using a computing system and/or processor) to generate or extract models, rules, etc. that correspond to, govern, and/or estimate the operation of the system(s), or with respect to the embodiments described herein, to analyze computing system incidents and the resolution thereof, as described herein. Utilizing the models, the performance (or operation) of the system (e.g., utilizing/based on new inputs) may be predicted and/or the performance of the system may be optimized by investigating how changes in the input(s) effect the output(s)”; Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein the alert detector may utilize machine learning or neural networks to determine the incident);
receiving the AI diagnosis result from the AI engine (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; wherein from the alert/incident, the system can analyze this and provide a possible resolution); and
executing a remote action to resolve the incident based on the AI Diagnosis Result (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; Paragraph [0019], “The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event”; wherein from the alert/incident, the system can analyze this and provide a possible resolution and this resolution can be done automatically/executed from the alert system or be provided as a recommendation, in which the action is originating remotely).
However, Ha does not appear to explicitly teach:
automatic triggering, by a production agent, generation of a trouble ticket associated with an incident;
executing a task to collect system event logs from servers based on the automatic triggering of the generation of the trouble ticket;
However, in the same field of endeavor, Langevin teaches:
automatic triggering, by a production agent, generation of a trouble ticket associated with an incident (Langevin: Paragraph [0036], “Client 23 (production agent) will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket”);
automatically collecting, by the production agent, system event logs from remote servers based on the automatic triggering of the generation of the trouble ticket (Langevin: Paragraph [0036], “Client 23 will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket. The ATG Server will then attempt to open a trouble-ticket and send to ATG Client 23 a response indicative of whether or not a trouble-ticket has been opened and, if so, providing identification information for that trouble-ticket”; Paragraph [0038], “the server incorporates information provided by the customer network and information previously stored in the ATG Database into a bundled error message stored in the ATG Database by querying the database based on information provided to it by client 23. If there is no previous trouble-ticket, server 24 will generate one and commit the bundled error message to the database 26 so that operator O may subsequently retrieve the bundled error message from the ATG Database and take corrective action”; wherein a trigger to automatically generate a trouble ticket is initiated; afterward system event logs are fetched for the specific trouble ticket; wherein the trouble ticket is created and the information is tied to it; wherein the information is from the customer network which under BRI is “from servers”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Ha by generating a trouble ticket automatically, as taught by Langevin. One of ordinary skill in the art would have been motivated to use the methods of Langevin because it would improve the completeness of information related to networks and permit more efficient network management. (Langevin: Paragraph [0012]).
However, the Ha/Langevin combination does not appear to explicitly teach:
using a Method Of Procedure (MOP).
However, in the same field of endeavor, Devin teaches:
using a Method Of Procedure (MOP) (Devin: Paragraph [0003], “It is the objective of the inventive, MOP system, to create and store complete, accurate, and effective Methods of Procedure (MOPS) that defines the work and timing of said work to be performed in a critical infrastructure environment”; and Paragraph [0022], “In the preferred embodiment a work/mop ticket is automatically created by the MOP System in order to maintain a record of the work and notify impacted interested parties”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin combination by generating the ticket in MoP format, as taught by Devin. One of ordinary skill in the art would have been motivated to use the methods of Devin because it would improve the completeness of the ticket using the MOP for effectiveness and simplified access. (Devin: Paragraphs [0020]-[0021]).
However, the Ha/Langevin/Devin combination does not appear to explicitly teach:
corresponding script for addressing the incident associated with the trouble ticket; obtaining, by the production agent, action result logs in response to executing the script to perform the remote action; and providing, by the production agent, a data set from the action result logs to the AI engine for training a model used by the AI engine for generating the AI diagnosis result and the script.
However, in the same field of endeavor, Metimath teaches:
obtaining action result logs in response to executing the script to perform the remote action and providing data set from the log to the AI engine for training a model; (Metimath: Paragraph [0040] discloses, the device can execute script 260 on log 250 (obtaining target log in response to executing the script), which can read the parameter values within the log to train the AI model (providing data set from the log to the AI for training AI model. The AI model can be a machine learning model);
corresponding script for addressing the incident associated with the trouble ticket; (Metimath: Paragraph [0021-0022] the script is associated with the diagnostic testing (associated with Ha/Langevin/Devin trouble ticket) and is executed with the log as an input. The diagnostic tools can be based on AI model trained on the log data. The script addresses the incident associated with the diagnostic testing).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin combination by executing a script to obtain result logs to train AI model, as taught by Metimath. One of ordinary skill in the art would have been motivated to use the methods of Metimath because it would improve the efficiency of the training process. (Metimath: Paragraphs [0040]).
Regarding claim 8, Ha teaches:
A system for automating data center server diagnosis and action, wherein the system is configured to:
obtain a system document that includes an event list (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “The metric module 416 may perform “health checks” on the cloud service 404 (e.g., request information, metrics, etc. related to the status, operation, etc. of the cloud service) and receive such information (e.g., related to failures, incidents, etc.) from the cloud service 404”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
provide the event list along with the system event logs to an Artificial Intelligence (AI) engine for analysis (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
in response to the event list and the system event logs, generate, by the AI engine, an AI diagnosis result (Ha: Paragraph [0028], “As such, in some embodiments, the methods and/or systems described herein may utilize a “neural network,” “cognitive analysis,” “cognitive system,” “machine learning,” “cognitive modeling,” “predictive analytics,” and/or “data analytics,” as is commonly understood by one skilled in the art. Generally, these processes may include, for example, receiving and/or retrieving multiple sets of inputs, and the associated outputs, of one or more systems and processing the data (e.g., using a computing system and/or processor) to generate or extract models, rules, etc. that correspond to, govern, and/or estimate the operation of the system(s), or with respect to the embodiments described herein, to analyze computing system incidents and the resolution thereof, as described herein. Utilizing the models, the performance (or operation) of the system (e.g., utilizing/based on new inputs) may be predicted and/or the performance of the system may be optimized by investigating how changes in the input(s) effect the output(s)”; Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein the alert detector may utilize machine learning or neural networks to determine the incident);
receive the AI diagnosis result from the AI engine (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; wherein from the alert/incident, the system can analyze this and provide a possible resolution); and
execute a remote action to resolve the incident based on the AI Diagnosis Result (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; Paragraph [0019], “The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event”; wherein from the alert/incident, the system can analyze this and provide a possible resolution and this resolution can be done automatically/executed from the alert system or be provided as a recommendation, in which the action is originating remotely).
However, Ha does not appear to explicitly teach:
automatically trigger generation of a trouble ticket associated with an incident;
execute a task to collect system event logs from servers based on the automatic triggering of the generation of the trouble ticket;
However, in the same field of endeavor, Langevin teaches:
automatically trigger generation of a trouble ticket associated with an incident (Langevin: Paragraph [0036], “Client 23 will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket”) using a Method Of Procedure (MOP) (Devin: Paragraph [0003], “It is the objective of the inventive, MOP system, to create and store complete, accurate, and effective Methods of Procedure (MOPS) that defines the work and timing of said work to be performed in a critical infrastructure environment”; and Paragraph [0022], “In the preferred embodiment a work/mop ticket is automatically created by the MOP System in order to maintain a record of the work and notify impacted interested parties”);
execute a task to collect system event logs from servers based on the automatic triggering of the generation of the trouble ticket (Langevin: Paragraph [0036], “Client 23 will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket. The ATG Server will then attempt to open a trouble-ticket and send to ATG Client 23 a response indicative of whether or not a trouble-ticket has been opened and, if so, providing identification information for that trouble-ticket”; Paragraph [0038], “the server incorporates information provided by the customer network and information previously stored in the ATG Database into a bundled error message stored in the ATG Database by querying the database based on information provided to it by client 23. If there is no previous trouble-ticket, server 24 will generate one and commit the bundled error message to the database 26 so that operator O may subsequently retrieve the bundled error message from the ATG Database and take corrective action”; wherein a trigger to automatically generate a trouble ticket is initiated; afterward system event logs are fetched for the specific trouble ticket; wherein the trouble ticket is created and the information is tied to it; wherein the information is from the customer network which under BRI is “from servers”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Ha by generating a trouble ticket automatically, as taught by Langevin. One of ordinary skill in the art would have been motivated to use the methods of Langevin because it would improve the completeness of information related to networks and permit more efficient network management. (Langevin: Paragraph [0012]).
However, the Ha/Langevin combination does not appear to explicitly teach:
using a Method Of Procedure (MOP).
However, in the same field of endeavor, Devin teaches:
using a Method Of Procedure (MOP) (Devin: Paragraph [0003], “It is the objective of the inventive, MOP system, to create and store complete, accurate, and effective Methods of Procedure (MOPS) that defines the work and timing of said work to be performed in a critical infrastructure environment”; and Paragraph [0022], “In the preferred embodiment a work/mop ticket is automatically created by the MOP System in order to maintain a record of the work and notify impacted interested parties”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin combination by generating the ticket in MoP format, as taught by Devin. One of ordinary skill in the art would have been motivated to use the methods of Devin because it would improve the completeness of the ticket using the MOP for effectiveness and simplified access. (Devin: Paragraphs [0020]-[0021]).
However, the Ha/Langevin/Devin combination does not appear to explicitly teach:
corresponding script for addressing the incident associated with the trouble ticket; obtain, by the production agent, action result logs in response to executing the script to perform the remote action; and provide, by the production agent, a data set from the action result logs to the AI engine for training a model used by the AI engine for generating the AI diagnosis result and the script.
However, in the same field of endeavor, Metimath teaches:
obtain action result logs in response to executing the script to perform the remote action and provide data set from the log to the AI engine for training a model; (Metimath: Paragraph [0040] discloses, the device can execute script 260 on log 250 (obtaining target log in response to executing the script), which can read the parameter values within the log to train the AI model (providing data set from the log to the AI for training AI model). The AI model can be a machine learning model.
corresponding script for addressing the incident associated with the trouble ticket; (Metimath: Paragraph [0021-0022] the script is associated with the diagnostic testing (associated with Ha/Langevin/Devin trouble ticket) and is executed with the log as an input. The diagnostic tools can be based on AI model trained on the log data. The script addresses the incident associated with the diagnostic testing).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin combination by executing a script to obtain result logs to train AI model, as taught by Metimath. One of ordinary skill in the art would have been motivated to use the methods of Metimath because it would improve the efficiency of the training process. (Metimath: Paragraphs [0040]).
Regarding claim 15, Ha teaches:
A non-transitory computer-readable media having computer-readable instructions stored thereon, which when executed perform operations comprising (Ha: Paragraph [0099], “the computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device”):
obtaining a system document that includes an event list (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “The metric module 416 may perform “health checks” on the cloud service 404 (e.g., request information, metrics, etc. related to the status, operation, etc. of the cloud service) and receive such information (e.g., related to failures, incidents, etc.) from the cloud service 404”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
providing the event list along with the system event logs to an Artificial Intelligence (AI) engine for analysis (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein metrics herein can be interpreted as incidents or metrics of health/operation that can be interpreted as an event list; the system logs can be interpreted as the system event logs);
in response to the event list and the system event logs, generating, by the AI engine, an AI diagnosis result (Ha: Paragraph [0028], “As such, in some embodiments, the methods and/or systems described herein may utilize a “neural network,” “cognitive analysis,” “cognitive system,” “machine learning,” “cognitive modeling,” “predictive analytics,” and/or “data analytics,” as is commonly understood by one skilled in the art. Generally, these processes may include, for example, receiving and/or retrieving multiple sets of inputs, and the associated outputs, of one or more systems and processing the data (e.g., using a computing system and/or processor) to generate or extract models, rules, etc. that correspond to, govern, and/or estimate the operation of the system(s), or with respect to the embodiments described herein, to analyze computing system incidents and the resolution thereof, as described herein. Utilizing the models, the performance (or operation) of the system (e.g., utilizing/based on new inputs) may be predicted and/or the performance of the system may be optimized by investigating how changes in the input(s) effect the output(s)”; Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions”; Paragraph [0088], “This information may be sent to (and/or received/accessed by) the alert detector 418. Depending on the information received, the alert detector 418 may generate an indication of an incident or alert (and/or receive such from other components, such as the metric module 416 or the cloud service 404)”; wherein the alert detector may utilize machine learning or neural networks to determine the incident);
receiving the AI diagnosis result from the AI engine (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; wherein from the alert/incident, the system can analyze this and provide a possible resolution); and
executing a remote action to resolve the incident based on the AI Diagnosis Result (Ha: Paragraph [0071], “As previously mentioned, some embodiments described herein provide systems and/or methods (e.g., incident response systems/methods) that provide for automated responding to computing system and/or service (e.g., cloud system/technology) incident alerts by, for example, evaluating structured and unstructured data from system logs, metric dashboards, and “playbook” instructions. In some embodiments, the methods and/or systems described herein, group alerts based on multiple features extracted from metrics, logs, and dashboards using, for example, natural language processing and clusters them for better overall understanding of the situation. The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event. In some embodiments, the system may independently assess an appropriate response for an alert without human interaction (i.e., automatically). Additionally, the system may respond to incidents in multiple ways, not limited to executing pre-existing configurations, and perform a series of multiple intelligent operations if the initial response action is not successful”; Paragraph [0019], “The system may learn from previous incidents to provide an approximate time for incident resolution and parse the playbook to find known actions to be taken and execute or recommend a possible resolution, as well as detect anomalies in the metrics or log data to escalate an issue or ignore it as a random, inconsequential event”; wherein from the alert/incident, the system can analyze this and provide a possible resolution and this resolution can be done automatically/executed from the alert system or be provided as a recommendation, in which the action is originating remotely).
However, Ha does not appear to explicitly teach:
automatic triggering generation of a trouble ticket associated with an incident;
executing a task to collect system event logs from servers based on the automatic triggering of the generation of the trouble ticket;
However, in the same field of endeavor, Langevin teaches:
automatic triggering generation of a trouble ticket associated with an incident (Langevin: Paragraph [0036], “Client 23 will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket”) using a Method Of Procedure (MOP) (Devin: Paragraph [0003], “It is the objective of the inventive, MOP system, to create and store complete, accurate, and effective Methods of Procedure (MOPS) that defines the work and timing of said work to be performed in a critical infrastructure environment”; and Paragraph [0022], “In the preferred embodiment a work/mop ticket is automatically created by the MOP System in order to maintain a record of the work and notify impacted interested parties”);
executing a task to collect system event logs from servers based on the automatic triggering of the generation of the trouble ticket (Langevin: Paragraph [0036], “Client 23 will then store certain trap information in a "safe store" binary file 23b to thereby preserve the data in the event of a problem that prematurely terminates the process (such as a system crash) and will send to the ATG Server 24 a request to automatically generate a trouble-ticket. The ATG Server will then attempt to open a trouble-ticket and send to ATG Client 23 a response indicative of whether or not a trouble-ticket has been opened and, if so, providing identification information for that trouble-ticket”; Paragraph [0038], “the server incorporates information provided by the customer network and information previously stored in the ATG Database into a bundled error message stored in the ATG Database by querying the database based on information provided to it by client 23. If there is no previous trouble-ticket, server 24 will generate one and commit the bundled error message to the database 26 so that operator O may subsequently retrieve the bundled error message from the ATG Database and take corrective action”; wherein a trigger to automatically generate a trouble ticket is initiated; afterward system event logs are fetched for the specific trouble ticket; wherein the trouble ticket is created and the information is tied to it; wherein the information is from the customer network which under BRI is “from servers”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Ha by generating a trouble ticket automatically, as taught by Langevin. One of ordinary skill in the art would have been motivated to use the methods of Langevin because it would improve the completeness of information related to networks and permit more efficient network management. (Langevin: Paragraph [0012]).
However, the Ha/Langevin combination does not appear to explicitly teach:
using a Method Of Procedure (MOP).
However, in the same field of endeavor, Devin teaches:
using a Method Of Procedure (MOP) (Devin: Paragraph [0003], “It is the objective of the inventive, MOP system, to create and store complete, accurate, and effective Methods of Procedure (MOPS) that defines the work and timing of said work to be performed in a critical infrastructure environment”; and Paragraph [0022], “In the preferred embodiment a work/mop ticket is automatically created by the MOP System in order to maintain a record of the work and notify impacted interested parties”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin combination by generating the ticket in MoP format, as taught by Devin. One of ordinary skill in the art would have been motivated to use the methods of Devin because it would improve the completeness of the ticket using the MOP for effectiveness and simplified access. (Devin: Paragraphs [0020]-[0021]).
However, the Ha/Langevin/Devin combination does not appear to explicitly teach:
corresponding script for addressing the incident associated with the trouble ticket; obtaining, by the production agent, action result logs in response to executing the script to perform the remote action; and providing, by the production agent, a data set from the action result logs to the AI engine for training a model used by the AI engine for generating the AI diagnosis result and the script.
However, in the same field of endeavor, Metimath teaches:
obtaining action result logs in response to executing the script to perform the remote action and providing data set from the log to the AI engine for training a model; (Metimath: Paragraph [0040] discloses, the device can execute script 260 on log 250 (obtaining target log in response to executing the script), which can read the parameter values within the log to train the AI model (providing data set from the log to the AI for training AI model). The AI model can be a machine learning model.
corresponding script for addressing the incident associated with the trouble ticket; (Metimath: Paragraph [0021-0022] the script is associated with the diagnostic testing (associated with Ha/Langevin/Devin trouble ticket) and is executed with the log as an input. The diagnostic tools can be based on AI model trained on the log data. The script address the incident associated with the diagnostic testing).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin combination by executing a script to obtain result logs to train AI model, as taught by Metimath. One of ordinary skill in the art would have been motivated to use the methods of Metimath because it would improve the efficiency of the training process. (Metimath: Paragraphs [0040]).
Claims 2-3, 5, 9-10, 12, 16-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ha in view of Langevin in view of Devin and further in view of Metimath and further in view of U.S. Publication No. 2023/0072752 to Villani (“Villani”).
Regarding claim 2 the Ha/Langevin/Devin/Metimath combination teaches all of the elements of claim 1. and further teaches:
attaching the action result logs and the AI diagnosis result (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result),
However, the Ha/Langevin/Devin/Metimath combination does not appear to teach:
attaching, to the trouble ticket, the result, and providing the trouble ticket to a service desk.
However, in the same field of endeavor, Villani teaches:
attaching, to the trouble ticket, the result, and providing the trouble ticket to a service desk (Villani: Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the data from the action is logged and sent to the appropriate support group which is interpreted as attaching it to the support ticket and sending it to the service desk).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin/Metimath combination by attaching results to a trouble ticket to be sent to service desk, as taught by Villani. One of ordinary skill in the art would have been motivated to use the methods of Villani because it would improve customer service by minimizing human intervention. (Villani: Paragraph [0041]).
Regarding claim 3, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 2 and further teaches:
verifying, by an operation team, a result of executing the script to perform the remote action based on the trouble ticket, and communicating, by the operation team closing of the trouble ticket after verifying that the incident has been addressed (Villani: Paragraph [0022], “In other examples, the self-service support desk platform further comprises a self-service reporting dashboard. The user is configured to engage the self-service reporting dashboard to view information, such as, a status of an action in progress, an action history, a status of a support ticket, and/or a history associated with the support ticket, among other information not explicitly listed herein”; Paragraph [0028], “In some examples, the user is an administrator”; and Paragraph [0027], “On the execution date, the method includes executing, via the self-service support desk platform, the action associated with the support ticket. Further, in response to a determination of a successful completion of the action, the method includes: updating and closing, via the self-service support desk platform, the support ticket”; wherein the user accesses a self-service reporting dashboard, the user is an administrator, and upon determination of a successful completion of the action the ticket is closed through the self-service support desk platform by the administrator).
Regarding claim 5, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 2 and further teaches:
in response to the obtaining the action result logs based on the executing the script to perform the remote action, generating a result document that includes a result of the executing the script to perform the remote action (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result), and providing the result document to a visualization tool (Villani: Paragraph [0078], “FIG. 3 depicts process steps that occur when the user 102 accesses the self-service reporting dashboard 310 of the web server platform 112. As shown, at a process step 154, the user 102 can access the self-service reporting dashboard 310 to view information, such as the status of actions in progress, action history, ticket status and history or a self-service reporting engine 390”; Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the self-service dashboard shows the information of ticket to the user via a GUI and wherein the results are updated on the ticket such as “job failure”).
Regarding claim 9 the Ha/Langevin/Devin/Metimath combination teaches all of the elements of claim 8. and further teaches:
obtain action result logs in response to executing the remote action, attach the action result logs and the AI diagnosis result (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result),
However, the Ha/Langevin/Devin/Metimath combination does not appear to teach:
attach, to the trouble ticket, the result, and provide the trouble ticket to a service desk.
However, in the same field of endeavor, Villani teaches:
attach, to the trouble ticket, the result, and provide the trouble ticket to a service desk (Villani: Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the data from the action is logged and sent to the appropriate support group which is interpreted as attaching it to the support ticket and sending it to the service desk).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin combination by attaching results to a trouble ticket to be sent to service desk, as taught by Villani. One of ordinary skill in the art would have been motivated to use the methods of Villani because it would improve customer service by minimizing human intervention. (Villani: Paragraph [0041]).
Regarding claim 10, the Ha/Langevin/Devin/Villani/Metimath combination teaches all of the elements of claim 9 and further teaches:
provide the trouble ticket to an operation team for verifying the result of the executing the remote action; and receiving, from the operation team closing of the trouble ticket after verification that the incident has been addressed (Villani: Paragraph [0022], “In other examples, the self-service support desk platform further comprises a self-service reporting dashboard. The user is configured to engage the self-service reporting dashboard to view information, such as, a status of an action in progress, an action history, a status of a support ticket, and/or a history associated with the support ticket, among other information not explicitly listed herein”; Paragraph [0028], “In some examples, the user is an administrator”; and Paragraph [0027], “On the execution date, the method includes executing, via the self-service support desk platform, the action associated with the support ticket. Further, in response to a determination of a successful completion of the action, the method includes: updating and closing, via the self-service support desk platform, the support ticket”; wherein the user accesses a self-service reporting dashboard, the user is an administrator, and upon determination of a successful completion of the action the ticket is closed through the self-service support desk platform by the administrator).
Regarding claim 12, the Ha/Langevin/Devin/Villani/Metimath combination teaches all of the elements of claim 9 and further teaches:
in response to the obtaining the action result logs based on the executing the remote action, generate a result document that includes a result of the executing the remote action (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result), and to provide the result document to a visualization tool (Villani: Paragraph [0078], “FIG. 3 depicts process steps that occur when the user 102 accesses the self-service reporting dashboard 310 of the web server platform 112. As shown, at a process step 154, the user 102 can access the self-service reporting dashboard 310 to view information, such as the status of actions in progress, action history, ticket status and history or a self-service reporting engine 390”; Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the self-service dashboard shows the information of ticket to the user via a GUI and wherein the results are updated on the ticket such as “job failure”).
Regarding claim 16 the Ha/Langevin/Devin/Metimath combination teaches all of the elements of claim 15. and further teaches:
obtaining action result logs in response to executing the remote action, attaching the action result logs and the AI diagnosis result (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result),
However, the Ha/Langevin/Devin/Metimath combination does not appear to teach:
attaching, to the trouble ticket, the result, and providing the trouble ticket to a service desk.
However, in the same field of endeavor, Villani teaches:
attaching, to the trouble ticket, the result, and providing the trouble ticket to a service desk (Villani: Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the data from the action is logged and sent to the appropriate support group which is interpreted as attaching it to the support ticket and sending it to the service desk).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin combination by attaching results to a trouble ticket to be sent to service desk, as taught by Villani. One of ordinary skill in the art would have been motivated to use the methods of Villani because it would improve customer service by minimizing human intervention. (Villani: Paragraph [0041]).
Regarding claim 17, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 16 and further teaches:
The non-transitory computer-readable media of claim 16 further comprising
verifying, by an operation team, the result of the remote action based on the trouble ticket; and communicating, by the operation team closing of the trouble ticket after verifying that the incident has been addressed (Villani: Paragraph [0022], “In other examples, the self-service support desk platform further comprises a self-service reporting dashboard. The user is configured to engage the self-service reporting dashboard to view information, such as, a status of an action in progress, an action history, a status of a support ticket, and/or a history associated with the support ticket, among other information not explicitly listed herein”; Paragraph [0028], “In some examples, the user is an administrator”; and Paragraph [0027], “On the execution date, the method includes executing, via the self-service support desk platform, the action associated with the support ticket. Further, in response to a determination of a successful completion of the action, the method includes: updating and closing, via the self-service support desk platform, the support ticket”; wherein the user accesses a self-service reporting dashboard, the user is an administrator, and upon determination of a successful completion of the action the ticket is closed through the self-service support desk platform by the administrator).
Regarding claim 19, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 16 and further teaches:
in response to the obtaining the action result logs based on the executing the remote action, generating a result document that includes a result of the executing the remote action (Ha: Paragraph [0072], “The system may use structured and unstructured data associated with a computing system (or service), such as metrics, dashboards, logs, playbooks, etc. to detect an alert and determine the appropriate actions to resolution (i.e., if available). If no appropriate action is found, the system may escalate and/or reassign the alert. In some embodiments, regardless of how the system handles an alert, a detailed report of the incident is logged (or saved/stored). The data collected may be used to compute or estimate a time for incident resolution and compare handling of different occurrences of similar incidents over time”; wherein the full incident after handling can be logged as well as how the alert was responded to and the incident which is equivalent to action result logs and the diagnosis result), and providing the result document to a visualization tool (Villani: Paragraph [0078], “FIG. 3 depicts process steps that occur when the user 102 accesses the self-service reporting dashboard 310 of the web server platform 112. As shown, at a process step 154, the user 102 can access the self-service reporting dashboard 310 to view information, such as the status of actions in progress, action history, ticket status and history or a self-service reporting engine 390”; Paragraph [0076], “Further, as shown in FIG. 2 , a process step 144 follows the process step 140 or the process step 142. The process step 144 inquires whether the action (e.g., the action 316) was completed successfully. A “YES” response 146 or a “NO” response 148 follows the process step 144. If the “YES” response 146 follows the process step 144, a process step 150 occurs where the support ticket 318 is automatically updated and closed. If the “NO” response 148 follows the process step 144, a process step 152 occurs, where the support ticket 318 is automatically updated and marked as “job failure.” Further, the support ticket 318 is assigned to the appropriate group based on where the job failed”; wherein the self-service dashboard shows the information of ticket to the user via a GUI and wherein the results are updated on the ticket such as “job failure”).
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ha in view of Langevin in view of Devin in view of Metimath and further in view of Villani and further in view of U.S. Publication No. 2016/0380843 to Duncan et al. (“Duncan”).
Regarding claim 4, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 3. However, the combination does not appear to teach:
resolving the incident on-site by the operation team in response to the incident not being able to be addressed by the executing the remote action.
However, in the same field of endeavor, Duncan teaches:
resolving the incident on-site by the operation team in response to the incident not being able to be addressed by the executing the remote action (Duncan: Paragraph [0027], “Using this graphically displayed information, the user can identify corrective measures required, including providing firmware updates and component resets, etc., without having to dispatch a technician or technician team. When a technician or technician team is required, the exact device that has failed or triggered the condition and the device's location within the overall IHS as well as specific information on the required fixes, etc., can be sent to the technician or technician team as a troubleshooting ticket”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin/Villani combination by resolving the incident on site when the problem couldn’t be resolved automatically, as taught by Duncan. One of ordinary skill in the art would have been motivated to use the methods of Duncan because it would improve the time and cost efficiency of repairs. (Duncan: Paragraphs [0005]-[0006]).
Regarding claim 11, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 9. However, the combination does not appear to teach:
provide the trouble ticket to an operation team for resolving the incident on-site in response to the incident not being able to be addressed by the executing the remote action.
However, in the same field of endeavor, Duncan teaches:
provide the trouble ticket to an operation team for resolving the incident on-site in response to the incident not being able to be addressed by the executing the remote action (Duncan: Paragraph [0027], “Using this graphically displayed information, the user can identify corrective measures required, including providing firmware updates and component resets, etc., without having to dispatch a technician or technician team. When a technician or technician team is required, the exact device that has failed or triggered the condition and the device's location within the overall IHS as well as specific information on the required fixes, etc., can be sent to the technician or technician team as a troubleshooting ticket”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin/Metimath/Villani combination by resolving the incident on site when the problem couldn’t be resolved automatically, as taught by Duncan. One of ordinary skill in the art would have been motivated to use the methods of Duncan because it would improve the time and cost efficiency of repairs. (Duncan: Paragraphs [0005]-[0006]).
Regarding claim 18, the Ha/Langevin/Devin/Metimath/Villani combination teaches all of the elements of claim 17. However, the combination does not appear to teach:
resolving the incident on-site by the operation team in response to the incident not being able to be addressed by the executing the remote action.
However, in the same field of endeavor, Duncan teaches:
resolving the incident on-site by the operation team in response to the incident not being able to be addressed by the executing the remote action (Duncan: Paragraph [0027], “Using this graphically displayed information, the user can identify corrective measures required, including providing firmware updates and component resets, etc., without having to dispatch a technician or technician team. When a technician or technician team is required, the exact device that has failed or triggered the condition and the device's location within the overall IHS as well as specific information on the required fixes, etc., can be sent to the technician or technician team as a troubleshooting ticket”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Ha/Langevin/Devin/Metimath/Villani combination by resolving the incident on site when the problem couldn’t be resolved automatically, as taught by Duncan. One of ordinary skill in the art would have been motivated to use the methods of Duncan because it would improve the time and cost efficiency of repairs. (Duncan: Paragraphs [0005]-[0006]).
Allowable Subject Matter
Claims 6, 7, 13, 14, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s arguments, see Remarks pages 1-8, filed on December 16 2025, with respect to 35 U.S.C. 101 rejection of claims 1-20 have been fully considered and are persuasive based on the amended claims. The 35 U.S.C. 101 rejection of claims 1-20 has been withdrawn.
Applicant’s arguments with respect to amended claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely solely on references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (US 20240346283 A1 and US 20210328888 A1). The following statement is a brief summary of very pertinent art that was not relied upon:
US 2017/0068721 A1: Chafle discloses the server system automatically generates trouble ticket and the search apparatus may collect all logs as target logs related to the incident.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jigar Patel whose telephone number is 571-270-5067. The examiner can normally be reached on Monday-Thursday 10:00am-6:00pm CT.
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, Ashish Thomas can be reached at (571) 272-0631. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JIGAR P PATEL/Primary Examiner, Art Unit 2114
Prosecution Insights