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 .
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 3/11/26 has been entered.
Notice to Applicant
The following is a Non-Final Office Action. In response to Examiner’s Non-Final Rejection of 6/8/26, Applicant, on 8/31/26, amended claims. Claims 1, 5, 7, 9-11, 15, 17, 19-20 are pending in the instant application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The previous 112(a) rejections and claim objections are withdrawn in light of the amendments.
The 101 rejections are withdrawn. The claim is not directed to an abstract idea, and when viewing the limitations in combination, is also viewed as a technological solution rooted in computing technology (MPEP 2106.05a) with additional elements of memory, requirements for a first computer system to interact with a chain of systems that depend on a previous response from an API, constructing via the processor a set of computational steps to meet the requirements [which comes from the API], executing an activity container that supports execution of activities as a process wrapper, and producing a configuration file comprising a JSON API-Call configuration that specifies an API to connect.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-5, 7, 9, 11, 14-15, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Varghese (US 2023/0067833) in view of Liu (US 2022/0066847) and Manohar (US 2023/0251835).
Concerning claim 1, Varghese discloses:
A method for configuring an activity framework, the method residing as instructions on a non-transitory computer-readable medium, the instructions being configured to cause a processor to perform operations (Varghese – see par 14 - provide a computer system that is specially-configured to integrate applications using a container image of an integration flow. see par 84-87 – computer system includes processor (CPU); machine-readable medium storing instructions for execution by the machine) comprising:
receiving, in a memory associated with the processor (Varghese – see par 84-86 – example computer system 900 includes processor and memory 904), a set of requirements (Varghese – see par 35 - one or more of the first application 312, the second application 322, and the development platform 330 are configured to receive user input. See par 36, FIG. 3 – the first system 310 comprises an on-premise system that includes an on-premise data center on which the first application 312 (e.g., an on-premise application) is hosted, and the second system 320 comprises a cloud system that includes a cloud data center on which the second application 322 (e.g., a cloud application) is hosted. The second system 320 is external to and independent of the first system 310. The first system 310 has a first data model that provide the definition and format of its data; see par 54 - The data mapping specification may comprise a list of attributes for the first system 310, a corresponding mapped list of attributes for the second system 320, and translation rules defining any data manipulation that needs to happen as information moves between the first system 310 and the second system 320, such as setting default values, combining fields, or mapping values; see par 40 - the development platform 330 is configured to enable a user of a computing device 350, such as an integration developer, to develop an integration flow 336 for integrating the first application 312 and the second application 322 to enable communication between the two) the set of requirements comprising at least one requirement for a first computer system to interact with a chain of systems having input and output … from an application programming interface (API) (Varghese – see par 26 - The API modules 146 can enable the development of service-based applications by exposing an interface to existing and new applications as services. Repositories can be included in the platform as a central place to find available services when building applications. see par 55 - The second system 320 may, at operation 820, set an authorization to enable the second system 320 to obtain a payload of a request from the first application 312. In some example embodiments, the second system 320 may set authorization headers that are specific for certain API calls. Each authorization header may comprise credentials to authenticate a user agent with a server; See par 56 - Next, the second system 320 may convert the payload of the request from a first data format of the first application 312 to a second data format of the second application 322, at operation 830. In one example, the first data format of the first system 310 is XML and the second data format of the cloud system is JSON, and the second system 320 may convert the payload of the request from the first application 312 from XML into JSON. The second system 320 may also format the payload of the request in other ways as well. See par 57 - Then, at operation 840, the second system 320 may perform a network call to the second application 322 using the converted payload of the request. For example, the second system 320 may send the converted payload to the second application 322 as an HTTP API call).
With regards to “that depend on a previous response”, Liu discloses:
the set of requirements comprising at least one requirement for a first computer system to interact with a chain of systems having input and output “that depend on a previous response” from an application programming interface (API) (Liu – see par 24 - With reference to FIG. 1, there is further shown a set of API providers 110, a workflow system 112, and a communication network 114. see par 31 - Additionally, in some cases, the mashup installer 104 may receive a set of rule parameters associated with the at least one trigger rule. For example, if the event data in the foregoing example is a message posted on the messaging platform, then a trigger rule may include a rule pattern, such as “USA” and a rule operator as “includes”. The rule pattern may be matched in the event data based on the rule operator defined in the trigger rule. By using the trigger rule, it may be checked whether the message posted on the messaging platform includes “USA”. Details of trigger rules are further provided, for example, in FIG. 3. see par 36 - The set of API gateways 122A, 122B, and 122C may enable the workflow system 112 to invoke at least one of: the deployed trigger function 120A, the deployed rule function 120B, and the deployed action function 120C. Such functions may be invoked in a specific order for an execution of the API mashup on the cloud computing system 102).
Varghese and Liu disclose:
constructing, via the processor, a set of computational steps required to meet the set of requirements (Varghese – see par 38 - An organization may want to integrate the first application 312 with the second application 322 to enable communication between the first application 312 and the second application 322. By integrating the ERP application of the first application 312 and the field service management application of the second application 322, data that is input or created via the first application 312 may be available for use by the second application 322, and data that is input or created via the second application 322 may be available for use by the first application 312; see par 42, FIG. 3 - the integration development component 332 is configured to receive a configuration of the integration flow from the computing device 350 of the integration developer via the LCNC development platform. The integration flow is configured to enable communication between the first application 312 being hosted on the first system 310 and the second application 322 being hosted on the second system 320), wherein each computational step of the set of computational steps is broken into one or more corresponding activities (Varghese see par 21, FIG. 2 - the cross-functional services 132 can provide portal services (e.g., web services), database services, and connectivity to the domain applications 134 for users that operate the client machine 116, the client/server machine 117, and the small device client machine 122. FIG. 2 includes 7 different example “domain applications” of businesses, including financial application 152; See par 29 - Enterprise personnel can utilize financial applications 152 and business processes to track and control financial transactions within the enterprise application platform 112. The financial applications 152 can facilitate the execution of operational, analytical, and collaborative tasks that are associated with financial management. Specifically, the financial applications 152 can enable the performance of tasks related to financial accountability, planning, forecasting, and managing the cost of finance. see FIG. 6, par 41 - In FIG. 6, the integration developer has used the LCNC development platform to create endpoints 610 and 630 and components 621, 622, 623, 624, and 625 of an integration flow 620. For example, the integration flow 620 may be configured to enable communication between the endpoint 610, such as the first application 312, and the endpoint 630, such as the second application 322) based on a set of rules associated with executing a subsequent activity (Varghese – see par 54 - At operation 810, the second system 320 maps the first application 312 to the second application 322. For example, the second system 320 may obtain a database schema of the first system 310 and a database schema of the second system 320, and then generate a data mapping specification for transforming attributes of the first system 310 to the second system 320 based on the database schema of the first system 310 and the database schema of the second system 320. The data mapping specification may comprise a list of attributes for the first system 310, a corresponding mapped list of attributes for the second system 320, and translation rules defining any data manipulation that needs to happen as information moves between the first system 310 and the second system 320, such as setting default values, combining fields, or mapping values;
see also Liu – see par 32 - The mashup installer 104 may further deploy a rule function 120B on the cloud computing system 102. The rule function 120B may include the generated computer-executable rule code as a function setting of the deployed rule function 120B. The rule function 120B may be deployed for application of at least one trigger rule on the event data associated with the electronic trigger event. see par 77 - rule operator menu 304A may be a drop-down menu, which may list a set of pre-defined rule operators that may be applicable on the event data associated with the electronic trigger event. Examples of such rule operators with their corresponding descriptions are presented in Table 1);
generating, based on the set of computational steps, an activity framework, the activity framework including a … of activities (Varghese – see par 21 - The cross-functional services 132 provide services to users and processes that utilize the enterprise application platform 112. For instance, the cross-functional services 132 can provide portal services (e.g., web services), database services, and connectivity to the domain applications 134 for users that operate the client machine 116; see par 29 - Enterprise personnel can utilize financial applications 152 (See FIG. 2 – 152 is one of the domain application 134 in FIG. 1) and business processes to track and control financial transactions within the enterprise application platform 112. The financial applications 152 can facilitate the execution of operational, analytical, and collaborative tasks that are associated with financial management; See par 47 - the system architecture 300 may receive a configuration of the integration flow 336 from the computing device 350 via the LCNC development platform, at operation 720. For example, a user of the computing device 350 may use the GUI 600 discussed above with respect to FIG. 6 to develop the configuration of the integration flow 336. The configuration may comprise details of the integration flow 336, such as messaging endpoints (e.g., a sender and a receiver) and individual processing steps between the messaging endpoints)
Varghese discloses “business processes” and collaborative tasks, and having different domain applications and services (See par 21, 29) where details of an integration flow and individual processing steps is given by the user (See par 47). To the extent that Varghese does not disclose the word “workflow”, Liu discloses:
generating, based on the set of computational steps, an activity framework, the activity framework including a “workflow” of activities (Liu – see par 39 - Based on the collected information, the mashup installer 104 may generate a workflow template of the API mashup on the cloud computing system 102. workflow template may describe a workflow sequence to execute the API mashup by individually invoking the trigger function 120A, the rule function 120B, and the action function 120C. see par 40 - The workflow system 112 may include suitable logic, circuitry, interfaces, or code that may be configured to control the workflow execution of the API mashup on the cloud computing system 102 based on the posted workflow template. In an embodiment, for such control, the workflow system 112 may be implemented as a low-code or a no-code platform, which may read the workflow template to individually invoke the trigger function 120A, the rule function 120B, and the action function 120C on the cloud computing system 102. see par 82 - the set of action destinations may contain a list of API providers, each of which may provide one or more API endpoints as API-based action(s))
Varghese and Liu disclose:
executed using an activity container that supports execution of a single activity and execution of a set of activities as a process wrapper comprising multiple activities (Varghese see par 40 - The development platform 330 may comprise an integration development component 332 with which the integration developer interacts to configure the integration flow 336. In some example embodiment, the integration development component 332 comprises a low-code no-code (LCNC) development platform that is configured to enable the integration developer to develop an integration flow 336 by using a graphical user interface (GUI) of the LCNC development platform to drag and drop components of the integration flow 336. See par 41 - In FIG. 6, the integration developer has used the LCNC development platform to create endpoints 610 and 630 and components 621, 622, 623, 624, and 625 of an integration flow 620 (disclosing alternative of “sequentially executing activities” – e.g. setting authorization 622, THEN XML to JSON converter 623… etc; See par 43, 49 - Then, at operation 730 (FIG. 7), the system architecture 300 may build a container image of the integration flow 336 based on the configuration of the integration flow 336. In some example embodiments, the container image is configured to execute the integration flow 336. The container image of the integration flow 336 may comprise a lightweight, standalone, executable package of software that includes everything needed to run the integration flow, such as code, runtime, system tools, system libraries, and settings. The building the container image of the integration flow 336 may comprise generating a Java Archive (JAR) file that includes the container image of the integration flow 336
PNG
media_image1.png
570
852
media_image1.png
Greyscale
see also Liu – see par 48 - The container may be a form of operating system virtualization that may be used to run anything from a small microservice or a software process to a larger application. The container may include all the necessary executables, binary code, libraries, and configuration files. see par 126 - After the rule function 120B and the second API gateway 122B are deployed, an invoke URL of the second API gateway 122B may be automatically converted to a provider and a connector for future usage of the API mashup. The workflow system 112 may invoke the second API gateway 122B and the rule function 120B, by calling the generated provider and connector).
Varghese and Liu disclose:
producing a configuration file, responsive to the generated activity framework, wherein the configuration file comprises a JSON API-call configuration (Varghese – see FIG. 8, par 53 – 810 -map first application to second application; 820 – set authorization; 830 – convert payload; 840 – performance network call; see par 56 - In one example, the first data format of the first system 310 is XML and the second data format of the cloud system is JSON, and the second system 320 may convert the payload of the request from the first application 312 from XML into JSON. The second system 320 may also format the payload of the request in other ways as well. See par 57 - Then, at operation 840, the second system 320 may perform a network call to the second application 322 using the converted payload of the request. For example, the second system 320 may send the converted payload to the second application 322 as an HTTP API call);
See also Liu – see par 39 - Based on the collected information, the mashup installer 104 may generate a workflow template of the API mashup on the cloud computing system 102. The workflow template may be generated in a structured data format, such as, but not limited to, JavaScript Object Notation (JSON); see par 126 - After the rule function 120B and the second API gateway 122B are deployed, an invoke URL of the second API gateway 122B may be automatically converted to a provider and a connector for future usage of the API mashup; see par 132 - the computer-executable action code may be an API call code to an API endpoint associated with the second API provider. The API call code may be generated based on an API specification file, such as an OpenAPI Specification (OAS) file. Such a file may define a standard, programming language-agnostic interface description for Representational State Transfer (REST) APIs. Many API providers offer OAS for their APIs. If the OAS is not offered, machine learning methods may be applied to learn unstructured API documentations, retrieve essential information from such documentations, and convert such information to a structured OAS file) that specifies an API to connect (Vareghese – see par 25 - The connector and messaging modules 144 can enable communication across different types of messaging systems that are utilized by the cross-functional services 132 and the domain applications 134 by providing a common messaging application processing interface), how to create a request, how to map a response back (Varghese - see par 54 - see par 54 - The data mapping specification may comprise a list of attributes for the first system 310, a corresponding mapped list of attributes for the second system 320, and translation rules defining any data manipulation that needs to happen as information moves between the first system 310 and the second system 320, such as setting default values, combining fields, or mapping values;
see also Liu – see FIG. 3, par 75 – disclosing request and response - The trigger parameter(s) may be used as input parameters for API calls to a API resource server of the first API provider (such as Twitter®) to extract an API response, which may include the new tweet from the specific user and metadata, such as message ID, tweet time, tweet ID, or tweet tags. Information in the API response may be considered as the event data, which may be later on used to check whether trigger rules are satisfied, as described herein. see par 114 - The generated trigger function 120A, when triggered or invoked, may execute the computer-executable trigger code to periodically call an API endpoint of the first API provider and may receive a sequence of responses from the API endpoint. The electronic trigger event may be detected based on a comparison between a first response in the received sequence of responses and a second response in the received sequence of responses. see par 132 - The API call code may be generated based on an API specification file, such as an OpenAPI Specification (OAS) file. If the OAS is not offered, machine learning methods may be applied to learn unstructured API documentations, retrieve essential information from such documentations, and convert such information to a structured OAS file.), and how to handle retry processing (Liu see par 87 - After the trigger function is successfully deployed, the mashup installer 104 may send a response code to the electronic UI 108. The response code (such as 200) may indicate whether the deployment of the trigger function is successful. see par 150 - At 818, a second error may be displayed on the electronic UI 108 of the user device 106. The second error may correspond to an unsuccessful attempt in the setup of the API mashup on the workflow system 112. Such an error may occur if, for example, the workflow template is rejected by the workflow system 112; see par 170 - The deployed action function 120C, when invoked, may further receive a response of the second API provider to the generated at least one API call. The response of the second API provider may be associated with a confirmation or a rejection of the action. The deployed action function 120C, when invoked, may further post the response to the workflow system 112. The workflow system 112 may update the response, via an API call, to the electronic UI 108 on the user device 106.).
wherein the JSON API-call configuration is stored in a configuration table with a configuration type and a configuration identifier (Liu – see par 109 - The mashup installer 104 may determine an API identifier and a root resource identifier based on the created first REST API in the API gateway 214. The API identifier may correspond to a unique identifier of the first API gateway 122A and the root resource identifier may correspond to a base path URL of the first API gateway 122A.), and
wherein invocation of an API integration library with the configuration identifier and an input causes the API integration library to fetch the JSON API-call configuration from the configuration table and perform API integration based on the fetched JSON API-call configuration… (Liu – see par 87 - For example, if the first API call is made to /setupTrigger on the mashup installer 104, then the mashup installer 104 may deploy the trigger function 120A on the cloud computing system 102 and may integrate the API gateway 122A with the trigger function 120A. See par 110 - At 510, an integration of the first API gateway 122A of the deployed set of API gateways 122A, 122B, and 122C with the configured trigger function 120A may be created. After the integration is created, the trigger function 120A may be considered as deployed and ready to be invoked via a call to the first API gateway 122A. see par 125 - By way of example, and not limitation, after “/setupRule” endpoint may be invoked, the mashup installer 104 may upload the generated computer-executable rule code (such as the simplified code of the foregoing example) to a container or a VM on the cloud computing system 102. Also, the mashup installer 104 may create libraries and IAM roles required to execute the uploaded code, correctly).
Varghese discloses that the platform has software for an enterprise application platform (See par 19) and that there is a development environment for extension of software components “without” impacting existing cross-functional services and domain applications (see par 27). Liu discloses having a container to run a small microservice or a software process to a larger application, where the container may isolate the application processes (See par 48).
Manohar discloses:
without modifying source code of the activity framework (Manohar see par 39 - In one embodiment, each micro frontend is configured with hard coding and is an executable file/code. Typically, hard coded software is compiled from source code of a program into an executable file or other executable object. Usually, the hard-coded, executable data can only be modified by editing the source code and then the source code must be recompiled into executable code before the edits take effect and can be used. see par 40 - Conversely, in one embodiment, the metadata associated with each micro frontend is coded with JSON code that is preferably not executable and does not need to be compiled. In this manner, the JSON code can be directly modified through user input, for example, by editing the text of the metadata to change the parameters and/or configuration of the APIs or other properties of the associated micro frontend. Since the metadata is not executable code, the metadata may be modified without having to recompile the code of the metadata and without having to recompile the executable code in the associated micro frontend).
Varghese and Liu are analogous art as they are directed to allowing different system/service/applications to communicate and be used together for business purposes (See Varghese Abstract, par 28-30, 36, FIG. 3; Liu Abstract, par 3; Manohar Abstract, par 11). 1) Varghese discloses “business processes” and collaborative tasks, and having different domain applications and services, financial application 152 can be one that helps facilitate tasks (See par 21, 29) where details of an integration flow and individual processing steps is given by the user (See par 47), and setting authorization headers for certain API calls (See par 26). Liu improves upon Varghese by having trigger rules for specific order of executions with sets of APIs (See par 24, 31, 36) and having it for a workflow template and system (See par 39, 40) as well as calling a second API provider, and converting information for API specification files with JSON format, and integrating APIs (See par 39, 125-126, 132). One of ordinary skill in the art would be motivated to have activities that are part of a “workflow” and different sets of APIs, and converting and rules for APIs, to efficiently improve upon the business processes and the building of software needed to run the integration flow, such as code, system tools, system libraries, as disclosed in Varghese. 2) Varghese discloses that the platform has software for an enterprise application platform (See par 19) and that there is a development environment for extension of software components “without” impacting existing cross-functional services and domain applications (see par 27). Liu discloses having a container to run a small microservice or a software process to a larger application, where the container may isolate the application processes (See par 48). Manohar improves upon Varghese and Liu by having a micro frontend with APIs that does not need to be recompiled, where microservices support business tasks (See par 11, 17, 39, 40). One of ordinary skill in the art would be motivated to APIs that do not require recompiling of a source code of a program, to efficiently improve upon the business processes and the building of software needed to run the integration flow, such as code, system tools, system libraries, as disclosed in Varghese and the isolated/small microservices in Liu.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the use of updating and extending software components to domain applications of other systems/services that uses business processes in Varghese, to further include rules for order of executions with sets of APIs, a workflow template, and converting information for API files in Liu, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 11, Varghese and Liu disclose:
A system for configuring an activity framework (Varghese – see par 84-87 – computer system includes processor (CPU); machine-readable medium storing instructions for execution by the machine), the system comprising:
a memory (Varghese – see par 84-86 – example computer system 900 includes processor and memory 904);
a processor, which when executing instructions from the memory, is configured to perform operations including (Varghese – see par 84-87 – computer system includes processor (CPU); machine-readable medium storing instructions for execution by the machine).
The remaining limitations are similar to claim 1 above. Claim 11 is rejected for the same reasons.
It would be obvious to combine Varghese and Liu for the same reasons as claim 1.
Concerning independent claim 20, Varghese and Liu disclose:
. A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method (Varghese – see par 84-87 – computer system includes processor (CPU); machine-readable medium storing instructions for execution by the machine)) comprising:
receiving, in a memory associated with the processor (Varghese – see par 84-86 – example computer system 900 includes processor and memory 904);
The remaining limitations are similar to claim 1 above. Claim 20 is rejected for the same reasons.
It would be obvious to combine Varghese and Liu for the same reasons as claim 1.
Concerning claims 5 and 15, Varghese and Liu disclose:
The method of claim 1, wherein the configuration file obviates the need for writing code (0007] as published - The embodiments also provide a low-code and conflict-driven process for onboarding different businesses having different requirements.
Varghese discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 40-41 - The development platform 330 may comprise an integration development component 332 with which the integration developer interacts to configure the integration flow 336. In some example embodiment, the integration development component 332 comprises a low-code no-code (LCNC) development platform that is configured to enable the integration developer to develop an integration flow 336 by using a graphical user interface (GUI) of the LCNC development platform to drag and drop components of the integration flow 336. See par 41 - In FIG. 6, the integration developer has used the LCNC development platform to create endpoints 610 and 630 and components 621, 622, 623, 624, and 625 of an integration flow 620).
It would be obvious to combine Varghese and Liu for the same reasons as claim 1.
Concerning claims 7 and 17, Varghese and Liu disclose:
The method of claim 1, wherein the configuration file supports execution of set of activities (Varghese – see par 23- The portal modules 140 can enable a single point of access to other cross-functional services 132 and domain applications 134 for the client machine 116, the small device client machine 122, and the client/server machine 117. In addition, the portal modules 140 can enable user roles, a construct that associates a role with a specialized environment that is utilized by a user to execute tasks, utilize services, and exchange information with other users within a defined scope; see par 51 - The system architecture 300 may then run the container image of the integration flow 336 on the second system 320, at operation 750. For example, the second system 320 may use the deployed container image of the integration flow 336 to process requests from the first application 312 to the second application 322)
It would be obvious to combine Varghese and Liu for the same reasons as claim 1.
Concerning claim 9, Varghese and Liu disclose:
The method of claim 1, wherein the configuration file supports holding and executing an activity in a context-called activity (Varghese see par 29 - Enterprise personnel can utilize financial applications 152 and business processes to track and control financial transactions within the enterprise application platform 112. The financial applications 152 can facilitate the execution of operational, analytical, and collaborative tasks that are associated with financial management. see par 40 - The development platform 330 may comprise an integration development component 332 with which the integration developer interacts to configure the integration flow 336. In some example embodiment, the integration development component 332 comprises a low-code no-code (LCNC) development platform that is configured to enable the integration developer to develop an integration flow 336 by using a graphical user interface (GUI) of the LCNC development platform to drag and drop components of the integration flow 336.);
see also Liu see par 29 - For example, if the first API provider is a messaging service provider, then the API-based trigger option may correspond to an endpoint to retrieve a message posted on a messaging platform associated with the messaging service provider. see par 34 - The action function 120C may be deployed for generating at least one API call to the second API provider of the set of API providers 110 based on whether the event data satisfies the at least one trigger rule. see par 35 - Each of the set of API gateways 122A, 122B, and 122C may be deployed as a service to filter and route incoming requests to a respective function on the cloud computing system 102. see par 36 - The set of API gateways 122A, 122B, and 122C may enable the workflow system 112 to invoke at least one of: the deployed trigger function 120A, the deployed rule function 120B, and the deployed action function 120C. Such functions may be invoked in a specific order for an execution of the API mashup on the cloud computing system 102; see par 167 - The API call may be transmitted to invoke the deployed rule function 120B with the event data including values from the payload as the input. When invoked, the rule function 120B may be configured to execute the computer-executable rule code on the cloud computing system 102 to determine whether the event data in the payload satisfies at least one trigger rule (i.e. a rule and a pattern).).
It would be obvious to combine Varghese and Liu for the same reasons as claim 1.
Concerning claims 10, Varghese discloses executing a computer program in a distributed manner across multiple sites (See par 81), and having a build container image of integration flow enables communication between a first application 312 and a second application 322 (See par 44, 49) and making a network “call” to the second application using a converted payload of a request (See par 66).
Liu discloses:
The method of claim 1, wherein the configuration file supports clearing an execution of a previous activity (Liu - see par 40 - The workflow system 112 may include suitable logic, circuitry, interfaces, or code that may be configured to control the workflow execution of the API mashup on the cloud computing system 102 based on the posted workflow template. See par 60 - the API gateway 214 may receive inputs, such as API calls from the electronic UI 108 to deploy functions, such as the trigger function 120A, the rule function 120B, and the action function 120C, or to delete such deployed functions.)
Varghese discloses executing a computer program in a distributed manner across multiple sites (See par 81), and having a build container image of integration flow enables communication between a first application 312 and a second application 322 (See par 44, 49) and making a network “call” to the second application using a converted payload of a request (See par 66). Liu improves upon Varghese by disclosing one can delete deployed functions from electronic UI. One of ordinary skill in the art would be motivated to delete functions to efficiently improve upon the business processes and the building of software needed to run the integration flow and the image of integration flow in Varghese.
Concerning claim 19, Varghese and Liu disclose
The system of claim 12, wherein the input and output of said chain of systems
depend on a previous response from an application programming interface (API)
(Varghese - see par 56 - The second system 320 may also format the payload of
the request in other ways as well. See par 57 - Then, at operation 840, the second
system 320 may perform a network call to the second application 322 using the
converted payload of the request. For example, the second system 320 may send
the converted payload to the second application 322 as an HTTP API call; See
Each of the set of API gateways 122A, 122B, and 122C may be deployed as a service to filter and route incoming requests to a respective function on the cloud computing system 102;
Liu see par 34 - The action function 120C may be deployed for generating at least one API call to the second API provider of the set of API providers 110 based on whether the event data satisfies the at least one trigger rule. see par 35 - Each of the set of API gateways 122A, 122B, and 122C may be deployed as a service to filter and route incoming requests to a respective function on the cloud computing system 102. see par 36 - The set of API gateways 122A, 122B, and 122C may enable the workflow system 112 to invoke at least one of: the deployed trigger function 120A, the deployed rule function 120B, and the deployed action function 120C. Such functions may be invoked in a specific order for an execution of the API mashup on the cloud computing system 102).
It would be obvious to combine Varghese and Liu for the same
reasons as claim 1 and 9 above. In addition, Varghese discloses having multiple API calls (See par 55) and converting payloads (See par 56) when sending to different
applications/services (See par 57). Liu improves upon Varghese by
disclosing generating APIs calls based on trigger rules, having a set of API gateways, and invoking functions in a specific order for execution of an API mashup (See par 34-36).
Response to Arguments
Applicant’s arguments filed 8/31/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
Applicant’s arguments are moot in view of the revised rejections necessitated by the amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at 571-270-3614. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
