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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 12/15/2025 has been entered.
Response to Amendment
The Amendment filed 12/15/2025 has been entered. Claims 2, 9, and 16 have been canceled. Claims 1, 3-8, 10-15, and 17-20 remain pending in the present Office Action.
The Amendment has overcome all rejections under 35 U.S.C. 112(b) set forth in the previous Office Action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-8, 10-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Alurralde Iturri et al. (U.S. Pub. No. 2018/0081642), hereinafter Alurralde Iturri, in view of Ide et al. (U.S. Patent No. 11,182,131), hereinafter Ide, Barton et al. (U.S. Pub. No. 2018/0324279), hereinafter Barton, Douglas et al. (U.S. Pub. No. 2020/0401465), hereinafter Douglas, and Kochhar et al. (U.S. Patent No. 11,082,373), hereinafter Kochhar.
Regarding claim 1, Alurralde Iturri teaches a method, comprising:
at design time, generating, by a computer operating on an information exchange platform based on application programming interface (API) documentation associated with an external service, a reusable API connector for the external service ([0090] – “FIG. 5 shows a second example UI display screen 130, which is accessible via the first UI display screen of FIG. 4, and which represents an example first step 132 of a wizard for creating an example Simple Object Access Protocol (SOAP) connector.”; [0091] – “Accordingly, the current UI display screen 130 displays various UI controls 138 for selecting a source used to access data to be used for the connector. The data may include specifications of a service interface to be used by an existing connector, where the specifications are included in an existing locally stored file; may include specifications pertaining to a portion of a file to be uploaded; or may include specifications accessible via a URL, etc.”; [0093] – “In the example of FIG. 5, the user has selected an existing WSDL file (i.e., “v01.wsdl”), via the file-selection UI control 142, for use with the SOAP connector under construction. Note that the selected WSDL file may include a description of a particular service interface for a service that the connector will connect to on behalf of a process step to be associated with the connector.”; [0059] – “Once a particular connector has been constructed, e.g., in response to developer interaction with the client-side connector construction wizard UI display screens 38, it is made available to application development editor functionality 50, via a connectors catalog 66 in which the connector is saved.”; [0141] – “the method 270 may further specify that the first UI-control-providing step 270 further includes storing the developed connector in a catalog (e.g., the connectors catalog 66 of FIG. 2) of reusable connectors. Once stored in the connectors catalog 66, a developer may readily employ one or more of the editors 22 to browse the connectors catalog 66 and select a connector to facilitate implementing another step of the first process-based software application or a another step of another process-based software application.”), […] an itinerary using the reusable API connector ([0061] – “The process-based software application 70 includes one or more different steps, where each step represents a flow element, e.g. activity or other step. One or more steps of the flow 72 have been associated with one or more selected connectors 52, which shall be used to facilitate implementing the activity or step (by calling the service or API interfaced by the connector) upon deployment of the process-based software application 70”), the external service provided by a third-party system communicatively connected to the information exchange platform over a network ([0040] – “connectors 24 represent or are associated with outbound services 18, also called external services herein.”; [0042] – “The overall system 10 may represent a networked computing environment, such as a networked enterprise computing environment.”; [0048] – “The example system 10 includes one or more developer systems 12 in communication with the one or more application development systems 14. The application development systems 14 and connectors framework 16 may run on a server system, e.g., a process cloud, accessible to the client developer systems 12. The outbound services 18 that are accessed by process-based software applications using the configured connectors 24 may be external to such a process cloud, i.e., running on a different server system.”); and
at runtime: […]
calling, by the computer in processing the itinerary […], the external service using the reusable API connector ([0061] – “The process-based software application 70 includes one or more different steps, where each step represents a flow element, e.g. activity or other step. One or more steps of the flow 72 have been associated with one or more selected connectors 52, which shall be used to facilitate implementing the activity or step (by calling the service or API interfaced by the connector) upon deployment of the process-based software application 70. When deployed, the process-based software application 70 may use the connectors 52 to call associated external services 18, using connector implementation functions 24 of the connectors framework 16 as needed to map or translate communications between the connectors 52 (for different steps of the flow 72) and associated services 18.”; [0143] – “The second example method 270 may further include deploying the connector using a runtime of a connectors framework used to implement the second example method 270. Note that the connectors framework 16 of FIG. 2 may include or otherwise communicate with a runtime that can be used to run the process-based software application 70 and associated connectors 52 in a test environment.”), […]
fetch the reusable API connector from the connector database ([0061] – “When deployed, the process-based software application 70 may use the connectors 52 to call associated external services 18, using connector implementation functions 24 of the connectors framework 16 as needed to map or translate communications between the connectors 52 (for different steps of the flow 72) and associated services 18.”; [0062] – “The selected connectors 52 are selected by a process developer (e.g., business user) from the connectors catalog 66.”; [0167] – “the runtime may use and access data of the process connectors catalog 66”),
call the external service using the reusable API connector ([0061] – “When deployed, the process-based software application 70 may use the connectors 52 to call associated external services 18”), […].
Alurralde Iturri fails to expressly teach the reusable API connector being defined for reflecting updates in an API of the external service independently of an itinerary using the reusable API connector; and at runtime: receiving a file from a client system; determining the itinerary for processing the file based on a set of attributes associated with the file, the set of attributes comprising: a sender of the file; a receiver of the file; and a document type of the file; and the itinerary that includes a universal service, the universal service being defined within the determined itinerary to invoke the external service via the reusable API connector without modifying the determined itinerary, […] wherein the universal service is operable to: obtain a customer identifier from the determined itinerary, obtain an object identifier from a data object contained in a request from a client system of the information exchange platform, query a connector database using the customer identifier and the object identifier, and based on a result from the connector database, send a request to a connector engine, wherein the connector engine is operable to, based on the request from the universal service: […] handle results of the call, and return the results to the universal service.
However, Ide teaches processing of an itinerary that includes a universal service, the universal service being defined within the determined itinerary to invoke the external service (Col. 8, lines 33-35 – “The processing nodes include, for example, a service X using node that invokes the function of the service X via an API.”; Col. 8, lines 64-66 – “On the flow 221, based on the connection relationship between the nodes 222, the execution order of processes by a flow execution function 12 is determined.”; Col. 9, lines 42-48 – “Among nodes 222, there are nodes 222 that invoke the service 70 outside of the visual programming system 10 and uses the function of the service 70, such as the service X using nodes 222-2 and 222-3 described above. Such a nodes are referred to as "service using nodes". One service using node 222 operates a plurality of services 70 in some cases, and operates one service 70 in other cases.”; Col. 9, lines 65-67 – “One service using node may hold a plurality of connection setting properties.” A service using node in a flow can be considered “universal” because the single node may be able to connect to and invoke many services using connection information retrieved during execution of the flow, i.e., “at runtime”, as described in Col. 25, lines 19-46.) […] wherein the universal service is operable to: […] obtain an object identifier from a data object contained in a request from a client system of the information exchange platform (Col. 9, lines 32-33 – “When the user 40 presses the execution button 201, the flow 221 is executed by the flow execution function 12.”; Col. 13, lines 38-44 – “Upon receipt of the request issued by the flow editing function 11, the flow execution function 12 analyzes and executes the flow 221. The analysis of the flow 221 includes: analyzing the flow information 13; and recognizing the type of the nodes 222 constituting the flow 221 represented by the flow information 13, the properties, and the connection relationship.”; FIG. 4, “resourceID” is an identifier in a service using node object (“object identifier”) contained in flow information. The user request (user pressing the execution button) causes execution of the flow using the flow information, which contains the resourceID.), query a connector database using […] the object identifier, and based on a result from the connector database, send a request to a connector engine, wherein the connector engine is operable to, based on the request from the universal service: fetch the API connector from the connector database Col. 25, lines 19-46 – “When the process definition 24 of the service using node is executed by the flow execution function 12 during execution of the flow 221, the process definition 24 (program) requests the connection management function 34 to acquire the connection information, with ResourceId included in the property of the service using node being adopted as an argument (P1301). Next, the connection management function 34 acquires the values of the Endpoint 702, the Credential 703 and the Status 704, from the record having the ResourceId 700 coinciding with ResourceId of the argument, in the connection information list 35 (P1302). Subsequently, when the Status 704 is "Running" (P1303: Yes), the connection management function 34 transmits, to the process definition 24, the acquired Endpoint 702 and Credential 703 (P1304). When the Status 704 is "Error" (P1305: Yes), the connection management function 34 notifies the process definition 24 of an error (P1307). The process definition 24 notified of the error interrupts access to the service 70. In the case of interruption, the flow may be executed from the beginning. When the Status 704 is not "Running" nor "Error" (for example, "Provisioning") (P1305: No), the connection management function 34 stands by for a predetermined time (P1306) and subsequently re-executes P1302. That is, when the service 70 is not an error but the service 70 is inaccessible, access to the service 70 is made to stand by.”).
Alurralde Iturri and Ide are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of using an API connector to call an external service in processing of an itinerary. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the method taught by Alurralde Iturri to use a universal service to query the connector database using an object identifier, obtain a response, and cause a connector engine to fetch the API connector at runtime as taught by Ide. Acquiring the connection information, i.e., the “connector”, from a connection information list, i.e., the “connector database”, using an identifier during execution of the flow reduces the load on the user of manually setting the connection information for the service using node when constructing the flow (Ide: Col. 17, line 65-Col. 18, line 4), and receiving a response indicating the status of the service the node is to be connected to ensures the service is not invoked in a state where the service cannot be used (Ide: Col. 25, lines 47-52).
The combination of Alurralde Iturri in view of Ide fails to expressly teach the reusable API connector being defined for reflecting updates in an API of the external service independently of an itinerary using the reusable API connector; and at runtime: receiving a file from a client system; determining the itinerary for processing the file based on a set of attributes associated with the file, the set of attributes comprising: a sender of the file; a receiver of the file; and a document type of the file; the universal service operable to invoke the external service via the reusable API connector without modifying the determined itinerary, the universal service operable to: obtain a customer identifier from the determined itinerary, and query a connector database using the customer identifier, and the connector engine operable to handle results of the call, and return the results to the universal service.
However, Barton teaches at runtime: receiving a file from a client system ([0009] – “receiving a file from a client system of an information exchange platform. The receiving may be performed by a receive process executing on a server machine operating on the information exchange platform.”; [0074] – “operation 200 is triggered by the arrival of a file (e.g., an invoice). There is no human involved in operation 200 at all. Following the above example, the arrival of an invoice from a sender triggers operation 200 and the invoice was received by receive process 205.”); determining the itinerary for processing the file based on a set of attributes associated with the file, the set of attributes comprising: a sender of the file; a receiver of the file; and a document type of the file ([0012] – “the JIT auto-provisioning workflow may include creating a data flow tuple for the processing of the file from the client system. Such a data flow tuple has a set of tuple attributes, including a sender address for the client system, the routing address for the trading partner of the client system, and a document type. The data flow tuple has globally unique attributes within the custom solution and is associated with an itinerary that describes a processing model for processing the document type.”; [0074] – “Receive process 205 may operate to determine an itinerary because the invoice comes from a particular client of the Trading Grid, to a particular email address, and has a particular Doc Type. This specific combination of Sender, Receiver, and Doc Type indicates to receive process 205 that it needs to execute an itinerary which includes normalize process 210 and call JIT provisioning service 215”; [0076] – “tuples can be implemented in functional programming languages as a set of particular attributes ( e.g., Sender, Receiver, Doc Type) with values that can be passed from one program to another, for instance, in a data flow such as document data flow 220. […] a tuple has globally unique attributes and is associated with an itinerary.”; [0078] – “The tuple is passed to another service (e.g., multi-file processor 190 shown in FIG. 1) which takes the information contained in the tuple and determines what itinerary needs to be executed for that particular tuple.”).
Barton is considered to be analogous art to the claimed invention because it is in the same field of data processing in a network computing environment, and more specifically data processing by a plurality of services according to an itinerary in an information exchange platform. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the method taught by Alurralde Iturri in view of Ide to have received a file from a client system and determined the itinerary, or flow of processes performed by services, based on the sender, receiver and document type of the file as taught by Barton. The methods of Barton facilitate the real-time flow of information between disparate entities regardless of differences in standards preferences, spoken languages or geographic locations by using a plurality of services for processing information to be exchanged, and automatically provisions a plurality of services required in a scalable, streamlined and cost-effective manner (Barton: [0007]-[0008], [0036] and [0038]-[0039]).
The combination of Alurralde Iturri in view of Ide and Barton fails to expressly teach the reusable API connector being defined for reflecting updates in an API of the external service independently of an itinerary using the reusable API connector; the universal service operable to invoke the external service via the reusable API connector without modifying the determined itinerary, the universal service operable to: obtain a customer identifier from the determined itinerary, and query a connector database using the customer identifier, and the connector engine operable to handle results of the call, and return the results to the universal service.
However, Douglas teaches obtain a customer identifier from the determined itinerary, and query a connector database using the customer identifier ([0052] – “One or more workflow integration microservices may be configured to permit users of the core application to create one or more workflows comprised of sequential steps. Each step may correspond to an action to be taken using a connector profile from one or more connector microservice(s) (e.g., sources of information)”; [0058] – “a connector profile may include instance-level detail information pertaining to a specific customer or account.”; [0065] – “A connector manager provides a request with profile information to a response factory”), and the connector engine operable to handle results of the call, and return the results ([0065] – “A connector manager provides a request with profile information to a response factory. The response factory may include one or more connectors, such as a JsonAPI connector, an XMLAPI connector, a SOAP API connector, or any other connector. […] One or more of the connectors of the response factory may execute the request, for example, my transmitting information to a third-party application and/or receiving information from the third-party application and optionally returning that information to a sender of the original request or entity associated with such sender.”).
Douglas is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of using an API connector to call an external service in processing of an itinerary. Douglas teaches customer-specific information may be included in a connector profile that is part of a workflow (“itinerary”), wherein the connector profile is provided in a request to a response factory that includes a plurality of connectors (Douglas: [0058] and [0065]). Douglas suggests using connector profiles specific to particular customers or accounts provides the benefit of enabling generic connectors which can be used across multiple workflows to include details specific to a particular user (Douglas: [0058] and [0122]). Further, Ide teaches a user identifier may be stored as part of the credentials in a record of the connection information list (“connector database”) to be queried (Ide: FIG. 7, Col. 10 lines 35-47). Accordingly, it would have been obvious to one of ordinary skill in the art that the connection list of Ide could have been queried to identify a connection information record using a user (“customer”) identifier in addition to the resourceID (“object identifier”). Further, it would have been obvious to one of ordinary skill in the art to have modified the method taught by Alurralde Iturri in view of Ide using the teachings of Douglas such that the connection engine handles results of the call and returns the information to the entity which sent the request, i.e., the universal service of Ide. Alurralde Iturri suggests results may be returned from the external service in response to the call made by the API connector (Alurralde Iturri: [0083]); accordingly the system of Alurralde Iturri necessarily has a means to handle the results. Further, returning the results to the universal service of Ide would make the results available for processing by the next step of the workflow (Douglas: [0065]).
The combination of Alurralde Iturri in view of Ide, Barton, and Douglas fails to expressly teach the reusable API connector being defined for reflecting updates in an API of the external service independently of an itinerary using the reusable API connector; the universal service operable to invoke the external service via the reusable API connector without modifying the determined itinerary.
However, Kocchar teaches the reusable API connector being defined for reflecting updates in an API of the external service independently of an itinerary using the reusable API connector (Col. 4, lines 13-29 – “The connector 118 can provide a standardized mechanism for the workflow service 115 to communicate with a third-party service 127. Each third-party service 127 can provide an application programming interface (API) for communicating, querying, or otherwise interacting with the third-party service 127, which can include different methods or functions with different parameters compared to other third-party services 127. This can allow for the workflow service 115 to send a single, uniformly formatted query to one or more connectors 118. Each connector 118 is then responsible for using the information provided in the query from the workflow service 115 to invoke the appropriate functions provided by the API of the third-party service 127. If a change is made to the API of the third-party service 127, the connector 118 between the workflow service 115 and the third-party service 127 can be updated without having to modify the workflow service 115 itself.”); the universal service operable to invoke the external service via the reusable API connector without modifying the determined itinerary (Col. 4, lines 20-29 – “This can allow for the workflow service 115 to send a single, uniformly formatted query to one or more connectors 118. Each connector 118 is then responsible for using the information provided in the query from the workflow service 115 to invoke the appropriate functions provided by the API of the third-party service 127. If a change is made to the API of the third-party service 127, the connector 118 between the workflow service 115 and the third-party service 127 can be updated without having to modify the workflow service 115 itself.”; Col. 6, lines 32-38 – “The connector data 139 includes configuration data associated with the connectors 118. As discussed, the connector 118 can refer to a service or component of the workflow 35 service 115 that can fetch information that may be required by a user of a client device 106. In some examples, the connector data 139 can include data that can be used to determine which connector 118 to use in response to a content query received from a client device 106.”).
Kochhar is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of using an API connector to call an external service in processing of an itinerary. Kochhar teaches a workflow service (analogous to the “universal service” since it can invoke a plurality of third-party services), in managing a workflow, invokes a third-party service via one or more API connectors which reflect updates to the API of their corresponding third-party service without modification to the workflow service (Kochhar: Col. 3, lines 56-64, and Col. 4, lines 6-29). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the reusable API connector used in an itinerary taught by Alurralde Iturri and specifically used by a universal service within the itinerary to invoke an external service as taught by Ide, such that the API connector reflects updates to the API of the external service independently of the itinerary which uses it and such that the external service can be invoked via the API connector without modification to the itinerary in as taught by Kochhar. The API connectors of Kochhar provide the benefit of allowing a user to trigger an action of a third-party service without being redirected to a different application (Kochhar: Col. 11, lines 24-27, Col. 1, lines 26-38). In this manner, it would have been obvious to one of ordinary skill in the art to have combined Alurralde Iturri, Ide, Barton, Douglas, and Kochhar to achieve the invention as recited in claim 1.
Regarding claim 3, the combination of Alurralde Iturri in view of Ide, Barton, Douglas and Kochhar teaches the method according to claim 1. Barton teaches the method further comprising:
passing information about the file and control of the determined itinerary to an orchestration engine of the information exchange platform, wherein processing of the determined itinerary is orchestrated by the orchestration engine of the information exchange platform (FIG. 1, orchestration engine 160; [0013] – “The JIT provisioning subsystem returns a response that contains the many pieces of information needed for downstream processing, including workflow attributes, data flow tuples, and the legal entity and the receiver address for the trading partner of the client system. The orchestration engine utilize the response from the JIT provisioning subsystem to complete processing of the file from the client system and produce a deliverable which is then provided for delivery to the trading partner of the client system just in time as the file is received from the client system.”; [0033] – “Orchestration Engine 160 may process the document based on itinerary 165.”; [0078]-[0079] – “The workflow attributes (which are programmatically and automatically generated by the auto provisioning process described above, for instance, with references to FIGS. 2 and 3) are returned to the orchestration component (e.g., Orchestration Engine 160 shown in FIG. 1) that initiated this whole process. […] The multi-file processor sends the itinerary back to the orchestration component (e.g., Orchestration Engine 160) with the name of the itinerary for execution by the orchestration component (e.g., as part of receive process 205).”).
It would have been obvious to one of ordinary skill in the art to one of ordinary skill in the art before the effective filing date of the invention to have further incorporated the teachings of Barton to pass information about the received file and control of the itinerary to an orchestration engine. The methods of Barton facilitate the real-time flow of information between disparate entities regardless of differences in standards preferences, spoken languages or geographic locations by using a plurality of services for processing information to be exchanged, and automatically provisions a plurality of services required in a scalable, streamlined and cost-effective manner (Barton: [0007]-[0008], [0036] and [0038]-[0039]).
Regarding claim 4, the combination of Alurralde Iturri in view of Ide, Barton, Douglas and Kochhar teaches the method according to claim 1. Barton further teaches wherein the determined itinerary further includes a managed service provided by a backend system operating on the information exchange platform ([0027] – “system 110 operating on Trading Grid 100 […] system 110 may be configured to provide and manage (orchestrate) a very large number (e.g., 50 or more) of services ("managed services").”; [0076] – “an itinerary can be an XML document that describes a processing model for processing a particular Doc Type. For example, processing a certain type of document may require performing a set of managed services on the document”; [0081] – “Each managed service is defined in an itinerary for a tuple (which, as discussed above, was created using an output from the JIT auto-provisioning function and which includes a sender, a receiver, and a Doc Type) for completing a data flow within a custom solution. For instance, itinerary 420 specifies what services are to be used for processing tuple 410b of Doc Type 460 from a client system at customer address 440 to a trading partner' s system at partner address 450.”; [0093] – “Trading Grid computer 716 may include one or more backend systems configured for providing a variety of services to first enterprise computers 712 over network 714.”).
It would have been obvious to one of ordinary skill in the art to one of ordinary skill in the art before the effective filing date of the invention to have further incorporated the teachings of Barton such that the itinerary includes managed services as taught by Barton. The methods of Barton facilitate the real-time flow of information between disparate entities regardless of differences in standards preferences, spoken languages or geographic locations by using a plurality of services for processing information to be exchanged, and automatically provisions a plurality of services required in a scalable, streamlined and cost-effective manner (Barton: [0007]-[0008], [0036] and [0038]-[0039]).
Regarding claim 5, the combination of Alurralde Iturri in view of Ide, Barton, Douglas and Kochhar teaches the method according to claim 1. Alurralde Iturri further teaches the method further comprising:
at design time, providing a connector catalog through a user interface, the connector catalog containing API connectors stored in the connector database, wherein each API connector contains details of an API particular to an external service ([0043] – “the connectors framework 16 may be alternatively shown as communicating with a catalog of connectors that stores the configured connectors 24 for use during development of a process-based software application. Furthermore, the configured connectors 24 may be shown separately from the web services 18 that connectors 24 interface with and call. In such case, the connectors 24 may be shown as separate abstractions or adapters (i.e., separate from but associated with the external services 18) for connecting process steps with associated external services 18, APIs, etc., via the exposed interfaces of the external services 18.”; [0141] – “Once stored in the connectors catalog 66, a developer may readily employ one or more of the editors 22 to browse the connectors catalog 66 and select a connector to facilitate implementing another step of the first process-based software application or a another step of another process-based software application.”; [0169] – “The development environments may be backed by the PCS, such that certain developed software application files are stored in a PCS database (e.g., the connectors catalog 66 of FIG. 2)” The connector catalog is a database storing connectors that is browsed using editors 22 (user interfaces – see [0050]).).
Regarding claim 6, the combination of Alurralde Iturri in view of Ide, Barton, Douglas, and Kochhar teaches the method according to claim 1. Alurralde Iturri further teaches the method further comprising:
at design time, providing a connector building tool for building the reusable API connector for the external service, the connector building tool including a user interface, the user interface including a field for providing a link or address to the API documentation associated with the external service ([0090] – “FIG. 5 shows a second example UI display screen 130, which is accessible via the first UI display screen of FIG. 4, and which represents an example first step 132 of a wizard for creating an example Simple Object Access Protocol (SOAP) connector.”; [0091] – “Accordingly, the current UI display screen 130 displays various UI controls 138 for selecting a source used to access data to be used for the connector. The data may include specifications of a service interface to be used by an existing connector, where the specifications are included in an existing locally stored file; may include specifications pertaining to a portion of a file to be uploaded; or may include specifications accessible via a URL, etc.”; [0093] – “In the example of FIG. 5, the user has selected an existing WSDL file (i.e., “v01.wsdl”), via the file-selection UI control 142, for use with the SOAP connector under construction. Note that the selected WSDL file may include a description of a particular service interface for a service that the connector will connect to on behalf of a process step to be associated with the connector. Note that if the user had selected another option, e.g., to upload connector-related data from a file stored on a network or to use a URL to access content of the connector-related data, that one or more additional different UI controls may be displayed in place of the file-selection drop down control 142.”).
Regarding claim 7, the combination of Alurralde Iturri in view of Ide, Barton Douglas, and Kochhar teaches the method according to claim 1. Alurralde Iturri further teaches the method further comprising:
at runtime, in processing another itinerary containing […], calling the external service using the reusable API connector […] ([0141] – “the method 270 may further specify that the first UI-control-providing step 270 further includes storing the developed connector in a catalog (e.g., the connectors catalog 66 of FIG. 2) of reusable connectors. Once stored in the connectors catalog 66, a developer may readily employ one or more of the editors 22 to browse the connectors catalog 66 and select a connector to facilitate implementing another step of the first process-based software application or a another step of another process-based software application.” Connectors may be reused in process flows (“itineraries”) of other process-based applications. Accordingly, when another process-based application containing a step associated with the connector is deployed and run, the external service will be called using the connector as described in [0061].).
Alurralde Iturri fails to teach the universal service.
However, Ide teaches a universal service (Col. 8, lines 33-35 – “The processing nodes include, for example, a service X using node that invokes the function of the service X via an API.”; Col. 8, lines 64-66 – “On the flow 221, based on the connection relationship between the nodes 222, the execution order of processes by a flow execution function 12 is determined.”; Col. 9, lines 42-48 – “Among nodes 222, there are nodes 222 that invoke the service 70 outside of the visual programming system 10 and uses the function of the service 70, such as the service X using nodes 222-2 and 222-3 described above. Such a nodes are referred to as "service using nodes". One service using node 222 operates a plurality of services 70 in some cases, and operates one service 70 in other cases.”; Col. 9, lines 65-67 – “One service using node may hold a plurality of connection setting properties.” A service using node in a flow can be considered “universal” because the single node may be able to connect to and invoke many services using connection information retrieved during execution of the flow, i.e., “at runtime”, as described in Col. 25, lines 19-46.).
It would have been obvious to one of ordinary skill in the art to have modified the method taught by Alurralde Iturri to use a universal service in the itinerary as taught by Ide. Acquiring the connection information for a service using node, i.e., the “connector”, from a connection information list, i.e., the “connector database”, during execution of the flow reduces the load on the user of manually setting the connection information for the service using node when constructing the flow (Ide: Col. 17, line 65-Col. 18, line 4).
Claim 8 is directed to a system, comprising: a processor; a non-transitory computer-readable medium; and instructions stored on the non-transitory computer-readable medium and translatable by the processor (Alurralde Iturri: FIG. 13, [0175]-[0176]) for: implementing the method of claim 1. Accordingly, claim 8 is rejected as being unpatentable over Alurralde Iturri in view of Ide, Barton, Douglas, and Kochhar for the same reasons presented with respect to claim 1.
Claims 10-14 recite substantially the same limitations as claims 3-7, respectively. Accordingly, claims 10-14 are rejected as being unpatentable over Alurralde Iturri in view of Ide, Barton, Douglas, and Kochhar for the same reasons presented with respect to claims 3-7.
Claim 15 is directed to a computer program product comprising a non-transitory computer-readable medium storing instructions translatable by a processor (Alurralde Iturri: [0176], [0182]) for: implementing the method of claim 1. Accordingly, claim 15 is rejected as being unpatentable over Alurralde Iturri in view of Ide, Barton, Douglas, and Kochhar for the same reasons presented with respect to claim 1.
Claims 17 and 18-20 recite substantially the same limitations as claims 3 and 5-7, respectively. Accordingly, claims 17 and 18-20 are rejected as being unpatentable over Alurralde Iturri in view of Ide, Barton, Douglas, and Kochhar for the same reasons presented with respect to claims 3 and 5-7.
Response to Arguments
Applicant’s arguments with respect to the rejection of claims 1, 8 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, Applicant argues the limitations “determining the itinerary for processing the file based on a set of attributes associated with the file, the set of attributes comprising: a sender of the file; a receiver of the file; and a document type of the file” are not taught by Alurralde Iturri, Ide, Douglas, nor Kochhar. However, the Examiner has relied upon the new reference, Barton (U.S. Pub. No. 2018/0324279), to teach the argued limitations, as presented above in the rejections of the section titled Claim Rejections - 35 USC § 103.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Levitt (U.S. Pub. No. 2021/0006478) teaches a centralized component adapter configured to build adapters to APIs of external third parties from the the API documentation for each external third party service to interact with the external third party service (see [0095] and [0105]).
Burbeck et al. (U.S. Pub. No. 2004/0019630) teaches a method for managing processing of a document comprising identifying a set of services registered for use in processing a document received from a client, where a service is selected from the set and executed on the document, and selection and execution of the services is repeated until a response is returned to the client (see claim 1). Further, communication with at least one service provider is facilitated by a service provider proxy which encapsulates API details with connectors can speak with the service provider (see [0065]).
Vityaz (U.S. Patent No. 11,237,835) teaches a universal computing element which is a computing node than can be integrated with any external services via an API used to create business processes (see Abstract).
Wikipedia (NPL Document: “Just-in-time compilation”) teaches the phrase “just-in-time” in computing, e.g., just-in-time compilation, means something, e.g. compilation, occurs during execution of a program (at run time) rather than before execution (see page 1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194