/5/24Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office action is in response to the amendment filed on January 15, 2026.
Claims 1-20 are pending with claims 1, 8, and 15 being independent claims.
Response to Arguments
Applicant’s arguments filed on 1/15/2026 have been fully considered, but they are not persuasive.
In the Remarks, Applicant argues: The error data sets described in Bergen are not an "issue report describing any one of the software engineering tasks with source code associated with the any one of the software engineering tasks," as required by claim 1. Since Bergen's software error data sets do not describe software engineering tasks, they are not a disclosure of issue reports that describe software engineering tasks and correspondingly do not cure Gnaneswaran's acknowledged deficiency. (Remarks, pg. 7-8)
Examiner’s response:
Examiner respectfully disagrees with Applicant’s assertion that the software error data sets described in Bergen are not “an "issue report describing any one of the software engineering tasks with source code associated with the any one of the software engineering tasks," as required by claim 1.
Contrary to Applicant’s assertion, Bergen teaches a plurality of software error data sets that function as issue reports documenting software defects and their resolution. As shown in Bergen’s Fig. 1 and described at col. 2, ln. 20-31, Bergen teaches that each software error data set include source code exhibiting an error as well as corresponding source code without the error, which describes a software engineering task of error-analysis by showing the possible error source. Further, Bergen teaches that software error data set includes a proposed code section with erroneous code that causes undesired performance, which describes a software engineering task of debugging by pinpointing the code that needs to be fixed. Accordingly, Bergen’s software error data sets do not merely identify software source code errors, but describe the performance of software engineering tasks through their recorded inputs, analyses, and corrective actions, thereby satisfying the requirement for an issue report describing software tasks with associated source code.
Importantly, Bergen’s software error data sets do not merely exist in isolation, but describe performance of the foregoing software engineering tasks through their included contend. Specifically, each error data set includes: a) source code containing an error, b) corresponding source code without the error, and c) reworked source code that corrects the error (Fig. 1, col. 2, ln. 20-31; col. 4, ln. 51-54). By documenting the identification of an source code error, the analysis of erroneous versus non-erroneous code, and the provision of corrected code, Bergen’s error data sets inherently describe the software engineering tasks being performed and include the associated source code. Accordingly, Bergen’s software error data sets constitute issue reports describing software engineering tasks with associated source code, as recited in Applicant’s claim 1.
Therefore, for at least the reasons set forth above, the rejections made under 35 U.S.C. § 103(a) with respect to claims 1, 8 and 15 are proper and therefore, maintained.
With respect to the remaining independent and dependent claims, Applicant merely reiterates the argument made regarding claim 1 and asserts that any additional references cited by the Examiner fail to resolve the alleged deficiencies in the rejections of the independent claims (see Remarks at pg. 8). Applicant’s arguments are unpersuasive for the same reasons articulated above with respect to claim 1.
Allowable Subject Matter
Claims 7, 14, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of their base claims and any intervening claims respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-6, 8-12, 12-13, 15-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0342251 (hereinafter "Gnaneswaran”) in view of US 10,423,522 (hereinafter “Bergen”).
In the following claim analysis, Applicant’s claim limitations are shown in bold text and Examiner’s explanations/notes/remarks are enclosed in square brackets and emphases are underlined.
As to claim 1, Gnaneswaran discloses A system that trains machine-learning models to assist with performing software engineering tasks (Gnaneswaran, Fig. 3, ¶ 23, a sequence diagram of an example method for implementing machine learning to continuously train a prediction model for determining changeset risk factors), the system comprising:
one or more processors (Gnaneswaran, claim 15, a computing device including a hardware-based processor that executes the instructions to carry out stages); and a non-transitory computer readable medium storing a plurality of instructions, which when executed, cause the one or more processors to (Gnaneswaran, claim 15, a memory storage including a non-transitory, computer-readable medium comprising instructions):
retrieve data from a plurality of data sources associated with software engineering tasks (Gnaneswaran, Fig. 1, ¶ 32, the aggregator can obtain the target code data from a central data stream that includes an extraction layer which collects and saves data from different data sources … a computing service that can collect data from other code data streams, as well as code review services);
link the data by linking pass or fail results of overall changeset describing any one of the software engineering tasks with source code associated with the any one of the software engineering tasks (Gnaneswaran, ¶ 33, The central data stream can collect data related to: CICD pipeline execution; overall changeset pass or fail results that get triggered for each code review … the central data stream can collect feature data related to the target code; ¶ 36, For each instance of data collection and aggregation by the aggregator, a call can be made to central data stream requesting data related to the target code);
transform the data to be compatible with a data format used to train a machine-learning model to assist with performing software engineering tasks (Gnaneswaran, ¶ 98, the controller 422 can modify or format training data from any source. For example, the controller 422 may format data provided from a component of the modification review system 420, so that the data can be processed by review system component, such as the model generator 426; ¶ 27, The prediction model can be trained, continuously, with training data that includes a plurality of data artifacts resulting from code build processes; ¶ 37, The prediction model can be trained, continuously, with training data that includes a plurality of data artifacts resulting from code build processes; ¶ 38, An algorithm implemented by a prediction model for a requested use case can determine a pattern in the training data, map input data to a target (review time, risk factors, overall risk factor) of the selected use case, and provide a machine learning model output that captures the patterns);
train the machine-learning model with the transformed data to assist with performing a software engineering task (Gnaneswaran, ¶ 29, FIG. 4 can represent system components that respectively communicate as components of an enterprise computing infrastructure that generates and continuously trains prediction models for evaluating changesets to code of software products used; ¶ 34, the aggregator can collect and aggregate the data from the central data stream into a package of aggregated data. In one example, the aggregated data can be transmitted to a machine learning model as part of a prediction model training process;¶ 37, The training data can include a plurality of data artifacts corresponding to results from a plurality of code build processes associated with the target code … training can include running a training session using data artifacts from the repository not available in a previous training iteration; ¶ 107, the model generator 426 can be provided by a script that obtains the latest training data and creates machine learning artifacts required to formulate a prediction) by making a prediction of source code associated with the software engineering task (Gnaneswaran, ¶ 21, Based on the training data, the machine learning model is trained to generate a prediction of task code(s) and a probability a user will select the respective task code).
Gnaneswaran does not appear to explicitly disclose link the data by linking each issue report describing any one of the software engineering tasks with source code and making a prediction of source code change associated with the software engineering task. However, in an analogous art to the claimed invention in the field of software maintenance or management, Bergen teaches link the data by linking each issue report describing any one of the software engineering tasks with source code (Bergen, Fig. 1, col. 2, ln. 20-31, collect a plurality of software error data sets (operation 102). … each software error data set includes a proposed code section with erroneous code that causes undesired performance … With either example software error data set, erroneous code can be identified by comparing the code with the error and the code without the error; col. 3, ln. 55-58, examine a section of code and predict whether the code section contains suspicious code that may not execute as intended; col. 4, ln. 51-54, the identified suspicious code and the reworked code that fixed an error found in the suspicious code) and making a prediction of source code change associated with the software engineering task (Bergen, col. 3, ln. 55-58, The prediction model may be used to examine a section of code and predict whether the code section contains suspicious code that may not execute as intended; col. 4, ln. 51-54, the identified suspicious code and the reworked code that fixed an error found in the suspicious code can be provided to the classification engine to improve the prediction accuracy of the classification engine).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gnaneswaran’s system with the system taught by Bergen including link[ing] the data by linking each issue report describing any one of the software engineering tasks with source code associated with the any one of the software engineering tasks and making a prediction of source code change associated with the software engineering task. The modification would be obvious because one of ordinary skill in the art would be motivated to detect a likely software malfunction by training a computer-implemented algorithmic model using the collected software error data sets to devise a software code classifier for predicting a likely error in a code section, reviewing a section of code using the software code classifier, and identifying suspicious code in the reviewed section of code as containing a suspected error using the software code classifier (Bergen, Abstract).
As to claim 2, the rejection of claim 1 is incorporated. Gnaneswaran as modified further discloses The system of claim 1, wherein the plurality of instructions further causes the one or more processors to iteratively retrieve additional data from the plurality of data sources, link the retrieved additional data, transform the additional data, and train the machine-learning model with the transformed additional data (Gnaneswaran, Fig. 2B, ¶ ¶ 57-60, a model tuning instruction can be generated in stage 268. Following generation, the orchestration service can transmit the tuning instruction to the model generator in stage 270. An optional series of stages 271, 273, and 275 for additional training data acquisition can be executed as a result of the model generator receiving the tuning instruction at stage 270. In one example, execution of the series, instead of being optional, can be conditioned on a check of an inventory of training data immediately accessible by the model generator. The model generator may determine that additional data artifacts, or more up to date data artifacts, are required for tuning the prediction model; ¶ 13, Training of the prediction model can continue on an automatic basis).
As to claim 3, the rejection of claim 2 is incorporated. Gnaneswaran as modified further discloses The system of claim 2, wherein iteratively training the machine-learning model with the transformed additional data comprises one of initializing the machine-learning model, and then using only the transformed additional data to train the initialized machine-learning model, using both the transformed additional data and the data that was previously transformed to train the machine-learning model, or incrementally using the transformed additional data to train the machine-learning model (Gnaneswaran, ¶ 13, Training of the prediction model can continue on an automatic basis until a variance between the validation score and the model accuracy score is within a predetermined range; ¶ 27, The prediction model can be trained, continuously, with training data that includes a plurality of data artifacts resulting from code build processes; ¶ 29, continuously trains prediction models for evaluating changesets to code of software products used internally, or sold externally by the enterprise; Fig. 2B, ¶ ¶ 57-60).
As to claim 5, the rejection of claim 1 is incorporated. Gnaneswaran as modified further discloses The system of claim 1, wherein the data is retrieved from a plurality of data sources which comprise a data source associated with a plurality of software engineering projects associated with a single enterprise (Gnaneswaran, ¶ 48, The data source can be a central data stream that receives data related to target code for a software product from other data streams [from a plurality of software engineering projects associated with a company] and code review services).
As to claim 6, the rejection of claim 1 is incorporated. Gnaneswaran as modified further discloses The system of claim 1, wherein the machine-learning model comprises one of a group comprising the machine-learning model trained with data associated with a plurality of software engineering projects associated with a single enterprise (Gnaneswaran, ¶ 48, The data source can be a central data stream that receives data related to target code for a software product from other data streams [from a plurality of software engineering projects associated with a company] and code review services) and the machine-learning model trained with data associated with general software engineering knowledge, or the machine-learning model trained with both data associated with multiple software engineering projects associated with a single enterprise (Gnaneswaran, ¶ 48, The data source can be a central data stream that receives data related to target code for a software product from other data streams [from a plurality of software engineering projects associated with a company] and code review services) and data associated with general software engineering knowledge (Gnaneswaran, ¶ 33, The central data stream can collect data related to: CICD pipeline execution; overall changeset pass or fail results that get triggered for each code review [with general software engineering knowledge]; and the code data stream pipeline stages, tasks, and execution results).
Claim 8 is essentially the same as claim 1 except is set forth the claimed invention as a method and is rejected with the same reasoning as applied hereinabove.
As to claims 9-10 and 12-13, the rejection of claim 8 is incorporated and the claims are corresponding to system claims 2-3 and 5-6. Therefore, they are rejected under the same rational set forth in the rejections of claims 2-3 and 5-6.
Claim 15 is essentially the same as claim 1 except is set forth the claimed invention as a computer program product and is rejected with the same reasoning as applied in claim 1.
As to claims 16-17 and 19, the rejection of claim 15 is incorporated and the claims are corresponding to system claims 2-3 and 5. Therefore, they are rejected under the same rational set forth in the rejections of claims 2-3 and 5.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0342251 (hereinafter "Gnaneswaran”) in view of US 10,423,522 (hereinafter “Bergen”) and further in view of US 2023/0214190 (hereinafter “MANIVASAGAM”).
As to claim 4, the rejection of claim 1 is incorporated. Gnaneswaran as modified does not appear to explicitly disclose The system of claim 1, wherein the data is retrieved from a plurality of data sources which comprise an open-source software project. However, in an analogous art to the claimed invention in the field of software management, MANIVASAGAM teaches The system of claim 1, wherein the data is retrieved from a plurality of data sources which comprise an open-source software project (MANIVASAGAM, ¶ 107, In implementations, steps of the Design Thinking process 1006-1010 are completed, … with assistance from the AI module 420 of the server 404, utilizing information stored in the knowledge base repository 412 or 412′. Information stored in the knowledge base repository 412 or 412′ may be obtained from … self-created repositories (e.g., from the open-source community), and from various data sources accessible via the network 402, which can be automatically collected and stored by the server 404).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gnaneswaran’s system as modified with the system taught by MANIVASAGAM including that the data is retrieved from a plurality of data sources which comprise an open-source software project. The modification would be obvious because one of ordinary skill in the art would be motivated to run an open-source software project and collect source data related to the project to take advantages of open source projects, such as promoting a collaborative environment, implementing public available source code to customize and integrate projects into users own systems.
As to claims 11 and 18, the rejections of claims 8 and 15 are incorporated respectively, and they are corresponding to system claim 4. Accordingly, they are rejected under the same rational set forth in the rejection of claim 4.
Conclusion
THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAXIN WU whose telephone number is (571) 270-7721. The examiner can normally be reached on M-F (7 am - 11:30 am; 1:30- 5 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Wei Mui can be reached at (571) 272-3708. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
Wu, Daxin
Primary Examiner
Art Unit 2191
/DAXIN WU/Primary Examiner, Art Unit 2191