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 Final Rejection of 12/11/25, Applicant, on 3/11/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.
Examiner notes that claim 9 has added new limitations without underlining. Examiner has underlined them below.
The previous 112(b) rejections are withdrawn in light of the amendment to claim 9 and cancelling claim 4.
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 dependent 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], generating activity containers that supports executing activities, where and producing a configuration file that supports the activities.
Claim Objections
Claim 19 is objected to because of the following informalities: it depends from claim 12 which is cancelled. The subject matter of claim 12 (“wherein the set of requirements includes a requirement for a first computer system to interact with a chain of systems”) is already in claim 11. Claim 19 should be amended to recite “The system of claim [[12]] 11.” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 5, 7, 9-11, 15, 17, 19-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 now recites “generating, based on the set of computational steps, an activity framework, the activity framework including a workflow of activities including at least one activity container that supports simultaneously or sequentially executing activities wherein the activity framework further defines a dependency structure between activities such that outputs of one activity dynamically parameterize inputs of a subsequent activity across heterogeneous APIs.” The disclosure as filed does not disclose various words from this limitation such as - “dependency structure,” “dynamic”, “dynamically”, “parameterize”, or “heterogeneous APIs”. While explicit word-for-word support is not needed, Examiner is still unable to decipher how this is supported by the disclosure as filed. The closest thing Examiner can find is [0032] as published for part of this, where it states “ set of requirements can include a requirement for a first computer system to interact with a chain of systems. Furthermore, the input and output of the chain of systems depend on a previous response from an API. The set of requirements can further include a set of rules associated with executing a subsequent activity from the activity framework. Furthermore, in the set of computational steps, each computational step is broken into corresponding activities.” However, [0032] does not say what is in the current claim. Examiner invites Applicant to explain how the limitation is supported by pointing to specific portions of the disclosure as filed, amend the claim, and/or cancel some portions of the claim limitations.
Independent claims 11 and 20 recite similar limitations and are rejected for the same reasons.
Claims 5, 7, 9-10, 15, 17, 19 depend from independent claims and are rejected for the same reasons.
Claim 9 now recites “executing one of the one or more corresponding activities within the activity container of the activity framework wherein the execution is orchestrated based on dynamic dependency resolution among chained API response.” The disclosure as filed does not “dynamic dependency resolution”. There is no “dynamic”, or “dependency.” There is a mention in [0036] that a “use case” can be “ enrichment, investigation, resolution, entitlement validation, allocation, assignment, prioritization.” It is unclear how the mention of resolution in [0036] is related to [0029, 0032] “chain of systems” which is closest Examiner can find for “dependency.” Examiner is unable to decipher how this is supported. Perhaps Applicant is intending to have limitations related to [0037, 0038]? Examiner cannot tell what Applicant has in mind. Examiner invites Applicant to explain how the limitation is supported by pointing to specific portions of the disclosure as filed, amend the claim, and/or cancel some portions of the claim limitations.
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) and Liu (US 2022/0066847).
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 “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 “dependent 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 is decomposed 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:
including at least one activity container that supports simultaneously or sequentially executing 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 - In some example embodiments, the integration development component 332 is configured to build a container image of the integration flow (see 336 above) based on the configuration of the integration flow. The container image is configured to execute the integration flow. See par 44 - the development platform 330 is configured to deploy the container image of the integration flow 336 on the second system 320. The deployed container image of the integration flow 336 enables communication between the first application 312 and the second application 322
PNG
media_image1.png
570
852
media_image1.png
Greyscale
see also Liu - The 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);
wherein the activity framework further defines a dependency structure between activities such that outputs of one activity dynamically parameterize inputs of a subsequent activity across heterogeneous APIs (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 - 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).
Liu also discloses the limitations as best understood:
wherein the activity framework further defines a dependency structure between activities such that outputs of one activity dynamically parameterize inputs of a subsequent activity across heterogeneous APIs (Liu – 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).
Varghese and Liu disclose:
producing a configuration file, responsive to the generated activity framework, wherein the configuration file supports executing a single activity (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 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) or a process wrapper comprising multiple activities (Varghese or Liu discloses 2nd alternative of “wrapper”, based on broadest reasonable interpretation in light of Applicant’s specification [0035] as published “The configuration file obviates the need for writing code. The configuration file supports executing a single activity from the activity framework. It can further support the execution of set of activities which are a process wrapper for multiple activities.”: Varghese – see par 46 - In some example embodiments, the LCNC development platform is configured to enable a user of the computing device 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; 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
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. ), wherein the configuration file is automatically generated based on said dependency structure (Varghese – see par 48 - container may include all the necessary executables, binary code, libraries, and configuration files; see par 49 - 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).
Both 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). 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 (See par 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.
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, executing one of the one or more corresponding activities within the activity container of the activity framework (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 - In some example embodiments, the integration development component 332 is configured to build a container image of the integration flow (see 336 above) based on the configuration of the integration flow. The container image is configured to execute the integration flow. See par 44 - the development platform 330 is configured to deploy the container image of the integration flow 336 on the second system 320. The deployed container image of the integration flow 336 enables communication between the first application 312 and the second application 322)
PNG
media_image1.png
570
852
media_image1.png
Greyscale
wherein the execution is orchestrated based on dynamic dependency resolution among chained API response (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. 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).
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 3/11/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.
Conclusion
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
Prosecution Insights