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 .
This action is in response to response filed on 6/23/2024. This action is FINAL.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bader et al. “Getafix: Learning to Fix Bugs Automatically” as applied to claims 1 above, and further in view of Smith (US 2020/0097389 A1).
As per claim 1, Bader et al. teaches the invention as claimed including, “A method of code parameter verification, comprising:
detecting a parameter verification request for
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed (1 Introduction, paragraphs (1, 3 and 5). Also see figure 2 where in the code with static analysis warning is input to the apply fix patterns and rank fix candidate box and (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”). Getafix takes previous unseen code that come with the same signal as the training data and produces a fix (2 Overview).
“in response to detecting the parameter verification request, extracting at least one code segment from the
generating, based on the at least one code segment, a verification statement for at least one parameter of the code with a trained machine learning model, the verification statement being configured to verify validation of the at least one parameter,”
Bader et al. teaches a prediction phase which applies the patterns to previously unseen buggy code to produce a suitable fix (2 Overview, paragraph 4). Getafix is an automated technique that learns recurring fix patterns for static analysis warnings and suggests fixes for future occurrences of the same bug category. First it splits a given set of example fixes into AST-level edit steps. Second it learns recurring fix patterns from these edit steps and third, given a previously unseen bug to fix, Getafix finds suitable fix patterns, ranks all candidate fixes, and suggests the top-most fixes to the developer (1 Introduction, paragraph 7). Getafix matches a tree pattern to the tree representation of buggy code (extracted segments). Given a specific edit pattern p and a buggy tree t, the approach creates a fix (5 Applying And Ranking Fix Patterns – 5.2 Ranking Fix Candidates). Also see figures 2 and 3. Figure 1 shows a fix for a null deference bug. Bug categories include potential null dereferences, incorrect uses of Java’s reference equality, and common API misuses (1 Introduction, paragraph 10). As can be seen in figure 1, different fixes for potential null dereference bugs include null verification checks such as “if (v==null) {return;}”.
“presenting an insertion prompt control for the verification statement; and
In response to detecting a predetermined operation for the insertion prompt control, inserting the verification statement into the code,”
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed. Given only these two inputs, the problem is to predict a fix that addresses the static analysis warning in a similar way as a human. By automating the fix generation and leaving the human only the final decision of whether to apply the fix. Give a previously unseen bug to fix, Getafix finds suitable fix patterns, ranks all candidate fixed, and suggests the fixes to the developer (1 Introduction, paragraphs 1, 3 ,5 and 7). Also see figure 2 and 8. As you can see in figure 2, code with static analysis warning is sent into the box (apply fix patterns & rank fix candidates) to initiate a bug fix determination. Also see (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”).
Bader et al. does not explicitly appear to teach, “in response to detecting a predetermined operation for the insertion prompt control, inserting the verification statement into the target code.”
Smith et al. teaches displaying a predicted error fix to a user and if the person selects the accept button, the predicted fix is applied to the code in the code editing container (0076).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bader et al. with Smith et al. because both teach the use of machine learning to generate predicted fixes for errors and presenting them to a developer/user. Bader et al. teaches displaying the predicted/suggested fixes but does not explicitly teach performing the action of modifying/changing code to apply the fix. Bader et al. teaches by automating the fix generation and leaving the human only the final decision of whether to apply the fix. Smith et al. teaches the known technique of allowing a human to accept or decline a fix and it would have been obvious to apply the technique to Bader et al. to produce similar results.
“wherein the machine learning model is trained based on a sample code set and sample verification statements for parameters of sample code in the sample code set.”
Bader teaches, during the learning phase, a set of pairs of bugs and their fixes is given as training data to Getafix. Training data can server any collection of past human code changes tied to a specific signal, such as a static analysis warning, a type error, a lint message, or simply the fact that a change was suggested during human code review. Getafix is currently focused on all bugs and fixes that have been detected as instance of a specific bug category by a static analyzer. Another key contribution is to include into the fix patterns not only the code changes themselves, but also some surrounding context (2 Overview). Also see figure 2 and 8. The edit patterns learned by Getafix also include context information (4.3 Additional Context in Edit Patterns).
As per claim 2 (Amended), Bader et al. further teaches, “The method of claim 1, wherein detecting the parameter verification request comprises:
detecting the parameter verification request in a code editing page of the receiving the parameter verification request initiated for a code file of the .”
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed. Given only these two inputs, the problem is to predict a fix that addresses the static analysis warning in a similar way as a human. By automating the fix generation and leaving the human only the final decision of whether to apply the fix. Give a previously unseen bug to fix, Getafix finds suitable fix patterns, ranks all candidate fixed, and suggests the fixes to the developer (1 Introduction, paragraphs 1, 3 ,5 and 7). Getafix takes previous unseen code that come with the same signal as the training data and produces a fix (2 Overview). Also see figure 2 and 8. As you can see in figure 2, code with static analysis warning is sent into the box (apply fix patterns & rank fix candidates) to initiate a bug fix determination.
As per claim 4 (Amended), Bader et al. and Smith et al. further teach, “The method of claim [[3]] 1, wherein inserting the verification statement into the
determining a target position of a verification statement to be inserted in the
inserting the verification statement into the
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed. Given only these two inputs, the problem is to predict a fix that addresses the static analysis warning in a similar way as a human. By automating the fix generation and leaving the human only the final decision of whether to apply the fix. Give a previously unseen bug to fix, Getafix finds suitable fix patterns, ranks all candidate fixed, and suggests the fixes to the developer (1 Introduction, paragraphs 1, 3 ,5 and 7). Also see figure 2 and 8. As you can see in figure 2, code with static analysis warning is sent into the box (apply fix patterns & rank fix candidates) to initiate a bug fix determination. Also see (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”).
Smith et al. teaches displaying a predicted error fix to a user and if the person selects the accept button, the predicted fix is applied to the code in the code editing container (0076). Smith shows in figure 10F in box 1051 the line of the error and the line of the correction to be made along with a options to accept and apply the correction 1052. The examiner states if the user is selecting accept to make the change at the specified line, then the user is determining/approving/specifying the target position.
As per claim 5, Bader et al. further teaches, “The method of claim 1, wherein the plurality of predetermined statement types comprises at least one of the following:
a parameter fetching statement, a function header, or a remote procedure call statement.”
Bader et al. teaches edit patterns also include contextual code. The static analysis warning addressed by Getafix may also provide additional context information (4.3 Additional Context in Edit Patterns). Getafix matches a tree pattern to the tree representation of buggy code (extracted segments). Given a specific edit pattern p and a buggy tree t, the approach creates a fix (5 Applying And Ranking Fix Patterns – 5.2 Ranking Fix Candidates). Also see figures 2 and 3. Figure 1 shows a fist for a null deference bug. Bug categories include potential null dereferences, incorrect uses of Java’s reference equality, and common API misuses (1 Introduction, paragraph 10). As can be seen in figure 1 different fixes for potential null dereference bugs include null verification checks such as “if (v==null) {return;}”. Getafix is currently focused on all bugs and fixes that have been detected as instance of a specific bug category by a static analyzer. Another key contribution is to include into the fix patterns not only the code changes themselves, but also some surrounding context (2 Overview). Bader et al. teaches 1,268 bug fixes for six kinds of warnings. Bug categories include potential null dereferences, incorrect uses of Java’s reference equality, common API misuses (I Introduction, paragraph 14). Also see figure 3.
The examiner states that Geafix uses AST nodes which would comprise variables, methods and calls that inherently include parameter access, function definitions and calls.
As pr claim 6 (Amended), Badder et al. further teaches, “The method of claim 1, wherein generating the verification statement further comprises:
determining a
extracting a further code segment in a predetermined neighborhood of the
generating the validation statement based on the at least one code segment and the further code segment with the machine learning model. “
Getafix takes previously unseen code that comes with the same signal as the training examples and produces a bug fix (2 Overview). Getafix matches a tree pattern to the tree representation of buggy code (extracted segments). Given a specific edit pattern p and a buggy tree t, the approach creates a fix (5 Applying And Ranking Fix Patterns – 5.2 Ranking Fix Candidates). Bader et al. teaches a prediction phase which applies the patterns to previously unseen buggy code to produce a suitable fix (2 Overview, paragraph 4). Bader et al. teaches, edit patterns learned by GetaFix also include context information. Learned edit patterns also include contextual code. Such contextual code helps deciding when a pattern is applicable. The static analysis warning addressed by Getafix may also provide additional context information (4.3 Additional Context in Edit Patterns). The static analysis warning addressed by GetaFix may also provide additional context information (extracted further code segment). For examiner the expression blamed for a NullPointerException gives a hint about how and where (target position) to apple a fix pattern (4.3 Additional Context in Edit Patterns).
As per claim 7, Bader et al. further teaches, “The method of claim 1, wherein generating the verification statement comprises:
combining the at least one code segment and a task prompt to obtain a prompt input, the task prompt indicating a verification statement generation task; and providing the prompt input to the machine learning model to obtain the verification statement.”
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed (1 Introduction, paragraphs 1, 3 and 5). Also see figure 2 where in the code with static analysis warning is input to the apply fix patterns and rank fix candidate box (ML model) and (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”). Getafix takes previous unseen code that come with the same signal as the training data and produces a fix (2 Overview). Getafix matches a tree pattern to the tree representation of buggy code. Given a specific edit pattern p and a buggy tree t, the approach creates a fix (5 Applying And Ranking Fix Patterns – 5.2 Ranking Fix Candidates).
As per claim 8 (Amended), Bader et al. further teaches, “The method of claim 7, wherein the at least one code segment comprises a plurality of code segments, and wherein combining the at least one code segment and the task prompt comprises:
concatenating the plurality of code segments in an order of the plurality of code segments in the
combining the plurality of concatenated code segments and the task prompt.”
Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed (1 Introduction, paragraphs 1, 3 and 5). Also see figure 2 where the code with static analysis warning is input to the apply fix patterns and rank fix candidate box (ML model) and (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”). Getafix takes previous unseen code that come with the same signal as the training data and produces a fix (2 Overview). Getafix matches a tree pattern to the tree representation of buggy code (concatenated code segments). Given a specific edit pattern p and a buggy tree t, the approach creates a fix (5 Applying And Ranking Fix Patterns – 5.2 Ranking Fix Candidates).
As per claim 9, Bader et al. further teaches, “The method of claim 1, wherein the training of the machine learning model comprises a pre-training process and a fine-tuning process,
wherein the machine learning model is pre-trained in the pre-training process with the sample code set, and”
During the learning phase, a set of pairs of bugs and their fixes is given as training data to Getafix. Training data can server any collection of past human code changes tied to a specific signal, such as a static analysis warning, a type error, a lint message, or simply the fact that a change was suggested during human code review. Getafix is currently focused on all bugs and fixes that have been detected as a instance of a specific bug category by a static analyzer. Another key contribution is to include into the fix patterns not only the code changes themselves, but also some surrounding context (2 Overview). Also see figure 2 and 8. The edit patterns learned by Getafix also include context information (4.3 Additional Context in Edit Patterns).
Bader et al. does not explicitly appear to teach, “wherein the machine learning model is fine-tuned in the fine-tuning process with at least one sample code segment in sample code from the sample code set and a sample verification statement for a parameter in the sample code, the at least one sample code segment comprising a code segment of the sample code that matches at least one of the plurality of predetermined statement types.”
Smith et al. teaches, when training a machine learning model, code output results can be compared to training corrected code, and parameters of the first encoder and decoder may be adjusted to reduce the difference between the code output results and the training corrected code (0064).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bader et al. with Smith et al. because both teach predicting a fix for an error using a machine learning model. Using the know technique to adjust/tune a machine learning model as shown in Smith et al. will help increase the accuracy of the machine learning model of Bader et al.
As per claim 10, Bader et al. further teaches, “The method of claim 9, wherein the at least one sample code segment further comprises a code segment in the sample code that is in a predetermined neighborhood of the sample verification statement.”
During the learning phase, a set of pairs of bugs and their fixes is given as training data to Getafix. Training data can server any collection of past human code changes tied to a specific signal, such as a static analysis warning, a type error, a lint message, or simply the fact that a change was suggested during human code review. Getafix is currently focused on all bugs and fixes that have been detected as a instance of a specific bug category by a static analyzer. Another key contribution is to include into the fix patterns not only the code changes themselves, but also some surrounding context (2 Overview). Also see figure 2 and 8. The edit patterns learned by Getafix also include context information (4.3 Additional Context in Edit Patterns).
As claims 11-12, and 14-20 contain similar limitations to claim 1-2, 4-12 and 14-20 are therefore rejected for similar reasons.
Response to Arguments
Applicant's arguments filed 8/23/2026 have been fully considered but they are not persuasive.
Applicant argument 35 U.S.C 102
Applicant argues, “That is, Bader discloses a technique that can suggest fixes for bugs in code. The system is trained using training data that includes pairs of bugs and their fixes. Then, after the system is trained, the system can be used to predict bug fixes for previously unseen code.
In contrast, claim 1 requires detecting a parameter verification request for code and then extracting at least one code segment from the code that matches at least one of a plurality of predetermined statement types in response to detecting the parameter verification request. Bader discloses a system that can predict bug fixes for previously unseen code. But Bader does not disclose that the system receives a "request" of any sort, let alone a "request" for parameter verification. Indeed, Bader's system only predict bug fixes-it does not perform any parameter verification, so it would not make any for Bader's system to receive a parameter verification request for code and then extracting at least one code segment from the code that matches at least one of a plurality of predetermined statement types in response to detecting the parameter verification request.
Further, claim 1 requires generating, based on the at least one code segment, a
verification statement for at least one parameter of the code with a trained machine learning model, the verification statement being configured to verify validation of the at least one
parameter. As noted above Bader's system only predicts bug fixes. It does not perform any parameter verification. A predicted bug fix is not a verification statement that is configured to verify validation of the at least one parameter. A predicted bug fix is a code modification generated to eliminate a detected defect. By contrast, a verification statement is a statement that is configured to check whether a parameter satisfies certain validity conditions.”
The examiner respectfully disagrees. Bader et al. teaches a piece of code with a static analysis warning that needs to be fixed (1 Introduction, paragraphs (1, 3 and 5). Also see figure 2 where in the code with static analysis warning is input to the apply fix patterns and rank fix candidate box and (6.7 Real-World Deployment: Auto-Fix Suggestions for infer Bug Reports”). The interprets inputting the static analysis warning to the apply fic patterns and rank fix candidate box of Bader et al. to be the parameter verification request.
Figure 1 of Bader et al. shows a fix for a null deference bug. Bug categories include potential null dereferences, incorrect uses of Java’s reference equality, and common API misuses (1 Introduction, paragraph 10). As can be seen in figure 1, different fixes for potential null dereference bugs include null verification checks such as “if (v==null) {return;}”. Therefore, the static analysis warning input could be a null dereference bug. Bader teaches that a null dereference bug is solved by adding a verification check such as “if (v==null) {return;}”. Therefore, the null dereference bug is solved by adding a verification statement and the request to solve the null dereference bug would then be equivalent to a request to add a parameter verification. As claimed the only definition of a verification statement is “the verification statement being configured to verify validation of the at least one parameter” which “if (v==null) {return;}” of Bader et al. is doing. The bug in Bader et al. is a bug that needs a parameter verification. Nothing in the claimed limitations claim how the verification is performed, therefore under its broadest reasonable interpretation the taught limitations to Bader et al. will cover the limitation.
Applicant further argues, “Finally, claim 1 requires that the machine learning model is trained based on a sample code set and sample verification statements for parameters of sample code in the sample code set. Bader's system is trained using training data that includes pairs of bugs and their fixes. However, as explained above, bug fixes are not the same as sample verification statements for parameters of sample code. Accordingly, Bader's system is not trained based on a sample code set and sample verification statements for parameters of sample code in the sample code set, as required by claim 1.”
The examiner disagrees, in light of the above response to the previous arguments, the bug in Bader is determined to be a null dereference bug which needs a verification statement such as “if (v==null) {return;}” to solve it. As stated in the above rejection, Bader teaches, during the learning phase, a set of pairs of bugs and their fixes is given as training data to Getafix. Training data can serve any collection of past human code changes tied to a specific signal, such as a static analysis warning, a type error, a lint message, or simply the fact that a change was suggested during human code review. Getafix is currently focused on all bugs and fixes that have been detected as instance of a specific bug category by a static analyzer. Another key contribution is to include into the fix patterns not only the code changes themselves, but also some surrounding context (2 Overview). Therefore, the machine learning model can be trained for null dereference bugs that will require a verification statement such as “if (v==null) {return;}” to solve it.
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 MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights