DETAILED ACTION
This action is responsive to Remarks and Claim Amendments filed on August 19, 2026.
Claims 1, 4, 6, 11, 14, 16 and 19-20 have been amended. Claims 5, 7, 15 and 17 have been canceled. Claims 21-24 have been newly added.
Claims 1-4, 6, 8-14, 16 and 18-24 are pending and are 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 .
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 Amendments
The objections to claims 4, 11-16 and 18-20 set forth in the Non-Final Office Action mailed May 18, 2026 are withdrawn in view of applicant’s amendments to claims 4, 11, 14 and 19-20 and the cancellation of claim 15.
Response to Arguments
Applicant’s arguments filed August 18, 2026 have been fully considered but they are not persuasive.
Applicant argues (Remarks, p. 10) that “Claim 1 is amended to incorporate limitations of claim 5. Therefore claim 1 is allowable,” and that “Independent claims 11 and 20 are also allowable for the same reasons.”
This argument is not persuasive. The limitation of canceled claim 5 was not incorporated into claim 1 as a required limitation. Rather, it was added as a fourth member of the pre-existing disjunctive list introduced by the transitional phrase “one or more of.” Claim 1 as amended recites that the information related to development of the database application “represents one or more of: a database query for accessing data stored using the schema of the database; a resultset obtained by executing the database query; a chart representing the resultset obtained by executing the database query; or description of a schema for storing data processed by the database application.” Adding an additional alternative to a group of alternatives does not narrow the claim; it broadens the universe of subject matter that will satisfy the limitation.
Claim language reciting alternatives in the form “one or more of” is satisfied when the prior art teaches any single one of the recited alternatives. See MPEP § 2111.03, subsection II, and MPEP § 2131.02, subsection III (a claim reciting alternatives is unpatentable over the prior art where one member of the recited group is taught by the prior art). Maddigan teaches the third recited alternative—a chart representing the resultset obtained by executing the database query—as set forth in the rejection of claim 1 below and as previously set forth in the Non-Final Office Action mailed May 18, 2026. The presence of the newly added fourth alternative therefore does not distinguish claim 1 over the applied art, and claim 1 remains unpatentable for the reasons of record.
Because claims 11 and 20 were amended identically to claim 1 and are argued only on the basis of their correspondence to claim 1, the foregoing analysis applies equally to those claims.
Applicant further argues (Remarks, p. 10) that “The dependent claims incorporate the limitations of their respective claims and are therefore allowable.”
This argument is not persuasive. Applicant advances no argument directed to the separate patentability of any dependent claim, and instead relies solely upon the asserted allowability of the independent claims from which those claims depend. Because the independent claims are not allowable for the reasons set forth above, the dependent claims are not allowable by virtue of their dependency. See MPEP § 2145. The rejections of the dependent claims are maintained for the reasons of record, as restated below.
Applicant’s attention is directed, however, to the Allowable Subject Matter section below. As indicated in the Non-Final Office Action and as maintained herein, the subject matter of claims 6, 8-9, 16, 18-19 and 23-24 would be allowable if rewritten in independent form. Applicant is further advised that the subject matter of canceled claim 5 remains allowable if recited as a required limitation of claim 1, rather than as one of several alternatives.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 6, 8-14, 16 and 18-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claim 1, the claim recites the indefinite article “a schema” twice, introducing two separate schemas. The claim first recites “a schema of a database for storing data of the database application” in the configuring step, and thereafter recites, in the newly added fourth alternative of the receiving step, “description of a schema for storing data processed by the database application.” The claim also recites “the schema of the database” in the first alternative of the receiving step. In view of the two separate indefinite introductions, it cannot be determined which of the two recited schemas is referenced by “the schema of the database.” The metes and bounds of the claim are therefore indefinite. Appropriate correction is required; applicant may, for example, amend the fourth alternative to recite “description of the schema of the database” if a single schema is intended.
With respect to claim 6, the claim recites “database commands for generating the schema of a database for storing data processed by the database application.” The recitation combines the definite article “the” with the indefinite article “a database,” and, in view of the two separate schemas introduced in claim 1, it cannot be determined which schema is referenced. The claim is therefore indefinite.
With respect to claim 8, the claim recites “information describing one or more indexes for efficient execution of the one or more database queries for accessing data stored using the schema of the database.” In view of the two separate schemas introduced in claim 1, it cannot be determined which schema is referenced. The claim is therefore indefinite.
With respect to claim 9, the claim recites “database commands for generating one or more indexes for efficient execution of the one or more database queries for accessing data stored using the schema of the database” and is indefinite for the same reasons set forth above with respect to claim 8.
With respect to claim 11, the claim recites limitations corresponding to those of claim 1 in the form of a non-transitory computer readable storage medium claim and is indefinite for the same reasons set forth above with respect to claim 1.
With respect to claim 16, the claim recites limitations corresponding to those of claim 6 in the form of a non-transitory computer readable storage medium claim and is indefinite for the same reasons set forth above with respect to claim 6.
With respect to claim 18, the claim recites limitations corresponding to those of claim 8 in the form of a non-transitory computer readable storage medium claim and is indefinite for the same reasons set forth above with respect to claim 8.
With respect to claim 19, the claim recites limitations corresponding to those of claim 9 in the form of a non-transitory computer readable storage medium claim and is indefinite for the same reasons set forth above with respect to claim 9.
With respect to claim 20, the claim recites limitations corresponding to those of claim 1 in the form of a computer system claim and is indefinite for the same reasons set forth above with respect to claim 1.
With respect to claim 23, the claim recites limitations corresponding to those of claim 6 in the form of a computer system claim and is indefinite for the same reasons set forth above with respect to claim 6.
With respect to claim 24, the claim recites limitations corresponding to those of claim 8 in the form of a computer system claim and is indefinite for the same reasons set forth above with respect to claim 8.
Dependent claims 2-4, 10, 12-14 and 21-22 do not overcome the deficiency of the base claim from which they depend and, therefore, are rejected under 35 U.S.C. § 112(b) for the same reasons as the base claim.
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, 3-4, 11, 13-14, 20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Paula Maddigan et al. (“Chat2VIS: Generating Data Visualisations via Natural Language using ChatGPT, Codex and GPT-3 Large Language Models”, hereinafter “Maddigan”) in view of Disha Shrivastava et al. (“Repository-Level Prompt Generation for Large Language Models of Code”, hereinafter “Shrivastava”).
With respect to claim 1 (Currently Amended), A computer-implemented method comprising:
configuring a user interface of [[an integrated development environment for developing database applications]], wherein the user interface is configured to display one or more of: code being developed for a database application, a schema of a database for storing data of the database application, or sample data processed by the database application (Maddigan teaches configuring the Streamlit user interface to display sample data processed by the database application in the form of a tabular display of the loaded dataset, alongside the natural language input box and the resulting visualization. Maddigan further teaches that the side toolbar of the user interface provides the functionality to import CSV files and SQLite databases for processing (Maddigan, p. 45184, col. 2: “The interface enables users to select a dataset and enter free-form text describing their data visualisation intent. The side toolbar provides the functionality to import additional CSV files and SQLite databases”; see also Fig. 3 at p. 45187 depicting the rendered interface with the dataset tabularly displayed beneath the input box)).
sending the user interface of the [[integrated development environment]] for display via a client device (Maddigan teaches that the user interface is implemented as a “Streamlit NLI app which is an open-source Python framework for web-based dashboards” (Maddigan, p. 45184, col. 2). The web-based dashboard is necessarily transmitted to and rendered at a client device (e.g., a user’s browser) for display (id.; Fig. 2 at p. 45184 depicting the user interacting with the interface on a client computing device)).
receiving via the user interface of the [[integrated development environment]], a natural language request for information related to development of the database application, wherein the information related to development of the database application represents one or more of: a database query for accessing data stored using the schema of the database; a resultset obtained by executing the database query; a chart representing the resultset obtained by executing the database query; or description of a schema for storing data processed by the database application (Maddigan teaches receiving via the Streamlit user interface a free-form natural language request from the user (Maddigan, p. 45184, col. 2: “A user enters a NL query via a Streamlit NLI app . . .”). The limitation recites four alternatives joined by the transitional phrase “one or more of,” and is therefore satisfied by prior art teaching any one of the recited alternatives. Maddigan teaches the third recited alternative. The requested information represents a chart representing the resultset obtained by executing the database query. For example, in Case Study 1, Maddigan teaches receiving the natural language request “What is the highest price of product, grouped by product type? Show a bar chart, and display by the names in desc” against the nvBench department_store SQLite database, and producing a bar chart depicting the highest price of product grouped by product type—that is, a chart representing the resultset obtained by executing the corresponding aggregation query against the database (Maddigan, p. 45186, col. 2 – p. 45187; Fig. 5 at p. 45187)).
determining contextual information [[describing a development task associated with the database application being developed]] (Maddigan teaches determining contextual information about the database, comprising a “Description Prompt” that enumerates the dataframe name, column names, column data types, and categorical column values (Maddigan, p. 45185, col. 1; Fig. 4(b)–(c) at p. 45187), together with a “Code Prompt” comprising Python import statements and a starting dataframe variable assignment (Maddigan, p. 45185, col. 2; Fig. 4(h)–(j) at p. 45187)).
generating a prompt for input to a machine learning based language model based on the natural language request and the contextual information (Maddigan teaches that the natural language query is inserted into the Description Prompt (Maddigan, Fig. 4(f) at p. 45187) and that “the two prompt elements are amalgamated, with the resulting string submitted to the LLMs via the text completion endpoint API” (Maddigan, p. 45185, col. 2)).
providing the prompt to the machine learning based language model for execution (Maddigan teaches submitting the assembled prompt via the OpenAI text-completion endpoint API to the GPT-3 (“text-davinci-003”), Codex (“code-davinci-002”), and ChatGPT large language models (Maddigan, p. 45184, col. 2; p. 45185, Table 1)).
receiving a response to the prompt from the machine learning based language model (Maddigan teaches that the large language model returns a Python script as the response (Maddigan, p. 45186, col. 1: “On the return of the script from the API for each model, the Code Prompt is inserted at the start and the Python code may be edited to eliminate unnecessary instructions”)).
extracting the information related to development of the database application from the response generated by the machine learning based language model (Maddigan teaches extracting the returned Python script (and, upon execution thereof, the chart it produces) from the language model’s response, including editing the script to eliminate extraneous text returned by the model (Maddigan, p. 45186, col. 1)).
displaying the information via the user interface of the [[integrated development environment]] (Maddigan teaches that the Python script returned by the language model, when executed, renders the resulting chart in the Streamlit user interface for display to the user: “It is rendered on the interface for each LLM” (Maddigan, p. 45186, col. 1; see also Figs. 5–10 at pp. 45187–45192 illustrating the rendered visualizations displayed in the user interface)).
Maddigan is silent to disclose an integrated development environment for developing database applications and contextual information describing a development task associated with the database application being developed; however, in an analogous art, Shrivastava teaches:
an integrated development environment for developing database applications (Shrivastava teaches a framework in which a large language model is integrated with an integrated development environment for developing applications. Shrivastava teaches that Codex, the same OpenAI large language model used by Maddigan, “has been deployed as part of GitHub Copilot, a state-of-the-art in-IDE code assistant” (Shrivastava, p. 1, col. 2). Shrivastava further teaches that its Repo-Level Prompt Generator (RLPG) framework operates “on the task of single-line code autocompletion in an IDE, where the objective is to predict the blanked-out portion (or target hole) starting from the position of an imagined cursor to the end of the line” (Shrivastava, p. 2, col. 2). Fig. 1 of Shrivastava (p. 2) depicts the integrated development environment displaying the current file containing the code being developed (the file AffinityPropagation.java), the directory structure of the repository in which the application is stored, and the position of the developer’s cursor at which code is being authored. Shrivastava expressly teaches that its framework is “quite general and applicable to other programming languages” and that “our framework provides the flexibility to incorporate new prompt proposals” (Shrivastava, p. 6, col. 1), making it applicable to an integrated development environment for developing database applications of the kind used by Maddigan).
describing a development task associated with the database application being developed (Shrivastava teaches a Prompt Proposal Classifier that determines contextual information describing the developer’s current development task. Specifically, Shrivastava teaches that the Prompt Proposal Classifier “takes in the hole position (position of the cursor) in the current file, the repository to which the current file belongs, and a set of repo-level prompt proposals as input, and predicts a prompt proposal” representing contextual information about the development task at the cursor position (Shrivastava, p. 2, col. 2 – p. 3, col. 1; Fig. 1 at p. 2). Shrivastava enumerates ten prompt sources from which contextual information describing the development task is drawn, including: code from the current file at the cursor position, code from the parent class file of the class to which the target hole belongs, code from import files used in the current file, code from sibling files in the same directory, code from files having a similar name to the current file, code from child class files, and code from import files of each of the foregoing (Shrivastava, p. 3, col. 2 – p. 4, col. 1). Shrivastava characterizes the assembled context as describing the development task at the cursor position, explaining that “the dependencies specified via imports can provide useful cues to predict the target hole” and that the selected context is tied to what the developer is presently developing (Shrivastava, p. 3, col. 2)).
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 natural language interface taught by Maddigan to be implemented as part of an integrated development environment for developing database applications, of the kind taught by Shrivastava, and to augment the contextual information taught by Maddigan with contextual information describing the developer’s current development task, as taught by Shrivastava, in order to arrive at the claimed invention.
A person of ordinary skill in the art would have been motivated to make this combination for the following reasons. First, Maddigan and Shrivastava address the same problem in the same field of endeavor—namely, improving the relevance and accuracy of large language model outputs by augmenting the user’s natural language input with structured contextual information drawn from the data and code that the user is presently working with—and both employ the same family of OpenAI large language models (e.g., GPT-3 and Codex) under the same black-box prompting paradigm. Maddigan expressly recognizes the value of augmenting the natural language query with schema-level context by way of its Description Prompt (Maddigan, p. 45185, col. 1; Fig. 4 at p. 45187), and Shrivastava analogously teaches that “the relevant context to be put in the prompt can come from not just the current file, but also from outside, such as imports, parent classes, files within the same directory, and API documentation” and that “it becomes increasingly crucial for our domain-specific understanding to guide the selection of relevant context” (Shrivastava, p. 1, col. 2). Second, Shrivastava expressly contemplates extending its prompt-augmentation framework beyond its illustrative Java code-completion use case, teaching that the framework’s prompt proposals “are quite general and applicable to other programming languages” and that the framework “provides the flexibility to incorporate new prompt proposals” (Shrivastava, p. 6, col. 1). A person of ordinary skill in the art reading Maddigan and Shrivastava would therefore have recognized that Maddigan’s natural language interface for generating charts from a database could be implemented within Shrivastava’s integrated development environment framework, yielding an integrated development environment for developing database applications. Third, a person of ordinary skill in the art would have recognized that supplementing Maddigan’s static schema-level Description Prompt with development-task context drawn from the current file, imports, and repository structure (as taught by Shrivastava) would predictably improve the relevance of the language model’s output to the developer’s current task, in the same manner that Shrivastava’s repo-level context improves Codex’s code-completion accuracy by 17–36% over the default Codex context (Shrivastava, p. 3, col. 1; Table 3 at p. 7). The proposed combination is no more than the predictable use of prior-art elements according to their established functions, yielding the predictable result of an integrated development environment for developing database applications in which a developer’s natural language request is augmented with development-task context before being provided to the large language model, and the language model’s response is extracted and displayed within the integrated development environment.
With respect to claim 3 (Original), Maddigan is silent to disclose; however, in an analogous art, Shrivastava teaches wherein the contextual information describing the development task associated with the database application being developed comprises description of one or more code submissions to a code repository storing code of the database application being developed (Shrivastava teaches that the contextual information used to augment the prompt is drawn from a code repository storing the code of the application being developed, and includes code from one or more code submissions to that repository, namely: code from the current file at the cursor position; code from the parent class file; code from import files used in the current file; code from sibling files in the same directory as the current file; code from files having a similar name to the current file; and code from child class files (Shrivastava, p. 3, col. 2 – p. 4, col. 1; Fig. 1 at p. 2 depicting the repository directory structure). Each such file constitutes a code submission to the repository, and the code contained therein constitutes a description of the corresponding code submission).
The motivation to combine the teachings of Maddigan and Shrivastava is the same as that set forth above with respect to claim 1.
With respect to claim 4 (Currently Amended), Maddigan is silent to disclose; however, in an analogous art, Shrivastava teaches wherein the integrated development environment stores code of the database application being developed in a code repository, the computer-implemented method further comprising: accessing from the code repository, information describing a project associated with the database application being developed, wherein the contextual information comprises the information describing the project (Shrivastava teaches an integrated development environment in which the code being developed is stored in a code repository (Shrivastava, p. 1, col. 2; Fig. 1 at p. 2 depicting the repository directory structure including the model/parameters/, utils/, and sampler/ directories of the project). Shrivastava further teaches accessing the code repository to obtain information describing the project, including the structure of the repository (e.g., the directory hierarchy and inter-file dependencies such as parent-class, import, and sibling relationships), and using this project-describing information as the contextual information for prompt generation: Shrivastava’s Repo-Level Prompt Generator “while generating the prompt, incorporates both the structure of the repository as well as the relevant context in the files in the repository” (Shrivastava, p. 1, col. 2)).
The motivation to combine the teachings of Maddigan and Shrivastava is the same as that set forth above with respect to claim 1.
With respect to claim 11 (Currently Amended), claim 11 recites limitations similar to claim 1 and differs only in that the limitations are recited as A non-transitory computer readable storage medium storing instructions that when executed by one or more computer processors, cause the one or more computer processors to perform steps comprising. Maddigan teaches such a medium, disclosing that its method is implemented in software submitted to the OpenAI API and rendered via the Streamlit Python framework (Maddigan, p. 45184, col. 2; p. 45185, Table 1). Claim 11 is otherwise rejected for the same reasons set forth above for claim 1, including the same motivation to combine.
With respect to claim 13 (Original), claim 13 recites limitations similar to claim 3 in the form of a non-transitory computer readable storage medium claim and is rejected for the same reasons set forth above for claim 3 (Shrivastava, p. 3, col. 2 – p. 4, col. 1; Fig. 1 at p. 2), including the same motivation to combine.
With respect to claim 14 (Currently Amended), claim 14 recites limitations similar to claim 4 in the form of a non-transitory computer readable storage medium claim and is rejected for the same reasons set forth above for claim 4 (Shrivastava, p. 1, col. 2; Fig. 1 at p. 2), including the same motivation to combine.
With respect to claim 20 (Currently Amended), claim 20 recites limitations similar to claim 1 and differs only in that the limitations are recited as A computer system comprising: one or more computer processors; and a non-transitory computer readable storage medium storing instructions that when executed by one or more computer processors, cause the one or more computer processors to perform steps comprising. Maddigan teaches such a system, disclosing execution of its method on a computer system comprising one or more processors and storage media (Maddigan, p. 45184, col. 2). Claim 20 is otherwise rejected for the same reasons set forth above for claim 1, including the same motivation to combine.
With respect to claim 22 (New), claim 22 recites limitations similar to claim 3 in the form of a computer system claim and is rejected for the same reasons set forth above for claim 3.
Claims 2, 12 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Paula Maddigan et al. (“Chat2VIS: Generating Data Visualisations via Natural Language using ChatGPT, Codex and GPT-3 Large Language Models”, hereinafter “Maddigan”) in view of Disha Shrivastava et al. (“Repository-Level Prompt Generation for Large Language Models of Code”, hereinafter “Shrivastava”) and further in view of Vadim Borisov et al. (“Language Models are Realistic Tabular Data Generators”, hereinafter “Borisov”).
With respect to claim 2 (Original), Maddigan in view of Shrivastava is silent to disclose; however, in an analogous art, Borisov teaches wherein the information related to development of the database application represents sample data for providing as input to the code being developed for the database application (While Maddigan teaches that a user imports sample data (in the form of CSV files or SQLite databases) into the Streamlit user interface for processing (Maddigan, p. 45184, col. 2), neither Maddigan nor Shrivastava expressly teaches that the large language model itself outputs sample data for providing as input to the code being developed for the database application. Borisov teaches a method, denominated “GReaT” (Generation of Realistic Tabular data), by which a pretrained, auto-regressive generative large language model is fine-tuned to output realistic synthetic tabular data conditioned on the schema of a tabular database (Borisov, Abstract at p. 1; Section 3 at pp. 4–7). Borisov teaches that each row of a tabular database is first transformed into a textual representation in subject-predicate-object form, e.g., “Age is 39, Education is Bachelors, Occupation is Adm-clerical, Gender is Male, Income is ≤ 50K.” (Borisov, Fig. 2 at p. 4; Section 3.1 at p. 4, Definition 1). A pretrained generative LLM (e.g., GPT-2 in Borisov’s experiments) is fine-tuned on the resulting textually encoded records (Borisov, Section 3.1 at p. 5). At inference time, the fine-tuned LLM is sampled—optionally conditioned on any subset of feature names or feature-value pairs—to output additional synthetic records that conform to the same schema as the original database table (Borisov, Section 3.2 at p. 6; Fig. 3 at p. 5). The output of Borisov’s LLM is, therefore, synthetic tabular sample data conditioned on the schema of the database. Borisov further teaches that the resulting synthetic tabular records are realistic and may be used in place of the real data in downstream consumers, including machine learning code and other applications operating on the database schema: “Since the generated data set should be able to replace the real data in a training process, this measure evaluates the performance of discriminative models trained on synthetic data sets” (Borisov, Section 4 at p. 8). The synthetically generated tabular data is thus sample data for providing as input to the code being developed for the database application).
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 integrated development environment of Maddigan in view of Shrivastava such that the large language model further outputs realistic synthetic tabular sample data conditioned on the schema of the database, as taught by Borisov, the synthetic tabular sample data being provided as input to the code being developed for the database application.
A person of ordinary skill in the art would have been motivated to make this combination for the following reasons. First, Maddigan, Shrivastava, and Borisov operate in the same field of endeavor of harnessing pretrained large language models for tasks involving structured tabular data and the schemas thereof, and all three references encode tabular schema information as natural language for input to the LLM (Maddigan, p. 45185, col. 1; Fig. 4(b)–(c) at p. 45187; Shrivastava, p. 1, col. 2; Borisov, Section 3.1 at p. 4; Fig. 2 at p. 4). Second, the generation of realistic synthetic sample data is a recognized need in database application development—e.g., for populating test fixtures, exercising application code against representative inputs, and supporting development in privacy-sensitive contexts where production data is not available—and Borisov expressly identifies its synthesized samples as suitable for replacing real data in downstream consumers (Borisov, Section 4 at p. 8). A person of ordinary skill in the art reading Maddigan and Shrivastava in light of Borisov would therefore have recognized that the natural language interface of Maddigan, when deployed within the integrated development environment of Shrivastava, could be extended to perform the additional task of generating sample data for the database application being developed, simply by directing the developer’s natural language request to that task and applying Borisov’s GReaT pipeline to the schema already extracted by Maddigan’s Description Prompt. Third, Borisov expressly identifies its approach as a drop-in component with minimal integration cost: “we provide an easy-to-use Python implementation of the GReaT model, where it takes only three lines of code to generate new synthetic samples. Access to the package is provided via pip install be-great” (Borisov, Section 1 at p. 3). The combination amounts to no more than the predictable use of prior-art elements—Maddigan’s natural-language-prompt-to-LLM-to-display pipeline within Shrivastava’s integrated development environment, with the LLM’s task switched from chart generation to Borisov’s schema-conditioned tabular data generation—according to their established functions, yielding the predictable result of an integrated development environment for developing database applications in which the developer’s natural language request causes the large language model to output sample data for providing as input to the code being developed.
With respect to claim 12 (Original), claim 12 recites limitations similar to claim 2 in the form of a non-transitory computer readable storage medium claim and is rejected for the same reasons set forth above for claim 2.
With respect to claim 21 (New), claim 21 recites limitations similar to claim 2 in the form of a computer system claim and is rejected for the same reasons set forth above for claim 2.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Paula Maddigan et al. (“Chat2VIS: Generating Data Visualisations via Natural Language using ChatGPT, Codex and GPT-3 Large Language Models”, hereinafter “Maddigan”) in view of Disha Shrivastava et al. (“Repository-Level Prompt Generation for Large Language Models of Code”, hereinafter “Shrivastava”) and further in view of Patrick Bareiß et al. (“Code Generation Tools (Almost) for Free? AStudy of Few-Shot, Pre-Trained Language Models on Code”, hereinafter “Bareiß”). With respect to claim 10 (Previously Presented), Maddigan in view of Shrivastava is silent to disclose; however, in an analogous art, Bareiß teaches wherein the information related to development of the database application represents one or more unit tests for testing the database application (While the framework of Maddigan as modified by Shrivastava processes a natural language request within an integrated development environment for developing database applications and causes the large language model to output information related to development of the database application, neither Maddigan nor Shrivastava expressly teaches that the large language model output represents one or more unit tests for testing the database application. Bareiß teaches a methodology for using a pretrained generative large language model—OpenAI’s Codex, which is the same model used by both Maddigan (Maddigan, p. 45185, Table 1) and Shrivastava (Shrivastava, p. 1, col. 2)—to generate unit tests for a method under test (Bareiß, Abstract at p. 1; Section 3.4 at p. 5). Bareiß describes the test generation task as follows: “we consider the problem of generating unit tests. This task represents a class of tasks where the FSLM generates a method, i.e., a larger portion of code compared with the previous examples. Test case generation is a labor-intensive task in software testing . . . , and several techniques have been proposed to automate unit test case generation” (Bareiß, Section 3.4 at p. 5). Bareiß’s prompt for unit test generation (Bareiß, Fig. 4 at p. 6) presents Codex with (i) a natural-language task description, (ii) a list of helper constructors and methods relevant to the method under test, (iii) the method under test itself, and (iv) an example test, and obtains from Codex a generated unit test that exercises the method under test (Bareiß, Section 3.4.3 at p. 6; Section 3.4.4 at p. 6). Bareiß reports that, across the eighteen methods under test in its evaluation, this FSLM-based unit test generator outperforms the established Randoop tool, achieving 14% line coverage versus 10% for Randoop (Bareiß, Section 4.1.3 at p. 7; Table 5 at p. 8). Bareiß thus teaches that the large language model output represents one or more unit tests for the application under test).
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 integrated development environment of Maddigan in view of Shrivastava such that the large language model further outputs one or more unit tests for testing the database application being developed, as taught by Bareiß. A person of ordinary skill in the art would have been motivated to make this combination for the following reasons. First, Maddigan, Shrivastava, and Bareiß all employ the same family of OpenAI Codex/GPT-3 large language models for code- and data-related tasks (Maddigan, p. 45185, Table 1; Shrivastava, p. 1, col. 2; Bareiß, Section 2 at p. 2). Second, automated generation of unit tests is a long-recognized and essential aspect of application development—an activity that the integrated development environment of Maddigan as combined with Shrivastava is intended to support—and Bareiß expressly identifies test case generation as a “labor-intensive task in software testing” for which LLM-based automation is both desirable and practicable (Bareiß, Section 3.4 at p. 5). Third, Bareiß expressly contemplates that its methodology is generalizable across diverse code generation tasks, framing the contribution as the ability to obtain “code generation tools (almost) for free” by reusing a single pretrained model for many tasks (Bareiß, Abstract at p. 1; Section 1 at pp. 1–2). A person of ordinary skill in the art reading Maddigan, Shrivastava, and Bareiß would therefore have recognized that the natural language interface of Maddigan, when deployed within the integrated development environment of Shrivastava, could be extended to support unit test generation simply by directing the developer’s natural language request to that task and applying Bareiß’s prompt template and post-processing to the method under test. The combination amounts to no more than the predictable use of prior-art elements—Maddigan’s natural-language-prompt-to-LLM-to-display pipeline within Shrivastava’s integrated development environment, with the LLM’s task switched from chart generation to Bareiß’s test case generation—according to their established functions, yielding the predictable result of an integrated development environment for developing database applications in which the developer’s natural language request causes the large language model to output one or more unit tests for testing the database application being developed.
Allowable Subject Matter
Claims 6, 8-9, 16, 18-19 and 23-24 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if the rejection under 35 U.S.C. § 112(b) set forth above is overcome.
The following is a statement of reasons for the indication of allowable subject matter: the prior art of record does not teach or fairly suggest, in combination with the remaining limitations of the corresponding base claim, that the information related to development of the database application output by the machine learning based language model represents (i) database commands for generating the schema of a database for storing data processed by the database application (claims 6, 16 and 23), (ii) information describing one or more indexes for efficient execution of the database queries for accessing data stored using the schema of the database (claims 8, 18 and 24), or (iii) database commands for generating one or more such indexes together with executing those database commands (claims 9 and 19).
Applicant is further advised that the subject matter of canceled claim 5—that the information related to development of the database application represents a description of a schema for storing data processed by the database application—remains allowable over the prior art of record when recited as a required limitation of an independent claim, rather than as one of several alternatives recited in a “one or more of” group.
Conclusion
Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights