DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s arguments and amendment dated March 10, 2026. Claims 1, 3, 9, 11, 15, and 17 are currently amended and claims 1-20 remain pending in the application and have been fully considered by Examiner.
Applicant’s arguments regarding the 35 USC 112(f) interpretation of claims 1 and 11 have been considered but are not persuasive (see the Response to Arguments -- Claim Interpretation section below).
The 35 USC 112(b) rejections of claims 5, 6, 7, 12, 13, and 19 are maintained1 as the deficiencies remain uncorrected and have not been addressed in Applicant’s Arguments/Remarks.
Applicant's arguments with respect to the double patenting rejections have been considered but are moot in view of the new grounds of rejection presented herein.
In view of Applicant’s Amendments and Remarks, the 35 USC 101 rejections are withdrawn.
Applicant's arguments with respect to the prior art rejections have been considered but are moot in view of the new grounds of rejection presented herein.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “determining, by a code analysis module of a computer, an equivalency mapping … adjusting, by the code analysis module, one or more parameters” in claim 1, “a processing device … the processing device configured to: …” in claim 11, “the processing device is configured to: …” in claim 12, and “the processing device is further configured to: …” in claims 12-16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For example, Applicant’s Fig. 1, particularly Processing Circuitry 120.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 5, 6, 7, 9, 12, 13, and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claim 5, lines 1-3 recite “an equivalency mapping between a first AST constructed for the input source code and a second AST constructed for the output source code.” It is unclear if this is the same as “an equivalency mapping between a first abstract syntax tree (AST) constructed for the input source code and a second AST constructed for the output source code,” as recited on lines 5-7 of claim 1. The scope of claim 5 is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 5 as reciting “the equivalency mapping between the first AST constructed for the input source code and the second AST constructed for the output source code.”
With respect to claims 6 and 7, each inherits the deficiency of claim 5 identified above.
With respect to claims 12 and 19, each recites limitations similar to those identified above with respect to claim 5 and are indefinite for the same reason. For purposes of compact prosecution only, Examiner has interpreted claims 12 and 19 similarly to claim 5, as indicated above.
With respect to claim 13, it inherits the deficiency of claim 12 identified above.
With respect to claim 9, lines 4-5 recite “regenerating, by the AI language model in response to the validation result, new output source code from the input source code”. It is unclear if this is the same “new output source code from the input source code”, as recited in parent claim 1. For purposes of compact prosecution only, Examiner has interpreted claim 9 consistent with Applicant’s specification2 to mean “regenerating, by the AI language model in response to the validation result, the new output source code from the input source code”.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 2, 4, 8, 9, 10, 11, 14, 15, 16, 17, 18, and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 6, 8, 9, 14, 15, 16, and 20 of copending Application No. 18/398,300 in view of Yafi “A Syntactical Reverse Engineering Approach to Fourth Generation Programming Languages Using Formal Methods” (hereinafter Yafi), Weber et al. (US 20250094145, hereinafter Weber), and Takyar “From good to great: Enhancing your large language model’s performance for desired outputs” (hereinafter Takyar). The claims of the instant application are compared to the claims of the reference application in the following table:
Instant Application
Reference App. No. 18/398,300
1. A method of code generated by artificial intelligence the method comprising:
generating, by an artificial intelligence (AI) language model, output source code based on input source code;
by a code analysis module of a computer;
, a validation result for the output source code;
adjusting,one or more parameters of the AI language modelbased on the validation result
1. A method of using complexity metrics to assess code generated using artificial intelligence comprising:
generating, by an artificial intelligence (AI) language model, output source code based on input source code, wherein the Al language is trained using datasets of original source code in one programming language that has been remapped to source code in a different programming language, and wherein the Al language is trained to perform code translations by generating the output source code based on the input source code;
identifying, using a code analysis module, complexity scores for the input source code and the output source code using one or more complexity metrics; and
generating, using the code analysis module and based on an evaluation of the respective complexity scores, a validation score for the output source code;
adjusting one or more parameters of the AI language model based on the validation score to improve a quality and an accuracy of the code translations; and
retraining the AI language model, based on the validation score, to improve the quality and the accuracy of the code translations.
9. The method of claim 1 further comprising:
regenerating, by the AI language model in response to the validation result, new output source code from the input source code .
6. The method of claim 1 further comprising:
regenerating, by the AI language model based on the validation score, the output source code from the input source code.
10. The method of claim 1 further comprising:
determining, subsequent to retraining the AI language model, a second validation result for regenerated output source code; and
quantifying an improvement of the AI language model based on at least the validation result and the second validation result.
8. The method of claim 1 further comprising:
generating, subsequent to retraining the AI language model, a second validation score for regenerated output source code; and
quantifying an improvement of the AI language model based on at least the validation score and the second validation score.
11. An apparatus comprising: a memory; and a processing device, operatively coupled to the memory, the processing device configured to:
generate, by an artificial intelligence (AI) language model, output source code based on input source code;
;
, a validation result for the output source code;
adjust one or more parameters of the AI language model based on the validation result
.
9. An apparatus comprising: a memory; and a processing device, operatively coupled to the memory, the processing device configured to:
generate, by an artificial intelligence (AI) language model, output source code based on input source code, wherein the AI language is trained using datasets of original source code in one programming language that has been remapped to source code in a different programming language, and wherein the AI language is trained to perform code translations by generating the output source code based on the input source code;
identify respective complexity scores for the input source code and the output source code using one or more complexity metrics; and
generate, based on an evaluation of the respective complexity scores, a validation score for the output source code;
adjust one or more parameters of the AI language model based on the validation score to improve a quality and an accuracy of the code translations; and
retrain the AI language model, based on the validation score, to improve the quality and the accuracy of the code translations.
15. The apparatus of claim 11, wherein the processing device is further configured to:
regenerate, by the AI language model in response to the validation result, the new output source code from the input source code .
14. The apparatus of claim 9, where the processing device is further configured to:
regenerate, by the AI language model based on the validation score, the output source code from the input source code.
16. The apparatus of claim 11, wherein the processing device is further configured to:
determine, subsequent to retraining the AI language model, a second validation result for regenerated output source code; and
quantify an improvement of the AI language model based on at least the validation result and the second validation result.
15. The apparatus of claim 9, where the processing device is further configured to:
generate, subsequent to retraining the AI language model, a second validation score for regenerated output source code; and
quantify an improvement of the AI language model based on at least the validation score and the second validation score.
17. A non-transitory computer-readable storage medium storing instructions which, when executed, cause a processing device of a computer to:
, wherein the output source code is generated by an artificial intelligence (AI) language model based on the input source code;
, a validation result for the output source code;
adjust one or more parameters of the AI language model based on the validation result
16. A non-transitory computer readable storage medium storing instructions which, when executed, cause a processing device to:
identify respective complexity scores for input source code and output source code using one or more complexity metrics, wherein the output source code is generated by an artificial intelligence (AI) language model based on the input source code, wherein the AI language is trained using datasets of original source code in one programming language that has been remapped to source code in a different programming language, and wherein the AI language is trained to perform code translations by generating the output source code based on the input source code;
generate, based on an evaluation of the respective complexity scores, a validation score for the output source code;
adjust one or more parameters of the AI language model based on the validation score to improve a quality and an accuracy of the code translations; and
retrain the AI language model, based on the validation score, to improve the quality and the accuracy of the code translations.
20. The computer-readable storage medium of claim 17, wherein the processing device is further configured to:
determine, subsequent to retraining the AI language model, a second validation result for regenerated output source code; and
quantify an improvement of the AI language model based on at least the validation result and the second validation result.
20. The computer readable storage medium of claim 16, wherein the instructions further cause the processing device to:
generate, subsequent to retraining the AI language model, a second validation score for regenerated output source code; and
quantify an improvement of the AI language model based on at least the validation score and the second validation score.
With respect to claim 1, as can be seen in the table above, the limitations in bold are disclosed in reference claim 1. To the extent that “a validation result” in the instant claim differs from “validation score” in the reference claim, paragraph [0046] of the instant specification shows that the broadest reasonable interpretation of “validation result” includes “a validation score.”
The reference claim does not appear to disclose the following, which is taught in analogous art, Yafi: validating (e.g., p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact.) …. using abstract syntax trees (e.g., p. 209,
demonstrate that the output code had the same syntax as that of the original source language. To
do this a novel method was designed to show syntactical equivalence between the ASTs.) … determining … an equivalency mapping between a first abstract syntax tree (AST) constructed for the input source code and a second AST constructed for the output source code (Id.; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.) … indicating, based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi, such that the translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Weber: by the code analysis module … indicating a validation failure (e.g., Figs. 3-5 and associated text, e.g., [0068], uses the previously extracted critical code segments 302, transpiles them using a LLM into a TCL and verifies using the reference input 304 and ground truth data 306 … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM (e.g., if it is a compilation/syntax error, or if it one or multiple outputs have been wrong) … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM; [0110], Processing system 500 can have a modular design where certain modules include a plurality of the features/functions.); and regenerating, by the AI language model, new output source code from the input source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the invention of Weber because it can “improve performance portability,” as suggested by Weber (see [0014]).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Takyar: to adjust a randomness of an output of the AI language model (e.g., p. 5, § Balancing creativity and coherence: The temperature parameter, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [adjusting one or more parameters of the AI language model to adjust a randomness of an output of the AI language model]. Gradually increase or decrease the temperature to achieve the desired balance.) … after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 11, as can be seen in the table above, the limitations in bold are disclosed in reference claim 9. To the extent that “a validation result” in the instant claim differs from “validation score” in the reference claim, paragraph [0046] of the instant specification shows that the broadest reasonable interpretation of “validation result” includes “a validation score.”
The reference claim does not appear to disclose the following, which is taught in analogous art, Yafi: determine an equivalency mapping between a first abstract syntax tree (AST) constructed for the input source code and a second AST constructed for the output source code (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.); indicate, based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi, such that the translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Weber: indicating a validation failure (e.g., Figs. 3-5 and associated text, e.g., [0068], uses the previously extracted critical code segments 302, transpiles them using a LLM into a TCL and verifies using the reference input 304 and ground truth data 306 … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM (e.g., if it is a compilation/syntax error, or if it one or multiple outputs have been wrong) … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.); and regenerate, by the AI language model, new output source code from the input source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the invention of Weber because it can “improve performance portability,” as suggested by Weber (see [0014]).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Takyar: after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 17, as can be seen in the table above, the limitations in bold are disclosed in reference claim 16. To the extent that “a validation result” in the instant claim differs from “validation score” in the reference claim, paragraph [0046] of the instant specification shows that the broadest reasonable interpretation of “validation result” includes “a validation score.”
The reference claim does not appear to disclose the following, which is taught in analogous art, Yafi: determine an equivalency mapping between a first abstract syntax tree (AST) constructed for input source code and a second AST constructed for output source code (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.) … indicate, based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi, such that the translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Weber: indicating a validation failure (e.g., Figs. 3-5 and associated text, e.g., [0068], uses the previously extracted critical code segments 302, transpiles them using a LLM into a TCL and verifies using the reference input 304 and ground truth data 306 … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM (e.g., if it is a compilation/syntax error, or if it one or multiple outputs have been wrong) … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM; [0110], Processing system 500 can have a modular design where certain modules include a plurality of the features/functions.) … regenerate the output source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the invention of Weber because it can “improve performance portability,” as suggested by Weber (see [0014]).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Takyar: wherein the one or more parameters influence a creativity of a response of the AI language model to a prompt (e.g., p. 2, 1st para., crafting of prompts or inputs to guide the model’s responses; p. 5, 1st bullet point, Randomness and creativity: On the other end of the spectrum, higher temperature values introduce more randomness and creativity into the outputs; p. 5, § Balancing creativity and coherence, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [one or more parameters influence a creativity of a response of the AI language model to a prompt]. Gradually increase or decrease the temperature to achieve the desired balance.); and … after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claims 10, 16, and 20, as can be seen in the table above, reference claims 8, 15, and 20 disclose all of the limitations3.
These are provisional nonstatutory obvious type double patenting rejections.
With respect to claims 2 and 18, The reference claims do not appear to disclose the following, which is further taught in Yafi: wherein the input source code is implemented in a first programming language and the output source code is implemented in a second programming language that is different from the first programming language (e.g., p. 186, 1st para., compared for the source programming language (Uniface) against the output target (C#).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi for the same reason set forth above.
These are provisional nonstatutory obvious type double patenting rejections.
With respect to claim 4, The reference claims do not appear to disclose the following, which is further taught in Yafi: wherein the validation result indicates a degree of equivalency (e.g., p. 186, To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched; p. 188, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact … Other types of translation encountered during other tests were: ‘partial complete’.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claims 8 and 14, The reference claims do not appear to disclose the following, which is further taught in Yafi: indicating a location of a nonequivalent element found in at least one of the input source code and the output source code (e.g., Fig. 10.5 on p. 186 and associated text, e.g., p. 187, Figure 10.5 shows the chunking tree for both languages Uniface (top), and C# (bottom) which match exactly with respect to each language’s syntax. Nodes numbered 1 to 9 represent the language syntax grammar rules using the format: grammar rule name + ‘:’ + exact token value as seen in the code. Non matching language-specific nodes are marked using the asterisk symbol ‘*’; p. 189, Partial complete translation, This was when the translation is done successfully but parts of the code were missing. In the case of Uniface it could be due to missing elements … For example, Uniface used internal variables called ‘status’ … The translator generated the variable in the target languages (C#) but its value was constant.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi for the same reason set forth above.
These are provisional nonstatutory obvious type double patenting rejections.
With respect to claims 9 and 15, as can be seen in the table above, the limitations in bold are disclosed in reference claims 6 and 14 respectively. However, the reference claims do not appear to disclose the following, which is further taught in Takyar: adjusting the one or more parameters to increase the randomness of the output of the AI language model (e.g., p. 5, § Balancing creativity and coherence: The temperature parameter, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [adjusting the one or more parameters to increase the randomness of the output of the AI language model]. Gradually increase or decrease the temperature to achieve the desired balance.); and … after increasing the randomness of the output of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Takyar for the same reason set forth above.
These are provisional nonstatutory obvious type double patenting rejections.
Claim 3 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/398,300 in view of Yafi, Webber, and Takyar, as applied to instant claim 1 above, and further in view of Geirsson “scalafmt: opinionated code formatter for Scala”.
With respect to claim 3, Yafi further teaches wherein the validation result indicates the validation failure (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 188, types of translation encountered during other tests were: … ‘failure’.); and
wherein the validation result indicates a validation success (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; e.g., p. 186, last para., The result provided valid destination code (C#) … and correct results i.e. matching chunking trees derived from each code demonstrated a complete and syntactically correct translation (figure 10.5).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi for the same reason set forth above.
The reference application as modified does not appear to disclose the following, which is taught in analogous art, Geirsson: when the equivalency mapping indicates at least one nonequivalent element in at least one of the first AST and the second AST (e.g., p. 46, § 4.2.2 AST integrity, 1st para., The AST integrity property says that the abstract syntax tree of the formatted source file should be identical to the abstract syntax tree of the original input … Algorithm 8 shows the code needed to test AST integrity. This property catched several critical bugs.) … when the equivalency mapping indicates an equivalency for all elements of the first AST and the second AST (e.g., p. 46, § 4.2.2 AST integrity, 1st para., The AST integrity property says that the abstract syntax tree of the formatted source file should be identical to the abstract syntax tree of the original input … Algorithm 8 shows the code needed to test AST integrity ... Knowing that scalafmt preserves the AST of the input code gives us great confidence that scalafmt will not introduce bugs in our users code.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Geirsson, such that output source code is only validated successfully when the AST of the output source code is identical to the AST of the input source code, because it can provide “great confidence” that the output code “will not introduce bugs,” as suggested by Geirsson (see p. 46, last para.).
Claims 5, 6, 12, 13, and 19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9, and 16 of copending Application No. 18/398,300 in view of Yafi, Weber, and Takyar, as applied to instant claims 1, 11, and 17 above, and further in view of Baxter et al. “Clone Detection Using Abstract Syntax Trees” (hereinafter Baxter).
With respect to claims 5, 12, and 19, Yafi further teaches wherein determining an equivalency mapping between a first AST constructed for the input source code and a second AST constructed for the output source code (e.g., p. 181, § 10.2, A comparison of ASTs of the input source programming language against the output produced in the target language; p. 186, 1st para., ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of the reference application with the technique of Yafi for the same reason set forth above.
The reference claims as modified does not appear to discloses the following, which is taught in analogous art, Baxter: includes: partitioning the first AST and the second AST into subtrees (e.g., p. 2, last para., we must first fragment the program in parts we are willing to compare, and then determine if fragment pairs are equivalent; p. 3, right col., 1st full para., partition the sets of comparisons by categorizing sub-trees with hash values.); and identifying equivalencies between the subtrees of the first AST and the second AST (e.g., p. 2, last para., we must first fragment the program in parts we are willing to compare, and then determine if fragment pairs are equivalent; p. 3, left col., § 4, 1st para., compare every subtree to every other sub-tree for equality; p. 4, left col., top para., every pair of sub-trees located in the same hash bucket is compared.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Baxter, such that AST equivalence is determined based on comparing subtrees of the ASTs, because it is “simple and practical” and “could also be useful in producing more structured code, and in reverse engineering to discover domain concepts and their implementations,” as suggested by Baxter (see Abstract, 1st and 2nd paras.).
With respect to claims 6 and 13, Baxter further teaches wherein identifying equivalencies between the subtrees of the first AST and the second AST includes: identifying one or more equivalent permutations of a first subtree of one AST (e.g., p. 3, right col., 3rd full para., we used a hash function that ignores only the identifier names (leaves in the tree). Thus our hashing function puts trees which are similar modulo identifiers into the same hash bins for comparison; p. 4, left col., 1st full para., detection of similar trees containing commutative operators such as add (“+”). The value is in detecting re-ordered operands … Implementing this requires merely that such tree node types be identified as commutative, that the hashing function produces identical values on commutative trees, and that the similarity function tries all child orderings on commutative subtrees.); and determining that a second subtree in another AST matches one of the one or more equivalent permutations (Id, particularly, the similarity function tries all child orderings on commutative subtrees; p. 4, left col., top para., every pair of sub-trees located in the same hash bucket is compared.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Baxter for the same reason set forth above.
Claim 7 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/398,300 in view of Yafi, Weber, Takyar, and Baxter, as applied to instant claim 6 above, and further in view of Duley et al. “Program Differencing Algorithm for Verilog HDL” (hereinafter Duley).
With respect to claim 7, Baxter further teaches wherein the one or more equivalent permutations of the first subtree are generated by one or more of and reordering (e.g., p. 4, left col., 1st full para., detection of similar trees containing commutative operators such as add (“+”). The value is in detecting re-ordered operands … Implementing this requires merely that such tree node types be identified as commutative, that the hashing function produces identical values on commutative trees, and that the similarity function tries all child orderings on commutative subtrees.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Baxter for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Duley: independent statements (e.g., Fig. 1 on p. 479 and associated text, e.g., p. 478, right col., top para. - 1st full para., the non-blocking assignment (<=) denotes a non-blocking operation that executes simultaneously … the order in which top, bottom, and count are declared does not matter … the two non-blocking statements are reordered; e.g., p. 7, § 4.1, 1st para., Then it marks AST nodes that correspond to nonblocking assignments ... Marking these nodes allows for the matching algorithm to carefully handle semantically equivalent reordering of such nodes. The resulting abstract syntax tree allows certain concurrent nodes to be arranged in any sequence inside a module.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference application with the technique of Duley because considering permutations with reordered statements would allow for a correct determination of equivalence between ASTs even when statement orderings differ.
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, 2, 4, 8, 9, 11, 14, 15, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. (US 20250094145, hereinafter Weber) in view of Yafi “A Syntactical Reverse Engineering Approach to Fourth Generation Programming Languages Using Formal Methods” (hereinafter Yafi) and Takyar “From good to great: Enhancing your large language model’s performance for desired outputs” (hereinafter Takyar).
With respect to claim 1, Weber discloses A method of validating code generated by artificial intelligence , the method comprising (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … transpiling includes a process for taking source code written in one language and transforming it into another language … the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304.):
generating, by an artificial intelligence (AI) language model, output source code based on input source code (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … transpiling includes a process for taking source code written in one language and transforming it into another language.);
determining, by a code analysis module of a computer, ; and
indicating, , a validation result for the output source code (e.g., Figs. 3-4 and associated text, e.g., [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found … embodiments of the present invention provide for improved results and an automatic verification loop. As described herein, the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.);
adjusting, by the code analysis module, an output of the AI language model based on the validation result indicating a validation failure (e.g., Figs. 3-5 and associated text, e.g., [0068], uses the previously extracted critical code segments 302, transpiles them using a LLM into a TCL and verifies using the reference input 304 and ground truth data 306 … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM (e.g., if it is a compilation/syntax error, or if it one or multiple outputs have been wrong) … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM; [0110], Processing system 500 can have a modular design where certain modules include a plurality of the features/functions.); and
regenerating, by the AI language model, new output source code from the input source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.).
Weber does not appear to disclose the following, which is taught in analogous art, Yafi: using abstract syntax trees (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs.) … an equivalency mapping between a first abstract syntax tree (AST) constructed for the input source code and a second AST constructed for the output source code (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched. An initial trial (Run U1) used the full example code snippet above; see also p. 74) … based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi, such that the translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
Weber as modified does not appear to disclose the following, which is taught in analogous art, Takyar: one or more parameters of the AI language model to adjust a randomness of (e.g., p. 5, § Balancing creativity and coherence: The temperature parameter, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [adjusting one or more parameters of the AI language model to adjust a randomness of an output of the AI language model]. Gradually increase or decrease the temperature to achieve the desired balance.) … after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
With respect to claim 11, Weber discloses An apparatus comprising: a memory; and a processing device, operatively coupled to the memory (e.g., Figs. 3-5 and associated text, e.g., [0102], Referring to FIG. 5, a processing system 500 can include one or more processors 502, memory 504.), the processing device configured to:
generate, by an artificial intelligence (AI) language model, output source code based on input source code (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … transpiling includes a process for taking source code written in one language and transforming it into another language.);
indicate, , a validation result for the output source code (e.g., Figs. 3-4 and associated text, e.g., [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found … embodiments of the present invention provide for improved results and an automatic verification loop. As described herein, the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.);
adjust based on the validation result indicating a validation failure (e.g., Figs. 3-5 and associated text, e.g., [0068], uses the previously extracted critical code segments 302, transpiles them using a LLM into a TCL and verifies using the reference input 304 and ground truth data 306 … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM (e.g., if it is a compilation/syntax error, or if it one or multiple outputs have been wrong) … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM; [0110], Processing system 500 can have a modular design where certain modules include a plurality of the features/functions.); and
regenerate, by the AI language model, new output source code from the input source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.).
Weber does not appear to disclose the following, which is taught in analogous art, Yafi: determine an equivalency mapping between a first abstract syntax tree (AST) constructed for the input source code and a second AST constructed for the output source code (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.) … based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi, such that the code translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
Weber as modified does not appear to disclose the following, which is taught in analogous art, Takyar: one or more parameters of the AI language model (e.g., p. 5, § Balancing creativity and coherence: The temperature parameter, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [adjust one or more parameters of the AI language model]. Gradually increase or decrease the temperature to achieve the desired balance.) … after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
With respect to claim 17, Weber discloses A non-transitory computer-readable storage medium storing instructions which, when executed, cause a processing device of a computer to (e.g., Figs. 3-5 and associated text, e.g., [0102], Referring to FIG. 5, a processing system 500 can include one or more processors 502, memory 504; [0107] Examples of memory 504 include a non-transitory computer-readable media):
, wherein the output source code is generated by an artificial intelligence (AI) language model based on the input source code (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … transpiling includes a process for taking source code written in one language and transforming it into another language.);
indicate, , a validation result for the output source code (e.g., Figs. 3-4 and associated text, e.g., [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found … embodiments of the present invention provide for improved results and an automatic verification loop. As described herein, the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.);
adjust based on the validation result indicating a validation failure, ; and
regenerate the output source code (Id., particularly, [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop.).
Weber does not appear to disclose the following, which is taught in analogous art, Yafi: determine an equivalency mapping between a first abstract syntax tree (AST) constructed for input source code and a second AST constructed for output source code (e.g., p. 209, demonstrate that the output code had the same syntax as that of the original source language. To do this a novel method was designed to show syntactical equivalence between the ASTs; p. 186, 1st para., To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.) … based on the equivalency mapping (Id.; p. 186, The result provided valid destination code (C#). This can be found in appendix A (Output Code in C# from Input Code in Uniface), and correct results i.e. matching chunking trees derived from each code’s ASTs, which demonstrated a complete and syntactically correct translation (figure 10.5); p. 188, § Complete translation, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact; p. 190, § 10.4.1, Table 10.2 below gives summary results for comparisons of the ASTs in chunking tree form, for the Uniface input and C# outputs for all the grammar rules as implemented.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi, such that the code translation is validated based on AST equivalence, because it “reduces the cost, effort, and complexity compared to writing unit tests,” as suggested by Yafi (see p. 72, 2nd full para.).
Weber as modified does not appear to disclose the following, which is taught in analogous art, Takyar: one or more parameters of the AI language model … wherein the one or more parameters influence a creativity of a response of the AI language model to a prompt (e.g., p. 2, 1st para., crafting of prompts or inputs to guide the model’s responses; p. 5, 1st bullet point, Randomness and creativity: On the other end of the spectrum, higher temperature values introduce more randomness and creativity into the outputs; p. 5, § Balancing creativity and coherence, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [one or more parameters influence a creativity of a response of the AI language model to a prompt]. Gradually increase or decrease the temperature to achieve the desired balance.) … after adjusting the one or more parameters of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the iterative temperature fine-tuning technique of Takyar, such that an LLM temperature parameter is iteratively increased to generate new outputs, because “Optimizing the temperature parameter is essential”, as suggested by Takyar (see p. 6, § Striking the balance: Optimizing temperature for desired results, 1st para.).
With respect to claims 2 and 18, Weber also discloses wherein the input source code is implemented in a first programming language and the output source code is implemented in a second programming language that is different from the first programming language (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … transpiling includes a process for taking source code written in one language and transforming it into another language. For example, taking source code of a program written in one programming language as input and transpiling the source code into an equivalent source code in a different programming language.).
With respect to claim 4, Yafi further teaches wherein the validation result indicates a degree of equivalency (e.g., p. 186, To test the author’s system ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched; p. 188, The above (Run U1) is an example of a ‘complete translation’ where a complete translation has been defined as where the target language syntax was valid and intact … Other types of translation encountered during other tests were: ‘partial complete’.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi for the same reason set forth above.
With respect to claims 8 and 14, Yafi further teaches indicating a location of a nonequivalent element found in at least one of the input source code and the output source code (e.g., Fig. 10.5 on p. 186 and associated text, e.g., p. 187, Non matching language-specific nodes are marked using the asterisk symbol ‘*’; p. 189, Partial complete translation, This was when the translation is done successfully but parts of the code were missing. In the case of Uniface it could be due to missing elements … For example, Uniface used internal variables called ‘status’ … The translator generated the variable in the target languages (C#) but its value was constant.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi for the same reason set forth above.
With respect to claims 9 and 15, Weber also discloses regenerating, by the AI language model in response to the validation result, new output source code from the input source code (please note the 35 USC 112(b) rejection and interpretation of claim 9 above e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.) and Takyar further teaches adjusting the one or more parameters to increase the randomness of the output of the AI language model (e.g., p. 5, § Balancing creativity and coherence: The temperature parameter, 3rd para., The temperature parameter is a vital aspect when working with large language models. It controls the trade-off between creativity and coherence in the generated outputs. Adjusting the temperature parameter can influence the level of randomness or variability in the model’s responses; 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting [adjusting the one or more parameters to increase the randomness of the output of the AI language model]. Gradually increase or decrease the temperature to achieve the desired balance.); and … after increasing the randomness of the output of the AI language model (e.g., p. 6, 1st -2nd bullet point, Fine-tuning the temperature: experiment with different temperature values to find the optimal setting that aligns with your requirements. Gradually adjust the temperature and observe the output variations … Iterative refinement: If the initial outputs do not meet your expectations, iterate by refining the temperature setting. Gradually increase or decrease the temperature to achieve the desired balance.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Takyar for the same reason set forth above.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Weber in view of Yafi and Takyar, as applied to claim 1 above, and further in view of Geirsson “scalafmt: opinionated code formatter for Scala” (hereinafter Geirsson).
With respect to claim 3, Weber also discloses wherein the validation result indicates the validation failure (e.g., Figs. 3-4, particularly “if failed”, and associated text, e.g., [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … As described herein, the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304.); and
wherein the validation result indicates a validation success (e.g., Figs. 3-4, particularly “if successful”, and associated text, e.g., [0068], If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found … As described herein, the system may generate TCL candidates 316 which are verified 318 using the ground truth 306 and/or input data 304.).
Weber as modified by Yafi does not appear to disclose the following, which is taught in analogous art, Geirsson: when the equivalency mapping indicates at least one nonequivalent element in at least one of the first AST and the second AST (e.g., p. 46, § 4.2.2 AST integrity, 1st para., The AST integrity property says that the abstract syntax tree of the formatted source file should be identical to the abstract syntax tree of the original input … Algorithm 8 shows the code needed to test AST integrity. This property catched several critical bugs.) … when the equivalency mapping indicates an equivalency for all elements of the first AST and the second AST (e.g., p. 46, § 4.2.2 AST integrity, 1st para., The AST integrity property says that the abstract syntax tree of the formatted source file should be identical to the abstract syntax tree of the original input … Algorithm 8 shows the code needed to test AST integrity ... Knowing that scalafmt preserves the AST of the input code gives us great confidence that scalafmt will not introduce bugs in our users code.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Geirsson, such that output source code is only validated successfully when the AST of the output source code is identical to the AST of the input source code, because it can provide “great confidence” that the output code “will not introduce bugs,” as suggested by Geirsson (see p. 46, last para.).
Claims 5, 6, 12, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Weber in view of Yafi and Takyar, as applied to claims 1, 11, and 17 above, and further in view of Baxter et al. “Clone Detection Using Abstract Syntax Trees” (hereinafter Baxter).
With respect to claims 5, 12, and 19, Yafi further teaches wherein determining an equivalency mapping between a first AST constructed for the input source code and a second AST constructed for the output source code (e.g., p. 181, § 10.2, A comparison of ASTs of the input source programming language against the output produced in the target language; p. 186, 1st para., ASTs chunking trees were compared for the source programming language (Uniface) against the output target (C#) for various aspects of language syntax to determine whether and to what extent they matched.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Weber with the technique of Yafi for the same reason set forth above.
Yafi as modified by Weber does not appear to discloses the following, which is taught in analogous art, Baxter: includes: partitioning the first AST and the second AST into subtrees (e.g., p. 2, last para., we must first fragment the program in parts we are willing to compare, and then determine if fragment pairs are equivalent; p. 3, right col., 1st full para., partition the sets of comparisons by categorizing sub-trees.); and identifying equivalencies between the subtrees of the first AST and the second AST (e.g., p. 2, last para., we must first fragment the program in parts we are willing to compare, and then determine if fragment pairs are equivalent; p. 3, left col., § 4, 1st para., compare every subtree to every other sub-tree for equality; p. 4, left col., top para., every pair of sub-trees located in the same hash bucket is compared.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Baxter, such that AST equivalence is determined based on comparing subtrees of the ASTs, because it is “simple and practical” and “could also be useful in producing more structured code, and in reverse engineering to discover domain concepts and their implementations,” as suggested by Baxter (see Abstract, 1st and 2nd paras.).
With respect to claims 6 and 13, Baxter further teaches wherein identifying equivalencies between the subtrees of the first AST and the second AST includes: identifying one or more equivalent permutations of a first subtree of one AST (e.g., p. 3, right col., 3rd full para., we used a hash function that ignores only the identifier names (leaves in the tree). Thus our hashing function puts trees which are similar modulo identifiers into the same hash bins for comparison; p. 4, left col., 1st full para., detection of similar trees containing commutative operators such as add (“+”). The value is in detecting re-ordered operands … Implementing this requires merely that such tree node types be identified as commutative, that the hashing function produces identical values on commutative trees, and that the similarity function tries all child orderings on commutative subtrees.); and determining that a second subtree in another AST matches one of the one or more equivalent permutations (Id, particularly, the similarity function tries all child orderings on commutative subtrees; p. 4, left col., top para., every pair of sub-trees located in the same hash bucket is compared.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Baxter for the same reason set forth above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Weber in view of Yafi, Takyar, and Baxter, as applied to claim 6 above, and further in view of Duley et al. “A Program Differencing Algorithm for Verilog HDL” (hereinafter Duley).
With respect to claim 7, Baxter further teaches wherein the one or more equivalent permutations of the first subtree are generated by one or more of and reordering (e.g., p. 4, left col., 1st full para., detection of similar trees containing commutative operators such as add (“+”). The value is in detecting re-ordered operands … Implementing this requires merely that such tree node types be identified as commutative, that the hashing function produces identical values on commutative trees, and that the similarity function tries all child orderings on commutative subtrees.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Baxter for the same reason set forth above.
Weber as modified does not appear to disclose the following, which is taught in analogous art, Duley: independent statements (e.g., Fig. 1 on p. 479 and associated text, e.g., p. 478, right col., top para. - 1st full para., the non-blocking assignment (<=) denotes a non-blocking operation that executes simultaneously … the order in which top, bottom, and count are declared does not matter … the two non-blocking statements are reordered; e.g., p. 7, § 4.1, 1st para., Then it marks AST nodes that correspond to nonblocking assignments ... Marking these nodes allows for the matching algorithm to carefully handle semantically equivalent reordering of such nodes. The resulting abstract syntax tree allows certain concurrent nodes to be arranged in any sequence inside a module.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Duley because it “identifies syntactic differences robustly, even when multiple AST nodes have similar labels and when they are reordered,” as suggested by Duley (see p. 480, 3rd full para.).
Claims 10, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Weber in view of Yafi and Takyar, as applied to claims 1, 11, and 17 above, and further in view of Katz et al. “Towards Neural Decompilation” (hereinafter Katz).
With respect to claims 10, 16, and 20, Weber also discloses determining, subsequent to the AI language model, a second validation result for regenerated output source code (e.g., Figs. 3-4 and associated text, e.g., [0068], transpiling the legacy languages into an equivalent TCL using an LLM, and automatic verification … If the transpilation 308 was successful 310, the result is stored 312, otherwise the process continues until a suitable candidate is found. The cause of the failure is provided as feedback 314 to the LLM … embodiments of the present invention provide for improved results and an automatic verification loop; [0080], Overall, this process is repeated with verification and feeding performance-related metadata into the LLM until it converges to one or multiple best candidates 422; [0081], The transpilation and optimization process could also be done in a single LLM.); .
Weber does not appear to disclose the following, which is taught in analogous art, Katz: retraining (e.g., p. 3, right col. § 2.2.1, 1st - 2nd para., We surround the NMT model with a feedback loop that allows the system to determine success/failure rates and improve itself as needed by further training; p. 4, After each iteration we update the dataset used for training. Retraining without doing so would lead to over-fitting the model to the existing dataset; p. 5, § 4.1, 3rd para., It then iteratively extends the training and validation sets (Section 4.2), trains a model on the new sets and attempts to translate the input set … The framework repeats these steps as long as the stopping condition was not reached (Section 4.5); p. 6, model.retrain (Train,Validate) … model.translate(inputset).) … and quantifying an improvement of the AI language model based on at least the validation result and the second validation result (e.g., p. 5, § 4.1, 3rd para., The framework repeats these steps as long as the stopping condition was not reached (Section 4.5); p. 8, § 4.5, 2. No more progress: The framework keeps track of the amount of remaining test samples. When the framework detects that that number has not changed in x iterations, meaning no progress was made during these iterations, it terminates.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Weber with the technique of Katz, such that it iteratively regenerates new output code after retraining the model until it no longer improves, because it would allow the model to “improve itself” and “focus training on aspects where the model is weaker,” as suggested by Katz (see p. 3, § 2.2.1, 1st para. and p. left col. 1st full para.).
Response to Arguments -- Claim Interpretation
Applicant' s arguments with respect to the claim interpretation under 35 USC 112(f) have been fully considered by Examiner but are not persuasive, as follows:
Applicant simply states that “the independent claims recite sufficient structure to perform the claimed function. For example, independent claim 1 recites a code analysis module of a computer. independent claim 10 [sic]4 recites an apparatus comprising: a memory; and a processing device. Independent claim 17 recites a processing device of a computer.”5 Examiner first notes that claim 17 was not interpreted under 35 USC 112(f). Furthermore, Applicant does not explain why or how these limitations provide sufficient structure to perform the claimed function.
Contrary to Applicant’s assertions, courts have recognized that terms such as “module”, as recited in claim 1, and “device”, as recited in claim 11, may be non-structural terms having no specific structural meaning (also called a “generic placeholder” or “nonce term”).6 In a specific example, the court held that a “distributed learning control module” failed to recite sufficient structure7. In the instant case, and similarly to “distributed learning control”, “code analysis” and “processing” merely describe the respective functions of the claimed “module” and “device” rather than imparting any particular structure to the “module” or “device”. Furthermore, “of a computer”, as recited in claim 1, merely describes the technological environment in which the “module” operates rather than imparting any definite structure to the “module”.
Applicant’s arguments are therefore unpersuasive. For additional details of the 35 USC 112(f) interpretation, please see the Claim Interpretation section above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Rudenko et al. US 20250004915 A1 teaches increasing a temperature parameter of a code fixing LLM to create a variety of responses.
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 STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 See pp. 5-6 on of the Non-Final Office action mailed on December 10, 2025.
2 See Applicant’s specification at [0054].
3 As noted above with respect to claim 1, 11, and 17, according to para. [0046] of the instant specification, the broadest reasonable interpretation of “validation result” includes a “validation score.”
4 This appears to be a typographical error that should be “independent claim 11”
5 See Remarks at p. 11.
6 See MPEP at § 2181(I)(A)
7See MPEP at § 2181(I)(A) and § 2181(I)(C)
Prosecution Insights