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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/30/2025 has been entered.
Response to Amendment
The previous 35 U.S.C. 112(a) rejections are withdrawn due to Applicant’s amendments.
Response to Arguments
Applicant’s arguments on pages 13 regarding the rejection under 35 U.S.C. 103 with respect to claims 1-20 have been fully considered but are moot. New reference Jelodar has been incorporated below to teach the newly presented limitations.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Guven at al. (US20170178038A1); hereinafter Guven in view of Mann et al. (US20190132191A1); hereinafter Mann in view of Jelodar et al. (Latent Dirichlet allocation (LDA) and topic modeling: models, applications, a survey); hereinafter Jelodar in view of Bales et al. (US20170212829A1); hereinafter Bales in view of Jain et al. (US20220237108A1); hereinafter Jain and in further view of Rahman et al. (Source code properties of defective infrastructure as code scripts); hereinafter Rahman
Claim 1 is rejected over Guven, Mann, Jelodar, Bales, Jain and Rahman.
Regarding claim 1, Guven teaches the method comprising, performing by one or more processors, operations including: (Guven [0028]: “The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”)
receiving first metadata regarding a previous modification to a computer system; (Guven [0003]: “obtaining, from a service management database, one or more change tickets and one or more incident tickets relating to an information technology infrastructure,”; [0028]: “Change data”; [0032]: “As such, the search space can be limited to changes performed on the application itself as well as other CIs supporting the application, such as underlying hardware, middleware, etc.”)
extracting a first feature from the received first metadata; (Guven [0003]: “obtaining, from a service management database, one or more change tickets and one or more incident tickets relating to an information technology infrastructure,”; [0034]: “Change data describes various change attributes.”)
receiving second metadata regarding a previous incident related to the previous modification occurring in the computer system, (Guven [0003]: “obtaining, from a service management database, one or more change tickets and one or more incident tickets relating to an information technology infrastructure,”; [0028]: “Incident data”; [0037]: “Incident data, such as incident tickets, can also include a number of attributes. Incident attributes may include, by way of example, description, start and/or end time, type, severity, resolver group, resolution, etc. Certain major incidents may also have RCAs, which explain the path to the incident in detail as well as lessons learned for future incident prevention.”)
the previous incident including a decrease in a performance of the computer system; (Guven [0040]: Similarly, a reported incident may state that a specific database (CI4) hosted on server (CI2) is not responding.”; Note: A database system not responding indicates a decrease in performance of the computer system.)
extracting a second feature from the received second metadata; (Guven [0003]: “obtaining, from a service management database, one or more change tickets and one or more incident tickets relating to an information technology infrastructure,”; [0037]: “Incident data, such as incident tickets, can also include a number of attributes.”)
[training the machine-learning based model to] learn an association between the previous modification and the previous incident related to the previous modification, based on the extracted first feature and the extracted second feature; and (Guven [0028]: “The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”)
automatically determining the previous modification related to the previous incident based on the extracted second feature, [by using the trained machine-learning based model,] based on the learned association between the previous modification and the previous incident related to the previous modification; and (“The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”; [0028])
Guven does not teach training the machine-learning based model to
by using the trained machine-learning based model,
However, Mann teaches training the machine-learning based model to (Mann [0031]: “a root cause for an incident may be determined by a machine learning model trained to identify root causes of incidents.”)
by using the trained machine-learning based model, (Mann [0031]: “a root cause for an incident may be determined by a machine learning model trained to identify root causes of incidents.”)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the trained machine learning model of Mann to improve the prediction model (Mann, [0106]). Guven and Mann are analogous art because they both concern determining the relationship between changes and incidents of a system.
Guven does not teach wherein training the machine-learning based model to learn an association includes performing unsupervised clustering and topic modeling on the first feature and second feature;
However, Jelodar teaches wherein training the machine-learning based model to learn an association includes performing unsupervised clustering and topic modeling on the first feature and second feature; (Jelodar [Section 2.1 Latent Dirichlet allocation]: “LDA, an unsupervised generative probabilistic method for modeling a corpus, is the most commonly used topic modeling method. LDA assumes that each document can be represented as a probabilistic distribution over latent topics, and that topic distribution in all documents share a common Dirichlet prior.”; [page 15192]: “Statistical topic models can have different applications in software engineering such as bug prediction, traceability link recovery and software evolution. Chen et al. in [19] used a generative statistical model(LDA) for analyzing source code and find relationships between software defects and software development”; Note: Latent Dirichlet allocation is a form of topic modeling and an unsupervised clustering technique. Software development is the first extracted feature and software defects are the second feature.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the Latent Dirichlet allocation of Jelodar for effective group discovery (Jelodar, [5.5 Group discovery and topic modeling]). Guven and Jelodar are analogous art because they both concern finding relationships between incidents and changes in computer systems.
Guven does not teach automatically determining, by using a classification/probability prediction model running on the trained machine-learning based model, a code change to correct the previous incident;
However, Bales teaches automatically determining, by using a classification/probability prediction model running on the trained machine-learning based model, a code change to correct the previous incident; (Bales [0003]: “Software containing a large number of defects or defects that seriously interfere with its functionality can be so harmful that the software no longer satisfies it intended purpose. Defects can also cause software to crash, freeze, or enable a malicious user to bypass access controls in order to obtain unauthorized privileges (previous incidents). Defects can be a serious problem for security and safety critical software. “; [0045]: “the embodiments herein describe a source code repairer that can suggest possible fixes to defects in source code. In some embodiments, the source code repairer trains an artificial neural network using source code with known defects as input to the network and fixes to those defects as the expected outputs. The source code repairer can locate defects within source code using the techniques employed by the source code analyzer, or by using test cases created by developers. Once defects are located, the source code repairer can make suggestions to the code based on a trained artificial neural network model. The fix suggestions can be automatically integrated into the source code. In some embodiments, the suggestions can be presented to developers in their IDEs, and accepted or declined using a selectable user interface element.”; [0093]; and In some embodiments, recurrent auto-fixer 427 can be trained using defect free code for a particular type to leverage the probabilistic nature of artificial neural networks. When recurrent auto-fixer 427 is trained to recognize defect free source code for a particular defect, it will likely recognize defective code as anomalous. As a result, given defective code as input, the output will likely be a “normalized” version of the defect—defect free code that is similar in structure to the defective code, yet without the defect.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the automated code repair method of Bales to effectively improve system operational efficiency (Bales, [0060]). Guven and Bales are analogous art because they both concern identifying code that needs to be corrected.
Guven teaches wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding includes a message (Guven [0038]: Incident resolutions describe what was done to fix a problem or incident,”; Note: Incident resolutions come from incident data (metadata) as shown in paragraph [0033] of Guven.)
Guven does not teach wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding includes a file name, display identifier, message, committer type, committer link, properties, file changes, and branch information of the previous modification to the computer system or the previous incident related to the previous modification to the computer system.
However, Jain teaches wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding includes a file name (Jain [0049]: “(3.6.2) Add line information such as line number, operation performed on a line, file name, file path, and operation performed on the file to the “delta_lines” variable (metadata).”,
display identifier (Jain [0062]: “(2.4) Add commit information such as commit id (display identifier), commit message, commit time, committer, and author to the “relevant_commits” variable.”),
committer type (Jain [0062]: “(2.4) Add commit information such as commit id, commit message, commit time, committer, and author to the “relevant_commits” variable.”),
committer link (Jain [0035]: “For example, the impact analysis engine uses the git blame command (committer link) such as “git blame-L2 commit_idA—“file1”” to identify a parent commit that previously touched line 2 in file 1.”),
properties (Jain [0078]: “The user, via the user interface 701, inputs a version (properties) of a software code on which a deep impact analysis or a regression test is to be performed.”),
file changes, and (Jain [0043]: “Fetch all files touched and operations (file changes) such as added, renamed, modified, and deleted, performed on each file between the “start_tag” and the “end_tag” from a source control management (SCM) system using a p4 diff2 or git diff equivalent command.”)
branch information of the previous modification to the computer system or the previous incident related to the previous modification to the computer system (Jain [0041]: “The impact analysis engine is configured to scan all code changes (previous modifications) performed between “start_tag” and “end_tag,” (branch information) to identify the impacted (incident) artifacts.”).
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the commit metadata that includes software code commits of Jain to efficient execution of the impact analysis on software code (Jain, [0079]). Guven and Jain are analogous art because they both concern analyzing relationships between system changes and incidents.
Guven does not teach script name, script type, script description.
However, Rahman teaches wherein the first metadata or the second metadata includes a script name (Rahman [page 155, Table 4]: “fix hadoop.pp documentation default”;”; Note: Hadoop.pp is the file name of the Puppet script.)
script type, (Rahman [page 149, 2.1 Background]: “A module is a collection of manifests. Manifests are written as scripts that use a .pp extension.”; Note: The .pp extension shows type of script.)
script description (Rahman [page 154, Table 1]: “The script includes comments (description) that has ‘fixme’ and ‘todo’ as keywords (metadata) “;
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the script defect analysis of Rahman to increase the quality of infrastructure (Rahman, [Abstract]). Guven and Rahman are analogous art because they both concern analyzing relationships between system changes and incidents.
Claim 2 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman.
Regarding claim 2, Guven teaches a method for determining and counteracting a modification to a computer system causing a decrease in a performance of the computer system, the method comprising, performing by one or more processors, operations including: (Guven [0028]: “The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”; [0024]: “Another important aspect of an effective change management process is risk management (counteracting), which aims to assess and mitigate change risk to reduce the chance of failure or eventual outage.”)
receiving metadata regarding the decrease in the performance of the computer system; (Guven [0040]: “Similarly, a reported incident (metadata) may state that a specific database (CI4) hosted on server (CI2) is not responding.”; Note: A database system not responding indicates a decrease in performance of the computer system.)
extracting a feature from the received metadata, the extracted feature corresponding to a feature [of a trained machine-learning model] (Guven [0003]: “obtaining, from a service management database, one or more change tickets and one or more incident tickets relating to an information technology infrastructure,”; [0028]: “Incident data”; [0037]: “Incident data, such as incident tickets, can also include a number of attributes. Incident attributes may include, by way of example, description, start and/or end time, type, severity, resolver group, resolution, etc. Certain major incidents may also have RCAs, which explain the path to the incident in detail as well as lessons learned for future incident prevention.”)
for determining the cause for the decrease in the performance of the computer system based on a learned association between the extracted feature and the modification to the computer system; and (Guven [0028]: “The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”)
automatically determining the modification causing the decrease in the performance of the computer system based on the extracted feature, [by using the trained machine-learning model that as trained] based on a first feature extracted from metadata regarding a previous modification to the computer system and a second feature extracted from metadata regarding a previous incident related to the previous modification occurring in the computer system, based on the learned association between the extracted feature and the modification to the computer system; (Guven [0028]: “The link discovery module 120 is configured to define linkages between changes and incidents using change and incident data from SMDB 104. These linkages are used by real-time risk assessment module 122 to build a risk assessment model used in monitoring subsequent changes to CIs in the IT infrastructure.”)
Guven does not teach of a trained machine-learning based model
by using the trained machine-learning based model that was trained
However, Mann teaches of a trained machine-learning based model (Mann [0031]: “a root cause for an incident may be determined by a machine learning model trained to identify root causes of incidents.”)
by using the trained machine-learning based model that was trained (Mann [0031]: “a root cause for an incident may be determined by a machine learning model trained to identify root causes of incidents.”)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the trained machine learning model of Mann to improve the prediction model (Mann, [0106]). Guven and Mann are analogous art because they both concern determining the relationship between changes and incidents of a system.
Guven does not teach wherein training the machine-learning based model to learn an association includes performing unsupervised clustering and topic modeling on the first feature and second feature; and
However, Jelodar teaches wherein training the machine-learning based model to learn an association includes performing unsupervised clustering and topic modeling on the first feature and second feature; and (Jelodar [Section 2.1 Latent Dirichlet allocation]: “LDA, an unsupervised generative probabilistic method for modeling a corpus, is the most commonly used topic modeling method. LDA assumes that each document can be represented as a probabilistic distribution over latent topics, and that topic distribution in all documents share a common Dirichlet prior.”; [page 15192]: “Statistical topic models can have different applications in software engineering such as bug prediction, traceability link recovery and software evolution. Chen et al. in [19] used a generative statistical model(LDA) for analyzing source code and find relationships between software defects and software development”; page 24; Note: Latent Dirichlet allocation is a form of topic modeling and an unsupervised clustering technique. Software development is the first extracted feature and software defects are the second feature.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the Latent Dirichlet allocation of Jelodar for effective group discovery (Jelodar, [5.5 Group discovery and topic modeling]). Guven and Jelodar are analogous art because they both concern finding relationships between incidents and changes in computer systems.
Guven does not teach automatically determining, by using a classification/probability prediction model running on the trained machine-learning based model, a code change to correct the previous incident;
However, Bales teaches automatically determining, by using a classification/probability prediction model running on the trained machine-learning based model, a code change to correct the previous incident; and (Bales [0003]: “Software containing a large number of defects or defects that seriously interfere with its functionality can be so harmful that the software no longer satisfies it intended purpose. Defects can also cause software to crash, freeze, or enable a malicious user to bypass access controls in order to obtain unauthorized privileges (previous incidents). Defects can be a serious problem for security and safety critical software. “; [0045]: “the embodiments herein describe a source code repairer that can suggest possible fixes to defects in source code. In some embodiments, the source code repairer trains an artificial neural network using source code with known defects as input to the network and fixes to those defects as the expected outputs. The source code repairer can locate defects within source code using the techniques employed by the source code analyzer, or by using test cases created by developers. Once defects are located, the source code repairer can make suggestions to the code based on a trained artificial neural network model. The fix suggestions can be automatically integrated into the source code. In some embodiments, the suggestions can be presented to developers in their IDEs, and accepted or declined using a selectable user interface element.”; [0093]; and In some embodiments, recurrent auto-fixer 427 can be trained using defect free code for a particular type to leverage the probabilistic nature of artificial neural networks. When recurrent auto-fixer 427 is trained to recognize defect free source code for a particular defect, it will likely recognize defective code as anomalous. As a result, given defective code as input, the output will likely be a “normalized” version of the defect—defect free code that is similar in structure to the defective code, yet without the defect.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the automated code repair method of Bales to effectively improve system operational efficiency (Bales, [0060]). Guven and Bales are analogous art because they both concern identifying code that needs to be corrected.
Guven does not teach wherein the metadata includes a programming language associated with the modification,
However, Rahman teaches wherein the metadata includes a programming language associated with the modification, (Rahman [page 149, 2.1 Background]: “A module is a collection of manifests. Manifests are written as scripts that use a .pp extension.”; Note: The .pp extension shows the programming language.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the script defect analysis of Rahman to increase the quality of infrastructure (Rahman, [Abstract]). Guven and Rahman are analogous art because they both concern analyzing relationships between system changes and incidents.
Guven does not teach wherein the metadata includes a time associated with the modification, and an identifier for a person associated with the modification.
However, Jain teaches wherein the metadata includes a time associated with the modification, and (Jain [0062]: “(2.4) Add commit (modification) information such as commit id, commit message, commit time (time associated with the modification), committer, and author to the “relevant_commits” variable (metadata).”);
an identifier for a person associated with the modification (Jain [0062]: “(2.4) Add commit (modification) information such as commit id, commit message, commit time, committer, and author (identifier for a person associated with the modification) to the “relevant_commits” variable (metadata).”).
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the commit metadata that includes software code commits of Jain to effectively determine how changes to software code impact systems (Jain, [0005]). Guven and Jain are analogous art because they both concern analyzing relationships between system changes and incidents.
Claim 3 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 3, Guven does not teach providing an alert identifying the determined modification causing the decrease in the performance of the computer system.
However, Mann teaches providing an alert identifying the determined modification causing the decrease in the performance of the computer system. (Mann [0053]: “In an embodiment, the root cause analyzer 130 is configured to generate an alert indicating the determined root cause. In another embodiment, the root cause analyzer 130 is configured to group together alerts which have a common cause into one incident. In yet another embodiment, the root cause analyzer 130 is further configured to report any alert remaining after the root cause analysis with additional information related to the associated incident or incidents. That is, an alert would indicate the detected root cause and would be reported with the associated incident(s). This allows the user to drill down and better understand the problem potential solutions.”)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the trained machine learning model of Mann to improve the prediction model (Mann, [0106]). Guven and Mann are analogous art because they both concern determining the relationship between changes and incidents of a system.
Claim 4 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 4, Guven teaches wherein the computer system includes at least one of an intake system, a development system, a release system, a deployment system, or an incident reporting system. (Guven [0084]: “The process 900 begins with step 902, obtaining one or more change tickets and one or more incident tickets relating to IT infrastructure 106 from SMDB 104.”; Note: SMDB 104 containing incident data is the incident reporting system.)
Claim 5 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 5, Guven teaches wherein the modification includes at least one of a modification of a hardware component of the computer system or (Guven [0032]: “For CIs such as business applications, the topology of such business applications can provide insight for linking changes to incidents. A business application outage, for example, will typically only be caused by changes to the IT infrastructure supporting the application. As such, the search space can be limited to changes performed on the application itself as well as other CIs supporting the application, such as underlying hardware, middleware, etc.”)
a modification of a software component of the computer system. (Guven [0035]: “As an example, consider a patch that is successfully applied to software. Once the change is applied, its outcome attribute may be set to success. The software, however, may later misbehave or otherwise cause an incident because of the patch.”; Note: A software patch is a modification of a software component.)
Claim 6 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 6, Guven teaches wherein the metadata includes at least one of a location of the modification in the computer system, (Guven [0040]: “Typically, changes and incidents are related to one or more CIs. For example, a change may apply to a software product (CI.sub.1) installed on a specific server (CI.sub.2) in order to ensure that a specific business application (CI.sub.3) runs smoothly.”; Note: A change applied to a specific server is the location of the modification in the system.)
a dependency upon a portion of the computer system having the modification with other portions of the computer system, (Guven [0040]: “Typically, changes and incidents are related to one or more CIs. For example, a change may apply to a software product (CI.sub.1) installed on a specific server (CI.sub.2) in order to ensure that a specific business application (CI.sub.3) runs smoothly. Similarly, a reported incident may state that a specific database (CI.sub.4) hosted on server (CI.sub.2) is not responding. There may be an overlap between CIs affected by a change and CIs related to an incident. For example, the aforementioned change and incident are both related to the same server (CI.sub.2). A change affecting a given CI is more likely to cause an incident for that CI than a different CI.”; Note: There is dependency on the server and database.)
Claim 7 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 7, Guven teaches wherein the operations are performed by using one or more Application Programming Interface (API) interactions. (Guven [0087]: “or example, the real-time risk assessment module 122 may be configured to interact with application programming interfaces (APIs) or otherwise communicate with CIs of the IT infrastructure 106 so as to modify whether a given subsequent change is implemented at all, or to change how the given subsequent change is implemented.”)
Claim 8 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 2.
Regarding claim 8, Guven teaches a non-transitory computer readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method of claim 2. (Guven [0088]: “The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”)
Claim 9 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman.
Regarding claim 9, Guven teaches a computer-implemented system for determining a modification to a computer system causing a decrease in a performance of the computer system, the computer-implemented system comprising: (Guven [0088]: “The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”)
a memory to store instructions; and (Guven [0089]: “The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM),”)
a processor to execute the stored instructions to perform operations including: (Guven [0088]: “The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”)
The remainder of claim 9 is claim 2 in the form of a computer-implemented system and is rejected for the same reasons as claim 2 stated above.
Dependent claim 10 is claim 3 in the form of a computer-implemented system and is rejected for the same reasons as claim 3 stated above. For the rejection of the limitations specifically pertaining to the computer-implemented system of claim 9, see the rejection of claim 9 above.
Dependent claim 11 is claim 4 in the form of a computer-implemented system and is rejected for the same reasons as claim 4 stated above. For the rejection of the limitations specifically pertaining to the computer-implemented system of claim 9, see the rejection of claim 9 above.
Dependent claim 12 is claim 5 in the form of a computer-implemented system and is rejected for the same reasons as claim 5 stated above. For the rejection of the limitations specifically pertaining to the computer-implemented system of claim 9, see the rejection of claim 9 above.
Dependent claim 13 is claim 6 in the form of a computer-implemented system and is rejected for the same reasons as claim 6 stated above. For the rejection of the limitations specifically pertaining to the computer-implemented system of claim 9, see the rejection of claim 9 above.
Dependent claim 14 is claim 7 in the form of a computer-implemented system and is rejected for the same reasons as claim 7 stated above. For the rejection of the limitations specifically pertaining to the computer-implemented system of claim 9, see the rejection of claim 9 above.
Claim 15 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 9.
Regarding claim 15, Guven teaches wherein one or more of the metadata regarding the previous modification to the computer system or the metadata regarding the previous incident related to the previous modification occurring in the computer system includes one or more of an incident number, (Guven [0033]: “Incident data, such as incident tickets, incident resolution text, chronology logs, RCA, etc., for a given incident are also likely to mention the same entity-action pair as the change that caused the given incident.”; Note: Incident tickets have incident numbers.)
closed date/time, (Guven [0037]:“Incident data, such as incident tickets, can also include a number of attributes. Incident attributes may include, by way of example, description, start and/or end time, type, severity, resolver group, resolution, etc.”; Note: The incident attributes are incident metadata. Closed date/time is start and/or end time.)
category, (Guven [0033]; “Change and incident data, such as change and incident tickets or other records, may also contain structured metadata that can be leveraged to further strengthen the link between changes and incidents. For example, changes classified as storage may be related to incidents classified as storage capacity errors”; Note: The classifications are the category.)
close code, (Guven [0034]: “Change attributes may include one or more of summary, detailed description, start and/or end time, type, priority, owner group, implementation steps, verification plan, backout plan, approvers and outcome (e.g., success, fail, backout).”; Note: The outcome is the close code.)
close note, (Guven [0038]: “Incident resolutions describe what was done to fix a problem or incident, and as part of this narrative often mention what the problem was”;)
long description, (Guven [0034]: “Change data describes various change attributes. Change attributes may include one or more of summary, detailed description,”; Note: A detailed description is a long description.)
short description, (Guven [0045]: “Useful structured fields for incident data include, but are not limited to, summary, detailed description, resolution, start time, severity, type and resolver group.”; Note: A summary is a short description.)
root cause, or (Guven [0037]: “Certain major incidents may also have RCAs, which explain the path to the incident in detail as well as lessons learned for future incident prevention.”; Note: Explaining the path to the incident is the root cause.)
assignment group. (Guven [0045]: “Useful structured fields for change data include, but are not limited to, start time, priority, type and owner group”; Note: Owner group is the assignment group.)
Claim 16 is rejected over Guven, Mann, Jain, Rahman and Bales with the incorporation of claim 9.
Regarding claim 16, Guven teaches wherein one or more of the metadata regarding the previous modification to the computer system or the metadata regarding the previous incident related to the previous modification occurring in the computer system includes one or more of an issue key,
description, (Guven [0034]: “Change data describes various change attributes. Change attributes may include one or more of summary, detailed description,”; Note: A detailed description is a long description.)
summary, (Guven [0045]: “Useful structured fields for incident data include, but are not limited to, summary, detailed description, resolution, start time, severity, type and resolver group.”; Note: A summary is a short description.)
label, (Guven [0033]: “Change and incident data, such as change and incident tickets or other records, may also contain structured metadata that can be leveraged to further strengthen the link between changes and incidents. For example, changes classified as storage may be related to incidents classified as storage capacity errors”; Note: The classifications are the label.)
issue type, (Guven [0037]: “Incident attributes may include, by way of example, description, start and/or end time, type, severity, resolver group,”; Note: The severity type is the issue type.)
fix version,
environment, (Guven [0040]: “Typically, changes and incidents are related to one or more CIs. For example, a change may apply to a software product (CI.sub.1) installed on a specific server (CI.sub.2) in order to ensure that a specific business application (CI.sub.3) runs smoothly.”; Note: A server can be an environment.)
author, or (Guven [0045]: “Useful structured fields for change data include, but are not limited to, start time, priority, type and owner group”; Note: Owner group includes the author.)
comments. (Guven [0033]: “Incident data, such as incident tickets, incident resolution text”; Note: Incident resolution text are comments.)
Claim 17 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 9.
Regarding claim 17, Guven teaches wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding the previous incident related to the previous modification occurring in the computer system includes one or more of a message (Guven [0038]: “Incident resolutions describe what was done to fix a problem or incident,”; Note: Incident resolutions come from incident data (metadata) as shown in paragraph [0033] of Guven.)
Guven does not teach wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding the previous incident related to the previous modification occurring in the computer system includes one or more of a file name, display identifier, message, committer type, committer link, properties, file changes, and branch information of the previous modification to the computer system or the previous incident related to the previous modification to the computer system.
However, Jain teaches wherein the first metadata or the second metadata regarding the previous modification to the computer system or the metadata regarding the previous incident related to the previous modification occurring in the computer system includes one or more of a file name (Jain [0049]: “(3.6.2) Add line information such as line number, operation performed on a line, file name, file path, and operation performed on the file to the “delta_lines” variable (metadata).”,
display identifier (Jain [0062]: “(2.4) Add commit information such as commit id (display identifier), commit message, commit time, committer, and author to the “relevant_commits” variable.”),
committer type (Jain [0062]: “(2.4) Add commit information such as commit id, commit message, commit time, committer, and author to the “relevant_commits” variable.”),
committer link (Jain [0035]: “For example, the impact analysis engine uses the git blame command (committer link) such as “git blame-L2 commit_idA—“file1”” to identify a parent commit that previously touched line 2 in file 1.”),
properties (Jain [0078]: “The user, via the user interface 701, inputs a version (properties) of a software code on which a deep impact analysis or a regression test is to be performed.”),
file changes, and (Jain [0043]: “Fetch all files touched and operations (file changes) such as added, renamed, modified, and deleted, performed on each file between the “start_tag” and the “end_tag” from a source control management (SCM) system using a p4 diff2 or git diff equivalent command.”)
branch information of the previous modification to the computer system or the previous incident related to the previous modification to the computer system (Jain [0041]: “The impact analysis engine is configured to scan all code changes (previous modifications) performed between “start_tag” and “end_tag,” (branch information) to identify the impacted (incident) artifacts.”).
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the commit metadata that includes software code commits of Jain to efficient execution of the impact analysis on software code (Jain, [0079]). Guven and Jain are analogous art because they both concern analyzing relationships between system changes and incidents.
Guven does not teach script name, script type, script description.
However, Rahman teaches wherein the first metadata or the second metadata includes a script name (Rahman [page 155, Table 4]: “fix hadoop.pp documentation default”;”; Note: Hadoop.pp is the file name of the Puppet script.)
script type, (Rahman [page 149, 2.1 Background]: “A module is a collection of manifests. Manifests are written as scripts that use a .pp extension.”; Note: The .pp extension shows type of script.)
script description (Rahman [page 154, Table 1]: “The script includes comments (description) that has ‘fixme’ and ‘todo’ as keywords (metadata) “;
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the script defect analysis of Rahman to increase the quality of infrastructure (Rahman, [Abstract]). Guven and Rahman are analogous art because they both concern analyzing relationships between system changes and incidents.
Claim 18 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 9.
Regarding claim 18, Guven teaches wherein the metadata regarding the decrease in the performance of the computer system includes one or more of CPU metrics, (Guven [0042]: “For example, antivirus programs or processes may cause prolonged CPU spikes at regular intervals, databases may reserve large amounts of disk space in advance resulting in the false impression that a system is running out of storage, etc.”)
memory metrics, (Guven [0051]: “Some meaningful substring of the entity such as “application server” or “memory parameters” may be sufficient to link the change to an incident.”)
network metrics,
disk metrics,
response time,
number of requests,
number of users, or
types of actions executed by users.
Claim 19 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 9.
Regarding claim 19 Guven teaches wherein the metadata regarding the decrease in the performance of the computer system is extracted from reported incidents and automatically reported based on a threshold. (Guven [0044]: “Examples of usage-specific rules include: anti-virus programs cause CPU spikes, databases reserve disk space, paging utilization alerts are only real beyond a certain threshold, etc.”)
Claim 20 is rejected over Guven, Mann, Jelodar, Bales, Jain, and Rahman with the incorporation of claim 9.
Regarding claim 20, Guven does not teach wherein the metadata regarding the decrease in the performance of the computer system is extracted from reported incidents and manually reported from one or more external users or internal users.
However, Mann teaches wherein the metadata regarding the decrease in the performance of the computer system is extracted from reported incidents and manually reported from one or more external users or internal users. (Mann [0121]: “For example, the issues 1010 may be reported via emails, text messages, SMS messages, or messages received via a portal. As another example, the issues 1010 may be reported via a phone call, and an IT staff may record a textual summary of the call that describes the reported issues.”; Note: The issues are IT problems which relate to the performance of the system.)
It would have been obvious before the effective filing date to combine the change and incident metadata of Guven with the trained machine learning model of Mann to improve the prediction model (Mann, [0106]). Guven and Mann are analogous art because they both concern determining the relationship between changes and incidents of a system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
NPL: Kim, Youngtaek, et al. “Githru: Visual Analytics for Understanding Software Development History Through Git Metadata Analysis.” (2021)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID H TRAN whose telephone number is (703)756-1525. The examiner can normally be reached M-F 9:30 am - 5:30 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, Viker Lamardo can be reached on (571) 270-5871. 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.
/DAVID H TRAN/Examiner, Art Unit 2147
/VIKER A LAMARDO/Supervisory Patent Examiner, Art Unit 2147