DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is responsive to the application filed November 14, 2024.
Claims 1-20 are pending and are presented for examination.
Examiner Notes
3. Examiner cites particular columns 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 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.
4. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Specification
5. The specification is objected to for information provided on page 1, paragraph 0001, where the current status of the Cross Reference to Related Applications should be updated. See MPEP 608.01[R-5] and 37 CFR 1.78.
Claim Objections
6. Claims 16-20 are objected to because of the following informalities:
As to claim 16, lines 19-20 recites to include the following limitation “wherein the beam search ends” – appear to lack of antecedent basis for this limitation in the claim. For expedited in prosecution, examiner anticipated amend at lines 15 -16 as follows,
--wherein the search comprises a beam search to generate partial sequences of tokens –
Claims 17-20 are also objected to for being depended upon the objection of base claim 16.
Claim Rejections - 35 USC § 103
7. 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.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over GUPTA et al. (US 20190228319 A1, hereinafter Gupta) in view of Li et al. “Automating Code Review Activities by Large-Scale Pre-training” hereinafter Li, ESEC/FSE ’22, November 14–18, 2022, Singapore of 04/13/2025 IDS, and in further view of CLEMENT et al. (US 20210357187 A1, hereinafter Clement).
As to claim 1, Gupta, discloses a system--(e.g., computing device 702, Fig. 7, -- see at least 0068) comprising: a processor (e.g., one or more processors 704, Fig. 7 – see at least 0068); and a memory (e.g., memory 710, Fig. 7 – see at last 0068-0070) that stores a program configured to be executed by the processor, the program comprising instructions to perform actions that:
obtain, from a pull request of a version-controlled source code repository, a proposed source code change to a source code program– (e.g., “When a new pull request is received in a shared source code repository, it may include new source code file or modifications (proposed change) to existing source code files in the repository – see at least 0005, 0034-0035,0052, Fig. 4, and associated text);
access a database of augmented code review comments, wherein each augmented code review comment of the database is associated with a code edit – (e.g., pull/extract data from the shared source code repository 106, which include comments etc. of the source code file such as snippet etc. – see at least 0005, 0024-0026, 0034-0035, 0052, Fig. 4, and associated text);
retrieve at least one augmented code review comment for the proposed source code change from the database, wherein the at least one augmented code review comment is associated with a code edit similar to a code edit of the proposed source code change – (e.g., “The knowledge base is searched for code reviews having closely matching source code, lower context and upper context as the input code snippet (block 606)” -- see at least 0044-0045, 0061, Fig. 4, Fig. 6, and associated text);
perform a search to generate a code review comment for the proposed source code change, wherein the search invokes a neural model given the proposed source code change and the at least one augmented code review comment, to generate a probability distribution, at each time step, that identifies a next token to append to a respective partial sequence, and then outputs the select partial sequence as the code review comment for the proposed source code change--(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see at least 0062, Fig. 6 and associated text); and
output the code review comment to the version-controlled source code repository—(e.g., The shared source code repository 106 may be configured as a source control system or version control system that stores each version of an artifact, such as a source code file, and tracks the changes or differences between the different versions. Repositories managed by source control systems are distributed so that each user of the repository has a working copy of the repository. The source control system coordinates the distribution of the changes made to the contents of the repository to the different users. When the user is finished with editing the source code file, the user performs a commit which checks in the modified version of the source code file back into the shared source code repository. A pull request informs others that changes have been made to one or more file which were pushed or committed back into the repository. The term pull request is a well-known term of art associated with GitHub. The reviews may be presented in any visual manner (block 614). In one aspect, a review may be placed inline in close proximity to the affected source code snippet as shown in FIG. 2B. However, the subject matter disclosed is not limited to a particular manner to display a recommendation and other ways of displaying the review and the affected source code snippet may be used.”—see at least 0024, 0025, 0063).
It is to note that Gupta does not explicitly disclose; however, Li, in an analogous art, discloses transform the proposed source code change into a code diff hunk that represents code edits to the source code program as such,
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk. – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Li’s teaching into Gupta’s teaching for
further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2).
It is further note that while modified Gupta with Li discloses perform a search to generate a code review comment for the proposed source code change, wherein the search invokes a neural model given the proposed source code change and the at least one augmented code review comment, to generate a probability distribution, at each time step, that identifies a next token to append to a respective partial sequence, and then outputs the select partial sequence as the code review comment for the proposed source code change --(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see Gupta, at least 0062, Fig. 6 and associated text), but the modified does not explicitly disclose; however, Clement, in an analogous art, discloses the perform a beam search, wherein the beam search generates partial sequences of tokens iteratively at each of a plurality of timesteps, wherein the beam search invokes a neural model given , to generate a probability distribution, at each time step, that identifies a next token to append to a respective partial sequence, wherein the beam search ends when a termination token appears as the most probable next token for a select partial sequence and then outputs the select partial sequence -- (e.g., using a neural transformer model with attention to generate candidate sequences to complete a searching candidate via inferencing such as beam search with probability distribution as such,
The use of the neural transformer model in an inference system as in the beam search
uses the probability distribution generated by the neural transformer model to identify the top k subtokens likely to be the next subtoken in a candidate sequence. The beam search expands the search by instantiating new partial sequences using each of the selected subtokens identified by the neural transformer model's probability distribution. The search continues generating new partial sequences from the top k subtokens identified by the output distributions from the neural transformer model until the search ends. The search may end when the end-of-method subtoken appears as the most probable next subtoken.—see Clement at least 0004-005, and 0075-0079).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated beam search with probability distribution of Clement into deep learning model of modified teaching of Gupta with Li for
further optimize the generate review comments by speeding up and avoid error as seen in Clement (e.g., 0002-0004).
As to claim 2, modified Gupta with Li and Clement discloses comprises instructions to perform actions that: associate each augmented code review comment of the database with one or more encodings, wherein each encoding is generated by a neural encoder – (e.g., encode for input source code and encode in repository – see Gupta at least paragraphs 0017, 0052, 0059, 0061-0062).
As to claim 3, modified Gupta with Li and Clement discloses, wherein the program comprises instructions to perform actions that: partition each code diff hunk into a plurality of chunks; generate an encoding for each chunk of the plurality of chunks; and associate the encoding of each chunk with a select code review comment – (E.g., incorporated Li’s teaching
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk.” – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text,
into modified teaching of Gupta with Clement for further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2)).
As to claim 4, modified Gupta with Li and Clement discloses wherein the program comprises instructions to perform actions that: generate a plurality of training samples to train the neural encoder to generate a select encoding that relates select code edits to a select code review comment – (E.g., incorporated Li’s teaching--
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3, Figures 1 & 2, Fig. 4, and associated text.
into modified teaching of Gupta with Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 5, it is to note that modified Gupta with Clement does not discloses, but Li, in an analogous art discloses wherein the plurality of training samples comprises a denoising code diff pretraining dataset, wherein the denoising code diff pretraining dataset comprises a plurality of denoising code diff samples, wherein a denoising code diff sample comprises masked out lines of source code of a code diff hunk -- using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of thistask, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a better representation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3, Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 6, it is to note that modified Gupta with Clement does not discloses, but Li, in an analogous art discloses wherein the plurality of training samples comprises a denoising review comment pretraining dataset, wherein the denoising review comment pretraining dataset comprises a plurality of denoising review comment samples, wherein a denoising review comment sample comprises masked out tokens of a code review sample hunk -- using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment… The model outputs consist of two components: token representations from the encoder and generated token sequence from the decoder. For classification tasks, the representation of [𝐶𝐿𝑆] token
is used to generate the predictions 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of this task, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a better representation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3, Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 7, it is to note that modified Gupta with Clement does not discloses, but Li, in an analogous art discloses wherein the plurality of training samples comprises a diff tag prediction pretraining dataset, wherein the diff tag prediction pretraining dataset comprises a plurality of diff tag prediction samples, wherein a diff tag prediction sample comprises masked out diff characters in a code diff hunk-- using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment… The model outputs consist of two components: token representations from the encoder and generated token sequence from the decoder. For classification tasks, the representation of [𝐶𝐿𝑆] token
is used to generate the predictions 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of this task, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a betterrepresentation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3 , Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 8, it is to note that while modified Gupta with Li discloses wherein the deep learning model includes a neural transformer model -- (e.g., deep learning model 110 – see Gupta, at least 0022-0023, 0046-0048, 0059, 0061, Fig. 4, and associated text) but does not explicitly disclose that the deep learning model is with cross-chunk attention. However, Clement, in an analogous art, discloses the deep learning model includes a neural transformer model with cross-attention— (e.g., neural transformer model based on encoder and decoder blocks with attention—see Clement, at least 0009, 0022, 0026, 0031-0036, 0039-0042, 0108).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Clement’s teaching into the deep learning model of modified Gupta with Li for further optimize the generate review comments via categorizing as seen in Clement (e.g.,0005-0006).
As to claim 9, Gupta discloses a computer-implemented method, comprising:
retrieving, from a pull request of a version-controlled source code repository, a proposed source code change to a source code program– (e.g., “When a new pull request is received in a shared source code repository, it may include new source code file or modifications (proposed change) to existing source code files in the repository – see at least 0005, 0034-0035,0052, Fig. 4, and associated text);
retrieving an augmented code review comment for the proposed source code change of the source code program from a collection of code review comments, wherein the retrieved augmented code review comment is selected based on having code edits similar to the code edits of the proposed source code change– (e.g., “The knowledge base is searched for code reviews having closely matching source code, lower context and upper context as the input code snippet (block 606)” -- see at least 0044-0045, 0061, Fig. 4, Fig. 6, and associated text);
generating a code review comment for the proposed source code change, wherein the generation of the code review comment comprises a search invokes a neural model given the proposed source code change and the augmented code review comment, to generate a probability distribution, that identifies the most probable next token for a select partial sequence which is then output as the code review comment for the proposed source code change --(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see at least 0062, Fig. 6 and associated text); and
outputting the code review comment in the version-controlled source code repository—(e.g., The shared source code repository 106 may be configured as a source control system or version control system that stores each version of an artifact, such as a source code file, and tracks the changes or differences between the different versions. Repositories managed by source control systems are distributed so that each user of the repository has a working copy of the repository. The source control system coordinates the distribution of the changes made to the contents of the repository to the different users. When the user is finished with editing the source code file, the user performs a commit which checks in the modified version of the source code file back into the shared source code repository. A pull request informs others that changes have been made to one or more file which were pushed or committed back into the repository. The term pull request is a well-known term of art associated with GitHub. The reviews may be presented in any visual manner (block 614). In one aspect, a review may be placed inline in close proximity to the affected source code snippet as shown in FIG. 2B. However, the subject matter disclosed is not limited to a particular manner to display a recommendation and other ways of displaying the review and the affected source code snippet may be used.”—see at least 0024, 0025, 0063).
It is to note that Gupta does not explicitly disclose; however, Li, in an analogous art, transforming the proposed source code change into a code diff hunk that represents code edits to the source code program as such,
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk. – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Li’s teaching into Gupta’s teaching for
further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2).
It is further note that while modified Gupta with Li discloses generating a code review comment for the proposed source code change, wherein the generation of the code review comment comprises a search invokes a neural model given the proposed source code change and the augmented code review comment, to generate a probability distribution, that identifies the most probable next token for a select partial sequence which is then output as the code review comment for the proposed source code change--(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see Grupata, at least 0062, Fig. 6 and associated text) ), but the modified does not explicitly disclose; however, Clement, in an analogous art, discloses the perform a beam search, wherein the beam search generates partial sequences of tokens iteratively at each of a plurality of timesteps, wherein the beam search invokes a neural model given, to generate a probability distribution, at each time step, that identifies a next token to append to a respective partial sequence, wherein the beam search ends when a termination token appears as the most probable next token for a select partial sequence and then outputs the select partial sequence -- (e.g., using a neural transformer model with attention to generate candidate sequences to complete a searching candidate via inferencing such as beam search with probability distribution as such,
The use of the neural transformer model in an inference system as in the beam search
uses the probability distribution generated by the neural transformer model to identify the top k subtokens likely to be the next subtoken in a candidate sequence. The beam search expands the search by instantiating new partial sequences using each of the selected subtokens identified by the neural transformer model's probability distribution. The search continues generating new partial sequences from the top k subtokens identified by the output distributions from the neural transformer model until the search ends. The search may end when the end-of-method subtoken appears as the most probable next subtoken.—see Clement at least 0004-005, and 0075-0079).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated beam search with probability distribution of Clement into deep learning model of modified teaching of Gupta with Li for
further optimize the generate review comments by speeding up and avoid error as seen in Clement (e.g., 0002-0004).
As to claim 10, modified Gupta with Li and Clement discloses further comprising: associating each code review comment of the collection with one or more encodings– (e.g., encode for input source code and encode in repository – see Gupta at least paragraphs 0017, 0052, 0059, 0061-0062).
As to claim 11, modified Gupta with Li and Clement discloses further comprising: partitioning each code diff hunk into a plurality of chunks; generating an encoding for each chunk of the plurality of chunks; and associating the encoding of each chunk of the plurality of chunks with a select code review comment of the collection having a similar encoding – (E.g., incorporated Li’s teaching
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk.” – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text,
into modified teaching of Gupta with Clement for further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2)).
As to claim 12, modified Gupta with Li and Clement discloses further comprising: training a neural encoder to generate the encodings for each chunk of the plurality of chunks from a training dataset comprising a plurality of denoising code diff hunks--using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of thistask, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a better representation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3 , Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 13, modified Gupta with Li and Clement discloses further comprising: training a neural encoder to generate the encodings for each chunk of the plurality of chunks from a training dataset comprising a plurality of denoising review comment samples using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment… The model outputs consist of two components: token representations from the encoder and generated token sequence from the decoder. For classification tasks, the representation of [𝐶𝐿𝑆] token
is used to generate the predictions 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of this task, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a better representation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3, Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 14, modified Gupta with Li and Clement discloses further comprising: training a neural encoder to generate the encodings for each chunk of the plurality of chunks from a training dataset comprising diff tag prediction samples-- using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments as such,
To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
4 CODEREVIEWER In this section, we describe our CodeReviewer model in detail, including the model architecture, the input-output representations of the model, and the pre-training tasks designed for code review. We develop CodeReviewer based on Transformer [42] and design
four pre-training tasks related to the code reviewprocess to improve the model’s capacity for automating code review activities.4.2 Input-Output Representations CodeReviewer takes different inputs and outputs for different tasks. For code understanding tasks or comment generation tasks, the model takes code diff as input. For the code refinement task, the model takes as input both the original source code and the review comment… The model outputs consist of two components: token representations from the encoder and generated token sequence from the decoder. For classification tasks, the representation of [𝐶𝐿𝑆] token
is used to generate the predictions 4.3 Pre-training Tasks The key challenge of automating code review activities is to understand code changes and capture the relationship between code changes and corresponding review comments. Therefore, we design four pre-training tasks to improve the abilities of CodeReviewer. 4.3.1 Diff Tag Prediction. As mentioned in Section 2.5, diff is a special format containing rich information in code changes. Compared with encoding both the original and new version code, the diff format prevents duplicates of unchanged lines. Thus, learning code diff as a special format of source code is critical for the model in the code review scenario 4.3.2 Denoising Objective. Denoising objective is an unsupervised pre-training objective introduced by Lewis et al. [24] to acquire a general understanding of a corpus. The original denoising objective randomly masks spans in the input sentence with a corrupted rate of 15% and predicts these spans. By learning to predict masked spans, the model gains general knowledge about the corpus distribution.To better understand code diff and review comments, we design two denoising objectives for CodeReviewer: denoising code diff(DCD) and denoising review comment (DRC). In the DCD task, we randomly select 15% code lines and mask them. We corrupt inputson line-level but not span-level in order to keep the integrity format of code diff. It’s worth noting that to reduce the difficulty of this task, the line tags ([𝐴𝐷𝐷], [𝐷𝐸𝐿] and [𝐾𝐸𝐸𝑃]) are preserved to inform the model whether a line is updated or removed. The DCD task aims to help the model learn the distribution of code changes, augmenting both the encoder and decoder. Encoder producing a betterrepresentation of code changes benefits both understanding and generation tasks. Pre-training the decoder on DCD helps the model generate better source code in the code refinement task.In DRC task, the model is given a corrupted review comment as input and is required to recover the masked spans. Specifically, we randomly mask spans with 20% corrupted rate and train the decoder to generate them. Training with the DRC task is expected to benefit comment-related tasks. We describe the loss of DCD and DRC tasks as: …are the span sequence of code diff and review comment generated so far.”– see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, page 1039: sections, 4:4.1-4.3.3 , Figures 1 & 2, Fig. 4, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated using pre-train CodeReviewer of encoder-decoder transformer model having four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation of Li into deep learning model of modified teaching of Gupta and Clement for further optimize performing of the generate review comments by speeding up process within large scale dataset collection as seen in Li (e.g., page 1045, section 9).
As to claim 15, it is to note that while modified Gupta with Li discloses wherein the deep learning model includes a neural model -- (e.g., deep learning model 110 – see Gupta, at least 0022-0023, 0046-0048, 0059, 0061, Fig. 4, and associated text) but does not explicitly disclose that the deep learning model is with cross-chunk attention layer. However, Clement, in an analogous art, discloses the deep learning model includes a neural transformer model with cross-chunk attention layer — (e.g., neural transformer model based on encoder and decoder blocks with attention—see Clement, at least 0009, 0022, 0026, 0031-0036, 0039-0042, 0108).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Clement’s teaching into the deep learning model of modified Gupta with Li for further optimize the generate review comments via categorizing as seen in Clement (e.g.,0005-0006).
As to claim 16, Gupta discloses a hardware storage device (e.g., a storage device 708 – see at least 0068, Fig. 7, and associated text) having stored thereon computer executable instructions that are structured to be executable by a processor of a computing device to thereby cause the computing device to perform actions that:
access a proposed source code change to a source code program from a pull request of a version-controlled source code repository– (e.g., “When a new pull request is received in a shared source code repository, it may include new source code file or modifications (proposed change) to existing source code files in the repository – see at least 0005, 0034-0035,0052, Fig. 4, and associated text);
access a database of augmented code review comments, wherein each augmented code review comment of the database is indexed by one or more encodings, wherein an encoding represents code edits associated with a respective augmented code review comment– (e.g., pull/extract data from the shared source code repository 106, which include comments etc. of the source code file such as snippet etc. – see at least 0005, 0024-0026, 0034-0035, 0052, Fig. 4, and associated text);
retrieve at least one code augmented review comment for the proposed source code change from the database, wherein the at least one augmented code review comment is associated with code edits similar to the code edits of the proposed source code change – (e.g., “The knowledge base is searched for code reviews having closely matching source code, lower context and upper context as the input code snippet (block 606)” -- see at least 0044-0045, 0061, Fig. 4, Fig. 6, and associated text);
search for a code review comment for the proposed source code change, wherein the search generates partial sequences of tokens iteratively at each of a plurality of timesteps, wherein the search invokes a neural model given the proposed source code change and the at least one augmented code review comment, to generate a probability distribution, at each time step, that identifies the select partial sequence is output as the code review comment for the proposed source code change--(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see at least 0062, Fig. 6 and associated text); and
output the code review comment to the version-controlled source code repository – (e.g., The shared source code repository 106 may be configured as a source control system or version control system that stores each version of an artifact, such as a source code file, and tracks the changes or differences between the different versions. Repositories managed by source control systems are distributed so that each user of the repository has a working copy of the repository. The source control system coordinates the distribution of the changes made to the contents of the repository to the different users. When the user is finished with editing the source code file, the user performs a commit which checks in the modified version of the source code file back into the shared source code repository. A pull request informs others that changes have been made to one or more file which were pushed or committed back into the repository. The term pull request is a well-known term of art associated with GitHub. The reviews may be presented in any visual manner (block 614). In one aspect, a review may be placed inline in close proximity to the affected source code snippet as shown in FIG. 2B. However, the subject matter disclosed is not limited to a particular manner to display a recommendation and other ways of displaying the review and the affected source code snippet may be used.”—see at least 0024, 0025, 0063).
It is to note that Gupta does not explicitly disclose; however, Li, in an analogous art, discloses transform the proposed source code change into a code diff hunk that represents code edits to the source code program as such,
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk. – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text.
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Li’s teaching into Gupta’s teaching for
further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2).
It is further note that while modified Gupta with Li discloses search for a code review comment for the proposed source code change, wherein the search generates partial sequences of tokens iteratively at each of a plurality of timesteps, wherein the search invokes a neural model given the proposed source code change and the at least one augmented code review comment, to generate a probability distribution, at each time step, that identifies the select partial sequence is output as the code review comment for the proposed source code change--(e.g., “The encoded representations of the code snippet, upper context, lower context, and review are then combined into a single feature vector (block 610) which is then input into the deep learning model (block 612). The deep learning model generates a probability for each review indicating the likelihood of the relevance of the review to the code snippet (block 612). Reviews are then selected based on the probability score and a target objective (block 614).” – see at least 0062, Fig. 6 and associated text)), but the modified does not explicitly disclose; however, Clement, in an analogous art, discloses the search is the beam search, that identifies a next token to append to a respective partial sequence, wherein the beam search ends when an end-of-sequence token is predicted as the next token for a select partial sequence, wherein the select partial sequence is output as the code review comment for the proposed source code change-- (e.g., using a neural transformer model with attention to generate candidate sequences to complete a searching candidate via inferencing such as beam search with probability distribution as such,
The use of the neural transformer model in an inference system as in the beam search
uses the probability distribution generated by the neural transformer model to identify the top k subtokens likely to be the next subtoken in a candidate sequence. The beam search expands the search by instantiating new partial sequences using each of the selected subtokens identified by the neural transformer model's probability distribution. The search continues generating new partial sequences from the top k subtokens identified by the output distributions from the neural transformer model until the search ends. The search may end when the end-of-method subtoken appears as the most probable next subtoken.—see Clement at least 0004-005, and 0075-0079).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated beam search with probability distribution of Clement into deep learning model of modified teaching of Gupta with Li for
further optimize the generate review comments by speeding up and avoid error as seen in Clement (e.g., 0002-0004).
As to claim 17, modified Gupta with Li and Clement discloses having stored thereon computer executable instructions that are structured to be executable by a processor of a computing device to thereby cause the computing device to perform actions that: access an encoder, trained on code diff hunks and code review comments, to generate the encodings of the indices of the augmented code review comment database – (E.g., incorporated Li’s teaching
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk.” – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text,
into modified teaching of Gupta with Clement for further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2)).
As to claim 18, modified Gupta with Li and Clement discloses wherein the code diff hunk comprises source code surrounding the changed code– (E.g., incorporated Li’s teaching
“To tackle the problems, we pre-train CodeReviewer, an encoderdecoder transformer model. Different from Tufano et al. [40]’s work, CodeReviewer is pre-trained on a large dataset in code review scenario, consisting of code diff hunks and code review comments. We propose four pre-training tasks, including diff tag prediction, denoising code diff, denoising review comment, and review comment generation to make CodeReviewer better understand code diffs and generate review comments. Figure 1 shows the overview of the workflow of our CodeReviewer. To make CodeReviewer more suitable for the code review process, we build a large-scale dataset of code changes and corresponding review comments.
All three tasks are related to source code or code changes. In the code review process, there are usually multiple related files and functions [19]. A source code file or a function/method is too large to process, because there may be multiple review comments and code revisions spreading across a file or function/method. Instead, we define the inputs of the three tasks at diff hunk level. In pull requests, the original version and revised version of code are shown in a special format: diff (Figure 2). The diff file is generated by comparing two files before and after the change. The diff tool finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Specifically, a diff hunk is a sequence of source code lines surrounded by a few unchanged lines. Diff hunk includes the lines deleted from the original file and added to the new file. The diff format is frequently used by programmers to show the changes in the code clearly. Moreover, the diff format is an efficient representation for code changes because the unchanged lines occur only once, and the changes are aligned with “-” and “+” tags at the begging of each line. In the first two tasks, we formulate the input as a diff hunk representing the code change. In the code refinement task, we extract the input lines (𝐶1) and output lines (𝐶2) from the revision diff hunk.” – see Li, at least page 1036, left column, paragraphs 3-4, sections 2.1, 2.5, 4.2, Figures 1 & 2, and associated text,
into modified teaching of Gupta with Clement for further optimize the generate review comments by making it easier for programmer/developer to show changes made in code clearly as seen in Li (e.g., section 2.5, Figures 1 and 2)).
As to claim 19, it is to note that while modified Gupta with Li discloses wherein the neural model is a neural transformer model configured with an encoder block coupled to a decoder block -- (e.g., deep learning model 110 – see Gupta, at least 0022-0023, 0046-0048, 0059, 0061, Fig. 4, and associated text) but does not explicitly disclose that the deep learning model is with cross-chunk attention. However, Clement, in an analogous art, discloses wherein the decode block comprises a chunk-cross attention layer receiving output from the encoder block — (e.g., neural transformer model based on encoder and decoder blocks with attention—see Clement, at least 0009, 0022, 0026, 0031-0036, 0039-0042, 0108).
Thus, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have incorporated Clement’s teaching into the deep learning model of modified Gupta with Li for further optimize the generate review comments via categorizing as seen in Clement (e.g.,0005-0006).
As to claim 20, modified Gupta with Li and Clement discloses wherein the encoder block comprises a cross-attention layer receiving the at least one augmented code review comment – (E.g., incorporated Clement’s teaching such as neural transformer model based on encoder and decoder blocks with attention—see Clement, at least 0009, 0022, 0026, 0031-0036, 0039-0042, 0108, into the deep learning model of modified Gupta with Li for further optimize the generate review comments via categorizing as seen in Clement (e.g.,0005-0006)).
Conclusion
9. The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure.
Svyatkovskiy et al. (US-20210034335-A1) disclosed multi-lingual line-of-code completion system is based on a neural transformer model including multiple decoder blocks comprises a multi-head self-attention layer coupled to a multi-layer one-dimensional convolutional neural network and a beam search is used to generate candidate sequence.
Van Zijst et al. (US-9430229-B1) disclosed merge previewing in a version control system having a meta-diff, or the diff between merges, is analyzed for comments on added lines; for each portion of the meta-diff occurring before the line that was commented on, the process adjusts or drifts the comment's position by a net total of the number of lines that were added or removed in that portion or hunk of the code.
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET).
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.
/MARINA LEE/Primary Examiner, Art Unit 2192
