Prosecution Insights
Last updated: April 19, 2026
Application No. 18/478,394

Structural Code Refactoring Based On The User's Code Changes Using Large Language Models

Final Rejection §103
Filed
Sep 29, 2023
Examiner
MITCHELL, JASON D
Art Unit
2199
Tech Center
2100 — Computer Architecture & Software
Assignee
Google LLC
OA Round
2 (Final)
55%
Grant Probability
Moderate
3-4
OA Rounds
4y 2m
To Grant
86%
With Interview

Examiner Intelligence

Grants 55% of resolved cases
55%
Career Allow Rate
342 granted / 623 resolved
At TC average
Strong +31% interview lift
Without
With
+31.4%
Interview Lift
resolved cases with interview
Typical timeline
4y 2m
Avg Prosecution
32 currently pending
Career history
655
Total Applications
across all art units

Statute-Specific Performance

§101
10.4%
-29.6% vs TC avg
§103
49.4%
+9.4% vs TC avg
§102
14.2%
-25.8% vs TC avg
§112
20.0%
-20.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 623 resolved cases

Office Action

§103
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 Applied References The examiner apologizes for the omission and will include Groenewegen and Subramaniam on the PTO-892 associated with this action. Objection to the Drawings The examiner does not appear to have received an amended figure 4. Accordingly, although the described amendment would likely overcome it, the objection is maintained. Claim Rejection Under 35 U.S.C. §112 The applicant’s amendments are sufficient to overcome the previous rejections which are consequently withdrawn. Claim Rejections under 35 U.S.C. §102 Applicant's arguments have been fully considered but they are not persuasive. Applicant has amended independent claim 1 substantially as proposed during the telephonic interview conducted on October 9, 2025. For example, amended independent claim 1 recites, in part, "generating, by the data processing hardware and using a large language model (LLM), refactoring code based on the original code snapshot and the modified code snapshot, wherein the refactoring code restructures existing code without changing the function of the code, and the refactoring generalizes a structural modification demonstrated by a difference between the original code snapshot and the modified code snapshot, where the refactoring code is configured to apply the code modification to code from other files of the plurality of files associated with the original code." As agreed during the telephonic interview conducted on October 9, 2025, the cited portions of Chan fail to disclose at least this combination of features. Accordingly, amended independent claim 1 is patentable over Chan. At least in view of the newly cited Balasubramanian, the examiner respectfully disagrees. Chan discloses “generating, by the data processing hardware and using a large language model (LLM), refactoring code based on the original code snapshot and the modified code snapshot” (see e.g. par. [0052] “generates a prompt for a large language model to predict the repaired code”, par. [0047] “the vector containing the code diff embedding and the code change description”), “generalizing a structural modification demonstrated by the difference” (see e.g. par. [0052] “returns a predicted repaired code”) to “apply the code modification to code from other files” (par. [0042] “provides repaired code 310 without the software vulnerability”, par. [0023] “software vulnerabilities 114 found in each source code file”). However, Chan does not explicitly disclose the function of the code does not change. As indicated below, refactoring which does not change the function of the refactored code was known in the art (see e.g. Balasubramanian col. 9, line 61-col. 10, line 9) and it would have been obvious to perform such refactoring with Chan’s system. Drawings Figure 4 should be designated by a legend such as --Prior Art-- because only that which is old is illustrated. See MPEP § 608.02(g). Corrected drawings in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance. 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. Claim(s) 1-2, 6, 11 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 8,793,645 to Balasubramanian et al. (Balasubramanian). Claims 1 and 11: Chan discloses a computer-implemented method that when executed on data processing hardware causes the data processing hardware to perform operations comprising: receiving, by data processing hardware, an original code snapshot corresponding to original code from a first file of a plurality of files (par. [0023] “a list of software vulnerabilities 114 found in each source code file … obtains the pull request”, par. [0024] “the “from file””); receiving, by the data processing hardware, a modified code snapshot corresponding to modified code from the first file of the plurality of files, the modified code comprising a code modification modifying the original code (par. [0046] “extracts the code diff of the changes made to correct the vulnerability”, par. [0023] “A code diff 116 is data comparison between … two versions of the same file”, par. [0024] “the “to file””); generating, by the data processing hardware and using a large language model (LLM), refactoring code based on the original code snapshot and the modified code snapshot (par. [0052] “generates a prompt for a large language model to predict the repaired code … returns a predicted repaired code”, par. [0047] “the vector containing the code diff embedding and the code change description”), wherein the refactoring code restructures existing code (par. [0052] “repaired code”), and the refactoring generalizes a structural modification demonstrated by a difference between the original code snapshot and the modified code snapshot (par. [0023] “A code diff 116 is data comparison between … two versions of the same file”, also see pars. [0024]-[0025]), where the refactoring code is configured to apply the code modification to code from other files of the plurality of files associated with the original code (par. [0052] “generates a prompt for a large language model to predict the repaired code … returns a predicted repaired code”); identifying, by the data processing hardware, target code from a second file of the plurality of files, the target code associated with the original code (par. [0018] “The static analyzer 104 discovers software vulnerabilities over a codebase or source code repository”); and applying, by the data processing hardware using the refactoring code, the code modification to the target code of the second file of the plurality of files (par. [0042] “provides repaired code 310 without the software vulnerability”). Chan does not explicitly disclose: the refactoring code restructures existing code without changing the function of the code. Balasubramanian teaches: refactoring code restructures existing code without changing the function of the code (col. 9, line 61-col. 10, line 9 “The refactored activity retains all of the functionality of the replaced portion”). It would have been obvious before the effective filing date of the claimed invention to refactor the code without changing the function of the code. Those of ordinary skill in the art would have been motivated to do so as a known type of refactoring which would have produced only the expected results and would have provided a simplified visualization while maintaining the desired functionality (see e.g. Balasubramanian col. 9, line 61-col. 10, line 9). Claim 2: Chan discloses claim 1, wherein a code functionality of the original code is the same as a code functionality of the modified code (par. [0002] “A software vulnerability differs from … functional bugs”, those of ordinary skill would have understood this to indicate that the “functionality” remains the same). Claims 6 and 16: Chan discloses claims 1 and 11, wherein the LLM comprises a pre-trained LLM (par. [0026] “The encoder neural transformer … pre-trained”). Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 8,793,645 to Balasubramanian et al. (Balasubramanian) in view of US 11,809,841 to Zhang et al. (Zhang). Claims 3 and 13: Chan discloses claims 1 and 11, but does not explicitly disclose wherein: the original code and the modified code each comprise respective code in a first programming language; and the refactoring code comprises code in a second programming language different from the first programming language. Zhang teaches: the original code and the modified code each comprise respective code in a first programming language (col. 12, lines 18-23 “applications written in particular types of programming languages”, it would at least have been obvious for the application and any changes to the application to be written in the same language (e.g. one of a limited number of choices comprising the same or different language); and the refactoring code comprises code in a second programming language different from the first programming language (col. 7, lines 33-40 “defining refactoring logic in a declarative language”). It would have been obvious before the effective filing date of the claimed invention to write the original and modified code in a first language (e.g. those of skill in the art would have understood that it is common place to update code using the same language) and generate refactoring code in a second language. Those of ordinary skill in the art would have been motivated to do so as a known means of defining refactoring logic which would have produced only the expected results. Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 8,793,645 to Balasubramanian et al. (Balasubramanian) in view of US 2025/0103314 to Bober et al. (Bober). Claims 5 and 15: Chan discloses claims 1 and 11, wherein the method further comprises, before applying the code modification to the target code: displaying, by the data processing hardware and via a user device associated with a user, the refactoring code (par. [0042] “notifies the source code editor 304 … and provides repaired code 310”); applying, by the data processing hardware and using the refactoring code, the code modification to the identified target code (par. [0042] “provides repaired code 310 without the software vulnerability”). Chan does not explicitly disclose: receiving, by the data processing hardware and from the user device associated with the user, updated refactoring code comprising a user modification (par. [0077] “the software developer may revise the code”); and applying, using the updated refactoring code, the code modification to the identified target code. Bober teaches: receiving, from the user device associated with the user, updated refactoring code comprising a user modification (par. [0077] “the software developer may revise the code”); and applying, using the updated refactoring code, the code modification to the identified target code (par. [0077] “compiled”). It would have been obvious before the effective filing date of the claimed invention to receive and apply updated refactoring code. Those of ordinary skill in the art would have been motivated to do so to allow a human reviewer to test/analyze, and possibly correct or improve, the change before applying it. Claim(s) 7-8 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 2024/0428015 to Yoon et al. (Yoon). Claims 7 and 17: Chan discloses claims 1 and 11, but does not disclose wherein the method further comprises training, by the data processing hardware, the LLM using labeled training samples, each respective labeled training sample comprising a corresponding training input paired with ground-truth refactoring code, and the corresponding training input comprising training original code and training modified code. Yoon teaches: training the LLM using labeled training samples, each respective labeled training sample comprising a corresponding training input paired with ground-truth refactoring code (par. [0029] “the training examples can be labeled … with a ground truth label”). It would have been obvious before the effective filing date of the claimed invention to train the LLM using labeled training samples, training original code and training modified code (Yoon par. [0028] “training data associated with the generative task”, Chan par. [0023] “A code diff 116 is data comparison between … two versions of the same file”). Those of ordinary skill in the art would have been motivated to do so as a known method of training/refining a LLM which would have produced only the expected results. Claims 8 and 18: Chan and Yoon teach claims 7 and 17, wherein training the LLM using labeled training samples comprises, for each respective labeled training sample: generating, by the data processing hardware and using the LLM, predicted refactoring code based on the corresponding training input (Chan par. [0052] “generates a prompt for a large language model to predict the repaired code”); determining, by the data processing hardware, a training loss based on the predicted refactoring code and the paired ground-truth refactoring code (Yoon par. [0029] “evaluated through a loss function to determine an error … with a ground-truth label”); and training, by the data processing hardware, the LLM based on the training loss (Yoon par. [0029] “back propagated through the model”). Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 2024/0428015 to Yoon et al. (Yoon) in view of US 2023/0289151 to Groenewegen et al. (Groenewegen). Claims 9 and 19: Chan and Yoon teach claims 8 and 18, but does not disclose wherein the ground-truth refactoring code comprises placeholders for capture variables. Chan and Yoon do not teach: the ground-truth refactoring code comprises placeholders for capture variables. Groenewegen teaches: refactoring code comprising placeholders for capture variables (e.g. par. [0050] associate one or more variables with a template”). It would have been obvious before the effective filing date of the claimed invention to include placeholders for capture variables in the ground-truth refactoring code. Those of ordinary skill in the art would have been motivated to do so as a known means of applying changes to source code which would have produced only the expected results. Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0403438 to Chan et al. (Chan) in view of US 11,948,118 to Subramaniam et al. (Subramaniam). Claims 10 and 20: Chan discloses claims 1 and 11, wherein the method further comprises: determining, by the data processing hardware, a first Abstract Syntax Tree (AST) based on the original code snapshot (par. [0022] “the syntactic data from an abstract syntax tree of each code”); determining, by the data processing hardware, a second AST based on the modified code snapshot (par. [0022] “the syntactic data from an abstract syntax tree of each code”); and wherein the refactoring code generalizes the comparison between the first and the second snapshots (par. [0037] “diffs 220 … input into the prompt”). Chan does not explicitly disclose: generating, by the data processing hardware, a comparison between the first AST with the second AST. Subramaniam teaches: generating a comparison between the first AST with the second AST (col. 8, lines 31-34 “create ASTs for the two file versions … and returns a POJO representing the differences between the two ASTs”). It would have been obvious before the effective filing date of the claimed invention to compare first and second ASTs generated from the changed code. Those of ordinary skill in the art would have been motivated to do so because “This is more accurate than conventional line-diffing tools” (Subramaniam col. 8, lines 2-4). 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. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 11,042,369 to Kimball et al., US 2024/0289126 to Dolby et al., US 11,758,010 to Tamilselvam et al. and US 2010/02875289 to Lochmann teach alternate forms of refactoring. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm. 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. /JASON D MITCHELL/Primary Examiner, Art Unit 2199
Read full office action

Prosecution Timeline

Sep 29, 2023
Application Filed
Aug 08, 2025
Non-Final Rejection — §103
Sep 24, 2025
Interview Requested
Oct 09, 2025
Examiner Interview Summary
Oct 09, 2025
Applicant Interview (Telephonic)
Nov 12, 2025
Response Filed
Jan 05, 2026
Final Rejection — §103
Feb 27, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591423
Determining a security patch for a cyberattack by executing simulations of different security protocols
2y 5m to grant Granted Mar 31, 2026
Patent 12585575
Auto-Complete Testing
2y 5m to grant Granted Mar 24, 2026
Patent 12572346
OTA MASTER, METHOD, AND NON-TRANSITORY STORAGE MEDIUM
2y 5m to grant Granted Mar 10, 2026
Patent 12561122
SOFTWARE PACKAGE UPDATE HANDLING
2y 5m to grant Granted Feb 24, 2026
Patent 12561119
Live Range Reduction to Enhance Register Allocation of Structured Control Flow Programs
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
55%
Grant Probability
86%
With Interview (+31.4%)
4y 2m
Median Time to Grant
Moderate
PTA Risk
Based on 623 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month