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 .
DETAILED ACTION
This action is in response to application filed 02/03/2026.
Claims 1-18 are pending in this application.
Response to Arguments
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 of this title, 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-2, 6-10, 12-13, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Sachan et al. (US 2020/0293946 A1) in view of Hunter et al. (US 2022/0156138 A1).
Regarding claim 1, Sachan discloses a method for incident response using artificial intelligence for information technology operations ([0023]: methods for machine learning based incident classification and resolution), comprising:
receiving, by an incident response computer program executed by an electronic device ([0029], [0031]: utilizing a machine learning based incident classification model that is trained on historical incident tickets, where each such historical incident tickets may be labeled as actionable or non-actionable…Incident category may represent the high-level categorization of incident tickets that is aligned with an organization. [0049]: The incident recommender 122 may determine, based on the key phrases associated with the incident 110, a historical incident, from a plurality of historical incidents), a plurality of incident tickets for incidents involving computer products or computer system within an organization from a service management platform for the computer products or the computer systems ([0024]: the incident ticket may be created using incident management tools such as ServiceNow (SNOW), Incident Management (ICM), etc. Personnel in charge of analyzing the incident ticket may attempt to determine a severity or priority of an incident (or underlying issue) specified in the incident ticket. The incident ticket may be thereafter routed to an appropriate location for resolution);
clustering, by the incident response computer program, the plurality of incident tickets into common incident clusters according to categories for the incidents ([0196]: the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). In order to find similar behavior existing between the incident and the identified cluster members, a determination may be made as to how many incidents have similar severity (e.g., impact of the incident such as Sev1, Sev2, Sev3, etc.), how many incidents are impacting similar applications such as App1, App2, App3, etc., how many incidents have similar issue type such as network issues, database issues, etc.);
providing, by the incident response computer program, incident information from the prioritized incident ticket to a trained incident response machine learning engine, wherein the trained incident response machine learning engine is trained to predict a solution for the incident based on historical incident data ([0030]: any issue for which resolution steps are present may be an appropriate candidate for automated resolution. In this regard, resolution as disclosed herein may be a configurable process that includes an indication of whether a process or a component may include a set of parameters that are appropriate for resolution of a potential incident. If the issue (or associated potential incident) is determined to be appropriate for resolution, once the specified resolution steps have been implemented, a determination may be made as to whether an underlying issue associated with a potential incident is resolved. [0031]: An incident resolution recommendation may specify details of similar historical incidents that may be referred to for solving a current incident. An incident knowledge base article recommendation may provide details of knowledge base articles that may be referred to for solving a current incident);
receiving, by the incident response computer program and from the trained incident response machine learning engine, a predicted solution for the incident ([0034]: This information may be fed to a machine learning based automated incident resolution model that has been continuously trained or historical data that led to the creation of incidents. When the 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
providing, by the incident response computer program, the predicted solution to the service management platform; wherein the service management platform provides the predicted solution to the computer product or the computer system ([0041]: determine, based on the analysis of the issue 104 and based on a machine learning based automated incident resolution model 108, whether the issue 104 is appropriate for automated resolution. Based on a determination that the issue 104 is appropriate for automated resolution, the automated incident resolver 106 may implement automated resolution of the issue 104 to resolve the issue 104 associated with performance of the task or operation of the application or the device).
However, Sachan does not disclose determining, by the incident response computer program, that a velocity of incident tickets in one of the common incident clusters exceeds a threshold; prioritizing, by the incident response computer program, one of the incident tickets in the common incident clusters having the velocity that exceeds the threshold.
In an analogous art, Hunter discloses determining, by the incident response computer program, that a velocity of incident tickets in one of the common incident clusters exceeds a threshold ([0028]: ITS is provided that can automatically detect incidents. To do this, the ITS monitors the rate at which tickets are created. If the rate increases above a threshold value, the ITS may determine that a potential incident has occurred. [0068]: the incident detection module 107 can analyze the issue description for keywords and determine that an incident has occurred if the same or similar keywords are identified in a threshold number of issue descriptors related to the same application/service (e.g. common incident cluster) in a given interval); prioritizing, by the incident response computer program, one of the incident tickets in the common incident clusters having the velocity that exceeds the threshold ([0071]: if it is determined at this step that the calculated issue rate is equal to or higher than the threshold rate, the method proceeds to step 508, where the incident detection module 107 determines that a potential incident has occurred and invokes the assistant program 109. [0072]: the incident detection module 107 identifies one or more relevant users to communicate an alert to about the potential incident (e.g. prioritizing) identified at step 508. In some embodiments, the incident management system 106 may be communicatively coupled to a database/system that stores and manages a list of helpdesk staff and a real time schedule of the support staff on duty at any given time).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Sachan to comprise “determining, by the incident response computer program, that a velocity of incident tickets in one of the common incident clusters exceeds a threshold; prioritizing, by the incident response computer program, one of the incident tickets in the common incident clusters having the velocity that exceeds the threshold” taught by Hunter.
One of ordinary skilled in the art would have been motivated because it would have enabled detecting and/or managing incidents in issue tracking systems in order to quickly alert users about potential incident (Hunter, [0029]).
Regarding claim 2, Sachan-Hunter discloses the method of claim 1, wherein the incident ticket identifies a description of the incident (Sachan, [0086]: a description and short description for the incident that is being analyzed may be obtained from incident data) and/or a labelling of product/incident type (Sachan, [0186]: The issue may thus be labeled as “incident worthy” or “incident not worthy”. Thus a label data set may be created to use for machine learning based model training).
Regarding claim 6, Sachan-Hunter discloses the method of claim 1, wherein the predicted solution comprises a self-service troubleshooting guide for the predicted solution, product frequently asked questions (FAQs) for the predicted solution, solution instructions for the predicted solution, scripts for the predicted solution, patches for the predicted solution, configurations for the predicted solution, and/or solution articles for the predicted solution (Sachan [0141]: Incident resolution recommendations may be displayed, for example, for support personnel in a format as shown in a “Similar Historical Incidents” section 1000 of FIG. 10. Incident knowledge base article recommendations may be displayed, for example, for support personnel in a format as shown in a “Recommended KB Articles”).
Regarding claim 7, Sachan-Hunter discloses the method of claim 1, further comprising: receiving, by the incident response computer program, feedback for the predicted solution; and re-training, by the incident response computer program, the trained incident response machine learning engine with the feedback (Sachan, [0141]: The proactive Bot may also collect feedback data from a user, and use the feedback data to determine the relevance percentage of recommendations in order to better train and/or retrain the machine learning based models as disclosed herein).
Regarding claim 8, Sachan discloses a method for incident response using artificial intelligence for information technology operations ([0023]: methods for machine learning based incident classification and resolution), comprising:
receiving, by an incident response computer program executed by an electronic device, a plurality of incident tickets for incidents involving computer products or computer systems within an organization from a service management platform for the computer products or the computer systems ([0029], [0031]: utilizing a machine learning based incident classification model that is trained on historical incident tickets, where each such historical incident tickets may be labeled as actionable or non-actionable…Incident category may represent the high-level categorization of incident tickets that is aligned with an organization. [0049]: The incident recommender 122 may determine, based on the key phrases associated with the incident 110, a historical incident, from a plurality of historical incidents);
predicting, by the incident response computer program executed by an electronic device and using a trained incident response machine learning engine that is trained to predict a category for each incident ticket, a category for each of the plurality of incident tickets ([0031]: The incident nature recommendation may be determined, for example, by using a machine learning based incident nature model to predict various incident features such as incident category, subcategory, assignment group, application name, severity, etc., based on the historical incident information);
clustering, by the incident response computer program, the plurality of incident tickets into common incident clusters according to the categories ([0196]: the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). In order to find similar behavior existing between the incident and the identified cluster members, a determination may be made as to how many incidents have similar severity (e.g., impact of the incident such as Sev1, Sev2, Sev3, etc.), how many incidents are impacting similar applications such as App1, App2, App3, etc., how many incidents have similar issue type such as network issues, database issues, etc.).
However, Sachan does not discloses determining, by the incident response computer program, a velocity of incident tickets in the common incident clusters exceeds a threshold; ranking, by the incident response computer program, the common incident clusters based the velocities; and prioritizing, by the incident response computer program, improvement of production quality for programs or applications based on the ranking.
In an analogous art, Hunter discloses determining, by the incident response computer program, a velocity of incident tickets in the common incident clusters exceeds a threshold ([0028]: ITS is provided that can automatically detect incidents. To do this, the ITS monitors the rate at which tickets are created. If the rate increases above a threshold value, the ITS may determine that a potential incident has occurred. [0068]: the incident detection module 107 can analyze the issue description for keywords and determine that an incident has occurred if the same or similar keywords are identified in a threshold number of issue descriptors related to the same application/service (e.g. common incident cluster) in a given interval); ranking, by the incident response computer program, the common incident clusters based the velocities (fig. 11, [0058]: this example, the priority field and the rank field store different information. A large number of issues may have the same priority (e.g. critical), however only one issue may have a given rank value); and prioritizing, by the incident response computer program, improvement of production quality for programs or applications based on the ranking ([0071]: if it is determined at this step that the calculated issue rate is equal to or higher than the threshold rate, the method proceeds to step 508, where the incident detection module 107 determines that a potential incident has occurred and invokes the assistant program 109. [0072]: the incident detection module 107 identifies one or more relevant users to communicate an alert to about the potential incident (e.g. prioritizing) identified at step 508. In some embodiments, the incident management system 106 may be communicatively coupled to a database/system that stores and manages a list of helpdesk staff and a real time schedule of the support staff on duty at any given time. [0076]: the alert 1100 includes an alert identifier, a status of the alert, an application/service identifier, a team identifier (of the team responsible for handling such alerts), a time at which the alert was created, a description of the alert, and a priority of the alert).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Sachan to comprise “determining, by the incident response computer program, a velocity of incident tickets in the common incident clusters exceeds a threshold; ranking, by the incident response computer program, the common incident clusters based the velocities; and prioritizing, by the incident response computer program, improvement of production quality for programs or applications based on the ranking” taught by Hunter.
One of ordinary skilled in the art would have been motivated because it would have enabled detecting and/or managing incidents in issue tracking systems in order to quickly alert users about potential incident (Hunter, [0029]).
Regarding claim 9, Sachan-Hunter discloses the method of claim 8, wherein the incident ticket identifies a description of the incident (Sachan, [0086]: a description and short description for the incident that is being analyzed may be obtained from incident data) and/or a labelling of product/incident type (Sachan, [0186]: The issue may thus be labeled as “incident worthy” or “incident not worthy”. Thus a label data set may be created to use for machine learning based model training).
Regarding claim 10, Sachan-Hunter discloses the method of claim 8.
Sachan discloses wherein the categories comprise a common issue ([0029]: learn incident ticket routing patterns from historical incident ticket assignments, and determine a correct assignment group for a new incident ticket based on prior assignment of similar incident tickets for the assigned group), a common software program, a common computer system ([0031]: using a machine learning based incident nature model to predict various incident features such as incident category, subcategory, assignment group, application name, severity, etc., based on the historical incident information. Incident category may represent the high-level categorization of incident tickets that is aligned with an organization, such as, “application and service”, “infrastructure and network”, etc. Incident subcategory may represent a next level categorization that represents a type of an incident ticket, such as, “configuration”, “functionality”, “data missing”, etc) and a common solution ([0031]: An incident resolution recommendation may specify details of similar historical incidents that may be referred to for solving a current incident. Assignment group may represent a group of people that may be assigned to an incident for resolution of the incident).
However, Sachan does not disclose wherein the categories comprise a common geography.
In an analogous art, Hunter discloses wherein the categories comprise a common geography ([0072]: the relevant support staff may be selected based on the application/service ID associated with a majority of the created issues and/or a geographical location where a majority of the issues were created).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Sachan to comprise “wherein the categories comprise a common geography” taught by Hunter.
One of ordinary skilled in the art would have been motivated because it would have enabled detecting and/or managing incidents in issue tracking systems in order to quickly alert users about potential incident (Hunter, [0029]).
Regarding claim 12; the claim is interpreted and rejected for the same reason as set forth in claim 1.
Regarding claim 13; the claim is interpreted and rejected for the same reason as set forth in claim 2.
Regarding claim 17; the claim is interpreted and rejected for the same reason as set forth in claim 6.
Regarding claim 18; the claim is interpreted and rejected for the same reason as set forth in claim 7.
Claims 3-5, 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Sachan in view of Hunter, as applied to claim 1, in further view of Murthy et al. (US 10,860,451 B1).
Regarding claim 3, Sachan-Hunter discloses the method of claim 1.
However, Sachan-Hunter does not disclose further comprising training the trained incident response machine learning engine, comprising: retrieving, by the incident response computer program, the historical incident data comprising a plurality of prior incidents; training, by the incident response computer program, the trained incident response machine learning engine using a first portion of the historical incident data; verifying, by the incident response computer program, the training of the trained incident response machine learning engine using a second portion of the historical incident data; and deploying, by the incident response computer program, the verified incident response machine learning engine to a production environment.
In an analogous art, Murthy discloses further comprising training the trained incident response machine learning engine, comprising: retrieving, by the incident response computer program, the historical incident data comprising a plurality of prior incidents (column 1, 57-61: The meta-model can be trained on historical data and deployed in real time to process incoming log data from multiple computing modules to detect issues in the larger computing system); training, by the incident response computer program, the trained incident response machine learning engine using a first portion of the historical incident data; verifying, by the incident response computer program, the training of the trained incident response machine learning engine using a second portion of the historical incident data (column 9, 15-22: data can be stored as a training data set for the incidents in a defined generic data model, e.g., the log meta model discussed above. This step can be a continual step applied for the training data set, for example to be split 80/20:80% of the data can be used for generating the pattern and 20% of the historical data can be used for validating the generated pattern and refining before applying it to the real time data); and deploying, by the incident response computer program, the verified incident response machine learning engine to a production environment (column 9, 29-32 For a given new rolling window, for data that is flowing inward, the model is executed, and any detection of an issue is registered as an incident ticketing system).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Sachan-Hunter to comprise “further comprising training the trained incident response machine learning engine, comprising: retrieving, by the incident response computer program, the historical incident data comprising a plurality of prior incidents; training, by the incident response computer program, the trained incident response machine learning engine using a first portion of the historical incident data; verifying, by the incident response computer program, the training of the trained incident response machine learning engine using a second portion of the historical incident data; and deploying, by the incident response computer program, the verified incident response machine learning engine to a production environment.” taught by Murthy.
One of ordinary skilled in the art would have been motivated because it would have enabled to using historical computer log data for multiple computing system modules to predict and prevent issues across the computing system (Murthy, column 1, 10-12).
Regarding claim 4, Sachan-Hunter-Murthy discloses the method of claim 3, wherein the historical incident data comprises, for each of the plurality of prior incidents, a description of the prior incident, a labelling of a product involved in the prior incident, a system involved in the prior incident, an individual involved in the prior incident, a team involved in the prior incident, a time and date of the prior incident, solutions to the prior incident, and/or results of the solution (Murthy, column 7, 24-33: a set of incident management tickets 202 is received for a set of computing system issues (e.g., from an incident ticketing system database) that has occurred in past. The tickets 202 can be classified according to the nature of issue that occurred. The tickets 202 can then be arranged into groups (or “buckets”), with each group associated with a particular computing system issue, and the tickets within groups ordered chronologically. Buckets corresponding to particular issues can be defined using short descriptions, e.g., “fileAlerts, Pluggable database, etc). The same rationale applies as in claim 3.
Regarding claim 5, Sachan-Hunter-Murthy discloses he method of claim 4, wherein the historical incident data further comprises, for the plurality of prior incidents, network environment data at the time of the prior incident (Murthy, column 7, 38-42: a set of computer log files 212, again from history for the date range corresponding to the date ranges of issues, can be received for multiple modules of the computing system (e.g., a database log, a network log, and a system log. Column 7, 61-66: date and/or timestamp information can be extracted from each ticket. Since there may or may not be a textual similarity between incident tickets and the associated log information, time slicing along with a time window helps establish a correlation of cause and effect between the tickets and the associated log entries). The same rationale applies as in claim 3.
Regarding claim 14; the claim is interpreted and rejected for the same reason as set forth in claim 3.
Regarding claim 15; the claim is interpreted and rejected for the same reason as set forth in claim 4.
Regarding claim 16; the claim is interpreted and rejected for the same reason as set forth in claim 5.
Claims 11 are rejected under 35 U.S.C. 103 as being unpatentable over Sachan in view of Hunter, as applied to claim 8, in view of Shahul Hameed et al. (herein after Shahul, US 2023/0275912 A1).
Regarding claim 11, Sachan-Hunter discloses the method of claim 8.
However, Sachan-Hunter does not disclose wherein the common incident clusters are further ranked based on a severity or impact of the incident in each common incident cluster.
In an analogous art, Shahul discloses wherein the common incident clusters are further ranked based on a severity or impact of the incident in each common incident cluster ([0007]: Using one or more graph-based clustering techniques, the multipartite graph is then broken up into clusters, which can be ranked by some metric quantifying the severity of the threat, such as based on the number of security alerts or indicators of compromise (IoCs) associated with each cluster)..
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Sachan-Hunter to comprise “wherein the common incident clusters are further ranked based on a severity or impact of the incident in each common incident cluster” taught by Shahul.
One of ordinary skilled in the art would have been motivated because it would have enabled an incident analysis tool to output a listing of the nodes associated with the highest-ranking cluster(s), which can be reviewed by security analysists or further processed automatically, and which may prompt mitigating actions to be performed (Shahul, [0013]).
Additional References
The prior art made of record and not relied upon is considered pertinent to applicants disclosure.
Sloane et al., US 11,620,182 B2: System for Resolution of Technical Issues Using Computing System-Specific Contextual Data.
Kapoor et al., US 10,346,851 B1: Automated Incident, Problem, Change Correlation Analysis System.
Conclusion
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 JUAN C TURRIATE GASTULO whose telephone number is (571)272-6707. The examiner can normally be reached Monday - Friday 8 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, Brian J Gillis can be reached at 571-272-7952. 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.
/J.C.T/Examiner, Art Unit 2446
/BRIAN J. GILLIS/Supervisory Patent Examiner, Art Unit 2446
Prosecution Insights