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 Objections
Claims 1-7 are objected to because of the following informalities:
Claim 1, line 2, “configured to store” should be --storing--.
Claims 2-7 depend on the objected claim and inherit the same issue.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the term “likely” in line 19 is subjective and vague and indefinite. “components likely to experience” will be treat as --components to experience--. Likewise, claims 8 and 15 have the same issue.
Regarding claims 2-7, 9-14, and 16-20, they depend on rejected claims and inherit the same issue.
Regarding claim 4, the claims do not recite any metric or baseline for determining predictiveness. Therefore, it is unclear what features of the runtime environment are being predicted. Furthermore, it is unclear whether or not the extraction of “a set of most predictive features” recited in claim 4 is separate from the extraction of “a set of features” recited in claim 1. For examination purposes, the claim will be treated as --extract a set of features--.
Regarding claim 11, the claims do not recite any metric or baseline for determining predictiveness. Therefore, it is unclear what features of the runtime environment are being predicted. Furthermore, it is unclear whether or not the extraction of “a set of most predictive features” recited in claim 11 is separate from the extraction of “a set of features” recited in claim 1. For examination purposes, the claim will be treated as --extracting a set of features--.
Regarding claim 18, the claims do not recite any metric or baseline for determining predictiveness. Therefore, it is unclear how features of the runtime environment are being predicted. Furthermore, it is unclear whether or not the extraction of “a set of most predictive features” recited in claim 18 is separate from the extraction of “a set of features” recited in claim 1. For examination purposes, the claim will be treated as --extract a set of features--.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claims are directed toward an abstract idea without significantly more.
Regarding claims 1, 8, and 15:
Step 1:
Claims 1-7 are directed toward a system, claims 8-14 are directed toward a method, and claims 15-20 are directed toward a manufacture. Therefore, all claims fall into statutory categories.
Step 2A, Prong 1:
Claim 1 recites:
access the software codebase of the at least one software application;
identify, based at least in part on the software codebase, one or more relationships between the plurality of software application components;
extract, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application;
execute, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies of each of the plurality of software application components on one or more other software application components of the plurality of software application components, wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components; and
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
Steps (a), (b), (c), and (e) are mental processes that can be performed in the human mind or by a human using pen and paper.
Claim 8 recites:
accessing a software codebase of at least one software application;
identifying, based at least in part on the software codebase, one or more relationships between a plurality of software application components of the at least one software application;
extracting, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application;
executing, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies of each of the plurality of software application components on one or more other software application components of the plurality of software application components, wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components;
outputting, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
Steps (a), (b), (c), and (e) are mental processes that can be performed in the human mind or by a human using pen and paper.
Claim 15 recites:
access a software codebase of at least one software application;
identify, based at least in part on the software codebase, one or more relationships between a plurality of software application components of the at least one software application;
extract, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application;
execute, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies of each of the plurality of software application components on one or more other software application components of the plurality of software application components, wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components;
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
Steps (a), (b), (c), and (e) are mental processes that can be performed in the human mind or by a human using pen and paper.
Step 2A, Prong 2:
The claims recite the additional elements, “machine-learning model” and step (d) in claims 1, 8, and 15, “memory” and “processors” in claim 1, and “medium” and “processors” in claim 15.
Step (d) merely recites instructions to implement the abstract idea on a generic computer or merely uses a generic computer or computer components as a tool to perform the abstract idea. Therefore, this additional element is not a practical application under Prong 2, or amount to significantly more under Step 2B (See MPEP 2106.05(f)).
“Machine-learning model”, “memory”, “medium” and “processors” are recited at a high level of generality. Therefore, the claims as a whole do not integrate into a practical application.
Step 2B:
The additional elements, considering them both individually and in combination, do not amount to significantly more than the judicial exception itself.
Regarding claim 2, the additional elements: “neuromorphic image compression (NIC) model”, “spiking neural network (SNN)”, “autoencoder (AE)”, “variational autoencoder (VAE)”, “generative adversarial network (GAN)”, and “bidirectional generative adversarial network (BiGAN)” are recited at a high level of generality.
Regarding claim 3, the additional element: “identify the one or more relationships” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element: “receiving a real-time or near real-time data stream” is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 4, the additional element: “extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 5, the additional element: “combine the set of most predictive features representative of the runtime environment into a combined feature data set” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element: “machine-learning models” is recited at a high level of generality.
Regarding claim 6, the additional element: “execute the one or more machine-learning models” merely recites instructions to implement the abstract idea on a generic computer or merely uses a generic computer or computer components as a tool to perform the abstract idea. Furthermore, the additional element: “generate the prediction of the one or more dependencies” is a mental process that can be performed in the human mind or by a human using pen and paper.
Regarding claim 7, the additional elements: “user portal component”, “validator component”, “activity component”, “authentication component”, “secure documentation component”, and “third-party application component” are recited at a high level of generality.
Regarding claim 9, the additional elements: “neuromorphic image compression (NIC) model”, “spiking neural network (SNN)”, “autoencoder (AE)”, “variational autoencoder (VAE)”, “generative adversarial network (GAN)”, and “bidirectional generative adversarial network (BiGAN)” are recited at a high level of generality.
Regarding claim 10, the additional element: “receiving a real-time or near real-time data stream” is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 11, the additional element: “extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 12, the additional element: “combining the set of most predictive features representative of the runtime environment into a combined feature data set” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element: “machine-learning models” is recited at a high level of generality.
Regarding claim 13, the additional element: “executing the one or more machine-learning models” merely recites instructions to implement the abstract idea on a generic computer or merely uses a generic computer or computer components as a tool to perform the abstract idea. Furthermore, the additional element “generate the prediction of the one or more dependencies” is a mental process that can be performed in the human mind or by a human using pen and paper.
Regarding claim 14, the additional elements: “user portal component”, “validator component”, “activity component”, “authentication component”, “secure documentation component”, and “third-party application component” are recited at a high level of generality.
Regarding claim 16, the additional elements: “neuromorphic image compression (NIC) model”, “spiking neural network (SNN)”, “autoencoder (AE)”, “variational autoencoder (VAE)”, “generative adversarial network (GAN)”, and “bidirectional generative adversarial network (BiGAN)” are recited at a high level of generality.
Regarding claim 17, the additional element: “identify the one or more relationships” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element: “receiving a real-time or near real-time data stream” is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 18, the additional element: “extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element is merely data gathering and is therefore considered an insignificant extra-solution activity.
Regarding claim 19, the additional element: “combine the set of most predictive features representative of the runtime environment into a combined feature data set” is a mental process that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element: “machine-learning models” is recited at a high level of generality.
Regarding claim 20, the additional element: “generate the prediction of the one or more dependencies based at least in part on the combined feature data set” is a mental process that can be performed in the human mind or by a human using pen and paper.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-8, 10-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Reddy et al. (US20220164181, Reddy hereinafter), in view of Mathen et al. (US20190196938, Mathen hereinafter).
Regarding claim 1, Reddy discloses: A system, comprising: a memory configured to store a software codebase of at least one software application, wherein the at least one software application comprises a plurality of software application components (Reddy, see paragraph [0039], “…the system 100 may include or may access a database that stores one or more code bases, the code bases being computer programming source code for methods, functional calls, components, and solutions of the one or more workflows.”), (Reddy, see paragraph [0038], “As used herein, a “dependency” can refer to any type of functional call between methods within a component, between one component and another component, and/or between two different solutions, for the workflows within the code base…”); and one or more processors operably coupled to the memory (Reddy, see paragraph [0091], “…The computing device 2304 may include components such as a processing unit, internal system memory, and a suitable system bus for coupling to various components, including a database or database cluster…”), (Reddy, see paragraph [0099], “…the computing device 2304 may execute, using a processor, computer instructions stored in the data store 2308 in order to perform aspects described herein.”) and configured to:
access the software codebase of the at least one software application (Reddy, see paragraph [0049], “…one or more code bases that encode one or more client workflows are received, retrieved, obtained, or otherwise accessed as input to the system 100 of FIG. 1…”);
identify, based at least in part on the software codebase, one or more relationships between the plurality of software application components (Reddy, see paragraph [0040], “…the static dependency graph module 102 generates a static dependency graph that maps a first plurality of dependencies for one or more client workflows, as the workflows are encoded in a code base. The static dependency graph module 102 scans the code in a static manner, without execution of the code…”), (Reddy, see paragraph [0050], “…generating the static dependency graph includes scanning computer code that encodes the one or more client workflows in the code base. In one such aspect, all of the first plurality of dependencies between method calls are identified based on scanning the computer code…”);
extract, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0043], “…the superimposing module 106 superimposes the internal-domain dynamic dependency graph and the static dependency graph, in aspects, in order to make a comparison of the dependencies found by static scanning of the code and the dependencies found by tracing the workflow when the code is executed in the internal domain…”); and
execute, based at least in part on the extracted set of features, (Reddy, see paragraph [0006], “…the impact analysis identifies specific upstream and downstream method call dependencies for the one or more client workflows using each of the first, second, and third plurality of dependencies…”), (Reddy, see paragraph [0075], “The system 1600 further includes, in various aspects, a recommendation engine module 1606. The recommendation engine module 1606 identifies at least a second method that was modified by at least one of the one or more prior requests that include a prior modification made to the first method, in aspects. In some aspects, the recommendation engine module 1606 determines a score of the second method, and based on the score, identifies that the second method is predicted to be affected by the modification made to the first method by the current request…”), (Reddy, see paragraph [0065], “…The impact analysis may results in a report that individually identifies, for any particular or selected method, all of the upstream and downstream dependencies of that particular methods as aggregated from the first, second, and third dependencies identified. In this manner, a comprehensive view of all of the dependency relationships for every individual method (e.g., upstream, downstream, sequencing) in the workflows is generated”), (Reddy, see paragraph [0081], “…a plurality of methods are identified, where each of the plurality of methods are predicted to be affected by the modification being made to the first method in the current request…”), (Reddy, see paragraph [0038], “As used herein, a “dependency” can refer to any type of functional call between methods within a component, between one component and another component, and/or between two different solutions, for the workflows within the code base…”).
Reddy, does not appear to distinctly disclose:
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components; and
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
However, Mathen discloses:
execute, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies (Mathen, see paragraph [0068], “…the machine learning component can be a k-nearest neighbor model, a hidden markov model, or any other suitable machine learning model. The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects. For example, the correlation can span multiple modules, where an irregularity (or defect) for a first module (shown by the host logs) can be correlated to a defect for a second module (also shown by the host logs).”), (Mathen, see paragraph [0023], “…events input 102 can be the runtime logs of the different modules or components of the heterogeneous enterprise system while the events of the patch or update are being performed (e.g., current signature)…”),
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components (Mathen, see paragraph [0021], “…The trained machine learning component can then identify patterns where an irregularity generates a defect downstream. For example, the historic data can show that in some configurations of heterogeneous enterprise systems, a first irregularity caused by patching or updating a first module can generate a first defect in a second module, while in other configuration of heterogeneous enterprise systems the first irregularity caused by updating or patching the first module can generate a second defect in a third module… Embodiments can also use the predicted defects to predict a downtime for a heterogeneous enterprise system while the change is being implemented, such as downtime for the system while a module is being patched or updated.”), (Mathen see paragraph [0075], “…the machine learning component can predict defects to particular modules/components, and/or can predict a number of defects that will be experienced by implementing the change (e.g., patch or update)…”), (Mathen, see paragraph [0065], “…defects can include failed updates or changes to sub-systems (e.g., failure to run a script or program to update a piece of software), errors in software interactions (e.g., errors generated by a first software module passing a object, value, or piece of data to a second module in an unexpected manner, such as an incorrect format), failed system health diagnostics, aborted processes, and other suitable failures or errors generated within computing device/server logs.”), (Mathen, see paragraph [0040], “A modern software product is often maintained continuously and enhancements/bug fixes are pushed to ensure the product remains in a healthy state…”); and
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0077], “…user interface 1002 can include button 1004 for displaying the downtime associated with a change to a heterogeneous enterprise system. User interface 1102 then shows a graph that illustrates the predicted downtime when implementing changes to a heterogeneous enterprise system versus the actual downtime observed when the change was implemented.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include executing a machine-learning model to generate a prediction wherein the prediction identifies components likely to experience downtime during remediation and outputting the prediction as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 3, Reddy discloses: wherein the one or more processors are further configured to
identify the one or more relationships between the plurality of software application components by receiving a real-time or near real-time data stream during the execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”).
Regarding claim 4, Reddy does not appear to distinctly disclose: wherein the one or more processors are further configured to
extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application.
However, Mathen discloses: wherein the one or more processors are further configured to
extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application (Mathen, see paragraph [0071], “…During the machine learning building phase and training phase, a plurality of variables (e.g., that impact the downtime for a particular customer) were identified. For example, this list of variables can include type of hardware, processor, memory, network, current software version, data center, the previous upgrade path, the client/customer, the volume of data in the database, the source and target release versions, and the like. For example, variables such as processor, memory, source/target release versions, and/or data center can be used to predict downtime…”), (Mathen, see paragraph [0074], “…a probability matrix can be generated to identify the probability that a particular event (e.g., irregularity/defect) has repercussion events elsewhere…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application as taught by Mathen, for the result of improving the accuracy and reliability of the prediction of components likely to experience downtime.
Regarding claim 5, Reddy does not appear to distinctly disclose: wherein the one or more processors are further configured to:
prior to executing the one or more machine-learning models, combine the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models.
However, Mathen discloses: wherein the one or more processors are further configured to:
prior to executing the one or more machine-learning models, combine the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models (Mathen, see paragraph [0025], “…events input 102 can be processed prior to being input to machine learning component 106 to identify discrepancies…”), (Mathen, see paragraph [0050], “…Processing the retrieved log files can include data aggregation/harvesting (e.g., collating logs from various file systems and/or from several parallel processed subsystems to a single location)…”), (Mathen, see paragraph [0052], “…a number of processed and sequenced log files can be aggregated to generate a signature that represents that behavior of a heterogeneous enterprise system when a particular change is implemented, such as the patch to a particular module of the heterogeneous enterprise system…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include combining the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models prior to execution as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 6, Reddy does not appear to distinctly disclose: wherein the one or more processors are further configured to
execute the one or more machine-learning models further trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set.
However, Mathen discloses: wherein the one or more processors are further configured to
execute the one or more machine-learning models further trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set (Mathen, see paragraph [0068], “…The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects…”), (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0075], “…the trained machine learning component can use the current signature and base signature (e.g., irregularities/defects that can be identified by comparison) to predict downstream defects (e.g., a number of defects) that will be experienced by implementing the change.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include executing a machine-learning model trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 7, Reddy does not appear to distinctly disclose:
wherein the plurality of software application components comprises one or more of a user portal component, a validator component, an activity component, an authentication component, a secure documentation component, or a third-party application component.
However, Mathen discloses:
wherein the plurality of software application components comprises one or more of (Mathen, see paragraph [0017], “A heterogeneous system can be a computing system with a plurality of different modules or components working together, such as an enterprise software system that leverages different types of cloud services, application services, database services, and the like. In some implementations, these modules or components can be sourced from different product and service vendors and/or developed and built by different development teams.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include a third-party application component as taught by Mathen, for the result of extending the prediction of dependencies and downtime to all parts of the software.
Regarding claim 8, Reddy discloses: A method, comprising:
accessing a software codebase of at least one software application (Reddy, see paragraph [0049], “…one or more code bases that encode one or more client workflows are received, retrieved, obtained, or otherwise accessed as input to the system 100 of FIG. 1…”);
identifying, based at least in part on the software codebase, one or more relationships between a plurality of software application components of the at least one software application (Reddy, see paragraph [0040], “…the static dependency graph module 102 generates a static dependency graph that maps a first plurality of dependencies for one or more client workflows, as the workflows are encoded in a code base. The static dependency graph module 102 scans the code in a static manner, without execution of the code…”), (Reddy, see paragraph [0050], “…generating the static dependency graph includes scanning computer code that encodes the one or more client workflows in the code base. In one such aspect, all of the first plurality of dependencies between method calls are identified based on scanning the computer code…”);
extracting, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0043], “…the superimposing module 106 superimposes the internal-domain dynamic dependency graph and the static dependency graph, in aspects, in order to make a comparison of the dependencies found by static scanning of the code and the dependencies found by tracing the workflow when the code is executed in the internal domain…”);
executing, based at least in part on the extracted set of features, (Reddy, see paragraph [0006], “…the impact analysis identifies specific upstream and downstream method call dependencies for the one or more client workflows using each of the first, second, and third plurality of dependencies…”), (Reddy, see paragraph [0075], “The system 1600 further includes, in various aspects, a recommendation engine module 1606. The recommendation engine module 1606 identifies at least a second method that was modified by at least one of the one or more prior requests that include a prior modification made to the first method, in aspects. In some aspects, the recommendation engine module 1606 determines a score of the second method, and based on the score, identifies that the second method is predicted to be affected by the modification made to the first method by the current request…”), (Reddy, see paragraph [0065], “…The impact analysis may results in a report that individually identifies, for any particular or selected method, all of the upstream and downstream dependencies of that particular methods as aggregated from the first, second, and third dependencies identified. In this manner, a comprehensive view of all of the dependency relationships for every individual method (e.g., upstream, downstream, sequencing) in the workflows is generated”), (Reddy, see paragraph [0081], “…a plurality of methods are identified, where each of the plurality of methods are predicted to be affected by the modification being made to the first method in the current request…”), (Reddy, see paragraph [0038], “As used herein, a “dependency” can refer to any type of functional call between methods within a component, between one component and another component, and/or between two different solutions, for the workflows within the code base…”).
Reddy does not appear to distinctly disclose:
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components; and
outputting, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
However, Mathen discloses:
executing, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies (Mathen, see paragraph [0068], “…the machine learning component can be a k-nearest neighbor model, a hidden markov model, or any other suitable machine learning model. The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects. For example, the correlation can span multiple modules, where an irregularity (or defect) for a first module (shown by the host logs) can be correlated to a defect for a second module (also shown by the host logs).”), (Mathen, see paragraph [0023], “…events input 102 can be the runtime logs of the different modules or components of the heterogeneous enterprise system while the events of the patch or update are being performed (e.g., current signature)…”),
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components (Mathen, see paragraph [0021], “…The trained machine learning component can then identify patterns where an irregularity generates a defect downstream. For example, the historic data can show that in some configurations of heterogeneous enterprise systems, a first irregularity caused by patching or updating a first module can generate a first defect in a second module, while in other configuration of heterogeneous enterprise systems the first irregularity caused by updating or patching the first module can generate a second defect in a third module… Embodiments can also use the predicted defects to predict a downtime for a heterogeneous enterprise system while the change is being implemented, such as downtime for the system while a module is being patched or updated.”), (Mathen see paragraph [0075], “…the machine learning component can predict defects to particular modules/components, and/or can predict a number of defects that will be experienced by implementing the change (e.g., patch or update)…”), (Mathen, see paragraph [0065], “…defects can include failed updates or changes to sub-systems (e.g., failure to run a script or program to update a piece of software), errors in software interactions (e.g., errors generated by a first software module passing a object, value, or piece of data to a second module in an unexpected manner, such as an incorrect format), failed system health diagnostics, aborted processes, and other suitable failures or errors generated within computing device/server logs.”), (Mathen, see paragraph [0040], “A modern software product is often maintained continuously and enhancements/bug fixes are pushed to ensure the product remains in a healthy state…”); and
outputting, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0077], “…user interface 1002 can include button 1004 for displaying the downtime associated with a change to a heterogeneous enterprise system. User interface 1102 then shows a graph that illustrates the predicted downtime when implementing changes to a heterogeneous enterprise system versus the actual downtime observed when the change was implemented.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include executing a machine-learning model to generate a prediction wherein the prediction identifies components likely to experience downtime during remediation and outputting the prediction as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 10, Reddy discloses:
wherein identifying the one or more relationships between the plurality of software application components comprises receiving a real-time or near real-time data stream during the execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”).
Regarding claim 11, Reddy does not appear to distinctly disclose:
extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application.
However, Mathen discloses:
extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application (Mathen, see paragraph [0071], “…During the machine learning building phase and training phase, a plurality of variables (e.g., that impact the downtime for a particular customer) were identified. For example, this list of variables can include type of hardware, processor, memory, network, current software version, data center, the previous upgrade path, the client/customer, the volume of data in the database, the source and target release versions, and the like. For example, variables such as processor, memory, source/target release versions, and/or data center can be used to predict downtime…”), (Mathen, see paragraph [0074], “…a probability matrix can be generated to identify the probability that a particular event (e.g., irregularity/defect) has repercussion events elsewhere…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application as taught by Mathen, for the result of improving the accuracy and reliability of the prediction of components likely to experience downtime.
Regarding claim 12, Reddy does not appear to distinctly disclose:
prior to executing the one or more machine-learning models, combining the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models.
However, Mathen discloses:
prior to executing the one or more machine-learning models, combining the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models (Mathen, see paragraph [0025], “…events input 102 can be processed prior to being input to machine learning component 106 to identify discrepancies…”), (Mathen, see paragraph [0050], “…Processing the retrieved log files can include data aggregation/harvesting (e.g., collating logs from various file systems and/or from several parallel processed subsystems to a single location)…”), (Mathen, see paragraph [0052], “…a number of processed and sequenced log files can be aggregated to generate a signature that represents that behavior of a heterogeneous enterprise system when a particular change is implemented, such as the patch to a particular module of the heterogeneous enterprise system…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include combining the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models prior to execution as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 13, Reddy does not appear to distinctly disclose:
executing the one or more machine-learning models further trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set.
However, Mathen discloses:
executing the one or more machine-learning models further trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set (Mathen, see paragraph [0068], “…The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects…”), (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0075], “…the trained machine learning component can use the current signature and base signature (e.g., irregularities/defects that can be identified by comparison) to predict downstream defects (e.g., a number of defects) that will be experienced by implementing the change.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include executing a machine-learning model trained to generate the prediction of the one or more dependencies based at least in part on the combined feature data set as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 14, Reddy does not appear to distinctly disclose:
wherein the plurality of software application components comprises one or more of a user portal component, a validator component, an activity component, an authentication component, a secure documentation component, or a third-party application component.
However, Mathen discloses:
wherein the plurality of software application components comprises one or more of (Mathen, see paragraph [0017], “A heterogeneous system can be a computing system with a plurality of different modules or components working together, such as an enterprise software system that leverages different types of cloud services, application services, database services, and the like. In some implementations, these modules or components can be sourced from different product and service vendors and/or developed and built by different development teams.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include a third-party application component as taught by Mathen, for the result of extending the prediction of dependencies and downtime to all parts of the software.
Regarding claim 15, Reddy discloses: A non-transitory computer-readable medium storing instructions that, when executed by one or more processors (Reddy, see paragraph [0006], “…one more non-transitory computer-readable media having computer-executable instructions embodied thereon are provided that, when executed using one or more hardware processors, perform a method for impact identification based on code analysis…”), cause the one or more processors to:
access a software codebase of at least one software application (Reddy, see paragraph [0049], “…one or more code bases that encode one or more client workflows are received, retrieved, obtained, or otherwise accessed as input to the system 100 of FIG. 1…”);
identify, based at least in part on the software codebase, one or more relationships between a plurality of software application components of the at least one software application (Reddy, see paragraph [0040], “…the static dependency graph module 102 generates a static dependency graph that maps a first plurality of dependencies for one or more client workflows, as the workflows are encoded in a code base. The static dependency graph module 102 scans the code in a static manner, without execution of the code…”), (Reddy, see paragraph [0050], “…generating the static dependency graph includes scanning computer code that encodes the one or more client workflows in the code base. In one such aspect, all of the first plurality of dependencies between method calls are identified based on scanning the computer code…”);
extract, based at least in part on the identified one or more relationships between the plurality of software application components, a set of features representative of a runtime environment associated with an execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0043], “…the superimposing module 106 superimposes the internal-domain dynamic dependency graph and the static dependency graph, in aspects, in order to make a comparison of the dependencies found by static scanning of the code and the dependencies found by tracing the workflow when the code is executed in the internal domain…”); and
execute, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies of each of the plurality of software application components on one or more other software application components of the plurality of software application components (Reddy, see paragraph [0006], “…the impact analysis identifies specific upstream and downstream method call dependencies for the one or more client workflows using each of the first, second, and third plurality of dependencies…”), (Reddy, see paragraph [0075], “The system 1600 further includes, in various aspects, a recommendation engine module 1606. The recommendation engine module 1606 identifies at least a second method that was modified by at least one of the one or more prior requests that include a prior modification made to the first method, in aspects. In some aspects, the recommendation engine module 1606 determines a score of the second method, and based on the score, identifies that the second method is predicted to be affected by the modification made to the first method by the current request…”), (Reddy, see paragraph [0065], “…The impact analysis may results in a report that individually identifies, for any particular or selected method, all of the upstream and downstream dependencies of that particular methods as aggregated from the first, second, and third dependencies identified. In this manner, a comprehensive view of all of the dependency relationships for every individual method (e.g., upstream, downstream, sequencing) in the workflows is generated”), (Reddy, see paragraph [0081], “…a plurality of methods are identified, where each of the plurality of methods are predicted to be affected by the modification being made to the first method in the current request…”), (Reddy, see paragraph [0038], “As used herein, a “dependency” can refer to any type of functional call between methods within a component, between one component and another component, and/or between two different solutions, for the workflows within the code base…”),
Reddy does not appear to distinctly disclose:
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components; and
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components.
However, Mathen discloses:
execute, based at least in part on the extracted set of features, one or more machine-learning models trained to generate a prediction of one or more dependencies (Mathen, see paragraph [0068], “…the machine learning component can be a k-nearest neighbor model, a hidden markov model, or any other suitable machine learning model. The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects. For example, the correlation can span multiple modules, where an irregularity (or defect) for a first module (shown by the host logs) can be correlated to a defect for a second module (also shown by the host logs).”), (Mathen, see paragraph [0023], “…events input 102 can be the runtime logs of the different modules or components of the heterogeneous enterprise system while the events of the patch or update are being performed (e.g., current signature)…”),
wherein the prediction of the one or more dependencies comprises an identification of one or more of the plurality of software application components likely to experience a downtime during a remediation of the one or more other software application components (Mathen, see paragraph [0021], “…The trained machine learning component can then identify patterns where an irregularity generates a defect downstream. For example, the historic data can show that in some configurations of heterogeneous enterprise systems, a first irregularity caused by patching or updating a first module can generate a first defect in a second module, while in other configuration of heterogeneous enterprise systems the first irregularity caused by updating or patching the first module can generate a second defect in a third module… Embodiments can also use the predicted defects to predict a downtime for a heterogeneous enterprise system while the change is being implemented, such as downtime for the system while a module is being patched or updated.”), (Mathen see paragraph [0075], “…the machine learning component can predict defects to particular modules/components, and/or can predict a number of defects that will be experienced by implementing the change (e.g., patch or update)…”), (Mathen, see paragraph [0065], “…defects can include failed updates or changes to sub-systems (e.g., failure to run a script or program to update a piece of software), errors in software interactions (e.g., errors generated by a first software module passing a object, value, or piece of data to a second module in an unexpected manner, such as an incorrect format), failed system health diagnostics, aborted processes, and other suitable failures or errors generated within computing device/server logs.”), (Mathen, see paragraph [0040], “A modern software product is often maintained continuously and enhancements/bug fixes are pushed to ensure the product remains in a healthy state…”); and
output, by the one or more machine-learning models, the prediction of the one or more dependencies of each of the plurality of software application components (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0077], “…user interface 1002 can include button 1004 for displaying the downtime associated with a change to a heterogeneous enterprise system. User interface 1102 then shows a graph that illustrates the predicted downtime when implementing changes to a heterogeneous enterprise system versus the actual downtime observed when the change was implemented.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include executing a machine-learning model to generate a prediction wherein the prediction identifies components likely to experience downtime during remediation and outputting the prediction as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 17, Reddy discloses: wherein the instructions further cause the one or more processors to
identify the one or more relationships between the plurality of software application components by receiving a real-time or near real-time data stream during the execution of the at least one software application (Reddy, see paragraph [0051], “…generating the internal-domain dynamic dependency graph includes executing the one or more client workflows within an internal domain and tracing the first plurality of method calls that occur during the execution of the one or more client workflows…”), (Reddy, see paragraph [0060], “…a sequenced method call tree that represents a portion of all of the first plurality of method calls traced during the execution of the one or more client workflows in the internal domain can be generated…”), (Reddy, see paragraph [0061], “…one or more client workflows encoded in one or more code bases are performed or run within, for example, an automated runtime environment that mimics performance and utilization of the client workflow(s)…”).
Regarding claim 18, Reddy does not appear to distinctly disclose: wherein the instructions further cause the one or more processors to
extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application.
However, Mathen discloses: wherein the instructions further cause the one or more processors to
extract a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application (Mathen, see paragraph [0071], “…During the machine learning building phase and training phase, a plurality of variables (e.g., that impact the downtime for a particular customer) were identified. For example, this list of variables can include type of hardware, processor, memory, network, current software version, data center, the previous upgrade path, the client/customer, the volume of data in the database, the source and target release versions, and the like. For example, variables such as processor, memory, source/target release versions, and/or data center can be used to predict downtime…”), (Mathen, see paragraph [0074], “…a probability matrix can be generated to identify the probability that a particular event (e.g., irregularity/defect) has repercussion events elsewhere…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include extracting a set of most predictive features representative of the runtime environment associated with the execution of the at least one software application as taught by Mathen, for the result of improving the accuracy and reliability of the prediction of components likely to experience downtime.
Regarding claim 19, Reddy does not appear to distinctly disclose: wherein the instructions further cause the one or more processors to:
prior to executing the one or more machine-learning models, combine the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models.
However, Mathen discloses: wherein the instructions further cause the one or more processors to:
prior to executing the one or more machine-learning models, combine the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models (Mathen, see paragraph [0025], “…events input 102 can be processed prior to being input to machine learning component 106 to identify discrepancies…”), (Mathen, see paragraph [0050], “…Processing the retrieved log files can include data aggregation/harvesting (e.g., collating logs from various file systems and/or from several parallel processed subsystems to a single location)…”), (Mathen, see paragraph [0052], “…a number of processed and sequenced log files can be aggregated to generate a signature that represents that behavior of a heterogeneous enterprise system when a particular change is implemented, such as the patch to a particular module of the heterogeneous enterprise system…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include combining the set of most predictive features representative of the runtime environment into a combined feature data set for input to the one or more machine-learning models prior to execution as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Regarding claim 20, Reddy does not appear to distinctly disclose but Mathen discloses: wherein the instructions further cause the one or more processors to
generate the prediction of the one or more dependencies based at least in part on the combined feature data set (Mathen, see paragraph [0068], “…The training data can be used to configure the machine learning component to identify correlations between irregularities (which can include defects) and downstream defects…”), (Mathen, see paragraph [0069], “…after training, a trained model that receives input and generates defect prediction output can be generated…”), (Mathen, see paragraph [0075], “…the trained machine learning component can use the current signature and base signature (e.g., irregularities/defects that can be identified by comparison) to predict downstream defects (e.g., a number of defects) that will be experienced by implementing the change.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include generating the prediction of the one or more dependencies based at least in part on the combined feature data set as taught by Mathen, for the result of improving the accuracy and efficiency of the identification and remediation of the components.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Reddy and Mathen as applied to claims 1, 8, and 15 above, and further in view of Chang et al. (US20210058424, Chang hereinafter).
Regarding claim 2, Reddy as modified does not appear to distinctly disclose:
wherein the one or more machine-learning models comprises one or more of a neuromorphic image compression (NIC) model, a spiking neural network (SNN), an autoencoder (AE), a variational autoencoder (VAE), a generative adversarial network (GAN), or a bidirectional generative adversarial network (BiGAN).
However, Chang discloses:
wherein the one or more machine-learning models comprises one or more of (Chang, see paragraph [0058], “…ML system 204 may use or implement an autoencoder for anomaly detection… Autoencoder 602 is an unsupervised artificial neural network that learns how to compress and encode data, and learns how to reconstruct the data back from the reduced encoded representation to a representation that is as close as possible to the original input. One type of autoencoder 602 is a Long Short-Term Memory (LSTM) autoencoder 604. LSTM autoencoder 604 learns representative time series data generated by a microservice or microservice type… AE.sub.i yields a reconstruction loss l based on the structured dataset 504 traced from microservice 120 (step 610). When the reconstruction loss is greater than a reconstruction loss threshold, an anomaly or outlier is detected in the structured dataset 504 from microservice 120 (step 612)…”), (Chang, see paragraph [0057], “…Anomaly detection model 210 is trained on the baseline behaviors of microservices 120-124 so that any type of anomaly that deviates from normal execution behaviors may be detected. During training, ML system 204 may be trained for each microservice or microservice type…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include an autoencoder as taught by Chang, for the result of enabling the prediction of dependencies of software applications.
Regarding claim 9, Reddy as modified does not appear to distinctly disclose:
wherein the one or more machine-learning models comprises one or more of a neuromorphic image compression (NIC) model, a spiking neural network (SNN), an autoencoder (AE), a variational autoencoder (VAE), a generative adversarial network (GAN), or a bidirectional generative adversarial network (BiGAN).
However, Chang discloses:
wherein the one or more machine-learning models comprises one or more of (Chang, see paragraph [0058], “…ML system 204 may use or implement an autoencoder for anomaly detection… Autoencoder 602 is an unsupervised artificial neural network that learns how to compress and encode data, and learns how to reconstruct the data back from the reduced encoded representation to a representation that is as close as possible to the original input. One type of autoencoder 602 is a Long Short-Term Memory (LSTM) autoencoder 604. LSTM autoencoder 604 learns representative time series data generated by a microservice or microservice type… AE.sub.i yields a reconstruction loss l based on the structured dataset 504 traced from microservice 120 (step 610). When the reconstruction loss is greater than a reconstruction loss threshold, an anomaly or outlier is detected in the structured dataset 504 from microservice 120 (step 612)…”), (Chang, see paragraph [0057], “…Anomaly detection model 210 is trained on the baseline behaviors of microservices 120-124 so that any type of anomaly that deviates from normal execution behaviors may be detected. During training, ML system 204 may be trained for each microservice or microservice type…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include an autoencoder as taught by Chang, for the result of enabling the prediction of dependencies of software applications.
Regarding claim 16, Reddy as modified does not appear to distinctly disclose:
wherein the one or more machine-learning models comprises one or more of a neuromorphic image compression (NIC) model, a spiking neural network (SNN), an autoencoder (AE), a variational autoencoder (VAE), a generative adversarial network (GAN), or a bidirectional generative adversarial network (BiGAN).
However, Chang discloses:
wherein the one or more machine-learning models comprises one or more of (Chang, see paragraph [0058], “…ML system 204 may use or implement an autoencoder for anomaly detection… Autoencoder 602 is an unsupervised artificial neural network that learns how to compress and encode data, and learns how to reconstruct the data back from the reduced encoded representation to a representation that is as close as possible to the original input. One type of autoencoder 602 is a Long Short-Term Memory (LSTM) autoencoder 604. LSTM autoencoder 604 learns representative time series data generated by a microservice or microservice type… AE.sub.i yields a reconstruction loss l based on the structured dataset 504 traced from microservice 120 (step 610). When the reconstruction loss is greater than a reconstruction loss threshold, an anomaly or outlier is detected in the structured dataset 504 from microservice 120 (step 612)…”), (Chang, see paragraph [0057], “…Anomaly detection model 210 is trained on the baseline behaviors of microservices 120-124 so that any type of anomaly that deviates from normal execution behaviors may be detected. During training, ML system 204 may be trained for each microservice or microservice type…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a stem for predicting the impact of source code modifications as taught by Reddy, to include an autoencoder as taught by Chang, for the result of enabling the prediction of dependencies of software applications.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Joshua Tran whose telephone number is (571)272-5460.
The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s
supervisor, Hyung Sough can be reached on (571)272-6799. 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 http://pair-direct.uspto.gov. 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.
/JOSHUA TRAN/
Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights