DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
(Submitted 3/23/2026)
In regard to 101 rejections
- The examiner noted the arguments of the applicant on Page 9 through 13. After carefully reviewing, the examiner submits that applicant has overcome the 101 mental steps as a result of the hyperparameters supporting the code analyzer to select the source code signals.
In Conclusion, the examiner hereby WITHDRAWS the 101 rejections on claims 1,9 and 16 and on all dependent claims 2-8, 10-15 and 17. The examiner notes that the applicant has CANCELLED the claims 6, and 18-20 and has added four new clams 21-24.
In regard to 103 rejections
- The applicant on Page 14 argues that the amendments to claim 1 (claim 9 and 16) is not taught by the current references.
Examiner’s Response:
The examiner submits that per the specification [0110 ]“ generating the amplified code comprises performing a refactoring”. Generating amplified code can involve refactoring, rewriting, and automated rewriting and automated rewriting (or automated refactoring) uses AI or code transformation tools to perform these changes automatically. In this context, any tool or device for refactoring can acts as a code re-writer. Further, the examiner submits that the applicant’s argument is now shifted toward the support of hyperparameters as such the arguments are MOOT in view of new grounds of rejection using new references “ Colleen”,“ Tufano”, and “Svyat” to teach independent claims.
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 1-5, 7-17, and 21-24 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.
For claims 1, 9 and 16, the applicant recites “adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals” and “more clear” is a relative term. The specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
As a result of claims 1, 9 and 16 rejections, the dependent claims 2-5, 7-8, 21-24, 17, and 10-15 are also rejected under 112(b).
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, 4-5, 9, 12-13 , 16, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Kimball Colleen (hereinafter Colleen) US 11042369 B1, in view of Michele Tufano (hereinafter Tufano) On Learning Meaningful Code Changes via Neural Machine Translation, 2019 IEEE/ACM 41 st International Conference on Software Engineering (ICSE) and further in view of Alexey Svyatkovsky et al. (hereinafter Svyat) US 2021/0034335 A1.
In regard to claim 1: (Currently Amended)
Colleen discloses in:
- A computer-implemented method, comprising: identifying via an automated code analyzer one or more source code signals in a source code;
[Abstract]:
Disclosed herein are embodiments of systems, methods, and products for modernizing and optimizing legacy software. A computing device may perform an automated runtime performance profiling process. The performance profiler may automatically profile the legacy software at runtime, monitor the memory usage and module activities of the legacy software,
[Abstract]:
The computing device may further perform a source code analysis and refactoring process.
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
- generating, via an automated code-rewriter, an amplified code based on the one or more identified source code signals and the source code,
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
[Col 16, lines 63-67]:
The computing device may train an artificial intelligence ( AI ) model 422 to determine /
Update the rules for refactoring " bloated ” ) code and the rules for identification 426. The
computing device may monitor and analyze the user selections of refactoring options for
certain identified code violations.
[Col 17, lines 1-22]:
The computing device may train the artificial intelligence model 422 by learning from the user selections of refactor ing options and/or user manual refactoring operations for different code violations. For example, if the user consistently selects "do nothing" for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified. In another example, if the user consistently selects a particular refactoring option for certain types of code violations, the AI 10 model 422 may update the rules for refactoring 424 accordingly, such that those types of code violations may be automatically refactored instead of refactored in response to user selection. In yet another example, if the user does not select any of the refactoring options provided by the computing device and instead performs manual refactoring for certain types of code violations, the AI model 422 may update the rules for refactoring 424 by learning from the user's manual refactoring operations. For example, the AI model 422 may include the user's manual refactoring operations as a new automatic refactoring option for those types of code violations.
PNG
media_image1.png
642
926
media_image1.png
Greyscale
[Col 18, lines 25-50]:
FIG. 4 illustrates the source code analysis and refactoring process 400, according to an embodiment. The user may input user configuration and select performance test to target 404 for legacy software through the graphical user interface 406 displayed on the computing device 402. The computing device may perform automated runtime performance profiling process as described in FIG. 3. Specifically, the computing device may create, configure, and launch profiling tests based on the user configuration to monitor timing and memory data. The computing device may process the monitored raw status data and save the processed data into the database 408. The processed data may comprise the analysis results of the automated runtime performance profiling. Based on the analysis results of the runtime performance profiling, the computing device may identify the inefficient functions 410 that scale poorly and cause the poor performance in the targeted performance test. After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. The user may implement the refactoring suggestions manually 414 to optimize the inefficient functions. Alternatively, the computing device may implement the refactoring suggestions automatically 428. (BRI: AI engine 422 determines the update rules for refactoring (hyper-parameters) and these rules are used in automated refracting (428) which represents automatic code rewriter. Per the specification [0110], the refactoring is an example of amplified code]
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
- selecting, via a hyperparameter optimization optimizer, one or more hyperparameters so
that the automated code-rewriter controls
[Col 15, lines 41-46]:
After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. [BRI: refactoring is the
“hyperparameter”
Colleen does not explicitly disclose:
- wherein the amplified code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals,
- and wherein the amplified code is in a same programming language that the source code is in;
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
However, Tufano discloses:
- wherein the amplified code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals,
[III, Page 31]: 5) Readability:
Readable code is easier to understand and maintain
[III, Page 31]: 5) Readability:
We found several types of code transformations learned by the model and targeting the improvement of code readability.
[II D, Page 28]:
we describe the NMT models we use to learn code transformations. In particular, we train these models to translate the abstracted code amb in ama, effectively simulating the code change performed in the PR by developers.
II C, Page 27]: We also filter out those method pairs such that amb = ama, meaning the abstracted code before and after the PR appear the same
IV C, Page 30]:
Refactoring We grouped in the refactoring sub-tree, all code transformations that modify the internal structure of the system by improving one or more of its non-functional attributes (e.g., readability) without changing the system’s external behavior. We categorized transformations into five sub-categories
[IV, Page 29]:
Table III reports the perfect predictions (i.e., successfully predicted code transformations) by the NMT models, in terms of raw numbers and percentages of the test sets. When we allow the models to generate only a single translation
[1, Page 26]:
We demonstrate a quantitative and qualitative evaluation of the NMT model. For the quantitative analysis, we assessed its ability in modifying the project’s code exactly as done by developers during real PRs. This means that we compare, for the same code components, the output of the manually implemented changes and of the output of the NMT model. The qualitative analysis aims instead at distilling a taxonomy of meaningful code transformations that the model was able to automatically learn from the training data- see Fig. 1.
[BRI: code transformations that improve internal structure without changing external behavior do represent functional equivalence between the source code and its abstract/refactored form ]
- and wherein the amplified code is in a same programming language that the source code is in;
[V, Page 33]:
External validity. We experimented with the NMT model on data related to Java programs only. However, the learning process is language-independent and the whole infrastructure can be instantiated for different programming languages by replacing the lexer, parser and AST differencing tools.
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
[1, Page 25]:
GitHub alone hosted 100M repositories, with over 200M merged pull requests (PRs)
[BRI: Codebase Collaboration: NMT projects often involves a pull request that allows a developer to push changes (e.g., a new training script, a bug fix, or a model optimization) from their local branch to a shared repository (e.g., GitHub)]
[II, Page 28]:
As the name suggests, this model consists of two major components: an RNN Encoder, which encodes a sequence of tokens x into a vector representation, and an RNN Decoder, which decodes the representation into another sequence of tokens y. During training, the model learns a conditional distribution over a (output) sequence conditioned on another (input) sequence of terms: P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
), where the lengths n and m may differ. In our setting, given the sequence representing the abstract code before the PR x =
a
m
b
= (
x
1
,
,
…
,
x
n
) and a corresponding target sequence representing the abstract code after the PR y =
a
m
a
= (
y
1
,
,
…
,
y
m
) the model is trained to learn the conditional distribution: P (
a
m
a
|
a
m
b
) = P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
) , where
x
i
and
y
j
abstracted source tokens: Java keywords, separators, IDs, and frequent identifiers and literals. The Encoder takes as input a sequence x =(
x
1
,
,
…
,
x
n
) and produces a sequence of states h =(
h
1
,
,
…
,
h
n
). In particular, we adopt a bi-directional RNN Encoder [30], which is formed by a backward and a forward RNN. The RNNs process the sentence both from left-to-right and right-to-left, and are able to create sentence representations taking into account both past and future inputs [32]. The RNN Decoder predicts the probability of a target sequence y =(
y
1
,
,
…
,
y
m
)
) given h. Specifically, the probability of each output token
y
i
is computed based on: (i) the recurrent state si in the Decoder; (ii) the previous i−1 tokens (
y
1
,
,
…
,
y
i
-
1
)
and (iii) a context vector
c
i
. This vector
c
i
i
s
also called attention vector, is computed as a weighted average of the states in h:
∑
i
=
1
n
a
i
t
h
t
where the weights
a
i
t
allow the model to pay more attention to different parts of the input sequence, when predicting the token
y
i
.
[II C, Page 27]:
The source code of a method is fed to a lexer, built on top of ANTLR [56], which tokenizes the raw code into a stream of tokens. This stream of tokens is then fed into a Java parser, which discerns the role of each identifier (i.e., whether it represents a variable, method, or type name) and the type of a literal.
[BRI: Identifiers are indeed categories of source code tokens (source code signals]
developers are not limited to a finite dictionary of words to represent source code, rather, they can generate a potentially infinite amount of novel identifiers and literals. Table I shows the number of unique tokens identified in the source code of the three datasets.
PNG
media_image2.png
271
565
media_image2.png
Greyscale
[V, Page 33]:
The performance of the NMT model might be influenced by the hyperparameter configuration we adopted.
[II D, Page 28]:
3) Hyperparameter Search: We tested ten configurations of the encoder-decoder architecture with different combinations of RNN Cells (LSTM [45] and GRU [33]), number of layers (1, 2, 4) and units (256, 512) for the encoder/decoder, and the embedding size (256, 512). Bucketing and padding was used to deal with the variable length of the sequences. We trained the models for a maximum of 60k epochs, and selected the model’s checkpoint before over-fitting the training data. To guide the selection of the best configuration, we used the loss function computed on the validation set (not on the test set), while the results are computed on the test set
[II, Page 28]:
Encoder and Decoder are trained jointly by minimizing the negative log likelihood of the target tokens, using stochastic gradient descent.
[II, Page 28]:
Given a dataset, we train different configurations of the Encoder-Decoder models on
[II, Page 29]:
the training set, then use the validation set to select the best performing configuration of the model. We then evaluate the validity of the model with the unseen instances of the test set
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
Colleen and Tufano does not explicitly discloses:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data; for training of the machine learning model, determining a loss of machine learning model using a loss function
However, Svyat discloses in:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data; for training of the machine learning model, determining a loss of machine learning model using a loss function
[0006]:
Each source code program in the training dataset does need not be written in the same programming language. The training dataset may be composed of numerous source code programs, each of which may be written in a different programming language. Each source code program in the training dataset is encoded into a sequence composed of tokens and/or subtokens. The frequently-used elements in a programming language are encoded into tokens and the less frequently-occurring elements are encoded into combinations of characters referred to as subtokens. This reduces the need to store a large vocabulary and provides better accuracy for out-of-vocabulary tokens.
[0034]:
The source code extraction component 108 extracts selected source code programs 110 from the source code repository 106 to obtain the training and validation datasets.
[0025] :
A transformer may act as an encoder or a decoder where the encoder maps an input sequence of symbol representations to a sequence of continuous representations and the decoder generates an output sequence of symbols from the sequence of continuous representations. The encoder-decoder architecture is not a good fit for conditional code generation or code completion tasks and is better suited for machine translation and patch generation type tasks. A variant of the transformer model is used that is composed of decoder blocks having masked self-attention and convolutional layers.
[0038]:
For example, the following line of source code:
loss= tf. reduce_ sum (tf. square (linear_model−y))
[0039]:
can be partitioned into the following sequence of tokens/ subtokens, each of which are separated by the character “|”:
PNG
media_image3.png
37
330
media_image3.png
Greyscale
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined.
[0053]:
Neural networks are trained iteratively, making multiple passes over the training dataset before converging to a minimum. An epoch represents the entire training dataset passed forwards and backwards through the neural network once. Since the training dataset is very large, it is partitioned into smaller batches. The training is iterative and the entire dataset is passed through the neural network in multiple iterations. Each training iteration includes forward propagation, loss calculation, backpropagation steps followed by updating the weights.
[0020]:
A line of source code may consist of various elements (e.g., keywords, delimiters, variables, methods, constants, operators, etc.) that are combined in a particular order in accordance with the grammar of the underlying programming language [BRI: a line of code in the underlying language is based on the same language]
[0123]:
The system tracks the sequence of characters entered into the line of the source code program by obtaining a sequence of tokens/subtokens representing a current context of the line of code and finding token/subtoken embedding vectors and positional embedding vectors for the sequence of tokens/subtokens
[BRI: the context of syntactic tree for preserving the functional equivalence [0036] and generating embedding vector of the tokens form the enhanced (amplified) representation of the code more useful for machine learning analysis]
[0124]:
The system includes instructions that input the token/subtoken embedding vectors and positional embedding vectors into the neural transformer model. The neural transformer model generates a probability distribution for the tokens/subtokens of a model vocabulary.
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code. (BRI: Perhaps known to the POSITA that an enriched source code representation is one that goes beyond the raw text of the code and incorporates additional contextual or structural information to make it more meaningful for analysis or learning to extract bug reports, and design patterns to improve tasks like code classification. However, perhaps also known to the POSITA that the “amplified code” is less common in formal software engineering literature, but in related domains it can mean increasing the amount or impact of information to make it more useful. A sequence of token representations — including token embeddings and positional embeddings can indeed provide a richer, more context-aware representation of source code than raw text alone, but whether it “enriches” the code depends on how it is used. A sequence of token embeddings plus positional embeddings provides a contextual, structure-aware representation of source code, which can be “enriched” into a more meaningful form when processed by a Transformer or similar architecture].
[0033]:
The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0094]:
the source code editor 130 performs a background parsing process that monitors the characters input into the source coe editor and continuously parses the source code to update the concrete syntax tree representing the source code of the current line of code (block 602).
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system. Software programs can include source code files, created in one or more source code languages (e.g., Visual Basic, Visual J#, C++. C#, J#, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk and the like). The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof.
[BRI: JAV, and Python are managed code environment]
[0115]:
one or more source code program files 952, an IDE 954 that may include a source code editor 956, a user interface 958, a compilation component 960, a code completion component 962 and a neural transformer model 964 and other applications and data 966.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system
[0113]:
The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof.
[0114]:
A user can create and/or edit the source code program files 952 according to known software programming techniques and the specific logical and syntactical rules associated with a particular source language via a user interface 958 and a source code editor 956 in the IDE 954.
[BRI:A syntax analyzer is a subset of automated source code analyzers and is a first step in parsing code, but automated source code analyzers can include syntax analysis plus semantic, style, and policy checks. In this context, the compilation component is the automated code analyzer. A compilation component that generates data structures for syntactic and semantic representation is conceptually similar to what an automated code analyzer does internally. Modern AI-assisted code completion components often integrate automated code analysis to improve suggestion accuracy, context awareness, and code quality]
[0054]:
The neural network has multiple layers so that more detailed relationships within the data are learned as well as how the features interact with each other on a non-linear level. The model architecture, training procedure, data normalization and vocabulary encoding procedures are hyperparameters that are tailored to meet a particular objective. The values of the hyperparameters influence how the parameters are learned.
[0055]:
In one aspect, the hyperparameters may include the following: (1) token/subtoken and position embedding layers of dimensions: 30000×768, and 1024×768 respectively; (2) twelve transformer blocks, with each block consisting of two convolutions, masked self-attention and layer normalization layers; (3) for the training procedure: auto-regressive, with a cross-entropy loss optimization objective; the sequence length is 1024 tokens/subtokens; the mini-batch size is 8; the gradient accumulation steps for each weight update is 8; the Adam stochastic optimization procedure is used to train the neural network; and the learning rate is 0.0001; (4) the data normalization procedure: normalize all string and numerical literals, keeping the ten most frequent;
[0033]:
FIG. 1 illustrates a block diagram of an exemplary code completion system 100 in which various aspects of the invention may be practiced. As shown in FIG. 1, system 100 includes a training phase 102 which trains a transformer model 122 and an inference phase 104 that utilizes the transformer model 122 in a line-of-code completion system. The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0070]:
A beam search uses a breadth-first search to build a search tree. The search tree is composed of nodes at one or more inference levels. Each node represents a probability distribution generated by the neural transformer model for the tokens/subtokens in the model vocabulary. At each level, only the top k tokens/subtokens having the highest probabilities from the output distribution generated by the neural transformer model are expanded to the next inference level. The variable k is preconfigured and also referred to as the beam width. Each of the k subtokens/tokens is then expanded into a search that updates the current context sequence with the selected subtoken/token to input into the neural transformer model to generate an additional probability distribution for the next token in a sequence. This process is repeated until the end of a line token is predicted as being the next likely token candidate.
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
[0088]:
Next, the neural transformer model is validated. Before the neural transformer model is trained, a set of hyperparameters is selected randomly and then tuned to achieve a desired performance. The neural transformer model is tested using a validation dataset to determine the appropriate hyperparameters settings to achieve a desired goal. When the desired goal is not achieved, one or more hyperparameters are adjusted and the training is repeated until the target goal is achieved (collectively, block 518).
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined. The weight gradients are calculated as the difference between the old values and the new values of the weights. The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano and Svyat.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
One of ordinary skill would have motivation to combine Colleen, Tufano, and Svyat that can use sub tokens for less frequently occurring elements to provide better accuracy for out-of-vocabulary tokens [Svyat [0007]).
In regard to claim 4: (Previously Presented)
Colleen does not explicitly disclose:
- wherein the generating the amplified code comprises performing a refactoring.
Tufano discloses in:
- wherein the generating the amplified code comprises performing a refactoring.
[1, Page 25]:
Moreover, the extracted taxonomy shows that the model is able to learn a rich variety of meaningful code transformations, automatically fixing bugs and refactoring code as humans would do.
[IV, Page 29]:
Fig. 1 shows the taxonomy of code transformations that we derived by manually analyzing the 722 perfect predictions. Note that a single perfect prediction can include multiple types of changes falling into different categories of our taxonomy (e.g., a refactoring and a bug fix implemented in the same code transformation).
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
In regard to claim 5: (Previously Presented)
Colleen and Tufano do not explicitly disclose:
- wherein the generating the amplified source code comprises performing a compiler optimization.
However, Svyat discloses:
- wherein the generating the amplified source code comprises performing a compiler optimization.
[0036]:
A syntactic analyzer 112 transforms each of the selected source code programs 110 into a concrete syntax tree 114. The concrete syntax tree 114 represents the source code text in the parsed form. The concrete syntax tree 114 may also be a parse tree. The syntactic analyzer 112 may be a parser, part of a front-end compiler, part of a language compiler, or part of a compilation tool. A concrete syntax tree 114 represents the syntactic structure of a program in a hierarchical or tree structure.
[0081]:
Each selected source code program 110 is then parsed and/or compiled by the compilation component 112 to produce a concrete syntax tree (block 504).
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs,
[BRI: syntactic analyzer, also known as a parser, plays a crucial role in the compilation. It ensures generating an optimized code]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano and Svyat.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
One of ordinary skill would have motivation to combine Colleen, Tufano, and Svyat that can use sub tokens for less frequently occurring elements to provide better accuracy for out-of-vocabulary tokens [Svyat [0007]).
In regard to claim 9: (Currently Amended)
Colleen discloses in:
- A computer program product comprising one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions when executed by one or more processors causing the one or more processors to perform a method comprising:
[Col 5, lines 34-59], [Col 6, lines 14-23],
- identifying via an automated code analyzer one or more source code signals in a source code;
[Abstract]:
The computing device may further perform a source code analysis and refactoring process.
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
- generating via an automated code-rewriter, an amplified code based on the identified source code signals and the source code
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
[Col 16, lines 63-67]:
The computing device may train an artificial intelligence ( AI ) model 422 to determine /
Update the rules for refactoring " bloated ” ) code and the rules for identification 426. The
computing device may monitor and analyze the user selections of refactoring options for
certain identified code violations.
[Col 17, lines 1-22]:
The computing device may train the artificial intelligence model 422 by learning from the user selections of refactor ing options and/or user manual refactoring operations for different code violations. For example, if the user consistently selects "do nothing" for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified. In another example, if the user consistently selects a particular refactoring option for certain types of code violations, the AI 10 model 422 may update the rules for refactoring 424 accordingly, such that those types of code violations may be automatically refactored instead of refactored in response to user selection. In yet another example, if the user does not select any of the refactoring options provided by the computing device and instead performs manual refactoring for certain types of code violations, the AI model 422 may update the rules for refactoring 424 by learning from the user's manual refactoring operations. For example, the AI model 422 may include the user's manual refactoring operations as a new automatic refactoring option for those types of code violations.
PNG
media_image1.png
642
926
media_image1.png
Greyscale
[Col 18, lines 25-50]:
FIG. 4 illustrates the source code analysis and refactoring process 400, according to an embodiment. The user may input user configuration and select performance test to target 404 for legacy software through the graphical user interface 406 displayed on the computing device 402. The computing device may perform automated runtime performance profiling process as described in FIG. 3. Specifically, the computing device may create, configure, and launch profiling tests based on the user configuration to monitor timing and memory data. The computing device may process the monitored raw status data and save the processed data into the database 408. The processed data may comprise the analysis results of the automated runtime performance profiling. Based on the analysis results of the runtime performance profiling, the computing device may identify the inefficient functions 410 that scale poorly and cause the poor performance in the targeted performance test. After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. The user may implement the refactoring suggestions manually 414 to optimize the inefficient functions. Alternatively, the computing device may implement the refactoring suggestions automatically 428. (BRI: AI engine 422 determines the update rules for refactoring (hyper-parameters) and these rules are used in automated refracting (428) which represents automatic code rewriter]
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
- and selecting, via a hyperparameter optimization optimizer, one or more hyperparameters so that the automated code-rewriter controls selection
[Col 15, lines 41-46]:
After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. [BRI: refactoring is the
“hyperparameter””]
Colleen does not explicitly disclose:
- wherein the amplified source code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals, [[and]] wherein the amplified source code comprises one or more amplified signals, and wherein the amplified code is in a same programming language that the source code is in
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
However, Tufano discloses:
- wherein the amplified source code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals, [[and]] wherein the amplified source code comprises one or more amplified signals, and wherein the amplified code is in a same programming language that the source code is in
[III, Page 31]: 5) Readability:
Readable code is easier to understand and maintain
[III, Page 31]: 5) Readability:
We found several types of code transformations learned by the model and targeting the improvement of code readability.
[II D, Page 28]:
we describe the NMT models we use to learn code transformations. In particular, we train these models to translate the abstracted code amb in ama, effectively simulating the code change performed in the PR by developers.
II C, Page 27]: We also filter out those method pairs such that amb = ama, meaning the abstracted code before and after the PR appear the same
IV C, Page 30]:
Refactoring We grouped in the refactoring sub-tree, all code transformations that modify the internal structure of the system by improving one or more of its non-functional attributes (e.g., readability) without changing the system’s external behavior. We categorized transformations into five sub-categories
[IV, Page 29]:
Table III reports the perfect predictions (i.e., successfully predicted code transformations) by the NMT models, in terms of raw numbers and percentages of the test sets. When we allow the models to generate only a single translation (
[1, Page 26]:
We demonstrate a quantitative and qualitative evaluation of the NMT model. For the quantitative analysis, we assessed its ability in modifying the project’s code exactly as done by developers during real PRs. This means that we compare, for the same code components, the output of the manually implemented changes and of the output of the NMT model. The qualitative analysis aims instead at distilling a taxonomy of meaningful code transformations that the model was able to automatically learn from the training data- see Fig. 1. [BRI: code transformations that improve internal structure without changing external behavior do represent functional equivalence between the source code and its abstract/refactored form ]
- and wherein the amplified code is in a same programming language that the source code is in;
[V, Page 33]:
External validity. We experimented with the NMT model on data related to Java programs only. However, the learning process is language-independent and the whole infrastructure can be instantiated for different programming languages by replacing the lexer, parser and AST differencing tools.
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
[1, Page 25]:
GitHub alone hosted 100M repositories, with over 200M merged pull requests (PRs)
[BRI: Codebase Collaboration: NMT projects often involves a pull request that allows a developer to push changes (e.g., a new training script, a bug fix, or a model optimization) from their local branch to a shared repository (e.g., GitHub)]
[II, Page 28]:
As the name suggests, this model consists of two major components: an RNN Encoder, which encodes a sequence of tokens x into a vector representation, and an RNN Decoder, which decodes the representation into another sequence of tokens y. During training, the model learns a conditional distribution over a (output) sequence conditioned on another (input) sequence of terms: P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
), where the lengths n and m may differ. In our setting, given the sequence representing the abstract code before the PR x =
a
m
b
= (
x
1
,
,
…
,
x
n
) and a corresponding target sequence representing the abstract code after the PR y =
a
m
a
= (
y
1
,
,
…
,
y
m
) the model is trained to learn the conditional distribution: P (
a
m
a
|
a
m
b
) = P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
) , where
x
i
and
y
j
abstracted source tokens: Java keywords, separators, IDs, and frequent identifiers and literals. The Encoder takes as input a sequence x =(
x
1
,
,
…
,
x
n
) and produces a sequence of states h =(
h
1
,
,
…
,
h
n
). In particular, we adopt a bi-directional RNN Encoder [30], which is formed by a backward and a forward RNN. The RNNs process the sentence both from left-to-right and right-to-left, and are able to create sentence representations taking into account both past and future inputs [32]. The RNN Decoder predicts the probability of a target sequence y =(
y
1
,
,
…
,
y
m
)
) given h. Specifically, the probability of each output token
y
i
is computed based on: (i) the recurrent state si in the Decoder; (ii) the previous i−1 tokens (
y
1
,
,
…
,
y
i
-
1
)
and (iii) a context vector
c
i
. This vector
c
i
i
s
also called attention vector, is computed as a weighted average of the states in h:
∑
i
=
1
n
a
i
t
h
t
where the weights
a
i
t
allow the model to pay more attention to different parts of the input sequence, when predicting the token
y
i
.
[II C, Page 27]:
The source code of a method is fed to a lexer, built on top of ANTLR [56], which tokenizes the raw code into a stream of tokens. This stream of tokens is then fed into a Java parser, which discerns the role of each identifier (i.e., whether it represents a variable, method, or type name) and the type of a literal.
[BRI: Identifiers are indeed categories of source code tokens (source code signals]
developers are not limited to a finite dictionary of words to represent source code, rather, they can generate a potentially infinite amount of novel identifiers and literals. Table I shows the number of unique tokens identified in the source code of the three datasets.
PNG
media_image2.png
271
565
media_image2.png
Greyscale
[V, Page 33]:
The performance of the NMT model might be influenced by the hyperparameter configuration we adopted.
[II D, Page 28]:
3) Hyperparameter Search: We tested ten configurations of the encoder-decoder architecture with different combinations of RNN Cells (LSTM [45] and GRU [33]), number of layers (1, 2, 4) and units (256, 512) for the encoder/decoder, and the embedding size (256, 512). Bucketing and padding was used to deal with the variable length of the sequences. We trained the models for a maximum of 60k epochs, and selected the model’s checkpoint before over-fitting the training data. To guide the selection of the best configuration, we used the loss function computed on the validation set (not on the test set), while the results are computed on the test set
[II, Page 28]:
Encoder and Decoder are trained jointly by minimizing the negative log likelihood of the target tokens, using stochastic gradient descent.
[II, Page 28]:
Given a dataset, we train different configurations of the Encoder-Decoder models on
[II, Page 29]:
the training set, then use the validation set to select the best performing configuration of the model. We then evaluate the validity of the model with the unseen instances of the test set
Colleen and Tufano do not explicitly disclose:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data;
However, Svyat discloses:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data;
[0006]:
Each source code program in the training dataset does need not be written in the same programming language. The training dataset may be composed of numerous source code programs, each of which may be written in a different programming language. Each source code program in the training dataset is encoded into a sequence composed of tokens and/or subtokens. The frequently-used elements in a programming language are encoded into tokens and the less frequently-occurring elements are encoded into combinations of characters referred to as subtokens. This reduces the need to store a large vocabulary and provides better accuracy for out-of-vocabulary tokens.
[0034]:
The source code extraction component 108 extracts selected source code programs 110 from the source code repository 106 to obtain the training and validation datasets.
[0025] :
A transformer may act as an encoder or a decoder where the encoder maps an input sequence of symbol representations to a sequence of continuous representations and the decoder generates an output sequence of symbols from the sequence of continuous representations. The encoder-decoder architecture is not a good fit for conditional code generation or code completion tasks and is better suited for machine translation and patch generation type tasks. A variant of the transformer model is used that is composed of decoder blocks having masked self-attention and convolutional layers.
[0038]:
For example, the following line of source code:
loss= tf. reduce_ sum (tf. square (linear_model−y))
[0039]:
can be partitioned into the following sequence of tokens/ subtokens, each of which are separated by the character “|”:
PNG
media_image3.png
37
330
media_image3.png
Greyscale
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined.
[0053]:
Neural networks are trained iteratively, making multiple passes over the training dataset before converging to a minimum. An epoch represents the entire training dataset passed forwards and backwards through the neural network once. Since the training dataset is very large, it is partitioned into smaller batches. The training is iterative and the entire dataset is passed through the neural network in multiple iterations. Each training iteration includes forward propagation, loss calculation, backpropagation steps followed by updating the weights.
[0020]:
A line of source code may consist of various elements (e.g., keywords, delimiters, variables, methods, constants, operators, etc.) that are combined in a particular order in accordance with the grammar of the underlying programming language [BRI:a line of code in the underlying language is based on the same language]
[0123]:
The system tracks the sequence of characters entered into the line of the source code program by obtaining a sequence of tokens/subtokens representing a current context of the line of code and finding token/subtoken embedding vectors and positional embedding vectors for the sequence of tokens/subtokens
[BRI: the context of syntactic tree for preserving the functional equivalence [0036] and generating embedding vector of the tokens form the enhanced (amplified) representation of the code more useful for machine learning analysis]
[0124]:
The system includes instructions that input the token/subtoken embedding vectors and positional embedding vectors into the neural transformer model. The neural transformer model generates a probability distribution for the tokens/subtokens of a model vocabulary.
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code. [BRI: Perhaps known to the POSITA that an enriched source code representation is one that goes beyond the raw text of the code and incorporates additional contextual or structural information to make it more meaningful for analysis or learning to extract bug reports, and design patterns to improve tasks like code classification. However, perhaps also known to the POSITA that the “amplified code” is less common in formal software engineering literature, but in related domains it can mean increasing the amount or impact of information to make it more useful. A sequence of token representations — including token embeddings and positional embeddings can indeed provide a richer, more context-aware representation of source code than raw text alone, but whether it “enriches” the code depends on how it is used. A sequence of token embeddings plus positional embeddings provides a contextual, structure-aware representation of source code, which can be “enriched” into a more meaningful form when processed by a Transformer or similar architecture].
[0033]:
The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0094]:
the source code editor 130 performs a background parsing process that monitors the characters input into the source coe editor and continuously parses the source code to update the concrete syntax tree representing the source code of the current line of code (block 602).
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system. Software programs can include source code files, created in one or more source code languages (e.g., Visual Basic, Visual J#, C++. C#, J#, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk and the like). The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof. [BRI: JAV, and Python are managed code environment]
[0115]:
one or more source code program files 952, an IDE 954 that may include a source code editor 956, a user interface 958, a compilation component 960, a code completion component 962 and a neural transformer model 964 and other applications and data 966.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system
[0113]:
The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof.
[0114]:
A user can create and/or edit the source code program files 952 according to known software programming techniques and the specific logical and syntactical rules associated with a particular source language via a user interface 958 and a source code editor 956 in the IDE 954. [BRI:A syntax analyzer is a subset of automated source code analyzers and is a first step in parsing code, but automated source code analyzers can include syntax analysis plus semantic, style, and policy checks. In this context, the compilation component is the automated code analyzer. A compilation component that generates data structures for syntactic and semantic representation is conceptually similar to what an automated code analyzer does internally. Modern AI-assisted code completion components often integrate automated code analysis to improve suggestion accuracy, context awareness, and code quality]
[0054]:
The neural network has multiple layers so that more detailed relationships within the data are learned as well as how the features interact with each other on a non-linear level. The model architecture, training procedure, data normalization and vocabulary encoding procedures are hyperparameters that are tailored to meet a particular objective. The values of the hyperparameters influence how the parameters are learned.
[0055]:
In one aspect, the hyperparameters may include the following: (1) token/subtoken and position embedding layers of dimensions: 30000×768, and 1024×768 respectively; (2) twelve transformer blocks, with each block consisting of two convolutions, masked self-attention and layer normalization layers; (3) for the training procedure: auto-regressive, with a cross-entropy loss optimization objective; the sequence length is 1024 tokens/subtokens; the mini-batch size is 8; the gradient accumulation steps for each weight update is 8; the Adam stochastic optimization procedure is used to train the neural network; and the learning rate is 0.0001; (4) the data normalization procedure: normalize all string and numerical literals, keeping the ten most frequent;
[0033]:
FIG. 1 illustrates a block diagram of an exemplary code completion system 100 in which various aspects of the invention may be practiced. As shown in FIG. 1, system 100 includes a training phase 102 which trains a transformer model 122 and an inference phase 104 that utilizes the transformer model 122 in a line-of-code completion system. The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0070]:
A beam search uses a breadth-first search to build a search tree. The search tree is composed of nodes at one or more inference levels. Each node represents a probability distribution generated by the neural transformer model for the tokens/subtokens in the model vocabulary. At each level, only the top k tokens/subtokens having the highest probabilities from the output distribution generated by the neural transformer model are expanded to the next inference level. The variable k is preconfigured and also referred to as the beam width. Each of the k subtokens/tokens is then expanded into a search that updates the current context sequence with the selected subtoken/token to input into the neural transformer model to generate an additional probability distribution for the next token in a sequence. This process is repeated until the end of a line token is predicted as being the next likely token candidate.
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
[0088]:
Next, the neural transformer model is validated. Before the neural transformer model is trained, a set of hyperparameters is selected randomly and then tuned to achieve a desired performance. The neural transformer model is tested using a validation dataset to determine the appropriate hyperparameters settings to achieve a desired goal. When the desired goal is not achieved, one or more hyperparameters are adjusted and the training is repeated until the target goal is achieved (collectively, block 518).
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined. The weight gradients are calculated as the difference between the old values and the new values of the weights. The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano and Svyat.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
One of ordinary skill would have motivation to combine Colleen, Tufano, and Svyat that can use sub tokens for less frequently occurring elements to provide better accuracy for out-of-vocabulary tokens [Svyat [0007]).
In regard to claim 12: (Previously Presented)
Colleen does not explicitly disclose:
- wherein the generating the amplified code comprises performing a refactoring.
However, Tufano discloses in:
- wherein the generating the amplified code comprises performing a refactoring.
[1, Page 25]:
Moreover, the extracted taxonomy shows that the model is able to learn a rich variety of meaningful code transformations, automatically fixing bugs and refactoring code as humans would do.
[IV, Page 29]:
Fig. 1 shows the taxonomy of code transformations that we derived by manually analyzing the 722 perfect predictions. Note that a single perfect prediction can include multiple types of changes falling into different categories of our taxonomy (e.g., a refactoring and a bug fix implemented in the same code transformation).
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
In regard to claim 13: (Previously Presented)
Colleen and Tufano do not explicitly disclose:
- wherein the generating the amplified source code comprises performing a compiler optimization.
However, Svyat discloses in :
- wherein the generating the amplified source code comprises performing a compiler optimization.
[0036]:
A syntactic analyzer 112 transforms each of the selected source code programs 110 into a concrete syntax tree 114. The concrete syntax tree 114 represents the source code text in the parsed form. The concrete syntax tree 114 may also be a parse tree. The syntactic analyzer 112 may be a parser, part of a front-end compiler, part of a language compiler, or part of a compilation tool. A concrete syntax tree 114 represents the syntactic structure of a program in a hierarchical or tree structure.
[0081]:
Each selected source code program 110 is then parsed and/or compiled by the compilation component 112 to produce a concrete syntax tree (block 504).
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs,
[BRI: antactic analyzer, also known as a parser, plays a crucial role in the compilation. It ensures generating an optimized code]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano and Svyat.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
One of ordinary skill would have motivation to combine Colleen, Tufano, and Svyat that can use sub tokens for less frequently occurring elements to provide better accuracy for out-of-vocabulary tokens [Svyat [0007]).
In regard to claim 16: (Currently Amended)
Colleen discloses in:
- A system comprising: one or more computer processing circuits; and one or more computer-readable storage media storing an automated code analyzer,
[Col 5, lines 34-51],
[Abstract]:
The computing device may further perform a source code analysis and refactoring process.
- an automated code-rewriter, and program instructions which, when executed by the one or more computer processors, circuits, the automated code analyzer and the automated code-rewriter to perform a method comprising:
[Col 16, lines 63-67]:
The computing device may train an artificial intelligence ( AI ) model 422 to determine /
Update the rules for refactoring " bloated ” ) code and the rules for identification 426. The
computing device may monitor and analyze the user selections of refactoring options for
certain identified code violations.
[Col 17, lines 1-22]:
The computing device may train the artificial intelligence model 422 by learning from the user selections of refactor ing options and/or user manual refactoring operations for different code violations. For example, if the user consistently selects "do nothing" for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified. In another example, if the user consistently selects a particular refactoring option for certain types of code violations, the AI 10 model 422 may update the rules for refactoring 424 accordingly, such that those types of code violations may be automatically refactored instead of refactored in response to user selection. In yet another example, if the user does not select any of the refactoring options provided by the computing device and instead performs manual refactoring for certain types of code violations, the AI model 422 may update the rules for refactoring 424 by learning from the user's manual refactoring operations. For example, the AI model 422 may include the user's manual refactoring operations as a new automatic refactoring option for those types of code violations.
PNG
media_image1.png
642
926
media_image1.png
Greyscale
[Col 18, lines 25-50]:
FIG. 4 illustrates the source code analysis and refactoring process 400, according to an embodiment. The user may input user configuration and select performance test to target 404 for legacy software through the graphical user interface 406 displayed on the computing device 402. The computing device may perform automated runtime performance profiling process as described in FIG. 3. Specifically, the computing device may create, configure, and launch profiling tests based on the user configuration to monitor timing and memory data. The computing device may process the monitored raw status data and save the processed data into the database 408. The processed data may comprise the analysis results of the automated runtime performance profiling. Based on the analysis results of the runtime performance profiling, the computing device may identify the inefficient functions 410 that scale poorly and cause the poor performance in the targeted performance test. After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. The user may implement the refactoring suggestions manually 414 to optimize the inefficient functions. Alternatively, the computing device may implement the refactoring suggestions automatically 428. (BRI: AI engine 422 determines the update rules for refactoring (hyper-parameters) and these rules are used in automated refracting (428) which represents automatic code rewriter]
- identifying via an automated code analyzer one or more source code signals in a source code;
[Abstract]:
The computing device may further perform a source code analysis and refactoring process.
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
- generating, via the automated code-rewriter, an amplified code based on the one or more identified source code signals and the source code,
[Col 7, lines 59-65]:
the computing device 101 may parse the source code of the 60 subset of inefficient functions and identify refactoring opportunities using an artificial intelligence (AI) model. Specifically, the computing device 101 may use a front end compiler to generate an abstract syntax tree of the source code. [BRI: An AST (Abstract Syntax Tree) provide syntactic construct such as variable, functions or operator that represent keyword, identifiers, that represent “source code signals]
[Col 16, lines 63-67]:
The computing device may train an artificial intelligence ( AI ) model 422 to determine /
Update the rules for refactoring " bloated ” ) code and the rules for identification 426. The
computing device may monitor and analyze the user selections of refactoring options for
certain identified code violations.
[Col 17, lines 1-22]:
The computing device may train the artificial intelligence model 422 by learning from the user selections of refactor ing options and/or user manual refactoring operations for different code violations. For example, if the user consistently selects "do nothing" for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified. In another example, if the user consistently selects a particular refactoring option for certain types of code violations, the AI 10 model 422 may update the rules for refactoring 424 accordingly, such that those types of code violations may be automatically refactored instead of refactored in response to user selection. In yet another example, if the user does not select any of the refactoring options provided by the computing device and instead performs manual refactoring for certain types of code violations, the AI model 422 may update the rules for refactoring 424 by learning from the user's manual refactoring operations. For example, the AI model 422 may include the user's manual refactoring operations as a new automatic refactoring option for those types of code violations.
PNG
media_image1.png
642
926
media_image1.png
Greyscale
[Col 18, lines 25-50]:
FIG. 4 illustrates the source code analysis and refactoring process 400, according to an embodiment. The user may input user configuration and select performance test to target 404 for legacy software through the graphical user interface 406 displayed on the computing device 402. The computing device may perform automated runtime performance profiling process as described in FIG. 3. Specifically, the computing device may create, configure, and launch profiling tests based on the user configuration to monitor timing and memory data. The computing device may process the monitored raw status data and save the processed data into the database 408. The processed data may comprise the analysis results of the automated runtime performance profiling. Based on the analysis results of the runtime performance profiling, the computing device may identify the inefficient functions 410 that scale poorly and cause the poor performance in the targeted performance test. After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. The user may implement the refactoring suggestions manually 414 to optimize the inefficient functions. Alternatively, the computing device may implement the refactoring suggestions automatically 428. (BRI: AI engine 422 determines the update rules for refactoring (hyper-parameters) and these rules are used in automated refracting (428) which represents automatic code rewriter]
- and selecting, via a hyperparameter optimization optimizer, one or more hyperparameters so that the automated code-rewriter controls
[Col 15, lines 41-46]:
After identifying the inefficient functions 410, the computing device may analyze the source code of the inefficient functions 410 and provide refactoring opportunities 412 for the user to select. The refactoring opportunities 412 may comprise refactoring suggestions/options to optimize the inefficient functions. [BRI: refactoring is the
“hyperparameter””]
Colleen does not explicitly disclose:
- wherein the amplified source code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals, [[and]] wherein the amplified source code comprises one or more amplified signals, and wherein the amplified code is in a same programming language that the source code is in
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
However, Tufano discloses:
- wherein the amplified source code is functionally equivalent to the source code by maintaining the one or more source code signals but adding a code addition that makes the one or more source code signals more clear for identification of the one or more source code signals, [[and]] wherein the amplified source code comprises one or more amplified signals,
[III, Page 31]: 5) Readability:
Readable code is easier to understand and maintain
[III, Page 31]: 5) Readability:
We found several types of code transformations learned by the model and targeting the improvement of code readability.
[II D, Page 28]:
we describe the NMT models we use to learn code transformations. In particular, we train these models to translate the abstracted code amb in ama, effectively simulating the code change performed in the PR by developers.
[II C, Page 27]: We also filter out those method pairs such that amb = ama, meaning the abstracted code before and after the PR appear the same
[IV C, Page 30]:
Refactoring We grouped in the refactoring sub-tree, all code transformations that modify the internal structure of the system by improving one or more of its non-functional attributes (e.g., readability) without changing the system’s external behavior. We categorized transformations into five sub-categories
[IV, Page 29]:
Table III reports the perfect predictions (i.e., successfully predicted code transformations) by the NMT models, in terms of raw numbers and percentages of the test sets. When we allow the models to generate only a single translation (
[1, Page 26]:
We demonstrate a quantitative and qualitative evaluation of the NMT model. For the quantitative analysis, we assessed its ability in modifying the project’s code exactly as done by developers during real PRs. This means that we compare, for the same code components, the output of the manually implemented changes and of the output of the NMT model. The qualitative analysis aims instead at distilling a taxonomy of meaningful code transformations that the model was able to automatically learn from the training data- see Fig. 1. [BRI: code transformations that improve internal structure without changing external behavior do represent functional equivalence between the source code and its abstract/refactored form ]
- and wherein the amplified code is in a same programming language that the source code is in
[V, Page 33]:
External validity. We experimented with the NMT model on data related to Java programs only. However, the learning process is language-independent and the whole infrastructure can be instantiated for different programming languages by replacing the lexer, parser and AST differencing tools.
- selection of one or more categories of source code signals from amongst a group of multiple source code signal categories so that the selected one or more categories of source code signals [[that]] are amplified in the amplified code generated in multiple trials with the automated code-rewriter, with the machine learning model, and with the loss determination so as to minimize the loss.
[1, Page 25]:
GitHub alone hosted 100M repositories, with over 200M merged pull requests (PRs) [BRI: Codebase Collaboration: NMT projects often involves a pull request that allows a developer to push changes (e.g., a new training script, a bug fix, or a model optimization) from their local branch to a shared repository (e.g., GitHub)]
[II, Page 28]:
As the name suggests, this model consists of two major components: an RNN Encoder, which encodes a sequence of tokens x into a vector representation, and an RNN Decoder, which decodes the representation into another sequence of tokens y. During training, the model learns a conditional distribution over a (output) sequence conditioned on another (input) sequence of terms: P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
), where the lengths n and m may differ. In our setting, given the sequence representing the abstract code before the PR x =
a
m
b
= (
x
1
,
,
…
,
x
n
) and a corresponding target sequence representing the abstract code after the PR y =
a
m
a
= (
y
1
,
,
…
,
y
m
) the model is trained to learn the conditional distribution: P (
a
m
a
|
a
m
b
) = P(
y
1
,
,
…
,
y
m
|
x
1
,
,
…
,
x
n
) , where
x
i
and
y
j
abstracted source tokens: Java keywords, separators, IDs, and frequent identifiers and literals. The Encoder takes as input a sequence x =(
x
1
,
,
…
,
x
n
) and produces a sequence of states h =(
h
1
,
,
…
,
h
n
). In particular, we adopt a bi-directional RNN Encoder [30], which is formed by a backward and a forward RNN. The RNNs process the sentence both from left-to-right and right-to-left, and are able to create sentence representations taking into account both past and future inputs [32]. The RNN Decoder predicts the probability of a target sequence y =(
y
1
,
,
…
,
y
m
)
) given h. Specifically, the probability of each output token
y
i
is computed based on: (i) the recurrent state si in the Decoder; (ii) the previous i−1 tokens (
y
1
,
,
…
,
y
i
-
1
)
and (iii) a context vector
c
i
. This vector
c
i
i
s
also called attention vector, is computed as a weighted average of the states in h:
∑
i
=
1
n
a
i
t
h
t
where the weights
a
i
t
allow the model to pay more attention to different parts of the input sequence, when predicting the token
y
i
.
[II C, Page 27]:
The source code of a method is fed to a lexer, built on top of ANTLR [56], which tokenizes the raw code into a stream of tokens. This stream of tokens is then fed into a Java parser, which discerns the role of each identifier (i.e., whether it represents a variable, method, or type name) and the type of a literal. [BRI: Identifiers are indeed categories of source code tokens (source code signals]
developers are not limited to a finite dictionary of words to represent source code, rather, they can generate a potentially infinite amount of novel identifiers and literals. Table I shows the number of unique tokens identified in the source code of the three datasets.
PNG
media_image2.png
271
565
media_image2.png
Greyscale
[V, Page 33]:
The performance of the NMT model might be influenced by the hyperparameter configuration we adopted.
[II D, Page 28]:
3) Hyperparameter Search: We tested ten configurations of the encoder-decoder architecture with different combinations of RNN Cells (LSTM [45] and GRU [33]), number of layers (1, 2, 4) and units (256, 512) for the encoder/decoder, and the embedding size (256, 512). Bucketing and padding was used to deal with the variable length of the sequences. We trained the models for a maximum of 60k epochs, and selected the model’s checkpoint before over-fitting the training data. To guide the selection of the best configuration, we used the loss function computed on the validation set (not on the test set), while the results are computed on the test set
[II, Page 28]:
Encoder and Decoder are trained jointly by minimizing the negative log likelihood of the target tokens, using stochastic gradient descent.
[II, Page 28]:
Given a dataset, we train different configurations of the Encoder-Decoder models on
[II, Page 29]:
the training set, then use the validation set to select the best performing configuration of the model. We then evaluate the validity of the model with the unseen instances of the test set
Colleen and Tufano do not explicitly disclose:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data; for the training of the machine learning model, determining a loss of the machine learning model using a loss function
However, Svyat discloses:
- training a machine learning model to perform a source code relevant task by using the amplified code as training data; for the training of the machine learning model, determining a loss of the machine learning model using a loss function
[0006]:
Each source code program in the training dataset does need not be written in the same programming language. The training dataset may be composed of numerous source code programs, each of which may be written in a different programming language. Each source code program in the training dataset is encoded into a sequence composed of tokens and/or subtokens. The frequently-used elements in a programming language are encoded into tokens and the less frequently-occurring elements are encoded into combinations of characters referred to as subtokens. This reduces the need to store a large vocabulary and provides better accuracy for out-of-vocabulary tokens.
[0034]:
The source code extraction component 108 extracts selected source code programs 110 from the source code repository 106 to obtain the training and validation datasets.
[0025] :
A transformer may act as an encoder or a decoder where the encoder maps an input sequence of symbol representations to a sequence of continuous representations and the decoder generates an output sequence of symbols from the sequence of continuous representations. The encoder-decoder architecture is not a good fit for conditional code generation or code completion tasks and is better suited for machine translation and patch generation type tasks. A variant of the transformer model is used that is composed of decoder blocks having masked self-attention and convolutional layers.
[0038]:
For example, the following line of source code:
loss= tf. reduce_ sum (tf. square (linear_model−y))
[0039]:
can be partitioned into the following sequence of tokens/ subtokens, each of which are separated by the character “|”:
PNG
media_image3.png
37
330
media_image3.png
Greyscale
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined.
[0053]:
Neural networks are trained iteratively, making multiple passes over the training dataset before converging to a minimum. An epoch represents the entire training dataset passed forwards and backwards through the neural network once. Since the training dataset is very large, it is partitioned into smaller batches. The training is iterative and the entire dataset is passed through the neural network in multiple iterations. Each training iteration includes forward propagation, loss calculation, backpropagation steps followed by updating the weights.
[0020]:
A line of source code may consist of various elements (e.g., keywords, delimiters, variables, methods, constants, operators, etc.) that are combined in a particular order in accordance with the grammar of the underlying programming language
[BRI: a line of code in the underlying language is based on the same language]
[0123]:
The system tracks the sequence of characters entered into the line of the source code program by obtaining a sequence of tokens/subtokens representing a current context of the line of code and finding token/subtoken embedding vectors and positional embedding vectors for the sequence of tokens/subtokens [BRI: the context of syntactic tree for preserving the functional equivalence [0036] and generating embedding vector of the tokens form the enhanced (amplified) representation of the code more useful for machine learning analysis]
[0124]:
The system includes instructions that input the token/subtoken embedding vectors and positional embedding vectors into the neural transformer model. The neural transformer model generates a probability distribution for the tokens/subtokens of a model vocabulary.
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code.
[0033]:
The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0094]:
the source code editor 130 performs a background parsing process that monitors the characters input into the source coe editor and continuously parses the source code to update the concrete syntax tree representing the source code of the current line of code (block 602).
[0114]:
the source code program files 952 can be compiled via a compilation component 960 generating data structures representing the syntactic structure and semantic model of the source code.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system. Software programs can include source code files, created in one or more source code languages (e.g., Visual Basic, Visual J#, C++. C#, J#, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk and the like). The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof. [BRI: JAV, and Python are managed code environment]
[0115]:
one or more source code program files 952, an IDE 954 that may include a source code editor 956, a user interface 958, a compilation component 960, a code completion component 962 and a neural transformer model 964 and other applications and data 966.
[0113]:
Computing device 904 may utilize an integrated development environment (IDE) 954 that allows a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system
[0113]:
The IDE 954 may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof.
[0114]:
A user can create and/or edit the source code program files 952 according to known software programming techniques and the specific logical and syntactical rules associated with a particular source language via a user interface 958 and a source code editor 956 in the IDE 954. [BRI:A syntax analyzer is a subset of automated source code analyzers and is a first step in parsing code, but automated source code analyzers can include syntax analysis plus semantic, style, and policy checks. In this context, the compilation component is the automated code analyzer. A compilation component that generates data structures for syntactic and semantic representation is conceptually similar to what an automated code analyzer does internally. Modern AI-assisted code completion components often integrate automated code analysis to improve suggestion accuracy, context awareness, and code quality]
[0054]:
The neural network has multiple layers so that more detailed relationships within the data are learned as well as how the features interact with each other on a non-linear level. The model architecture, training procedure, data normalization and vocabulary encoding procedures are hyperparameters that are tailored to meet a particular objective. The values of the hyperparameters influence how the parameters are learned.
[0055]:
In one aspect, the hyperparameters may include the following: (1) token/subtoken and position embedding layers of dimensions: 30000×768, and 1024×768 respectively; (2) twelve transformer blocks, with each block consisting of two convolutions, masked self-attention and layer normalization layers; (3) for the training procedure: auto-regressive, with a cross-entropy loss optimization objective; the sequence length is 1024 tokens/subtokens; the mini-batch size is 8; the gradient accumulation steps for each weight update is 8; the Adam stochastic optimization procedure is used to train the neural network; and the learning rate is 0.0001; (4) the data normalization procedure: normalize all string and numerical literals, keeping the ten most frequent;
[0033]:
FIG. 1 illustrates a block diagram of an exemplary code completion system 100 in which various aspects of the invention may be practiced. As shown in FIG. 1, system 100 includes a training phase 102 which trains a transformer model 122 and an inference phase 104 that utilizes the transformer model 122 in a line-of-code completion system. The training phase 102 may utilize a source code repository 106, a source code extraction component 108, a syntactic analyzer 112, a token/subtoken sequence extraction component 116, and a model training and validation component 120.
[0070]:
A beam search uses a breadth-first search to build a search tree. The search tree is composed of nodes at one or more inference levels. Each node represents a probability distribution generated by the neural transformer model for the tokens/subtokens in the model vocabulary. At each level, only the top k tokens/subtokens having the highest probabilities from the output distribution generated by the neural transformer model are expanded to the next inference level. The variable k is preconfigured and also referred to as the beam width. Each of the k subtokens/tokens is then expanded into a search that updates the current context sequence with the selected subtoken/token to input into the neural transformer model to generate an additional probability distribution for the next token in a sequence. This process is repeated until the end of a line token is predicted as being the next likely token candidate.
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
[0088]:
Next, the neural transformer model is validated. Before the neural transformer model is trained, a set of hyperparameters is selected randomly and then tuned to achieve a desired performance. The neural transformer model is tested using a validation dataset to determine the appropriate hyperparameters settings to achieve a desired goal. When the desired goal is not achieved, one or more hyperparameters are adjusted and the training is repeated until the target goal is achieved (collectively, block 518).
[0077]:
FIGS. 5A-5B illustrate an exemplary method 500 illustrating usage of a neural transformer model for code completion. Before the neural transformer model is trained, a set of hyperparameters is selected randomly. A hyperparameter is a parameter associated with the neural network model architecture, the training algorithms, and data normalization, and is set before the start of the model training. A hyperparameter is not learned by the deep learning or neural network. The hyperparameters are selected at random from a set of categorical values or, for real valued hyperparameters like learning rate, drawn at random from a given range. Hyperparameters are tuned based on the performance of the neural transformer model when tested using the validation dataset.
[0086]:
The loss function estimates the loss or error which is used to compare how good or bad the predicted results are. In one aspect, a categorical cross-entropy loss function is used. Once the loss is calculated, it is propagated backwards to the hidden layer that contributed directly to the output. In backpropagation, the partial derivatives of the loss function with respect to the trainable parameters are determined. The weight gradients are calculated as the difference between the old values and the new values of the weights. The weights are adjusted to make the loss as close as possible to zero using a gradient descent technique. In one aspect, a Stochastic Gradient Descent (SGD) method is the optimization algorithm used to find the values of parameters of the function that minimizes the loss function. A backpropagation through time (BPTT) algorithm maybe used to update the weights.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano and Svyat.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
One of ordinary skill would have motivation to combine Colleen, Tufano, and Svyat that can use sub tokens for less frequently occurring elements to provide better accuracy for out-of-vocabulary tokens [Svyat [0007]).
In regard to claim 21 (New)
Colleen does not explicitly disclose:
- wherein the selected one or more categories of source code signals comprises syntax and the code addition includes a set of parentheses to help the machine learning model better identify correct operator precedence.
However, Tufano discloses:
- wherein the selected one or more categories of source code signals comprises syntax and the code addition includes a set of parentheses to help the machine learning model better identify correct operator precedence.
[IV, Page 32]: Change comparison operand [6]
PNG
media_image4.png
191
741
media_image4.png
Greyscale
[BRI: the code above does involve precedence (within the parentheses) that are explicit in which the relations operator( < , >=1) has higher precedence than II logical OR . This improves readability and make the grouping clearer. A code without parenthesis may look if i < 0 OR i >=mLEN perhaps to a POSITA in software programming)
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
In regard to claim 22: (New)
Colleen discloses:
- better identify correct binding between a function and variables of the function.
[Col 2, lines 66-67], [Col 2, lines 1-12]:
The performance profiler may automatically profile legacy software at runtime, pinpointing libraries, classes, and functions in the software that scale poorly or otherwise inefficient. The source code analysis and refactoring tool may statically analyze source code to identify improper coding practices and inefficient algorithms, providing automated solutions to 5 transform the source code to remove or reduce the problem caused by improper practices and algorithms. The APR system may keep developers/users in-the-loop while making decisions about refactoring and targeting problem areas. The APR system may not only optimize and refactor code, but 10 also provide assistance in transitioning the legacy software to a new language, architecture, or operating system.
(BRI: Automatically profiling legacy runtime and functions, combined with AI-assisted refactoring tools that perform in-loop static analysis, can indeed help identify and correct improper function–variable bindings and other inefficiencies. Combining automatic profiling with AI-driven, in-loop static analysis and refactoring can effectively identify and correct improper function (variable bindings in legacy code, leading to more efficient, maintainable, and scalable software)]
In regard to claim 23: (New)
Colleen does not explicitly disclose:
- wherein the selected one or more categories of source code signals comprises type and the code addition includes a variable type indicator to help the machine learning model better identify a correct type for a first variable
However, Tufano discloses:
- wherein the selected one or more categories of source code signals comprises type and the code addition includes a variable type indicator to help the machine learning model better identify a correct type for a first variable
[II, Page 27]:
The source code of a method is fed to a lexer, built on top of ANTLR [56], which tokenizes the raw code into a stream of tokens. This stream of tokens is then fed into a Java parser, which discerns the role of each identifier (i.e., whether it represents a variable, method, or type name) and the type of a literal. Each unique identifier and literal is mapped to an ID, having the form of CATEGORY_#, where CATEGORY represents the type of identifier or literal (i.e., TYPE, METHOD, VAR, INT, FLOAT, CHAR, STRING) and # is a numerical ID generated sequentially for each unique type of instance within that category [BRI: the INT, FLOAT, CHAR, STRING represents the variable type]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
In regard to claim 24: (New)
Colleen does not explicitly disclose:
- wherein the selected one or more categories of source code signals comprises data flow
However, Tufano discloses:
- wherein the selected one or more categories of source code signals comprises data flow
[VI, Page 34]:
Also helping with correct coding practices, Gu et al. uses an RNN encoder-decoder model to generate a series of correct API usages in source code based upon natural language queries. The learned semantics allow the model to associate natural language queries with a sequence of API usages
[IV C, Page 30]: Refactoring
We grouped in the refactoring sub-tree, all code transformations that modify the internal structure of the system by improving one or more of its non-functional attributes (e.g., readability) without changing the system’s external behavior. We categorized transformations into five sub-categories. [BRI: refactoring is indeed a pipeline of code transformation that modify the internal structure of the system without changing is external behavior)
- and the code addition includes a variable renaming to help the machine learning model better identify a correct consequence of a conditional statement.
[Abstract, Page 25]:
our qualitative analysis shows that the model is capable of learning and replicating a wide variety of meaningful code changes, especially refactorings and bug-fixing activities.
[IV, Page 31]:
A second example of renaming, is the renamed parameter proposed for the endTrace(JMethod type) method in a PR impacting the AbstractTracerBrush class in the Android repository [12]. The developer here renamed several parameters “for clarity” and, in this case, renamed the type parameter into method, to make it more descriptive and better reflect its aim.
[VI, Page 34]:
Attentional Neural Network (ANN) with a convoluation layer in order to summarize pieces of source code into short, functional descriptions
[BRI: Refactoring operations that changes the source code may include variable renaming,
In most programming languages, renaming a function parameter is effectively the same as renaming a local variable inside that function, because parameters are just variables whose values are passed in when the function is called].
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
Claims 2-3, 8, 10-11, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over
Kimball Colleen (hereinafter Colleen) US 11042369 B1,
In view of Michele Tufano (hereinafter Tufano) On Learning Meaningful Code Changes via Neural Machine Translation, 2019 IEEE/ACM 41 st International Conference on Software Engineering (ICSE).
in view of Alexey Syvatkovsky et al. (hereinafter Syvat) US 2021/0034335 A1.
further in view of Brian Cremeans et al. (hereinafter Cremeans) US 2019/0317743 A1.
In regard to claim 2: (Previously Presented)
Colleen, Tufano, and Svyat do not explicitly disclose:
- selecting one or more of the source code signal categories for de-amplif2019ication;
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
However, Cremeans discloses:
- selecting one or more of the source code signal categories for de-amplification;
In [0032]:
Training is performed using training data. In examples disclosed herein, the training data originates from the collateral
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130. [BRI: the pattern is a source code signal]
[0039]:
The intent receiver 150 receives an intent of the programmer. In some examples the intent is received by the intent receiver 150 directly from a human programmer identifying the intent.
[0039]:
The intent can be inferred by parsing input of a programmer to detect what the programmer wants to occur,
In [0039]:
intent is automatically determined using machine learning, based on a device environment, etc. For example, in an automobile, intent to tune a device in the engine can be determined based on measurements obtain from the automobile. In another example, data related to the location of a mobile phone may automatically trigger intent to perform a task. [BRI: the intent is a source code signal and the amplified code contains the intent]
In [0040]:
The intent analyzer 152 identifies a function that can accomplish or satisfy the intent. For example, the intent analyzer 152 analyzes the intent and identifies a desired function. The desired function is the work or operations to perform on the input to deliver output that will satisfy the intent,
In [0041]:
The code searcher 154 is communicatively coupled to the catalog 128. The code searcher 154 searches the tagged source code blocks in the catalog 128 to match input, output, and function with the input, output, and desired function identified from the intent. The code searcher 154 identifies a candidate source code block to fulfill the intent.
[BRI: the code searcher that identifies the candidate source code to fulfil the intent is performing the “de-amplification”]
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130. [BRI: the patterns represents one or more source code signals]
In [0021]:
In some examples the syntax matcher 112 analyzes the source code block selected by the code repository accessor 108 and categorizes the source code block based on the syntax of the source code block. In some examples, the syntax matcher 112 categorizes the source code block based on other elements of the language, punctuation, and/or indentation patterns of the text of the source code block. [BRI: a syntax element represents categories of the syntax which is one of the source code signals]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086]:)
In regard to claim 3: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- wherein the group of multiple source code signal categories consist of syntax; scope; data flow and types;
However, Cremeans discloses:
- wherein the group of multiple source code signal categories consist of syntax; scope; data flow and types;
In [0003]:
FIG. 1 is a schematic illustration of an example system to categorize source code blocks and automatically generate source code in accordance with the teachings of this disclosure.
In [0011]:
Code repositories include source code blocks that are mostly functional that have defined functions with limited side effects. The source code blocks also have collateral that define the expected behavior, input, and output of such functions.
In [0020]:
The code repository accessor 108 selects a source code block from the filtered subset of source code blocks. [BRI: a subset of source code blocks are groups]
syntax;
In [0010]:
One example analyzes the language or syntax of portions of human-generated code and attempts to match source code blocks from a repository based on the language.
scope;
In [0012]:
In the examples disclosed herein, the resources for machine programming enable intent-based programming that identify source code blocks for generation or insertion that satisfy the intent of the programmer.
data flow;
In[0074]:
the code entity or a reference to the code entity may be stored in a database and keywords associated with the code entity may be further filtered
types.
In [0056]:
The source code blocks may be filtered to facilitate searching for a specific type of source code block.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086]:)
In regard to claim 8: (Currently Amended)
Colleen does not explicitly disclose:
- a further amplified code that is functionally equivalent to a new source code and comprises one or more amplified signals,
However, Tufano discloses:
- a further amplified code that is functionally equivalent to a new source code and comprises one or more amplified signals,
III, Page 31]: 5) Readability:
Readable code is easier to understand and maintain
[III, Page 31]: 5) Readability:
We found several types of code transformations learned by the model and targeting the improvement of code readability.
[II D, Page 28]:
we describe the NMT models we use to learn code transformations. In particular, we train these models to translate the abstracted code
a
m
b
in
a
m
a
, effectively simulating the code change performed in the PR by developers.
[II C, Page 27]:
We also filter out those method pairs such that
a
m
b
=
a
m
a
, meaning the abstracted code before and after the PR appear the same
IV C, Page 30]:
Refactoring We grouped in the refactoring sub-tree, all code transformations that modify the internal structure of the system by improving one or more of its non-functional attributes (e.g., readability) without changing the system’s external behavior. We categorized transformations into five sub-categories
[IV, Page 29]:
Table III reports the perfect predictions (i.e., successfully predicted code transformations) by the NMT models, in terms of raw numbers and percentages of the test sets. When we allow the models to generate only a single translation
[1, Page 26]:
We demonstrate a quantitative and qualitative evaluation of the NMT model. For the quantitative analysis, we assessed its ability in modifying the project’s code exactly as done by developers during real PRs. This means that we compare, for the same code components, the output of the manually implemented changes and of the output of the NMT model. The qualitative analysis aims instead at distilling a taxonomy of meaningful code transformations that the model was able to automatically learn from the training data- see Fig. 1.
[1, Page 26]: B. Code Extraction
we rely on GumTreeDiff [38] to establish the file-to-file mapping, performed using semantic anchors, between pre- and post-PR files and disregarding any file added/removed during the code review process. After this step, each PR is stored in the format pr= {{(
f
1
,
,
…
,
f
n
),
(
f
'
1
,
,
…
,
f
'
m
)
}
, where
f
i
is the file before and
f
'
i
is the corresponding version of the file after the PR. Next, each pair of files
(
f
'
i
,
f
'
i
)
is again analyzed using GumTreeDiff, which establishes method-to-method mapping and identifies
[BRI: again analyzed PR used for training represents a functionally equivalent to new source code]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen and Tufano.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
One of ordinary skill would have motivation to combine Coleen and Tufano that can provide improved expressiveness of identifiers and better adhere to the coding style guidelines [Tufano [IV, Page 7]).
Colleen, Tufano, and Svyat do not explicitly disclose:
- wherein the further amplified code comprises at least one of: test data and production traffic.
However, Cremeans discloses:
- wherein the further amplified code comprises at least one of: test data and production traffic.
In [0016]:
As understood in this disclosure, “collateral” are software development artifacts that reference the source code. Collateral includes API spec, unit tests, functional tests, asserts, comment blocks, documentation blocks, other maintained documentation, and/or other examples disclosed herein.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086]:)
In regard to claim 10: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- selecting one or more of the source code signal categories for de-amplification;
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
However, Cremeans discloses:
- selecting one or more of the source code signal categories for de-amplification;
In [0032]:
Training is performed using training data. In examples disclosed herein, the training data originates from the collateral
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130. [BRI: the pattern is a source code signal]
In [0039]:
The intent receiver 150 receives an intent of the programmer. In some examples the intent is received by the intent receiver 150 directly from a human programmer identifying the intent.
In [0039]:
The intent can be inferred by parsing input of a programmer to detect what the programmer wants to occur,
In [0039]:
intent is automatically determined using machine learning, based on a device environment, etc. For example, in an automobile, intent to tune a device in the engine can be determined based on measurements obtain from the automobile. In another example, data related to the location of a mobile phone may automatically trigger intent to perform a task.
In [0040]:
The intent analyzer 152 identifies a function that can accomplish or satisfy the intent. For example, the intent analyzer 152 analyzes the intent and identifies a desired function. The desired function is the work or operations to perform on the input to deliver output that will satisfy the intent,
In [0041]:
The code searcher 154 is communicatively coupled to the catalog 128. The code searcher 154 searches the tagged source code blocks in the catalog 128 to match input, output, and function with the input, output, and desired function identified from the
from the intent. The code searcher 154 identifies a candidate source code block to fulfill the intent. [BRI: the code searcher that identifies the candidate source code to fulfil the intent is performing the “deamplification”]
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130.
(BRI: the patterns represents one or more source code signals)
In [0021]:
In some examples the syntax matcher 112 analyzes the source code block selected by the code repository accessor 108 and categorizes the source code block based on the syntax of the source code block. In some examples, the syntax matcher 112 categorizes the source code block based on other elements of the language, punctuation, and/or indentation patterns of the text of the source code block. [BRI: a syntax element represents categories of the syntax which is one of the source code signals]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086]:)
In regard to claim 11: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- wherein the group of multiple source code signal categories consist of syntax; scope; data flow and types;
However, Cremeans discloses:
- wherein the group of multiple source code signal categories consist of syntax; scope; data flow and types;
In [0003]:
FIG. 1 is a schematic illustration of an example system to categorize source code blocks and automatically generate source code in accordance with the teachings of this disclosure.
In [0011]:
Code repositories include source code blocks that are mostly functional that have defined functions with limited side effects. The source code blocks also have collateral that define the expected behavior, input, and output of such functions.
In [0020]:
The code repository accessor 108 selects a source code block from the filtered subset of source code blocks. [BRI: a subset of source code blocks are groups]
syntax;
In [0010]:
One example analyzes the language or syntax of portions of human-generated code and attempts to match source code blocks from a repository based on the language.
scope;
In [0012]:
In the examples disclosed herein, the resources for machine programming enable intent-based programming that identify source code blocks for generation or insertion that satisfy the intent of the programmer.
data flow;
In[0074]:
the code entity or a reference to the code entity may be stored in a database and keywords associated with the code entity may be further filtered
types.
In [0056]:
The source code blocks may be filtered to facilitate searching for a specific type of source code block.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086])
In regard to claim 15: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- wherein the further amplified code comprises at least one of: test data and production traffic.
However, Cremeans discloses:
- wherein the further amplified code comprises at least one of: test data and production traffic.
In [0016]:
As understood in this disclosure, “collateral” are software development artifacts that reference the source code. Collateral includes API spec, unit tests, functional tests, asserts, comment blocks, documentation blocks, other maintained documentation, and/or other examples disclosed herein.
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086]:)
In regard to claim 17: (Previously Presented)
Colleen, Tufano and Svyat do not explicitly disclose:
- selecting one or more of the source code signal categories for de-amplification;
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
However, Cremeans discloses:
- selecting one or more of the source code signal categories for de-amplification;
In [0032]:
Training is performed using training data. In examples disclosed herein, the training data originates from the collateral
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130. [BRI: the pattern is a source code signal]
In [0039]:
The intent receiver 150 receives an intent of the programmer. In some examples the intent is received by the intent receiver 150 directly from a human programmer identifying the intent.
In [0039]:
The intent can be inferred by parsing input of a programmer to detect what the programmer wants to occur,
In [0039]:
intent is automatically determined using machine learning, based on a device environment, etc. For example, in an automobile, intent to tune a device in the engine can be determined based on measurements obtain from the automobile. In another example, data related to the location of a mobile phone may automatically trigger intent to perform a task. [BRI: the intent is a source code signal and the amplified code contains the intent]
In [0040]:
The intent analyzer 152 identifies a function that can accomplish or satisfy the intent. For example, the intent analyzer 152 analyzes the intent and identifies a desired function. The desired function is the work or operations to perform on the input to deliver output that will satisfy the intent,
In [0041]:
The code searcher 154 is communicatively coupled to the catalog 128. The code searcher 154 searches the tagged source code blocks in the catalog 128 to match input, output, and function with the input, output, and desired function identified from the intent. The code searcher 154 identifies a candidate source code block to fulfill the intent.
(BRI: the code searcher that identifies the candidate source code to fulfil the intent is performing the “d-amplification”]
- and identifying the one or more source code signals based on the selected one or more source code signal categories.
In [0032]:
Once training is complete, the model is deployed for use as an executable construct that processes an input and provides an output based on the network of nodes and connections defined in the model. In this example, the model recognizes patterns in the collateral and can automatically categorize a source code block based on the recognized patterns. The model is stored at the catalog 128. The model may then be executed by the machine learning module 130.
(BRI: the patterns represents one or more source code signals)
In [0021]:
In some examples the syntax matcher 112 analyzes the source code block selected by the code repository accessor 108 and categorizes the source code block based on the syntax of the source code block. In some examples, the syntax matcher 112 categorizes the source code block based on other elements of the language, punctuation, and/or indentation patterns of the text of the source code block. [BRI: a syntax element represents categories of the syntax which is one of the source code signal]
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Cremeans.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Cremeans teaches de-amplification.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat, and Cremeans to increase the efficiency of a programming machine using intent-based programming (Cremeans [0086])
Claims 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over
Kimball Colleen (hereinafter Colleen) US 11042369 B1,
In view of Michele Tufano (hereinafter Tufano) On Learning Meaningful Code Changes via Neural Machine Translation, 2019 IEEE/ACM 41 st International Conference on Software Engineering (ICSE).
in view of Alexey Svyatkovsky et al. (hereinafter Svyat) US 2021/0034335 A1.
further in view of in view of Jiangao Zhang et al. (hereinafter Zhang) US 11809841 B1.
In regard to claim 7: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- generating one or more negative codes based on the source code;
- and further training the machine learning model using the source code and one or more negative codes.
However, Zhang discloses:
- generating one or more negative codes based on the source code;
However, Zhang discloses:
- generating one or more negative codes based on the source code;
[Col 2, lines 62-67]:
One aspect of many software modernization processes involves the identification of so-called “anti-patterns” associated with a software application. An anti-pattern generally represents any undesirable characteristic of a software application for which a known, better software development pattern exists. While a software application containing one
[Col 3, lines 1-4]:
or more anti-patterns may generally operate as its developers intend in most environments, the presence of such anti-patterns may cause the application to be ineffective or otherwise experience issues in other execution environments
- and further training the machine learning model using the source code and one or more negative [[code]] codes.
[Col 13, lines 9-13]:
The trained model can then be used for automatically identifying anti-pattern refactoring methods, where the model can recommend operations to mitigate particular types of identified anti-patterns
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Zhang.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Zhang teaches negative codes.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat and Zhang to improved operational performance and application availability (Zhang [Col 2, lines 50-54])
(Zhang [Col 2, lines 50-54])
In regard to claim 14: (Currently Amended)
Colleen, Tufano, and Svyat do not explicitly disclose:
- generating one or more negative codes based on the source code;
- and further training the machine learning model using the source code and one or more negative versions
However, Zhang discloses:
- generating one or more negative codes based on the source code;
In [Col 2, lines 62-67]:
One aspect of many software modernization processes involves the identification of so-called “anti-patterns” associated with a software application. An anti-pattern generally represents any undesirable characteristic of a software application for which a known, better software development pattern exists. While a software application containing one
[Col 3, lines 1-4]:
or more anti-patterns may generally operate as its developers intend in most environments, the presence of such anti-patterns may cause the application to be ineffective or otherwise experience issues in other execution environments
- and further training the machine learning model using the source code and one or more negative versions
[Col 13, lines 9-13]:
The trained model can then be used for automatically identifying anti-pattern refactoring methods, where the model can recommend operations to mitigate particular types of identified anti-patterns
It would have obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Colleen, Tufano, Svyat and Zhang.
Colleen teaches automatic code analyzer, hyperparameter used via automatic code analyzer.
Tufano teaches functionally equivalency, selecting one or more categories of source code signals from amongst a group of multiple source code signal .
Svyat teaches training and loss function and hyperparameter associated to the selection of source code signals.
Zhang teaches negative codes.
One of ordinary skill would have motivation to combine Colleen, Tufano, Svyat and Zhang to improved operational performance and application availability (Zhang [Col 2, lines 50-54])
(Zhang [Col 2, lines 50-54])
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to TIRUMALE KRISHNASWAMY RAMESH whose telephone number is (571)272-4605. The examiner can normally be reached by phone. 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, Li B Zhen can be reached on phone (571-272-3768). 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.
/TIRUMALE K RAMESH/Examiner, Art Unit 2121
/Li B. Zhen/Supervisory Patent Examiner, Art Unit 2121
Prosecution Insights