DETAILED ACTION
This is the initial Office action based on the application filed on July 12, 2024.
Claims 1-20 are pending.
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 .
Drawings
The drawings are objected to because the bottom of Figure 5 recites “To Step 414” instead of “To Step 416.” Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0037], line 4, recites “GetHub.” It should read – GitHub --.
Paragraph [0050], line 3, recites “for a for an issue.” It should read -- for an issue --.
Paragraph [0059], lines 4-5, recites “a patch for fix.” It should read -- a patch for fixing--.
Paragraph [0064], line 7, recites “the fix window 606.” It should read -- the fix window 605 --.
Paragraph [0067], lines 10-11, recites “This makes the user interface 600 is much.” It should read -- This makes the user interface 600 much--.
Appropriate correction is required.
Claim Objections
Claims 1, 3-8, 10-11, and 13-18 are objected to because of the following informalities:
Claims 1, 11, and 20, in line 13, line 11, and line 11 respectively, recite “providing set of one or more sentence encodings.” It should read -- providing the set of one or more sentence encodings --.
Claims 1, 11, and 20, in line 14, line 12, and line 12 respectively, recite “the AI algorithm.” It should read -- the trained AI algorithm --.
Claims 1, 11, and 20, in lines 16-17, line 15, and lines 14-15 respectively, recite “are the likely cause of the new identified issue.” It should read -- are likely the cause of the new identified issue --.
Claims 3 and 13, in line 4 and line 4 respectively, recite “the AI algorithm.” It should read -- the trained AI algorithm --.
Claim 4, in line 2 and line 4, recites the limitation “likely a cause of the new identified issue.” It should read -- likely the cause of the new identified issue--.
Claims 5 and 15, in line 5 and line 5 respectively, recite “the fix to the identified issue.” It should read -- the fix to the new identified issue --.
Claims 5 and 15, in line 4 and line 4 respectively, recite the “likely a cause of the new identified issue.” It should read -- likely the cause of the new identified issue --.
Claims 5 and 15, in line 7 and line 7 respectively, recite “are the cause of the new identified issue.” It should read – are likely the cause of the new identified issue --.
Claim 5 and 15, in line 8 and line 8 respectively, recite “the identified one or more files.” It should read – the one or more files --.
Claims 6 and 16, in line 2 and line 2 respectively, recite “the likely cause of the new identified issue.” It should read -- likely the cause of the new identified issue --.
Claims 7 and 17, in lines 2-3 and lines 2-3 respectively, recite “the likely cause of the new identified issue.” It should read -- likely the cause of the new identified issue --.
Claims 8 and 18, in lines 2-3 and lines 2-3 respectively, recite “tickets for issues.” It should read -- tickets for the issues --.
Claims 8 and 18, in line 3 and line 3 respectively, recite “pull requirements for the issues.” The specification does not mention “pull requirements,” but does mention “pull requests” and based on paragraph [0044] of the specification, the limitation should read -- pull requests for the issues --.
Claim 10, in lines 4-5, recites “to identify likely fixes to source code in the identify the one or more files.” It should read -- to identify likely fixes to source code in the one or more files --.
Claim 14, in line 2 and line 4, recites the limitation “likely a cause of the new identified issue.” It should read -- likely the cause of the new identified issue--.
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.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
The term “likely” in Claims 1, 4-7, 10-11, 14-17, and 20 is a relative term which renders the claim indefinite. The term “likely” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. As a result, likely a cause of the new identified issue, likely to identify the cause of the new identified issue, likely fixes to source code are rendered indefinite.
Claims 2-10 depend on Claim 1. Therefore, Claims 2-10 suffer the same deficiency as Claim 1.
Claims 12-19 depend on Claim 11. Therefore, Claims 12-19 suffer the same deficiency as Claim 11.
Claim 10, in line 6, recites the limitation “the best developers.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as – best developers – in Claim 10.
The term “best” in Claim 10 is a relative term which renders the claim indefinite. The term “best” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. As a result, “to identify the best developers to fix the issue” is rendered indefinite.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 9, 11-12, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0321856 (hereinafter “Chandramohan”) in view of “Sentence embedding and fine-tuning to automatically identify duplicate bugs” (hereinafter “Isotani”).
As per Claim 1, Chandramohan discloses:
A system (Figure 12A) comprising:
a microprocessor (paragraph [0005], “A system implements pre-trained large language model driven bug localization. The system includes at least one processor and an application that executes on the at least one processor.”); and
a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions (paragraph [0006], “A non-transitory computer readable medium includes instructions executable by at least one processor to implement pre-trained large language model driven bug localization.”) that, when executed by the microprocessor, cause the microprocessor to:
train an Artificial Intelligence (AI) algorithm using a training set, wherein the training set is a set of training [data] of issues associated with different components of source code (paragraph [0028], “The training files (117) are the files used to train the machine learning models. In an embodiment, the training files (117) may include copies of the source files (107) (emphasis added).”; paragraph [0020], “The source files (107) may include reports, source code files, commits, etc., for a programming project.”; paragraph [0021], “A report may be a recorded description of a bug of a system. A report may include text that provides a description of a bug, a set of steps for reproduction of the bug, environment information, severity level, etc., that may be used to diagnose, analyze, and resolve the bug (emphasis added).”; paragraph [0013], “One or more embodiments automatically identify the source files where a bug is originated to reduce the needed time and computer resources spent maintaining the source files in a code repository (emphasis added).”);
receive a new identified issue associated with a base of source code (abstract, “The method includes receiving a report and applying a fine-tuned language model to report text from the report, to source text from a source file of a set of source files, and to commit text from a commit of a set of commits to respectively generate a report vector, a source vector, and a commit vector from the fine-tuned language model (emphasis added).”; paragraph [0015], “When using an embodiment of the disclosure, a user may select a set of source files and a report in a request for the system to analyze and locate source files and code segments that may be relevant to the bug identified in the report (emphasis added).”);
provide the set of one or more [output vectors] to the trained AI algorithm (paragraph [0035], “The ranking model (155) is a machine learning model that is trained to generate the rankings (113) from the source files (107) (emphasis added).”; paragraph [0037], “For example, the fine-tuned language model (159) may receive embedding vectors generated by the input processing model (157) that are processed to generate output vectors stored in the vectors (109). The outputs of the fine-tuned language model (159) may be processed by the ranking model (155) to generate vectors, scores, and rankings stored in the vectors (109), the scores (111), and the rankings (113) in the repository (103) (emphasis added).”);
in response to providing set of one or more [output vectors] to the trained AI algorithm, receive an output from the AI algorithm that identifies one or more files that are likely a cause of the new identified issue (paragraph [0035], “The ranking model (155) is a machine learning model that is trained to generate the rankings (113) from the source files (107) (emphasis added).”; paragraph [0037], “For example, the fine-tuned language model (159) may receive embedding vectors generated by the input processing model (157) that are processed to generate output vectors stored in the vectors (109). The outputs of the fine-tuned language model (159) may be processed by the ranking model (155) to generate vectors, scores, and rankings stored in the vectors (109), the scores (111), and the rankings (113) in the repository (103) (emphasis added).”; paragraph [0063], “The file ranking model (280) is a program that may operate as part of the ranking model (202) […] In an embodiment, the file ranking model (280) may use a majority voting algorithm to determine the ranks for the source code files in a project. The source code files with higher ranks may have a higher likelihood of being relevant to the bug identified in the report (208) (emphasis added).”; paragraph [0086], “Step 412 includes applying a ranking model to the report source score and the report commit score to identify the source file corresponding to the report. In an embodiment, the source file may be identified with a file rank generated by the ranking model (emphasis added).”); and
generate for display, in a user interface, the one or more files that are the likely cause of the new identified issue (paragraph [0044], “In an embodiment, the user device A (180) is operated by a user to analyze the source files (107) and display predictions of which ones of the source files (107) may be revised to resolve a bug described in a report. In an embodiment, the rankings (113) may be displayed by the user device A (180) to show an ordered ranking of one or more files or segments of files from the source files (107) (emphasis added).”; paragraph [0087], “Step 415 includes presenting the source file responsive to the report. The source file may be presented by transmitting a response to a user device pursuant to a request from the user device to analyze the source files of a programming project with respect to a report of a bug. The response may be transmitted as part of a message that may include an identification of a source file that may be related to the bug from the report, and the response may include text extracted from the source file. The identification of the source file, the text from the source file, and the source file itself may be displayed on the user device (emphasis added).”) [Examiner’s Remarks: Note that Chandramohan discloses displaying ranked files and presenting a source file responsive to the bug report (likely cause of the new identified issue) by transmitting a message to the user device that includes text extracted from the source file. One of ordinary skill in the art would readily comprehend that corresponding data (such as text extracted from the source file) must be generated before being displayed in the user interface.].
Chandramohan discloses “the new identified issue,” but does not explicitly disclose:
sentence encodings;
convert text associated with the new identified issue into a set of one or more sentence encodings.
However, Isotani discloses:
sentence encodings (page 1 Section 1 Introduction, “In our system, sentence embedding (distributed representations of semantics) generates vectors from the description content for each element in a bug report.”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”);
convert text associated with the new identified issue into a set of one or more sentence encodings (page 3 Section 2.2 Sentence-BERT, “SBERT extends BERT to include sentence embedding (Reimers and Gurevych, 2019). It embodies the content features by converting sentences into vectors (emphasis added).”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”).
Chandramohan is within the same field of endeavor as the claimed invention regarding the identification of files related to code issues/bugs. Isotani is also within the same field of endeavor as the claimed invention regarding the use of sentence encodings.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the teaching of Chandramohan to include “sentence encodings; convert text associated with the new identified issue into a set of one or more sentence encodings.” The modification would be obvious because one of ordinary skill in the art would be motivated to include sentence encodings/embeddings in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports and help an AI algorithm effectively extrapolate meaning from reports. Moreover, by using sentence encodings/embeddings to effectively determine semantic similarity in bug duplication detection, burden on maintenance engineers can be reduced by potentially reducing how often a bug needs to be identified/fixed in code (Isotani, pages 4 & 11).
As per Claim 2, the rejection of Claim 1 is incorporated; and Chandramohan does not explicitly disclose:
wherein the set of one or more sentence encodings are one of: vectors of sentences, matched patterns, string comparisons, and an Euclidean distance.
However, Isotani discloses:
wherein the set of one or more sentence encodings are one of: vectors of sentences, matched patterns, string comparisons, and an Euclidean distance (page 3 Section 2.2 Sentence-BERT, “SBERT extends BERT to include sentence embedding (Reimers and Gurevych, 2019). It embodies the content features by converting sentences into vectors (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the teaching of Chandramohan to include “wherein the set of one or more sentence encodings are one of: vectors of sentences, matched patterns, string comparisons, and an Euclidean distance.” The modification would be obvious because one of ordinary skill in the art would be motivated to include sentence encodings/embeddings in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports and help an AI algorithm effectively extrapolate meaning from reports (Isotani, pages 4 & 11).
As per Claim 9, the rejection of Claim 1 is incorporated; and Chandramohan discloses “wherein, before the AI algorithm is trained, the set of training [data] of issues associated with different components of source code has been [obtained] (paragraph [0028], “The training files (117) are the files used to train the machine learning models. In an embodiment, the training files (117) may include copies of the source files (107) (emphasis added).”; paragraph [0020], “The source files (107) may include reports, source code files, commits, etc., for a programming project.”; paragraph [0021], “A report may be a recorded description of a bug of a system. A report may include text that provides a description of a bug, a set of steps for reproduction of the bug, environment information, severity level, etc., that may be used to diagnose, analyze, and resolve the bug (emphasis added).”; paragraph [0013], “One or more embodiments automatically identify the source files where a bug is originated to reduce the needed time and computer resources spent maintaining the source files in a code repository (emphasis added).”),” but does not explicitly disclose:
wherein, before the AI algorithm is trained, the set of training sentence encodings of issues associated with different components of source code has been run through a summarization algorithm and a vector AI algorithm.
However, Isotani discloses:
the set of sentence encodings has been run through a summarization algorithm and a vector AI algorithm (page 3 Section 2.2 Sentence-BERT, “SBERT extends BERT to include sentence embedding (Reimers and Gurevych, 2019). It embodies the content features by converting sentences into vectors (emphasis added).”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the teaching of Chandramohan to include “wherein, before the AI algorithm is trained, the set of training sentence encodings of issues associated with different components of source code has been run through a summarization algorithm and a vector AI algorithm.” The modification would be obvious because one of ordinary skill in the art would be motivated to run the sentence encodings/embeddings through a summarization/vector algorithm in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports through more context reflective vectors. Moreover, running the encodings/embeddings through a vector algorithm before an AI algorithm is trained allows the AI algorithm to learn from the more context-reflective vectors, as training data, and better extrapolate the meaning behind the sentences (Isotani, page 11).
Claims 11-12 and 19 are method claims corresponding to system Claims 1-2 and 9 respectively and are rejected for the same reasons as given in the rejections of those claims.
Claim 20 is a non-transient computer readable medium claim corresponding to system Claim 1 and is rejected for the same reasons as given in the rejection of that claim.
Claims 3-6 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Chandramohan in view of Isotani as applied to Claims 1 and 11 above, and further in view of US 2020/0097389 (hereinafter “Smith”).
As per Claim 3, the rejection of Claim 1 is incorporated; and Chandramohan discloses “issues associated with different components of source code (paragraph [0021], “A report may be a recorded description of a bug of a system. A report may include text that provides a description of a bug, a set of steps for reproduction of the bug, environment information, severity level, etc., that may be used to diagnose, analyze, and resolve the bug (emphasis added).”; paragraph [0013], “One or more embodiments automatically identify the source files where a bug is originated to reduce the needed time and computer resources spent maintaining the source files in a code repository (emphasis added).”; paragraph [0015], “When using an embodiment of the disclosure, a user may select a set of source files and a report in a request for the system to analyze and locate source files and code segments that may be relevant to the bug identified in the report (emphasis added).”),” and “the new identified issue (paragraph [0021], “A report may be a recorded description of a bug of a system. A report may include text that provides a description of a bug, a set of steps for reproduction of the bug, environment information, severity level, etc., that may be used to diagnose, analyze, and resolve the bug (emphasis added).”; paragraph [0015], “When using an embodiment of the disclosure, a user may select a set of source files and a report in a request for the system to analyze and locate source files and code segments that may be relevant to the bug identified in the report (emphasis added).”),” but does not explicitly disclose:
wherein the set of training sentence encodings of issues associated with different components of source code comprise source code that fixes issues associated with the different components of source code, and
wherein the output from the AI algorithm further comprises a fix to the new identified issue.
However, Smith discloses:
wherein the set of training [data] of issues associated with [source code] comprise source code that fixes issues associated with the [source code] (paragraph [0064], “The code sample may comprise a line of code, a logical statement, a class or method definition, a file, or a project containing multiple related files […] The sequence to sequence model may be trained on training examples, wherein each training example comprises a training code sample, the error associated with the sample and a corresponding training corrected code (emphasis added).”), and
wherein the output from the AI algorithm further comprises a fix to the new identified issue (paragraph [0064], “In step 802, the code sample and optionally the additional error information are input to a machine learning model which has been trained to output a prediction for how to correct the code to fix the error.”).
Smith is within the same field of endeavor as the claimed invention regarding fixing code issues.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the teaching of Chandramohan to include “wherein the set of training [data] of issues associated with different components of source code comprise source code that fixes issues associated with the different components of source code, and wherein the output from the AI algorithm further comprises a fix to the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to provide a system that identifies and applies fixes to code bugs/errors in order to help programmers save time by helping them eliminate errors in their code (Smith, paragraph [0003]).
The combination of Chandramohan and Smith does not explicitly disclose:
wherein the set of training sentence encodings of issues associated with different components of source code comprise source code that fixes issues associated with the different components of source code.
However, Isotani discloses:
sentence encodings (page 1 Section 1 Introduction, “In our system, sentence embedding (distributed representations of semantics) generates vectors from the description content for each element in a bug report.”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the combined teachings of Chandramohan and Smith to include “wherein the set of training sentence encodings of issues associated with different components of source code comprise source code that fixes issues associated with the different components of source code.” The modification would be obvious because one of ordinary skill in the art would be motivated to include sentence encodings/embeddings in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports and help an AI algorithm effectively extrapolate meaning from reports through training. Moreover, by using sentence encodings/embeddings to effectively determine semantic similarity in bug duplication detection, burden on maintenance engineers can be reduced by potentially reducing how often a bug needs to be identified/fixed in code (Isotani, pages 4 & 11).
As per Claim 4, the rejection of Claim 3 is incorporated; and the combination of Chandramohan and Isotani does not explicitly disclose:
wherein the user interface displays source code of the one or more files that are likely a cause of the new identified issue and the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue.
However, Smith discloses:
wherein the user interface displays source code of the one or more files that are likely a cause of the new identified issue and the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue (paragraph [0068], “FIG. 10B illustrates an exemplary interface 304 for investigation of an error in the programming co-pilot system 340. A user interface 1010 is illustrated and includes an error information container 1012, an additional links container 1014, a suggested fix container 1016, and a fix history container 1018 […] The suggested fix container 1016 may display a list of one or more suggested change sequences to the code which may remove the error. Each suggested change sequence may be summarized by one or more details, such as a title, a short description, a portion of corrected code, or a portion of code with markup to demonstrate the suggested change sequence. The markup may be for example a diff of code before and after a fix to correct an error (emphasis added).”; paragraph [0057], “In step 702, a source code file is loaded into the code editor.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the combined teachings of Chandramohan and Isotani to include “wherein the user interface displays source code of the one or more files that are likely a cause of the new identified issue and the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to display code before and after a fix in order to provide a user with a visualization of the changes made which saves the user time and effort compared to manually searching to determine the location of the fix (Smith, paragraphs [0003 & 0068]).
As per Claim 5, the rejection of Claim 4 is incorporated; and the combination of Chandramohan and Isotani does not explicitly disclose:
wherein a developer, from the user interface, can do at least one of the following options: select a button to automatically incorporate the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue, view a likelihood of how the fix to the identified issue in the source code of the one or more files will resolve the new identified issue, view a likelihood of how the one or more files are the cause of the new identified issue, and recommend one or more developers who have experience with the identified one or more files that are likely the cause of the new identified issue.
However, Smith discloses:
wherein a developer, from the user interface, can do at least one of the following options: select a button to automatically incorporate the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue (Figure 10F; paragraph [0076], “The predicted error dialog box 1051 may also include a display of a predicted fix for fixing the error. It also may include an accept button 1052 and reject button 1053 […] If the accept button 1052 is activated by the user, then the predicted fix is applied to the code in the code editing container 1002.”; paragraph [0057], “In step 702, a source code file is loaded into the code editor.”), view a likelihood of how the fix to the identified issue in the source code of the one or more files will resolve the new identified issue, view a likelihood of how the one or more files are the cause of the new identified issue, and recommend one or more developers who have experience with the identified one or more files that are likely the cause of the new identified issue.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the combined teachings of Chandramohan and Isotani to include “wherein a developer, from the user interface, can do at least one of the following options: select a button to automatically incorporate the fix to the new identified issue in the source code of the one or more files that are likely a cause of the new identified issue, view a likelihood of how the fix to the identified issue in the source code of the one or more files will resolve the new identified issue, view a likelihood of how the one or more files are the cause of the new identified issue, and recommend one or more developers who have experience with the identified one or more files that are likely the cause of the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to allow a user to select a button to incorporate the fix in order to allow the user to effectively review the fix and decide whether to incorporate it into the code which gives a developer more flexibility over what to include in the code (Smith, paragraph [0076]).
As per Claim 6, the rejection of Claim 3 is incorporated; and the combination of Chandramohan and Isotani does not explicitly disclose:
wherein the fix is automatically incorporated into the one or more files that are the likely cause of the new identified issue.
However, Smith discloses:
wherein the fix is automatically incorporated into the one or more files that are the likely cause of the new identified issue (paragraph [0067], “In this example, running the code produces an error, and an error message is displayed in the console container 1004 […] In some embodiments, a fix predicted by the fix prediction system 350 may be applied automatically when the user saves or runs the file. In other embodiments, the predicted fix may be applied as soon as it is predicted. For example, it may be applied without waiting for user approval or acceptance.”; paragraph [0057], “In step 702, a source code file is loaded into the code editor.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the combined teachings of Chandramohan and Isotani to include “wherein the fix is automatically incorporated into the one or more files that are the likely cause of the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to automatically incorporate the fix in order to save the developer effort and time by having the system apply the fix as soon as the fix is predicted or the file is saved/run instead of having the developer manually incorporate the fix (Smith, paragraph [0067]).
Claims 13-16 are method claims corresponding to system Claims 3-6 respectively and are rejected for the same reasons as given in the rejections of those claims.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chandramohan in view of Isotani and Smith as applied to Claims 6 and 16 above, and further in view of US 2005/0071838 (hereinafter “Hatasaki”).
As per Claim 7, the rejection of Claim 6 is incorporated; and Chandramohan discloses “the one or more files that are the likely cause of the new identified issue (paragraph [0021], “A report may be a recorded description of a bug of a system (emphasis added).”; paragraph [0015], “When using an embodiment of the disclosure, a user may select a set of source files and a report in a request for the system to analyze and locate source files and code segments that may be relevant to the bug identified in the report (emphasis added).”; paragraph [0063], “The file ranking model (280) is a program that may operate as part of the ranking model (202) […] In an embodiment, the file ranking model (280) may use a majority voting algorithm to determine the ranks for the source code files in a project. The source code files with higher ranks may have a higher likelihood of being relevant to the bug identified in the report (208) (emphasis added).”; paragraph [0086], “Step 412 includes applying a ranking model to the report source score and the report commit score to identify the source file corresponding to the report. In an embodiment, the source file may be identified with a file rank generated by the ranking model (emphasis added).”),” but the combination of Chandramohan, Isotani, and Smith does not explicitly disclose:
wherein in response to the fix being automatically incorporated into the one or more files that are the likely cause of the new identified issue do at least one of: recompile the base of source code with the fix to the new identified issue and reinterpret the base of source code with the fix to the new identified issue.
However, Hatasaki discloses:
wherein in response to the fix being automatically incorporated into the one or more [code] that are the likely cause of the new identified issue do at least one of: recompile the base of source code with the fix to the new identified issue (paragraph [0085], “Then, at the next step S532, the compile unit 530 acquires software-updating patches 102 to be tested. If the source-code information 330 and/or the source code retrieved by the software acquisition unit 520 include objects to be updated, the compile unit 530 applies source-code patches 410 of the software-updating patches 102 to be tested to the objects. After applying the source-code patches 410, at the next step S533, the compile unit 530 compiles the source-code information 330 and the source code retrieved by the software acquisition unit 520 to generate components of an executable binary format.”; paragraph [0010], “In particular, when it is desired to update a piece of software due to a serious reason such as a detected fragility in security or a found bug […].”) and reinterpret the base of source code with the fix to the new identified issue.
Hatasaki is within the same field of endeavor as the claimed invention regarding applying fixes to and compiling code.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Hatasaki into the combined teachings of Chandramohan, Isotani, and Smith to include “wherein in response to the fix being automatically incorporated into the one or more files that are the likely cause of the new identified issue do at least one of: recompile the base of source code with the fix to the new identified issue and reinterpret the base of source code with the fix to the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to automatically run and then compile the fixed/patched code to ensure high reliability by being able to check that the code compiled successfully and test it to verify the fix (Hatasaki, paragraphs [0012 & 0013]).
Claim 17 is a method claim corresponding to system Claim 7 and is rejected for the same reasons as given in the rejection of that claim.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chandramohan in view of Isotani as applied to Claims 1 and 11 above, and further in view of Smith, US 2024/0160435 (hereinafter “Duan”), and US 2025/0165379 (hereinafter “Baker”).
As per Claim 8, the rejection of Claim 1 is incorporated; and Chandramohan discloses “wherein the set of training [data] of issues associated with different components of source code comprises: tickets for issues (paragraph [0028], “The training files (117) are the files used to train the machine learning models. In an embodiment, the training files (117) may include copies of the source files (107). In an embodiment, reports [tickets] in the training files (117) may be identified as “closed” to indicate that a bug described with a report has been resolved and is no longer present when an application is executed.”; paragraph [0021], “A report may be a recorded description of a bug of a system (emphasis added).”; paragraph [0015], “When using an embodiment of the disclosure, a user may select a set of source files and a report in a request for the system to analyze and locate source files and code segments that may be relevant to the bug identified in the report (emphasis added).”),” but does not explicitly disclose:
wherein the set of training sentence encodings of issues associated with different components of source code comprises: tickets for issues, pull requirements for the issues, comments from the different components of source code, and fixes to the issues in the different components of source code.
However, Isotani discloses:
sentence encodings (page 1 Section 1 Introduction, “In our system, sentence embedding (distributed representations of semantics) generates vectors from the description content for each element in a bug report.”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the teaching of Chandramohan to include “wherein the set of training sentence encodings of issues associated with different components of source code comprises: tickets for issues.” The modification would be obvious because one of ordinary skill in the art would be motivated to include sentence encodings/embeddings in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports and help an AI algorithm effectively extrapolate meaning from reports through training. Moreover, by using sentence encodings/embeddings to effectively determine semantic similarity in bug duplication detection, burden on maintenance engineers can be reduced by potentially reducing how often a bug needs to be identified/fixed in code (Isotani, pages 4 & 11).
The combination of Chandramohan and Isotani does not explicitly disclose:
pull requirements for the issues, comments from the different components of source code, and fixes to the issues in the different components of source code.
However, Smith discloses:
fixes to the issues in the [source code] (paragraph [0064], “In step 802, the code sample and optionally the additional error information are input to a machine learning model which has been trained to output a prediction for how to correct the code to fix the error.”; paragraph [0076], “The predicted error dialog box 1051 may also include a display of a predicted fix for fixing the error. It also may include an accept button 1052 and reject button 1053 […] If the accept button 1052 is activated by the user, then the predicted fix is applied to the code in the code editing container 1002.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the combined teachings of Chandramohan and Isotani to include “fixes to the issues in the different components of source code.” The modification would be obvious because one of ordinary skill in the art would be motivated to provide a system that identifies and applies fixes to code bugs/errors in order to help programmers save time by helping them eliminate errors in their code (Smith, paragraph [0003]).
The combination of Chandramohan, Isotani, and Smith does not explicitly disclose:
pull requirements for the issues, comments from the different components of source code.
However, Duan discloses:
pull requirements for the issues (paragraph [0071], “The data mining engine 104 mines various source code repositories 102 for pull requests, commits, comments, code reviews, source code, and data that is used to generate the pre-training datasets.”; paragraph [0090], “For the code quality estimation classification activity, the source code repositories are mined for code changes. All changed code having a code review is regarded as suspicious code that introduced software bugs or conflicts with code specifications and labeled as requiring a code review.”).
Duan is within the same field of endeavor as the claimed invention regarding the utilization of pull requests and comments in training data.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Duan into the combined teachings of Chandramohan, Isotani, and Smith to include “pull requirements for the issues.” The modification would be obvious because one of ordinary skill in the art would be motivated to include pull requests as part of the training data to include more relevant pieces of data related to issues for more effective model training. Moreover, utilizing the pull requests to extract relevant code changes into a code diff format is a more efficient representation of code changes and a more natural way for model learning (Duan, paragraph [0030 & 0026]).
The combination of Chandramohan, Isotani, Smith, and Duan does not explicitly disclose:
comments from the different components of source code.
However, Baker discloses:
comments from the different components of source code (paragraph [0051], “For instance, for each pull request 265 uploaded to source code repository 275, the natural language interface 144 may automatically obtain text from the pull request 265 and code comments from files in the pull request 265. In the example depicted in FIG. 2B, the text and code comments (e.g., natural language content 205) are provided to an internal NLPS 110a in a request 260.”; Claim 8, “[…] wherein receiving the natural language content comprises at least one of […] receiving a comment included in the source code.”).
Baker is within the same field of the claimed invention regarding artificial intelligence and the utilization of source code comments.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Baker into the combined teachings of Chandramohan, Isotani, Smith, and Duan to include “comments from the different components of source code.” The modification would be obvious because one of ordinary skill in the art would be motivated to include comments from source code as part of the training data to include more relevant pieces of data related to directly to source code issues and better aid an AI algorithm in understanding the meaning or developer’s intent behind the code (Baker, paragraph [0051] & claim 8).
Claim 18 is a method claim corresponding to system Claim 8 and is rejected for the same reasons as given in the rejection of that claim.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Chandramohan in view of Isotani as applied to Claims 1 and 11 above, and further in view of US 2025/0254138 (hereinafter “Bonyadi”), Smith, and US 2022/0180290 (hereinafter “Xin”).
As per Claim 10, the rejection of Claim 1 is incorporated; and Chandramohan discloses “providing the set of one or more [output vectors] to the trained AI algorithm (paragraph [0035], “The ranking model (155) is a machine learning model that is trained to generate the rankings (113) from the source files (107) (emphasis added).”; paragraph [0037], “For example, the fine-tuned language model (159) may receive embedding vectors generated by the input processing model (157) that are processed to generate output vectors stored in the vectors (109). The outputs of the fine-tuned language model (159) may be processed by the ranking model (155) to generate vectors, scores, and rankings stored in the vectors (109), the scores (111), and the rankings (113) in the repository (103) (emphasis added).”)” and “identify the one or more files that are likely to identify the cause of the new identified issue (paragraph [0063], “The file ranking model (280) is a program that may operate as part of the ranking model (202) […] In an embodiment, the file ranking model (280) may use a majority voting algorithm to determine the ranks for the source code files in a project. The source code files with higher ranks may have a higher likelihood of being relevant to the bug identified in the report (208) (emphasis added).”; paragraph [0086], “Step 412 includes applying a ranking model to the report source score and the report commit score to identify the source file corresponding to the report. In an embodiment, the source file may be identified with a file rank generated by the ranking model (emphasis added).”),” but does not explicitly disclose:
wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue, and to identify the best developers to fix the issue.
However, Isotani discloses:
sentence encodings (page 1 Section 1 Introduction, “In our system, sentence embedding (distributed representations of semantics) generates vectors from the description content for each element in a bug report.”; page 4 Section 3.1 Duplicate bug report detection, “The second is converting bug reports into vectors that capture the characteristics of the reported problems. To address this challenge, our system vectorizes descriptions by element type in the report using sentence embedding. This approach should be suitable to clarify the characteristics of the problem because target reports are written in a natural language. In our system, reports are vectorized by element because each report contains unique information. Here, sentence embedding is both a technique and a model. It converts sentences into vectors that capture the characteristics of the content (emphasis added).”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Isotani into the teaching of Chandramohan to include “wherein providing the set of one or more sentence encodings to the trained AI algorithm […].” The modification would be obvious because one of ordinary skill in the art would be motivated to include sentence encodings/embeddings in order to effectively capture characteristics of the content/reported problems that help encapsulate the meaning of sentences within bug reports and help an AI algorithm effectively extrapolate meaning from reports. Moreover, by using sentence encodings/embeddings to effectively determine semantic similarity in bug duplication detection, burden on maintenance engineers can be reduced by potentially reducing how often a bug needs to be identified/fixed in code (Isotani, pages 4 & 11).
The combination of Chandramohan and Isotani does not explicitly disclose:
wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue, and to identify the best developers to fix the issue.
However, Bonyadi discloses:
a text prompt that instructs the trained AI algorithm to: identify […] (paragraph [0048], “The information retrieval AI 418 receives the user query/response as input and processes the user query/prompt to identify the people, event(s), task(s), and the like which are pertinent to the user query/request and accesses user data elements related to the identified people, event(s), task(s), and the like to identify relevant information which can be used by the digital assistant component to respond to the user query/response. The intelligent information retrieval component 416 provides the user input (e.g., query/request) and the retrieved user context data to the prompt generating component 420. The prompt generating component 420 is configured to generate a prompt for the digital assistant AI that includes the user input and the user context data and that is formatted and structured in a manner suitable for processing by the digital assistant AI (emphasis added).”).
Bonyadi is within the same field of endeavor as the claimed invention regarding prompting AI algorithms.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Bonyadi into the combined teachings of Chandramohan and Isotani to include “a text prompt that instructs the trained AI algorithm to: identify […].” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a prompt integrated with context information to an AI algorithm to enable more relevant information in the output of the AI algorithm (Bonyadi, paragraph [0023]).
The combination of Chandramohan, Isotani, and Bonyadi does not explicitly disclose:
wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue, and to identify the best developers to fix the issue.
However, Smith discloses:
to identify likely fixes to source code the [file] (paragraph [0064], “In step 802, the code sample and optionally the additional error information are input to a machine learning model which has been trained to output a prediction for how to correct the code to fix the error.”; paragraph [0076], “The predicted error dialog box 1051 may also include a display of a predicted fix for fixing the error. It also may include an accept button 1052 and reject button 1053 […] If the accept button 1052 is activated by the user, then the predicted fix is applied to the code in the code editing container 1002.”; paragraph [0057], “In step 702, a source code file is loaded into the code editor.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into the combined teachings of Chandramohan, Isotani, and Bonyadi to include “wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to provide a system that identifies and applies fixes to code bugs/errors in order to help programmers save time by helping them eliminate errors in their code (Smith, paragraph [0003]).
The combination of Chandramohan, Isotani, Bonyadi, and Smith does not explicitly disclose:
wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue, and to identify the best developers to fix the issue.
However, Xin discloses:
to identify the best developers to fix the issue (paragraph [0010], “In accordance with example implementations that are described herein, an extreme machine learning classifier, or feedforward neural network classifier, is trained and used to identify a software developer to assign to a given software defect report for purposes of resolving a software defect that is identified in the report.”; paragraph [0016], “In general, the computer system 100 includes a physical machine 120, which is constructed to apply machine learning, and more specifically, apply a feedforward neural network classifier 125, to unassigned software defect reports 110 for purposes of generating corresponding software defect reports 150 that contain or have recommended developers to resolve defects that are identified in the software defect reports 110.”).
Xin is within the same field of endeavor as the claimed invention regarding an AI algorithm identifying developers to fix a software issue.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Xin into the combined teachings of Chandramohan, Isotani, Bonyadi, and Smith to include “wherein providing the set of one or more sentence encodings to the trained AI algorithm further comprises a text prompt that instructs the trained AI algorithm to: identify the one or more files that are likely to identify the cause of the new identified issue, to identify likely fixes to source code in the identify the one or more files that are likely to identify the cause of the new identified issue, and to identify the best developers to fix the issue.” The modification would be obvious because one of ordinary skill in the art would be motivated to identify and automate assignment of developers to fix the issue allows a relatively fast and accurate defect triage, which minimizes time and costs (Xin, paragraph [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 2017/0212829 (hereinafter “Bales”) discloses fix suggestions being automatically integrated into source code.
US 2023/0118695 (hereinafter “Zhang”) discloses recompiling updated software patches.
US 20210064361 (hereinafter “Jayaraman”) discloses an AI platform identifying a developer to fix a software defect issue.
US 20220405091 (hereinafter “Mahanta”) discloses identifying developers to address source code issues using machine learning.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Feven H. Huruy whose telephone number is (571) 272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/F.H.H./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights