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 .
Claims 1-20 are presented for examination.
Allowable Subject Matter
Claim 5, 7, 9, 11 and 19 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 101 and U.S.C. 112(b) set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 16-19 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 16 recites, in the "generating a page generation prompt" limitation, the phrase "to generate a page of a software application using the metadata of the artifacts." There is insufficient antecedent basis for the limitation "the metadata of the artifacts" (plural) in the claim. Claim 16 earlier introduces "generating analysis data for an artifact in the plurality of artifacts based on metadata of the artifact" (singular) and "generating a page generation prompt based on the metadata of the artifact" (singular). The claim does not previously recite "metadata of the artifacts" (plural), and it is therefore unclear whether "the metadata of the artifacts" refers to (a) the previously recited "metadata of the artifact" for the single artifact for which the analysis data and page generation prompt are generated, or (b) the collective metadata of every artifact in the plurality of artifacts. Because the metes and bounds of the claim cannot be determined, claim 16 is indefinite.
Dependent claims 17-19 are also rejected under 35 U.S.C. 112(b) as being indefinite for failing to cure the deficiencies of their independent claims.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 16 and 20 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation "generating analysis data for an artifact in the plurality of artifacts based on metadata of the artifact; generating a page generation prompt based on the metadata of the artifact and the analysis data for the artifact, the page generation prompt being configured to instruct a large language model to generate a page of a software application using the metadata of the artifact" as drafted, is a process that, under its broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation, judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the "Mental Processes" grouping of abstract ideas.
This judicial exception is not integrated into a practical application. The claims recite the following additional elements "at least one hardware processor; and a non-transitory computer-readable medium storing executable instructions that, when executed, cause the at least one hardware processor to perform computer operations," "a non-transitory machine-readable storage medium tangibly embodying a set of instructions that, when executed by at least one hardware processor, causes the at least one hardware processor to perform computer operations," "using the large language model," and "obtaining a configuration of a process created via a software development platform, the configuration of the process comprising a plurality of artifacts, wherein each artifact in the plurality of artifacts has a manifest file comprising metadata that defines an artifact type, input parameters, and output parameters of the artifact," "obtaining a metadata file for the page of the software application based on the page generation prompt using the large language model; and providing the metadata file for the page of the software application to the software development platform, wherein the metadata file comprises a specification of one or more user interface controls, and wherein the software development platform is configured to render the page on a computing device based on the metadata file without program code for the page being manually written." The additional elements "at least one hardware processor," "a non-transitory computer-readable medium," "a non-transitory machine-readable storage medium," and "using the large language model," are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). The additional elements directed to obtaining a configuration of a process comprising a plurality of artifacts each having a manifest file, obtaining a metadata file, and providing/rendering the metadata file, do nothing more than add insignificant extra-solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea to perform a task. See MPEP 2106.05(g). The recitation that the software development platform renders the page "without program code for the page being manually written" does not impose a meaningful limit; it merely states the field of use (no-code/low-code software development) and the intended result of the extra-solution output step, and generally linking the use of the abstract idea to a particular technological environment does not integrate the abstract idea into a practical application. See MPEP 2106.05(h). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements "at least one hardware processor," the non-transitory media, and "using the large language model," are generic computer components and instructions used as tools to perform the abstract idea. See MPEP 2106.05(f). As to the additional elements directed to obtaining the configuration and artifacts, obtaining the metadata file, and providing/rendering the metadata file, the courts have identified receiving or transmitting data over a network, gathering data, and displaying or outputting the results of the abstract idea as well-understood, routine, and conventional activity. See MPEP 2106.05(d). The recitation of rendering a page from a metadata file specifying user interface controls "without program code for the page being manually written" is itself well-understood, routine, and conventional, as evidenced by at least Dengler (US 2007/0130205 A1, Para [0002], [0007], [0033]), which discloses that instead of an "application developer hard cod[ing] this functionality into the application," a metadata file defining UI controls is processed by a rendering engine to display the UI controls. Accordingly, the additional elements recited in the claims, considered individually and as an ordered combination, cannot provide an inventive concept. Thus, the claims are not patent eligible.
Claims 2 and 17 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation "determining that an artifact in the plurality of artifacts satisfies a set of one or more criteria based on the metadata of the artifact, wherein the generating of the analysis data for the artifact, the generating of the page generation prompt, and the obtaining of the metadata file are performed based on the determining that the artifact satisfies the set of one or more criteria" recites the abstract idea of mental processes (observation, evaluation, judgment and/or opinion). The additional elements add only insignificant extra-solution activity and generic computer implementation and do not integrate the abstract idea into a practical application or amount to significantly more. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claims 3 and 18 as drafted, recite the limitation "identifying an artifact type of the artifact based on the metadata of the artifact; and determining that the artifact type of the artifact is included in a list of artifact types", which recites the abstract idea of mental processes because these functions can be reasonably carried out through observation, evaluation, judgment and/or opinion, or even with the aid of pen and paper. The additional elements do not integrate the exception into a practical application or amount to significantly more, for the reasons given above. Thus, these claims are not patent eligible.
Claim 4 further defines the "list of artifact types" as part of the "identifying" function set forth in the claim from which it depends, and is also considered to recite a mental process since it can be reasonably carried out through observation, evaluation, judgment and/or opinion, or even with the aid of pen and paper. Thus, this claim is not patent eligible.
Claims 5 and 19 as drafted, recite the limitation "generating a suitability determination prompt based on the key-value pairs for the plurality of user interface properties of the artifact and the list of vector embeddings corresponding to the guidelines for suitability, the suitability determination prompt being configured to instruct the large language model to compute an evaluation score indicating a level of suitability of the artifact for mobile applications... and determining that the evaluation score satisfies a suitability threshold value", which recites the abstract idea of mental processes. The additional elements "using the large language model" and "obtaining key-value pairs... obtaining a list of vector embeddings... based on a querying of a vector database... obtaining the evaluation score" are generic computer implementation and insignificant extra-solution data gathering, respectively, and do not integrate the exception into a practical application or amount to significantly more. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claim 6 further defines the "analysis" function set forth in the claim from which it depends, and is also considered to recite a mental process. Thus, this claim is not patent eligible.
Claims 7, 9 and 11 as drafted, recite the limitation "generating an analysis generation prompt based on the manifest file of the artifact and the list of vector embeddings, the analysis generation prompt being configured to instruct the large language model to generate the analysis... using the manifest file of the artifact and the list of vector embeddings", which recites the abstract idea of mental processes. The additional elements "using the large language model" and "obtaining key-value pairs from a manifest file of the artifact; obtaining a list of vector embeddings from a vector database... based on a querying of the vector database... obtaining the analysis... based on the analysis generation prompt" are generic computer implementation and insignificant extra-solution data gathering, and do not integrate the exception into a practical application or amount to significantly more. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claims 8 and 10 further define the "analysis" function set forth in the claims from which they depend, and are also considered to recite a mental process. Thus, these claims are not patent eligible.
Claim 12 recites the additional element "obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge for no-code development of mobile applications based on a querying of the vector database using the analysis data", which does nothing more than add insignificant extra-solution activity to the judicial exception, such as data gathering. See MPEP 2106.05(g). Further, the courts have identified gathering data as well-understood, routine, and conventional activity. See MPEP 2106.05(d). Accordingly, this claim does not integrate the abstract idea into a practical application and does not provide an inventive concept. Thus, this claim is not patent eligible.
Claim 13 further defines the "documents of domain knowledge" as part of the "obtaining" function set forth in the claim from which it depends, which does nothing more than add insignificant extra-solution activity (data gathering). See MPEP 2106.05(g), (d). Thus, this claim is not patent eligible.
Claim 14 further defines the "metadata file" as part of the "generating"/"providing" function set forth in the claim from which it depends, and is also considered to recite a mental process. Thus, this claim is not patent eligible.
Claim 15 recites "generating a build version of the software application based on the metadata file using the software development platform" and the additional element "deploying the build version of the software application to an application lifecycle management service", which does nothing more than add insignificant extra-solution activity (outputting the results of the abstract idea). See MPEP 2106.05(g), (d). Thus, this claim is not patent eligible.
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-4, 6, 8, 10, 14-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Grigore (US 2025/0199774 A1) in view of Singh (US 2023/0385085 A1) and Shukla (US 8,170,901 B2) and further in view of Dengler (US 2007/0130205 A1).
Regarding Claim 1, Grigore teaches
A computer-implemented method comprising:
obtaining a configuration of a process created via a software development platform, the configuration of the process comprising a plurality of artifacts, (Para [0026], "The input source can take various forms. For instance, a user may enter a natural language sentence, provide a source document (e.g., a spreadsheet file, a JavaScript Object Notation (JSON) file... a Portable Document Format (PDF) file... etc.), write pseudocode for the desired task, etc.") Examiner Comments: Grigore teaches obtaining a configuration of a process (input source such as a document or pseudocode describing a desired task) created via a software development platform (RPA developer platform), the configuration comprising a plurality of artifacts (documents, files, pseudocode) that are used to generate the RPA workflow.
generating analysis data for an artifact in the plurality of artifacts based on metadata of the artifact; (Para [0031], "The cognitive AI layer may use a CV model to understand what graphical elements and text are present in the screen, and a generative AI model may create a software application that includes these graphical elements...") Examiner Comments: Grigore teaches generating analysis data (understanding of graphical elements and text) for an artifact (screen drawing or diagram) based on metadata of the artifact (the graphical elements and text within the artifact).
generating a page generation prompt based on the metadata of the artifact and the analysis data for the artifact, the page generation prompt being configured to instruct a large language model to generate a page of a software application using the metadata of the artifact; (Para [0031], "a diagram representing a design of a screen may be used to automatically generate an associated application. Consider the case where a user has designed a Visio® diagram of a UI for a screen... The cognitive AI layer may use a CV model to understand what graphical elements and text are present in the screen, and a generative AI model may create a software application that includes these graphical elements...") Examiner Comments: Grigore teaches generating a page generation prompt (input to the generative AI model based on the understood graphical elements and text) configured to instruct a large language model (generative AI model) to generate a page (screen) of a software application using the metadata of the artifact (the generative AI model creates the application to include the graphical elements and text understood from the artifact).
obtaining a metadata file for the page of the software application based on the page generation prompt using the large language model; and (Para [0032], "a user may submit a diagram of a desired process to automate. The high level steps of this process may then be generated as an RPA workflow. For instance, the generative AI model may be trained to understand text in the steps and the associations therebetween as shown by connectors.") Examiner Comments: Grigore teaches obtaining a metadata file (generated RPA workflow, which is a workflow file containing metadata describing the steps) for the page based on the page generation prompt using the large language model (generative AI model).
providing the metadata file for the page of the software application to the software development platform, (Para [0059], "The output from the cognitive AI layer may include... a newly generated RPA workflow...") Examiner Comments: Grigore teaches providing the metadata file (generated RPA workflow) to the software development platform (RPA designer or development environment).
Grigore did not specifically teach
the configuration of the process comprising a plurality of artifacts;
wherein each artifact in the plurality of artifacts has a manifest file comprising metadata that defines an artifact type, input parameters, and output parameters of the artifact;
wherein the metadata file comprises a specification of one or more user interface controls, and wherein the software development platform is configured to render the page on a computing device based on the metadata file without program code for the page being manually written.
However, Singh teaches
the configuration of the process comprising a plurality of artifacts (Para [0024], "User interactions extracted from data collected from multiple computing systems... combined into sequences associated with tasks... sequences of user interactions... used to generate RPA robots that are configured to perform the tasks.") Examiner Comments: Singh teaches a process configuration comprising a plurality of artifacts (sequences of user-interaction elements extracted from user data and combined into tasks) that are used by the RPA generation system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Grigore’s teaching with Singh’s in order to enhance process extraction by incorporating detailed user-interaction artifacts, thereby improving the accuracy and completeness of automated RPA generation by using generative artificial intelligence (AI)/machine learning (ML) models to determine sequences of user interactions with computing systems, extract common processes, and generate robotic process automation (RPA) robots (Singh, Summary).
Grigore and Singh did not specifically teach
wherein each artifact in the plurality of artifacts has a manifest file comprising metadata that defines an artifact type, input parameters, and output parameters of the artifact
wherein the metadata file comprises a specification of one or more user interface controls, and wherein the software development platform is configured to render the page on a computing device based on the metadata file without program code for the page being manually written.
However, Shukla teaches
wherein each artifact in the plurality of artifacts has a manifest file comprising metadata that defines an artifact type, input parameters, and output parameters of the artifact (Col. 5 ln. 1-53; Col. 11 ln. 15-25, "each activity represents a component that encapsulates metadata for the step in a workflow process... each activity has at least three parts: metadata, instance data, and execution logic. The metadata of the activity defines data properties that may be configured... declaration of variables, messages, channels, and correlation sets; declaration of in/out/ref parameters; declaration of additional custom properties") Examiner Comments: Shukla teaches that each artifact (activity) in a plurality of artifacts (workflow) has associated metadata (a manifest) that defines the activity type (i.e., send activity, receive activity, code activity) along with its input and output parameters (declaration of "in/out/ref parameters"), thereby teaching a manifest-file metadata structure that defines an artifact type, input parameters, and output parameters of the artifact.
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 process artifacts of Grigore and Singh to incorporate Shukla’s teaching of activity metadata defining the activity type and in/out parameters for each artifact. One of ordinary skill would have been motivated to make this modification in order to provide an "extensible framework for building a componentized workflow model" in which "any developer may extend the core workflow model by authoring these components," thereby enabling the workflow engine to coordinate the execution of various kinds of workflows without requiring modifications to the engine itself (Shukla, Abstract; Col. 3 ln. 5-25).
Grigore, Singh, and Shukla did not specifically teach
wherein the metadata file comprises a specification of one or more user interface controls, and wherein the software development platform is configured to render the page on a computing device based on the metadata file without program code for the page being manually written.
However, Dengler teaches
wherein the metadata file comprises a specification of one or more user interface controls, (Para [0007], "an application developer can write a metadata file that defines basic as well as custom UI controls, properties of the controls, layout of the controls, and the like.") Examiner Comments: Dengler teaches a metadata file that comprises a specification of one or more user interface controls (basic and custom UI controls with their properties and layout).
and wherein the software development platform is configured to render the page on a computing device based on the metadata file (Para [0033], "the rendering engine 230 receives the metadata defining the UI through interpreter 220 and renders the UI form 240... the rendering engine 230 parses the metadata that is supplied by interpreter 220 and instantiates the different controls (i.e. 241-243) that are described by metadata 210 and outputs a .NET control describing the UI form.") Examiner Comments: Dengler teaches that the software development platform (rendering framework) is configured to render the page (UI form) on a computing device by parsing the metadata file and instantiating the specified UI controls, thereby rendering the page based on the metadata file.
without program code for the page being manually written. (Para [0002], "the application developer hard codes this functionality into the application making it cumbersome to change and update.") Examiner Comments: Dengler teaches rendering the page without program code for the page being manually written by replacing the prior approach in which the developer "hard codes this functionality" with an approach in which the developer instead writes a metadata file that a rendering engine processes to display the UI controls, so that the page is produced from the metadata file rather than from manually written page program code.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined teachings of Grigore, Singh, and Shukla with Dengler’s metadata-driven user-interface framework, so that the metadata file specifies UI controls that are rendered by the software development platform on a computing device without manually written page code. One of ordinary skill would have been motivated to make this modification to obtain the benefit that "once created, the metadata is processed by a rendering engine to display the UI controls" and that "neither the rendering engine nor the interpreter needs knowledge of the host application and provides support for arbitrary metadata driven UI" thereby avoiding the "cumbersome" hard coding described in Dengler (Para [Backgorund/Summary]).
Regarding Claim 2, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1. Grigore further teaches
determining that an artifact in the plurality of artifacts satisfies a set of one or more criteria based on the metadata of the artifact, wherein the generating of the analysis data for the artifact, the generating of the page generation prompt, and the obtaining of the metadata file are performed based on the determining that the artifact satisfies the set of one or more criteria. (Para [0027], "The cognitive AI layer may determine that the type of the PDF is an invoice... The cognitive AI layer may then suggest an automation to the user and automatically generate the automation, if desired.") Examiner Comments: Grigore teaches determining that an artifact (PDF document) satisfies a criterion (type is invoice) based on metadata (content type), and performing the downstream generation (suggesting and automatically generating the automation) based on that determination.
Regarding Claim 3, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 2. Grigore further teaches
identifying an artifact type of the artifact based on the metadata of the artifact; and determining that the artifact type of the artifact is included in a list of artifact types. (Para [0027], "The cognitive AI layer may determine that the type of the PDF is an invoice...") Examiner Comments: Grigore teaches identifying an artifact type (invoice) based on the metadata of the artifact and determining that the type is included in a list of recognized types suitable for automation.
Regarding Claim 4, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 3. Singh further teaches
wherein the list of artifact types comprises a decision, a form, and a trigger. (Para [0113], "Workflows may include user-defined activities 420, API-driven activities 430, AI/ML activities 440, and/or UI automation activities 450") Examiner Comments: Singh teaches a list of artifact types that includes a decision (condition activity within a workflow), a form (UI automation activity), and a trigger (driver-based/event activity that initiates the workflow).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Grigore’s teaching with Singh’s in order to enhance process extraction by incorporating detailed user-interaction artifacts, thereby improving the accuracy and completeness of automated RPA generation by using generative artificial intelligence (AI)/machine learning (ML) models to determine sequences of user interactions with computing systems, extract common processes, and generate robotic process automation (RPA) robots (Singh, Summary).
Regarding Claim 6, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore further teaches
wherein the analysis data comprises an analysis of a structure of the artifact. (Para [0031], "The cognitive AI layer may use a CV model to understand what graphical elements and text are present in the screen...") Examiner Comments: Grigore teaches analysis data comprising an analysis of the structure of the artifact (the graphical-element and text structure of the screen drawing).
Regarding Claim 8, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore further teaches
wherein the analysis data comprises an analysis of input and output parameters of the artifact. (Para [0027], "Consider the case where a PDF is an invoice. The cognitive AI layer may determine that the type of the PDF is an invoice... This may involve creating an RPA workflow with the appropriate activities...") Examiner Comments: Grigore teaches analysis of the input and output parameters of the artifact (the invoice fields, which serve as input/output parameters of the invoice-typed PDF artifact used to create the workflow).
Regarding Claim 10, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore further teaches
wherein the analysis data comprises an analysis of a business logic of the artifact. (Para [0032], "the generative AI model may be trained to understand text in the steps and the associations therebetween as shown by connectors.") Examiner Comments: Grigore teaches analysis data comprising an analysis of the business logic of the artifact (the steps and the associations between them shown by connectors in the process diagram).
Regarding Claim 14, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore further teaches
wherein the metadata file comprises a specification of one or more user interface controls. (Para [0034] "some embodiments leverage natural language processing (NLP) to automate form building... a form is automatically built or other code is automatically generated...") Examiner Comments: Grigore teaches metadata file (generated form or code) comprising specification of UI controls (form elements).
Regarding Claim 15, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore further teaches
generating a build version of the software application based on the metadata file using the software development platform; and deploying the build version of the software application to an application lifecycle management service. (Para [0163], "If the user accepts the automation at 1250, the automation is generated at 1260.") Examiner Comments: Grigore teaches generating a build version of the software application (the generated automation) based on the metadata file, and deploying it for execution by the RPA platform, which serves as an application lifecycle management service that manages creation, deployment, and monitoring of the automation.
Regarding Claim 16, is the system claim corresponding to claim 1, taught by the same references.
Regarding Claim 17, is the system claim corresponding to claim 2, taught by the same references.
Regarding Claim 18, is the system claim corresponding to claim 3-4, taught by the same references.
Regarding Claim 20, is the medium claim corresponding to claim 1, taught by the same references.
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Grigore (US 2025/0199774 A1) in view of Singh (US 2023/0385085 A1), Shukla (US 8,170,901 B2) and Dengler (US 2007/0130205 A1) and further in view of Qin (US 2024/0346256 A1).
Regarding Claim 12, Grigore, Singh, Shukla and Dengler teach the computer-implemented method of Claim 1.
Grigore, Singh, Shukla and Dengler did not specifically teach
wherein the generating of the page generation prompt comprises: obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge for no-code development of mobile applications based on a querying of the vector database using the analysis data.
However, Qin teaches
wherein the generating of the page generation prompt comprises: obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge for no-code development of mobile applications (Para [0018]; Para [0036], "The non-parametric memory is a vector dictionary. A knowledge base is built for domain-specific content. This is accomplished with "dense vector embeddings"... Dataset(s) 112 may include one or more databases storing augmentation information... domain-specific information (e.g., information related to specific topics or fields)"; Para [0041], "a second feature vector 224 may be generated for each piece of augmentation information in dataset(s) 112 and stored as second feature vectors 206 for future use") Examiner Comments: Qin teaches a vector database (a vector dictionary/knowledge base stored in dataset databases) of vector embeddings (dense vector embeddings) corresponding to documents of domain knowledge (domain-specific content/augmentation information. Qin further teaches that the vector database stores a plurality (list) of vector embeddings (second feature vectors), one for each piece of domain-knowledge augmentation information.
based on a querying of the vector database using the analysis data. (Para [0019]; Para [0045], "a query string may be encoded into a first feature vector that is compared to a plurality of second feature vectors to determine a subset of the second feature vectors that satisfy a predetermined condition... retriever 210 may... identify and retrieve one or more pieces of augmentation information 232 from dataset(s) 112") Examiner Comments: Qin teaches querying the vector database using a query (which, in the combination, is the analysis data) by encoding the query into a feature vector, comparing it to the stored vector embeddings, and retrieving the subset (list) of vector embeddings and corresponding augmentation information that satisfy the similarity condition.
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 teachings of Grigore, Singh, Shukla, and Dengler to Qin’s retrieval-augmented generation using a vector database of dense embeddings queried by the analysis data, so as to retrieve domain-knowledge documents for no-code mobile-application development to augment the page generation prompt, so that augmenting a large language model with retrieved domain-specific information reduces hallucination and improves the relevance and accuracy of the generated output, which directly improves the accuracy of Grigore’s LLM-based page and code generation (Qin, Para [0017]-[0018]).
Regarding Claim 13, Grigore, Singh, Shukla, Dengler and Qin teach the computer-implemented method of Claim 12.
Qin further teaches
wherein the documents of domain knowledge comprise at least one of: one or more metadata schemas of mobile applications; reference documentation for application programming interfaces; sample code; or business documentation comprising information for executing business operations. (Para [0036], "augmentation information stored in dataset(s) 112 may include, but are not limited to, domain-specific information (e.g., information related to specific topics or fields), entity-specific information (e.g., internal or proprietary corporate information)... augmentation information may be stored in dataset(s) 112 in a variety of formats, including, but not limited to, in a database (e.g., SQL, etc.), in one or more markup languages (e.g., HTML, XML, Markdown, etc.), in one or more file formats (e.g., .pdf, .doc, etc.)") Examiner Comments: Qin teaches that the documents of domain knowledge comprise at least one of the recited types because the domain-specific augmentation documents (which, in the combination with Grigore, are documentation for no-code/RPA mobile-application development) are stored in markup-language and file formats that encompass business documentation and reference documentation, reading on the alternative "business documentation comprising information for executing business operations" and "reference documentation for application programming interfaces" (the claim requiring only one of the listed alternatives).
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 teachings of Grigore, Singh, Shukla, and Dengler to Qin’s retrieval-augmented generation using a vector database of dense embeddings queried by the analysis data, so as to retrieve domain-knowledge documents for no-code mobile-application development to augment the page generation prompt, so that augmenting a large language model with retrieved domain-specific information reduces hallucination and improves the relevance and accuracy of the generated output, which directly improves the accuracy of Grigore’s LLM-based page and code generation (Qin, Para [0017]-[0018]).
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional paragraphs to address the newly added claimed limitations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights