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-11, 13, 15-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.
Claims 1-11, 13, and 15-20 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.
Independent claims 1, 16, and 20 each recite, in the "generating a page generation prompt" limitation, that the page generation prompt is "configured to instruct a large language model to generate a page of a software application using the metadata of the artifact, using the metadata of the artifact and the list of vector embeddings." The phrase "using the metadata of the artifact" appears twice in immediate succession, separated only by a comma. It is unclear whether the claim requires (a) a single act of generating the page using the metadata of the artifact and the list of vector embeddings, or (b) two distinct uses of "the metadata of the artifact," one of which additionally uses "the list of vector embeddings." Because the duplicated language renders the metes and bounds of the limitation unclear, claims 1, 16, and 20 are indefinite. Claims 2-11, 13, 15, 17-19 are rejected under 35 U.S.C. 112(b) as depending from, and incorporating the indefinite limitation of, claims 1 and 16.
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-11, 13, and 15-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 recite, under their broadest reasonable interpretation, steps that could be performed in the human mind or with the aid of pen and paper but for the recitation of generic computer components. Specifically, the limitations "generating analysis data for an artifact in the plurality of artifacts based on metadata of the artifact" and "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 and the list of vector embeddings" encompass a person mentally or manually observing, evaluating, and forming a judgment about an artifact and composing written instructions describing a page to be built. These limitations fall within the "Mental Processes" grouping of abstract ideas. See MPEP 2106.04(a)(2)(III).
This judicial exception is not integrated into a practical application. The claims recite the additional elements "at least one hardware processor; and a non-transitory computer-readable medium storing executable instructions," "a non-transitory machine-readable storage medium tangibly embodying a set of instructions," "a 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 defining an artifact type, input parameters, and output parameters of the artifact," "obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge of mobile applications, based on a querying of the vector database using the analysis data," "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, 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 the hardware processor, the non-transitory media, and the large language model amount to mere instructions to implement the abstract idea on a computer, or use of a generic computer or a generic machine-learning tool to perform the abstract idea. See MPEP 2106.05(f). The additional elements directed to obtaining the configuration and artifacts, querying the vector database to obtain the list of vector embeddings, and obtaining/providing/rendering the metadata file add only insignificant extra-solution activity, such as data gathering (the vector-database retrieval) and outputting the results of the abstract idea (providing and rendering the metadata file). See MPEP 2106.05(g). The recitation that the platform renders the page "without program code for the page being manually written" states an intended result and a field of use (no-code/low-code development) and does not impose a meaningful limit on the abstract idea. See MPEP 2106.05(h). Accordingly, the additional elements do not integrate the abstract idea into a practical application.
The claims do not include additional elements sufficient to amount to significantly more than the judicial exception. The generic computer components and the large language model are recited at a high level of generality and are well-understood, routine, and conventional. See MPEP 2106.05(d)(II). The vector-database retrieval and the obtaining/providing/rendering of the metadata file are well-understood, routine, and conventional activities: (i) using a vector database of embeddings to retrieve, by similarity, documents that augment a machine-learning prompt is evidenced as conventional by at least Chandel (US 2025/0068665 A1, Para [0016], [0025]-[0026]), and (ii) rendering a page from a metadata file specifying user interface controls without manually written program code is evidenced as conventional by at least Dengler (US 2007/0130205 A1, Para [0002], [0007], [0033]). Receiving and transmitting data over a network and outputting the results of an abstract idea are likewise recognized as well-understood, routine, and conventional. See MPEP 2106.05(d)(II). Considered individually and as an ordered combination, the additional elements do not provide an inventive concept. Thus, claims 1, 16, and 20 are not patent eligible.
Claims 2 and 17 recite "determining that an artifact in the plurality of artifacts satisfies a set of one or more criteria based on the metadata of the artifact" and performing the generating and obtaining steps based on that determination, which further recites the mental-process abstract idea and adds only generic computer implementation and insignificant extra-solution activity. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claims 3 and 18 recite "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 a mental process (observation, evaluation, judgment). The additional elements do not integrate the exception into a practical application or amount to significantly more. Thus, these claims are not patent eligible.
Claim 4 further defines the "list of artifact types" recited in the mental-process step from which it depends and is likewise directed to the abstract idea without significantly more. Thus, this claim is not patent eligible.
Claims 5 and 19 recite "generating a suitability determination prompt... 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 mental-process abstract idea. 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. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claims 6, 8, and 10 further define the "analysis" recited in the claim from which they depend (analysis of a structure, of input and output parameters, and of a business logic of the artifact, respectively) and are likewise directed to a mental process without significantly more. Thus, these claims are not patent eligible.
Claims 7, 9, and 11 recite "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...", which recites the mental-process abstract idea, and add "using the large language model" and "obtaining key-value pairs from a manifest file... obtaining a list of vector embeddings from a vector database... based on a querying of the vector database" as generic computer implementation and insignificant extra-solution data gathering. See MPEP 2106.05(f), (g), (d). Thus, these claims are not patent eligible.
Claim 13 further defines the "documents of domain knowledge" recited in the extra-solution data-gathering step of claim 1 and does nothing more than add further insignificant extra-solution activity. See MPEP 2106.05(g), (d). Thus, this claim is not patent eligible.
Claim 15 recites "generating a build version of the software application based on the metadata file" and the additional element "deploying the build version of the software application to an application lifecycle management service", which adds only 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, 13, 15-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), in view of Shukla (US 8,170,901 B2), in view of Dengler (US 2007/0130205 A1), and further in view of Chandel (US 2025/0068665 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 describing a desired task) created via a software development platform (RPA developer platform), the configuration comprising a plurality of artifacts (documents, files, pseudocode).
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 (an understanding of graphical elements and text) for an artifact based on metadata of the artifact (the graphical elements and text 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 and the list of vector embeddings; (Para [0031], "a diagram representing a design of a screen may be used to automatically generate an associated application... 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) 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 reliance on a list of vector embeddings is supplied by Chandel below.
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 file describing the page/process) 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/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 defining an artifact type, input parameters, and output parameters of the artifact;
obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge of mobile applications, based on a querying of the vector database using the analysis data;
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 and the list of vector embeddings;
wherein the metadata file comprises a specification of one or more user interface controls, 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 combined into tasks) 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 using generative AI/ML models to determine sequences of user interactions, extract common processes, and generate RPA robots (Singh, Summary).
Grigore and Singh did not specifically teach
wherein each artifact in the plurality of artifacts has a manifest file defining an artifact type, input parameters, and output parameters of the artifact.
However, Shukla teaches
wherein each artifact in the plurality of artifacts has a manifest file defining an artifact type, input parameters, and output parameters of the artifact (Col. 5 ln. 1-30; Col. 7 ln. 55-67, "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 and its input and output parameters (declaration of "in/out/ref parameters").
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 activity metadata defining the activity type and in/out parameters for each artifact, in order to provide an "extensible framework for building a componentized workflow model" that lets any developer author and compose components without modifying the engine (Shukla, Abstract; Col. 3 ln. 5-25), and to enable downstream tools to programmatically consume and compose artifacts based on their declared type and parameter contracts.
Grigore, Singh, and Shukla did not specifically teach
wherein the metadata file comprises a specification of one or more user interface controls, 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 comprising a specification of one or more user interface controls (basic and custom UI controls with their properties and layout).
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) renders the page (UI form) on a computing device by parsing the metadata file and instantiating the specified UI controls.
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 manually written page program code by replacing the prior hard-coding approach with a metadata file that a rendering engine processes to display the UI controls, so the page is produced from the metadata file rather than from manually written page 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 with Dengler’s metadata-driven UI framework so the metadata file specifies UI controls rendered by the software development platform without manually written page code, to obtain the benefit that "once created, the metadata is processed by a rendering engine to display the UI controls" and to avoid the "cumbersome" hard coding of Dengler (Para [0002], [0007]), consistent with Grigore’s no-code development goal (Para [0034]).
Grigore, Singh, Shukla, and Dengler did not specifically teach
obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge of mobile applications, based on a querying of the vector database using the analysis data; and generating the page generation prompt using the list of vector embeddings.
However, Chandel teaches
obtaining a list of vector embeddings from a vector database of vector embeddings corresponding to documents of domain knowledge, based on a querying of the vector database using the analysis data; (Para [0016], "A code segment in the codebase segment table is indexed by an embedding that represents the code segment and its associated metadata. An embedding of the query and context is used as a search index to find closely-similar embeddings from the codebase segment table. The top-k closest embeddings to the embedding of the query and context point to the code segments and metadata from the codebase segment table to include as examples in the prompt to the large language model.") Examiner Comments: Chandel teaches obtaining a list of vector embeddings (the top-k closest embeddings) from a vector database (codebase segment table indexed by embeddings) of vector embeddings corresponding to documents of domain knowledge (code segments and associated metadata) based on a querying of the vector database using a machine-encoded query (an embedding of the query and context), which in the combination is the analysis data.
(continued) querying of the vector database using the analysis data (Para [0025], "The encoder 204 transforms the query and context 214 into a search index embedding 220. The search engine 206 utilizes the search index embedding 220 to find the top-k closely-similar embeddings using the embedding tree index 224 of the codebase segment table 208. The metadata and code segments 226 associated with the top-k closely-similar embeddings are extracted and used as the examples 222A-222K.") Examiner Comments: Chandel teaches that the query into the vector database is a machine-generated search index embedding of the query and context (not necessarily a human-typed question), rebutting the contention that a query must be a human question, so that in the combination the analysis data serves as the query used to retrieve the list of vector embeddings.
generating a page generation prompt ... using the metadata of the artifact and the list of vector embeddings; (Para [0026], "The prompt generator 210 uses the examples 222A-222K, the user query, and the context, and the examples to form a prompt 216 that is transmitted to the large language model 212.") Examiner Comments: Chandel teaches generating the prompt for the large language model using the retrieved list of vector embeddings (the examples corresponding to the top-k embeddings) together with the query/context, thereby teaching constructing the generation prompt from the retrieved list of vector embeddings.
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 incorporate Chandel’s retrieval of a list of vector embeddings from a vector database using a machine-encoded query, and Chandel’s construction of the large-language-model prompt from the retrieved embeddings, so that Grigore’s analysis data serves as the query for retrieving mobile-application domain-knowledge embeddings that augment the page generation prompt. One of ordinary skill would have been motivated to make this combination because Chandel teaches that augmenting the prompt with retrieved, closely-similar examples "allows the large language model, not having seen the code segments... during training, to make more accurate inferences" and to "predict a response that includes code elements from the codebase, such as method names, application programming interfaces (APIs), objects, variable names" (Chandel, Para [0017]-[0018]).
Regarding Claim 2, Grigore, Singh, Shukla, Dengler and Chandel 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) satisfies a criterion (type is invoice) based on metadata, and performing the downstream generation based on that determination.
Regarding Claim 3, Grigore, Singh, Shukla, Dengler and Chandel 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 metadata and determining that the type is included in a list of recognized types suitable for automation.
Regarding Claim 4, Grigore, Singh, Shukla, Dengler and Chandel 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 including a decision (condition activity), a form (UI automation activity), and a trigger (event/driver 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, Dengler and Chandel 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, Dengler and Chandel 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 serving as input/output parameters used to create the workflow).
Regarding Claim 10, Grigore, Singh, Shukla, Dengler and Chandel 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).
Regarding Claim 13, Grigore, Singh, Shukla, Dengler and Chandel teach the computer-implemented method of Claim 1. Chandel 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 [0037]; Para [0018], "The codebase contains source code files in addition to script files (i.e., markdown files) and documentation files... the model to predict a response that includes code elements from the codebase, such as method names, application programming interfaces (APIs), objects, variable names") Examiner Comments: Chandel teaches that the documents of domain knowledge comprise at least one of the recited alternatives, because the codebase documents include documentation files and source code files that read on "reference documentation for application programming interfaces" and "sample code" (the claim requiring only one of the listed alternatives).
The motivation to combine Chandel with Grigore, Singh, Shukla, and Dengler is the same as set forth in the rejection of Claim 1 above.
Regarding Claim 15, Grigore, Singh, Shukla, Dengler and Chandel 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.
Regarding Claim 16, Claim 16 is the system claim corresponding to Claim 1 and is rejected for the same reasons as Claim 1 by the same combination of references.
Regarding Claim 17, Claim 17 is the system claim corresponding to Claim 2 and is rejected for the same reasons as Claim 2 by the same combination of references.
Regarding Claim 18, Claim 18 is the system claim corresponding to Claims 3 and 4 and is rejected for the same reasons as Claims 3 and 4 by the same combination of references.
Regarding Claim 20, Claim 20 is the non-transitory machine-readable storage medium claim corresponding to Claim 1 and is rejected for the same reasons as Claim 1 by the same combination of references.
Response to Arguments
Applicant’s arguments with respect to claims 1-11, 13, 15-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.
Applicant argues "Querying a vector database of vector embeddings cannot practically be performed in the human mind... A human mind does not compute dot products and vector magnitudes across long lists of numbers representing high-dimensional embeddings, nor does a human mind maintain and search an indexed vector database."
Examiner respectfully disagrees. The abstract idea identified in the rejection is the mental process of generating analysis data from artifact metadata and composing a page generation prompt, not the vector-database query itself. The vector-database querying step is treated as an additional element, and it is addressed as insignificant extra-solution activity (data gathering) at Step 2A Prong Two and as well-understood, routine, and conventional at Step 2B, not as part of the abstract idea. See MPEP 2106.05(g), (d). That a particular additional element (the vector query) is computer-implemented and cannot itself be performed mentally does not render the claim as a whole patent eligible, because a claim that recites a mental process together with generic computer implementation and conventional data-gathering remains directed to the abstract idea. See MPEP 2106.05(f).The conventionality of retrieving embeddings from a vector database to augment a machine-learning prompt is evidenced by Chandel (Para [0016], [0025]-[0026]).
Applicant further argues "the amended claims recite the specific mechanism by which that improvement is achieved... obtaining from the large language model a metadata file specifying user interface controls, and providing that metadata file to the software development platform, which is configured to render the page... without program code for the page being manually written," and that this is a practical application under Core Wireless and Finjan.
Examiner respectfully disagrees. The claims do not recite a specific improvement to the functioning of a computer or to any technology; they recite the use of a generic large language model and a generic software development platform as tools to carry out the abstract idea, with the rendering of the page being the output/display of the result. See MPEP 2106.05(f), (g). Core Wireless is distinguishable because those claims recited a particular, specified manner of displaying a limited set of information through a specified application-summary interface with claimed behavior, whereas the present claims recite no particular manner of display or interface behavior, only that the platform "is configured to render the page." Finjan is distinguishable because the claimed "security profile" there enabled a specific, previously-unattainable behavior (identifying suspicious code by linking to a downloadable), whereas here a metadata file specifying UI controls is a conventional data structure, as evidenced by Dengler (Para [0007], [0033]). The recitation that the page is rendered "without program code for the page being manually written" states an intended result and a field of use and does not impose a meaningful limit. See MPEP 2106.05(h). The rejection is maintained.
Applicant further argues, under Berkheimer, that "the ordered combination... is not well-understood, routine, or conventional" and that the Office Action has not supplied evidence.
Examiner respectfully disagrees. As set forth in the Step 2B analysis above, the additional elements are supported by documentary evidence of conventionality consistent with the Berkheimer Memorandum: the vector-database retrieval augmenting a machine-learning prompt is evidenced by Chandel (Para [0016]-[0018], [0025]-[0026]), and the metadata-driven rendering of UI controls without manual coding is evidenced by Dengler (Para [0002], [0007], [0033]). The ordered combination recites these conventional additional elements applied to the abstract idea in their ordinary sequence and produces no unconventional technological result.
Conclusion
THIS ACTION IS MADE FINAL. 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 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 /Ted T. Vo/Primary Examiner, Art Unit 2191
Prosecution Insights