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 6/23/2026. This action is 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Golender et al. (US 7,386,839 B1) and further in view of Acharya et al. (US 2025/0045148 A1).
As per claim 1, Avresky teaches the invention as claimed including, “A method, comprising:
accessing a behavioral model of a codebase, wherein:
the behavioral model is generated based on executing the codebase and analyzing the executing, and
the behavior model includes operation details and events observed during the executing
interrogating the behavioral model, including the operational details and the events, to predict run-time complications within the codebase, the interrogating comprising comparing the behavior model to static and dynamic problem patterns;”
Golender et al. teaches analysis of an execution trace that allows the create of a data structure (behavior model) referred to herein as an application signature that includes traced data that corresponds to system resources configured to interact with an application during execution. The application signature includes system objects and/or data…(column 3, lines 54-67). Comparison of application signatures for two or more similar executions of an application on “problematic” and “good” computers or systems allows identification of differences in the computers, systems and/or application configuration that causes an application failure. In another embodiment, an application signature derived from a problematic computer or system is compared with a static configuration of a references computer having a known good configuration (column 4, lines 1-10). The application signature is configured to store information about system objects accessed or used by the application during execution (column 4, lines 18-23). An application signature can be analyzed to determine the cause of an application failure. The application signature analysis function is configured to detect known errors in the problem application signature corresponding to a known erroneous application, system or computer configuration. The problem application signature is compared with a reference application signature corresponding to a normal or acceptable execution of the application. The application signature analysis function is configured to compare the problem application signature with a static configuration. A Comparison can reveal numerous configuration differences which include whether the object is dynamic (column 5, lines 46 – column 6, lines 1-21). Signature can be viewed as a tree (column 8, lines 43-62). Tracing involves tracing the execution of the instrumented client process and reporting certain events (column 15, lines 43-45).
However, Golender et al. does not explicitly appear to teach, “receiving, [[in]] via a user interface, user input comprising a selection of a run-time complication of the run-time complications;
generating a prompt to elicit a reply from a foundation model, wherein the prompt tasks the foundation model with generating a solution for the selected run-time complication and wherein the prompt includes a portion of the codebase corresponding to the selected run-time complication; [[and]]
causing display of the solution for the selected run-time complication in the user interface; and modifying the codebase with at least a portion of the solution based on an indication received via the user interface.”
Acharya et al. teaches a user requests a generative AI system to provide to the user, in natural language, an explanation of a proposed solution to repair the detected issue in the software service or application. The AI system provides an explanation of a corrective modification that could be applied to the failing portion of software code to resolve the detected issue. A prompt, the error context, the lines of software, and/or previous dialogue requests and response are provided as input to the language model. The language model processes the received input and outputs an explanation of a proposed solution to repair the detected issues in the software service or application (0021). The AI system may also provide a proposed solution based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E. A pull request associated with a proposed solution to repair a portion of the software code can be provided by the generative AI system (0070). Also see 0025.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Golender et al. with Acharya et al. because both teach the detecting errors/issues with the execution of a program. Golender et al. teaches, an application signature can be analyzed to determine the cause of an application failure (column 5, lines 46 – column 6, lines 1-21). Acharya et al. teaches displaying a fault and allow a user to select/request an AI system to determine a fix for the fault. This would allow Golender et al. to rely on a AI system using previous fixes to determine a fix instead of the user. This will help reduce application and platform stability issues (0025) and would have been obvious to try.
As per claim 2, Acharya et al. further teaches, “The method of claim 1, wherein generating the prompt further comprises identifying the portion of the codebase corresponding to the selected run-time complication based on the behavioral model.”
Acharya et al. teaches the AI system creates an error context for the failing portion of software code and identifies or extracts lines of software code corresponding to and/or surrounding the failing portion of software code (0021-0022). Also see figures 3A, 3D, and 3E.
As per claim 3 , Acharya et al. further teach, “The The method of claim 1, wherein the prompt includes information from the behavioral model about the selected run-time complication, wherein the information includes a type of the selected run-time complication.
Acharya et al. teaches a user request for the generative AI system to provide to the user, in natural language, an explanation of a proposed solution to repair the detected issue in the software service or application. The AI system provides an explanation of a corrective modification that could be applied to the failing portion of software code to resolve the detected issue. A prompt, the error context, the lines of software, and/or previous dialogue requests and response are provided as input to the language model. The language model processes the received input and output an explanation of a proposed solution to repair the detected issues in the software service or application (0021). The AI system may also provide a proposed solution based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E.
As per claim 4, Acharya et al. further teaches, “The method of claim 1, wherein the prompt further tasks the foundation model with generating an explanation of the selected run-time complication and the solution, and wherein the method further comprises causing display of the explanation in the user interface in association with the solution.”
Acharya et al. teaches a user request for the generative AI system to provide to the user, in natural language, an explanation of a proposed solution to repair the detected issue in the software service or application. The AI system provides an explanation of a corrective modification that could be applied to the failing portion of software code to resolve the detected issue. A prompt, the error context, the lines of software, and/or previous dialogue requests and response are provided as input to the language model. The language model processes the received input and output an explanation of a proposed solution to repair the detected issues in the software service or application (0021). The AI system may also provide a proposed solution based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E.
As per claim 5, Acharya et al. further teaches, “The method of claim 1, wherein the solution comprises a code snippet generated by the foundation model in response to the prompt.”
The AI system provides a proposed solution (a software code fix) based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E.
As per claim 6, Acharya et al. further teaches, “The method of claim 5, wherein the method further comprises patching the codebase with the code snippet.”
The AI system can generate a pull request (e.g., a merge request) associated with a proposed solution for the detected issue in the software service or application. This will merge a first version with a second version. A pull request will indicate an intent to merge software code from a feature branch of a codebase to a repository comprising the main branch of the main codebase (0023-0025).
As per claim 7, Golender et al. and Acharya et al. further teaches, “The method of claim 1, wherein the user input comprises a selection of a portion of a visual representation of the codebase, wherein the visual representation is generated based on the behavioral model.”
Golender et al. teaches, GUI windows provide indication of the objects stored in the application signature. A signature can be viewed as a tree (column 8, lines 43-62). Tracing involved tracing the execution of the instrumented client process and reporting certain events (column 15, lines 43-45). Results of the comparison are presented in one or more GUI windows configured to show object differences (column 9, lines 40-55).
Acharya et al. teaches a user requests for the generative AI system to provide to the user, in natural language, an explanation of a proposed solution to repair the detected issue in the software service or application. The AI system provides an explanation of a corrective modification that could be applied to the failing portion of software code to resolve the detected issue. A prompt, the error context, the lines of software, and/or previous dialogue requests and response are provided as input to the language model. The language model processes the received input and outputs an explanation of a proposed solution to repair the detected issues in the software service or application (0021). The AI system may also provide a proposed solution based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E. As can be seen in figure 3A the error is shown and a user can select code fix 311 to generate code to fix the error.
As per claim 8, Golender et al. and Acharya et al. further teach, “The method of claim 7, wherein the visual representation comprises a sequence diagram of the codebase generated based on information from the behavioral model.
Golender et al. teaches, GUI windows provide indication of the objects stored in the application signature. A signature can be viewed as a tree (sequence diagram) (column 8, lines 43-62). Tracing involved tracing the execution of the instrumented client process and reporting certain events (column 15, lines 43-45). Results of the comparison are presented in one or more GUI windows configured to show object differences (column 9, lines 40-55).
Acharya et al. teaches a user request for the generative AI system to provide to the user, in natural language, an explanation of a proposed solution to repair the detected issue in the software service or application. The AI system provides an explanation of a corrective modification that could be applied to the failing portion of software code to resolve the detected issue. A prompt, the error context, the lines of software, and/or previous dialogue requests and response are provided as input to the language model. The language model processes the received input and output an explanation of a proposed solution to repair the detected issues in the software service or application (0021). The AI system may also provide a proposed solution based on the input. The proposed solution is provided to the user (0022). Also see figures 3A, 3D and 3E. As can be seen in figure 3A the sequence of code that led to the error (call stack) is shown and a user can select code fix 311 to generate code to fix the error.
As per claim 9-20, claims 9-20 contain similar limitations to claim 1-8 and are therefore rejected for similar reasons.
Response to Arguments
Applicant's arguments filed 6/23/2026 have been fully considered but they are moot due to amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
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
Prosecution Insights