DETAILED ACTION
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 4/15/26 has been entered, in which Applicant amended claims 1, 2, 17, 19, and 20 and cancelled claims 3, 4, and 9. Claims 1, 2, 5-8, and 10-20 are pending in this application and have been rejected as indicated below.
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 .
Information Disclosure Statement
No Information Disclosure Statement has yet been filed in regard to this Application. As such, Examiner has not yet considered any Information Disclosure Statements.
Response to Amendments
Applicant’s arguments are acknowledged.
The 35 USC 101 rejection of claims 1, 2, 5-8, and 10-20 in regard to abstract ideas has been maintained in light of Applicant’s explanations.
The 35 USC § 103 rejections of claims 1, 2, 5-8, and 10-20 are maintained in light of Applicant’s explanations.
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, 2, 5-8, and 10-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. Here, under considerations of the broadest reasonable interpretation of the claimed invention, Examiner finds that the Applicant invented a method and system for a process visibility application that provides users end-to-end operational visibility into an organization’s business processes. Examiner formulates an abstract idea analysis, following the framework described in the MPEP, as follows:
Step 1: The claims are directed to a statutory category, namely a "method" (claims 1, 2, 5-8, and 10-18) and "system" (claims 19 and 20).
Step 2A - Prong 1: The claims are found to recite limitations that set forth the abstract idea(s), namely, regarding claim 1:
receiving a natural language request … by the process visibility application;
the insights including one or more process key performance indicators (KPIs );
retrieving a definition of a visibility scenario configured for the business process, the visibility scenario comprising a model of the business process, a plurality of visibility-related attributes, and specifications of the one or more process KPIs;
retrieving metadata representative of the visibility scenario, the metadata being formatted in a format interpretable by a data query service of the process visibility application;
providing the natural language request, the definition of the visibility scenario, and the metadata representative of the visibility scenario as input to a first large language model (LLM) thereby causing the first LLM to output business process domain knowledge relevant to the natural language request;
…
using the natural language request, the definition of the visibility scenario, the metadata representative of the visibility scenario, information regarding a data query service including protocol version and supported functions and the business process domain knowledge to build a prompt for a second LLM;;
providing the prompt as input to the second LLM, wherein the response is a query to be executed by the data query service
Independent claims 19 and 20 recite substantially similar claim language.
Dependent claims 1, 2, 5-8, and 10-18 recite the same or similar abstract idea(s) as independent claims 1, 19, and 20 with merely a further narrowing of the abstract idea(s) to particular data characterization and/or additional data analyses performed as part of the abstract idea.
The limitations in claims 1, 2, 5-8, and 10-20 above falling well-within the groupings of subject matter identified by the courts as being abstract concepts, specifically the claims are found to correspond to the category of:
"Certain methods of organizing human activity- fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)" as the limitations identified above are directed to a process visibility application that provides users end-to-end operational visibility into an organization’s business processes and thus is a method of organizing human activity including at least commercial or business interactions or relations and/or a management of user personal behavior.
Step 2A - Prong 2: Claims 1, 2, 5-8, and 10-20 are found to clearly be directed to the abstract idea identified above because the claims, as a whole, fail to integrate the claimed judicial exception into a practical application, specifically the claims recite the additional elements of:
" a visibility dashboard … the visibility dashboard being a graphical user interface (UI) that presents insights pertaining to one or more instances of a business process… updating the visibility dashboard in accordance with the response " (claims 1, 19, and 20) "and presenting the new process KPI in the visibility dashboard using the data,” (claims 1, 19, and 20), “wherein the request to provide the natural language summary is received from a user of the visibility dashboard via a chatbot interface, " (claim 17), however the aforementioned elements directed to the receiving of user input/selection of data to view via a dashboard and displaying corresponding data via the dashboard merely amount to generic GUI elements of a general purpose computer used to "apply" the abstract idea (MPEP 2106.05(f)) and/or is merely an attempt at limiting the abstract idea of a process visibility application that provides users end-to-end operational visibility into an organization’s business processes to a particular field of use/technological environment of a GUI dashboard (MPEP 2106.05(h)) and therefore the GUI dashboard input and display of data fails to integrate the abstract idea into a practical application;
" A method performed by one or more computer systems implementing a process visibility application, the method comprising / A non-transitory computer readable storage medium having stored thereon instructions executable by one or more computer systems implementing a process visibility application, the instructions causing the one or more computer systems to: / A computer system comprising: one or more processors; and a computer readable storage medium having stored thereon program code that, when executed by the one or more processors, cause the one or more processors to:" (claims 1, 19, and 20), “thereby causing the first LLM to output business process domain knowledge relevant to the natural language request… thereby causing the second LLM to output a response to the natural language request,” (claims 1, 19, and 20), “wherein updating the visibility dashboard in accordance with the response comprises: providing the query as input to the data query service, thereby causing the data query service to output data for a new process KPI,” (claims 1, 19, and 20), “wherein the embeddings are computed using the second LLM,” (claim 8), “wherein the first LLM is an organization-specific LLM that has been trained on business data owned by an organization implementing the business process, and wherein the second LLM is a generic LLM that has been trained on publicly available data,” (claim 15), however the aforementioned elements merely amount to generic components of a general purpose computer used to "apply" the abstract idea (MPEP 2106.0S(f)) and thus fails to integrate the recited abstract idea into a practical application, furthermore the high-level recitation of receiving data from a generic "computer system" is at most an attempt to limit the abstract to a particular field of use (MPEP 2106.0S(h), e.g.: "For instance, a data gathering step that is limited to a particular data source (such as the Internet) or a particular type of data (such as power grid data or XML tags) could be considered to be both insignificant extra-solution activity and a field of use limitation. See, e.g., Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (limiting use of abstract idea to the Internet); Electric Power, 830 F.3d at 1354, 119 USPQ2d at 1742 (limiting application of abstract idea to power grid data); Intellectual Ventures I LLC v. Erie lndem. Co., 850 F.3d 1315, 1328-29, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017) (limiting use of abstract idea to use with XML tags).") and/or merely insignificant extra-solution activity (MPE 2106.05(g)) and thus further fails to integrate the abstract idea into a practical application;
Step 2B: Claims 1, 2, 5-8, and 10-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements as described above with respect to Step 2A Prong 2 merely amount to a general purpose computer that attempts to apply the abstract idea in a technological environment (MPEP 2106.0S(f)), including merely limiting the abstract idea to a particular field of use of analysis using a "computer system" via a GUI "dashboard", as explained above, and/or performs insignificant extra-solution activity, e.g. data gathering or output, (MPEP 2106.0S(g)), as identified above, which is further found under step 2B to be merely well-understood, routine, and conventional activities as evidenced by MPEP 2106.0S(d)(II) (describing conventional activities that include transmitting and receiving data over a network, electronic recordkeeping, storing and retrieving information from memory, electronically scanning or extracting data from a physical document, and a web browser's back and forward button functionality). Therefore, similarly the combination and arrangement of the above identified additional elements when analyzed under Step 2B also fails to necessitate a conclusion that the claims amount to significantly more than the abstract idea directed to a process visibility application that provides users end-to-end operational visibility into an organization’s business processes.
Claims 1, 2, 5-8, and 10-20 are accordingly rejected under 35 USC§ 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea(s)) without significantly more.
Note: The analysis above applies to all statutory categories of invention. As such, the presentment of any claim otherwise styled as a machine or manufacture, for example, would be subject to the same analysis
For further authority and guidance, see:
MPEP § 2106
https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility
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 of this title, 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, 2, 5-8, 10-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2024/0202221 to Siebel et al. (hereafter referred to as Siebel) in view of U.S. Patent Application Publication Number 2025/0006201 to Adlersberg et al. (hereafter referred to as Adlersberg).
As per claim 1, Siebel teaches:
A method performed by one or more computer systems implementing a process visibility application, the method comprising (Paragraph Number [0170] teaches receive an enterprise search query, wherein the enterprise search query comprises a natural language input. Based on the enterprise search query and one or more retriever models, a plurality of data records associated with at least a portion of enterprise data of an enterprise information environment are retrieved. A respective relevance score is determined by the one or more retriever models, for each of the retrieved data records. At least one of the retrieved data records are selected based on the respective relevance scores. At least a portion of at least one of the retrieved data records are selected based on one or more enterprise access control protocols. Paragraph Number [0171] teaches the systems, methods, modules, layers, engines, datastores, and/or databases described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an Application Program Interface (API))).
receiving a natural language request directed to a visibility dashboard generated by the process visibility application (Paragraph Number [0029] teaches FIG. 1 depicts a diagram of an example enterprise generative artificial intelligence system architecture and environment 100 according to some embodiments. In the example of FIG. 1, the system architecture and environment 100 includes an enterprise generative artificial intelligence system 102, enterprise systems 104, external systems 106, domain models 108, a vector datastore 126, an embeddings models datastore 124, and an enterprise access control layer 115. In some embodiments, the query comprises a natural language query received through a graphical user interface. Paragraph Number [0038] teaches FIG. 2A depicts an example enterprise search graphical user interface 200 and underlying architecture 202-208 according to some embodiments. Generally, the graphical user interfaces depicted in FIG. 2A and FIG. 2B include a human computer interface for receiving natural language queries and presenting relevant information from the enterprise information environment in response to the queries. Although not shown in FIG. 2A or 2B, the relevant information can also include visualizations, predictive analysis, and/or other information obtained or generated by enterprise generative artificial intelligence systems).
the visibility dashboard being a graphical user interface (UI) that presents insights pertaining to one or more instances of a business process (Paragraph Number [0029] teaches FIG. 1 depicts a diagram of an example enterprise generative artificial intelligence system architecture and environment 100 according to some embodiments. In the example of FIG. 1, the system architecture and environment 100 includes an enterprise generative artificial intelligence system 102, enterprise systems 104, external systems 106, domain models 108, a vector datastore 126, an embeddings models datastore 124, and an enterprise access control layer 115. In some embodiments, the query comprises a natural language query received through a graphical user interface. In some embodiments, the one or more enterprise data sets include any of documents, document segments, and insights generated by the one or more artificial intelligence applications. In some embodiments, each of the relevance scores is associated with a respective portion of the one or more enterprise data sets, and wherein each of the relevance scores are determined relative to the other respective portions of the one or more enterprise data sets. Paragraph Number [0038] teaches FIG. 2A depicts an example enterprise search graphical user interface 200 and underlying architecture 202-208 according to some embodiments. Generally, the graphical user interfaces depicted in FIG. 2A and FIG. 2B include a human computer interface for receiving natural language queries and presenting relevant information from the enterprise information environment in response to the queries. Although not shown in FIG. 2A or 2B, the relevant information can also include visualizations, predictive analysis, and/or other information obtained or generated by enterprise generative artificial intelligence systems).
the insights including one or more process key performance indicators (KPIs ) (Paragraph Number [0054] teaches supply chain data may be obtained from a first artificial intelligence application (e.g., an inventory management and optimization or supply chain application) and the impact information may be obtained based at least in part on the supply chain data and information from another artificial intelligence application, such as an artificial intelligence application used to monitor and predict maintenance needs for a fleet of vehicles. In the example, the supply chain data may indicate issues with the supply, another artificial intelligence application may be used to identify vehicles needing maintenance, and the impact information may represent an insight into how the vehicles needing maintenance are being impacted by issues in the supply chain (e.g., based on the supply chain data). Example information from different data domains or application objects may include key performance metrics (KPIs) (e.g., from left to right—a fleet readiness score, unscheduled maintenance avoided (hours) over a time period, a number of flights gained (e.g., due to avoided maintenance), operation time at risk, and/or the like), aircraft status risk score information, component risk score and ranking (e.g., by risk score) information, information associated with artificial intelligence alerts, flight capability information (e.g., by geographic region), case information, supply chain data, and impact information regarding aircraft being impacted by effects within the supply chain).
retrieving a definition of a visibility scenario configured for the business process, the visibility scenario comprising a model of the business process, a plurality of visibility-related attributes, and specifications of the one or more process KPIs (Paragraph Number [0063] teaches the type system provides data accessibility, compatibility and operability with disparate systems and data. Specifically, the type system solves data operability across diversity of programming languages, inconsistent data structures, and incompatible software application programming interfaces. Type system provides data abstraction that defines extensible type models that enables new properties, relationships and functions to be added dynamically without requiring costly development cycles. The type system can be used as a domain-specific language (DSL) within a platform used by developers, applications, or UIs to access data. The type system provides interact ability with data to perform processing, predictions, or analytics based on one or more type or function definitions within the type system. Paragraph Number [0064] teaches type definitions can be a canonical type declared in metadata using syntax similar to that used by types persisted in the relational or NoSQL data store. A canonical model in the type system is a model that is application agnostic (i.e., application independent), enabling all applications to communicate with each other in a common format. Unlike a standard type, canonical types are comprised of two parts, the canonical type definition and one or more transformation types. The canonical type definition defines the interface used for integration and the transformation type is responsible for transforming the canonical type to a corresponding type. Using the transformation types, the integration layer may transform a canonical type to the appropriate type (See also Paragraph Number [0054] in regard to attributes and specifications including KPIs)).
retrieving metadata representative of the visibility scenario (Paragraph Number [0065] teaches types can define meta models and may be virtual building blocks to create new types, extend existing types, or write business logic on a type to dictate how data in the type will function when called. Logic in a platform can be expressed in JavaScript which may allow APIs to be used to program against any type in the system. The type system generates composite types that include metadata from multiple layers. Composite types are used to construct or generate object instances for specific entities, functions etc. A composite type can include, for example, an entity definition, an application logic function, and one or UI view definitions. The composite type can be applied to data stored within one or more databases to create a specific instance of that type which can be used for processing by business logic).
the metadata being formatted in a format interpretable by a data query service of the process visibility application (Paragraph Number [0036] teaches the enterprise generative artificial intelligence system 102 can crawl, index, and/or map a corpus of data records (e.g., data records of one or more enterprise systems or environments) using contextual information (e.g., contextual metadata) along with data record embeddings to provide access control (e.g., role-based access), improved data record identification and retrieval, and map relationships between data records. In one example, contextual information may prevent some users from accessing (e.g., viewing, retrieving) certain data records, and improve similarity evaluations used in retrieval operation (e.g., of a generative artificial intelligence process). Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. (See also Example in Paragraph Numbers [0195]-[0196])).
providing the natural language request, the definition of the visibility scenario, and the metadata representative of the visibility scenario as input to a first large language model (LLM) (Paragraph Number [0167] teaches systems, methods, and non-transitory computer-readable media configured to process a query input. One or more artificial intelligence applications and a plurality of associated data models from a plurality of data domains are identified based on the query input. The query input is analyzed based on the data models from the plurality of data domains. A relevance score is determined by a machine learning model based on the analysis of the query input. One or more query sets for execution on at least one of the one or more artificial intelligence applications are generated based on the relevance score. A response output is composed based on results of the executed one or more generated query sets. (See Paragraph Number [0029] in regard to a natural language request; Paragraph Numbers [0063]-[0064] in regard to definitions of scenarios configured for a business process; Paragraph Number [0065] in regard to metadata representative of the scenario)).
thereby causing the first LLM to output business process domain knowledge relevant to the natural language request (Paragraph Number [0076] teaches the enterprise comprehension module 412 can function to process inputs to determine output results (or, “answers”), determine rationales for answers, and determine whether the enterprise comprehension module 412 needs more information to determine answers. The enterprise comprehension module 412 may output information (e.g., answers or additional queries) in a natural language format. Features of one or more models of the enterprise comprehension module 412 define conditions or functions that determine if more information is needed to satisfy a query or if there is enough information to satisfy the query and an accurate and reliable answer can be provided).
using the natural language request, the definition of the visibility scenario, the metadata representative of the visibility scenario, information regarding a data query service including protocol version and supported functions and the business process domain knowledge to build a prompt for a second LLM; (Paragraph Number [0079] teaches the enterprise comprehension module 412 processes inputs to determine one or more results (i.e., output, response, or answer), determine rationales for results, and determine whether the enterprise comprehension module 412 needs more information to determine results. Enterprise comprehension module 412 may output information (e.g., results, new prompts, or additional queries) in a natural language format. In some implementations, features of one or more models of the enterprise comprehension module 412 can define conditions or functions that determine if more information is needed to satisfy the initial input or if there is enough information to satisfy the initial input. In some implementations, the enterprise comprehension module 412 comprises one or more large language models. Paragraph Number [0166] teaches embed respective objects in the plurality of the different data domains of the enterprise information environment. The respective objects can enable the one or more enterprise access control protocols. In some embodiments, the enterprise access control protocols include user role-based enterprise access control protocols. In some embodiments, the enterprise access control protocols cause a first user with a first user role to be presented with a different natural language output relative to a second user with a second user role. In some embodiments, the enterprise access control protocols enable and/or cause preventing the presentation of at least a portion of the natural language output. (See Paragraph Number [0029] in regard to a natural language request; Paragraph Numbers [0063]-[0064] in regard to definitions of scenarios configured for a business process; Paragraph Number [0065] in regard to metadata representative of the scenario)).
providing the prompt as input to the second LLM, thereby causing the second LLM to output a response to the natural language request (Paragraph Number [0132] teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. The retrieval module 804 can process that new query and retrieves additional information. The system then generates a new prompt based on the additional information and the context. The enterprise comprehension module 806 can process the new prompt and again determines if it needs additional information. If it needs additional information (e.g., as shown in step 807), the enterprise generative artificial intelligence system can repeat (e.g., iterate) this process until the enterprise comprehension module 806 can satisfy criteria based on the initial input (e.g., query), at which point the enterprise comprehension module 806 can generate (step 813) the output result 814 (e.g., “answer” or “I don't know”). For example, generating the answer “I don't know” if no relevant passages have been generated (e.g., by applying a rule) and/or not enough relevant passages have been generated, the enterprise comprehension module 806 can prevent hallucination and increase the performance on the “I don't know” questions while saving a call to the models (e.g., large language models)).
wherein the response is a query to be executed by the data query service (Paragraph Number [0077] teaches the enterprise comprehension module 412 comprises one or more large language models. The one or more large language models may be configured to generate and process context, as well as the other inputs and outputs described herein. The enterprise comprehension module 412 may also include one or more large language models that pre-process queries. For example, the enterprise comprehension module 412 can parse a complex input into multiple segments, and generate new corresponding queries, which the enterprise comprehension module 412 can route to various agents for processing. The enterprise comprehension module 412 may also include one or more large language models that processes outputs from other models and modules. The enterprise comprehension module 412 may also include another large language model for processing results into a format more consistent with an answer. The enterprise comprehension module 412 can also notify users and systems if it cannot find an answer (e.g., as opposed to presenting an answer that is likely faulty or biased. (See also Paragraph Number [0054] in regard to use of KPIs)).
providing the query as input to the data query service, thereby causing the data query service to output data for a new process KPI (Paragraph Number [0076] teaches the enterprise comprehension module 412 can function to process inputs to determine output results (or, “answers”), determine rationales for answers, and determine whether the enterprise comprehension module 412 needs more information to determine answers. The enterprise comprehension module 412 may output information (e.g., answers or additional queries) in a natural language format. Features of one or more models of the enterprise comprehension module 412 define conditions or functions that determine if more information is needed to satisfy a query or if there is enough information to satisfy the query and an accurate and reliable answer can be provided. Paragraph Number [0077] teaches the enterprise comprehension module 412 comprises one or more large language models. The one or more large language models may be configured to generate and process context, as well as the other inputs and outputs described herein. The enterprise comprehension module 412 may also include one or more large language models that pre-process queries. For example, the enterprise comprehension module 412 can parse a complex input into multiple segments, and generate new corresponding queries, which the enterprise comprehension module 412 can route to various agents for processing. The enterprise comprehension module 412 may also include one or more large language models that processes outputs from other models and modules. The enterprise comprehension module 412 may also include another large language model for processing results into a format more consistent with an answer. The enterprise comprehension module 412 can also notify users and systems if it cannot find an answer (e.g., as opposed to presenting an answer that is likely faulty or biased. (See also Paragraph Number [0054] in regard to use of KPIs)).
and presenting the new process KPI in the visibility dashboard using the data (Paragraph Number [0100] teaches the presentation module 430 can function to generate graphical user interface components (e.g., server-side graphical user interface components) that can be rendered as complete graphical user interfaces on other systems. For example, the presentation module 460 can function to present an interactive graphical user interface for display and receiving information. For example, the presentation module 430 can generate graphical user interface enterprise search query input and response interfaces (e.g., as shown in FIG. 2A, FIG. 2B, FIG. 7A, and FIG. 7B)).
Siebel teaches a process visibility application that provides users end-to-end operational visibility into an organization’s business processes but does not explicitly teach updating a graphical user interface with updated information based on outputs from an LLM which is taught by the following citations from Adlersberg:
updating the visibility dashboard in accordance with the response comprising (Paragraph Number [0013] teaches other suitable types of representations may be generated and may be dynamically updated or modified by the system based on the LLM engine outputs; to thereby provide to the manager a birds-eye view or an “at a glance” view of the important/relevant insights as well as their Trend of Change Over Time. Paragraph Number [0014] teaches the manager may define or configure in advance, that the system would automatically send or deliver to its electronic device (computer, smartphone, tablet), an alert/notification/update, upon derivation or deduction of a new insight from a fresh batch of LLM-based analysis of meeting transcripts, or upon derivation or deduction of a change in a Trend of an already-derived insights or topic).
Both Siebel and Adlersberg are directed to Large Language Modelling. Siebel discloses a process visibility application that provides users end-to-end operational visibility into an organization’s business processes. Adlersberg improves upon Siebel by disclosing updating a graphical user interface with updated information based on outputs from an LLM. One of ordinary skill in the art would be motivated to further include updating a graphical user interface with updated information based on outputs from an LLM, to efficiently convey through a display the updated information produced by the output of the LLM.
Accordingly, 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 system and method of a process visibility application that provides users end-to-end operational visibility into an organization’s business processes in Siebel to further utilize updating a graphical user interface with updated information based on outputs from an LLM as disclosed in Adlersberg, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 2 the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
In addition, Sibel teaches:
wherein the natural language request is a request to create a new process KPI in the visibility dashboard. (Paragraph Number [0077] teaches the enterprise comprehension module 412 comprises one or more large language models. The one or more large language models may be configured to generate and process context, as well as the other inputs and outputs described herein. The enterprise comprehension module 412 may also include one or more large language models that pre-process queries. For example, the enterprise comprehension module 412 can parse a complex input into multiple segments, and generate new corresponding queries, which the enterprise comprehension module 412 can route to various agents for processing. The enterprise comprehension module 412 may also include one or more large language models that processes outputs from other models and modules. The enterprise comprehension module 412 may also include another large language model for processing results into a format more consistent with an answer. The enterprise comprehension module 412 can also notify users and systems if it cannot find an answer (e.g., as opposed to presenting an answer that is likely faulty or biased. (See also Paragraph Number [0054] in regard to use of KPIs)).
As per claim 5, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1 and 2.
In addition, Siebel teaches:
retrieving one or more previous requests to create new process KPIs previously submitted by the user with respect to the visibility dashboard (Paragraph Number [0131] teaches if the enterprise comprehension module 806 determines that it needs additional information to satisfy the initial input, it can generate context-specific data (or, simply, “context”) that will inform future iterations of the process and help the system more efficiently and accurately satisfy the initial input. The context is based on the rationale used by the enterprise comprehension module 806 when it is processing queries (or other inputs). For example, the enterprise comprehension module 806 may receive segments of information retrieved by the retrieval module 804. The segments may be passages of data record(s), for example, and the segments may be associated with embeddings from an embeddings datastore 808 that facilitates processing by the enterprise comprehension module 806. A query and rational generator 812 of the enterprise comprehension module 806 can process the information and generate a rationale for why it produced the result that it did. That rationale can be stored by the enterprise generative artificial intelligence system in an historical rational datastore 810 and provide the foundation for the context subsequent iterations).
computing embeddings of the request to create the new process KPI and the one or more previous requests (Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. Paragraph Number [0062] teaches embedding of objects in data domains of the enterprise information system enable rapid identification and complex processing with relevance scoring as well as additional functionality to enforce access, privacy, and security protocols. In some implementations, the orchestrator module can employ a variety of embedding methodologies and techniques understood by one of ordinary skill in the art).
determining, based on the embeddings, a subset of the one or more previous requests that are similar to the request to create the new process KPI (Paragraph Number [0132] teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. The retrieval module 804 can process that new query and retrieves additional information. The system then generates a new prompt based on the additional information and the context. The enterprise comprehension module 806 can process the new prompt and again determines if it needs additional information. If it needs additional information (e.g., as shown in step 807), the enterprise generative artificial intelligence system can repeat (e.g., iterate) this process until the enterprise comprehension module 806 can satisfy criteria based on the initial input (e.g., query), at which point the enterprise comprehension module 806 can generate (step 813) the output result 814 (e.g., “answer” or “I don't know”). For example, generating the answer “I don't know” if no relevant passages have been generated (e.g., by applying a rule) and/or not enough relevant passages have been generated, the enterprise comprehension module 806 can prevent hallucination and increase the performance on the “I don't know” questions while saving a call to the models (e.g., large language models)).
retrieving queries output by the second LLM in response to the subset of the one or more previous requests (Paragraph Number [0076] teaches the enterprise comprehension module 412 can function to process inputs to determine output results (or, “answers”), determine rationales for answers, and determine whether the enterprise comprehension module 412 needs more information to determine answers. The enterprise comprehension module 412 may output information (e.g., answers or additional queries) in a natural language format. Features of one or more models of the enterprise comprehension module 412 define conditions or functions that determine if more information is needed to satisfy a query or if there is enough information to satisfy the query and an accurate and reliable answer can be provided).
As per claim 6, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1, 2, and 5.
In addition, Siebel teaches:
wherein the queries and the subset of the one or more previous requests are also provided as inputs to the first LLM (Paragraph Number [0132] teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. The retrieval module 804 can process that new query and retrieves additional information. The system then generates a new prompt based on the additional information and the context. The enterprise comprehension module 806 can process the new prompt and again determines if it needs additional information. If it needs additional information (e.g., as shown in step 807), the enterprise generative artificial intelligence system can repeat (e.g., iterate) this process until the enterprise comprehension module 806 can satisfy criteria based on the initial input (e.g., query), at which point the enterprise comprehension module 806 can generate (step 813) the output result 814 (e.g., “answer” or “I don't know”). For example, generating the answer “I don't know” if no relevant passages have been generated (e.g., by applying a rule) and/or not enough relevant passages have been generated, the enterprise comprehension module 806 can prevent hallucination and increase the performance on the “I don't know” questions while saving a call to the models (e.g., large language models)).
As per claim 7, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1, 2, and 5.
In addition, Siebel teaches:
wherein the queries and the subset of the one or more previous requests are also used to build the prompt for the second LLM (Paragraph Number [0132] teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. The retrieval module 804 can process that new query and retrieves additional information. The system then generates a new prompt based on the additional information and the context. The enterprise comprehension module 806 can process the new prompt and again determines if it needs additional information. If it needs additional information (e.g., as shown in step 807), the enterprise generative artificial intelligence system can repeat (e.g., iterate) this process until the enterprise comprehension module 806 can satisfy criteria based on the initial input (e.g., query), at which point the enterprise comprehension module 806 can generate (step 813) the output result 814 (e.g., “answer” or “I don't know”). For example, generating the answer “I don't know” if no relevant passages have been generated (e.g., by applying a rule) and/or not enough relevant passages have been generated, the enterprise comprehension module 806 can prevent hallucination and increase the performance on the “I don't know” questions while saving a call to the models (e.g., large language models)).
As per claim 8, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1, 2, and 5.
In addition, Siebel teaches:
wherein the embeddings are computed using the second LLM (Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. Paragraph Number [0062] teaches embedding of objects in data domains of the enterprise information system enable rapid identification and complex processing with relevance scoring as well as additional functionality to enforce access, privacy, and security protocols. In some implementations, the orchestrator module can employ a variety of embedding methodologies and techniques understood by one of ordinary skill in the art).
As per claim 10, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
In addition, Siebel teaches:
wherein the natural language request is a request to provide a natural language summary of an insight presented in the visibility dashboard (Paragraph Number [0165] teaches each data model of the plurality of data models corresponds to a different data domain of the plurality of different data domains. In some embodiments, each data model represents respective relationships and attributes of the corresponding different data domain of the plurality of different data domains. In some embodiments, the respective relationships and attributes include any of data types, data formats, and industry-specific information. In some embodiments, the natural language output comprises a summary of at least one of the respective portions of the one or more enterprise data sets associated with a relevance score).
As per claim 11, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1 and 10.
In addition, Siebel teaches:
retrieving visibility data for the one or more instances of the business process, wherein the visibility data was previously computed by the process visibility application based on the visibility scenario and process event data associated with the one or more instances (Paragraph Number [0132] teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. The retrieval module 804 can process that new query and retrieves additional information. The system then generates a new prompt based on the additional information and the context. The enterprise comprehension module 806 can process the new prompt and again determines if it needs additional information. If it needs additional information (e.g., as shown in step 807), the enterprise generative artificial intelligence system can repeat (e.g., iterate) this process until the enterprise comprehension module 806 can satisfy criteria based on the initial input (e.g., query), at which point the enterprise comprehension module 806 can generate (step 813) the output result 814 (e.g., “answer” or “I don't know”). For example, generating the answer “I don't know” if no relevant passages have been generated (e.g., by applying a rule) and/or not enough relevant passages have been generated, the enterprise comprehension module 806 can prevent hallucination and increase the performance on the “I don't know” questions while saving a call to the models (e.g., large language models)).
computing one or more embeddings of the visibility data (Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. Paragraph Number [0062] teaches embedding of objects in data domains of the enterprise information system enable rapid identification and complex processing with relevance scoring as well as additional functionality to enforce access, privacy, and security protocols. In some implementations, the orchestrator module can employ a variety of embedding methodologies and techniques understood by one of ordinary skill in the art).
As per claim 12, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1, 10, and 11.
In addition, Siebel teaches:
wherein the one or more embeddings of the visibility data are also provided as inputs to the first LLM (Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. Paragraph Number [0062] teaches embedding of objects in data domains of the enterprise information system enable rapid identification and complex processing with relevance scoring as well as additional functionality to enforce access, privacy, and security protocols. In some implementations, the orchestrator module can employ a variety of embedding methodologies and techniques understood by one of ordinary skill in the art).
As per claim 13, the combination of Siebel and Adlersberg teaches each of the limitations of claims 1, 10, and 11.
In addition, Siebel teaches:
wherein the one or more embeddings of the visibility data are also used to build the prompt for the second LLM (Paragraph Number [0061] teaches the orchestrator module 404 creates one or more virtual metadata repositories across data stores, abstracts access to disparate data sources, and supports granular data access controls. The orchestrator module 404 can manage a virtual data lake with an enterprise catalogue that connect to a multiple data domains and industry specific domains. The orchestrator module is able to create embeddings for multiple data types across multiple industry verticals and knowledge domains, and even specific enterprise knowledge. Paragraph Number [0062] teaches embedding of objects in data domains of the enterprise information system enable rapid identification and complex processing with relevance scoring as well as additional functionality to enforce access, privacy, and security protocols. In some implementations, the orchestrator module can employ a variety of embedding methodologies and techniques understood by one of ordinary skill in the art).
As per claim 14, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
In addition, Siebel teaches:
wherein the prompt for the second LLM is built using a prompt model that comprises a static portion defined by a human prompt engineer (Paragraph Number [0038] teaches FIG. 2A depicts an example enterprise search graphical user interface 200 and underlying architecture 202-208 according to some embodiments. Generally, the graphical user interfaces depicted in FIG. 2A and FIG. 2B include a human computer interface for receiving natural language queries and presenting relevant information from the enterprise information environment in response to the queries. Although not shown in FIG. 2A or 2B, the relevant information can also include visualizations, predictive analysis, and/or other information obtained or generated by enterprise generative artificial intelligence systems).
and a dynamic portion that incorporates the natural language request, the definition of the visibility scenario, the metadata representative of the visibility scenario, and the business process domain knowledge (Paragraph Number [0079] teaches the enterprise comprehension module 412 processes inputs to determine one or more results (i.e., output, response, or answer), determine rationales for results, and determine whether the enterprise comprehension module 412 needs more information to determine results. Enterprise comprehension module 412 may output information (e.g., results, new prompts, or additional queries) in a natural language format. In some implementations, features of one or more models of the enterprise comprehension module 412 can define conditions or functions that determine if more information is needed to satisfy the initial input or if there is enough information to satisfy the initial input. In some implementations, the enterprise comprehension module 412 comprises one or more large language models. (See Paragraph Number [0029] in regard to a natural language request; Paragraph Numbers [0063]-[0064] in regard to definitions of scenarios configured for a business process; Paragraph Number [0065] in regard to metadata representative of the scenario)).
As per claim 15, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
In addition, Siebel teaches:
wherein the first LLM is an organization-specific LLM that has been trained on business data owned by an organization implementing the business process, and wherein the second LLM is a generic LLM that has been trained on publicly available data (Paragraph Number [0070] teaches the retrieval artificial intelligence models can be trained with the knowledge modeling for interacting with the data sources. Model training can be implemented continuously, asynchronously, with feedback (e.g., re-enforcement learning, etc.), and the like. Multiple retrieval models can be trained on a single set of data for different use cases. The retrieval artificial intelligence models are multimodal for different types of data formats (e.g., text, images, video, and/or the like), data sources (e.g., databases, repositories, unstructured data, and/or the like), functions (e.g., enterprise departments, technology types, and/or the like), access classifications (e.g., permissive, restricted, confidential, and/or the like), and the like. Retrieval artificial intelligence models (or, simply, retrieval models) can enable intelligent identification, access, and comprehension for context specific information management. Paragraph Number [0052] teaches the enterprise generative artificial intelligence system 302 can provide numerous technical advantages relative to the prior art. For example, input queries that are executed by the system 302 can return results that would not have been identified by the initial user supplied input query using traditional search techniques. Additionally, the results themselves may be different than what is stored in the distributed data sets (e.g., having a different format, type, or content) and that public and private data can be selectively searched without unnecessarily exposing private data).
As per claim 17, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
In addition, Siebel teaches:
wherein the request to provide the natural language summary is received from a user of the visibility dashboard via a chatbot interface (Paragraph Number [0097] teaches the model optimization module 428 can train generative artificial intelligence models to develop different types of responses (e.g., best results, ranked results, smart cards, chatbot, new content generation, and/or the like). [0124] In the example of FIG. 7A and FIG. 7B, the interactive query portion 708 in a generative artificial intelligence chat interface which provides a summary of top results with the interactive chat 706. Users can trigger presentation of plan details via interactive graphical icon 716)>
As per claims 18, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
Siebel teaches a process visibility application that provides users end-to-end operational visibility into an organization’s business processes but does not explicitly teach updating a graphical user interface with updated information based on outputs from an LLM which is taught by the following citations from Adlersberg:
wherein the natural language request is received from an automated agent that is configured by a user of the visibility dashboard to submit the natural language request on a periodic basis. (Paragraph Number [0009] teaches an automated system that automatically generates or obtains transcripts of meetings of a particular organization; and prepare a batch of transcripts in an automatic manner, such as a daily batch that includes all the transcripts of all the meetings held on a particular day, or a weekly batch that includes all the transcripts of all the meetings held on a particular week, or similarly a bi-weekly or monthly or quarterly or annual batch includes all the transcripts of all the meetings held in such corresponding time-period. The batch of transcripts are automatically fed as input into an Artificial Intelligence (AI) engine/Machine Learning (ML) engine/Deep Learning (DL) engine/Reinforcement Learning (RL)/Neural Network (NN) engine, and particularly to a Large Language Model (LLM) engine; and particularly an LLM engine (such as ChatGPT of OpenAI, or LLAMA of Meta, or Bard of Google/Alphabet) which can be pre-trained on a large training corpus of business or business-related or business-oriented meeting transcripts, optionally in a particular field (e.g., finance; legal; marketing). Such LLM engine can be prompted or inquired to configured to autonomously analyze such large plurality of organizational meeting transcripts, and to autonomously generate from them insights. Paragraph Number [0036] teaches a computerized method comprising: (a) automatically obtaining or generating a plurality of organizational meeting transcripts, that correspond to a plurality of organizational meetings that took place within a particular time-period by participants that are associated with a particular organization; (b) automatically providing the plurality of organizational meeting transcripts as inputs to a Large Language Model (LLM) engine; (c) automatically providing to said LLM engine an LLM prompt, commanding the LLM engine to generate insights/business insights that the LLM engine can derive by performing LLM analysis of said plurality of organizational meeting transcripts; (d) automatically generating, by said LLM engine, based on said prompt and based on said plurality of textual transcripts, one or more LLM-generated insights/business insights. In some embodiments, steps (b) and (c) and (d) are performed autonomously by the LLM engine; wherein the LLM engine does not receive as input, or as part of said prompt, any guidance with regard to any topic-of-interest to which the LLM-generated insights/business insights should relate; wherein the LLM engine autonomously determines one or more topics-of-interest from an LLM-based analysis of said plurality of organizational meeting transcripts).
One of ordinary skill in the art would be motivated to combine these references as described in regard to claim 1.
As per claim 19, Siebel teaches:
A non-transitory computer readable storage medium having stored thereon instructions executable by one or more computer systems implementing a process visibility application, the instructions causing the one or more computer systems to (Paragraph Number [0170] teaches receive an enterprise search query, wherein the enterprise search query comprises a natural language input. Based on the enterprise search query and one or more retriever models, a plurality of data records associated with at least a portion of enterprise data of an enterprise information environment are retrieved. A respective relevance score is determined by the one or more retriever models, for each of the retrieved data records. At least one of the retrieved data records are selected based on the respective relevance scores. At least a portion of at least one of the retrieved data records are selected based on one or more enterprise access control protocols. Paragraph Number [0171] teaches the systems, methods, modules, layers, engines, datastores, and/or databases described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an Application Program Interface (API))).
The remainder of the claim limitations are substantially similar to those found in claim 1 and are rejected for the same reasons put forth in regard to claim 1.
As per claim 20, Siebel teaches:
A computer system comprising: one or more processors; and a computer readable storage medium having stored thereon program code that, when executed by the one or more processors, cause the one or more processors to: (Paragraph Number [0170] teaches receive an enterprise search query, wherein the enterprise search query comprises a natural language input. Based on the enterprise search query and one or more retriever models, a plurality of data records associated with at least a portion of enterprise data of an enterprise information environment are retrieved. A respective relevance score is determined by the one or more retriever models, for each of the retrieved data records. At least one of the retrieved data records are selected based on the respective relevance scores. At least a portion of at least one of the retrieved data records are selected based on one or more enterprise access control protocols. Paragraph Number [0171] teaches the systems, methods, modules, layers, engines, datastores, and/or databases described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an Application Program Interface (API))).
The remainder of the claim limitations are substantially similar to those found in claim 1 and are rejected for the same reasons put forth in regard to claim 1.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2024/0202221 to Siebel et al. (hereafter referred to as Siebel) in view of U.S. Patent Application Publication Number 2025/0006201 to Adlersberg et al. (hereafter referred to as Adlersberg) and in further view of U.S. Patent Application Publication Number 2017/0039040 to Nayak et al. (hereafter referred to as Nayak).
As per claim 16, the combination of Siebel and Adlersberg teaches each of the limitations of claim 1.
Siebel teaches a process visibility application that provides users end-to-end operational visibility into an organization’s business processes but does not explicitly teach using the specific OData service with an EDMX formatting which is taught by the following citations from Nayak:
wherein the data query service is an OData service and wherein the metadata representative of the visibility scenario is formatted in Entity Data Model XML (EDMX). (Paragraph Number [0022] teaches the EDM created by Jack using XML may be referred to as an entity data model extensible markup language (EDMX) model or EDMX data file (e.g., EDMX file). In an embodiment, contents of the EDMX file may include descriptions of entities, relationships between entities, attributes describing the entities, attribute values, navigation information, etc, in an embodiment. Jack may instantiate the IDE and access the EDMX file. Upon creating the EDMX file, Jack may model and develop the OData model (e.g., for the business process) by accessing the EDMX file using the IDE. In an embodiment, the IDE may receive the EDMX file, at 210. Upon receiving the EDMX file, a text editor model may be instantiate at the IDE that may invoke a text editor (or text editor viewer). (See also Paragraph Number [0032])).
Both the combination of Siebel and Adlersberg and Nayak are directed to Large Language Modelling. The combination of Siebel and Adlersberg discloses a process visibility application that provides users end-to-end operational visibility into an organization’s business processes. Nayak improves upon the combination of Siebel and Adlersberg by disclosing using the specific OData service with an EDMX formatting. One of ordinary skill in the art would be motivated to further include using the specific OData service with an EDMX formatting, to efficiently gather and pass data in a format that is regularly utilized in LLMs and commonly uses metadata and standards related to the data. The format can additionally be annotated and utilize database scripts allowing for ease of modification.
Accordingly, 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 system and method of a process visibility application that provides users end-to-end operational visibility into an organization’s business processes in the combination of Siebel and Adlersberg to further utilize the specific OData service with an EDMX formatting as disclosed in Nayak, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Response to Arguments
Applicant’s arguments filed 4/15/2026 have been fully considered but they are not fully persuasive.
Applicant argues that the claims are eligible under 35 USC 101. (See Applicant’s Remarks, 4/15/2026, pgs. 8-12). Examiner respectfully disagrees. As noted in the 35 USC 101 analysis presented above, the claims recite an abstract concept that is encapsulated by decision making analogous to a method of organizing human activity. Examiner notes that each of the limitations that encapsulate the abstract concepts are recited in the above 35 USC 101. Implementing a knowledge graph and improving its functionality are abstract concepts. Being able to understand, add to, and manipulate a knowledge graph is additionally an abstract concept. Other than storing the knowledge graph in a computer database, the knowledge graph and its associated manipulations are wholly independent from computer technology. Additionally, the claims do not recite a practical application of the abstract concepts in that there is no specific use or application of the method steps other than to make conclusory determinations and provide for direction for either a person or machine to follow at some future time. The claims do not recite any particular use for these determinations and directions that improve upon the underlying computer technology (in this instance the computer software, processor, and memory). Instead, Examiner asserts that the additional elements in the claim language are only used as implementation of the abstract concepts utilizing technology. The concepts described in the limitations when taken both as a whole and individually are not meaningfully different than those found by the courts to be abstract ideas and are similarly considered to be certain methods of organizing human activity such as managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions. The steps are then encapsulated into a particular technological environment by executing these steps upon a computer processor and utilizing features such as a computer interface or sending and receiving data over a network or displaying information via a computerized graphical user interface. However, sending and receiving of information over a network and execution of algorithms on a computer are utilized only to facilitate the abstract concepts (i.e. selecting data on an interface, publishing/displaying information, etc.). As such, Examiner asserts that the implementation of the abstract concepts recited by the claims utilize computer technology in a way that is considered to be generally linking the use of the judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)). Accordingly, Examiner does not find that the claims recite a practical application of the abstract concepts recited by the claims.
Applicant argues that the previously cited reference does not teach the newly amended portions including the new limitations recited by the independent claims. (See Applicant’s Remarks, 4/15/2026, pgs. 13-16). Examiner respectfully disagrees. Applicant’s primary contention appears to relate to the use of two LLMs with a structured prompt construction. Siebel describes the use and output of a first LLM in Paragraph Numbers [0167], [0063]-[0064], and [0065]. The output is specifically described in Paragraph Number [0076]. Further, Paragraph Number [0132 explicitly teaches subsequent iterations can include the enterprise comprehension module 806 generating a new query, request, or other output that is then passed back to the retrieval module. This teaches the use of multiple LLMs used in an iterative manner (i.e. passing the output of a first LLM into a second LLM. As such, Examiner contends that the Siebel reference teaches the two LLMs structure with prompt constructions similar to how the claim language is structured. Applicant’s distinctions appear to require understandings of the limitations that are more narrowly tailored than the broadest reasonable interpretation used by the Examiner. Accordingly, Examiner is not persuaded by the distinctions Applicant is attempting to make.
Applicant argues that the previously cited reference does not teach the newly amended portions including the new limitations recited by the independent claims. (See Applicant’s Remarks, 4/15/2026, pgs. 13-16). Examiner respectfully disagrees. Applicant’s primary contention appears to relate to the visibility scenario language present in the independent claims. Applicant’s Specification provides for the following example of what constitutes a visibility scenario: This visibility scenario can be understood as a meta-model that comprises, among other things, (1) a model of the business process, including its process event types and process context attributes associated with those types, and (2) visibility semantics that are relevant to the business process, including visibility attributes, visibility expression attributes, and process KPIs that are defined in terms of the process event types, process context attributes, visibility attributes, and/or visibility expression attributes. (See Paragraph Number [0013] of Applicant’s Specification). This is what supports that claim language that a visibility scenario comprises a model of the business process, a plurality of visibility-related attributes, and specifications of process KPIs. It is these three elements that Examiner is interpreting under a broadest reasonable interpretation. The following citations from Siebel are applicable:
Paragraph Number [0063] teaches the type system provides data accessibility, compatibility and operability with disparate systems and data. Specifically, the type system solves data operability across diversity of programming languages, inconsistent data structures, and incompatible software application programming interfaces. Type system provides data abstraction that defines extensible type models that enables new properties, relationships and functions to be added dynamically without requiring costly development cycles. The type system can be used as a domain-specific language (DSL) within a platform used by developers, applications, or UIs to access data. The type system provides interact ability with data to perform processing, predictions, or analytics based on one or more type or function definitions within the type system. (Examiner assert that these sections teach at least the providing of data that constitutes a business model that provides for attributes that can be displayed and interacted with in a visual manner) Paragraph Number [0064] teaches type definitions can be a canonical type declared in metadata using syntax similar to that used by types persisted in the relational or NoSQL data store. A canonical model in the type system is a model that is application agnostic (i.e., application independent), enabling all applications to communicate with each other in a common format. Unlike a standard type, canonical types are comprised of two parts, the canonical type definition and one or more transformation types. The canonical type definition defines the interface used for integration and the transformation type is responsible for transforming the canonical type to a corresponding type. Using the transformation types, the integration layer may transform a canonical type to the appropriate type. Paragraph Number [0054] teaches supply chain data may be obtained from a first artificial intelligence application (e.g., an inventory management and optimization or supply chain application) and the impact information may be obtained based at least in part on the supply chain data and information from another artificial intelligence application, such as an artificial intelligence application used to monitor and predict maintenance needs for a fleet of vehicles. In the example, the supply chain data may indicate issues with the supply, another artificial intelligence application may be used to identify vehicles needing maintenance, and the impact information may represent an insight into how the vehicles needing maintenance are being impacted by issues in the supply chain (e.g., based on the supply chain data). Example information from different data domains or application objects may include key performance metrics (KPIs) (e.g., from left to right—a fleet readiness score, unscheduled maintenance avoided (hours) over a time period, a number of flights gained (e.g., due to avoided maintenance), operation time at risk, and/or the like), aircraft status risk score information, component risk score and ranking (e.g., by risk score) information, information associated with artificial intelligence alerts, flight capability information (e.g., by geographic region), case information, supply chain data, and impact information regarding aircraft being impacted by effects within the supply chain. (Examiner asserts that this section teaches the use of process KPIs and other visibility-related attributes).
Examiner asserts that these sections of the Siebel reference indicate the reception of a computer based model that visualizes specific real-word information in the form of rules relating to business processes (in Siebel this is the processing and prediction of processes within the system), a plurality of visibility-related attributes (in Siebel this is the definitions and transformations of data into various visualizations, and specifications that are one or more process KPIs (in Siebel these are also described as KPIs). As such, Examiner asserts that the Siebel reference teaches visibility scenarios as defined by both the specification and as claimed in the independent claims. Applicant’s distinctions appear to require understandings of the limitations that are more narrowly tailored than the broadest reasonable interpretation used by the Examiner. Accordingly, Examiner is not persuaded by the distinctions Applicant is attempting to make.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW H DIVELBISS whose telephone number is (571)270-0166. The examiner can normally be reached on 7: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, Jerry O'Connor can be reached on (571) 272-6787.
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).
/M. H. D./
Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624
Prosecution Insights