DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The instant application having application No. 18/904,249 filed on October 2, 2024, presents claims 1-20 for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Objections
Claims 4, 5, 6, 7, 14, 15, 16, and 17 are objected to because of the following informalities:
Withy respect to claims 4 and 14, “the at least one identified difference” lacks antecedent basis.
With respect to claims 5 and 15, the first instance of BERT should be spelled out in full. Claims 6, 7, 16, and 17 inherit this deficiency.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-7 and 12-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claims 2 and 12, each recites “a testing context … the generated commit message, file type and target test case examples information”. It is unclear if this is the same as the previously recited “testing context” in respective parent claims 1 and 11 and the previously recited “commit message information, file type information and target test case examples information” in claims 2 and 12. The scope of claims 2 and 12 are therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claims 2 and 12 as reciting -- the generated commit message information, the file type information, and the target test case examples information --.
Claims 3, 4, inherit the deficiency of claim 2 and claims 13 and 14 inherit the deficiency of claim 12.
With respect to claims 4 and 14, each recites the “the target test case examples”. It is unclear if this is the same as the previously recited “target test case examples information”, which renders the scope of claims 4 and 14 indefinite. For purposes of compact prosecution only, Examiner has interpreted claims 4 and 14 as reciting -- the target test case examples information --.
With respect to claims 5 and 15, each recites “model input” and it is unclear if this is same as “model input” recite in their respective parent claim. The scope of claims 5 and 15 are therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claims 5 and 15 as reciting – the model input --.
Claims 6-7 inherit the deficiency of claim 5 and claims 16-17 inherit the deficiency of claim 15.
With respect to claims 7 and 17, claim 7 recites “a testing script using a trained (NLP1 model” and claim 17 recites “a testing script using a trained NLP”. It is unclear if this is the same as “a testing script” and “a trained natural language processing model” as recited in their respective parent claims. The scope of claims 7 and 17 are therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claims 7 and 17 as reciting “the testing script using the trained NLP model”.
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, 5, 7, 11, 15, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yaraghi et al. “Automated Test Case Repair Using Language Models” (hereinafter Yaraghi) in view of Pillay (US 20260072811 A1, hereinafter Pillay).
With respect to claim 1, Yaraghi discloses A method (e.g., p. 2, left col., 1st bullet point, TARGET: An automatic broken test case repair technique using language models.) comprising:
generating, by a computing device, a testing context comprising information identifying at least one difference between first and second code versions (e.g., Figs. 1-2 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 4, right col., last full para., We proceed to create a set of hunks denoted as R, called the repair context set, that captures the changes in the SUT between Vi [first] and Vi+1 [second]; see also p. 3, § 3, 1st para. and p. 4, § 3.1.1 Repair Context Identification, 1st para.);
generating, by the computing device, model input using the testing context (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC) ... The input sequence I is thus formatted as follows: I = [<TESTCONTEXT>] TC [<REPAIRCONTEXT>] RC; p. 11, 4.3.2, we perform test repair given the broken test code, the location of the breakage within the test code, and a set of code changes made to the SUT. With these inputs, we can construct an input sequence for a CLM.);
generating, by the computing device, a testing script using a trained natural language processing (NLP) model and the model input (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 7, 3.2.3 Repair Generation, we employ the fine-tuned model to generate repairs for broken test cases ... As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.); and
testing, by the computing device, the second code version using the generated testing script (e.g., Figs. 1-5 and associated text, e.g., p. 7, right col., last para., Finally, we replace the broken lines of the original test code with the candidate repair patches. We compile and run the repaired test cases against the new version of the SUT (Vi+1).).
Yaraghi does not appear to disclose the following, which is taught in analogous art, Pillay: commit … commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Yaraghi with the invention of Pillay, such that git diff is used to identify source code changes between commits in a Git version control system (VCS), because both Git and git diff are commonly used, and further because a Git VCS can “track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions” and “The diff output provides a detailed line-by-line comparison of changes, highlighting additions and deletions, which is crucial for understanding the scope and impact of changes,” as suggested by Pillay (see [0071]).
With respect to claim 11, Yaraghi discloses A non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions that when executed by a processor associated with a computing device perform a method comprising (e.g., p. 2, left col., 1st bullet point, TARGET: An automatic broken test case repair technique using language models; p. 17, left col., top para., TARGET is also a comprehensive test repair tool; p. 16, § 4.8 Implementation and Resources, Computation Resources. We conducted our fine-tuning experiments on a machine with two Nvidia Quadro RTX 6000 GPUs (each with 24GB GPU memory), an Intel Xeon Gold 6234 16-Core CPU, and 187GB of RAM.):
generating a testing context comprising information identifying at least one difference between first and second code versions (e.g., Figs. 1-2 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 4, right col., last full para., We proceed to create a set of hunks denoted as R, called the repair context set, that captures the changes in the SUT between Vi [first] and Vi+1 [second]; see also p. 3, § 3, 1st para. and p. 4, § 3.1.1 Repair Context Identification, 1st para.);
generating model input using the testing context (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC) ... The input sequence I is thus formatted as follows: I = [<TESTCONTEXT>] TC [<REPAIRCONTEXT>] RC; p. 11, 4.3.2, we perform test repair given the broken test code, the location of the breakage within the test code, and a set of code changes made to the SUT. With these inputs, we can construct an input sequence for a CLM.);
generating a testing script using a trained natural language processing (NLP) model and the model input (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 7, 3.2.3 Repair Generation, we employ the fine-tuned model to generate repairs for broken test cases ... As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.); and
testing the second code version using the generated testing script (e.g., Figs. 1-5 and associated text, e.g., p. 7, right col., last para., Finally, we replace the broken lines of the original test code with the candidate repair patches. We compile and run the repaired test cases against the new version of the SUT (Vi+1).).
Yaraghi does not appear to disclose the following, which is taught in analogous art, Pillay: commit … commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Yaraghi with the invention of Pillay, such that git diff is used to identify source code changes between commits in a Git version control system (VCS), because both Git and git diff are commonly used, and further because a Git VCS can “track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions” and “The diff output provides a detailed line-by-line comparison of changes, highlighting additions and deletions, which is crucial for understanding the scope and impact of changes,” as suggested by Pillay (see [0071]).
With respect to claim 20, Yaraghi discloses A computing device comprising: a processor (e.g., p. 2, left col., 1st bullet point, TARGET: An automatic broken test case repair technique using language models; p. 17, left col., top para., TARGET is also a comprehensive test repair tool; p. 16, § 4.8 Implementation and Resources, Computation Resources. We conducted our fine-tuning experiments on a machine with two Nvidia Quadro RTX 6000 GPUs (each with 24GB GPU memory), an Intel Xeon Gold 6234 16-Core CPU, and 187GB of RAM.), configured to:
generate a testing context comprising information identifying at least one difference between first and second code versions (e.g., Figs. 1-2 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 4, right col., last full para., We proceed to create a set of hunks denoted as R, called the repair context set, that captures the changes in the SUT between Vi [first] and Vi+1 [second]; see also p. 3, § 3, 1st para. and p. 4, § 3.1.1 Repair Context Identification, 1st para.);
generate model input using the testing context (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC) ... The input sequence I is thus formatted as follows: I = [<TESTCONTEXT>] TC [<REPAIRCONTEXT>] RC; p. 11, 4.3.2, we perform test repair given the broken test code, the location of the breakage within the test code, and a set of code changes made to the SUT. With these inputs, we can construct an input sequence for a CLM.);
generating a testing script using a trained natural language processing (NLP) model and the model input (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., For all IOs, the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC); p. 7, 3.2.3 Repair Generation, we employ the fine-tuned model to generate repairs for broken test cases ... As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.); and
test the second code version using the generated testing script (e.g., Figs. 1-5 and associated text, e.g., p. 7, right col., last para., Finally, we replace the broken lines of the original test code with the candidate repair patches. We compile and run the repaired test cases against the new version of the SUT (Vi+1).).
Yaraghi does not appear to disclose the following, which is taught in analogous art, Pillay: commit … commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Yaraghi with the invention of Pillay, such that git diff is used to identify source code changes between commits in a Git version control system (VCS), because both Git and git diff are commonly used, and further because a Git VCS can “track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions” and “The diff output provides a detailed line-by-line comparison of changes, highlighting additions and deletions, which is crucial for understanding the scope and impact of changes,” as suggested by Pillay (see [0071]).
With respect to claims 5 and 15, Yaraghi also discloses generating model input further comprising: tokenizing the model input, wherein the tokenized model input is used by the NLP model in generating the testing script (e.g., Figs. 1-5 and associated text, e.g., p. 7, § 3.2.3. Repair Generation, 1st-2nd paras., Language models have a predefined vocabulary comprising various tokens. Therefore, the input source code goes through tokenization before being provided as input to the model, and the resulting outputs are also in token format. As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.).
With respect to claims 7 and 17, Yaraghi also discloses wherein generating a testing script using a trained (NLP model further comprises: receiving tokenized output (e.g., Figs. 1-5 and associated text, e.g., p. 7, § 3.2.3. Repair Generation, 1st-2nd paras., Language models have a predefined vocabulary comprising various tokens. Therefore … the resulting outputs are also in token format.); and de-tokenizing the tokenized output (e.g., Figs. 1-5 and associated text, e.g., p. 7, § 3.2.3. Repair Generation, 1st-2nd paras., Language models have a predefined vocabulary comprising various tokens. Therefore … the resulting outputs are also in token format. As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.).
Claims 2-3 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Yaraghi in view of Pillay, as applied to claims 1 and 11 above, and further in view Liu et al. “CommitBART: A Large Pre-trained Model for GitHub Commits” (hereinafter Liu) and Clement et al. (US 20240419917 A1, hereinafter Clement).
With respect to claims 2 and 12, Yaraghi also discloses generating a testing context further comprising: generating and target test case information (please note the 35 USC 112(b) rejection and interpretation above; e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC) ... The input sequence I is thus formatted as follows: I = [<TESTCONTEXT>] TC [<REPAIRCONTEXT>] RC; p. 11, 4.3.2, we perform test repair given the broken test code, the location of the breakage within the test code, and a set of code changes made to the SUT. With these inputs, we can construct an input sequence for a CLM.), wherein the testing context used in generating the model input further comprises the generated and target test case information (please note the 35 USC 112(b) rejection and interpretation above; Id.).
Yaraghi as modified by Pillay does not appear to disclose the following, which is taught in analogous art, Liu: commit message information, file type information (e.g., Fig. 1 and associated text, e.g., p. 2, § 2.1 GitHub Commits, A commit usually consists of the changed code with its commit message to describe the purpose of the current changed code in natural language. We present a commit to illustrate each component in Figure 1. The upper rectangle contains the content of the commit message, which summarizes this commit in natural language … The lower rectangle is the changed code namely one chunk, which contains the file path (i.e., "tpot/tpot.py") [file type information]; p. 6, right col., 3rd para., takes the commit message, and file path with the code snippet before modification as input; p. 12, § C.3, Updated Code Snippet Generation, We provide two examples for the task of updated code snippet generation. Similar to the task of positive code statements generation, the input includes the file path, the commit message and the previous code snippet; see also p. 12, § C.2 Positive Code Statements Generation.) … commit message, file type (please note the 35 USC 112(b) rejection and interpretation above; Id.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the technique of Liu because GitHub commit messages help with understanding code evolution and when included in model inputs lead to improved code generation, as suggested by Liu (see p. 1, top para. and pp. 12-13, §§ C.2-C.3).
Yaraghi as modified by Pillay and Liu does not appear to disclose the following, which is taught in analogous art, Clement: examples (e.g., Figs. 9-10 and associated text, e.g., [0067] A prompt is generated using a unit test generation prompt template for the programming language associated with the source code program (block 908). The prompt includes instructions describing the task, the source code program, and the top-k unit tests closely associated with the source code; see also [0068].) … examples (please note the 35 USC 112(b) rejection and interpretation above; Id.; see also [0067], The prompt is sent to the large language model (block 910) and a unit test class is received (block 912) which is output (block 914).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the invention of Clement because it can result in the “enhanced accuracy of the response without additional computational burden,” as suggested by Clement (see [0069]).
With respect to claims 3 and 13, Lie further teaches extracting the commit message information and the file type information from a Global Information Tracker (GIT) commit command (e.g., Fig. 1 and associated text, e.g., p. 2, § 2.1 GitHub Commits, A commit usually consists of the changed code with its commit message to describe the purpose of the current changed code in natural language. We present a commit to illustrate each component in Figure 1. The upper rectangle contains the content of the commit message, which summarizes this commit in natural language … The lower rectangle is the changed code namely one chunk, which contains the file path (i.e., "tpot/tpot.py"); p. 3, § 3, we collect commits from the open-source projects on GitHub … we utilize the open-source tool GitPython * to obtain the raw commits; p. 6, right col., 3rd para., takes the commit message, and file path with the code snippet before modification as input; p. 12, § C.3, Updated Code Snippet Generation, We provide two examples for the task of updated code snippet generation. Similar to the task of positive code statements generation, the input includes the file path, the commit message and the previous code snippet; see also p. 12, § C.2 Positive Code Statements Generation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the technique of Liu for the same reason set forth above.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Yaraghi in view of Pillay, Liu, and Clement, as applied to claims 2 and 12 above, and further in view of Chi et al. (CN 118331859 A, hereinafter Chi).
With respect to claims 4 and 14, Yaraghi also discloses generating the target test case the at least one identified difference between the first and second code versions (e.g., Figs. 1-5 and associated text, e.g., p. 6, right col., 1st full para., the input is created per each test case t as a sequence consisting of two parts: the test context (TC) and the repair context (RC) ... The input sequence I is thus formatted as follows: I = [<TESTCONTEXT>] TC [<REPAIRCONTEXT>] RC; p. 11, 4.3.2, we perform test repair given the broken test code, the location of the breakage within the test code, and a set of code changes made to the SUT. With these inputs, we can construct an input sequence for a CLM.).
Pillay further teaches commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.) and Clement further teaches examples (e.g., Figs. 9-10 and associated text, e.g., [0067] A prompt is generated using a unit test generation prompt template for the programming language associated with the source code program (block 908). The prompt includes … the top-k unit tests closely associated with the source code; see also [0068].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the inventions of Pillay and Clement for the same reasons set forth above.
Although Yaraghi as modified by Pillay and Clement teaches generating test case examples information and the at least one identified difference between the first and second code commit versions (see above), it does not appear to disclose using the at least one identified difference. However, in analogous art, Chi teaches using (e.g., p. 2, when the developer changes the production code in the project evolution process, the test example can be automatically updated; p. 3, S6) when the item is changed, searching the sample with the highest similarity with the production code diff; p. 3, S7) substituting the production code before and after the change obtained by S6, the test code before the change and the high similarity sample … into the prompt template to form a complete prompt; p. 4, 4th full para., These vectors will be used to find knowledge base samples with high similarity to the change of the target production code; p. 4, 5th full para., The constructed vector database supports high-efficiency similarity search and retrieval task, and the Agent for matching similarity and extracting the most similar sample to guide the large language model generates better test code.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the invention of Chi because the combination would result in examples information that guides the generation of the test code being similar to the specific changed code being tested, which would generate “better test code”, as suggested by Chi (see p. 4, 5th full para.).
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Yaraghi in view of Pillay, as applied to claims 1 and 11 above, and further in view Anonymous, “BertGeneration” (hereinafter Anonymous).
With respect to claims 6 and 16, Yaraghi also discloses wherein the tokenizing is performed using a tokenizer, and the trained NLP model is a transformer model (e.g., Figs. 1-5 and associated text, e.g., p. 7, § 3.2.3. Repair Generation, 1st-2nd paras., We utilize CLMs with both encoder-decoder and decoder only transformer architectures that are pre-trained on code (e.g., CodeT5+) ... Language models have a predefined vocabulary comprising various tokens. Therefore, the input source code goes through tokenization before being provided as input to the model, and the resulting outputs are also in token format. As described in Section 2, we use the beam search ranking strategy to generate candidate test case repairs. Finally, we replace the broken lines of the original test code with the candidate repair patches.).
Yaraghi does not appear to disclose the following, which is taught in analogous art, Anonymous: BERT (e.g., p. 2, tokenizer = BertTokenizer.from_pretrained ("google-bert/bert- large -uncased") … BERT (e.g., p. 1, The BertGeneration model is a BERT model that can be leveraged for sequence-to-sequence tasks using [EncoderDecoderModel]; p. 2, encoder = BertGenerationEncoder … decoder = BertGenerationDecoder … bert2bert = EncoderDecoderModel (encoder=encoder, decoder=decoder).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the technique of Anonymous, such that a BERT tokenizer and BERT transformer model are used, because BERT is a well-known transformer model and its bi-directional approach provides deep understanding of relationships between tokens, which would be helpful for understanding the input source code.
Claims 8, 9, 10, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yaraghi in view of Pillay, as applied to claims 1 and 11 above, and further in view Mitchell et al. (US 20180365133 A1, hereinafter Mitchell).
With respect to claims 8 and 18, Yaraghi also discloses wherein testing the second code version further comprises: causing the second code version to be executed using a testing function and a testing scenario defined by the testing script (e.g., Figs. 1-5, particularly in Fig. 2 “@Test void testDeposit() {… Bank account = new BankAccount("USD") … account.deposit(500, "USD"); … assertEquals(500, account.getBalance());” and associated text, e.g., p. 8, right col., last para., we replace the broken lines of the original test code with the candidate repair patches. We compile and run the repaired test cases against the new version of the SUT (Vi+1).); and the testing function (Id.)
Pillay further teaches commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Yaraghi with the invention of Pillay for the same reason set forth above.
Yaraghi does not appear to disclose the following, which is taught in analogous art, Mitchell: receiving, from …, result information indicating whether the second code commit version responded correctly given the testing scenario (e.g., Fig. 1 and associated text, e.g., [0011], a continuous integration (CI) service is used by developers who are writing code for an application … in response to certain source code commits, a CI build server rebuilds the target application, deploys it for execution by a test server, and tests the server application using automate testing techniques. Any errors found in this process are reported to the developers; [0017], The CI service may run the integration test after every developer code commit; [0036], After completing the test scripts 132, or whenever a test failure is detected, the device test controller 126 sends test results 130 to the CI service 108. The test results 130 include any detected failures of the tests specified by the test scripts 132; see also Abstract and [0034].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the invention of Mitchell because it would allow developers to know whether the code they committed works correctly.
With respect to claims 9 and 19, Yaraghi also discloses wherein the testing scenario comprises information indicating a value for at least one variable supplied to the second code version via the testing function (e.g., Figs. 1-5, particularly in Fig. 2 “@Test void testDeposit() {… Bank account = new BankAccount("USD") … account.deposit(500, "USD"); … assertEquals(500, account.getBalance());” and “public int deposit(int amount, String depositCurrency )” along with associated text, e.g., p. 8, right col., last para., we replace the broken lines of the original test code with the candidate repair patches. We compile and run the repaired test cases against the new version of the SUT (Vi+1).) and Pillay further teaches commit (e.g., [0071] The first step in identifying changes involves integrating with version control systems (VCS) (these may include, for example, systems such as Git, SVN, or Mercurial). These systems track changes to the codebase over time, providing a comprehensive history of modifications, additions, and deletions. By comparing different commits … the system may extract differences between code versions. Suitable tools (such as, for example, git diff) may be utilized to produce a list of changes, including modified lines, added or deleted functions, and other code alterations.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Yaraghi with the invention of Pillay for the same reason set forth above.
With respect to claim 10, Mitchell further teaches using a testing framework to perform the causing step, wherein the result information is received via the testing framework (e.g., Fig. 1 and associated text, e.g., [0029] The configuration 100 [testing framework] has a device test controller 126 that is configured to receive a client application 128 from the CI service 108, to perform testing of the client application 128 on the wireless devices 118, and to provide test results 130 to the CI service 108; see also Abstract and [0011], [0017], [0034], and [0036].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Yaraghi with the invention of Mitchell for the same reason set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Schaefer et al. US 20240311582 A1 teaches a large language model, trained on source code and natural language text generates a unit test for a change to a file in a pull request of a code repository.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 The single parenthesis here appears to be a typographical error.
Prosecution Insights