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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites, “interrogating the behavior model to predict run-time complications…”, “a selection of a run-time complication” and “generating a prompt to elicit a reply from a foundation model…”. The limitations of “interrogating… to predict”, “selection” and “generating” as drafted are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional elements “accessing behavioral model”, and “causing display of solution”. The additional element of “accessing” is an insignificant pre solution activities. The additional element of “causing display of solution”, is recited at a high level of generality and thus is an insignificant extra-solution activity. See MPEP 2106.05(g). Further, the limitation “a user interface” is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, MPEP 2106.05(f). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “causing display of the solution” is identified as well-understood, routine, conventional activity (2106.05(d)) and for the limitation of “accessing a behavior model” the courts have identified mere data gathering is also well-understood, routine and conventional activity. Se MPEP 2106.05(d) and MPEP 2106.05(f). As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “a user interface” amounts to no more than mere instructions, or generic computer/computer components to carry out the exception. The recitation of generic computer instruction and computer components to apply the judicial exception, and the well-understood, routine, conventional activities do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, claim 1 is not patent eligible under 35 USC 101.
As per claim 2, claims additional limitations of “generating a prompt…”. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
As per claim 3, claims additional limitations of “the prompt…”. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
As per claim 4, claims additional limitations of “the prompt…”. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B. The claim further claims, “causing display of the explanation…”, this is recited at a high level of generality and thus is an insignificant extra-solution activity. See MPEP 2106.05(g). Displaying is identified as a well-understood, routine, conventional activity (2106.05(d)).
Claim 5, The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 6, claims “patching the codebase with the code snippet”. The additional element of “patching” is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitations prevent this limitation from being performed in the mind.
Claim 7, further defines the mental process “selection” step. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 8, The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
As per claim 9-20, claims 9-20 contain similar limitations to claim 1-8 and are therefore rejected for similar reasons.
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 Avresky (US 2007/0277163 A1) 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 represents a run-time behavior of the codebase generated based on a run-time analysis of the codebase;
interrogating the behavioral model to predict run-time complications within the codebase;”
Avresky teaches the generation of a behavior model and the generation of well-define formula sequences from the behavior model. The well-defined formula sequences are then verified and faults are reported (0034). The source code is verified based on the set of well-defined formula sequences (0039). Also see 0042. Well-defined formula sequences generation module may the generate well-defined formula sequences, which are sections in the behavior model. A well-defined formula sequence is a sequence of behavior model sections (0045). Also see 0049 and 0053. Avresky further teaches the generation of a report documenting the type of fault and the portion of source code that is the origin of the fault. This report may be presented to the user on the user interface to provide diagnostic information during the verification process. The user may then switch to a code editor, correct the problem with the help of a diagnostic information (0058).
However, Avresky does not explicitly appear to teach, “receiving, in 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.”
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.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Avresky with Acharya et al. because both teach the determination of a fault/error. Avresky teaches displays the fault to a user in a report to allow the user to fix it while Acharya et al. teaches that the displaying the fault and allow a user to select/request an AI system to determine a fix for the fault. This would allow Avresky to rely on a AI system using previous fixes to determine a fix instead of the user and would have been obvious to try.
As per claim 2, Avresky and 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.”
Avresky teaches a report is generated documenting the type of fault and the portion of source code that is the origin of the fault (0058).
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).
As per claim 3 , Avresky and 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.
Avresky teaches the generation of a behavior model and the generation of well-define formula sequences form the behavior model. The well-defined formula sequences are then verified and faults are reported (0034). The source code is verified based on the set of well-defined formula sequences (0039). Also see 0042. Well-defined formula sequences generation module may the generate well-defined formula sequences, which are sections in the behavior model. A well-defined formula sequence is a sequence of behavior model sections (0045). Also see 0049 and 0053. A report is generated documenting the type of fault and the portion of source code that is the origin of the fault (0058). Also see 0043,0045 and 0047.
Acharya et al. teaches a user request is 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 is 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 , Avresky and Acharya et al. further teach, “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.
Avresky teaches the generation of a behavior model that is a logic representation or a second intermediate representation of the source code. A behavior model is a logic representation of source code and can be understood and analyzed by non-programmers. A logic representation of source code is a transformed version of the source code from the code domain logic domain, which can be displayed textually or visually (0043). Well-defined formula sequences generation module may generate well-defined formulas sequences, which are sections in the behavior model, as a depth first search tree (0045). All possible sequences of the WDFs are automatically generated from the behavior model and form a Depth-First Search Tree (DFST) define by the logic (0047). Avresky teaches the generation of a behavior model and the generation of well-define formula sequences form the behavior model. The well-defined formula sequences are then verified and faults are reported (0034). Also see 0055. Avresky also teaches the generation of a report documenting the type of fault and the portion of source code that is the origin of the fault. This report may be presented to the user on the user interface to provide diagnostic information during the verification process. The user may then switch to a code editor, correct the problem with the help of a diagnostic information (0058). The examiner states that the repot is generated and displayed based on the generated behavior model.
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 error is shown and a user can select code fix 311 to generate code to fix the error.
It would have been obvious to one or ordinary skill in the art before the effective filing date for the report of Avresky to be similar to the report in figure 3A of Acharya et al. They both allow the user to see the error and Acharya et al. allows the use to request AI to generation a fix for the error and would have been obvious to try. The examiner state that the since the report of Avresky is created and displayed based on the generated behavior model and generated sequence diagram then it would have been obvious for the report in Acharya et al. to be generated in a similar fashion. Therefore, the visual representation is based on the generated behavior model and generated sequence diagram.
As per claim 8, Avresky 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.
Avresky teaches the generation of a behavior model that is a logic representation or a second intermediate representation of the source code. A behavior model is a logic representation of source code and can be understood and analyzed by non-programmers. A logic representation of source code is a transformed version of the source code from the code domain logic domain, which can be displayed textually or visually (0043). Well-defined formula sequences generation module may generate well-defined formulas sequences, which are sections in the behavior model, as a depth first search tree (0045). All possible sequences of the WDFs are automatically generated from the behavior model and form a Depth-First Search Tree (DFST) define by the logic (0047). Avresky teaches the generation of a behavior model and the generation of well-define formula sequences form the behavior model. The well-defined formula sequences are then verified and faults are reported (0034). Also see 0055. Avresky teaches the generation of a report documenting the type of fault and the portion of source code that is the origin of the fault. This report may be presented to the user on the user interface to provide diagnostic information during the verification process. The user may then switch to a code editor, correct the problem with the help of a diagnostic information (0058). The examiner states that the repot is generated and displayed based on the generated behavior model.
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.
It would have been obvious to one or ordinary skill in the art before the effective filing date for the report of Avresky to be similar to the report in figure 3A of Acharya et al. They both allow the user to see the error and Acharya et al. allows the use to request AI to generation a fix for the error and would have been obvious to try. The examiner state that the since the report of Avresky is created and displayed based on the generated behavior model and generated sequence diagram then it would have been obvious for the report in Acharya et al. to be generated in a similar fashion. Therefore, the visual representation is based on the generated behavior model and generated sequence diagram.
As per claim 9-20, claims 9-20 contain similar limitations to claim 1-8 and are therefore rejected for similar reasons.
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
Prosecution Insights