Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to claims filed 10/31/2024. Claims 1-17 have been examined.
DETAILED ACTION
Priority
This application is filed on 10/31/2024 and claims benefit of PRO 63/699,263 filed on 9/26/2024.
Information Disclosure Statement
Information Disclosure Statement (IDS) is not filed with this application.
Drawings
The drawings are objected to because of the following:
FIG. 1 and FIG. 5-7 have the same identical brief description of the drawings in [0013], [0015], and [0016]. Examiner would appreciate the brief description to include the high-level difference for FIG. 5-7 drawings with respect to FIG. 1 drawing for the example system.
T
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 1 is objected to because of the following informalities:
“App” is not explicitly defined. For examination purposes, Examiner will interpret “app” as meaning “software application”.
Dependent claims (claims 2, 7-10) use the language “determined respective app characteristic” vs. claim 1 which uses “respective determined app characteristic”. Please use a consistent term across all claims. For examination purposes, wherever either term appears in the claims, Examiner will interpret it as “determined respective app characteristic” based on the claim 1 limitation citing “determining the respective app characteristic…”.
Appropriate correction is required.
Specification Objections
The abstract of the disclosure is objected to because the abstract does not provide a summary of the invention and is rather a verbatim copy of claim 1 as one continuous long sentence. Furthermore, simply saying “improved creation” does not provide any insight on the improvement of the claimed innovation. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: GRAPH-MODEL-BASED APP CHARACTERISTICS, AND APP, CREATION FROM NATURAL LANGUAGE PROMPT .
The disclosure is objected to because of the following informalities:
The specification recites “suitable” in [0043] “one or more suitable app characteristics 122 may be selected from the default app characteristics….of a suitable app”, “corresponding” in [0047] “to derive corresponding app characteristics” and in [0031] “create a corresponding app 120”, and many occurrences of “respective” like in [0049] “determine the respective app characteristic 122”, in [0050] “respective default app characteristic”, “respective well-matching default app characteristic” etc.. Examiner is unclear what the difference is between these 3 terms “respective”, “suitable”, and “corresponding” and if they refer to the same meaning. Applicant is requested to clarify the definition of the 3 terms listed. If these 3 terms mean the same thing, then Applicant is requested to use the same term throughout the application for consistency and clarity of the record.
For clarity purposes, the statement in [0063] needs to be split into 2 sentences, such that one describes the respective default app characteristic, and the second describes the respective app characteristic. [0063] “The respective default app characteristic 132 and the respective app characteristic 122 may include a (default) model, a (default) workflow 140, or a (default) API, wherein entities 138 may be included by the model, and wherein data processed by the workflow 140 may be communicated from or to another data resource via the API”.
Appropriate correction is required.
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 1-17 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.
Claim 1 recites the limitations “received user input” and “the respective app characteristic” in "providing a default program prompt associated with a large language model, wherein the default program prompt comprises a first prompt to generate one or more function calls relating to default app characteristics matching received user input" and in “determining the respective app characteristic using the default program prompt, the received user input, and the large language model”, respectively. There is insufficient antecedent basis for these limitations in the claim.
For examination purposes, relating to the “the received user input”, Examiner will reorder limitations in claim 1 and interpret it such as recited below, where the limitation “receiving …user input …characteristic of the app” is placed ahead of “received user input”. For examination purposes, for “the respective app characteristic”, Examiner will interpret that as the user-input-indicated app characteristic.
Re-ordered claim 1 limitations for examination purposes:
“A computer-implemented method of creating an app comprising app characteristics, the method comprising: providing an app development user interface (UI) of an app development platform to a user for developing the app; receiving natural language user input indicative of at least one app characteristic of the app; providing a default program prompt associated with a large language model; wherein the default program prompt comprises a first prompt to generate one or more function calls relating to default app characteristics matching received user input; determining the respective app characteristic using the default program prompt, the received user input, and the large language model; and developing the app using the respective determined app characteristic”.
Claims 2-6, 9, 13-15 are rejected by virtue of being dependent on claim 1.
Claims 7 and 10 are rejected by virtue of being dependent on claim 6 and 9 respectively.
Claims 8 and 11 are rejected by virtue of being dependent on claim 7 and 10 respectively.
Claims 16-17 are the system and computer-readable medium, respectively, for the method in claim 1. See claim 1 for how limitations are treated for the rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is
directed to non-statutory subject matter. The claim(s) does/do not fall within at least
one of the four categories of patent eligible subject matter because:
As per independent claim 17, it recites "A computer program product or a computer-readable medium comprising the computer program product, wherein the computer program product comprises computer program code that, when executed by a computer system, causes the computer system to: ... ". Examiner would like to point out that as the claimed computer program product is recited to comprise computer program code, with broadest reasonable interpretation, the claimed computer program product may be interpreted as code/program/software/etc., which is software per-se, and software per-se is not patent eligible under 35 USC 101. The examiner would like to recommend the wording/phrasing " A non-transitory computer-readable medium storing the computer program product, wherein the computer program product comprises computer program code that, when executed by a computer system, causes the computer system to: ..”
Claims 1-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to claim 1, the claim recites – “A computer-implemented method of creating an app comprising app characteristics, the method comprising: providing an app development user interface (UI) of an app development platform to a user for developing the app; providing a default program prompt associated with a large language model, wherein the default program prompt comprises a first prompt to generate one or more function calls relating to default app characteristics matching received user input; receiving natural language user input indicative of at least one app characteristic of the app; determining the respective app characteristic using the default program prompt, the received user input, and the large language model; and developing the app using the respective determined app characteristic.”
The steps of – “determining the respective app characteristic using the default program prompt, the received user input, and the large language model; and developing the app using the respective determined app characteristic; are reasonably directed to mental processes, observations, evaluations, judgements to generate individual repositories and a deployment method of procedure, and to substitute for specific variables in the templates generated by the machine learning model. See MPEP 2106.04(a).
The judicial exception is not integrated into a practical application. In particular, the claim recites an additional element – “app development user interface (UI) of an app development platform to a user for developing the app” which is a generic mere structure to apply the abstract idea on a device or merely uses a UI and app development platform as a tool to perform the abstract idea. See MPEP 2106.06(f). The claim further recites – “providing a default program prompt associated with a large language model, wherein the default program prompt comprises a first prompt to generate one or more function calls relating to default app characteristics matching received user input and receiving natural language user input indicative of at lest one app characteristic of the app” are mere data gathering, mere instructions to apply using the large language model as a tool wherein a human with the aid a of device receives a variety of user input, and mere data transmission which are insignificant extra solution activities to the judicial exception. See MPEP 2106.05(g). Accordingly, these do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The identified additional elements, whether considered individually and in a combination, further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea or are WURC to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f) and MPEP 2106.05(d).
As to claim 2, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the determined respective app characteristic comprises a respective graph, and wherein the respective graph comprises a plurality of entities associated with the respective app characteristic”.
The additional elements of - “the determined respective app characteristic”, “a respective graph” “a plurality of entities associated with the respective app characteristic” are reasonably directed to mere instructions to apply using “determined respective app characteristic” as a tool wherein a human with the aid of this to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 3, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the respective default app characteristic comprises a default model, a default rule, a default workflow, a default logic, a default functionality, a default user interface, a default application programming interface (API), a default target operation environment of a default app, or any combination thereof, and/or wherein the respective app characteristic comprises a model, a rule, a workflow, a logic, a function, a user interface, an API, a functionality, a target operation environment of the app, or any combination thereof.”
The additional elements of – “default app characteristic” and “respective app characteristic”, “default model”, “default rule”, “default workflow”, “default logic”, “default functionality”, “default user interface”, “default application programming interface (API)”, “default target operation environment of a default app”, “model”, “rule”, “workflow”, “logic”, “functionality”, “user interface”, “application programming interface (API)”, and “target operation environment of a default app” are reasonably directed to mere instructions to apply using these (or a combination thereof) as a tool wherein a human with the aid of these to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 4, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the respective function call initiates creating the respective app characteristic matching the received user input and at least one of the default app characteristics”
The steps of – “wherein the respective function call initiates creating the respective app characteristic matching the received user input and at least one of the default app characteristics”
The additional elements of – “respective function call”, “respective app characteristic”, “received user input”, and “default app characteristics” are reasonably directed to mere instructions to apply using “determined respective app characteristic” as a tool wherein a human with the aid of this to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 5, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the respective app characteristic is associated with model-based app development.”
The additional elements of – “respective app characteristic” is reasonably directed to mere instructions to apply using computer as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 6, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the default program prompt further comprises a second prompt having information on a persona for use by the large language model.”
The additional elements of – “default program prompt”, “a second prompt” “information on a persona” and “large language model” are reasonably directed to mere instructions to apply using large language model as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 7, the rejection of claim 6 is incorporated, the claim recites additional limitations – “wherein the default program prompt further comprises information on a data format of the determined respective app characteristic, and wherein the data format is a machine-parsable and/or graph description language format.”
The additional elements of – “default program prompt”, “data format of the determined respective app characteristic”, and “machine-parsable and/or graph description language” are reasonably directed to mere instructions to apply using computer as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 8, the rejection of claim 7 is incorporated, the claim recites additional limitations – “displaying the determined respective app characteristic in the data format via the app development UI; and developing, by the app development platform, the app using the determined respective app characteristic in the data format.”
The steps – “developing, by the app development platform, the app using the determined respective app characteristic in the data format” is reasonably directed to mental processes, including observation, evaluation, judgment and opinion. See MPEP 2106.04(a).
The additional elements of – “displaying the determined respective app characteristic in the data format via the app development UI”, “determined respective app characteristic”, “data format”, “app development UI” and “app development platform” are reasonably directed data transmission and mere instructions to apply using app development UI and platform as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 9, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the default program prompt further comprises information on a data format of the determined respective app characteristic, and wherein the data format is a machine-parsable and/or graph description language format.”
The additional elements of – “default program prompt”, “data format of the determined respective app characteristic”, and “machine-parsable and/or graph description language” are reasonably directed to mere instructions to apply using computer as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 10, the rejection of claim 9 is incorporated, the claim recites additional limitations – “displaying the determined respective app characteristic in the data format via the app development UI; and developing, by the app development platform, the app using the determined respective app characteristic in the data format.”
The step(s) – “developing, by the app development platform, the app using the determined respective app characteristic in the data format” is/are reasonably directed to mental processes, including observation, evaluation, judgment and opinion. See MPEP 2106.04(a).
The additional element(s) of – “displaying the determined respective app characteristic in the data format via the app development UI”, “determined respective app characteristic”, “data format”, “app development UI” and “app development platform” are reasonably directed data transmission and mere instructions to apply using app development UI and platform as a tool wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 11, the rejection of claim 10 is incorporated, the claim recites additional limitations – “displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI; and determining a respective amended app characteristic using the further user input”.
The step(s) – “determining a respective amended app characteristic using the further user input” is/are reasonably directed to mental processes, including observation, evaluation, judgment and opinion. See MPEP 2106.04(a).
The additional element(s) of – “displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI” are reasonably directed displaying, gathering, transmitting, and mere instructions to apply using app development UI wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 12, the rejection of claim 11 is incorporated, the claim recites additional limitations – “deploying the app on a target device”.
The additional element(s) of – “deploying the app on a target device” is reasonably directed to transmitting, updating, storing data /information and mere instructions to apply using target device wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 13, the rejection of claim 1 is incorporated, the claim recites additional limitations – “wherein the large language model is trained with other app characteristics of other apps, wherein the other apps are optionally developed with model-based app development”.
The additional element(s) of – “wherein the large language model is trained with other app characteristics of other apps, wherein the other apps are optionally developed with model-based app development” is reasonably directed to transmitting, updating, storing data /information and mere instructions to apply using large language model wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 14, the rejection of claim 1 is incorporated, the claim recites additional limitations – “displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI; and determining a respective amended app characteristic using the further user input”.
The step(s) – “determining a respective amended app characteristic using the further user input” is/are reasonably directed to mental processes, including observation, evaluation, judgment and opinion. See MPEP 2106.04(a).
The additional element(s) of – “displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI” are reasonably directed displaying, gathering, transmitting, and mere instructions to apply using app development UI wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claim 15, the rejection of claim 1 is incorporated, the claim recites additional limitations – “deploying the app on a target device”.
The additional element(s) of – “deploying the app on a target device” is reasonably directed to transmitting, updating, storing data /information and mere instructions to apply using target device wherein a human with the aid of a computer to apply the abstract idea.
The additional abstract idea whether considered individually and in a combination with the parent claim further does not amount to significantly more than the judicial exception because the additional elements mere instructions to apply using computer as a tool that does not amount to a practical application of such or amount to significantly more. See MPEP 2106.05(f).
As to claims 16-17, these are the system and computer readable storage medium versions of the claimed method discussed above in claim 1 (see above on how limitations are treated for claim 1) wherein all claim limitations also have been addressed and/or covered in cited areas as set forth 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.
Claim(s) 1, 3-5, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), and further in view of OpenAI (“Function Calling and Other API Updates”).
As to claim 1, Chlipala teaches a computer-implemented method of creating an app comprising app characteristics, the method comprising: providing an app development user interface (UI) of an app development platform to a user for developing the app; ([0024], “The described systems for application generation can generate inherently sound code for one or more applications that enable seamless data flows between different databases, collaboration systems, enterprise resource planning (ERP) systems, and/or customer relationship management (CRM) systems. The generated applications with inherently sound code can satisfy complex enterprise level security and data compliance policies based on (i) an intuitive large language model user interface, (ii) assembling and configuring pre-built and tested components, (iii) using predetermined mathematical functions that automatically test generated code for all possible data input(s), (iv) safety features that avoid hazardous or unintended behavior, and/ or(v) secure data access and authentication protocols”); receiving natural language user input indicative of at least one app characteristic of the app; ([0008] “The method includes: … (ii) receiving a natural language input from a user, the natural language input indicating a user-specified functionality for an application (e.g., the natural language input is associated with a plurality of user requested application features); [0124] “The system receives (804), via the user interface, an indication of a set of components in a specification language ( e.g., corresponding to the specification language data 342) and corresponding inputs for the set of components (e.g., indicating how to connect/couple the set of components). For example, a natural language input is provided by a user”, [0134] “Some embodiments include a method for developing applications using a large language model (LLM). The method includes: (i) receiving user input describing a desired application functionality”); providing a default program prompt associated with a large language model, wherein the default program prompt comprises a first prompt to identify one or more components relating to default app characteristics matching received user input; ([0008] “The method includes: (i) obtaining a list of application components (e.g., from a library of components for use in generating applications), including obtaining input and output type information (e.g., type information such as integer, string, float, date, etc.) for each application component of the list of application components … (iii) in response to the natural language input from the user, automatically: (a) generating a first prompt for a generative artificial intelligence (AI) component based on the natural language input, the first prompt requesting that the generative AI component select an appropriate set of application components from the list of application components”; [0134], “Some embodiments include a method for developing applications using a large language model (LLM)”, [0115] “In response to the natural language input from the user (706), the system automatically ( e.g., without further user input) generates (708) one or more prompts (e.g., via the prompt generation module 318) for a generative artificial intelligence (AI) component (e.g., the AI model(s) 150, FIG. 1) based on the natural language input and a decision tree. For example, a first prompt may request that the generative AI component select an appropriate set of components from the list of pre-generated components”, see also [0153]-[0154]), (EN: Examiner interprets “appropriate set of components”, selected based on natural language input and a decision tree as generated components relating to default app characteristics matching received user input); determining the respective app characteristic using the default program prompt, the received user input, and the large language model; ([0076] “In the process of responding to a user request, the intermediary component may compose a plurality of specially engineered prompts to the AI component, each of which provide some of the information for the creation of the application. For example, in response to a user request, the system may direct the AI component, via a specially engineered prompt which may indicate selection of available application components and their descriptions, to select which component would be the best match to the user's request. Additionally, special prompts may be used to direct and guide the AI component to generate ( e.g., select) names for features, icons or other graphic renderings for features and tabs, and how to layout the various features to build a useful and compelling interface ”); and developing the app using the respective determined app characteristic; ([0074] “In some embodiments, the application generation module 314 produces scalable binaries enabling the development of a whole-program optimization compiler. In some embodiments, the scalable binaries are developed based on high level source code. Some embodiments include an intermediary component (e.g., the application generation module … between the user and an artificial intelligence component (e.g., the AI module 320, a generative AI, one or more large language models (LLMs ), or other types of AI and/or machine learning”, [0080] “… when the intermediary component has acquired from the AI component the technical specifications it needs to properly generate/configure the generated application (e.g., user interface), the intermediary component may describe these specifications to the user in plain, non-technical language”, [0119] The system presents (716) to the user the full recommendation (e.g., the recommendation 675B, FIG. 6B) for implementing the user-specified functionality. … the full recommendation indicates selected components from the list of pre-generated components and configuration information for the selected components”, [0120] “In response to receiving an acceptance of the recommendation, the system implements (718) the user specified functionality using a subset of the pre-generated components”).
Chlipala does not teach the first prompt to generate one or more function calls relating to default app characteristics matching received user input.
However, in analogous art, Stephens teaches providing a default program prompt associated with a large language model, wherein the default program prompt comprises a first prompt to generate declarative model components in JSON data format relating to default app characteristics matching received user input. Stephens teaches about using machine-learned language model to turn natural language descriptions of a software app, via user interface, and processes it with a machine learned model to generate an application definition of the software application. Stephens’ development platform can then insert it into a declarative model into an application definition that is declarative model represented in markup language (such as JSON, XML, or YAML data format) of the default app characteristics matching received user input. The declarative model is associated with the software application. Stephens further teaches code generation systems including processors that can automatically generate code from the markup language representations of the declarative model (e.g. from JSON data format). [0058] lists some of the components of the declarative model. Stephens lists among those workflow and API calls but does not teach function calls. (See [0021], [0022] “application development platform can receive the natural language description from the user via a chatbot interface that enables the user to engage in a textual dialog with a chatbot or other artificial intelligence agent”, [0023] “the application development platform can process the natural language description with a machine-learned language model to generate, as an output of the machine learned language model, an application definition for the software application”, [0047] “The application development platform 30 can insert the application definition 64 generated by the machine-learned language model 40 into a declarative model 60 associated with the software application. More particularly, the application development platform 30 can maintain and assist the user in creating or editing a declarative model 60 for the software application being developed. The declarative model can include a data schema 62 and the application definition 64”, [0058] “the application definition 64 can refer to or include the components of the declarative model 60 that define the behavior, rules, workflow, user interface, and/or configuration settings of the software application. As examples, the application definition 64 can include rules, a workflow or process model, user interface components, configuration settings, and/or a security model, which collectively define the desired state or behavior of the application”, [0060] “Workflow or process models may be represented using visual diagrams, flowcharts, or process definitions in a declarative format, such as Business Process Model and Notation (BPMN) or Workflow Definition Language (WDL)”, [0065] “the application definition 64 can include one or more application programming interface (API) calls. The API calls can be made against or with reference to the data source 66. For example, in the declarative model 60, API calls can be used to make changes to the underlying data of the data source 66 or can be defined with reference to and/or act upon the data schema 62 or other aspects of the declarative model 60. The API calls can specify the endpoints, input parameters, output responses, authentication, and other details of the API. The specific API calls and their syntax may vary depending on the platform or system being used to implement the declarative model 60”, [0081] “the code generation system(s) 70 can be or include markup language processors. Markup languages such as XML, JSON, or YAML can be used to represent the declarative model 60 and processors or interpreters for these markup languages can automatically generate the application code 80 from the declarative model 60. Examples of markup language processors include XSLT (Extensible Stylesheet Language Transformations)”. See also [0082]).
Chlipala and Stephens, in analogous art, similarly both teach an application development platform leveraging machine learning language models to perform generation of application definition (claimed determined respective app characteristics) for a software application based on a natural language input prompt. Chlipala teaches the application definition as a broad set of components whereas Stephens teaches the declarative model, with more specifics, to include data schema, rules, workflow, process model, user interface components, API calls, etc.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala with the teachings of Stephens on the declarative model, application definition capabilities described above, explicitly including workflow graphs and API calls, and on the ability to generate the application code automatically from markup language representations (such as JSON data format).
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success, to help to improve productivity,
maintain consistency and reduce errors in software development (Stephens [0081]) and enabling many individuals without the specific set for software development to develop software applications using a low-code/no-code tools (Stephens [0003] and Abstract).
Chlipala-Stephens does not teach the first prompt to generate one or more function calls relating to default app characteristics matching received user input.
However, in analogous art, OpenAI teaches providing a one or more function calls relating to default app characteristics matching received user input. (Page 3/7, “Developers can now describe functions to gpt-4-0613 and gpt-3.5-turbo-0613, and have the model intelligently choose to output a JSON object containing arguments to call those functions. This is a new way to more reliably connect GPT's capabilities with external tools and APIs. These models have been fine-tuned to both detect when a function needs to be called (depending on the user’s input) and to respond with JSON that adheres to the function signature. For example, developers can: - Create chatbots that answer questions by calling external tools (e.g. like ChatGPT Plugins) - Convert queries such as “Email Anya to see if she wants to get coffee next Friday” to a function call like send_email(to: string,body: string) … - Convert natural language into API calls or database queries. … These use cases are enabled by new API parameters in our /v1/chat/completions endpoint, functions and function_call, that allow developers to describe functions to the model via JSON Schema, and optionally ask it to call a specific function”). (EN: Examiner interprets “function signature” as the “characteristics” of the function).
Chlipala-Stephens teaches about leveraging machine learning models to transform natural language input into a generated model-based application definition, which can be represented as a declarative model in markup languages such as JSON or XML as mentioned above. It also teaches about API calls, as taught by Stephens, as part of the application definition. OpenAI, in analogous art, teaches about the known technique to leverage OpenAI’s LLM to generate a list of function calls in JSON data format based on a received natural language user input and LLM’s knowledge of a list of predefined pre-existing functions. Adding the known technique of OpenAI function calls (represented in JSON data format) to expand the application definition capabilities, can be easily integrated to the Chlipala-Stephens system, while utilizing the existing architecture which already teaches (Stephens’) API calls in the declarative model (represented in JSON data format), and (Stephens’) code generation that automatically generates code from a declarative model (represented in JSON data format).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chlipala-Stephens to use function calls as part of the declarative model taught by Stephens (claimed app characteristics). That is, using the known technique, taught by OpenAI, to leverage LLMs in generating function calls based on natural language input would have been obvious to one of ordinary skill.
A person of ordinary skill, would have recognized the benefits of using this known technique to improve Chlipala-Stephens motivated by this new way to more reliably connect GPT's capabilities with external tools and APIs. (OpenAI, Page 3/7, top paragraph).
As to claim 3, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI does not teach wherein the respective default app characteristic comprises a default model, a default rule, a default workflow, a default logic, a default functionality, a default user interface, a default application programming interface (API), a default target operation environment of a default app, or any combination thereof, and/or wherein the respective app characteristic comprises a model, a rule, a workflow, a logic, a function, a user interface, an API, a functionality, a target operation environment of the app, or any combination thereof.
However, Stephens further teaches ([0021] “… an application development platform can obtain a natural language description of a software application. The natural language description can be or include a description of the software application as desired by the user. For example, the natural language description can provide a description of different aspects of the software application such as desired data structures, functions, requirements, data flows, or operations”, [0022] “The natural language description can be entered or otherwise input by a user”, [0023] “the application development platform can process the natural language description with a machine-learned language model to generate, as an output of the machine-learned language model, an application definition for the software application”, [0058] “… the application definition 64 can refer to or include the components of the declarative model 60 that define the behavior, rules, workflow, user interface, and/or configuration settings of the software application. As examples, the application definition 64 can include rules, a workflow or process model, user interface components, configuration settings, and/or a security model, which collectively define the desired state or behavior of the application”, [0059] “the application definition 64 can include rules. These are the rules and logic that govern the behavior of the application. Rules may include conditions, constraints, calculations, validations, and other logic that define how the application should operate based on the input data and desired outcomes. Rules may be expressed in a declarative format, such as through rule-based engines or configuration files”, [0060] “… the application definition 64 can include a workflow or process model. This component defines the flow of activities or processes in the application. It describes how different tasks or steps are executed, their sequence, dependencies, and interactions. Workflow or process models may be represented using visual diagrams, flowcharts, or process definitions in a declarative format, such as Business Process Model and Notation (BPMN) or Workflow Definition Language (WDL)”, [0061] “… the application definition 64 can include user interface (UI) components. These are the components that define the visual and/or interactive elements of the application's user interface. UI components may include screens, forms, buttons, menus, and other UI elements that allow users to interact with the application. The declarative model for UI components may be defined using UI frameworks, markup languages, or visual designers”, [0063] “the application definition 64 can include a security model. This component can define the security settings, access controls, and/or authentication/authorization mechanisms for the application. It can include the definition of user roles, permissions, and/or security policies that govern the access and actions allowed in the application. The security model can be defined in a declarative format, such as through security configuration files or access control lists (ACLs)”, [0064] “… the application definition 64 can include a deployment and infrastructure model. This component can define the deployment requirements, configuration, and/or infrastructure dependencies of the application. It can include information about the target deployment environment, such as servers, databases, networks, and/or other infrastructure components. The deployment and infrastructure model can be defined using configuration files, templates, or scripts in a declarative format”, [0065] “… the application definition 64 can include one or more application programming interface (API) calls. The API calls can be made against or with reference to the data source 66. For example, in the declarative model 60, API calls can be used to make changes to the underlying data of the data source”, [0047] “More particularly, the application development platform 30 can maintain and assist the user in creating or editing a declarative model 60 for the software application being developed. The declarative model can include a data schema 62 and the application definition 64”. See also [0048], [0078] “… the code generation system(s) 70 can be or include a model-driven development (MDD) framework. In these frameworks, the declarative model 60 can be represented in or using a domain-specific language (DSL) or a graphical modeling language”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the further teachings of Stephens on the declarative model into the Chlipala-Stephens-OpenAI system to improve and facilitate the automation of software application in a low-code no-code software development platform.
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success to help to improve productivity,
maintain consistency and reduce errors in software development (Stephens [0081]) and enabling many individuals without the specific set for software development to develop software applications using a low-code/no-code tools (Stephens [0003] and Abstract).
As to claim 4, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI teaches the respective function call initiates creating the respective app characteristic matching the received user input and at least one of the default app characteristics.
As mentioned above for claim 1, Chlipala-Stephens-OpenAI teaches about creating the respective app characteristic – including function calls - matching the received user input and at least one of the default app characteristics. It also teaches about the function calls being represented in JSON (OpenAI page 3/7) and the code generation taught by Stephens to automatically generate from JSON app characteristics. (Refer to claim 1 for teachings of Chlipala: [0024], [0008], [0124], [0134],[0115], [0153]-[0154], [0076], [0074], [0119], [0120] – of Stephens: [0021]-[0023], [0047], [0058], [0060], [0065] [0081] – of OpenAI: Page 3/7). Examiner interprets the teachings about the generation of the one or more function calls in the declarative model represented in JSON coupled with the automated code generation automated based on the declarative model that the function call initiates creating the respective app characteristic matching the user input and at least one of the default app characteristics. Thus, accordingly this claim is obvious. For motivation, see motivations for claim 1.
As to claim 5, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI does not teach the respective app characteristic is associated with model-based app development.
However, Stephens further teaches the respective app characteristic is associated with model-based app development; ([0033] “Users can then configure the application's behavior, user interface, and functionality using a visual interface and a set of predefined actions and workflows. The application development platform 30 can support a wide range of data types, including text, numbers, dates, images, and more, and can provide various features such as data validation, formulas, and workflows for creating robust applications”, [0060] “… the application definition 64 can include a workflow or process model. This component defines the flow of activities or processes in the application. It describes how different tasks or steps are executed, their sequence, dependencies, and interactions. Workflow or process models may be represented using visual diagrams, flowcharts, or process definitions in a declarative format, such as Business Process Model and Notation (BPMN) or Workflow Definition Language (WDL)”, [0047] “The application development platform 30 can insert the application definition 64 generated by the machine-learned language model 40 into a declarative model 60 associated with the software application. The declarative model 60 can describe what the software application should do, without specifying how it should do it. The declarative model 60 can define the desired state or outcome of a system, rather than the step-by-step instructions for achieving that state”, [0061] “the application definition 64 can include user interface (UI) components. These are the components that define the visual and/or interactive elements of the application's user interface. UI components may include screens, forms, buttons, menus, and other UI elements that allow users to interact with the application. The declarative model for UI components may be defined using UI frameworks, markup languages, or visual designers”, [0078] “the code generation system(s) 70 can be or include a model-driven development (MDD) framework. In these frameworks, the declarative model 60 can be represented in or using a domain-specific language (DSL) or a graphical modeling language”. See also [0022], [0076]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala-Stephens-OpenAI with the further teachings of Stephens on the declarative model, application definition capabilities described above are associated with model-based app development.
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success to help to improve productivity,
maintain consistency and reduce errors in software development (Stephens [0081]) and enabling many individuals without the specific set for software development to develop software applications using a low-code/no-code tools (Stephens [0003] and Abstract).
As to claim 13, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI does not teach the large language model is trained with other app characteristics of other apps, wherein the other apps are optionally developed with model-based app development.
However, Stephens further teaches ([0008] “The operations include obtaining, by the computing system, a training data pair comprising: a natural language description of a software application and a ground truth application definition for the software application. The operations include processing, by the computing system, the natural language description with a language model to generate, as an output of the language model, a predicted application definition for the software application. The operations include evaluating, by the computing system, a loss function that generates a loss value based on a comparison of the ground truth application definition with the predicted application definition. The operations include modifying, by the computing system, one or more parameter values of the language model based on the loss function”. See also [0086], [0087] “The computing system can modify one or more parameter values of the language model 40 based on the loss function 470. For example, as illustrated using the dashed line, the loss function 470 can be backpropagated through the language model 40. The process shown in FIG. 4 can be repeated for any number of training pairs over any number of training iterations”. [0088] “the natural language description 450 of the software application can have been generated by a human annotator. For example, a human annotator may be asked to describe, using natural language, an existing software application. The existing software application may have an existing application definition. The natural language description provided by the human annotator can be paired with the existing application definition to form a training pair. This process can be performed on a number of existing software applications to generate a training dataset of training pairs having the structure shown in FIG. 46”, [0089] “… the training process shown in FIG. 4 may be performed as fine-tuning on a pre-trained language model 40. Fine-tuning the language model 40 can include training the pre-trained model 40 on additional data (e.g., the training pair 430) to adapt it to a specific task or domain (e.g., to generate predicted application definitions)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala-Stephens-OpenAI system with the further teachings of Stephens on training the large language model with other app characteristics of other apps and on a number of existing software applications.
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success because as Stephens teaches “once trained, the machine-learned language model can leverage its learned understanding of language dynamics to identify the key aspects of the problem as stated in the user's description and to generate an application definition that has an appropriate structure to address the specified problems” (Stephens [0024]).
As to claim 14, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI teaches, through further teachings of Chlipala, displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI; and determining a respective amended app characteristic using the further user input. ([0098] “If the user approves of at least one recommendation of the one or more recommendations, the user can send the approval via a natural language input accepting the at least one recommendation of the one or more recommendations (e.g., "This looks good. Regenerate my app! … If the user does not approve of at least one recommendation of the one or more recommendations, the user can send disapproval information via a natural language input providing explanation information for the user request that includes details about the requested user interface feature (e.g., additional documents, database information, preferred presentation format, functional components, etc.).", [0101] “Upon determining that the user has approved the at least one recommendation for the user interface component, the conversational user interface 610K regenerates the user interface application as described earlier”, [102] “In some embodiments, the user can instruct the conversational user interface 610K to perform a second function (e.g., "Show an editable table of who registered for our Online seminars lately" 627K). In some embodiments, the second function is distinct from the first function. The conversational user interface 610K can then generate another user interface 615K for performing the requested second function”). Examiner interprets that in order to regenerate the app, the determining of the respective app characteristics using the further input must be completed prior to the regeneration.
As to claim 15, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI teaches deploying the app Chlipala further teaches ([0126] “For example, the system presents a user interface of the application. In some embodiments, the user may interact with the user interface(s) of the application and then revise and/or deploy the application”, [0129] “… the code generator 160 is a user interface component generator. In accordance with some embodiments, the production application generator 170 is a customized code generator that creates fully functional, ready-to-deploy software applications based on ensuring compatibility with different libraries, databases (e.g., AI database 130, component database 135, and ML database 140) and frameworks with automated testing, building, and deployment processes”).
Chlipala-Stephens-OpenAI does not teach deploying the app explicitly on a target device.
However, Stephens further teaches deploying the app on a target device; ([0078] “…once the declarative model 60 has been generated for the software application, the application development platform 30 can implement one or more code generation systems 70 to generate a set of application code 80 from the declarative model 60. The application code 80 can implement the application (e.g., as described by the declarative model 60) in any number of different application deployment settings. In particular, the platform 30 and/or a user of the platform 30 can specify different deployment parameters such as different device paradigms (e.g., mobile vs. desktop), different operating systems, different programming languages, and/or other parameters. In response, the one or more code generation system 70 can process the declarative model 60 and the specified deployment parameters to generate the application code 80 that implements the software application (e.g., as described by the declarative model 60) in the specified deployment setting. Thereafter, the set of application code 80 can be deployed or otherwise provided to execute the application”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala-Stephens-OpenAI system with the further teachings of Stephens on describing the deployment parameters as part of Stephens’ declarative model (claimed determined respective app characteristics) and allowing users to specify/modify such that the Chlipala-Stephens-OpenAI-JSONnpl-Nicolae is deployed on the target device.
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success, to help to improve productivity,
maintain consistency and reduce errors in software development (Stephens [0081]) and enabling many individuals without the specific set for software development to develop software applications using a low-code/no-code tools (Stephens [0003] and Abstract).
As to claims 16-17, these are the system and computer readable storage medium versions of the claimed method discussed above in claim 1 (see above on how limitations are treated for claim 1) wherein all claim limitations also have been addressed and/or covered in cited areas as set forth above.
Claim(s) 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1) , further in view of OpenAI (“Function Calling and Other API Updates”), and further in view of Nicolae (US 2025/0363371 A1).
As to claim 2, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI does not teach the determined respective app characteristic comprises a respective graph, and wherein the respective graph comprises a plurality of entities associated with the respective app characteristic.
However, in analogous art, Nicolae teaches the determined respective app characteristic comprises a respective graph, and wherein the respective graph comprises a plurality of entities associated with the respective app characteristic. ([0040] “Workflow graph definition 148 is a textual definition of a workflow graph that, in this example, defines the tasks and edges of an ML pipeline that builds and deploys target ML model 170”, [0043] “Workflow graph definition 148 defines a workflow graph and, herein, the workflow graph and its workflow graph definition 148 may be synonyms. IDE 100 can graphically display workflow graph definition 148 as a visual graph or as JSON. In other words, IDE 100 is a graphical user interface (GUI)”, [0044] “… a user may interactively (e.g. by mouse) select one or more vertices and/or edges in workflow graph definition 148. In an embodiment, the mouse pointer hovering over a vertex causes a popup (i.e. tooltip) to be displayed that contains a name, title, summary, or description of the task. In an embodiment, interactive selection of a vertex causes task properties and other task details to be displayed in a side panel in IDE 100”, [0045] “IDE 100 supports graphical direct manipulation of workflow graph definition 148 in which the mouse and (e.g. popup) menus and toolbar(s) can be used to interactively directly modify workflow graph definition 148 such as by editing the configuration of an existing vertex or by editing the topology of workflow graph definition 148 by adding or removing vertex(s) or edge(s)”, [0038] “For example, each distinct task may be a distinct vertex in a dataflow graph, and a directed edge connects two vertices to indicate that output generated by an upstream task is accepted as input by a downstream task”, [0046] “Natural language 131-132 both contain interaction 151 that, as discussed later herein, is an informal description of an activity that the user wants IDE 100 to apply to workflow graph definition”, [0055] “… a vertex property may also be referred to as a task property. Each property has a datatype and a value. If the datatype is a data structure, then the value is compound”, [0095] “From autonomous linguistic prompt 112, result 152 may be an inferentially generated proposal that contains either or both of: a) JSON document 149 is a new version of the workflow graph of target ML model”, [0025] “The IDE can reuse existing kinds of vertices or create brand new kinds of vertices with desired new functionalities informally specified in interactive natural languages”, [0101] “Step 205 specifies, in JSON document 149, selection of a data source that will provide data that will flow into the workflow graph. For example, interaction 151 may expressly or impliedly specify a database table, a spreadsheet, a data file, or a data stream, and step 205 inserts a formal reference, such as a file path or URL, to the data source into JSON document 149”, [0102] “Step 205 may entail specifying either or both of: a) step 206 that assigns the formal reference as a value of a property of a new or existing vertex and b) step 207 that adds a new data source vertex into the workflow graph”, [0103] “Step 207 specifies adding or removing a vertex in the workflow graph. As discussed earlier herein, an edge in the workflow graph may use an output from an upstream vertex as an input to a downstream vertex. As shown in FIG. 1, vertex 141 has four edges that operate in that way”). Examiner interprets Nicolae’s workflow graph/dataflow graph definition in a low-code no-code IDE as the claimed determined respective app characteristics, workflow graph/dataflow graph as the claimed graph, and the multiple vertices each representing task/operations as the claimed entities. Nicolae further teaches leveraging the LLM in generating a new JSON version of the workflow graph, including adding or removing vertices and edges based on natural language input.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala-Stephens-OpenAI with the teachings of Nicolae for representing the determined respective app characteristics, by the LLM, using Nicolae’s JSON-structured workflow graph representation to facilitate the design and development of software application. The use of structured language also facilitates special automation such as interpretation and validation of inferentially generated output. In an embodiment, the workflow graph is formatted in JSON to organize the workflow's attributes (e.g. name, identifier, creation date, etc.) and the workflow's components such as vertices
A person of ordinary skill, would have recognized the benefits of the use of JSON structured workflow graph representation motivated to facilitate software application automation when processing (NLP) and natural language interaction (NLI) is more difficult with machine learning models in the cases of complex technical subject matter (Nicolae [0002]).
Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), further in view of OpenAI (“Function Calling and Other API Updates”), and further in view of MartinShort (US 2024/0184983 A1).
As to claim 6, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI teaches the default program prompt further It teaches the default program prompt comprising a first prompt and additional iterations of prompts for use by the large language model. Chlipala further teaches about additional iterations of prompts to the LLM ([0075] “Additional iterations of input and updates can be performed as well. Other data can be added as context for the language model 40 as well”). Examiner interprets that as teaching the claimed second prompt but it does not explicitly teach including persona information explicitly as part of the “other data as context”.
Chlipala-Stephens-OpenAI does not teach the default program prompt further comprises a second prompt having information on a persona for use by the large language model.
However, in analogous art, MartinShort teaches a second prompt having information on a persona for use by the large language model ([0055] “In some embodiments, the query module 230 may receive queries describing personas. A persona may describe characteristics of a user or a demographic … The query may be a natural language query of any length (subject to fitting within the LLM context window length)”, [0056] “The query module 230 may process received queries using an LLM. The query module 230 generates a prompt for the LLM based on a received query”, [0057] “For example, the query module 230 may generate the prompt”, [0057] ““You are a mobile app ecosystem expert”. Identify information in <graph> that answers the question posed by or is relevant to <query>”. For a query pertaining to a persona (e.g., people who want to buy cars), the request may be that the LLM provide applications relevant to the persona the query describes”, [0058] “The query module 230 provides the prompt to the LLM as input”, [0064] “In some embodiments, the query module 230 may generate a second prompt for the LLM”, see also [0078] for selecting from a drop-down of pre-existing personas) Examiner interprets descriptions of personas in the queries as “prompts having information on a persona”. This provides context information on the persona, role/domain, assigned to the LLM like in instant application.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Chlipala-Stephens-OpenAI with the further teachings of MartinShort to provide in an additional (second) prompt, via the additional iterations of input prompts to the LLM (teachings of Chlipala) that are taught to contain context and other data, the LLM with information on a persona.
A person of ordinary skill, would have recognized the benefits of providing a second prompt to the LLM with additional context on a persona to enable the LLM to provide the appropriate response(s) to natural language user input prompt and queries based on high-affinity (MartinShort [0089]).
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), further in view of OpenAI (“Function Calling and Other API Updates”), further in view of MartinShort (US 2024/0184983 A1), and further in view of JSONnpl (“Introducing JSON”).
As to claim 7, the rejection of claim 6 (and claim 1) is incorporated. Chlipala-Stephens-OpenAI-MartinShort teaches the default program prompt further comprises information on a data format of the determined respective app characteristic, Chlipala-Stephens-OpenAI-MartinShort, through Stephens’ teachings for incorporated claim 1, teaches the determined the declarative model (claimed determined respective app characteristics) to be represented in JSON data format (See Stephens (Stephens [0081] “… the code generation system(s) 70 can be or include markup language processors. Markup languages such as XML, JSON, or YAML can be used to represent the declarative model 60 and processors or interpreters for these markup languages can automatically generate the application code 80 from the declarative model 60”). Further, the teachings of OpenAI for incorporated claim 1 mentioned above (OpenAI page 3/7, “These use cases are enabled by new API parameters in our/v1/chat/completions endpoint, functions and function_call, that allow developers to describe functions to the model via JSON Schema, and optionally ask it to call a specific function”). (EN: Examiner interprets that, for the LLM to be able to generate a declarative model in JSON for the natural language user inputs, the LLM is required to have received prior information on the JSON schema (data format for the determined respective app characteristics)).
Chlipala-Stephens-OpenAI-MartinShort does not teach the default program prompt further comprises information on a data format of the determined respective app characteristic, wherein the data format is a machine-parsable and/or graph description language format. It does not teach that JSON is a machine-parsable data format. The instant application describes as allowable data format in [0075] for the determined respective app characteristics [0073].
However, JSONnpl teaches that JSON is machine-parsable (Paragraph 1, “JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate”).
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 system of Chlipala-Stephens-OpenAI-MartinShort with the use the known technique for the JSON data format in application development environment as being machine-parsable data format and easier for downstream processing by LLMs.
A person of ordinary skill, would have recognized the benefits of utilizing a lightweight data interchange format such as JSON, which is a text format independent of any language, that is easy for humans to read and write (JSONnpl, paragraph 1). This would allow easier interaction using natural language input to the LLM especially in cases of low-code no-code application development platforms.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), further in view of OpenAI (“Function Calling and Other API Updates”), further in view of MartinShort (US 2024/0184983 A1), further in view of JSONnpl (“Introducing JSON”), and further in view of Nicolae (US 2025/0363371 A1).
As to claim 8, the rejection of claim 7 is incorporated. As mentioned in incorporated claim 7, the teachings of machine-parsable data format for the determined respective app characteristics being JSON and Chlipala-Stephens-OpenAI-MartinShort-JSONnpl teaches ((Stephens [0081] “… the code generation system(s) 70 can be or include markup language processors. Markup languages such as XML, JSON, or YAML can be used to represent the declarative model 60 and processors or interpreters for these markup languages can automatically generate the application code 80 from the declarative model 60”).
Chlipala-Stephens-OpenAI-MartinShort-JSONnpl does not specifically teach displaying the determined respective app characteristic in the data format via the app development UI.
However, in analogous art, Nicolae teaches ([0032] “FIG. 1 is a block diagram that depicts an example integrated development environment (IDE) 100 that performs generative natural language processing (NLP) of natural language 131-134 for workflow development. In IDE 100, generative large language model (LLM) 121 explains and modifies workflow graph definition 148”, [0043] “Workflow graph definition 148 defines a workflow graph and, herein, the workflow graph and its workflow graph definition 148 may be synonyms. IDE 100 can graphically display workflow graph definition 148 as a visual graph or as JSON. In other words, IDE 100 is a graphical
user interface (GUI)”). Examiner interprets the IDE as the app development UI.
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 teachings of Nicolae to the Chlipala-Stephens-OpenAI-MartinShort-JSONnpl system such as to provide the determined respective app characteristic to the user in a data format via the app the development UI.
A person of ordinary skill, would have recognized the benefits of such a combination motivated “to streamline design, development, and deployment of machine learning (ML) workflows in a low-code/no-code (LC/NC) environment that is productive for users having a wide variety of engineering proficiency”. (Nicolae, Abstract)
Claim 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), further in view of OpenAI (“Function Calling and Other API Updates”), and further in view of JSONnpl (“Introducing JSON”).
As to claim 9, the rejection of claim 1 is incorporated, Chlipala-Stephens-OpenAI teaches the default program prompt further comprises information on a data format of the determined respective app characteristic, . As mentioned above, through Stephens’ teachings in incorporated claim 1, Chlipala-Stephens-OpenAI teaches the declarative model (claimed determined respective app characteristics) to be represented in JSON data format (See Stephens (Stephens [0081] “… the code generation system(s) 70 can be or include markup language processors. Markup languages such as XML, JSON, or YAML can be used to represent the declarative model 60 and processors or interpreters for these markup languages can automatically generate the application code 80 from the declarative model 60”). Further, the teachings of OpenAI for incorporated claim 1 mentioned above (OpenAI page 3/7, “These use cases are enabled by new API parameters in our/v1/chat/completions endpoint, functions and function_call, that allow developers to describe functions to the model via JSON Schema, and optionally ask it to call a specific function”). (EN: Examiner interprets that, for the LLM to be able to generate a declarative model in JSON for the natural language user inputs, the LLM is required to have received prior information on the JSON schema (data format for the determined respective app characteristics)).
Chlipala-Stephens-OpenAI does not teach the default program prompt further comprises information on a data format of the determined respective app characteristic, wherein the data format is a machine-parsable and/or graph description language format. It does not teach that JSON is a machine-parsable data format. The instant application describes as allowable data format in [0075] for the determined respective app characteristics [0073].
However, in analogous art, JSONnpl teaches that JSON data format is machine-parsable data format (Paragraph 1, “JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate”).
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 system of Chlipala-Stephens-OpenAI with the use the known technique for the data format of JSON in application development environment as being machine-parsable data format and easier for downstream processing by LLMs.
A person of ordinary skill, would have recognized the benefits of utilizing a lightweight data interchange format such as JSON, which is a text format independent of any language, that is easy for humans to read and write (JSONnpl, paragraph 1). This would allow easier interaction using natural language input to the LLM especially in cases of low-code no-code application development platforms.
Claim 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Chlipala (US 2025/0315223 A1), in view of Stephens (US 2024/0354070 A1), further in view of OpenAI (“Function Calling and Other API Updates”), further in view of JSONnpl (“Introducing JSON”), and further in view of Nicolae (US 2025/0363371 A1).
As to claim 10, the rejection of claim 9 is incorporated. As mentioned in incorporated claim 1, the teachings of JSON data format for the determined respective app characteristics being the declarative model (of Stephens) represented in JSON data format. Chlipala-Stephens-OpenAI-JSONnpl teaches ((Stephens [0081] “… the code generation system(s) 70 can be or include markup language processors. Markup languages such as XML, JSON, or YAML can be used to represent the declarative model 60 and processors or interpreters for these markup languages can automatically generate the application code 80 from the declarative model 60”).
Chlipala-Stephens-OpenAI-JSONnpl does not specifically teach displaying the determined respective app characteristic in the data format via the app development UI.
However, in analogous art, Nicolae teaches ([0032] “FIG. 1 is a block diagram that depicts an example integrated development environment (IDE) 100 that performs generative natural language processing (NLP) of natural language 131-134 for workflow development. In IDE 100, generative large language model (LLM) 121 explains and modifies workflow graph definition 148”, [0043] “Workflow graph definition 148 defines a workflow graph and, herein, the workflow graph and its workflow graph definition 148 may be synonyms. IDE 100 can graphically display workflow graph definition 148 as a visual graph or as JSON. In other words, IDE 100 is a graphical user interface (GUI)”). Examiner interprets the IDE as the app development UI.
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 teachings of Nicolae to the Chlipala-Stephens-OpenAI-JSONnpl system such as to provide the determined respective app characteristic to the user in a data format via the app the development UI.
A person of ordinary skill, would have recognized the benefits of such a combination motivated “to streamline design, development, and deployment of machine learning (ML) workflows in a low-code/no-code (LC/NC) environment that is productive for users having a wide variety of engineering proficiency”. (Nicolae, Abstract)
As to claim 11, the rejection of claim 10 is incorporated, Chlipala-Stephens-OpenAI-JSONnpl-Nicolae teaches displaying the respective app characteristic to the user via the app development UI; receiving further user input indicative of an amendment to the respective app characteristic via the app development UI; and determining a respective amended app characteristic using the further user input. Chlipala further teaches ([0098] “If the user approves of at least one recommendation of the one or more recommendations, the user can send the approval via a natural language input accepting the at least one recommendation of the one or more recommendations (e.g., "This looks good. Regenerate my app! … If the user does not approve of at least one recommendation of the one or more recommendations, the user can send disapproval information via a natural language input providing explanation information for the user request that includes details about the requested user interface feature (e.g., additional documents, database information, preferred presentation format, functional components, etc.).", [0101] “Upon determining that the user has approved the at least one recommendation for the user interface component, the conversational user interface 610K regenerates the user interface application as described earlier”, [102] “In some embodiments, the user can instruct the conversational user interface 610K to perform a second function (e.g., "Show an editable table of who registered for our Online seminars lately" 627K). In some embodiments, the second function is distinct from the first function. The conversational user interface 610K can then generate another user interface 615K for performing the requested second function”). Examiner interprets that in order to regenerate the app, the determining of the respective app characteristics using the further input must have been completed prior to the regeneration.
As to claim 12, the rejection of claim 11 is incorporated, Chlipala-Stephens-OpenAI-JSONnpl-Nicolae teaches deploying the app Chlipala further teaches ([0126] “For example, the system presents a user interface of the application. In some embodiments, the user may interact with the user interface(s) of the application and then revise and/or deploy the application”, [0129] “… the code generator 160 is a user interface component generator. In accordance with some embodiments, the production application generator 170 is a customized code generator that creates fully functional, ready-to-deploy software applications based on ensuring compatibility with different libraries, databases (e.g., AI database 130, component database 135, and ML database 140) and frameworks with automated testing,
building, and deployment processes”).
Chlipala-Stephens-OpenAI-JSONnpl-Nicolae does not teach deploying the app explicitly on a target device.
However, Stephens further teaches deploying the app on a target device; ([0078] “…once the declarative model 60 has been generated for the software application, the application development platform 30 can implement one or more code generation systems 70 to generate a set of application code 80 from the declarative model 60. The application code 80 can implement the application (e.g., as described by the declarative model 60) in any number of different application deployment settings. In particular, the platform 30 and/or a user of the platform 30 can specify different deployment parameters such as different device paradigms (e.g., mobile vs. desktop), different operating systems, different programming languages, and/or other parameters. In response, the one or more code generation system 70 can process the declarative model 60 and the specified deployment parameters to generate the application code 80 that implements the software application (e.g., as described by the declarative model 60) in the specified deployment setting. Thereafter, the set of application code 80 can be deployed or otherwise provided to execute the application”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Chlipala-Stephens-OpenAI-JSONnpl-Nicolae system with the further teachings of Stephens on describing the deployment parameters as part of Stephens’ declarative model (claimed determined respective app characteristics) and allowing users to specify/modify such that the Chlipala-Stephens-OpenAI-JSONnpl-Nicolae is deployed on the target device.
A person having ordinary skill in the art would have been motivated to make this
combination with a reasonable expectation of success, to help to improve productivity,
maintain consistency and reduce errors in software development (Stephens [0081]) and enabling many individuals without the specific set for software development to develop software applications using a low-code/no-code tools (Stephens [0003] and Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTIANE SHOUSHA whose telephone number is (571)270-7569. The examiner can normally be reached Monday - Friday (8:00 am - 5: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, LEWIS BULLOCK JR. can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.S./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights