DETAILED ACTION
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 .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 6/2/25, Applicant, on 10/31/25, amended claims. Claims 1-20 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The 112b rejections on claims 8, 18 are withdrawn in light of the amendments.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“A method comprising:
forming a plurality of files representing automated workflow templates associated with graph data;
receiving activation data representing activation of an automated workflow template associated with a process workflow;
receiving configuration data as parameters;
configured to implement a type of the process workflow;
implementing a type of the process workflow based on the configuration data;
linking the automated workflow template to executable instructions;
executing the type of the process workflow based on the configuration data and the executable instructions;
retrieving execution data associated with execution of the type of the process workflow,
identifying an omission in the graph data based on the execution data;
based on identifying the omission in the graph data, assigning ownership of a data asset within the graph data to a user account.”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” – managing personal behavior or interactions between people (including following rules or instructions), as here we are having a template of workflow [series of tasks, that can be e.g. “approval” between people; assigning tasks to people – see e.g. Applicant’s FIG. 8], with a graph (e.g. See FIG. 1B, 146 - people are approving different requests); receiving configuration data (e.g. see [0043] as published – can be identity of users that can provide approval), and then linking the template with the type of workflow, and then identifying an omission and assigning ownership of an asset/task to a user. Accordingly, claim 1 is directed to an abstract idea because it is generating a series of rules or instructions people follow for tasks/approvals/workflows, and assigning ownership for omitted/missing information related to the users in the business process.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. A computer is not explicitly recited at this time. It appears a computer may be intended; for purposes of compact prosecution, Examiner recommends as starting point to recite a computer performing the steps here. In particular, the claim 1 recites additional elements that are:
A method comprising:
forming a plurality of files representing automated workflow templates associated with graph data;
receiving activation data representing activation of an automated workflow template associated with a process workflow;
…
linking the automated workflow template to executable instructions;
executing the type of the process workflow based on the configuration data and the executable instructions…”
The claim’s “automated” and “executable instructions” are interpreted as a “computer” performing the steps; and this is treated as” - MPEP 2106.05f applies –the claim involves a computer in only some of the steps; and is considered “apply it [the abstract idea] on a computer”; merely uses a computer as a tool to perform an abstract idea.
Accordingly, the additional elements, individually or in combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a computing system [if recited in future, or based on limitation of “automation” and “executable instructions”, is treated as MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent claim 11 is directed to a system at step 1, which is a statutory category. Claim 11 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one, 2a, prong 2, and step 2b. The additional limitations, of processor, memory, processor executing instructions, are all part of “apply it on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2b. The claim is not patent eligible.
Claims 2-4, 7, 12-14, 17 narrow the abstract idea by having various further data determined, related to tasks, workflows, templates.
Claims 5 and 15 narrow the abstract idea for similar reasons as above; but further states “object-oriented programming language.” This is viewed as an additional element and treated as MPEP 2106.05f “apply it [abstract idea] on a computer” and MPEP 2106.05h “field of use” at step 2a, prong two and step 2B.
Claims 6 and 16 narrow the abstract idea for similar reasons as above; but further states “application programming interface.” This is viewed as an additional element and treated as MPEP 2106.05f “apply it [abstract idea] on a computer” and MPEP 2106.05h “field of use” at step 2a, prong two and step 2B.
Claims 8, 18 narrow the abstract idea by having a graph-based ontology; generating a template based on the ontology, and “a subset of triples,” which based on Applicant’s [0003, 0048, 0085] as published are “metadata or statements”; and are viewed as some description of data. Any additional elements in amended claim 8, which still does not require a computer, at this time or once the claim is amended to clarify steps are performed “by a computer”, are also viewed as MPEP 2106.05f “apply it [abstract idea] on a computer.”
Claims 9 and 19 narrow the abstract idea for similar reasons as above; but further states “storing the automated workflow templates in a template repository.” This is viewed as an additional element and treated as MPEP 2106.05f “apply it [abstract idea] on a computer” and MPEP 2106.05h “field of use” at step 2a, prong two and step 2B. At step 2B, it is also considered a conventional computer function (See MPEP 2106.05d(II) iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306.
Claims 10 and 20 narrow the abstract idea by describing different data that are in a template in the alternative; one alternative is just “delegate ownership to a dataset” which is viewed as assigning responsibility.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-2, 5-7, 9-12, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 2021/0004711), Makhija (US 2022/0327006), and Kamath (US 2016/0092818).
Concerning claim 1, Gupta discloses:
A method (Gupta – see par 3 – computer-implemented method generating data structure that stores a knowledge graph for a decision making process that is to be automated) comprising:
forming a plurality of files representing automated workflow templates associated with graph data (Gupta – See par 22 – RPA (robotic process automation) automates repetitive human tasks; see par 63 - FIG. 3 depicts a block diagram of a system for automating a process cognitively according to one or more embodiments of the present invention. The system 100 facilitates not only automation of a process, but also facilitates optimizes the process and decision-making that is part of executing the method using artificial intelligence (AI). The system 100 derives actionable, real-time insights from operations intelligence to augment the formulation, orchestration, and automation of an adaptive process. The system 100 further facilitates a cognitive RPA (Robotic process automation) that formulates and orchestrates processes that reshape themselves as they run; see par 64 - The system includes a knowledge graph generator 115 that automatically generates a knowledge graph 120 using machine learning and deep learning techniques to identify the changes that happen using one or more of records, time series data, raw events. In one or more examples, such data representing a process (process-representation 105) that is to be automated is stored using a structured format such as a metalanguage, for example, extendable markup language (XML), business process execution language (BPEL), a Business Process Model and Notation (BPMN), etc);
receiving activation data representing activation of an automated workflow … associated with a process workflow (Gupta – see par 63 - FIG. 3… The system 100 derives actionable, real-time insights from operations intelligence to augment the formulation, orchestration, and automation of an adaptive process. The system 100 further facilitates a cognitive RPA that formulates and orchestrates processes that reshape themselves as they run. see par 84 - Referring back to the RPA system 100 in FIG. 3, the knowledge graph 120 that is generated is used by a decision tree maker 125 to generate a process execution model 130 (decision tree). An execution engine 150 uses the decision tree 130 to execute the process. The decision tree 130 includes “content”, which includes the entities associated with the process; “context”, which includes values of the entities at the time of process execution, and “contract”, which includes the factors/values that the entities hold or the condition and actions present in the process specific knowledge graph 120. See par 85 - The content, context, and contract values along with the input values and the final results of the process are mapped. The mapping here identifies these parameters and maps it into process specific knowledge graph 120. The decision tree 130 includes the knowledge base of entities and relationship with the corresponding parameters, stored in the form of metadata. This is manifested as a custom decision tree structure. Depending upon the final result of the process, the weightage of all the parameters is updated. Here, the “final result” is the knowledge graph 120 that is a result of evaluating the entities, transitions, conditions, content, context, and contract values. The execution engine 150 uses the decision tree 130 based on the weightages assigned to the parameters to execute the process.)
To any extent Gupta doesn’t disclose a “template”, Makhija discloses:
receiving data representing activation of an automated workflow “template” associated with a process workflow (Makhija – see par 56 - Data modeling is done through template definitions and API calls to the shared frameworks platform layer. See par 116 - Further, the platform as a product advantageously enables citizen developer user to create end to end application with additional customized microservices and API deployed and configured in CDS. The developer creates application templates based on the operational verticals with predefined rules and workflows and database schema for out of box implementation. Third party implementation entities can select the application, customize and extend schema based on specific needs of customer region and line of operation. The platform has an ability create microservices and schema dynamic based on standard templates and customize layer; see par 95 - the AI flow Orchestrator engine 201 takes a record centric view of all transactions applied to different records for the approval process. For example, an invoice record goes through different verification stages compared to a requisition for approval. Even within those types, there may be subtypes which require different business rules to act on them. The AI actions of Flow Orchestrations is explained in flow diagrams 200A and 200B of FIGS. 2A and 2B. In FIG. 2A, given an input transaction record and the desired approval, the user is guided with a predicted flow of operational/business tasks that would take the transaction to the intended output; see par 99 - The AI task orchestrator engine 202 further determine tradeoff between tasks that require user approval vs. automated approval to enable automation of process flows as shown by flow diagram 200D of FIG. 2D)
Gupta and Makhija disclose:
receiving configuration data as parameters ([0043] as published - Rather, configuration data, as variables, may be used to define workflow functionalities, whereby persons or users of any role may be capable to configure workflow processes. - Gupta discloses the limitations based on broadest reasonable interpretation in light of the specification– see par 71 - the knowledge graph generator 115 enhances the process-specific knowledge graph 120 with “entity source”, “states”, “conditions”, and “actions”—by analyzing the static process definitions (workflow and rules for decisions); and by analyzing the historical data (using machine learning algorithms) generated by process execution engines in the RPA system 100 when executing the process with manual intervention. Such information can be derived by evaluation of a process logs, audit trail logs, and other such information associated with the process);
implementing a type of the process workflow based on the configuration data (Gupta – see par 72 - historical data of process execution can include a sequence of path traversed, the input parameters for each operation, output parameters, and errors encountered. For example, in approval node the ruleset condition if (role is Manager) autoApprove is set to true. Based on the historical data, all the paths traversed by the process engine are analyzed and a flow pattern is captured; see par 75 - For example, the electronic data source can include a policy document that specifies that an employee that is designated a particular role cannot travel beyond a certain distance. Accordingly, the RPA system 100 can execute the process flow according to the condition by accessing corresponding information fields;
See also Makhija – par 104 – Approval Level Optimization - Depending on the criticality of required approvals, the ML classification model described in “AI Task orchestrator” section can also be extended to classify the level of User intervention; the ML classification model can leverage the organizational hierarchy to route high-value invoices to managers for approvals and simple invoices get auto-approved but general invoices requiring attention get routed to financial analysts as depicted by flow diagram 200F in FIG. 2F. see par 119 - Additional Features required to implement as part of Seed project include project repository as seed for all entity/end user implementations, manage all the entities from single manage interface to decide which entity is going to view what specific data, setting the permission and access control to the application development team to help them maintain and deploy their features and fixes faster and safer for Version control.);
linking the automated workflow template to executable instructions (Makhija – See par 49, FIG. 1 – foundation layer 102 enables creation and management of smart forms (and templates), framework to define UI (user interface) screens, controls, etc. through use of templates; see par 56 - Data modeling is done through template definitions and API calls to the shared frameworks platform layer. See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107.);
executing the type of the process workflow based on the configuration data and the executable instructions (Gupta – see par 74 - the process-specific knowledge graph 105 is further enhanced with “internal factors” and “external factors” that influence the outcomes. In one or more embodiments of the present invention, such factors are determined by analyzing historic process data, events and logs, various systems-of-records (databases and documents) like policies, regulation, streaming events, feeds etc.); See par 116 - Further, the platform as a product advantageously enables citizen developer user to create end to end application with additional customized microservices and API deployed and configured in CDS. The developer creates application templates based on the operational verticals with predefined rules and workflows and database schema for out of box implementation. Third party implementation entities can select the application, customize and extend schema based on specific needs of customer region and line of operation. The platform has an ability create microservices and schema dynamic based on standard templates and customize layer;
see also Makhija – see par 99 - The AI task orchestrator engine 202 further determine tradeoff between tasks that require user approval vs. automated approval to enable automation of process flows as shown by flow diagram 200D of FIG. 2D. ); and
retrieving execution data associated with execution of the type of the process workflow, (Gupta – See par 63 - The system 100 derives actionable, real-time insights from operations intelligence to augment the formulation, orchestration, and automation of an adaptive process. The system 100 further facilitates a cognitive RPA that formulates and orchestrates processes that reshape themselves as they run. see par 77 - The knowledge graph generator 115 automatically maps the process flow execution results against input variables, values obtained during process flow, the values of “internal factors” and the values of “external factors”. For the mapping, the process-specific knowledge graph 120 is enhanced with “entity source”, “states”, “conditions” and “actions” by analysing the static process definitions (workflow and rules for decisions); and by analysing the historical data (using machine learning algorithms) generated by process execution engines. See par 83 - the RPA system 100 is facilitate to determine actionable insights from the knowledge graph 120, the insights being used as an addendum for executing the process. The derivations (based on influencing factors) from the knowledge graph 120 include both, implicit information as well as the explicit data. The derivations of the knowledge graph 120 are consumed for the process execution depending on the context, content, and configuration. The RPA system 100 accordingly provides a dynamic behavior where the process execution assimilates the external factors and influences the decision making automatically;
see also Makhija - see par 84 - Further, the workflow includes compliance process with validation of end to end flows and is responsible to verify and simulate the flow as per the data model. The compliance process identifies outliers and generates alerts along with replaying the events. Furthermore, the workflow block 100B includes a user process block that generates notations, identifies blocks requiring user intervention, defines start and end of the flow, and connects user action to business events).
Gupta discloses that the RPA (Robotic Process Automation) results in orchestrating processes that reshape themselves as they run (See par 63) and determining insights used as an addendum for executing a process (See par 63, 83). Makhija discloses identifying blocks requiring user intervention (See par 84).
Kamath discloses:
identifying an omission in the graph data based on the execution data ([0045] as published states - In some cases, governance logic module 123 may be configured to automatically obviate (e.g., using algorithms configured by machine learning and the like) the issue or determine a recommended action. For example, if a dataset, resource data, data products, data assets, and the like are determined to omit an assigned role of ‘data steward,’ governance logic module 123 may automatically generate a recommend data steward based on, for instance, characteristics of data steward user and the attributes of dataset data or metadata.
Kamath discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 35 - some or all of the conditional stages in the workflow can be configured to be dependent upon the content of a hierarchy model 112. The hierarchy model 112 maintains a set of hierarchy data that tracks from an organizational perspective the products/people or products/role (e.g., for role based approvals) in the organization, and maps those products/people or products/role to designated locations within the hierarchy. As such, the hierarchy model provides a set of data that can provide a context for the execution of the workflow.); and
based on identifying the omission in the graph data, assigning ownership of a data asset within the graph data to a user account (Applicant’s [0039] as published states “A fifth automated workflow template may be configured to trigger a workflow responsive of detecting no identified owner (e.g., a user terminates employment with an enterprise or changes roles), whereby the fifth automated workflow template may be configured to automatically delegate ownership to another user that has similar characteristics or attributes (e.g., similar roles, similar permissions, etc.).”; Applicant’s [0045] as published states “In another example, governance logic module 123 may be configured to identify a status from any number of statuses (e.g., a status of one of “unassigned,” “pending,” “complete,” etc.) of an automated workflow, and may be configured further to automatically take action to resolve certain status conditions to ensure an automated workflow may operate optimally.”
Kamath – see par 35 - by consulting the hierarchy model 112, the conditional stage of the workflow can automatically determine whether a given product that needs approval falls within the first department or the second department, thereby automatically selecting the appropriate approval path for that product; see par 36 – workflow handles possible conditions, where context for conditions determined by consulting hierarchy data for the organization; see par 37 - It is a fact of life in many organizations that personnel will leave or change jobs, and that re-organizations will occur to change the way that departments and groups are structured in the business. With the current embodiments of the invention, a workflow may not need to be amended after such organizational changes since the workflow only needs to consult the new organizational data to work properly.).
Gupta, Makhija, and Kamath are analogous art as they are directed to business process workflows with tasks for people (see Gupta Abstract, FIG. 4, par 80; Makhija Abstract, see par 52, 86, 104, FIG. 2A-2F – approvals/tasks with user intervention; Kamath abstract, par 35). 1) Gupta discloses mapping processes and then having a “custom” structure based on context (See par 84-85). Makhija improves upon Gupta by having “templates” with “predefined rules and workflows” that are then customized (See par 56, 116). One of ordinary skill in the art would be motivated to further include “templates” to efficiently improve upon the customization for workflows in Gupta. 2) Gupta discloses that the RPA (Robotic Process Automation) results in orchestrating processes that reshape themselves as they run (See par 63) and determining insights used as an addendum for executing a process (See par 63, 83). Makhija discloses identifying blocks requiring user intervention (See par 84). Kamath improves upon Gupta and Makhija by having an omission in graph data with a conditional stage in a workflow and then assigning the conditional stage to an appropriate department (see par 35-37). One of ordinary skill in the art would be motivated to further include workflows that do not specifically identify who is responsible, and use context/conditions for determining which department/people are responsible for an approval to efficiently improve upon the customization for workflows in Gupta and the user interventions in Makhija.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for having business processes using knowledge graphs that are customized in Gupta (See Abstract, par 64, 84-85, FIG. 3), to further include templates for customization in Makhija, to further include identifying conditional stages of a workflow that can be used to then identify which department/group of people are responsible for approval as disclosed in Kamath, 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 and there is a reasonable expectation of success.
Concerning independent claim 11, Gupta and Makhija and Kamath disclose:
A system (Gupta – see par 4 – system includes a memory, and a processor coupled with the memory. The processor performs a method for automating a decision making process.) comprising:
a memory including executable instructions (Gupta – see par 5 - a computer program product includes a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a processing circuit to cause the processing circuit to perform a method for automating a decision making process); and
a processor, responsive to executing the instructions, is configured to (Gupta – see par 5 - a computer program product includes a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a processing circuit to cause the processing circuit to perform a method for automating a decision making process).
The remaining limitations are similar to claim 1 above. Claim 11 is rejected for the same reasons.
Concerning claim 2 and 12, Gupta and Makhija disclose:
The method of claim 1 wherein the graph data comprises one or more of a portion of a knowledge graph or a data catalog (Gupta – see par 64 – knowledge graph; data representing a process (process-representation 105) that is to be automated is stored using a structured format such as a metalanguage, for example, extendable markup language (XML), business process execution language (BPEL), a Business Process Model and Notation (BPMN), etc.).
Concerning claim 5 and 15, Gupta discloses:
The method of claim 1 …executable objects of an object-oriented programming language (Gupta – See par 64 – data representing a process stored in structured format… such as java connector architecture (JCA) files; see par 70 - It should be noted that the “entities” as described herein include computer data structures (e.g. objects) that are automatically instantiated and attributes populated by the knowledge graph generator 115; see par 124 – computer readable instructions to carry out operations include… an object oriented programming language;)
Makhija discloses:
The method of claim 1 wherein linking the automated workflow template to the executable instructions comprises linking the automated workflow template to executable objects … to implement a process model (Makhija – see par 56 - Data modeling is done through template definitions and API calls to the shared frameworks platform layer. See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107. See par 84 - the workflow visualization block 100B includes a process modeler that is responsible to generate notations and defines process as per trained models saved in the repository. The process modeler manages various processes, responsible to integrate these processes and use tools repository to structure the workflow. See par 116 - Further, the platform as a product advantageously enables citizen developer user to create end to end application with additional customized microservices and API deployed and configured in CDS. The developer creates application templates based on the operational verticals with predefined rules and workflows and database schema for out of box implementation. Third party implementation entities can select the application, customize and extend schema based on specific needs of customer region and line of operation. The platform has an ability create microservices and schema dynamic based on standard templates and customize layer. See par 120 - In step 403 interacting by an AI based orchestration engine with one or more configurable components in a codeless platform architecture for executing the SCM operations wherein the AI based orchestration engine drives execution of SCM operations through one or more data objects mapped to the API for structuring the workflow of the SCM operations by a process modeler of the AI based orchestration engine.
Obvious to combine Gupta and Makhija for the same reasons as claim 1 above. In addition, Gupta discloses using java (see par 64), instantiating objects (See par 70), and using object oriented programming language (See par 124). Makhija improves upon Gupta by further having a template [see reasons for combining claim 1] and executing data objects (See par 120).
Concerning claim 6 and 16, Gupta and Makhija disclose:
The method of claim 1 wherein…
linking the automated workflow template to executable objects of an object-oriented programming language (Gupta – See par 64 – data representing a process stored in structured format… such as java connector architecture (JCA) files; see par 124 – computer readable instructions to carry out operations include… an object oriented programming language; see par 70 - It should be noted that the “entities” as described herein include computer data structures (e.g. objects) that are automatically instantiated and attributes populated by the knowledge graph generator 115) via an application programming interface (“API”) to implement a process model (Gupta – see par 103 - Here, an “adapter” refers to technique used to access an external system. As the process can be interacting with different external (third party) systems, the adapters provide an abstraction in terms of connectivity, access, retrieval, updating of the external system during the process flow. For example, an application programming interface, a protocol, or any other specific access mechanism used for such access can be included in, or referred to as the adapter.
Makhija discloses:
The method of claim 1 wherein linking the automated workflow template to the executable instructions comprises:
linking the automated workflow template to executable objects …via an application programming interface (“API”) to implement a process model (Makhija – see par 56 - Data modeling is done through template definitions and API calls to the shared frameworks platform layer. See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107. See par 84 - the workflow visualization block 100B includes a process modeler that is responsible to generate notations and defines process as per trained models saved in the repository. The process modeler manages various processes, responsible to integrate these processes and use tools repository to structure the workflow. See par 116 - Further, the platform as a product advantageously enables citizen developer user to create end to end application with additional customized microservices and API deployed and configured in CDS. The developer creates application templates based on the operational verticals with predefined rules and workflows and database schema for out of box implementation. Third party implementation entities can select the application, customize and extend schema based on specific needs of customer region and line of operation. The platform has an ability create microservices and schema dynamic based on standard templates and customize layer. See par 120 - In step 403 interacting by an AI based orchestration engine with one or more configurable components in a codeless platform architecture for executing the SCM operations wherein the AI based orchestration engine drives execution of SCM operations through one or more data objects mapped to the API for structuring the workflow of the SCM operations by a process modeler of the AI based orchestration engine.).
It would be obvious to combine Gupta and Makhija for the same reasons as claim 1 and 5. In addition, Gupta and Makhija disclose use of APIs.
Concerning claim 7 and 17, Gupta and Makhija disclose:
The method of claim 1 further comprising implementing an instance of the automated workflow (Gupta – see par 63 - The system 100 further facilitates a cognitive RPA that formulates and orchestrates processes that reshape themselves as they run. These processes are data driven, adaptive, and intelligent, determining and executing a next action based on context formation from data, instead of the same repeatable sequence of actions. In other words, using the cognitive RPA, the system 100 automatically determines a sequence of operations in the process that is to be executed based on one or more data input from the user along with several contextual restrictions that the system 100 automatically detects; see par 79 - FIG. 4 depicts a flowchart of a process execution by an RPA system according to one or more embodiments of the present invention. Here, execution of the specific process of travel request approval is shown) template (Makhija – see par 49 – foundation layer 102 provides a set of microservices that execute the tasks of managing code deployment, supporting code versioning, deployment etc. The layer collectively enables creation and management of smart forms (and templates), framework to define UI screens, controls etc. through use of templates. Seamless theming support is built to enable specific form instances (created at runtime) to have personalized themes, extensive customization of the user experience (UX) for each client entity and or document; see par 76 - the orchestrator UI 109C provides details through graphical representation to customize data flow, workflow, manage run, settings and configuration to execute the workflow; see par 90 - The release manager component 111C is responsible for managing, planning, scheduling, and controlling delivery throughout the release lifecycle using other subcomponents and for Orchestrating entire pipeline with automation. The deployment manager component 111D configures and run delivery workflows for applications and platforms. It Creates standardized deployment process to deploy predictable, high-quality releases. The component automates workflows).
It would be obvious to combine Gupta and Makhija for the same reasons as claim 1.
Concerning claim 9 and 19, Gupta and Makhija disclose:
The method of claim 1 further comprising storing the automated workflow templates in a template repository, the automated workflow template associated with a link to a user input at an interface. (Makhija – see par 49 – foundation layer 102 enables creation and management of smart forms (and templates), framework to define UI screens, controls etc. through use of templates. See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107. see par 84 - the workflow visualization block 100B includes a process modeler that is responsible to generate notations and defines process as per trained models saved in the repository. The process modeler manages various processes, responsible to integrate these processes and use tools repository to structure the workflow. Further, the workflow includes compliance process with validation of end to end flows and is responsible to verify and simulate the flow as per the data model. The compliance process identifies outliers and generates alerts along with replaying the events. Furthermore, the workflow block 100B includes a user process block that generates notations, identifies blocks requiring user intervention, defines start and end of the flow, and connects user action to business events).
It would be obvious to combine Gupta and Makhija for the same reasons as in claim 1 above.
Concerning claim 10 and 20, Gupta and Makhija disclose:
The method of claim 1 wherein forming the plurality of files representing automated workflow templates comprises forming one or more of:
a data access template configured to perform a process workflow to provide approval responsive to a request to access data (Examiner notes that the claim as constructed only “represents” workflow, and is viewed as “describing” the names of different data in the templates, and as of 10/31/25, in the alternative. The various descriptions are viewed as “names”, printed matter in MPEP 2111.05 and since they do not have a functional relationship with the computer, they are not entitled to patentable weight. Nonetheless for purposes of compact prosecution, art will be applied –
Gupta discloses the alternative - see par 25 - consider an example scenario of a travel request approval process in an organization; see also Makhija – par 110 – Process Orchestrator has Access control policies; par 119 - the platform of the present invention provides creation of Seed project that includes common repository and template project containing all metadata information and applications can be built on top using these templates. Additional Features required to implement as part of Seed project include project repository as seed for all entity/end user implementations, manage all the entities from single manage interface to decide which entity is going to view what specific data, setting the permission and access control to the application development team);
a data enrichment template configured to identify types of data requiring action (Gerber discloses the alternative – see par 222 - The modeling task can be facilitated by providing features which assist users during modeling and make recommendations on how to complete a being edited business process model. Ideally, the assistance approach is context-aware, which means that it takes the current progress of modeling as a context for the recommendation into account. The basis for such a recommendation feature could be a repository of completed business process models.
See also Makhija – see par 84 - Further, the workflow includes compliance process with validation of end to end flows and is responsible to verify and simulate the flow as per the data model. The compliance process identifies outliers and generates alerts along with replaying the events. Furthermore, the workflow block 100B includes a user process block that generates notations, identifies blocks requiring user intervention, defines start and end of the flow, and connects user action to business events.);
a metadata completeness template configured to modify metadata to establish a substantially complete set of metadata for a dataset, a metadata freshness template configured to assign a task to review a dataset periodically (Makhija discloses the alternative– see par 104 - Depending on the criticality of required approvals, the ML classification model described in “AI Task orchestrator” section can also be extended to classify the level of User intervention. For example, the ML classification model can leverage the organizational hierarchy to route high-value invoices to managers for approvals and simple invoices get auto-approved but general invoices requiring attention get routed to financial analysts as depicted by flow diagram 200F in FIG. 2F. ),
an automatic delegation template configured to delegate ownership to a dataset, or
a status-based template configured to assign a status to a dataset.
It would be obvious to combine Gupta and Makhija for the same reasons as in claim 1 above.
Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 2021/0004711), and Makhija (US 2022/0327006), as applied above to claims 1-2, 5-7, 9-12, 15-17, and 19-20, and further in view of Reh (US 2020/0293564).
Concerning claim 3 and 13, Gupta discloses that data representing a process that is to be automated is stored using a structured format such as BPMN (See par 64).
Makhija discloses:
The method of claim 1 wherein linking the automated workflow template to the executable instructions comprises linking the automated workflow template to a process model (Makhija – see par 43 - the configurable components enable an application developer user/citizen developer, a platform developer user and a SCM application user working with the SCM application to execute the operations to code the elements of the SCM through configurable components. see par 56 - a developer user or admin user will structure one or more SCM application and associated functionality by the application layer of microservices, either by leveraging the shared frameworks platform layer; data modeling is done through template definitions and API calls to the shared frameworks platform layer; See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107. see par 84 - the workflow visualization block 100B includes a process modeler that is responsible to generate notations and defines process as per trained models saved in the repository. The process modeler manages various processes, responsible to integrate these processes and use tools repository to structure the workflow. Further, the workflow includes compliance process with validation of end to end flows and is responsible to verify and simulate the flow as per the data model).
Makhija checks compliance of process and for validation (See par 84). To any extent this is not considered a “process model,” Kamath also discloses:
linking the automated workflow template to a process model (Reh – See par 41 - A process model 222 may include the models, workflow stems, process definitions, and process relationships. see par 59 - The process models 222 may in a format that complies with the business process model and notation (BPMN). The computing server 120 may also receive process maps 310. A process map 310 may be a process model 222 that is automatically generated by the computing server 120, such as using the automatic process mining engine 254; see par 74 - The types of process models 222 (including process maps 310) received by the computing server 130 may depend on the context. The received process models 222 may include a target process model that needs to be optimized, similar or related process models. The process models 222 received by computing server 120 may include the models, workflow stems, process definitions, and process relationships).
It would be obvious to combine Gupta and Makhija and Kamath for the same reasons as in claim 1 above. Gupta, Makhija, Kamath, and Reh are analogous art as they are directed to business process workflows with tasks for people (see Gupta Abstract, FIG. 4, par 80; Makhija Abstract, see par 52, 86, 104, FIG. 2A-2F – approvals/tasks with user intervention; Kamath Abstract, par 35; Reh Abstract, par 43). Gupta discloses that data representing a process that is to be automated is stored using a structured format such as BPMN (See par 64). Makhija discloses allowed a user to use “configurable components” to develop the SCM (supply chain management) application and performing data modeling through template definitions and API calls to a shared layer (See par 43, 56, 84). Reh improves upon Gupta and Makhija and Kamath by sending and receiving “process models” in formats that comply with BPMN. One of ordinary skill in the art would be motivated to further include receiving “process models” in formats that comply with BPMN to efficiently improve upon the customization for workflows in Gupta and the data modeling done through template definitions in Makhija (See par 56).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for having business processes using knowledge graphs that are customized in Gupta (See Abstract, par 64, 84-85, FIG. 3), to further include templates for customization in Makhija, and to further include “process models” in formats that comply with BPMN as disclosed in Reh, 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 and there is a reasonable expectation of success.
Concerning claim 4 and 14, Gupta discloses that data representing a process that is to be automated is stored using a structured format such as BPMN (See par 64).
Makhija and Reh disclose [similar to claim 3 above]:
The method of claim 1 wherein linking the automated workflow template to the executable instructions comprises:
linking the automated workflow template to a process model (Makhija – see par 43 - the configurable components enable an application developer user/citizen developer, a platform developer user and a SCM application user working with the SCM application to execute the operations to code the elements of the SCM through configurable components. see par 56 - a developer user or admin user will structure one or more SCM application and associated functionality by the application layer of microservices, either by leveraging the shared frameworks platform layer; data modeling is done through template definitions and API calls to the shared frameworks platform layer; See par 62 - The entity machine 106A with a citizen developer user UI is configured for sending, receiving, modifying or triggering processes and data object for creation of one or more of a SCM application over a network 107. see par 84 - the workflow visualization block 100B includes a process modeler that is responsible to generate notations and defines process as per trained models saved in the repository. The process modeler manages various processes, responsible to integrate these processes and use tools repository to structure the workflow. Further, the workflow includes compliance process with validation of end to end flows and is responsible to verify and simulate the flow as per the data model) compliant with a Business Process Model and Notation (“BPMN”) standard (Reh – See par 41 - A process model 222 may include the models, workflow stems, process definitions, and process relationships. see par 59 - The process models 222 may in a format that complies with the business process model and notation (BPMN). The computing server 120 may also receive process maps 310. A process map 310 may be a process model 222 that is automatically generated by the computing server 120, such as using the automatic process mining engine 254; see par 74 - The types of process models 222 (including process maps 310) received by the computing server 130 may depend on the context. The received process models 222 may include a target process model that needs to be optimized, similar or related process models. The process models 222 received by computing server 120 may include the models, workflow stems, process definitions, and process relationships).
Obvious to combine Gupta, Makhija, Kamath, and Reh for the same reasons as claim 3 above.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 2021/0004711), and Makhija (US 2022/0327006), as applied above to claims 1-2, 5-7, 9-12, 15-17, and 19-20, and further in view of Bachhofner, “Automated Process Knowledge Graph Construction from BPMN Models,” 2022, In International Conference on Database and Expert Systems Applications, pages 32-47.
Concerning claim 8 and 18, Gupta discloses that data representing a process that is to be automated is stored using a structured format such as BPMN (See par 64).
Gupta discloses having a knowledge graph 120 using entities, attributes, and relationships extracted by a process miner (See FIG. 1) (see par 66) and that its robotic process automation system that creates decision models is trained on domain knowledge (See par 119). Makhija discloses having a workflow knowledge database that includes building model-driven flows incorporating application process within supply chain (See par 74).
Bachhofner discloses:
The method of claim 1 further comprising:
implementing a graph-based ontology (Bachhofner –see page 34, 1st paragraph – transform business process models in BPMN into a KG (knowledge graph) representation in RDF (resource description framework) based on and extending an existing ontology for process representation);
generating the automated workflow template based on implementing the graph-based ontology and a first subset of triples (Bachhofner –see page 34, 1st paragraph – transform business process models in BPMN into a KG representation in RDF (resource description framework) based on tonology for process representation; supports BPMN 2.0 elements, including “most used ones”; see page 35, 2nd paragraph - For modeling KGs (knowledge graphs), Resource Description Framework (RDF) [13] is a widely used language recommended by the World Wide Web Consortium (W3C). KGs in RDF are formed from triples, each of which consists of a subject, a predicate, and an object; see page 35, last paragraph - BPMN-based Ontology (BBO) [5] is an ontology to represent business processes modeled in BPMN 2.0 in a KG. An ontology is necessary as it for example allows us to sub-class it’s concepts, or use their properties); and
implementing the configuration data associated with a second subset of triples, based on the automated workflow template (Bachhofner – page 35 - Figure 2 illustrates two triples in RDFs from our motivating use case - the two triples belong to the first task of our mass production process. The first triple encodes the statement “Activity 10ruka0 is a subclass of bbo:ManualTask”, and the second “Activity 10ruka0 has the bbo name of Set machine to auto mode),
wherein a function of the automated workflow template is configured to extend at least one of a data catalog or a knowledge graph (Bachhofner – see page 39, 2nd paragraph - To transform BPMN models into a knowledge graph representation, we use RDF Mapping Language (RML) as a declarative mapping language. RML allows for a similar abstraction for the relationship of heterogeneous data structures to RDF. RML by definition is a “a generic mapping language, based on and extending” the Relational data base to Resource description framework Mapping Language (R2RML) standard; see page 41, 2nd paragraph - software layer on top of the RML adds a number of convenient features. First, the user can specify a folder instead of only a single file at a time for the transformation. Second, the URI templates need to be set only once and do not need to be manually exchanged each time. Third, it allows the user to easily change the target ontology. And finally, it encapsulates the complexity of RML into simple command line calls. As an engine for the RML transformations, we decided to use RMLMapper5 as it offers a command line as well as a library interface which enables us to change to a different architecture in the future without changing the technology behind the transformation).
It would be obvious to combine Gupta and Makhija and Kamath for the same reasons as in claim 1 above. Gupta, Makhija, Kamath, and Bachhofner are analogous art as they are directed to business process workflows with tasks for people (see Gupta Abstract, FIG. 4, par 80; Makhija Abstract, see par 52, 86, 104, FIG. 2A-2F – approvals/tasks with user intervention; Kamath Abstract, par 35; Bachhofner, page 34, 1st paragraph; page 38, Section 4.1). Gupta discloses that data representing a process that is to be automated is stored using a structured format such as BPMN (See par 64). Gupta discloses having a knowledge graph 120 using entities, attributes, and relationships extracted by a process miner (See FIG. 1) (see par 66) and that its robotic process automation system that creates decision models is trained on domain knowledge (See par 119). Makhija discloses having a workflow knowledge database that includes building model-driven flows incorporating application process within supply chain (See par 74). Kamath discloses that “ A business process management (BPM) engine, or workflow engine, can be used to design and implement business execution actions.” Bachhofner improves upon Gupta and Makhija and Kamath by using triples with knowledge graphs. One of ordinary skill in the art would be motivated to further include triples with knowledge graphs to efficiently improve upon the customization for workflows in BPMN in Gupta and the data modeling done through template definitions in Makhija (See par 56).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for having business processes using knowledge graphs that are customized in Gupta (See Abstract, par 64, 84-85, FIG. 3), to further include templates for customization in Makhija, selecting appropriate approval path for a workflow as in Kamath, and to further include triples with knowledge graphs as disclosed in Bachhofner, 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 and there is a reasonable expectation of success.
Response to Arguments
Applicant's arguments filed 10/31/25 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
With regards to 101, Applicant argues that the claim is “maintaining the integrity of a complex graph data structure by using data from an executed workflow to identify and rectify specific data omissions” and is tied to technical operation of a computerized data governance system. Remarks, pages 9-10. In response, Examiner respectfully disagrees. First, claim 1 does not require a computer for each step. Second, the “integrity” in the specification appears to be related to governance/policies [see Applicant’s 0045-0046], which would be part of the abstract idea; however, it is not helpful as this is not even required by the claim. Third, as explained in the revised rejection in response to the amendment, the “omission” and assigning ownership is viewed as assigning ownership/responsibility for processes/tasks, which is part of the abstract idea.
Applicant further argues that the claim is “specific, automated, and technical data remediation process performed by a computer on a complex data structure” and is tied to technical operation of a computerized data governance system. Remarks, page 10. In response, Examiner respectfully disagrees. First, claim 1 does not require a computer. Independent claim 11 does require a computer, but is viewed as MPEP 2106.05f (apply it [abstract idea] on a computer). Second, it is unclear how the data structure is viewed as “complex” nor how the remediation process is a “technical solution.” Rather, as explained in the revised rejection above, it is recommending/assigning a person be responsible or have ownership. This is part of the abstract idea of certain methods of organizing human activity and having user fulfill different roles and follow rules/instructions.
Applicant then argues that the graph data is “complex data structures”, and that a human mind is not equipped for “potentially including millions of data points”. Remarks, page 11. In response, Examiner respectfully disagrees. First, the claims do not require “complex.” Second, the claims do not require “millions” of data points. Third, arguing what is or isn’t in the “human mind” is for the abstract idea grouping of “mental processes.” See MPEP 2106.04(a). However, here the abstract idea grouping is “certain methods of organizing human activity.” Even if it was, Examiner notes “examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept.“ See MPEP 2106.04(a)(2)(III)(C).
Applicant then makes similar arguments on page 12 related to “practical application”, but similar issues as above occur, and the arguments are not persuasive. With regards to Applicant’s arguments that the claim is “specific,” Examiner notes eligibility based on 101 is not simply whether any “specific” limitations are recited in the claim – it needs to be a particular solution to “improve a computer or other technology.” See - McRo, as explained in MPEP 2106.05(a)(II)(“Improvements to Any Other Technology of Technical Field”), had a specific way to solve the problem of producing accurate and realistic lip synchronization and facial expressions in animated characters. As stated in MPEP 2106.05(a)(I)(“Improvement to Computer Functionality”),
in computer-related technologies, the examiner should determine whether the claim purports to improve computer capabilities or, instead, invokes computers merely as a tool. Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336, 118 USPQ2d 1684, 1689 (Fed. Cir. 2016).” See MPEP 2106.05(a)(I).
Applicant then argues that “creating or updating a triple in a triple store” to link a data asset node to a user account node” improves the “quality and integrity of the graph data.” Remarks, page 14. Examiner respectfully disagrees. This appears to be in reference to claim 8. However, the claim does not tie the triples into task assignment or delegating ownership as alleged; having a compliance aspect [not claimed, so not sure what Applicant wishes to refer to], appears to be related to just checking if each task/data item is assigned to a responsible user. The current claims are not viewed as having a technical solution as a result of just making sure that each data/task is assigned/owned by a person.
Applicant then argues that the claim is similar to Desjardins as it is “increasing data reliability, ensuring compliance with governance policies, and reducing the need for manual data stewardship.” Remarks, page 14. Examiner respectfully disagrees. First, claim 1 does not even require a computer in most limitations. Second, independent claim 11 does require a computer, but is viewed as “apply it [abstract idea] on a computer.” Mere presence of a computer alone still does not make a claim eligible, even after Desjardins. Third, Desjardins was explaining a technical improvement in machine learning, which is not similar to the situation here. See MPEP 2106.04(d)(1) “Conversely, if the specification explicitly sets forth an improvement only in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine that the claim improves technology or a technical field.” Here, the computer is used to assign ownership/responsibility to a user for a business process. There are no details explaining how a specific user account is chosen. The arguments are not persuasive with the current claim set.
The 103 arguments are moot in view of the new rejections necessitated by the amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619