Prosecution Insights
Last updated: October 02, 2026
Application No. 18/818,325

MODULAR SUBSEQUENT GENERATIONS OF DEDICATED INTERMEDIATE REPRESENTATIONS

Final Rejection §103§112§DOUBLEPATENT
Filed
Aug 28, 2024
Examiner
RIVERA, ANIBAL
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
SAP SE
OA Round
4 (Final)
91%
Grant Probability
Favorable
5-6
OA Rounds
2m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 91% — above average
91%
Career Allowance Rate
692 granted / 761 resolved
+35.9% vs TC avg
Moderate +12% lift
Without
With
+11.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
40 currently pending
Career history
792
Total Applications
across all art units

Statute-Specific Performance

§101
14.4%
-25.6% vs TC avg
§103
44.6%
+4.6% vs TC avg
§102
25.1%
-14.9% vs TC avg
§112
8.6%
-31.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 761 resolved cases

Office Action

§103 §112 §DOUBLEPATENT
DETAILED ACTION This action is responsive to RCE filed on August 24, 2026. Claims 1, 6, 9-10, 13 and 18 have been amended. Claim 2 has been cancelled. Claims 3-5 and 15-17 were previously cancelled. Claims 1, 6-14 and 18-20 are pending and presented to examination. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 24, 2026 has been entered. 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. Response to Amendment The rejection of claims 9 and 10 under 35 U.S.C. 112(b) is withdrawn in view of the amendment. Claim 9 has been amended to depend from claim 1 and to recite “the generated intermediate representation received for each feature of the plurality of features”, and claim 10 has been amended to recite “the combined intermediate representation”. The rejection of claim 8 under 35 U.S.C. 112(b) is maintained for the reasons set forth below, claim 8 having not been amended. The objections to claims 1-2, 6-14 and 18-20 with respect to the plural recitations “the generated intermediate representations” and “the prompts” are withdrawn in view of the amendment. New objections and a new rejection under 35 U.S.C. 112(d) are set forth below, necessitated by the amendment. Applicant states at page 10 of the Remarks that a terminal disclaimer under 37 CFR 1.321(c) over U.S. Patent No. 12,632,650 is being filed concurrently with the response. No terminal disclaimer has been received. The nonstatutory double patenting rejection is accordingly maintained and is restated below as applied to the claims as amended. The rejection may be overcome by the filing of a terminal disclaimer in compliance with 37 CFR 1.321(c), accompanied by a request for reconsideration. See MPEP § 804, subsection I.B.1. Applicant’s amendment has necessitated the new grounds of rejection set forth below. In particular, the subject matter of cancelled claim 2, previously rejected over Capire, has been incorporated into independent claims 1, 13 and 18, and those claims further recite that the final representation is “in a different format than the generated intermediate representation”, a limitation not previously presented in any claim. Capire is accordingly applied to the independent claims herein. Claim Objections Claims 1, 6-14 and 18-20 are objected to because of the following informalities: Claims 1, 13 and 18 each recite “behind a prompt corresponding to the another feature”. The recitation “the another feature” is grammatically improper. Appropriate correction is required. Claims 1, 13 and 18 each recite, immediately following the amended singular ordering clause, the further text “prompts are sent to the LLM in an order determined by the tree structure, the order placing prompts corresponding to features that are dependent on other features behind prompts corresponding to the other features”. This text is the plural ordering clause that the amended singular clause was presented to replace, and it appears in the claim set without any indication of deletion. As presented, each of claims 1, 13 and 18 contains two ordering clauses reciting the same requirement in different terms, the second of which lacks proper antecedent basis for the plural “prompts”. For purposes of examination, the examiner interprets this text as having been intended for deletion, consistent with the Remarks at pages 7-8. Applicant is required to submit a replacement claim set that clearly indicates the status of this text. Dependent claims 6-12, 14 and 19-20 do not overcome the deficiencies of the base claims and, therefore, are objected to for the same reasons as the base claims. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 8 is 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. Claim 8 recites “wherein the generated intermediate representation is not compilable”. There is insufficient antecedent basis for this limitation in the claim. Claim 1, from which claim 8 depends, recites two separate and differently-scoped generated intermediate representations: “a generated intermediate representation for the second feature” recited within the tree-structure limitation, and “a generated intermediate representation for the feature” received from the LLM within the “for each feature” loop. It is therefore unclear which of these “the generated intermediate representation” in claim 8 refers to. For purposes of examination, the examiner interprets “the generated intermediate representation” in claim 8 as “the generated intermediate representation for the feature” received from the LLM. The following is a quotation of 35 U.S.C. 112(d): (d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph: Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Claim 14 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 14 recites “The method of claim 13, wherein the final representation is compilable computer code”. Claim 13, as amended, already recites “the final representation being compilable computer code and in a different format than the generated intermediate representation”. The limitation recited in claim 14 is therefore already required by claim 13, and claim 14 does not specify any further limitation of the subject matter claimed. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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. 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. Claims 1, 6-14 and 18-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,632,650 in view of Khot, in view of Besta, and further in view of Hirsch. Although the claims at issue are not identical, they are not patentably distinct from each other for the reasons set forth below. U.S. Patent No. 12,632,650 (“the ’650 Patent”) and the instant application are commonly owned by SAP SE. This is a nonstatutory double patenting rejection and is not a rejection under 35 U.S.C. 102 or 103; the ’650 Patent is not applied as prior art. The rejection may be overcome by the filing of a terminal disclaimer in compliance with 37 CFR 1.321(c). Instant Application (as amended) U.S. Pat. No. 12,632,650 1. A system comprising: at least one hardware processor; and a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising: receiving natural language text requesting automatic generation of generated text, the natural language text comprising a plurality of features of the generated text; generating a tree structure based on the natural language text, the tree structure containing a node corresponding to each feature of the plurality of features, with an edge between a first node corresponding to a first feature and a second node corresponding to a second feature signifying that the second feature depends on the first feature, wherein the dependency of the second feature on the first feature signifies that a generated intermediate representation for the second feature is generated based on a generated intermediate representation received for the first feature; for each feature in the plurality of features: generating a prompt for the feature; sending the prompt to a large language model (LLM); and receiving, from the LLM, a generated intermediate representation for the feature; wherein the prompt generated for each feature of the plurality of features is sent to the LLM in an order determined by the tree structure, the order placing a prompt corresponding to a feature that is dependent on another feature behind a prompt corresponding to the another feature; merging the generated intermediate representation received for each feature of the plurality of features into a combined intermediate representation; and passing the combined intermediate representation to a programmatic component, which validates the combined intermediate representation and converts the combined intermediate representation into a final representation, the final representation being compilable computer code and in a different format than the generated intermediate representation. 1. A system comprising: at least one hardware processor; and a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising: receiving natural language text describing compilable computer code to be generated in a compilable computer language; generating a prompt by adding a system message to the natural language text, the system message including an instruction to generate computer code in an intermediate representation in a language other than the compilable computer language; passing the prompt to a large language model (LLM), wherein the LLM is transformer-based; receiving, from the LLM, a generated intermediate representation; and passing the generated intermediate representation to a programmatic component, which validates the generated intermediate representation and converts the generated intermediate representation into a final representation, the final representation being compilable computer code. 13. A method comprising: receiving natural language text requesting automatic generation of generated text, the natural language text comprising a plurality of features of the generated text; generating a tree structure based on the natural language text, the tree structure containing a node corresponding to each feature of the plurality of features, with an edge between a first node corresponding to a first feature and a second node corresponding to a second feature signifying that the second feature depends on the first feature, wherein the dependency of the second feature on the first feature signifies that a generated intermediate representation for the second feature is generated based on a generated intermediate representation received for the first feature; for each feature in the plurality of features: generating a prompt for the feature; sending the prompt to a large language model (LLM); and receiving, from the LLM, a generated intermediate representation for the feature; wherein the prompt generated for each feature of the plurality of features is sent to the LLM in an order determined by the tree structure, the order placing a prompt corresponding to a feature that is dependent on another feature behind a prompt corresponding to the another feature; merging the generated intermediate representation received for each feature of the plurality of features into a combined intermediate representation; and passing the combined intermediate representation to a programmatic component, which validates the combined intermediate representation and converts the combined intermediate representation into a final representation, the final representation being compilable computer code and in a different format than the generated intermediate representation. 8. A method comprising: receiving natural language text describing compilable computer code to be generated in a compilable computer language; generating a prompt by adding a system message to the natural language text, the system message including an instruction to generate computer code in an intermediate representation in a language other than the compilable computer language; passing the prompt to a large language model (LLM), wherein the LLM is transformer-based; receiving, from the LLM, a generated intermediate representation; and passing the generated intermediate representation to a programmatic component, which validates the generated intermediate representation and converts the generated intermediate representation into a final representation, the final representation being compilable computer code. 18. A non-transitory machine-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving natural language text requesting automatic generation of generated text, the natural language text comprising a plurality of features of the generated text; generating a tree structure based on the natural language text, the tree structure containing a node corresponding to each feature of the plurality of features, with an edge between a first node corresponding to a first feature and a second node corresponding to a second feature signifying that the second feature depends on the first feature, wherein the dependency of the second feature on the first feature signifies that a generated intermediate representation for the second feature is generated based on a generated intermediate representation received for the first feature; for each feature in the plurality of features: generating a prompt for the feature; sending the prompt to a large language model (LLM); and receiving, from the LLM, a generated intermediate representation for the feature; wherein the prompt generated for each feature of the plurality of features is sent to the LLM in an order determined by the tree structure, the order placing a prompt corresponding to a feature that is dependent on another feature behind a prompt corresponding to the another feature; merging the generated intermediate representation received for each feature of the plurality of features into a combined intermediate representation; and passing the combined intermediate representation to a programmatic component, which validates the combined intermediate representation and converts the combined intermediate representation into a final representation, the final representation being compilable computer code and in a different format than the generated intermediate representation. 15. A non-transitory machine-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving natural language text describing compilable computer code to be generated in a compilable computer language; generating a prompt by adding a system message to the natural language text, the system message including an instruction to generate computer code in an intermediate representation in a language other than the compilable computer language; passing the prompt to a large language model (LLM), wherein the LLM is transformer-based; receiving, from the LLM, a generated intermediate representation; and passing the generated intermediate representation to a programmatic component, which validates the generated intermediate representation and converts the generated intermediate representation into a final representation, the final representation being compilable computer code. Instant claim 1 as amended and claim 1 of the ’650 Patent are not patentably distinct. Both recite a system comprising at least one hardware processor and a computer-readable medium storing instructions that, when executed, cause the processor to receive natural language text, to generate a prompt from that natural language text, to send the prompt to a large language model, to receive from the large language model a generated intermediate representation, and to pass an intermediate representation to a programmatic component which validates it and converts it into a final representation, the final representation being compilable computer code. The scope of the two claims is therefore substantially the same as to every step of the recited pipeline, including the requirement that the final representation be compilable computer code, a limitation that was previously recited only in instant claim 2 and that the amendment has now incorporated into the instant independent claims. The instant amendment has further narrowed, rather than widened, the difference between the two claim sets. Amended instant claim 1 requires that the final representation be “in a different format than the generated intermediate representation”. Claim 1 of the ’650 Patent recites the same distinction in different words, requiring that the intermediate representation be generated “in a language other than the compilable computer language” while the final representation is “compilable computer code”. A representation in a language other than the language of the final compilable code is necessarily in a format different from that of the final compilable code. The limitation added by the amendment is therefore anticipated by, or at minimum rendered obvious over, the corresponding limitation of the ’650 Patent claim. The ’650 Patent claim is in certain other respects narrower, additionally requiring that the natural language text describe compilable computer code to be generated in a compilable computer language and that the LLM be transformer-based. A narrower reference claim does not render the broader instant claim patentably distinct, because the instant claim is anticipated by, or at minimum rendered obvious over, the species the ’650 Patent claims. The same analysis applies to instant claim 13 as against claim 8 of the ’650 Patent and to instant claim 18 as against claim 15 of the ’650 Patent, those claims reciting the identical subject matter in method and machine-readable-medium form respectively. The instant independent claims further recite subject matter that is not found in the claims of the ’650 Patent, namely that the natural language text comprises a plurality of features of the generated text and that a prompt is generated and sent for each such feature; that a tree structure is generated containing a node for each feature with dependency-signifying edges having the recited meaning; that the prompt generated for each feature is sent in an order determined by the tree structure with dependent features behind the features they depend upon; and that the per-feature intermediate representations are merged into a combined intermediate representation. To the extent those recitations are not found in the claims of the ’650 Patent, they are taught by Khot and Besta, as set forth in the rejections under 35 U.S.C. 103 above. It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the invention claimed in claim 1 of the ’650 Patent so that the received natural language text comprises a plurality of features of the code to be generated and a separate prompt is generated for each such feature, as taught by Khot, for the reasons set forth in the rejection of claim 1 under 35 U.S.C. 103 above, Khot teaching that few-shot prompting “struggles as the task complexity increases” and that decomposition “allows each prompt to be optimized for its specific sub-task” (Khot, Abstract); and to further modify that invention so that the features are organized as a tree of nodes joined by dependency edges signifying that the representation for a dependent feature is generated using the representation received for the feature it depends upon, so that the prompt generated for each feature is sent in the order that tree prescribes, and so that the per-feature representations are merged into a combined representation, as taught by Besta, for the reasons set forth in the rejection of claim 1 under 35 U.S.C. 103 above, Besta teaching that such decomposition and merging improve output quality while reducing cost (Besta, Abstract and Section 7.2). Instant claim 14 (the final representation is compilable computer code) is not patentably distinct from the ’650 Patent, the final representation of claims 1, 8 and 15 of the ’650 Patent already being compilable computer code. Instant claim 6 corresponds to claims 2, 9 and 16 of the ’650 Patent; instant claim 7 corresponds to claims 3, 10 and 17; instant claim 8 corresponds to claims 4, 11 and 18; instant claim 9 corresponds to claims 5, 12 and 19; and instant claim 10 corresponds to claims 6, 13 and 20. These instant dependent claims are not patentably distinct from the corresponding claims of the ’650 Patent, each such reference claim depending from, and being combined only with, the independent claim of its own group. Instant claims 11 and 19 (the plurality of features does not represent all of the features in the natural language text) recite subject matter not found in the claims of the ’650 Patent and are rejected over those claims further in view of Khot, for the reasons set forth in the rejection of claim 11 under 35 U.S.C. 103 above. Instant claims 12 and 20 (exclusion of a feature based on a user selection in a graphical user interface) recite subject matter not found in the claims of the ’650 Patent and are rejected over those claims further in view of Hirsch, for the reasons set forth in the rejection of claim 12 under 35 U.S.C. 103 above. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1, 6-11, 13-14 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Anders Hejlsberg et al. (“Introducing TypeChat”, hereinafter “Hejlsberg” – previously presented) in view of Tushar Khot et al. (“Decomposed Prompting: A Modular Approach for Solving Complex Tasks”, hereinafter “Khot” – previously presented) in view of Maciej Besta et al. (“Graph of Thoughts: Solving Elaborate Problems with Large Language Models”, hereinafter ‘Besta” – previously presented) and further in view of Capire, (“Core Data Services CDS”, hereinafter “Capire” – previously presented). With respect to claim 1 (Currently Amended), Hejlsberg teaches A system comprising: at least one hardware processor; and a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising: (Hejlsberg discloses TypeChat as “an experimental library” that the developer uses by “hooking it up with any language model to work with your app” (Hejlsberg, introductory section), and sets forth source code by which an application instantiates the library, supplies it with a schema, and processes user requests interactively (Hejlsberg, “Enter TypeChat” section). A software library that is installed onto a host computer and executed so as to operate upon user input is necessarily embodied as instructions stored on a computer-readable medium of that computer and executed by at least one hardware processor of that computer; there is no other manner in which the disclosed library could perform the disclosed operations. Hejlsberg therefore teaches the recited system comprising at least one hardware processor and a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform the recited operations) receiving natural language text requesting automatic generation of generated text, the natural language text comprising [[a plurality of features of the generated text]] (Hejlsberg discloses that the disclosed technique is used to “take a user request and turn it into something our apps can operate on” (Hejlsberg, introductory section). Hejlsberg illustrates the received request with the user-supplied natural language sentence “Could I get a blueberry muffin and a grande latte?”, which is submitted under the instruction “Translate the following request into JSON” (Hejlsberg, “Pampering and Parsing” section). The request is thus natural language text, and it requests that a structured result be automatically generated from it rather than supplying that result itself. Receiving such a request accordingly reads on receiving natural language text requesting automatic generation of generated text. The bracketed portion is addressed below with respect to Khot) [[for each feature in the plurality of features:]] generating a prompt [[for the feature]] (Hejlsberg discloses that “The technique of combining a human prompt and a "response schema" is not necessarily unique” but is the technique the library employs, and that “we’ve been using TypeScript types in our prompts” (Hejlsberg, “Enter TypeChat” and “Just Add Types!” sections). Constructing, from the human request together with the response schema, the input that is thereafter submitted to the language model is the act of generating a prompt, and accordingly reads on the recited limitation. The bracketed portions are addressed below with respect to Khot) sending the prompt to a large language model (LLM) (Hejlsberg discloses code by which the developer can “hook TypeChat up to an LLM” (Hejlsberg, “Enter TypeChat” section), and discloses that the approach is not tied to any particular model because it operates with “any chat completion-style API” (Hejlsberg, “Open and Pluggable” section). Submitting the constructed prompt to the language model through such an interface reads on sending the prompt to a large language model (LLM)) receiving, from the LLM, a generated intermediate representation for the feature (Hejlsberg discloses that “we can ask LLMs to respond in the form of JSON, and they generally respond with something sensible” (Hejlsberg, “Pampering and Parsing” section), and illustrates the model returning such a JSON instance in the “ChatBot:” response. That returned JSON instance is intermediate rather than final: it is not the artifact the application ultimately consumes, but is instead the artifact that Hejlsberg thereafter validates and converts, as set forth below. Receiving that JSON instance from the language model in response to the prompt reads on receiving, from the LLM, a generated intermediate representation, and in the combination set forth below such a representation is received for each feature into which the request is decomposed) passing the combined intermediate representation to a programmatic component, which validates the combined intermediate representation and converts the combined intermediate representation into a final representation, [[the final representation being compilable computer code and in a different format than the generated intermediate representation]] (Hejlsberg discloses that “we can validate the response against them using the TypeScript compiler itself” (Hejlsberg, “Just Add Types!” section), that the library supplies “schema validation, repair” (Hejlsberg, “Enter TypeChat” section), and that the library is used “to retrieve structured AI responses that are type-safe” (Hejlsberg, introductory section). The TypeScript compiler is a deterministic, programmatically-coded component rather than a learned model, and is therefore a programmatic component. Passing the representation returned by the model to that component, which checks it for conformance to the schema and then yields the type-safe artifact that the application consumes, reads on passing the representation to a programmatic component which validates it and converts it into a final representation. In the combination set forth below, the representation so passed is the combined intermediate representation produced by the merging taught by Besta. The bracketed portion is addressed below with respect to Capire) Hejlsberg is silent to disclose the following limitations; however, in an analogous art, Khot teaches: a plurality of features of the generated text (Khot is directed to solving a complex request by “decomposing them (via prompting) into simpler sub-tasks” (Khot, Abstract). Khot teaches that “the core is a decomposer LLM that tries to solve a complex task by generating a prompting program P” and that “Each step of P directs a simpler sub-query to a function” (Khot, Section 3), and that “Each sub-task is then delegated to the corresponding sub-task handler” (Khot, Figure 1). Critically, the decomposition is derived from the received natural language query itself: the decomposer is an LLM that reads the query and emits the program, Khot teaching “sub-task specific LLMs, with both the decomposer and the sub-task LLMs (henceforth, sub-task handlers) having their own few-shot prompts” (Khot, Section 1) and that “the decomposer defines the top-level program for the complex task” (Khot, Section 1). Each simpler sub-task so identified from the request is a separately-requested constituent of the output that the request asks to be produced, and is separately prompted for and separately answered. The set of such constituents identified from the received request therefore reads on the natural language text comprising a plurality of features of the generated text) for each feature in the plurality of features: generating a prompt for the feature (Khot teaches that the decomposer generates, for each decomposed sub-task in turn, a corresponding sub-query directed to that sub-task’s handler: the program P is a sequence in which “Each step of P directs a simpler sub-query to a function” (Khot, Section 3), and “Each sub-task is then delegated to the corresponding sub-task handler” (Khot, Figure 1), each such handler having “their own few-shot prompts” (Khot, Section 1). Khot teaches that this per-sub-task prompting is the point of the architecture, because the modular structure “allows each prompt to be optimized for its specific sub-task” (Khot, Abstract). Generating, for each decomposed sub-task (feature) of the plurality, the separate prompt directed to that feature reads on, for each feature in the plurality of features, generating a prompt for the feature) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the single-prompt natural-language-to-structured-output translation of Hejlsberg so that the received natural language request is decomposed into a plurality of features of the output to be generated, and so that a separate prompt is generated for each such feature and separately sent to the large language model, as taught by Khot. Khot expressly identifies the problem that motivates the modification, teaching that few-shot prompting “struggles as the task complexity increases” (Khot, Abstract), and expressly identifies decomposition as the solution to that problem because the resulting modular structure “allows each prompt to be optimized for its specific sub-task” (Khot, Abstract). A person of ordinary skill would have been motivated to apply Khot’s decomposition to Hejlsberg’s schema-guided generation in order to keep each request within the practical input limits of the language model, to prevent any one requested feature from being diluted or dropped when many features are requested in a single prompt, and to permit each feature’s prompt to be independently optimized and its result independently validated and repaired by Hejlsberg’s validation component. Hejlsberg and Khot are in the same field of endeavor, namely prompting a large language model so as to obtain a structured, machine-consumable result, and the combination applies the known technique of Khot (modular decomposition of a complex request into per-sub-task prompts) to the known and improvable system of Hejlsberg (schema-guided generation with compiler-based validation) to yield no more than the predictable result of reliably generating multi-feature structured output. Hejlsberg in view of Khot is silent to disclose the following limitations; however, in an analogous art, Besta teaches: generating a tree structure based on the natural language text, the tree structure containing a node corresponding to each feature of the plurality of features, with an edge between a first node corresponding to a first feature and a second node corresponding to a second feature signifying that the second feature depends on the first feature (Besta teaches modeling the information a large language model generates as a structure of nodes joined by dependency edges: “In GoT, an LLM thought is modeled as a vertex, while an edge is a dependency between such thoughts” (Besta, Section 1). Besta formalizes the structure, teaching “We model the reasoning process as a directed graph G = (V, E); V is a set of vertices and E ⊆ V × V is a set of edges” and that “A vertex contains a solution to a problem at hand (be it an initial, intermediate, or a final one)” (Besta, Section 3.1). Besta’s Generation transformation constructs precisely the recited tree: “one can generate one or more new thoughts based on an existing single thought v”, formally “V + = {v+ 1 ,...,v+ k} and E+ = {(v,v+ 1),...,(v,v+ k)}” (Besta, Section 3.2) — that is, a parent node v together with k child nodes, each child joined to the parent by a single directed edge, which is a tree. Besta further teaches that the vertices need not be abstract reasoning steps but may be the constituent parts of the work product itself, and may be of different classes: “in writing tasks, some vertices model plans of writing a paragraph, while other vertices model the actual paragraphs of text” (Besta, Section 3.1), and “a single thought can be a paragraph (e.g., in article summary), a document (e.g., in document generation), a block of code (e.g., in code debugging or optimization), and so on” (Besta, Section 2.1). Applied to the plurality of features into which Khot decomposes the received natural language request, each such feature is modeled as a vertex, and a directed edge drawn from the vertex of a first feature to the vertex of a second feature is, by Besta’s own definition, a dependency of the second upon the first. Because the features are themselves derived from the natural language text by Khot’s decomposer, the resulting structure is generated based on the natural language text. This reads on the recited limitation) wherein the dependency of the second feature on the first feature signifies that a generated intermediate representation for the second feature is generated based on a generated intermediate representation received for the first feature (Besta does not leave the meaning of a dependency edge to inference; Besta expressly defines it, and defines it as the very generation relationship recited. Besta teaches: “A directed edge (t1, t2) indicates that thought t2 has been constructed using t1 as "direct input", i.e., by explicitly instructing the LLM to use t1 for generating t2” (Besta, Section 3.1). Each vertex of Besta’s structure holds a representation that the language model produced — “A vertex contains a solution to a problem at hand (be it an initial, intermediate, or a final one)” (Besta, Section 3.1) — and the conversation with the model consists of “user messages (prompts) and LLM replies (thoughts)” (Besta, Section 2.1). Accordingly, in Besta an edge from a first vertex to a second vertex signifies, by definition, that the representation occupying the second vertex was generated by explicitly instructing the language model to use, as direct input, the representation already received for the first vertex. Applied to the per-feature intermediate representations of the Hejlsberg-Khot combination, in which a separate intermediate representation is received from the LLM for each feature, the dependency of a second feature upon a first feature signifies that a generated intermediate representation for the second feature is generated based on a generated intermediate representation received for the first feature. This reads on the recited limitation) wherein the prompt generated for each feature of the plurality of features is sent to the LLM in an order determined by the tree structure, the order placing a prompt corresponding to a feature that is dependent on another feature behind a prompt corresponding to the another feature (Besta teaches that the structure itself prescribes the order in which the model is prompted. Besta’s Graph of Operations “is a static structure that specifies the graph decomposition of a given task, i.e., it prescribes transformations to be applied to LLM thoughts, together with their order & dependencies” (Besta, Section 4), and “Each operation object knows its predecessor and successor operations” (Besta, Section 4.5). The Controller decides “whether the next round of interaction with the LLM should be initiated”, and “this is dictated by the execution plan specified in the GoO” (Besta, Section 4.4). Moreover, the recited ordering is a necessary consequence of Besta’s edge semantics: because a directed edge (t1, t2) requires the model to be instructed “to use t1 for generating t2” (Besta, Section 3.1), the representation t1 must already have been generated and received before the prompt for t2 can be composed and sent. A dependent thought is therefore necessarily prompted for behind the thought it depends upon. Besta’s worked decomposition confirms this ordering in practice, the input first being split, each part then being separately processed, and the results only thereafter being aggregated (Besta, Figure 4). Sending the per-feature prompts of the combination in the order so prescribed reads on the recited limitation) merging the generated intermediate representation received for each feature of the plurality of features into a combined intermediate representation; and (Besta teaches an express Aggregation transformation that merges separately generated representations into a single combined one. Besta teaches that “one can aggregate arbitrary thoughts by constructing vertices that have more than one incoming edge” (Besta, Section 1), and formalizes the transformation as “V + = {v+} and E+ = {(v1,v+),..., (vk,v+)}, where v1,...,vk are the merged k thoughts” (Besta, Section 3.2) — that is, k separately generated representations combined into one new representation. Besta teaches that this is the very purpose for which the framework is suited: “GoT is particularly well-suited for tasks that can be naturally decomposed into smaller subtasks that are solved individually and then merged for a final solution” (Besta, Section 1), and that its measured advantages are “due to GoT’s ability to decompose complex tasks into simpler subtasks, solve these subtasks independently, and then incrementally merge these outcomes into the final result” (Besta, Section 7.2). Besta illustrates the transformation both for structured data and for text, “Merging sorted subarrays into a sorted array of numbers” and “Combining articles into a coherent summary” (Besta, Figure 2). Merging the separately received per-feature intermediate representations of the combination into the single aggregated representation so taught reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to organize the plurality of features of the Hejlsberg-Khot combination as a tree structure of nodes joined by dependency edges having the meaning Besta assigns them, to send the per-feature prompts in the order that tree prescribes with dependent features behind the features they depend upon, and to merge the resulting per-feature intermediate representations into a combined intermediate representation, as taught by Besta. Besta expressly identifies both the problem and the benefit that motivate the modification, teaching that decomposing a task and merging the sub-results improves the quality of the generated output while reducing cost, “increasing the quality of sorting by 62% over ToT, while simultaneously reducing costs by >31%” (Besta, Abstract), and explaining that these advantages are “due to GoT’s ability to decompose complex tasks into simpler subtasks, solve these subtasks independently, and then incrementally merge these outcomes into the final result” (Besta, Section 7.2). A person of ordinary skill would have been strongly motivated to adopt Besta’s model here because the Hejlsberg-Khot combination already generates a separate intermediate representation for each feature and must thereafter reassemble them into a single result, which is precisely the class of task Besta identifies as best suited to its framework. Further, the features of a requested output are commonly interdependent, and Besta teaches that where a later thought must consume an earlier one the edge is drawn and the later thought is generated by instructing the model to use the earlier as direct input (Besta, Section 3.1); capturing those interdependencies as edges and honoring them in the order of prompting predictably prevents a dependent feature from being generated before the representation it consumes exists, and thereby improves the correctness of the merged result. Besta and the combination are in the same field of endeavor, namely prompting a large language model to produce and then combine structured intermediate results, and the modification applies Besta’s known graph-and-aggregation technique to the known and improvable per-feature generation pipeline of Hejlsberg and Khot to yield no more than the predictable result Besta itself reports. Hejlsberg in view of Khot in view of Besta is silent to disclose the following limitation; however, in an analogous art, Capire teaches: the final representation being compilable computer code and in a different format than the generated intermediate representation (Capire is the “Language Reference Documentation” for Core Data Services and discloses a pipeline in which a captured model is held in one format and is thereafter compiled into a different, compilable target format. Capire discloses that “CDS features to parse from a variety of source languages and to compile them into various target languages” (Capire, p. 1), and illustrates that pipeline expressly: source languages (CDS, JSON, YAML, Code) are parsed into a { CSN } representation, and that { CSN } representation is thereafter compiled into target languages including OData, Open API, Async API, JSON/YAML, SQL DDL and HANA DDL (Capire, p. 1, figure). Capire discloses the format of the parsed representation, teaching that “CDS models are plain JavaScript objects complying to the Core Schema Notation (CSN), an open specification derived from JSON Schema” (Capire, p. 2) and describing the “Specification of CSN, CDS’ canonical format for representing CDS models as plain JavaScript objects, similar to JSON Schema” (Capire, p. 2); Capire likewise teaches that the models are captured “in plain (JavaScript) object notations” (Capire, p. 1). Capire thus teaches two distinct formats within a single pipeline: the CSN representation, which is a plain-JavaScript-object notation resembling JSON Schema, and the compiled target artifacts such as SQL DDL and HANA DDL, which are in a different format from CSN. That the target artifacts are compilable computer code is confirmed by Capire’s repeated reference to the compiler that consumes and emits them, Capire disclosing annotations “supported by the CDS compiler and runtimes”, a section of “Compiler Messages”, and a versioned “CDS compiler version 2 (cv2)” (Capire, p. 3). Applied to the combination, in which the intermediate representation received from the LLM is a JSON artifact and is merged into a combined intermediate representation, the conversion of that combined representation into a compiled target artifact yields a final representation that is compilable computer code and that is in a different format than the generated intermediate representation. This reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to configure the programmatic component of the Hejlsberg-Khot-Besta combination so that it converts the combined intermediate representation into a final representation that is compilable computer code in a different format than the generated intermediate representation, as taught by Capire, in which “CDS features to parse from a variety of source languages and to compile them into various target languages” (Capire, p. 1). A person of ordinary skill would have been motivated to make this modification in order to obtain a directly compilable and executable artifact from the validated combined representation rather than a mere data structure requiring further manual treatment, which is the very purpose Capire identifies for compiling a captured model into target languages such as SQL DDL and HANA DDL (Capire, p. 1, figure). The combination is particularly natural here because the artifact the language model returns in Hejlsberg is JSON, and the representation Capire’s compiler consumes is a plain-JavaScript-object notation “similar to JSON Schema” (Capire, p. 2), so that the combined intermediate representation of the combination is already in substantially the form Capire’s toolchain accepts as its input. A person of ordinary skill would further have recognized that the format of a compiled target artifact necessarily differs from the format of the model from which it is compiled, that being the ordinary consequence of compilation as Capire describes it. The modification therefore applies a known compilation step to a known and improvable validated representation to yield no more than the predictable result of producing compilable computer code in the target format. With respect to claim 6 (Currently Amended), Hejlsberg in view of Khot in view of Besta is silent to disclose the following limitation; however, in an analogous art, Capire teaches wherein the compilable computer code is in a format that is at least partially proprietary (Capire discloses that “CDS is the backbone of the SAP Cloud Application Programming Model (CAP)” (Capire, p. 1). CDS is thus a language whose definition, compiler and runtimes are controlled and versioned by a single vendor, Capire being that vendor’s own language reference documentation and disclosing both annotations “supported by the CDS compiler and runtimes” and a vendor-issued “CDS compiler version 2 (cv2)” to which “All projects are recommended to upgrade as soon as possible” (Capire, p. 3). A format whose specification and toolchain are so controlled by a single entity is proprietary. That the format is at least partially rather than wholly proprietary is confirmed by Capire itself, which discloses that the notation to which CDS models comply is “an open specification derived from JSON Schema” (Capire, p. 2). Capire therefore teaches a format that is at least partially proprietary, which reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to provide the compilable computer code of the Hejlsberg-Khot-Besta-Capire combination in the at-least-partially-proprietary CDS format taught by Capire, in which “CDS is the backbone of the SAP Cloud Application Programming Model (CAP)” (Capire, p. 1). A person of ordinary skill would have been motivated to do so in order to emit code in the single controlled format that the vendor’s own compiler and runtimes support, thereby obtaining the reliability benefits of the intermediate-representation-and-validation pipeline of the combination while producing output directly consumable by that established toolchain, which is a predictable result. With respect to claim 7 (Original), Hejlsberg in view of Khot in view of Besta is silent to disclose the following limitation; however, in an analogous art, Capire teaches wherein the compilable computer code is a Core Data Services (CDS) model (Capire is directed on its face to “Core Data Services (CDS)” and is the “Language Reference Documentation” therefor (Capire, p. 1). Capire discloses the artifact expressly: “CDS models are plain JavaScript objects complying to the Core Schema Notation (CSN), an open specification derived from JSON Schema” (Capire, p. 2), and further discloses the “Specification of CSN, CDS’ canonical format for representing CDS models as plain JavaScript objects, similar to JSON Schema” (Capire, p. 2). Capire discloses that such captured models are what its toolchain compiles into target languages (Capire, p. 1 and p. 1, figure). Producing the compilable computer code of the combination as such a CDS model reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to provide the compilable computer code of the Hejlsberg-Khot-Besta-Capire combination as a Core Data Services (CDS) model, as taught by Capire, which is the “Language Reference Documentation” for that model format and describes such models being compiled into target languages (Capire, p. 1). A person of ordinary skill would have been motivated to apply the combination to generate CDS models in order to automate the production of the very declaratively-captured, compilable data model that Capire describes being authored, and because CDS models are already “plain JavaScript objects” (Capire, p. 2), which is the same class of structured artifact that Hejlsberg’s pipeline already validates and emits. The modification therefore yields no more than the predictable result of automatically generating an artifact of a format the prior art already produces by hand. With respect to claim 8 (Original), and consistent with the interpretation set forth in the rejection under 35 U.S.C. 112(b) above, Hejlsberg further teaches wherein the generated intermediate representation is not compilable (Hejlsberg discloses that the representation returned by the language model is JSON, teaching that “we can ask LLMs to respond in the form of JSON” (Hejlsberg, “Pampering and Parsing” section), and identifies JSON expressly as “JavaScript Object Notation” (Hejlsberg, “Just Add Types!” section). JSON is a notation for representing data values, not a programming language that is submitted to a compiler in order to produce an executable; it is for that very reason that Hejlsberg must thereafter validate the returned JSON and convert it into the artifact the application consumes. The generated intermediate representation disclosed by Hejlsberg is accordingly not compilable, which reads on the recited limitation) With respect to claim 9 (Currently Amended), Hejlsberg further teaches wherein the generated intermediate representation received for each feature of the plurality of features is a JavaScript Object Notation (JSON) file (Hejlsberg discloses that the language model is asked “to respond in the form of JSON, and they generally respond with something sensible” and illustrates the returned JSON instance in the “ChatBot:” response (Hejlsberg, “Pampering and Parsing” section), and identifies JSON expressly as “JavaScript Object Notation” (Hejlsberg, “Just Add Types!” section). In the combination, in which a separate representation is received from the language model for each feature of the plurality, each such representation is a JavaScript Object Notation (JSON) file, which reads on the recited limitation) With respect to claim 10 (Currently Amended), Hejlsberg further teaches wherein the programmatic component automatically corrects one or more errors in the combined intermediate representation (Hejlsberg discloses that the library supplies “schema validation, repair” (Hejlsberg, “Enter TypeChat” section), and that “the error feedback from the compiler can even be used to guide repairs” (Hejlsberg, “Just Add Types!” section). Using the compiler’s error feedback to automatically repair a representation that does not conform to the schema reads on the programmatic component automatically correcting one or more errors in the representation, and in the combination the representation passed to that component is the combined intermediate representation) With respect to claim 11 (Original), Hejlsberg in view of Besta in view of Capire is silent to disclose the following limitation; however, in an analogous art, Khot further teaches wherein the plurality of features in the natural language text does not represent all of the features in the natural language text (Khot teaches that the decomposer does not enumerate everything expressed in the request, but selects only certain sub-tasks with which to solve it: Decomposed Prompting “uses the decomposer prompt to only describe the procedure to solve the complex tasks using certain subtasks” (Khot, Figure 1). Because only certain sub-tasks (features) are selected by the decomposer from the received request, the plurality of features that is operated upon need not, and in Khot does not, encompass every feature expressed in the natural language text. This reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to limit the plurality of features processed by the Hejlsberg-Khot-Besta-Capire combination to fewer than all of the features expressed in the natural language text, as taught by Khot’s selection of “certain subtasks” (Khot, Figure 1). A person of ordinary skill would have been motivated to do so in order to conserve processing and token resources and to direct generation only to those features relevant to the desired output, which is the predictable benefit of the selective decomposition Khot describes. With respect to claim 13, the claim is directed to a method that recites limitations similar to those recited in claim 1 and is rejected for the same reasons set forth above with respect to claim 1 (see the citations to Hejlsberg, Khot, Besta and Capire set forth with respect to claim 1). With respect to claim 14, and notwithstanding the rejection under 35 U.S.C. 112(d) set forth above, the claim recites limitations similar to those recited in the final-representation limitation of claim 13 and is rejected for the same reasons set forth above with respect to claim 13 (see the citations to Capire set forth with respect to claim 1). With respect to claim 18, the claim is directed to a non-transitory machine-readable medium that recites limitations similar to those recited in claim 1 and is rejected for the same reasons set forth above with respect to claim 1, wherein Hejlsberg further teaches the recited non-transitory machine-readable medium storing instructions, Hejlsberg disclosing “an experimental library” (Hejlsberg, introductory section) that is necessarily embodied as stored, executable instructions. With respect to claim 19, the claim recites limitations similar to those recited in claim 11 and is rejected for the same reasons set forth above with respect to claim 11 (see the citations to Khot set forth with respect to claim 11). Claims 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Anders Hejlsberg et al. (“Introducing TypeChat”, hereinafter “Hejlsberg” – previously presented) in view of Tushar Khot et al. (“Decomposed Prompting: A Modular Approach for Solving Complex Tasks”, hereinafter “Khot” – previously presented) in view of Maciej Besta et al. (“Graph of Thoughts: Solving Elaborate Problems with Large Language Models”, hereinafter ‘Besta” – previously presented) in view of Capire, (“Core Data Services CDS”, hereinafter “Capire” – previously presented) and further in view of Hirsch et al. (US Pub. No. 2013/0305218, hereinafter “Hirsch” – previously presented). With respect to claim 12 (Original), Hejlsberg in view of Khot in view of Besta in view of Capire is silent to disclose; However, in an analogous art, Hirsch teaches this limitation wherein at least one feature that is not in the plurality of features but that is in the natural language text is excluded from the plurality of features based on a selection of the at least one feature by a user in a graphical user interface (Hirsch is directed to automatically generating an application in accordance with a user’s specification of the features it is to contain, and teaches “an intuitive, user-friendly, graphical user interface” through which “the user may select, combine and customize various predefined and user-uploaded components, including modules” (Hirsch, paragraph [0023]). Hirsch teaches that “selections are received from the user related to the customizable components presented to the user” (Hirsch, paragraph [0019]), and that the user is thereby “specifying the particular features, content, and layout of a desired mobile application” (Hirsch, paragraph [0023]). By the user selecting, in the graphical user interface, which of the presented items are incorporated into the generated application, an item that is presented to the user but that is not selected is thereby excluded from those that are incorporated. Applied to the combination, in which Khot already selects only certain features from the received natural language text so that fewer than all such features are operated upon (see the rejection of claim 11 above), Hirsch supplies the graphical user interface by which that selection is made by the user, so that a feature present in the natural language text but not selected is excluded from the plurality of features. This reads on the recited limitation) It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the Hejlsberg-Khot-Besta-Capire combination so that the exclusion of a feature present in the natural language text from the plurality of features operated upon is made on the basis of a user’s selection in a graphical user interface, as taught by Hirsch. Hirsch identifies the benefit that motivates the modification, teaching “an intuitive, user-friendly, graphical user interface” through which the user is “specifying the particular features, content, and layout of a desired mobile application” (Hirsch, paragraph [0023]). A person of ordinary skill would have been motivated to do so because the combination already operates on fewer than all of the features expressed in the request, and therefore already requires that some determination be made as to which features are carried forward; Hirsch teaches that letting the user make that determination through a graphical interface yields an application that matches the user’s actual intent, avoids expending generation effort on unwanted features, and does so without requiring the user to re-author the natural language request. Hirsch and the combination are in the same field of endeavor, namely automatically generating a software artifact in accordance with a user’s specification of the features it is to contain, and the modification applies Hirsch’s known graphical selection technique to the known and improvable feature-selection step of the combination to yield no more than the predictable result of user-directed feature selection. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007); MPEP 2143(I)(A) and (I)(D). With respect to claim 20, the claim recites limitations similar to those recited in claim 12 and is rejected for the same reasons set forth above with respect to claim 12 (see the citations to Hirsch set forth with respect to claim 12). Response to Arguments Applicant’s arguments filed August 24, 2026 have been fully considered. To the extent they are directed to the grounds of rejection newly presented in this action, they are moot. To the extent they are directed to the rejections maintained herein, they are not persuasive. The following is provided for completeness. A. The arguments are directed to claim limitations that were not filed. Applicant’s Remarks at pages 7 and 9 state that claim 8 has been cancelled and that “the limitation that the per-feature representation is not compilable has been incorporated into claims 1, 13, and 18 within the receiving step”. Applicant’s Remarks at page 14 state that claims 2 and 14 have been cancelled. The claim listing as filed does not so read. Claim 8 is designated “(Original)” and remains a pending dependent claim reciting “wherein the generated intermediate representation is not compilable”; claim 14 is designated “(Original)” and remains pending; and the receiving step of claims 1, 13 and 18 as filed recites only “receiving, from the LLM, a generated intermediate representation for the feature”, without any recitation that the representation so received is not compilable. Applicant’s arguments in Sections II and IV of the Remarks proceed from the premise that the independent claims require that every intermediate representation the large language model returns is not compilable. The independent claims as filed contain no such requirement. Arguments directed to limitations that do not appear in the claims are not persuasive. See MPEP 2145. The claims have been examined as filed. Should Applicant wish to place the “not compilable” limitation in the independent claims, an amendment doing so would be considered on its merits. B. Applicant’s Section IV (the claimed allocation between the LLM and the programmatic component) is not persuasive as to the claims as filed. Applicant argues that the amended claims allocate the production of the compilable artifact to the programmatic component and distinguish that artifact in format from what the large language model returns, and that the cited references do not teach that allocation. As set forth above, the independent claims as filed require only that the programmatic component convert the combined intermediate representation into a final representation that is compilable computer code and in a different format than the generated intermediate representation. They do not require that the representation returned by the language model be incapable of compilation. Capire, which was of record and applied to cancelled claim 2 in the previous action, teaches the limitation as filed. Capire discloses a pipeline in which representations are parsed into a { CSN } representation and thereafter compiled into target languages including SQL DDL and HANA DDL (Capire, p. 1 and p. 1, figure), teaching that “CDS features to parse from a variety of source languages and to compile them into various target languages” (Capire, p. 1). Capire discloses the format of the parsed representation as “plain JavaScript objects complying to the Core Schema Notation (CSN), an open specification derived from JSON Schema” (Capire, p. 2), which is a different format from the compiled target artifacts. Capire therefore teaches both that the final artifact is compilable computer code and that it is in a different format than the representation from which it was compiled. The conversion is performed by the compiler, a deterministic programmatic component, Capire disclosing annotations “supported by the CDS compiler and runtimes” and a versioned “CDS compiler version 2 (cv2)” (Capire, p. 3). Applicant’s Section V argues that Capire “is not relied upon for, and does not teach, the allocation discussed in Section IV above” and that Capire does not describe generating separate intermediate representations for respective features according to a dependency tree or merging those representations. Capire is not relied upon for those limitations. The per-feature decomposition and prompting are taught by Khot, and the tree structure, the dependency edges and their meaning, the tree-determined ordering, and the merging are taught by Besta, as set forth in the rejection above. One cannot show nonobviousness by attacking references individually where the rejection is based on a combination of references. See In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck & Co., 800 F.2d 1091 (Fed. Cir. 1986); MPEP 2145(IV). C. Applicant’s Section VI (claims 12 and 20) is not persuasive. Applicant argues that Hirsch presents for selection only predefined components, modules, app-types, themes, templates and user-uploaded content, that Hirsch does not receive natural language text or identify features within natural language text, and that the mapping therefore requires an unsupported repurposing of Hirsch’s interface. The argument attacks Hirsch individually. Hirsch is not relied upon for receiving natural language text or for identifying features within it; those limitations are taught by Hejlsberg and Khot respectively, as set forth in the rejection of claim 1 above. Hirsch is relied upon for the teaching that a user selects, in a graphical user interface, which of the items presented to the user are incorporated into the automatically generated application, so that an item not selected is excluded (Hirsch, paragraphs [0019] and [0023]). Both Hirsch and the combination are directed to automatically generating a software artifact in accordance with a user’s specification of the features it is to contain, and the motivation to apply Hirsch’s graphical selection to the feature-selection step already present in the combination is set forth with particularity above. D. Applicant's Section III (the nonstatutory double patenting rejection). Applicant states at page 10 of the Remarks that a terminal disclaimer under 37 CFR 1.321(c) over U.S. Patent No. 12,632,650 is being filed concurrently with the response, and requests withdrawal of the rejection on that basis. No terminal disclaimer has been received in this application. The nonstatutory double patenting rejection is therefore maintained, and is restated above as applied to the claims as amended. The examiner notes that the amendment has narrowed rather than widened the difference between the instant independent claims and the claims of the ’650 Patent, the limitation that the final representation be compilable computer code having been moved from cancelled claim 2 into the instant independent claims. Upon receipt of a terminal disclaimer in compliance with 37 CFR 1.321(c), accompanied by a request for reconsideration, the rejection will be withdrawn. E. The rejections and objections under 35 U.S.C. 112 and the claim objections. The rejection of claims 9 and 10 under 35 U.S.C. 112(b) is withdrawn in view of the amendment. The rejection of claim 8 under 35 U.S.C. 112(b) is maintained, claim 8 having not been amended and “the generated intermediate representation” remaining without a single antecedent in claim 1, as set forth above. The objections to the plural recitations “the generated intermediate representations” and “the prompts” are withdrawn in view of the amendment. New objections, and a new rejection of claim 14 under 35 U.S.C. 112(d), are set forth above and are necessitated by the amendment. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM. 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 at 5712726799. 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. /ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Read full office action

Prosecution Timeline

Show 5 earlier events
Jul 22, 2026
Final Rejection mailed — §103, §112, §DOUBLEPATENT
Aug 12, 2026
Applicant Interview (Telephonic)
Aug 12, 2026
Examiner Interview Summary
Aug 24, 2026
Request for Continued Examination
Aug 26, 2026
Response after Non-Final Action
Sep 01, 2026
Non-Final Rejection mailed — §103, §112, §DOUBLEPATENT
Sep 14, 2026
Response Filed
Sep 30, 2026
Final Rejection mailed — §103, §112, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12748576
Graph Analysis and Manipulation
2y 9m to grant Granted Sep 29, 2026
Patent 12748585
HOT UPGRADE WORKFLOW PROCESS IN AN EDGE COMPUTING ENVIRONMENT
2y 5m to grant Granted Sep 29, 2026
Patent 12743366
TEST SEQUENCE FOR STOP-AT-FIRST-FAIL TESTING
3y 0m to grant Granted Sep 22, 2026
Patent 12724698
Automated Assistive-Technology Driven Accessibility Testing Environments
2y 10m to grant Granted Sep 01, 2026
Patent 12717567
ENHANCED DEVICE UPDATING
3y 8m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

5-6
Expected OA Rounds
91%
Grant Probability
99%
With Interview (+11.9%)
2y 3m (~2m remaining)
Median Time to Grant
High
PTA Risk
Based on 761 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month