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-20 are objected to because of the following informalities:
Claim 1, line 9: “the indication” must have been --the second indication--.
Claim 1, line 10: “the coder LLM model” lacks proper antecedent basis.
Claim 8, line 8: “the indication” must have been --the second indication--.
Claim 15, line 8: “a code repository” must have been --the code repository--.
Claim 19 line 1: replace “plural LLMs” with --plural large language models (plural LLMs)--.
Claim 20 lines 2-3: “the suggested corrections” lack proper antecedent basis.
Claims 2-7 are objected to for being dependent on claim 1.
Claims 9-14 are objected to for being dependent on claim 8.
Claims 16-20 are objected to for being dependent on claim 15.
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.
Claim 5-7 and 12-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 5 lines 1-4, the claim does not contain --and-- or --or-- before the final item of the list. Therefore, it is unclear whether or not the claim requires at least one of all items in the list or if only a single item is sufficient. For examination purposes, the claim will be treated as --or--.
Regarding claim 6 lines 1-3, the claim does not contain --and-- or --or-- before the final item of the list. Therefore, it is unclear whether or not the claim requires at least one of all items in the list or if only a single item is sufficient. For examination purposes, the claim will be treated as --or--.
Regarding claim 12 lines 1-4, the claim does not contain --and-- or --or-- before the final item of the list. Therefore, it is unclear whether or not the claim requires at least one of all items in the list or if only a single item is sufficient. For examination purposes, the claim will be treated as --or--.
Regarding claim 13 lines 1-3, the claim does not contain --and-- or --or-- before the final item of the list. Therefore, it is unclear whether or not the claim requires at least one of all items in the list or if only a single item is sufficient. For examination purposes, the claim will be treated as --or--.
Regarding claim 15 line 7, it is unclear whether or not “the code” is referencing the “ground truth code” in line 2 or the “test code” in line 4. For examination purposes, the claim will be treated as --test code--.
Regarding claims 7 and 14, the claims are rejected for being dependent upon claims 6 and 13, respectively.
Regarding claims 16-20, the claims are rejected for being dependent upon claim 15.
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, 2, and 3 are rejected under 35 U.S.C. 103 as being unpatentable over MacIver et al. (US12393401, MacIver hereinafter) in view of Rasheed et al. (AI-powered Code Review with LLMs: Early Results, 2024, Rasheed hereinafter) and Palanki et al. (US20250217584, Palanki hereinafter).
Regarding claim 1, MacIver discloses: An apparatus comprising: at least one processor system (MacIver, see col. 7 lines 3-7, “...Computing device 400 may include processor 405 that may be coupled to memory 410. Memory 410 may include volatile memory. Processor 405 may execute computer-executable program code stored in memory 410, such as software programs 415...”) configured to:
input code from a coder computer (“workstation 120”) to at least a (MacIver, see col. 4 lines 9-35, “Analysis and recommendation service may interface with workstation 120 that may be used by a user (e.g., a developer) to write code, or to retrieve code from library 140”...“code entered from workstation 120 and/or retrieved from libraries”), (MacIver, see col. 6 lines 42-44, “the analysis and recommendation service may receive the code from the repository, or may receive the code as it is being entered.”), (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree, etc.”);
receive (MacIver, see col. 1 lines 38-51, “(4) checking, by the analysis and recommendation service computer program, the code for compliance with the rules or control patterns;”), (MacIver, see col. 2 lines 5-10, “checks the code for compliance with the rules or control patterns by: extracting features from the code; generating labels for each of the features; and classifying the labeled features as compliant or non-compliant.”), (MacIver, see col. 4 lines 26-35, “review code entered from workstation 120 and/or retrieved from libraries 140, and may check the code for compliance against a set of rules and their objectives, and, against a set of best practices and standards for one or more domain, such as an organization's published API Standards”), (MacIver, see col. 5 lines 33-41, “indicate compliance or non-compliance. The machine learning engine may be trained on these features and labels and used to predict whether code is complaint or not compliant.”);
responsive to the first indication, commit the code to a code repository (MacIver, see col. 1 lines 38-51, “(5) deploying, by analysis and recommendation service computer program, the code in response to the code being in compliance”), (MacIver, see col. 6 lines 5-6, “code that is recommended may either be automatically integrated into the software repository”);
responsive to the second indication, input the indication to at least a coder LLM (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4);
receive from the coder LLM model at least one alternative solution responsive to the second indication for implementation of the alternative solution in the code (MacIver see col. 1 lines 52-63 “ determining, by the analysis and recommendation service computer program, that the code is not in compliance; identifying, by the analysis and recommendation service computer program, a recommendation for the code to comply to with the rules or control patterns; enriching, by the analysis and recommendation service computer program, the code by incorporating the recommendation into the code; and deploying, by the analysis and recommendation service computer program, the code.”), (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4).
MacIver does not appear to distinctly disclose:
However, Rasheed discloses:
input code (Rasheed, see page 2 paragraph 2, “our paper introduces a novel LLM-based AI agent system specifically tailored for the software development context. The proposed multi-agent system consists of four agents that identify code smells, potential bugs, and deviations from coding standards, and, crucially, provide actionable suggestions for improvement”), (Rasheed, see page 3 paragraph 5, “LLM-based AI agent system aimed at identifying potential issues in code and providing actionable recommendations”), (Rasheed, see page 4 paragraph 3, “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code”), and
receive from the (Rasheed, see page 3 paragraph 5, “LLM-based AI agent system aimed at identifying potential issues in code”).
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 system for improving software compliance as taught by MacIver, to include inputting code to at least a license and policy large language model and receiving indications of compliance and non-compliance as taught by Rasheed, for the result of evaluating code against coding rules and producing a compliance indication to control the subsequent handling of the code.
MacIver as modified does not appear to distinctly disclose:
However, Palanki discloses:
input code (Palanki, see paragraph [0043], “The trained LLM 146 can use the protection module 159 to determine a type of misuse by running multiple tests. The tests may include a harmful content test, a bias test, a sensitive data element (SDE) test, a hallucination test, a code generator test, an offensive language test, a copyright test, a license violation test, or a combination thereof.”), (Palanki, see paragraph [0051], “A license violation test can include checking whether there is any use, distribution, or modification of a software product or its source code in a manner that is not in compliance with the terms and conditions specified by the software's license.”) (Palanki, see paragraph [0040], “Content can be determined to be inappropriate if it violates set policy standards, laws, regulations, etc.”), and
receive from the L&P LLM a first or second indication respectively indicating that the code complies with all of plural code rules and that the code does not comply with at least one of the code rules (Palanki, see paragraph [0040], “an anomalous transaction can be determined if the inputs and/or the outputs include information or data that is inaccurate, nonsensical, fictitious, inappropriate, breaches confidentiality, is offensive, is based on or communicates bias, violates a license, violates intellectual property protection (e.g., copyright), etc. Additionally, or alternatively, an anomalous transaction can be determined if the inputs and/or the outputs violate applicable standards. In contrast, a normal transaction can be determined if the inputs and/or outputs are devoid of any anomalies or a predefined number of anomalies. Additionally, or alternatively, a normal transaction can be determined based on the inputs and/or outputs following applicable standards.”), (Palanki, see paragraph [0033], “the trained LLM service provider 139 can report details, including the transaction metadata, of the blocked transaction to the distributed agent 119, the client device 113, etc.”).
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 system for improving software compliance as taught by MacIver, to include inputting code to a L&P LLM and receiving an indication of compliance or non-compliance as taught by Palanki, for the result of producing a compliance indication to control subsequent handling of code.
Regarding claim 2, MacIver discloses:
automatically implement the alternative solution in the code (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree... In step 235, the analysis and recommendation service may deploy the compliant code”), (MacIver, see col. 6 lines 58-61 “code that is recommended may either be automatically integrated into the software repository”).
Regarding claim 3, MacIver discloses:
provide the alternative solution to the coder computer for implementation by the coder computer in the code (MacIver see col. 5 lines 56-67 col. 6 lines 1-4, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree... In step 235, the analysis and recommendation service may deploy the compliant code”).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, and Palanki as applied to claim 1 above, and further in view of Medford (US20250165890).
Regarding claim 4, MacIver does not appear to distinctly disclose:
receive the first or second indication from the L&P LLM at a gatekeeper LLM; and
based on output from the gatekeeper LLM, commit the code to the code repository or input the second indication to the coder LLM.
However, Rasheed discloses:
receive the first or second indication from the (Rasheed, see page 2 paragraph 2, “our paper introduces a novel LLM-based AI agent system specifically tailored for the software development context. The proposed multi-agent system consists of four agents that identify code smells, potential bugs, and deviations from coding standards, and, crucially, provide actionable suggestions for improvement”), (see page 3 paragraph 5, “LLM-based AI agent system aimed at identifying potential issues in code and providing actionable recommendations”), (page 4 paragraph 3. “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code”);
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 system for improving software compliance as taught by MacIver, to include receiving an indication from an L&P LLM as taught by Rasheed, for the result of capturing the L&P LLM’s compliance determination to use downstream.
MacIver as modified does not appear to distinctly disclose:
based on output from the gatekeeper LLM, commit the code to the code repository or input the second indication to the coder LLM.
However, Palanki discloses:
receive the first or second indication from the L&P (Palanki, see paragraph [0040], “an anomalous transaction can be determined if the inputs and/or the outputs include information or data that is inaccurate, nonsensical, fictitious, inappropriate, breaches confidentiality, is offensive, is based on or communicates bias, violates a license, violates intellectual property protection (e.g., copyright), etc. Additionally, or alternatively, an anomalous transaction can be determined if the inputs and/or the outputs violate applicable standards. In contrast, a normal transaction can be determined if the inputs and/or outputs are devoid of any anomalies or a predefined number of anomalies. Additionally, or alternatively, a normal transaction can be determined based on the inputs and/or outputs following applicable standards.”), (Palanki, see paragraph [0033], “the trained LLM service provider 139 can report details, including the transaction metadata, of the blocked transaction to the distributed agent 119, the client device 113, etc.”);
However, Medford discloses:
receive the first or second indication from the (“Executor Agent 210”) at a gatekeeper LLM (“Chat Manager Agent 212”) (Medford, see paragraph [0069], “Once the code is executed, the Executor Agent 210 collects data on its performance, including execution logs, error reports, and output results. This data provides tangible feedback on the code's real-world operability. The Chat Manager Agent 212 then processes this output to determine the success of the execution. It analyzes the data to identify any errors or issues that occurred during the execution and assesses whether the code has met all operational benchmarks successfully.”); and
based on output from the gatekeeper LLM, commit the code to the code repository (Medford, see paragraph [0071], “This iterative development process, facilitated by the Chat Manager Agent 212, ensures that the software code evolves into a robust and efficient final product, ready for deployment. Once the code successfully passes all tests and validations without any errors, it is deemed ready for a final commit to a code repository, such as Git. This final step formally integrates the tested and approved code into the project's main codebase, making it available for deployment or further integration with other system components. The detailed workflow of this process, including the interactions between the Engineer Agent 208, Executor Agent 210, and the Chat Manager Agent 212 leading to the final code commit, is illustrated in FIG. 3”).
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 system for improving software compliance as taught by MacIver, to include receiving an indication from the L&P LLM at a gatekeeper LLM and committing code to a repository based on the output of the gatekeeper LLM as taught by Medford, for the result of only allowing code that complies with all rules to be committed to a repository.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, and Palanki as applied to claim 1, and further in view of Kumar (US20260037234).
Regarding claim 5, MacIver as modified does not appear to distinctly disclose:
wherein the plural code rules comprise one or more of proper indentation to ensure readability, naming convention for variables, functions and code file names, standardization of module headers, maximum number of characters in each line of code.
However, Kumar discloses:
wherein the plural code rules comprise one or more of (Kumar, see paragraph [0018], “software code is software code that adheres to a set of additional rules, restrictions, and/or conventions... The additional rules, restrictions, and/or conventions are in addition to the set of rules that characterize the programming language and that every set of software code written in the programming language are required to comply with. Examples of additional rules that characterize proprietary software code include naming conventions for naming data objects, variables”).
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 system for improving software compliance as taught by MacIver, to include naming convention for variables as taught by Kumar, for the result of enforcing consistent style, readability, and maintainability across the codebase.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, and Palanki as applied to claim 1 above, and further in view of Somsikov et al. (US20180349575).
Regarding claim 6, MacIver as modified does not appear to distinctly disclose:
wherein the plural code rules comprise one or more of use of a specific code library forbidden by at least one license, specific use of code forbidden by at least one license.
However, Somsikov discloses:
wherein the plural code rules comprise one or more of use of a specific code library forbidden by at least one license, specific use of code forbidden by at least one license (Somsikov, see paragraph [0012], “authorization verification tools make use of managed code libraries that provide functionality for applications to check a user's authorization (e.g., a license status) with a trusted authorization server (e.g., a trusted licensing server)”), (Somsikov, see paragraph [0013],“to check a licensing status, an application calls functions provided by an authorization verification library to check the licensing status of the computing device on which the user is trying to run the application. The trusted authentication servers retrieve licensing details of the application for the particular device on which the application is running. The application then determines whether the licensing details satisfy the licensing constraints.”), (Somsikov, see paragraph [0014], “licensing constraints the trusted authorization server may return licensing details (e.g., whether the device or user is authorized, what level they are authorized to, and the like) to the application on the device. The application then uses the licensing details to determine whether the use of the application is to be allowed”).
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 system for improving software compliance as taught by MacIver, to include rules comprising use of a specific code library forbidden by a license or specific use of code forbidden by a license as taught by Somsikov, for the result of screening the code for license-based restriction on library and code use prior to commitment.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, Palanki, and Somsikov as applied to claim 6 above, and further in view of Fisher et al. (US20250307465, Fisher hereinafter).
Regarding claim 7, MacIver does not appear to distinctly disclose:
wherein information identifying licenses is deleted from information provided to the L&P LLM.
However, Somsikov discloses:
(Somsikov, see paragraph [0014], “licensing constraints the trusted authorization server may return licensing details (e.g., whether the device or user is authorized, what level they are authorized to, and the like) to the application on the device. The application then uses the licensing details to determine whether the use of the application is to be allowed”).
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 system for improving software compliance as taught by MacIver, to include information identifying licenses as taught by Somsikov, for the result of allowing the identification of applicable licenses.
MacIver as modified does not appear to distinctly disclose:
wherein
However, Fisher discloses:
wherein information identifying (Fisher, see paragraph [0007], “a method of large language model (LLM)-agnostic data anonymization comprises authenticating a user to a system for data anonymization for a LLM; intercepting a request from the user to upload a document into an LLM service; parsing the document to extract document content; detecting confidential information (CI) within the document content; obfuscating the detected CI; redacting the document by replacing the CI with the obfuscated CI; uploading the redacted document to the LLM service”), (Fisher, see paragraph [0019], “data anonymization can include data obfuscation (and data deobfuscation) to protect confidential information a user is going to send to an LLM service”), (Fisher, see paragraph [0020], “the terms “personal data,” “personal information,” “personally identifiable information (PII),” “sensitive data,” “confidential information (CI)” and similar language do not reference any particular definition”).
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 system for improving software compliance as taught by MacIver, to include deleting from information provided to an LLM as taught by Fisher, for the result of evaluating code without considering license-identifying information.
Claims 8, 9, 10, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over MacIver et al. (US12393401, MacIver hereinafter) in view of Rasheed et al. (AI-powered Code Review with LLMs: Early Results, 2024, Rasheed hereinafter) and Medford (US20250165890).
Regarding claim 8, MacIver discloses: An apparatus comprising: at least one processor system (MacIver, see col. 7 lines 3-7, “...Computing device 400 may include processor 405 that may be coupled to memory 410. Memory 410 may include volatile memory. Processor 405 may execute computer-executable program code stored in memory 410, such as software programs 415...”) configured to:
input code from a coder computer to at least a first machine learning (ML) model (MacIver, see col. 4 lines 9-35, “Analysis and recommendation service may interface with workstation 120 that may be used by a user (e.g., a developer) to write code, or to retrieve code from library 140”...“code entered from workstation 120 and/or retrieved from libraries”), (MacIver, see col. 6 lines 42-44, “the analysis and recommendation service may receive the code from the repository, or may receive the code as it is being entered.”), (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree, etc.”);
receive from the first ML model a first or second indication respectively indicating that the code complies with all of plural code rules and that the code does not comply with at least one of the code rules (MacIver, see col. 1 lines 38-51, “(4) checking, by the analysis and recommendation service computer program, the code for compliance with the rules or control patterns;”), (MacIver, see col. 2 lines 5-10, “checks the code for compliance with the rules or control patterns by: extracting features from the code; generating labels for each of the features; and classifying the labeled features as compliant or non-compliant.”), (MacIver, see col. 4 lines 26-35, “review code entered from workstation 120 and/or retrieved from libraries 140, and may check the code for compliance against a set of rules and their objectives, and, against a set of best practices and standards for one or more domain, such as an organization's published API Standards”), (MacIver, see col. 5 lines 33-41, “indicate compliance or non-compliance. The machine learning engine may be trained on these features and labels and used to predict whether code is complaint or not compliant.”);
responsive to the first indication, commit the code to a code repository (MacIver, see col. 1 lines 38-51, “(5) deploying, by analysis and recommendation service computer program, the code in response to the code being in compliance”), (MacIver, see col. 6 lines 5-6, “code that is recommended may either be automatically integrated into the software repository”);
responsive to the second indication, input the indication to at least a (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4);
receive from the (MacIver, see col. 1 lines 52-63 “ determining, by the analysis and recommendation service computer program, that the code is not in compliance; identifying, by the analysis and recommendation service computer program, a recommendation for the code to comply to with the rules or control patterns; enriching, by the analysis and recommendation service computer program, the code by incorporating the recommendation into the code; and deploying, by the analysis and recommendation service computer program, the code.”), (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4).
MacIver does not appear to distinctly disclose:
However, Rasheed discloses:
receive from the second ML model at least one alternative solution responsive to the second indication for implementation of the alternative solution in the code (Rasheed, see page 2 paragraph 2, “our paper introduces a novel LLM-based AI agent system specifically tailored for the software development context. The proposed multi-agent system consists of four agents that identify code smells, potential bugs, and deviations from coding standards, and, crucially, provide actionable suggestions for improvement”), (Rasheed, see page 3 paragraph 5, “LLM-based AI agent system aimed at identifying potential issues in code and providing actionable recommendations”), (Rasheed, see page 4 paragraph 3, “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code”).
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 system for improving software compliance as taught by MacIver, to include receiving an alternative solution responsive to an indication of non-compliance as taught by Rasheed, for the result of resolving the identified non-compliant code.
MacIver as modified does not appear to distinctly disclose:
However, Medford discloses:
responsive to the second indication, input the indication to at least a second ML model (Medford, see paragraph [0070], “Following the execution and initial evaluation by the Executor Agent 210, the results, including any execution logs, error reports, and performance data, are passed back to the Engineer Agent 208 via the Chat Manager Agent 212. This iterative feedback loop is crucial for refining and optimizing the code. The Engineer Agent 208 reviews the feedback to identify any necessary changes or improvements, and then adjusts the code accordingly.”), (Medford, see Abstract, “The disclosure presents a multi-agent AI system utilizing specialized Large Language Models (LLMs) to automate and enhance software development workflows.”).
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 system for improving software compliance as taught by MacIver, to include inputting an indication of non-compliance into a second ML model as taught by Medford, for the result of having specialized ML models that each perform a specific task in the identification and correction of non-compliant code.
Regarding claim 9, MacIver discloses:
automatically implement the alternative solution in the code (MacIver, see col. 5 lines 56-67-col. 6 lines 1-4, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree... In step 235, the analysis and recommendation service may deploy the compliant code”), (MacIver, see col. 6 lines 58-61 “code that is recommended may either be automatically integrated into the software repository”).
Regarding claim 10, MacIver discloses:
provide the alternative solution to the coder computer for implementation by the coder computer in the code (MacIver, see col. 5 lines 56-67 col. 6 lines 1-4 “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree... In step 235, the analysis and recommendation service may deploy the compliant code”).
Regarding claim 11, MacIver does not appear to distinctly disclose:
receive the first or second indication from the first ML model at a third ML model; and
based on output from the third ML model, commit the code to the code repository or input the second indication to the second ML model.
However, Rasheed discloses:
receive the first or second indication from the first ML model (Rasheed, see page 2 paragraph 2, “our paper introduces a novel LLM-based AI agent system specifically tailored for the software development context. The proposed multi-agent system consists of four agents that identify code smells, potential bugs, and deviations from coding standards, and, crucially, provide actionable suggestions for improvement”), (see page 3 paragraph 5, “LLM-based AI agent system aimed at identifying potential issues in code and providing actionable recommendations”), (page 4 paragraph 3. “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code”);
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 system for improving software compliance as taught by MacIver, to include receiving an indication from an ML model as taught by Rasheed, for the result of capturing the ML model’s compliance determination to use downstream.
MacIver as modified does not appear to distinctly disclose:
based on output from the third ML model, commit the code to the code repository or input the second indication to the second ML model.
However, Medford discloses:
receive the first or second indication from the first ML model (“Executor Agent 210”) at a third ML model (“Chat Manager Agent 212”) (Medford, see paragraph [0069], “Once the code is executed, the Executor Agent 210 collects data on its performance, including execution logs, error reports, and output results. This data provides tangible feedback on the code's real-world operability. The Chat Manager Agent 212 then processes this output to determine the success of the execution. It analyzes the data to identify any errors or issues that occurred during the execution and assesses whether the code has met all operational benchmarks successfully.”); and
based on output from the third ML model, commit the code to the code repository (Medford, see paragraph [0071], “This iterative development process, facilitated by the Chat Manager Agent 212, ensures that the software code evolves into a robust and efficient final product, ready for deployment. Once the code successfully passes all tests and validations without any errors, it is deemed ready for a final commit to a code repository, such as Git. This final step formally integrates the tested and approved code into the project's main codebase, making it available for deployment or further integration with other system components. The detailed workflow of this process, including the interactions between the Engineer Agent 208, Executor Agent 210, and the Chat Manager Agent 212 leading to the final code commit, is illustrated in FIG. 3”).
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 system for improving software compliance as taught by MacIver, to include receiving an indication from a first ML model at a third ML model and committing code to a repository based on the output of the third ML model as taught by Medford, for the result of only allowing code that complies with all rules to be committed to a repository.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, and Medford as applied to claim 8, and further in view of Kumar (US20260037234).
Regarding claim 12, MacIver as modified does not appear to distinctly disclose:
wherein the plural code rules comprise one or more of proper indentation to ensure readability, naming convention for variables, functions and code file names, standardization of module headers, maximum number of characters in each line of code.
However, Kumar discloses:
wherein the plural code rules comprise one or more of (Kumar, see paragraph [0018], “software code is software code that adheres to a set of additional rules, restrictions, and/or conventions... The additional rules, restrictions, and/or conventions are in addition to the set of rules that characterize the programming language and that every set of software code written in the programming language are required to comply with. Examples of additional rules that characterize proprietary software code include naming conventions for naming data objects, variables”).
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 system for improving software compliance as taught by MacIver, to include naming convention for variables as taught by Kumar, for the result of enforcing consistent style, readability, and maintainability across the codebase.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, and Medford as applied to claim 8 above, and further in view of Somsikov et al. (US20180349575).
Regarding claim 13, MacIver as modified does not appear to distinctly disclose:
wherein the plural code rules comprise one or more of use of a specific code library forbidden by at least one license, specific use of code forbidden by at least one license.
However, Somsikov discloses:
wherein the plural code rules comprise one or more of use of a specific code library forbidden by at least one license, specific use of code forbidden by at least one license (Somsikov see paragraph [0012], “authorization verification tools make use of managed code libraries that provide functionality for applications to check a user's authorization (e.g., a license status) with a trusted authorization server (e.g., a trusted licensing server)”), (Somsikov, see paragraph [0013], “to check a licensing status, an application calls functions provided by an authorization verification library to check the licensing status of the computing device on which the user is trying to run the application. The trusted authentication servers retrieve licensing details of the application for the particular device on which the application is running. The application then determines whether the licensing details satisfy the licensing constraints.”), (Somsikov, see paragraph [0014], “licensing constraints the trusted authorization server may return licensing details (e.g., whether the device or user is authorized, what level they are authorized to, and the like) to the application on the device. The application then uses the licensing details to determine whether the use of the application is to be allowed”).
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 system for improving software compliance as taught by MacIver, to include rules comprising use of a specific code library forbidden by a license or specific use of code forbidden by a license as taught by Somsikov, for the result of screening the code for license-based restriction on library and code use prior to commitment.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over MacIver, Rasheed, Medford, and Somsikov as applied to claim 13 above, and further in view of Fisher et al. (US20250307465, Fisher hereinafter).
Regarding claim 14, MacIver does not appear to distinctly disclose:
wherein information identifying licenses is deleted from information provided to the first ML model.
However, Somsikov discloses:
(Somsikov, see paragraph [0014], “licensing constraints the trusted authorization server may return licensing details (e.g., whether the device or user is authorized, what level they are authorized to, and the like) to the application on the device. The application then uses the licensing details to determine whether the use of the application is to be allowed”).
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 system for improving software compliance as taught by MacIver, to include information identifying licenses as taught by Somsikov, for the result of allowing the identification of applicable licenses.
MacIver as modified does not appear to distinctly disclose:
wherein
However, Fisher discloses:
wherein information identifying (Fisher, see paragraph [0007], “a method of large language model (LLM)-agnostic data anonymization comprises authenticating a user to a system for data anonymization for a LLM; intercepting a request from the user to upload a document into an LLM service; parsing the document to extract document content; detecting confidential information (CI) within the document content; obfuscating the detected CI; redacting the document by replacing the CI with the obfuscated CI; uploading the redacted document to the LLM service”), (Fisher, see paragraph [0019], “data anonymization can include data obfuscation (and data deobfuscation) to protect confidential information a user is going to send to an LLM service”), (Fisher, see paragraph [0020], “the terms “personal data,” “personal information,” “personally identifiable information (PII),” “sensitive data,” “confidential information (CI)” and similar language do not reference any particular definition”).
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 system for improving software compliance as taught by MacIver, to include deleting from information provided to an ML model as taught by Fisher, for the result of evaluating code with without considering license-identifying information.
Claims 15, 16, 17, 18, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over MacIver et al. (US12393401, MacIver hereinafter) in view of Rasheed et al. (AI-powered Code Review with LLMs: Early Results, 2024, Rasheed hereinafter) and Cabrera Lozoya et al. (US20230418599, Cabrera hereinafter).
Regarding claim 15, MacIver discloses: A method comprising:
subsequent to training, input test code to the ML assembly (MacIver, see col. 5 lines 33-41, “the analysis and recommendation service may extract features from the code and may represent the code as features (e.g., code embeddings from a deep learning model, abstract syntax trees, etc.). It may then apply a label generator (e.g., a pseudo-label generator such as Snorkel) to the features to indicate compliance or non-compliance. The machine learning engine may be trained on these features and labels and used to predict whether code is complaint or not compliant.”); and
responsive to the ML assembly indicating that the test code does not violate any of the one or more rules, committing the test code to a code repository (MacIver, see col. 1 lines 38-51, “(5) deploying, by analysis and recommendation service computer program, the code in response to the code being in compliance”), (MacIver, see col. 6 lines 5-6, “code that is recommended may either be automatically integrated into the software repository”);
MacIver does not appear to distinctly disclose:
training a machine learning (ML) assembly on ground truth code to recognize violations of one or more rules by the ground truth code; and
responsive to the ML assembly indicating that the code violates any of the one or more rules, not committing the test code to a code repository.
However, Rasheed discloses:
training a machine learning (ML) assembly on ground truth code (“established coding standards”) to recognize violations of one or more rules by the ground truth code (Rasheed, see page 4 paragraph 3, “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code and then forwards its findings to subsequent agents for deeper analysis within the multi-agent workflow.”);
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 system for improving software compliance as taught by MacIver, to include training an ML assembly on ground truth code to recognize violations as taught by Rasheed, for the result of increasing the efficiency of recognizing and correcting code violations.
MacIver as modified does not appear to distinctly disclose:
responsive to the ML assembly indicating that the code violates any of the one or more rules, not committing the test code to a code repository.
However, Cabrera discloses:
responsive to the ML assembly indicating that the code violates any of the one or more rules, not committing the test code to a code repository (Cabrera, see paragraph [0048], “the computing system can flag the commit 504 in a list of received commits for a project owner to review or the computing system can send a notification to one or more computing devices or other computing systems that the commit 504 should be reviewed for malicious activity. In this way, a commit that potentially introduces malicious code is not integrated into the project repository 524.”).
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 system for improving software compliance as taught by MacIver, to include committing or not committing code based on whether or not the code has violated any rules as taught by Cabrera, for the result of only allowing code that complies with all rules to be committed to a repository.
Regarding claim 16, MacIver discloses:
responsive to the ML assembly indicating that the test code violates any of the one or more rules, generating using the ML assembly one or more suggested corrections to the test code (MacIver, see col. 1 lines 52-63, “ determining, by the analysis and recommendation service computer program, that the code is not in compliance; identifying, by the analysis and recommendation service computer program, a recommendation for the code to comply to with the rules or control patterns; enriching, by the analysis and recommendation service computer program, the code by incorporating the recommendation into the code; and deploying, by the analysis and recommendation service computer program, the code.”), (MacIver, see col. 5 line 63-col. 6 line 2, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree, etc.”).
Regarding claim 17, MacIver discloses:
automatically changing the test code using the suggested corrections (MacIver, see col. 5 line 63-col. 6 line 2, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree, etc.”), (MacIver see col. 6 lines 58-61, “code that is recommended may either be automatically integrated into the software repository”).
Regarding claim 18, MacIver discloses:
wherein the ML assembly comprises a single large language model (LLM) (MacIver, see col. 5 line 63-col. 6 line 2, “the analysis and recommendation service may automatically apply any code fixes to non-compliant code. The code changes may be automatically incorporated into the code, by, for example, using a large language model (LLM) to change the code, by using a set of deterministic rules based on re-writing the code's AST tree, etc.”).
Regarding claim 19, MacIver does not appear to distinctly disclose:
wherein the ML assembly comprises plural LLMs.
However, Rasheed discloses:
wherein the ML assembly comprises plural LLMs (Rasheed, see page 4 paragraph 2, “The methodology for our proposed LLM-based AI agent system, designed to assist in code reviews, revolves around four specialized agents: the Code Review Agent, Bug Report Agent, Code Smell Agent, and Code Optimization Agent. Each agent is tasked with a distinct aspect of the code review process, utilizing LLM technology to analyze code repositories, identify issues, and suggest improvements.”).
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 system for improving software compliance as taught by MacIver, to include multiple LLMs as taught by Rasheed, for the result of utilizing specialized LLMs by distributing the rule-violation analysis and correction.
Regarding claim 20, MacIver does not appear to distinctly disclose:
wherein a first one of the LLMs (“Code Review Agent”) outputs indications of whether the test code violates one or more rules and a second one of the LLMs (“Code Smell Agent”) outputs the suggested corrections (Rasheed, see page 4 paragraph 3, “The primary function of the Code Review Agent is to analyze source code and identify potential issues, including bugs, code smells, and deviations from established coding standards. This agent performs the initial assessment of the submitted code and then forwards its findings to subsequent agents for deeper analysis within the multi-agent workflow.”), (Rasheed, see page 4 paragraph 5-page 5 paragraph 1, “After receiving prior assessments from earlier agents in the workflow, the Code Smell Agent performs a more design-oriented evaluation of the code. Using prompt-based instructions and the GPT-4 model, it proposes refactoring strategies aimed at improving long-term code quality and reducing technical debt.”).
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 system for improving software compliance as taught by MacIver, to include an LLM outputting an indication of a rule violation and an LLM outputting suggested corrections as taught by Rasheed, for the result of utilizing specialized LLMs by distributing the rule-violation analysis and correction.
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