DETAILED ACTION
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 .
This action is in response to response filed on 3/12/2026. This action is Non-Final.
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, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (US 2019/0179624 A1) and further in view of Bhattacharjee et al. (US 2018/0349257 A1) and Freeman et al. (US 2023/0205676 A1).
As per claim 1 (Amended), Agarwal et al. teaches the invention as claimed including, “A method of update deployment by a version control system, the method comprising:
storing a first version of code of a software application in a code repository of the version control system;
receiving an updated version of the code, the updated version comprising a modification of the first version of the code
extracting, using a machine learning model, a plurality of feature labels to represent corresponding functional features in the version control system based on textual information of [[the]] a plurality of updates, the functional features corresponding to a plurality of functionalities;
mapping the plurality of updates using the plurality of feature labels;
identifying, by a processing device based on the plurality of feature labels, a portion of the software application that is altered by the modifications, the portion corresponding to a function of the software application ”
Agarwal et al. teaches, Natural language processing that performs text parsing on product documents to identify (mapping) changes made in the version update. The natural language processing then performs natural language understanding to analyze the scope of those changes (mapping) on the source code and custom files (portion of sw application altered) (0030). A impact analysis report contains information about new functionalities, enhancements to existing functionalities (plurality of updates), a list of issues resolved (updates) in the version upgrade (0029). The release notes and/or product documents hereinafter referred to simply as product documents, may include information about new functionalities, enhancements to existing functionalities, and a list of issues resolved in the version upgrade (0026). Natural language processing identifies key programming language (PL) specific terms and/or phrases (feature labels) from the product documentation that identifies changes made to existing APIs in the version upgrade (mapping) (0031). The text parser in the natural language processing reads the product documents which includes new and existing API change information. The text parser in the natural language processing uses configurable text parsing techniques to derive text patterns (features) from unstructured text of the product documents. The text patterns, which comprises structured texts such as file name related (mapped) to the API change information, are used to filter the list of custom files (portion of code) that are affected by the API change information, to generate an intermediate output comprised of the API change information (0048). The natural language processing processes the product document to identify details associated with any existing API changes. The NLP parses the text to identify the terms that provide an empirical context for the significance of the existing API change (0053). The natural language processing is initially trained using information that comprises pre-defined sample data sets (e.g., the release notes/product documents related to the current version upgrade). Later, the natural language processing is trained using information that comprise previous data sets (e.g., the release notes/product documents related to previous version upgrades, along with optimum real-time working solutions (0067). Based on the initial training, the natural language processing is able to predict the exact context of the version update of the software application (0072). The examiner further states that it would be inherent that the natural language processor is a machine learning model for the reasons as shown above regarding training and using the natural language processor.
Agarwal et al. teaches, the impact analysis report contains information about new functionalities, enhancements to existing functionalities (functional features), a list of issues resolved in the version upgrade (0029). However, Agarwal et al. does not explicitly appear to teach “performing, by the processing device, a verification job on the portion to test the function of the software application
submitting, by the processing device, two or more tasks each corresponding to the portion
Bhattacharjee teaches a test prediction system that can access a mapping table data store to access a mapping table. The mapping table can identify a set of tests that (tasks) can be performed on the source code (subset of code). The mapping table includes the one or more executable functions that are included in the source code. The mapping table can be queried to identify the tests (tasks) that should be run on the affected functions (e.g., the functions that were impacted or affected by the unit of work delivery) (subset of code) included in the modified machine-readable code (0083). The prediction system can access the mapping table to determine the subset of the set of tests. If a first function and a second function are identified (portion of code) as being modified in the comparing step, the mapping table can be queried using the first function identifier and the second function identifier to identify test identifiers that correspond to each of the first function id and the second function id. The test production system can perform each test of the subset of tests to identify whether the modified machine-readable code includes one or more errors (associated with review and correcting) (0086-0087). Bhattacharjee teaches the test prediction system can perform each test of the subset of tests to identify whether the modified machine-readable code includes one or more errors (0087). The examiner states that an error needs to be reviewed and fixed/corrected, therefore the error is associated reviewing and correcting.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Agarwal et al. with Bhattacharjee because both teach determine changes made in a code update. While Agarwal et al. is able to create an impact analysis report Bhattacherajee would be able to use that information to select tests to test code portions that were changed. This would allow one to find errors based on tests for the specific changed portions. Thus, the known technique of Bhattacheraje will improve Agarwal to yield a predictable result of tests for only changed code/functions.
Agarwal et al. and Bhattacharjee do not explicitly appear to teach, “storing a first version of code of a software application in a code repository of the version control system;
receiving n updated version of the code…
…and a second one of the two or more tasks is associated with tracking results of the verification job; [[and]]
saving the results of the verification job in a commit decision with corrections to resolve errors of the mapping of the plurality of updates; and
committing, to the code repository based on the commit decision, the updated version as a second version of the code of the software application.”
Freeman et al. teaches testing committed code to verify successful operation (0009). A code repository manages software code versions including branches of software code (0011). Tests result in a stability score that is used to accept or reject code versions from submission to the repository (0013). A previous version may have previously recorded (0014). Also see 0015 and 00027. After execution of a test, the results of the tests (tracking verification) may be evaluated and compared to determining pass or failure of the tests (0033).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Agarwal et al. and Bhattacharjee with Freeman et al. because all teach performing some type of operation on updated code to determine either what has changed or to test it. Testing code and using the results to determine if it should be applied to a repository is known to one of ordinary skill in the art. Applying this known method would have been obvious to try in order to make sure the code is properly functioning before it is committed.
Claims 8 and 15, they contain similar limitations to claim 1. Therefore, they are rejected for the same reasons.
Claims 2-4, 9-11 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (US 2019/0179624 A1), Bhattacharjee et al. (US 2018/0349257 A1) and Freeman et al. (US 2023/0205676 A1) as applied to claims 1, 8 and 15 above and further in view of Magnezi et al. (US 2021/0042216 A1).
As per claim 2, Agarwal et al. further teach, “The method of claim 1, wherein mapping the plurality of updates using the plurality of feature labels comprises:
gathering a plurality of references corresponding to a first release marker of the code repository of the version control system and a second release marker of the code repository of the version control system, wherein the plurality of updates corresponds to valid commits that take place between the first release marker and the second release marker; and
parsing the plurality of references into a plurality of messages for extracting the plurality of feature labels from the plurality of messages.”
Agarwal et al. teaches a natural language processing identifies key programming language (PL) specific terms and/or phrases (feature label) from the product documentation that identifies changes made to existing APIs in the version upgrade (0031). The text parser in the natural language processing reads the product documents which includes new and existing API change information. The text parser in the natural language processing uses configurable text parsing techniques to derive test patterns from unstructured text of the product documents. The text patterns, which comprises structured texts such as file name related to the API change information, are used to filter the list of custom files that are affected by the API change information, to generate an intermediate output comprised of the API change information (0048). The natural language processing processes the product document to identify details associated with any existing API changes. The NLP parses the text to identify the terms that provide an empirical context for the significance of the existing API change (0053). The natural language processing is initially trained using information that comprises pre-defined sample data sets (e.g., the release notes/product documents related to the current version upgrade). Later, the natural language processing is trained using information that comprise previous data sets (e.g., the release notes/product documents related to previous version upgrades, along with optimum real-time working solutions (0067). Based on the initial training, the natural language processing is able to predict the exact context of the version update of the software application (0072).
However Agarwal et al. does not explicitly appear to teach, “gathering a plurality of references corresponding to a first release marker of the code repository of the version control system and a second release marker of the code repository of the version control system, wherein the plurality of updates corresponds to valid commits that take place between the first release marker and the second release marker; and”
Magnezi et al. teaches, a system can identify a broken software build for a software project. The system can identify a last stable build (first release marker) for the software project. The broken software build may arise from software developers making many code changes to the last stable software-build. These code changes can be referred to as commits. To determine which code commit resulted in the broken software build, the system can generate a list of code commits associated with the software project that were applied after the last stable software-build and before the broken software build (second release marker). Each code commit in the list can be tested to determine which code commit resulted in the broken software build (0009).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Agarwal et al, Bhattacharjee and Freeman et al. with Magnezi et al. because all teach analyzing code changes. As shown above, Agarwal et al. and Bhattacharjee together teach determining what source code/functionality has changes and selecting tests to test the change. Magnezi et al. teaches determining what code commit resulted in a broken software build by gathering all commits from the last stable build to the current commit. This known technique would allow Agarwal et al. to check each commit to determine what changes occurred and to test the changes using Bhattacharjee in order to determine what commit is actually causing the issue.
As per claim 3, Agarwal et al. further teaches, “The method of claim 2, wherein parsing the plurality of references into the plurality of messages comprises:
providing the plurality of messages to a text processing engine; and
tokenizing, by the text processing engine, the plurality of messages into a plurality of phrases.”
Natural language processing identifies key programming language (PL) specific terms and/or phrases (tokenizing) from the product documentation that identifies changes made to existing APIs in the version upgrade (0031). The test parser in the natural language processing reads the product documents which includes new and existing API change information. The text parser in the natural language processing uses configurable text parsing techniques to derive test patterns from unstructured text of the product documents (tokenizing). The text patterns, which comprises structured texts such as file name related to the API change information, are used to filter the list of custom files that are affected by the API change information, to generate an intermediate output comprised of the API change information (0048). The natural language processing processes the product document to identify details associated with any existing API changes. The NLP parses the text to identify the terms that provide an empirical context for the significance of the existing API change (0053). The natural language processing is initially trained using information that comprises pre-defined sample data sets (e.g., the release notes/product documents related to the current version upgrade). Later, the natural language processing is trained using information that comprise previous data sets (e.g., the release notes/product documents related to previous version upgrades, along with optimum real-time working solutions (0067). Based on the initial training, the natural language processing is able to predict the exact context of the version update of the software application (0072).
As per claim 4 (Amedned), Agarwal et al. further teaches, “The method of claim 3, wherein identifying the portion of the software application
generating, by the machine learning model, the plurality of feature labels based on the plurality of phrases from the text processing engine, wherein the plurality of feature labels indicates updated functionalities corresponding to the plurality of updates to be tested.”
Agarwal et al. teaches natural language processing identifies key programming language (PL) specific terms and/or phrases (feature label) from the product documentation that identifies changes made to existing APIs in the version upgrade (0031). The text parser in the natural language processing reads the product documents which includes new and existing API change information. The text parser in the natural language processing uses configurable text parsing techniques to derive test patterns (feature label) from unstructured text of the product documents. The text patterns, which comprises structured texts (feature labels) such as file name related to the API change information, are used to filter the list of custom files that are affected by the API change information, to generate an intermediate output comprised of the API change information (0048). The natural language processing processes the product document to identify details associated with any existing API changes. The NLP parses the text to identify the terms that provide an empirical context for the significance of the existing API change (0053). The natural language processing is initially trained using information that comprises pre-defined sample data sets (e.g., the release notes/product documents related to the current version upgrade). Later, the natural language processing is trained using information that comprise previous data sets (e.g., the release notes/product documents related to previous version upgrades, along with optimum real-time working solutions (0067). Based on the initial training, the natural language processing is able to predict the exact context of the version update of the software application (0072).
Claims 9-11 and 18-18, they contain similar limitations to claims 2-4. Therefore, they are rejected for the same reasons.
Claims 5-7, 12-14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (US 2019/0179624 A1), Bhattacharjee et al. (US 2018/0349257 A1), Freeman et al. (US 2023/0205676 A1) and Magnezi et al. (US 2021/0042216 A1) as applied to claims 4, 11 and 18 above and further in view of Geddes et al. (US 2022/0083450 A1).
As per claim 5, Agarwal et al, Bhattacharjee, Freeman et al. and Magnezi do not explicitly appear teach, “The method of claim 4, wherein generating, by the machine learning model, the plurality of feature labels based on the plurality of phrases from the text processing engine comprises:
predicting one or more new functional updates associated with the plurality of updates without executing the plurality of updates, wherein the machine learning model analyzes the plurality of phrases using at least one of a neural embedder or a convolutional neural network for predicting the one or more new functional updates using historical data.”
Geddes et al. teaches, generating a patch (new update) to fix bugs and/or vulnerabilities using deep learning encoder-decoder architectures that may utilize recurrent neural networks (RNNs) or multi-head attention (0025). A revision history including a listing of update implemented by patch generator may be used to rain the various deep learning models available to the patch generator (0044). See also 0066-0098.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Agarwal et al, Bhattacharjee, Freeman and Magnezi et al. with Geddes et al. As shown above, Agarwal et al. together with Bhattacharjee teaches determining what source code/functionality has changed and selecting tests to just test what has changed. Magnezi et al. teaches finding all code changes (updates/commits) and testing those code changes to determine the root cause of an error in the build. Magnezi et al. further teaches, the generation of a patch or suggestion to solve the found error. Geddes et al. teaches, generating a patch to fix bugs and/or vulnerabilities using deep learning encoder-decoder architectures that may utilize recurrent neural networks (RNNs). There are many ways in which a system can determine a fix for an issue/error. The use of deep learning/machine learning is well known to one of ordinary skill in the art and would have been obvious.
As per claim 6, Magnezi et al. further teaches, “The method of claim 5, wherein the one or more new functional updates comprise new commits to be deployed in the code repository of the version control system.”
Magnezi et al. teaches a generated code patch or suggestion is sent to an administrator or developer for review, editing and implementation. In some embodiments the patch generation module can automatically apply (commit) the generated patch to the software project (0021).
As per claim 7, Agarwal et al. further teaches, “The method of claim 5, further comprising:
providing the plurality of feature labels into a dataset having additional features from other data sources;
generating, by the machine learning model or an engine based on a gradient boosted tree algorithm, an updated set of plurality of feature labels base on the dataset; and
tagging, based on the updated set of plurality of feature labels, new commits of the plurality of updates corresponding to the subset of codes.”
Agarwal et al. teaches a natural language processing identifies key programming language (PL) specific terms and/or phrases (feature label) from the product documentation that identifies changes made to existing APIs in the version upgrade (0031). The text parser in the natural language processing reads the product documents which includes new and existing API change information. The text parser in the natural language processing uses configurable text parsing techniques to derive test patterns (feature label) from unstructured text of the product documents. The text patterns, which comprises structured texts (feature labels) such as file name related to the API change information, are used to filer the list of custom files that are affected by the API change information, to generate an intermediate output comprised of the API change information (0048). The natural language processing processes the product document to identify details associated with any existing API changes. The NLP parses the text to identify the terms that provide an empirical context for the significance of the existing API change (0053). The natural language processing is initially trained using information that comprises pre-defined sample data sets (e.g., the release notes/product documents related to the current version upgrade). The natural language processing is trained using information that comprise previous data sets (e.g., the release notes/product documents related to previous version upgrades, along with optimum real-time working solutions (0067). Based on the initial training, the natural language processing is able to predict the exact context of the version update of the software application (0072).
Claims 12-14 and 19-20, contain similar limitations to claims 4-7. Therefore, they are rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 3/12/2026 have been fully considered but are moot due to amendments. Please see above rejection regarding new limitations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199