Prosecution Insights
Last updated: July 17, 2026
Application No. 18/429,233

EXTENDED FEATURES AND FUNCTIONS FOR MOBILE APPLICATIONS AND THEIR USER INTERFACES

Non-Final OA §101§102
Filed
Jan 31, 2024
Examiner
PADUA, NICO LAUREN
Art Unit
3626
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
NCR Voyix Corporation
OA Round
3 (Non-Final)
13%
Grant Probability
At Risk
3-4
OA Rounds
5m
Est. Remaining
34%
With Interview

Examiner Intelligence

Grants only 13% of cases
13%
Career Allowance Rate
5 granted / 39 resolved
-39.2% vs TC avg
Strong +22% interview lift
Without
With
+21.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
32 currently pending
Career history
88
Total Applications
across all art units

Statute-Specific Performance

§101
19.8%
-20.2% vs TC avg
§103
66.7%
+26.7% vs TC avg
§102
11.6%
-28.4% vs TC avg
§112
1.0%
-39.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 39 resolved cases

Office Action

§101 §102
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 . Status of Claims This non-final rejection is in response to claims filed on 02/19/2026. Claims 1, 14, and 19 are amended. Claims 9-10, 17-18, and 20 are cancelled. Claims 1-8, 11-16, and 19 are currently pending and are examined herein. Continued Examination Under 37 CFR 1.114 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 02/19/2026 has been entered. Priority The effective filing date of the application is the filing date of the present disclosure which is 01/31/2024. 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-8, 11-16, and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1: Is the claim to a process, machine, manufacture or composition of matter? Claims 1-8, 11-13, and 14-16 are to a method, which falls under “process.” Claim 19- recites A system, comprising: at least one server comprising a processor and a non-transitory computer-readable storage medium; the non-transitory computer-readable storage medium comprises executable instructions; and the executable instructions when executed on the processor cause the processor to perform operations. This is an apparatus claim which falls under at least “machine or manufacture.” Therefore, claims 1-8, 11-16, and 19 fall under at least one potentially eligible subject matter category and are to be further analyzed under step 2. Step 2a Prong 1: Is the claim reciting a Judicial Exception(A Law of Nature, a Natural Phenomenon (Product of Nature), or An Abstract Idea?) The claims under the broadest reasonable interpretation in light of the specification are analyzed herein. Representative claims 1, 14 and 19 are marked up, isolating the abstract idea from additional elements, wherein the abstract idea is in bold and the additional elements have been italicized as follows: Claim 1: A method, comprising: identifying a request to create a custom workflow automation responsive to a user selection within a user interface of an enterprise application; presenting [an input display] one or more interface screens within the user interface; receiving, via the one or more interface screens, user input indicative of a condition and a corresponding target action to be performed responsive to satisfaction of the condition; creating a custom automated workflow based on the condition and the corresponding target action by generating a control data structure that stores instructions for the custom automated workflow and providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise application via an application programming interface; and processing the custom automated workflow as an extension of functionality of the enterprise application by receiving events from one or more of a user device, an enterprise service, the enterprise application, and third-party applications, wherein the events are associated with a user and used to manage the custom workflow automation, and wherein processing further includes evaluating the events against the condition of the custom automated workflow to determine when to process the corresponding target action. Claim 14: A method, comprising: integrating a workflow into a user interface of an enterprise application associated with an enterprise service by enhancing the enterprise application and its user interface to include an option to create the workflow, wherein when the workflow is selected by a user, the enterprise application passes session control to an integration manager; initiating the workflow during a user session responsive to a user selection of a selectable option to create a custom automated workflow, wherein the selectable option is presented within the user interface; obtaining, from the workflow, user input for creating the custom automated workflow; and processing the custom automated workflow to provide functionality that is unavailable from the enterprise service and the enterprise application without integration of the workflow by instructing the enterprise service and the enterprise application to report predefined events associated with the custom automated workflow, and providing event types for the predefined events to the enterprise service and the enterprise application as one or more of geo-location events, account events, transaction events, date events, and time events associated with a user. Claim 19: A system, comprising: at least one server comprising a processor and a non-transitory computer-readable storage medium; the non-transitory computer-readable storage medium comprises executable instructions; and the executable instructions when executed on the processor cause the processor to perform operations comprising: interacting with a user interface of an enterprise application associated with an enterprise service to provide a workflow that extends functionality of the enterprise application and enterprise service; defining a custom workflow that supports extended functionality while processing the workflow during a user session between a user and the enterprise service based on input received from the user via interaction with the workflow by storing conditions and target actions defined by the user during the user session through interaction with interface screens in a control data structure as a conditional processing flow, wherein the conditions are provided back to the enterprise service through an application programming interface; and providing the extended functionality by processing the custom workflow using events reported by the enterprise application and the enterprise service, wherein the events are used to evaluate at least one user-specified condition defined in the custom workflow and wherein the executable instructions are provided as a cloud service to the enterprise application and the enterprise service. When evaluating the bolded limitations of the claims under the broadest reasonable interpretation in light of the specification, it is clear that representative claims 1, 14, and 19 are a recitation to the abstract idea category of “certain methods of organizing human activity” outlined in MPEP 2106.05(a)(2). More specifically, the present claims fall under the sub-grouping “managing personal behavior or relationships or interactions between people” which include social activities, teaching, and following rules or instructions. The claims recite the creation of a user selected workflow on an enterprise service(such as a bank), and providing functionality of performing a target action upon the condition of an occurrence. In view of the bolded claims alone, this is an example of setting forth rules or instructions in order to manage the behaviors or interactions of individuals, since it is a delegation of tasks. In view of the specification it is also a fundamental economic practice or principle and a commercial or legal interaction in that it recites banking operations, which is a longstanding commercial practice. The specification [0012-0013] states, “[0012]Enterprises provide a variety of services to their customers/users via mobile applications. This is particularly the case for mobile banking customers who utilize mobile banking applications to perform financial transactions or other mobile banking operations such as transferring funds or making bill payments. [0013] The framework permits a customer or user to set up conditional operation processing flows within the user interfaces of the mobile applications using, for example, a graphical user interface (GUI). The processing flows are assigned one or more trigger actions via the GUI.” Even when considering the amended limitations of claim 1, “by generating a control data structure that stores instructions for the custom workflow and providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise,” the generating of a control data structure, in its broadest reasonable interpretation covers any data that represents a set of instructions for a workflow, which are still examples of “certain methods of organizing human activity.” It is no more than a set of rules or instructions to manage personal behavior, especially when the scope of the claims merely recite “providing at least a portion of the control data structure to at least one of an enterprise service,” which is no more than a set of instructions provided to an enterprise (such as a business or a bank). The examiner notes that while some of the claimed interactions may require a computer, MPEP 2106.04(a)(2)(II) states, “Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the "certain methods of organizing human activity" grouping.” Therefore, even when considering this claim with the rest of amended claim 1, the claims still recite an abstract idea under “certain methods of organizing human activity.” Similarly, amended claim 14 merely adds the steps of “include an option to create the workflow,” “wherein when the workflow is selected by a user, the enterprise passes session control to an integration manager;” which still fall within the scope of “certain methods of organizing human activity,” because providing an option to create the workflow is still managing interactions between a user and a computer. Furthermore, the crux of the workflow step is that when a workflow is selected by a user, the enterprise passes session control to an integration manager, which is recited broadly enough to encompass providing permissions to a user, which is not necessarily limited to computer implementation. While the broadest reasonable interpretation of the limitation is read in view of the specification, limitations in the specification are not read into the claims unless they are explicitly recited. Therefore, even when considering this claim with the rest of amended claim 14, the claims still recite an abstract idea under “certain methods of organizing human activity.” For purposes of compact prosecution, the enterprise application passes session control to an integration manager is also evaluated as an additional element in Prong 2. Similarly, claim 19 merely adds “by storing conditions and target actions defined by the user during the user session through interaction with interface screens in a control data structure as a conditional processing flow, wherein the conditions are provided back to the enterprise service”, which still fall under “certain methods of organizing human activity,” because a user is still defining the conditions and target actions in a control data structure and relaying the information to an enterprise service, without specifically limiting how the steps are supposed to be carried out. The considerations that these interactions are between a user and a computer (interface screen) does not preclude the claims from reciting an abstract idea. Therefore, even when considering this claim with the rest of amended claim 19, the claims still recite an abstract idea under “certain methods of organizing human activity.” Therefore, it is clear that claim limitations such as “custom workflow,” and “target actions” merely indicate the performance of banking operations. Therefore, the claims recite an abstract idea and are be further analyzed under Prong 2. Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? Claims 1, 14, and 19 recite the following additional elements: - custom workflow automation/ custom automated workflow in claims 1, 14 - presenting one or more interface screens within the user interface/user interface in claims 1, 14, 19 - defined by the user during the user session through interaction with interface screens in claim 19 - providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise application via an application programming interface in claim 1 -provided back to the enterprise service through an application programming interface in claim 19 -enterprise application in claims 1, 14, 19 -A system, comprising: at least one server comprising a processor and a non-transitory computer-readable storage medium; the non-transitory computer-readable storage medium comprises executable instructions; and the executable instructions when executed on the processor cause the processor to perform operations comprising in claim 19 - a user device in claim 1 - third-party applications, in claim 1 - cloud service in claim 19 - enhancing the enterprise application and its user interface in claim 14 - the enterprise application passes session control to an integration manager; in claim 14 The additional elements listed above, when considered individually and in combination with the claim as a whole, no more than a recitation of the words “apply it” (or an equivalent) or mere instructions to implement an abstract idea or other exception on generic computing components as outlined in MPEP 2106.05(f). In this case, the abstract idea of “the creation of a user selected workflow on an enterprise service(such as a bank), and providing functionality of performing a target action upon the condition of an occurrence” is merely instructed to be performed on generic computing components such as a user device, server, non-transitory computer readable medium, user interfaces and processor. Furthermore, limiting the custom workflow to be “automated” is also merely an indication that it is to be using a computer, which does not meaningfully limit the claims. It is clear in at least paragraph [0049] that the automation is a result of applying the abstract idea to a computer, since paragraph [0049] recites performing the methods as executable instructions programmed on a computer. The additional elements of using a user interface to receive and display data associated with the abstract idea, is merely an example of generally linking the abstract idea to a particular technological environment or field of use as outlined in MPEP 2106.05(h). User interfaces are recited so generally that they do not meaningfully limit the abstract idea. Furthermore, the recitation of an enterprise application is also an example of generally linking the abstract idea to a particular technological environment, in this case to “enterprise applications.” This also applies to “third-party applications” which are still a general link. As stated in [0048] the enterprise service is a financial institution, and the enterprise application is a mobile banking application, therefore the additional elements are merely generally linking the abstract idea of banking to the technological environment of mobile applications. Regarding Amended Claim 1: The additional element of providing a control data structure to an enterprise application via an application programming interface, is an “apply it” level element because it is no more than mere instructions to apply the abstract idea on a generic computer. Providing a control data structure via “an application programming interface,” does not limit the claims as it merely claims a transmission of information using general purpose computing, without specifically limiting how API’s send the information. Nor do the claims provide an improvement to how API’s interact with enterprise applications. While the specification may provide more information on how the API specifically interacts with the enterprise applications, the scope of the claims must reflect the purported improvement in order for the claims to be eligible. Therefore, amended claim 1 is directed to an abstract idea because even when considering the additional elements individually or as a combination, they fail to integrate the abstract idea into a practical application. Regarding Amended Claim 14: Furthermore, merely “enhancing the enterprise application and its user interface,” by enabling the enterprise application to pass “session control to an integration manager,” does not integrate the abstract idea into a practical application because it is merely “sets forth an improvement but 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 the claim improves technology.” (MPEP 2106.05(a)). Furthermore, enabling the enterprise application to pass session control to an integration manager is still merely an “apply it” level element because it is claimed at such a high level of generality because they recite no more than an idea of a solution. Similar examples under MPEP 2106.05(f) include, “i. Remotely accessing user-specific information through a mobile interface and pointers to retrieve the information without any description of how the mobile interface and pointers accomplish the result of retrieving previously inaccessible information, Intellectual Ventures v. Erie Indem. Co., 850 F.3d 1315, 1331, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017);” Similarly, the claims cause the enterprise application to pass session control to an integration manager, but does not specifically entail how the session control is passed, and it is not clear what the integration manager does with the session control, since the remaining steps are not necessarily limited to be performed by the integration manager. Therefore, as it is claimed, it cannot possibly be an improvement to computer functionality because it merely claims every mode of passing session control to any integration manager. Therefore, amended claim 14 is directed to an abstract idea because even when considering the additional elements individually or as a combination, they fail to integrate the abstract idea into a practical application. Regarding Amended Claim 19: The additional elements of collecting information through “interface screens” is still a use of a device in its ordinary capacity to perform an economic task (an interface screen to collect data). Similarly, as stated in response to amended claim 1, merely using the “application programming interface” to provide information to an enterprise service is still “apply it” level element because it merely claims the idea of transmitting data using an API without any specific mechanisms or improvements to APIs. Furthermore, storing the instructions on a “cloud service” in claim 19 is also a general link because it merely indicates where the information is to be stored without meaningfully limiting the use of “cloud services” on the abstract idea. Even when considering the combination of elements in claim 19, “wherein the executable instructions are provided as a cloud service to the enterprise application and the enterprise service”, this is still a general link because it still recites broad interactions between the cloud service, application, and enterprise service in broad manner without meaningfully limitation. In addition, whether considered individually or as a combination, the additional elements do not integrate the abstract idea into a practical application. One of the considerations of whether they provide an integration is whether an improvement to a technology/technological environment/technical field of use has been made. Since the computing infrastructure recited is merely a generic computing infrastructure performing the abstract idea, and since no improvement to user interfaces or application programming has been made, the additional improvements fail to provide an improvement under MPEP 2106.05(a). Therefore, the additional elements, whether analyzed individually or an ordered combination fail to provide an integration into a practical application, and the claims are directed to an abstract idea. Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? Claims 1, 14, and 19 recite the following additional elements: - custom workflow automation/ custom automated workflow in claims 1, 14 - presenting one or more interface screens within the user interface/user interface in claims 1, 14, 19 - defined by the user during the user session through interaction with interface screens in claim 19 - providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise application via an application programming interface in claim 1 -provided back to the enterprise service through an application programming interface in claim 19 -enterprise application in claims 1, 14, 19 -A system, comprising: at least one server comprising a processor and a non-transitory computer-readable storage medium; the non-transitory computer-readable storage medium comprises executable instructions; and the executable instructions when executed on the processor cause the processor to perform operations comprising in claim 19 - a user device in claim 1 - third-party applications, in claim 1 - cloud service in claim 19 - enhancing the enterprise application and its user interface in claim 14 - the enterprise application passes session control to an integration manager; in claim 14 The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using generic computing components such as a server, user device, non-transitory computer readable medium, user interface screens, and processor to perform the abstract idea of “the creation of a user selected workflow on an enterprise service(such as a bank), and providing functionality of performing a target action upon the condition of an occurrence” amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Furthermore, limiting the abstract idea to be performed on an automatically, using a user interface, with a cloud service, using an API or on an application does not meaningfully limit the claim beyond generally linking the abstract idea to a particular technological environment or field of use and is equivalent to “apply it.” Accordingly, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Thus claims 1, 14, and 19 are not patent eligible because the claims are directed to an abstract without significantly more. Dependent claims 2-8, 11-13, 15, and 16 are also given the full two part analysis both individually and in combination with the claims they depend on herein: Claim 2 merely further limits the abstract idea by adding the steps of obtaining control of a user session with the enterprise application and remotely providing the one or more interface screens for presentation within the user interface. This is more of the same abstract idea because it merely recites the same steps of presenting data and controlling a user session. Furthermore, it is another example of generally linking the abstract idea to enterprise application, and user interface screens, performing more tasks well within the ordinary capacity of such application and user interfaces, including controlling a session, and remotely providing a data output. Therefore, whether analyzed individually or as an ordered combination, the additional elements fail to integrate the abstract idea into a practical application or provide significantly more. Therefore, the claims are still directed to an abstract idea without an inventive concept. Claims 3, 15, 16 further limit the abstract by adding steps associated with the format in which the content is displayed on the interface(container object), and the interaction with cloud-based services. This is more of the same abstract idea since it is merely performing data processing and data display steps of the abstract idea. Furthermore, the additional elements of a container object and cloud-based services are still examples of generally linking the abstract idea to the field of user interfaces and cloud-technology without providing specific implementation steps that would meaningfully limit their use on the claims. Therefore, whether analyzed individually or as an ordered combination, the additional elements fail to integrate the abstract idea into a practical application or provide significantly more. Therefore, the claims are still directed to an abstract idea without an inventive concept. Claim 4 merely further limit the abstract idea to by identifying the condition as geo-location based, account based, transaction based, date/time based. This is more of the same abstract idea since even when substituting this into the broader genus, the claims still read on the abstract idea of “certain methods of organizing human activity. Furthermore, there are no additional elements to consider therefore the claims are still directed to an abstract idea without significantly more. Claims 5, 13 merely further limit the abstract by limiting how the receiving step is performed, specifically through user input fields and selectable conditions. This is more of the same abstract idea since it is merely indicating how data collection towards performing the abstract idea is to be conducted. Furthermore, the input fields and selectable icons still do not provide enough specificity or technical improvements beyond merely generally linking the abstract idea to the field of user interface technology. Therefore, whether analyzed individually or as an ordered combination, the additional elements fail to integrate the abstract idea into a practical application or provide significantly more. Therefore, the claims are still directed to an abstract idea without an inventive concept. Claims 6, 7, and 8 further define the abstract idea by adding the steps of generating a control data structure, and providing a portion to the enterprise service or application. These are merely broadly stated data processing/transmission steps towards performing more of the same abstract idea, since “generating a control data structure” is not a specific implementation or algorithm. Furthermore, there are no additional elements to consider therefore the claims are still directed to an abstract idea without significantly more. Claims 11 and 12 merely further limit the abstract idea by specifying that the app interacts with enterprise services or third-party services during the processing. This is more of the same abstract idea since it merely indicates the other parties involved in the commercial or legal interactions, which are “certain methods of organizing human activity.” Furthermore, there are no additional elements to consider therefore the claims are still directed to an abstract idea without significantly more. Claim Rejections – 35 USC § 102 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-8, 11-16, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Parmar et al. (US 20230222419 A1) hereinafter Parmar. Regarding Claim 1: Parmar teaches: - A method, comprising: identifying a request to create a custom workflow automation responsive to a user selection within a user interface of an enterprise application; (Parmar [0052] In practice, the software technology disclosed herein may be implemented as a new software subsystem that is hosted by a computing platform operated by a financial institution, such as the computing platform 102 of FIG. 1. At a high level, this new software subsystem may provide a new service that enables a user to build a user-customized workflow related to one or more financial accounts associated with the user (which may leverage other services provided by the computing platform) and then deploys the user-defined workflow for automatic execution by the computing platform. [0074] As shown in FIG. 4, the example process 400 may begin at 402 with the custom workflows software subsystem 300 receiving an indication of a user request to create a customized workflow. For instance, a user may direct a client station 108 to access the “Custom Workflows” service provided by the custom workflows software subsystem 300 by opening a software application that facilitates interaction with the computing platform 102 (e.g., an operating system software, a web browser software, a mobile application, etc.) and navigating to a view for creating a customized workflow.) In view of the specification, an enterprise refers to a bank or financial institution, thereby satisfying the limitation above. -presenting one or more interface screens within the user interface; (Parmar [0075] In turn, at block 404, the custom workflows software subsystem 300 may cause the client station 108 to present the user interface for creating a user-customized workflow (e.g., by transmitting one or more instruction messages to the client station 108).) -receiving, via the one or more interface screens, user input indicative of a condition and a corresponding target action to be performed responsive to satisfaction of the condition; (Parmar [0076] In general, the user interface may serve to guide the user through a process of building a new user-customized workflow, which may involve (i) defining a set of information about one or more financial accounts associated with the user that is to serve as input for the new user-customized workflow, and (ii) defining at least one rule that comprises (a) at least one user-defined condition that is to be evaluated based on the user-defined set of information, and (b) at least one corresponding action that is to be carried out automatically by the computing platform if the at least one user-defined condition is satisfied.) -creating a custom automated workflow based on the condition and the corresponding target action by generating a control data structure that stores instructions for the custom automated workflow (Parmar [0088] After a user has finished providing inputs for the new user-customized workflow, the user may select an option within the user interface indicating that the user has finished building the new user-customized workflow and wishes to “save” that workflow. After the client station 108 has received the indication that the user has finished building the user-customized workflow, the client station 108 may transmit data that defines the user-customized workflow built by the user to the computing platform 102. [0090] In turn, at block 408, the custom workflows software subsystem 300 of the computing platform 102 may store a data representation of the user-customized workflow into the workflow data store 304. In practice, this data representation of the user-customized workflow may take any of various forms, one example of which may be a data record for storage within a relationship database. [0073] Further, it should be understood that, in practice, these functions of the custom workflows software subsystem 300 may be encoded in the form of program instructions that are executable by one or more processors of the computing platform 102. [0125] As shown in FIG. 6A, during the build process, the user may have provided inputs in the manner described above to define a new user-customized workflow titled “Workflow 1,” which may include a user-defined set of information that is to serve as input to the user-customized workflow and at least two user-defined rules. A representation of the data defining Workflow 1 may then be stored by the custom workflows software subsystem 300 in the workflow data store 304. ) Parmar’s workflow data store, which stores a data representation of instructions and rules to carry out the automated workflow falls within the broadest reasonable interpretation of the “control data structure” at least in view of [0025] which indicates that the control data structure is merely a store of “data indicative of the conditions and corresponding target actions.” - and providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise application via an application programming interface;(Parmar [0037] For example, the computing platform 102 may receive from a client station 108 via the API Gateway 106 a communication indicating a request on behalf of a user to receive an alert when a given activity within a given financial account occurs. The API Gateway 106 may then route that request to the software subsystem 104d, which may in turn perform functions in order to carry out the request and issue an alert to the user when the given activity within the given financial account occurs. [0052] In practice, the software technology disclosed herein may be implemented as a new software subsystem that is hosted by a computing platform operated by a financial institution, such as the computing platform 102 of FIG. 1. [0070] (ii) receiving, from the client station 108 via the network-accessible interface 308, data defining a given workflow that has been built by the user. [0089] At block 406 of FIG. 4, the custom workflows software subsystem 300 may then receive from the client station 108 the data defining the user-customized workflow that has been built by the user. In practice, this data defining the user-customized workflow may initially be received by the API gateway 106 of the computing platform 102, and may then be routed from the API gateway 106 to the custom workflows software subsystem 300. [0041] In practice, the software subsystems that are hosted by the computing platform 102 to deliver services provided by the financial institution to users may be implemented using any of a variety of software architecture styles and/or deployment patterns. As examples, the software subsystems that are hosted by the computing platform 102 may be implemented using a microservices architecture, a service-oriented architecture, and/or a serverless architecture, among various other possibilities, along with a container-based deployment pattern...) Since Parmar teaches that the computing platform is the enterprise service/enterprise application, users routing the customized workflow from the client devices (as in at least [0037], [0052], [0070], and [0089]) satisfies the limitation above. -processing the custom automated workflow as an extension of functionality of the enterprise application. (Parmar [0071] Further, in general, the workflow execution engine 306 may be configured to perform functions that facilitate execution of a user-customized workflow, examples of which may include (i) retrieving a given user-customized workflow that is stored in the workflow data store 304, (ii) beginning to execute the given user-customized workflow, which may involve iteratively performing functions of (a) obtaining a given snapshot of the user-defined set of information about one or more financial accounts (which may involve either obtaining a new snapshot or obtaining a prior snapshot has been stored for future access) and (b) applying the user-defined rule included in the user-customized workflow to the given snapshot of the user-defined set of information to determine whether at least one user-defined condition is satisfied and at least one corresponding action is to be carried out, and then (iii) while executing the given user-customized workflow, carrying out the at least one corresponding action each time an iteration results in a determination that the condition is satisfied (which may involve requesting at least one other software subsystem to perform an action related to the one or more financial accounts).) Parmar’s execution of the user-customized workflow teaches the processing step. - by receiving events from one or more of a user device, (Parmar [0113] Further, it should be understood that the iterations for the given user-customized workflow need not be carried out according to a fixed rate, and could instead be carried out according to event-based triggers. [0043] As noted above, the example network environment 100 may also include three example client stations 108 that may be utilized by customers of the financial institution to access and interact with the computing platform 102. In this respect, each client station 108 may include hardware components such as a processor, data storage, a communication interface, and user-interface components (or interfaces for connecting thereto), among other possible hardware components, as well as software that facilitates the client station’s ability to interact with the computing platform 102 in order to access the services hosted by the computing platform 102 (e.g., operating system software, web browser software, a mobile application, etc.). As representative examples, each client station 108 may take the form of a computing device such as a desktop computer, a laptop, a netbook, a tablet, a smartphone, or a personal digital assistant (PDA), among other possibilities.) -an enterprise service, the enterprise application, and (Parmar [0101] In line with the discussion above, the given user-customized workflow that is retrieved from the workflow data store may comprise (i) a user-defined set of information about one or more financial accounts associated with the user that is to serve as input for the user-customized workflow, which may be based at least in part on information provided by one or more other software subsystems hosted by the computing platform 102) -third-party applications, (Parmar [0104] For instance, the function of obtaining a given snapshot of the user-defined set of information about the one or more financial accounts associated with the user may take various forms, which may depend on the types of information included in the user-defined set of information for the given user-customized workflow and perhaps also on the state of the execution of the given user-customized workflow. In this respect, as one possible scenario, the user-defined set of information for the given user-customized workflow may include a type of information that is directly available from another software subsystem hosted by the computing platform 102 (including but not limited to a software subsystem that is configured to retrieve information from a third-party platform) and is “dynamic” in the sense that the information is expected to change over time, such as a balance amount for a financial account ) - wherein the events are associated with a user and used to manage the custom workflow automation, and (Parmar [0051] To address these and other problems, disclosed herein is new software technology that allows for the creation and execution of user-customized workflows that automate actions related to one or more financial accounts associated with a user by applying user-defined rules to user-defined sets of information about the one or more financial accounts. In this way, the disclosed technology enables customers of a financial institution to interact with their financial accounts in a more targeted and personalized way. [0058] For example, if the user-defined set of information comprises a balance amount for a financial account, such information may be provided directly by the third software subsystem 104c, whereas if the user-defined set of information comprises total or net spend for a financial account during a given period of time, such information may need to be calculated by custom workflows software subsystem 104x based on transactions information provided by one or more other software subsystems (e.g., the second software subsystem). Many other examples are well. [0059] Turning to the at least one user-defined condition that is to be evaluated based on the user-defined set of information, in general, each such condition may take the form of a logical expression that can be evaluated either as true (e.g., the condition is satisfied) or false (e.g., the condition is not satisfied),) Parmar’s user defined sets of information are mapped to events associated with the users used to manage the custom workflow because it refers to the status of information regarding the financial events of a user, in order to determine the status of a condition in the custom workflow. - wherein processing further includes evaluating the events against the condition of the custom automated workflow to determine when to process the corresponding target action. (Parmar [0058] For example, if the user-defined set of information comprises a balance amount for a financial account, such information may be provided directly by the third software subsystem 104c, whereas if the user-defined set of information comprises total or net spend for a financial account during a given period of time, such information may need to be calculated by custom workflows software subsystem 104x based on transactions information provided by one or more other software subsystems (e.g., the second software subsystem). Many other examples are well. [0059] Turning to the at least one user-defined condition that is to be evaluated based on the user-defined set of information, in general, each such condition may take the form of a logical expression that can be evaluated either as true (e.g., the condition is satisfied) or false (e.g., the condition is not satisfied), [0071] (b) applying the user-defined rule included in the user-customized workflow to the given snapshot of the user-defined set of information to determine whether at least one user-defined condition is satisfied and at least one corresponding action is to be carried out, and then (iii) while executing the given user-customized workflow, carrying out the at least one corresponding action each time an iteration results in a determination that the condition is satisfied (which may involve requesting at least one other software subsystem to perform an action related to the one or more financial accounts). ) Regarding Claim 2: Parmar teaches: The method of claim 1, -wherein presenting further includes obtaining control of a user session with the enterprise application and (Parmar[0034] As one example, the computing platform 102 may include a first software subsystem 104a for providing a “Money Transfer” service that generally functions to facilitate a transfer of funds from one financial account to another financial account. The computing platform 102 may call upon, or run, the software subsystem 104a in order to provide the “Money Transfer” service to a given user. For example, the computing platform 102 may receive from a client station 108 via the API Gateway 106 a communication indicating a request on behalf of a user to transfer a given amount of funds from the user’s checking account to the user’s savings account. The API Gateway 106 may then route that request to the software subsystem 104a, which may in turn perform functions in order to carry out the request and cause the transfer to be executed. [0118] At block 506, while executing the given user-customized workflow, the workflow execution engine 306 may at some point (e.g., during a given iteration) determine that at least one user-defined condition is satisfied and then responsively cause the at least one corresponding action to be carried out. In line with the discussion above, examples of an action that may be carried out by the computing platform 102 may include, as some non-limiting possibilities, implementing a funds transfer from a first financial account to a second financial account, issuing an alert to be provided to the user, implementing a payment from a financial account to a third party (e.g., a utility provider, a bill payee), and/or generating a report to be provided to the user, among other possibilities. Further, the function of causing the at least one corresponding action to be carried out may take various forms, and at least for some types of actions, may involve making a call to one or more other subsystems of the computing platform 102 that are configured to perform functions for carrying out the action.) The BRI of the limitation is any transfer of control over the enterprise application from the user to another separate system of the platform. In present specification [0024], session control is given to the integration manager in order to perform the functions of the workflow to perform calls. In Parmar, the computing platform calls upon a software subsystem to carry out the request. In both cases, control is given to the workflow execution engine/workflow integration manager. -remotely providing the one or more interface screens for presentation within the user interface.(Parmar [0096] For instance, a user (which may or may not be the same as the user who created the original given workflow) may direct a client station (which may be different from a client station that was accessed at the time of creating the workflow) to access the service provided by the custom workflows software subsystem 300. The user may then navigate to an interface view for viewing a status of the given workflow. In turn, the computing platform may cause the user’s client station to present one or more interface views that include information about the status of the given workflow. [0118] and/or generating a report to be provided to the user, among other possibilities See also [0036-0039] Api Gateway).In Parmar, a user which may a different user from a different client station can access the screens for the status of the workflow. Giving “remote” the BRI of providing the information from a separate/distant site, the computing platform is remotely presenting the interface views to the user at the different client station. Regarding Claim 3: Parmar teaches: The method of claim 1, -wherein presenting further includes initiating a container object from the user interface and (Parmar [0093] The user may then navigate to an interface view for viewing and/or modifying the given workflow. In turn, the computing platform may cause the user’s client station to present an interface view that includes a visualization of the given workflow. Additionally, the view may include one or more options that enable the user to modify the given workflow. [0107] . In such a scenario, the function of obtaining a given snapshot of information of that type that is carried out during the first iteration may involve (i) requesting and receiving a new snapshot of information from each of one or more other software subsystems (e.g., by calling the service provided by the software subsystem via its API) In view of present specification [0024-0026], the BRI of “initiating a container object” includes performing a call to receive the information to be displayed. In Parmar, “calling the service provided to receive a snapshot of information” satisfies this limitation. -presenting the one or more interface screens within the container object.(Parmar [0041] As examples, the software subsystems that are hosted by the computing platform 102 may be implemented using a microservices architecture, a service-oriented architecture, and/or a serverless architecture, among various other possibilities, along with a container-based deployment pattern, a virtual-machine-based deployment pattern, and/or a Lambda-function-based deployment pattern, among other possibilities. [0075] In turn, at block 404, the custom workflows software subsystem 300 may cause the client station 108 to present the user interface for creating a user-customized workflow (e.g., by transmitting one or more instruction messages to the client station 108). [0096] In turn, the computing platform may cause the user’s client station to present one or more interface views that include information about the status of the given workflow. ) Since Parmar teaches a “container-based deployment pattern” and performs the calls to receive information being displayed, in view of Fig. 6A and 6B, the presenting of interface screens includes presenting within container objects. Regarding Claim 4: Parmar teaches: The method of claim 1, -wherein receiving further includes identifying the condition as one or more of an account-based condition, a transaction-based condition, (Parmar [0008] Still further, the data defining the given workflow may take various forms, and in some example embodiments, may comprise... In this respect, as examples, the at least one given type of information may comprise one of (i) information about an account balance, (ii) information about one or more transactions, or (iii) information about one or more due payments, among other possibilities... (i) a threshold amount of money, (ii) a minimum balance amount, or (iii) an occurrence of a given type of transaction, among other possibilities.) -a date-based condition, and a time-based condition. (Parmar [0047] ... such as the computing platform 102, may allow users to schedule tasks that are to be carried out automatically by the computing platform. For example, a user may be able to schedule a transfer ... on a given date or schedule a payment to a given payee that is to be carried out automatically by the computing platform on a given date.) Regarding Claim 5: Parmar teaches: The method of claim 1, -wherein receiving further includes providing input fields and selectable conditions and (Parmar [0125] The example shown in FIGS. 6A-6B depicts an implementation where a user may have built a user-customized workflow... As shown in FIG. 6A, during the build process, the user may have provided inputs in the manner described above to define a new user-customized workflow titled “Workflow 1,” which may include a user-defined set of information that is to serve as input to the user-customized workflow and at least two user-defined rules. [0066] The configuration information for that condition may include (i) a first threshold percentage (e.g., 70%), (ii) a second threshold percentage (e.g., 80%), and (iii) a third threshold percentage (e.g., 90%). [0084] Further yet, in order to facilitate the user’s task of defining at least one rule for the new user-customized workflow, the user interface may include a view that (i) presents a list of one or more available actions that may be carried out by the computing platform 102 and (ii) enables the user to select one or more of the actions to add to the new user-customized workflow. [0093] For example, the view may include options to modify the user-defined set of information, the configuration information, one or more conditions, and/or one or more corresponding actions that are included in the given workflow. The options to modify the given workflow may include options to edit, re-arrange, add, and/or remove one or more components of the workflow, as well as an option to delete the given workflow.) The excerpts above are various examples of input fields and selectable conditions, including an option to choose the threshold percent, and options to modify the workflow. -target actions within the one or more interface screens to obtain the user input. (Parmar [0085] In practice, the list of available actions may be presented to the user for selection in various ways. As one example, the list of available actions may be presented to the user in the form of a drop-down list from which one or more of the available actions may be selected. As another example, the list of available actions may be presented to the user in the form of a list of selectable tiles corresponding to the actions that can each be dragged and dropped into a selection panel. The list of available actions may be presented to the user for selection in other manners as well.) Regarding Claim 6: Parmar teaches: The method of claim 1, -wherein creating further includes generating a control data structure that defines the custom automated workflow. (Parmar [0090] In turn, at block 408, the custom workflows software subsystem 300 of the computing platform 102 may store a data representation of the user-customized workflow into the workflow data store 304. In practice, this data representation of the user-customized workflow may take any of various forms, one example of which may be a data record for storage within a relationship database. Also see [0128-0129] Workflow execution engine.) The broadest reasonable interpretation of “control data structure” in view of both the plain meaning in the art, and the specification, refers to any data structure that stores the instructions for the custom automated workflow. Therefore, the workflow data store which holds the data representation of the user-customized workflow (and thereby holds the workflow execution engine) satisfies this limitation. Regarding Claim 7: Parmar teaches: The method of claim 6, -wherein generating further includes providing at least a portion of the control data structure to an enterprise service. (Parmar [0030] In this respect, a financial institution’s computing platform may host a variety of different software subsystems that each functions to provide a certain type of service related to a financial account associated with a customer via a network-accessible interface such as an application programming interface (API) that can be accessed by the customer’s computer, smartphone, tablet, or the like. [0052] In practice, the software technology disclosed herein may be implemented as a new software subsystem that is hosted by a computing platform operated by a financial institution, such as the computing platform 102 of FIG. 1... (ii) automatically carrying out one or more actions related to the one or more financial accounts associated with the user (e.g., by calling one or more other services provided by the computing platform). [0089] At block 406 of FIG. 4, the custom workflows software subsystem 300 may then receive from the client station 108 the data defining the user-customized workflow that has been built by the user. In practice, this data defining the user-customized workflow may initially be received by the API gateway 106 of the computing platform 102, and may then be routed from the API gateway 106 to the custom workflows software subsystem 300. However, other examples are possible as well.) With the software system being operated by the financial institution, and data being called by the system in [0052], then it is clear that at least a portion of the control data structure is provided to the enterprise service. Regarding Claim 8: Parmar teaches: The method of claim 6, -wherein providing further includes providing at least a portion of the control data structure to an enterprise application. (Parmar [0002] In this respect, a financial institution’s computing platform may host a variety of different software subsystems that each functions to provide a particular type of service related to a financial account associated with a customer via a network-accessible interface such as an application programming interface (API) that can be accessed by a computing device, such as the customer’s computer, smartphone, or tablet (either directly or via an API gateway or the like). [0089] At block 406 of FIG. 4, the custom workflows software subsystem 300 may then receive from the client station 108 the data defining the user-customized workflow that has been built by the user. In practice, this data defining the user-customized workflow may initially be received by the API gateway 106 of the computing platform 102, and may then be routed from the API gateway 106 to the custom workflows software subsystem 300. However, other examples are possible as well. ) Regarding Claim 11: Parmar teaches: The method of claim 1, -wherein managing and processing further includes interacting with an enterprise service during the processing. (Parmar [0132] In the ways described herein, the disclosed software technology enables creation and execution of user-customized workflows that automate actions related to one or more financial accounts associated with a user by applying user-defined rules to user-defined sets of information about the one or more financial accounts, thereby allowing customers of a financial institution to interact with their financial accounts in a more targeted and personalized way.) Regarding Claim 12: Parmar teaches: The method of claim 11, -wherein managing and processing further includes interacting with third-party services used by the user during the processing. (Parmar [0063] As yet another example, configuration information for a payment type of action may comprise information identifying a third party that is to be paid and/or an amount that is to be paid. Many other examples are possible as well. [0105] As another possible scenario, the user-defined set of information for the given user-customized workflow may include a type of information that is directly available from another software subsystem hosted by the computing platform 102 (including but not limited to a software subsystem that is configured to retrieve information from a third-party platform)) Regarding Claim 13: Parmar teaches: The method of claim 1, -wherein the user input and the custom automated workflow includes one or more additional conditions and corresponding target actions. (Parmar [0067] The preceding examples demonstrate merely two specific ways that user-defined information, at least one user-defined condition, and at least one corresponding action may be used to create a user-customized workflow as described herein. It should be understood that many other ways of combining user-defined information, a condition(s), and a corresponding action(s) are possible. For instance, in either one of the preceding example workflows, one or more predicates may be added to each condition, one or more additional conditions may be added, and/or one or more additional corresponding actions may be added. Additionally, the user-defined information, condition, and corresponding action included in the two workflows described above may be combined into a single workflow. Many other examples are possible. ) Regarding Claim 14: Parmar teaches: A method, comprising: -integrating a workflow into a user interface of an enterprise application associated with an enterprise service; (Parmar [0074] As shown in FIG. 4, the example process 400 may begin at 402 with the custom workflows software subsystem 300 receiving an indication of a user request to create a customized workflow. For instance, a user may direct a client station 108 to access the “Custom Workflows” service provided by the custom workflows software subsystem 300 by opening a software application that facilitates interaction with the computing platform 102 (e.g., an operating system software, a web browser software, a mobile application, etc.) and navigating to a view for creating a customized workflow. [0075] In turn, at block 404, the custom workflows software subsystem 300 may cause the client station 108 to present the user interface for creating a user-customized workflow (e.g., by transmitting one or more instruction messages to the client station 108). [0076] In general, the user interface may serve to guide the user through a process of building a new user-customized workflow, [0077] In order to facilitate the user’s task of defining the set of information that is to serve as input for the new user-customized workflow, the user interface may include a view that (i) presents a list of available types of information that may be obtained about one or more financial accounts associated with the user and (ii) enables the user to select one or more of the types of information that are to serve as input for the new user-customized workflow. In line with the discussion above, these available types of information that are presented as options to the user may take various forms, examples of which may include information about an account balance of a financial account, information about transactions within a financial account (e.g., transaction-level and/or summary information about occurrences of one or more specific types of transactions), information regarding a credit score, and/or information regarding upcoming payments that are due (e.g., a mortgage payment, a bill payment, etc.), among other possibilities.) The broadest reasonable interpretation (BRI) of the limitation above, in view of the specification, is any step where a workflow is displayed and can be interacted with, on a user interface of a banking application for a bank. Therefore, the excerpts above which guides the user through workflow steps teaches the limitation. -by enhancing the enterprise application and its user interface to an include an option to create the workflow,(Parmar [0070] In general, the workflow creation engine 302 may be configured to perform functions that facilitate creation of a user-customized workflow, examples of which may include (i) causing a client station 108 associated with a user to present an interface for building such a workflow via the network-accessible interface 308, [0132] In the ways described herein, the disclosed software technology enables creation and execution of user-customized workflows that automate actions related to one or more financial accounts associated with a user by applying user-defined rules to user-defined sets of information about the one or more financial accounts, thereby allowing customers of a financial institution to interact with their financial accounts in a more targeted and personalized way.) -wherein when the workflow is selected by a user, the enterprise application passes session control to an integration manager; (Parmar [0118] At block 506, while executing the given user-customized workflow, the workflow execution engine 306 may at some point (e.g., during a given iteration) determine that at least one user-defined condition is satisfied and then responsively cause the at least one corresponding action to be carried out. In line with the discussion above, examples of an action that may be carried out by the computing platform 102 may include, as some non-limiting possibilities, implementing a funds transfer from a first financial account to a second financial account, issuing an alert to be provided to the user, implementing a payment from a financial account to a third party (e.g., a utility provider, a bill payee), and/or generating a report to be provided to the user, among other possibilities. Further, the function of causing the at least one corresponding action to be carried out may take various forms, and at least for some types of actions, may involve making a call to one or more other subsystems of the computing platform 102 that are configured to perform functions for carrying out the action. For example, if the action to be carried out is a funds transfer from a first financial account to a second financial account, the function of carrying out this action may involve sending a request to the first software system 104a to implement the funds transfer. Many other examples are possible as well. [0104] In this respect, as one possible scenario, the user-defined set of information for the given user-customized workflow may include a type of information that is directly available from another software subsystem hosted by the computing platform 102 (including but not limited to a software subsystem that is configured to retrieve information from a third-party platform) and is “dynamic” in the sense that the information is expected to change over time, such as a balance amount for a financial account. In such a scenario, the function of obtaining a given snapshot of information of that type that is carried out during each iteration may involve requesting a new snapshot of the information of that type from the other software subsystem (e.g., by calling the service provided by the software subsystem via its API). For example, if the user-defined set of information comprises a balance amount for a financial account, the function of obtaining a given snapshot of information of that type that is carried out during each iteration may involve requesting and receiving a new snapshot of the account balance information from the third software subsystem 104c that provides the service for determining an account balance.)) The integration manager in view of the instant specification does not have a specific definition set forth by the applicant, but is interpreted given its broadest reasonable interpretation in view of the specification to include the features of “initiating a call to a third-party service, or instructing enterprise service to report when a given condition is satisfied, or to initiate a corresponding target action” (0026). Therefore, Parmar’s workflow engine, which has the feature of calling external services via API in [0104], satisfies the “integration manager.” -initiating the workflow during a user session responsive to a user selection of a selectable option to create a custom automated workflow, (Parmar [0088] After a user has finished providing inputs for the new user-customized workflow, the user may select an option within the user interface indicating that the user has finished building the new user-customized workflow and wishes to “save” that workflow. After the client station 108 has received the indication that the user has finished building the user-customized workflow, the client station 108 may transmit data that defines the user-customized workflow built by the user to the computing platform 102. [0102] At block 504, after retrieving the data representation of the given user-customized workflow from the workflow data store 304, the workflow execution engine 306 may begin executing the given user-customized workflow. The function of executing the given user-customized workflow may take various forms.) The BRI of the limitation is that the workflow begins executing in response to a user selecting an option to create the workflow. In this case, this is mapped to the “save” option in Parmar’s workflow. -wherein the selectable option is presented within the user interface; (Parmar [0093] The user may then navigate to an interface view for viewing and/or modifying the given workflow. In turn, the computing platform may cause the user’s client station to present an interface view that includes a visualization of the given workflow. Additionally, the view may include one or more options that enable the user to modify the given workflow. For example, the view may include options to modify the user-defined set of information, the configuration information, one or more conditions, and/or one or more corresponding actions that are included in the given workflow. The options to modify the given workflow may include options to edit, re-arrange, add, and/or remove one or more components of the workflow, as well as an option to delete the given workflow, and may be presented to the user in various ways, including the ways described above with respect to the workflow creation engine 302 presenting one or more interface views for creating a user-customized workflow.) -obtaining, from the workflow, user input for creating the custom automated workflow; and (Parmar [0054] The user-customized workflows that may be created and executed in accordance with the present disclosure may take various forms, but in general, each such user-customized workflow may comprise (i) a user-defined set of information about one or more financial accounts associated with the user that is to serve as input for the user-customized workflow [0057] the user may specify the type of information along with certain configuration information that serves to further define the set of information that is to serve as input for the user-customized workflow... As one example, such configuration information may include an identifier of a particular financial account for which information is to be obtained (e.g., one of the financial accounts to which the user has access). As another example, such configuration information may include an indication of a particular transaction type for which information is to be obtained. As yet another example, such configuration information may include an identifier of a particular period of time for which information is to be obtained (e.g., over the course of a calendar month). Other examples are possible as we) -processing the custom automated workflow to provide functionality that is unavailable from the enterprise service and the enterprise application without integration of the workflow. (Parmar [0123] Advantageously, this functionality for executing a user-customized workflow in an iterative manner alleviates any burden from a user to repeatedly prompt the computing platform 102 to perform the workflow, among various other advantages of the disclosed technology. [0049] Further, given that existing technology limits a user to selecting from some limited set of predefined options for scheduled an automated task, such existing technology provides no ability for a user to build user-customized workflows for automating tasks—let alone user-customized workflows that automate tasks by applying user-customized rules to user-customized sets of account-related information for the user. For example, while existing technology may allow a user to schedule an automated transfer of a set amount to take place on a set date, existing technology provides no ability for a user to build a user-customized workflow for automating a transfer that iteratively applies a user-customized rule to a user-customized set of account-related information in order to dynamically determine whether to execute a transfer and/or what amount to transfer. Similar limitations exist with respect to other existing services that allow users to configure automated tasks.) - by instructing the enterprise service and the enterprise application to report predefined events associated with the custom automated workflow, and (Parmar [0012] The function of iteratively obtaining the given snapshot of the user-defined set of information about the one or more financial accounts associated with the user may take various forms, and in some example embodiments, may involve iteratively obtaining a given snapshot of information from one or more other network-accessible services hosted by the computing platform, which may either be used as the given snapshot of the user-defined set of information or may be used as a basis for deriving the given snapshot of the user-defined set of information. [0113] Further, it should be understood that the iterations for the given user-customized workflow need not be carried out according to a fixed rate, and could instead be carried out according to event-based triggers. For instance, in an implementation where the workflow execution engine 306 is configured to carry out the iterations for the given user-customized workflow according to a frequency that is defined based on information returned about occurrences of certain types of transactions, each reporting of a new transaction occurrence may cause a new iteration to be carried out for the user-customized workflow to determine if the at least one user-defined condition is satisfied based on the new transaction occurrence. [0120] ,,,“satisfied” state, and may then return to the original frequency after determining that the at least one condition is no longer in the “satisfied” state. For instance, if the given user-customized workflow includes a user-defined rule that requires the workflow execution engine 306 to determine whether an account balance is below a threshold and then issue an alert if the balance is below the threshold, the workflow execution engine 306 may perform iterations of the given user-customized workflow at an original frequency that is more continuous in nature (e.g., every 5 minutes). During an iteration where the workflow execution engine 306 determines that the account balance is below the threshold and the user-defined rule is thus satisfied,) Parmar’s platform which hosts the financial institution, and as a result the financial enterprise, reports on event-based triggers, such as predefined thresholds. - providing event types for the predefined events to the enterprise service and the enterprise application Parmar [0104] For instance, the function of obtaining a given snapshot of the user-defined set of information about the one or more financial accounts associated with the user may take various forms, which may depend on the types of information included in the user-defined set of information for the given user-customized workflow and perhaps also on the state of the execution of the given user-customized workflow. ) See Parmar’s “Types of information included” - as one or more of geo-location events, account events, (Parmar [0104] receiving a new snapshot of the account balance information from the third software subsystem 104c that provides the service for determining an account balance. [0120] For instance, if the given user-customized workflow includes a user-defined rule that requires the workflow execution engine 306 to determine whether an account balance is below a threshold and then issue an alert if the balance is below the threshold,) The limitation only requires “one or more” out of the list, thus satisfying the limitation with the inclusion of account events, though geo-location events are not necessarily explicitly taught. -transaction events, (Parmar [0126] As depicted in FIG. 6A, the user-defined set of information included in the Workflow 1 comprises (i) information about transactions within a given financial account (e.g., net spend)) -date events, and time events associated with the user. (Parmar [0114] As one possibility, the status information may include an indication of how long the given user-customized workflow has been executing, which may be represented in terms of a date/time when execution of the given user-customized workflow began and/or a running amount of execution time, among other examples.) Regarding Claim 15: Parmar teaches: The method of claim 14, -wherein integrating further includes integrating the workflow as a container object that presents interface screens to the user (Parmar [0041] In practice, the software subsystems that are hosted by the computing platform 102 to deliver services provided by the financial institution to users may be implemented using any of a variety of software architecture styles and/or deployment patterns. As examples, the software subsystems that are hosted by the computing platform 102 may be implemented using a microservices architecture, a service-oriented architecture, and/or a serverless architecture, among various other possibilities, along with a container-based deployment pattern, [0043] In this respect, each client station 108 may include hardware components such as a processor, data storage, a communication interface, and user-interface components (or interfaces for connecting thereto), among other possible hardware components, as well as software that facilitates the client station's ability to interact with the computing platform 102 in order to access the services hosted by the computing platform 102 [0070] In general, the workflow creation engine 302 may be configured to perform functions that facilitate creation of a user-customized workflow, examples of which may include (i) causing a client station 108 associated with a user to present an interface for building such a workflow via the network-accessible interface 308, (ii) receiving, from the client station 108 via the network-accessible interface 308.) -and that interacts with a cloud-based service.(Parmar [][0136] Communication interface 706 may be configured to facilitate wireless and/or wired communication with client stations (e.g., one or more client stations 108 of FIG. 1) and/or third-party computing platforms. Additionally, in an implementation where the computing platform 700 comprises a plurality of physical computing devices connected via a network, communication interface 706 may be configured to facilitate wireless and/or wired communication between these physical computing devices (e.g., between computing and storage clusters in a cloud network).) Regarding Claim 16: Parmar teaches: The method of claim 15, -wherein initiating further includes initiating the container object with a user context provided by the enterprise application for the user session.(Parmar [0032] As shown in FIG. 1, the computing platform 102 may comprise a set of software subsystems 104 that may each function to provide a respective type of service to users via a network-accessible interface such as an API, as well as an API gateway 106 that may function to receive and process an API-based request incoming from a client station 108, route the API-based request to one or more appropriate software subsystems, and then return information associated with the API-based request to the client station 108. [0035] For example, the computing platform 102 may receive from a client station 108 via the API Gateway 106 a communication indicating a request on behalf of a user to access information about all occurrences of a given type of transaction within a given time frame for a given financial account associated with the user. The API Gateway 106 may then route that request to the software subsystem 104b, which may in turn perform functions in order to carry out the request and return the information requested by the user so that it can be sent back to the client station 108. [0057] As one example, such configuration information may include an identifier of a particular financial account for which information is to be obtained (e.g., one of the financial accounts to which the user has access). As another example, such configuration information may include an indication of a particular transaction type for which information is to be obtained.) The BRI of the limitation above is that an API call is performed including identifier information and the particular function being requested (Present specification [0022] Enterprise mobile app 133 provides context for the API call for the user including a user account identifier... Integration manager 113 uses the context to render the subset of new interface screens to the user within the user session.) Regarding Claim 19: Parmar teaches: A system, comprising: at least one server comprising a processor and a non-transitory computer-readable storage medium; (Parmar [0042] Further, in practice, the computing platform 102 may generally comprise some set of physical computing resources (e.g., processors, data storage, etc.) that are configured to run the software subsystems discussed herein, among various other software subsystems that may be hosted and run by computing platform 102. As another possibility, the computing platform 102 may comprise “on-premises” computing resources of the financial institution that operates the example computing platform 102 (e.g., institution-owned servers). As yet another possibility, the example computing platform 102 may comprise a combination of cloud computing resources and on-premises computing resources. Other implementations of the computing platform 102 are possible as well.) -the non-transitory computer-readable storage medium comprises executable instructions; and the executable instructions when executed on the processor cause the processor to perform operations comprising: (Parmar [0135] In turn, data storage 704 may comprise one or more non-transitory computer-readable storage mediums that are collectively configured to store (i) program instructions that are executable by processor 702 such that computing platform 700 is configured to perform certain functions in connection with providing services for interacting with financial accounts, and (ii) data that may be received, derived, or otherwise stored, for example, in one or more databases, file systems, repositories, or the like, by computing platform 700, in connection with providing services for interacting with financial accounts.) -interacting with a user interface of an enterprise application associated with an enterprise service to provide a workflow that extends functionality of the enterprise application and enterprise service; (Parmar [0137] Although not shown, the computing platform 700 may additionally include or have an interface for connecting to one or more user-interface components that facilitate user interaction. [0048] In this respect, the existing technology for configuring such automated tasks is simplistic and offers very limited customizability of these automated tasks. For instance, existing technology for configuring automated tasks does not allow users to create their own user-customized tasks and instead typically requires a user to select from a set of available tasks that have been predefined by the financial institution. Thus, the scope of automated tasks that the user may schedule is restricted by the set of tasks that have been predefined by the financial institution. Tasks that fall outside of that limited scope may be unable to be automated and may instead need to be performed by the user manually or on an “on demand” basis as described above. [0051] To address these and other problems, disclosed herein is new software technology that allows for the creation and execution of user-customized workflows that automate actions related to one or more financial accounts associated with a user by applying user-defined rules to user-defined sets of information about the one or more financial accounts. In this way, the disclosed technology enables customers of a financial institution to interact with their financial accounts in a more targeted and personalized way.) -defining a custom workflow that supports the extended functionality while processing the workflow during a user session between a user and the enterprise service based on input received from the user via interaction with the workflow; (Parmar [0063] In practice, when defining the at least one action for the user-customized workflow, the user may specify the type of action along with certain configuration information that serves to further define the at least one action for the user-customized workflow. [0088] After a user has finished providing inputs for the new user-customized workflow, the user may select an option within the user interface indicating that the user has finished building the new user-customized workflow and wishes to “save” that workflow. After the client station 108 has received the indication that the user has finished building the user-customized workflow... [0100] As shown in FIG. 5, the example process 500 may begin at 502 with the workflow execution engine 306 retrieving a given user-customized workflow from the workflow data store 304... in order to facilitate execution of the given user-customized workflow. In practice, the workflow execution engine 306 may perform this function in response to determining that the given user-customized workflow has been newly created and is available for execution (e.g., by detecting a new entry in the workflow data store 304 or receiving a communication from the custom workflow creation engine 302 indicating that the given user-customized workflow has been created), although the workflow execution engine 306 may execute the given workflow at other times and/or in response to other triggers as well.) Defining the workflow is given the BRI of the user establishing the rules of the workflow. Processing the workflow based on input is an indication that the workflow conditions are being monitored and executed based on an input, which in the case of Parmar, is the save function which initializes the workflow. -by storing conditions and target actions defined by the user during the user session through interaction with interface screens in a control data structure as a conditional processing flow, (Parmar [0070] In general, the workflow creation engine 302 may be configured to perform functions that facilitate creation of a user-customized workflow, examples of which may include (i) causing a client station 108 associated with a user to present an interface for building such a workflow via the network-accessible interface 308, , (ii) receiving, from the client station 108 via the network-accessible interface 308, data defining a given workflow that has been built by the user, and (iii) storing, in the workflow data store 304, a data representation of the given workflow. [0054] and (ii) at least one user-defined rule that is to be applied to the user-defined set of information, which includes (a) at least one user-defined condition that is to be evaluated based on the user-defined set of information and (b) at least one corresponding action that is to be carried out automatically by the computing platform if the at least one user-defined condition is satisfied. [0094] After receiving an indication that the user has completed inputting one or more modifications to the given workflow, the client station may send data defining the one or more modifications to the custom workflows software subsystem 300. The custom workflows software subsystem 300 may then cause the data defining the one or more modifications to be stored in the workflow data store 304. In this regard, the data defining the one or more modifications may update or replace data defining the original given workflow.) The custom workflow falls within the scope of “conditional processing flow,” and the paragraphs above teach storing conditions and target actions defined by a user through interaction with interface screens. -wherein the conditions are provided back to the enterprise service through an application programming interface;(Parmar [0089] At block 406 of FIG. 4, the custom workflows software subsystem 300 may then receive from the client station 108 the data defining the user-customized workflow that has been built by the user. In practice, this data defining the user-customized workflow may initially be received by the API gateway 106 of the computing platform 102, and may then be routed from the API gateway 106 to the custom workflows software subsystem 300. However, other examples are possible as well.[0032] route the API-based request to one or more appropriate software subsystems, [0040] For example, although not shown, the computing platform 102 may include a software subsystem for providing a service that involves interaction with a computing system that is external to the computing platform 102 (e.g., via an API of the external computing system).) Therefore, receiving data defining the user-customized workflow from a client station, from an API gateway, whether that is internally based on [0032] or externally [0040], satisfies the limitation above. -and providing the extended functionality by processing the custom workflow using events reported by the enterprise application and the enterprise service, (Parmar [0113] Further, it should be understood that the iterations for the given user-customized workflow need not be carried out according to a fixed rate, and could instead be carried out according to event-based triggers. For instance, in an implementation where the workflow execution engine 306 is configured to carry out the iterations for the given user-customized workflow according to a frequency that is defined based on information returned about occurrences of certain types of transactions, each reporting of a new transaction occurrence may cause a new iteration to be carried out for the user-customized workflow to determine if the at least one user-defined condition is satisfied based on the new transaction occurrence.) In Parmar, transaction events are reported by the financial institution which causes the event-based triggers. -wherein the events are used to evaluate at least one user-specified condition defined in the custom workflow. (Parmar [0113] and [0004] wherein the at least one user-defined rule comprises (a) at least one condition that is to be evaluated based on the user-defined set of information and [0052] (i) automatically evaluating whether some user-defined condition related to the one or more financial accounts associated with the user is satisfied [0055] In general, the user-defined set of information about the one or more financial accounts... may comprise any information about a financial account associated with a user that can be evaluated by a user-defined rule ... in order to determine whether to carry out an action related to a financial account associated with the user ... This information may take various forms. [0056] As a first possibility, the user-defined set of information... may comprise information about an account balance of a financial account associated with the user. As a second possibility, the user-defined set of information... may comprise information about one or more transactions within a financial account, such as an occurrence of a credit, a debit, a purchase, a withdrawal, a deposit, a refund, a transfer, or a payment, among other possibilities. -and wherein the executable instructions are provided as a cloud service to the enterprise application and the enterprise service (Parmar [0041] In practice, the software subsystems that are hosted by the computing platform 102 to deliver services provided by the financial institution to users may be implemented using any of a variety of software architecture styles and/or deployment patterns. [0042] This set of physical computing resources take any of various forms. As one possibility, the computing platform 102 may comprise cloud computing resources that are supplied by a third-party provider of “on demand” cloud computing resources, such as Amazon Web Services (AWS), Amazon Lambda, Google Cloud Platform (GCP), Microsoft Azure, or the like...As yet another possibility, the example computing platform 102 may comprise a combination of cloud computing resources and on-premises computing resources. [0136] Communication interface 706 may be configured to facilitate wireless and/or wired communication with client stations (e.g., one or more client stations 108 of FIG. 1) and/or third-party computing platforms...communication interface 706 may be configured to facilitate wireless and/or wired communication between these physical computing devices (e.g., between computing and storage clusters in a cloud network).) The broadest reasonable interpretation of the limitation above is that the executable instructions (the instructions to execute the method) are provided on a cloud service that communicates to the enterprise application (such as the software services provided to the users), and to the enterprise service (the bank itself). Since the cloud is a hybrid communication with “on demand” cloud computing resources and on-premise computing resource (enterprise service), then the limitation has been satisfied. Response to Arguments Applicant's arguments filed on 02/19/2026 have been fully considered but they are not persuasive. Regarding applicant’s remarks over rejections under 35 U.S.C. 101, the applicant’s arguments have been fully considered but are not persuasive for the following reasons. In response to the applicant’s assertion that the claims are not directed to an abstract idea under Alice step one, the examiner respectfully disagrees because the claims clearly at least recite “managing personal behavior, interactions, or relationships between people.” Furthermore, the applicant alleges that the claims recite specific technological improvements, by “integrating extended interface screens within the user interfaces of the mobile applications to support extended features and functions.” However, this argument is not persuasive for the following reasons. The alleged technical problem being solved is that existing enterprise applications “limited automation capabilities, forcing customers to manually perform a variety of tasks, many of which need to be performed repetitively.” However, providing interface screens within mobile applications to automate particular functions is merely an “apply it” level additional element, in that it is merely an instruction to perform the abstract idea on a generic computer. MPEP 2106.05(f) similar example of additional elements found to be mere instructions to apply an exception, because they recite no more than an idea of a solution or outcome include: i. Remotely accessing user-specific information through a mobile interface and pointers to retrieve the information without any description of how the mobile interface and pointers accomplish the result of retrieving previously inaccessible information, Intellectual Ventures v. Erie Indem. Co., 850 F.3d 1315, 1331, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017); Therefore, the claims do not provide adequate description of how the interface extends the features and functions because all of the claimed features and functions tied to the user interface are within the ordinary capacity (a user interface to receive and display data). Therefore, “Integration of workflows into existing enterprise applications,” is not a persuasive argument because the claims do not reflect the alleged improvement, and they only recite the idea of the solution without specific mechanisms that enable the integration of workflows into existing external enterprise applications. Furthermore, the applicant’s arguments regarding “event-based processing architecture,” and “storage and processing efficiency” are not persuasive because a “control data structure” is broad enough to encompass mere instructions, and the applicant has not made clear how improvements to storage and processing efficiency are reflected in the scope of the claims. The wording of “effectively learning new tasks in succession whilst protecting knowledge about previous tasks,” does not apply to the present claims because this wording is in line with an improved machine learning technique that lent improvements to the software arts, whereas the present claims do not recite any machine learning or improvements to any technological fields. In response to the applicant’s arguments regarding Desjardins, the examiner acknowledges that software improvements are patent-eligible, however, for the same reasons stated in the rejections, the claims do not qualify as software improvements. Furthermore, the claims have not been evaluated at a high level of generality, contrary to the applicant’s allegation, as they have been evaluated at given the BRI of the actual claim language, which has a broad scope. Finally, even when “focusing on the improvement to the technology itself,” there is no improvement because the claims do not reflect the alleged improvement to API features, as they are claimed at such a high level of generality without reciting the specific mechanisms that lead to the solution. Therefore, the applicant’s argument that the claims (1) extend functionality, (2) enable event-based automated processing, (3) coordinating between enterprise services and third-party applications, and (4) using control data structures communicated via APIs to manage conditional workflow execution, is not persuasive because the claims do not “extend functionality” beyond what is capable in generic computers. Furthermore, (2) and (3) are still part of the abstract idea because processing events and coordinating between enterprises is merely interactions between individuals (and a computer). Finally (4) is not persuasive because control data structures are not specifically defined, and are any data representing control instructions, and communicating via API is also an “apply it” level element because it is merely using generic API functionality to transmit instructions. Furthermore, the examiner acknowledges that the proper statutory tools are 102, 103, and 112, and not “categorically excluding AI innovations from patent protection.” The examiner notes that the claims remain rejected under prior art, and do not fall within the realm of “AI innovations.” Therefore, the applicant’s assertions are not persuasive. Furthermore, in regards to applicant’s arguments over Prong 2 and Step 2B, the alleged improvement to “improved workflow integration,” is not purported within the scope of the claims because the claims do not reflect integrating workflows into existing enterprise applications without requiring complete system. “Including passing session control,” and “using container objects,” does not lend an improvement to the computer functionality, because it is not clear how the claims arrive at the solution. Furthermore, “enhanced event processing,” is not persuasive because receiving data from multiple sources does not preclude a claim from being directed to an abstract idea, therefore, the applicant’s argument is not persuasive. Furthermore, “extended functionality through API integration,” is not clear, because the claims merely recite transmitting a control data structure via API, which does not provide functionality that was previously unavailable. And even assuming arguendo that improvements are made in the specification to enable functionality, the actual claim scope does not provide the alleged improvement because it merely transmits information using an API. Therefore, none of the applicant’s arguments regarding Prong two are persuasive. Regarding the applicant’s arguments over Step 2B, even when considering the combination of (1, 2, 3, 4, 5), the claims as a whole still fail to meaningfully limit the claims such that it is limited to a particular technological implementation. For example, the claims merely add the step of “passing session control to an integration manager” in claim 14, without reciting what the integration manager does with the session control or providing any improvements that enable passing session control that weren’t previously attainable. Similarly, using control data structures to store workflow definitions, enabling communicating between workflow systems and enterprise services, event processing from multiple sources, and automated action triggering merely claim instructions to perform certain tasks based on conditions (certain methods of organizing human activity). Therefore, none of the applicant’s arguments regarding 35 U.S.C. 101 are persuasive, even in light of Desjardins. The examiner notes that in order to qualify as an improvement and integrate the abstract idea into a practical application, the claims should be amended so that they meaningfully limit the abstract idea to a particular practical application by explicitly reciting the series of steps that has enabled the API to directly provide these functionalities to any external enterprise system beyond its generic functionality. In regards to applicant’s remarks over rejections under 35 U.S.C. 102, the applicant alleges that Parmar does not disclose providing a control data structure to an Enterprise Service via an API. However, the examiner respectfully disagrees. The applicant argues that Parmar discloses “storing workflow data in a “workflow data store,” and describes internal interactions between different software subsystems within the same computing platform, but does not disclose or suggest providing a control data structure containing workflow instructions to an external enterprise service via an API. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “external enterprise service”, “a distributed architecture where workflow management functionality is provided as a separate service that communicates with enterprise services and applications via APIs”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The plain language of the claims merely requires at least a portion of the control data structure to be provided to an enterprise service and the enterprise application via an API, in which Parmar has been shown to teach in the updated rejection above. There is no explicit limitation requiring that these provision is to be from to an “external” enterprise service, and the furthermore, even assuming, arguendo, that the claims explicitly “required” an “external” enterprise service, the plain language of “external” is broad enough such that Parmar would satisfy such a limitation. For example, Parmar teaches([0039] Each of the foregoing software subsystems 104 hosted by the computing platform 102 may also have a respective network-accessible interface—such as an API, an Inter-process communication (IPC) interface, or the like—that allows the software subsystem 104 to be accessed over a data network by other software subsystems either directly or via the API gateway 106 (e.g., software subsystems running at the computing platform 102 and/or software subsystems running on client stations 108). [0040] As illustrated in FIG. 1 by the software subsystem 104n, the computing platform 102 may also host other software subsystems for providing other types of account-related services not shown in FIG. 1. For example, although not shown, the computing platform 102 may include a software subsystem for providing a service that involves interaction with a computing system that is external to the computing platform 102 (e.g., via an API of the external computing system).) Therefore, since transmissions can occur from the client devices and via an API of the “external computing system,” the applicant’s argument (that the present application describes a distributed architecture where workflow management functionality is provided as a separate service that communicates with enterprise services and applications via APIs) is not persuasive because Parmar teaches the claims in the broadest reasonable interpretation. Furthermore, the examiner notes that for the same reasons above, the applicant’s argument that Parmar recites a “monolithic computing platform where all subsystems are internal components” is both unpersuasive and a mischaracterization of Parmar. Furthermore, the applicant’s arguments under the sub-heading, “Parmar’s Internal Data Routing Does Not Satisfy the Claim Element” has been fully considered but it still not persuasive for the following reasons. Firstly, the applicant’s argument that Parmar describes receiving workflow definitions from a client station and routing them to an internal subsystem – not providing control data structures to external enterprise services or applications, is not persuasive because nothing in the claims or in the specification specifically limits the definition of “control data structures,” in a manner that is narrower than Parmar’s “workflow data store storing a data representation.” Furthermore, nothing in the claims specifically narrows the scope of the claims such that Parmar’s alleged “internal” subsystem falls outside of the scope of the claims. Furthermore, the applicant’s argument that Parmar’s API’s do not facilitate communication between “workflow management system and separate enterprise services” is not persuasive for the same reasons, particularly, that the features upon which applicant relies (i.e., “external enterprise service”, “a distributed architecture where workflow management functionality is provided as a separate service that communicates with enterprise services and applications via APIs”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Therefore, the applicant’s argument that the claims as amended, recite a specific architectural relationship where workflow control data is communicate to enterprise services/applications, enabling those service/applications to execute workflow-defined actions is not persuasive because the amended claims merely require performing the steps, “creating a custom automated workflow based on the condition and the corresponding target action by generating a control data structure that stores instructions for the custom automated workflow; and providing at least a portion of the control data structure to at least one of an enterprise service and the enterprise application via an application programming interface;” which does not specifically limit the where/who creates the custom automated workflow, whether the enterprise services and enterprise applications must be “external,” nor any of the other features argued by the application. Furthermore, regarding the applicant’s arguments under the sub-heading “Amended Claim 14 is not Anticipated by Parmar,” the applicant’s remarks have been fully considered but are not persuasive for the following reasons. The applicant alleges that “Parmar does not describe an enterprise application passing session control to a separate integration manager,” however, this argument is not persuasive because the claims do not specifically exclude internal “integration manager” nor do the claims specifically limit the scope of the “integration manager” such that Parmar’s teachings would fail to satisfy such a limitation. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Therefore, while Parmar’s teachings describe a unified computing platform, which may be a service hosted by the same platform, Parmar still satisfies the claims, in view of the plain language of the claims. Therefore, the applicant’s argument that the “passing of session control” represents a “specific technical implementation where an enterprise application transfers control to a separate service, enabling that service to manage the workflow creation process” is not persuasive because the features upon which applicant relies (i.e., enterprise application transfers control to a separate service, enabling that service to manage the workflow creation process) is not recited in the rejected claim. The broadest reasonable interpretation of the limitation “wherein when the workflow is selected by a user, the enterprise application passes session control to an integration manager” includes any passing of control ability to any “manager,” even by internal subsystems. While the applicant argues “the Examiner’s Interpretation of Parmar’s “session control” is overbroad,” this argument is not persuasive because of the guidelines of “broadest reasonable interpretation” in MPEP 2111. MPEP 2111 states, “The broadest reasonable interpretation does not mean the broadest possible interpretation. Rather, the meaning given to a claim term must be consistent with the ordinary and customary meaning of the term (unless the term has been given a special definition in the specification), and must be consistent with the use of the claim term in the specification and drawings. Further, the broadest reasonable interpretation of the claims must be consistent with the interpretation that those skilled in the art would reach.” The ordinary and customary meaning of “session control” broadly refers to the control of access to any session on an application, including given access to an app user, or any access to control whatsoever. Though the specification describes passing “session control” in a context in which it can be interpreted as external session control, the claim does not specifically limit session control in this manner. Furthermore, since the claim has not been given a “special definition” in the specification, the claim term is given the broadest reasonable interpretation in view of the ordinary and customary meaning of the term. MPEP 2111(IV) states, “The only exceptions to giving the words in a claim their ordinary and customary meaning in the art are (1) when the applicant acts as their own lexicographer; and (2) when the applicant disavows or disclaims the full scope of a claim term in the specification. To act as their own lexicographer, the applicant must clearly set forth a special definition of a claim term in the specification that differs from the plain and ordinary meaning it would otherwise possess.” The applicant has not set out an uncommon definition in some manner within the patent disclosure for the term “session control” so as to give one of ordinary skill in the art advance notice of the change. Therefore, the applicant is advised to amend the claim language such that it matches the exact scope of the features in which they argue. Therefore, it is not persuasive for the applicant to argue that the specification describes “a specific handoff of session control where the integration manager takes over rendering interface screens and managing user interaction within the context of the user’s session with the enterprise,” which Parmar’s internal subsystem navigation does not teach or disclose, particularly when the claims do not reflect this particular language given their broadest reasonable interpretation. Regarding the applicant’s arguments that amended claim 19 is not anticipated by Parmar, the applicant alleges that Parmar does not disclose providing conditions back to an enterprise service through an API. These arguments are also based on the notion that Parmar’s embodiments are internal components of the same computing platform operated by a financial institution. However, for the same reasons stated above, the claims do not reflect the features that are being argued, particularly the argument that Parmar describes “internal communication between subsystems within the unified platform, not providing conditions to a separate enterprise service through an API.” In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., separate enterprise service, separate service that coordinates with enterprise services through defined API interfaces, evaluate conditions based on their internal data and logic, and report results back to the workflow system) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Therefore, the applicant’s arguments that Parmar does not disclose the specific combination of elements (1), (2), (3) is not persuasive, because given their broadest reasonable interpretation, the limitations have been shown to be taught by Parmar in the updated rejection above. Furthermore, assuming arguendo, that the claim was limited to the external subsystems, Parmar’s teachings are not specifically limited to internal subsystems as evident in (Parmar [0040], “As illustrated in FIG. 1 by the software subsystem 104n, the computing platform 102 may also host other software subsystems for providing other types of account-related services not shown in FIG. 1. For example, although not shown, the computing platform 102 may include a software subsystem for providing a service that involves interaction with a computing system that is external to the computing platform 102 (e.g., via an API of the external computing system). Other examples are possible.”) Furthermore, the distinction between internal and external subsystems is not properly defined by the present disclosure. Interactions with client devices, including providing the ability to enter information through a GUI of a user device as an interaction with “external systems.” Thus the applicant is advised to amend the claim language such that the features in which they argue are positively recited. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: -Wang et al. (US 10762471 B1) discloses a system for integrating disparate subsidiary workflows to enable the automation of workflows that depend on disparate data sources with different access privileges. -Scarfutti et al. (US 20250306994) discloses a system that orchestrates tasks and services to performed from external microservices to be integrated into a process workflow, -Chaudhry et al. (US 20170315782 A1) disclose a workflow designer user interface of a workflow development application into a user interface of another software application, as that the workflow designer interface can generate workflows that generate/interact with the other software application. Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICO LAUREN PADUA whose telephone number is (703)756-1978. The examiner can normally be reached Mon to Fri: 8:30 to 5:00pm. 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, Jessica Lemieux can be reached at (571) 270-3445. 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. /NICO L PADUA/Junior Patent Examiner, Art Unit 3626 /JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
Read full office action

Prosecution Timeline

Jan 31, 2024
Application Filed
Jul 14, 2025
Non-Final Rejection mailed — §101, §102
Oct 14, 2025
Response Filed
Nov 20, 2025
Final Rejection mailed — §101, §102
Feb 19, 2026
Request for Continued Examination
Mar 09, 2026
Response after Non-Final Action
May 18, 2026
Non-Final Rejection mailed — §101, §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12586035
INTERACTIVE USER INTERFACE FOR SYSTEM
4y 7m to grant Granted Mar 24, 2026
Patent 12523701
METHOD FOR MANAGING BATTERY RECORD AND APPARATUS FOR PERFORMING THE METHOD
3y 2m to grant Granted Jan 13, 2026
Patent 11881521
SEMICONDUCTOR DEVICE
1y 11m to grant Granted Jan 23, 2024
Study what changed to get past this examiner. Based on 3 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
13%
Grant Probability
34%
With Interview (+21.6%)
2y 11m (~5m remaining)
Median Time to Grant
High
PTA Risk
Based on 39 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month