DETAILED ACTION
Claims 1, 8, and 15 are amended. Claims 1-20 are pending in the application.
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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). 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(s) fully consider the references 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 09/03/2025 has been entered.
Response to Amendment
Amendments to paragraph [0091] are fully considered and are satisfactory to overcome the corresponding objections directed to the specification 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lachaume (US 2016/0154870 A1) in view of Grefenstette et al. (JP 4849730 B2; hereinafter Grefenstette; references are made to the corresponding English translation), Douglas et al. (US 2020/0401465 A1; hereinafter Douglas), and Pfeil et al. (US 2019/0347583 A1; hereinafter Pfeil).
With respect to claim 1, Lachaume teaches: A method for generating an application programming interface (API) connector for an external service called by an orchestration engine operating on an information exchange platform, the method comprising:
at design time (see e.g. Lachaume, paragraph 30: “developers can use the API framework to efficiently create app connectors 128, 130, 132… developer may choose to develop an app connector 128, 130, 132 on top of an API 129, 131, 133”), generating the API connector (see e.g. Lachaume, paragraph 29: “an application connector (app connector) 128, 130 and 132, respectively, each of which may be built from or include an application programming interface (API) 129, 131, and 133, respectively”; and paragraph 30: “development of the app connectors 128, 130 and 132 (e.g., developers can use the API framework to efficiently create app connectors 128, 130, 132… developer may choose to develop an app connector 128, 130, 132 on top of an API 129, 131, 133, in which case the app connector would wrap the API in its core and extend it”; and Fig. 1: “App connector 128, 130, 132”) for the external service (see e.g. Lachaume, Fig. 1: “ESB 102”; paragraph 20: “application engine 110 and services 140, 150 communicate with the ESB 102 via networks 170, 174 and 178”; paragraph 30: “app connector… may be configured to permit an application to publish data to a channel… app connector 128, 130 and 132 may also be configured to receive and process data received from a channel”; and paragraph 32) based on documentation (see e.g. Lachaume, paragraph 30: “libraries that provide out-of-the-box functions”) describing the external service (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be built from or include an API 129, 131, and 133… APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102 and that can simplify the development of the app connectors 128, 130 and 132 (e.g., developers can use the API framework to efficiently create app connectors 128, 130, 132 with minimal programming/coding effort being required). The developer may choose to develop an app connector 128, 130, 132 on top of an API 129, 131, 133, in which case the app connector would wrap the API in its core and extend it”)
generating… a set of services (see e.g. Lachaume, Fig. 1: “Management service 112”, “Configuration service 114”, “Routing service 116”, “Storage service 118”, “Compute service 120”) to transact on the orchestration engine (see e.g. Lachaume, Fig. 1: “Application engine 110”; and paragraph 25: “application engine 110 may include a management service 112, a configuration service 114, a routing service 116, a storage service 118, and a compute service 120”), the set of services comprising a first service (see e.g. Lachaume, Fig. 1: “Compute service 120”) with the API connector for calling the external service (see e.g. Lachaume, paragraph 29: “compute service 120 may run multiple application instances, e.g., such as application instances 122, 124 and 126… each application instance 122, 124 and 126 may be associated with an application connector (app connector) 128, 130 and 132”; and paragraph 30), the set of services provided by the information exchange platform (see e.g. Lachaume, paragraph 5: “a computer processing platform with a communication backbone referred to herein as an enterprise service bus (ESB), for managing the exchange and sharing of business data between applications running on a common operating platform”; paragraph 25: “application engine 110 may include a management service 112, a configuration service 114, a routing service 116, a storage service 118, and a compute service 120”; and Fig 1),
receiving, at runtime of the orchestration engine (see e.g. Lachaume, Fig. 1: “Management service 112”), a request to transact the set of services (see e.g. Lachaume, paragraph 25: “management service 112 may be configured to control and manage the compute, storage, configuration and routing services. The management service 112 manages the lifecycle of applications by ensuring that resources are optimally allocated for each service. The management service 112 may also serve as a point of contact between an external client and the application engine 110”);
transacting the set of services… including the first service (see e.g. Lachaume, paragraph 25: “control and manage the compute, storage, configuration and routing services”; and paragraphs 26-29) transacting with the external service (see e.g. Lachaume, paragraph 30: “APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102”; and paragraph 32: “application instances 122, 124 and 126 of the application engine 110 may communicate with the ESB 102 via a network 170. According to the present disclosure, the ESB 102 is a primary component (along with various application connectors, platform connectors, and APIs) of data management and distribution functionality that may be implemented using software and one or more server computers to facilitate communication between hosted applications, cloud-based applications and web services”) through the API connector (see e.g. Lachaume, paragraph 32: “application instances 122, 124 and 126 of the application engine 110 may communicate with the ESB 102 via a network 170…the ESB 102 is a primary component (along with various application connectors, platform connectors, and APIs) of data management and distribution functionality that may be implemented using software and one or more server computers to facilitate communication between hosted applications, cloud-based applications and web services”), the transacting comprising:
passing, using the API connector (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be built from or include an API 129, 131, and 133, respectively. In this regard, the APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102”), a value (see e.g. Lachaume, paragraph 46: “the app connector, e.g., 128, 130, 132 (e.g., using functionality of an API 129, 131, 133), creates a corresponding new object for the ESB side. The app connector, e.g., 128, 130, 132 can extract relevant fields from the new/updated object (e.g., name, surname and email address of a new employee) and can create a new data object using these fields. More generally, to facilitate the object creation process for the ESB side, the app connector, e.g., 128, 130, 132 may access existing transformation tables which may correlate the field names used for objects at the client (application) side and field names used for objects at the ESB side. The type of object (e.g., “employee”), can added to the data object by the app connector, e.g., 128, 130, 132 (e.g., using API functionality)”) for the customer identifier (see e.g. Lachaume, paragraph 30: “app connectors however constructed may be configured to manage client specific metadata as well as object substantive data to facilitate the object updating and communication as described herein. Such metadata may include client identification information”) to the external service (see e.g. Lachaume, paragraph 46: “extract relevant fields from the new/updated object (e.g., name, surname and email address of a new employee) and can create a new data object using these fields. More generally, to facilitate the object creation process for the ESB side, the app connector, e.g., 128, 130, 132 may access existing transformation tables which may correlate the field names used for objects at the client (application) side and field names used for objects at the ESB side”);
receiving a response from the external service (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may also be configured to receive and process data received from a channel… functions and suitable framework to facilitate communication with the ESB 102”; and paragraph 49: “Once that is done, the ESB access layer 104 may send to the application instance, e.g., 122, 124, 126, a notification message with a “success” status code and the associated unique identifier, e.g., UUID”), the response based on the customer identifier (see e.g. Lachaume, paragraph 30: “app connectors however constructed may be configured to manage client specific metadata as well as object substantive data to facilitate the object updating and communication as described herein. Such metadata may include client identification information”); and
passing the response to the orchestration engine for processing by the orchestration engine (see e.g. Lachaume, paragraph 49: “Once that is done, the ESB access layer 104 may send to the application instance, e.g., 122, 124, 126, a notification message with a “success” status code and the associated unique identifier, e.g., UUID. Upon receipt of this message, the application instance may attach the unique identifier to its local client-side (application-side) object by updating the corresponding field of its data structure”; and Fig .1).
Even though Lachaume discloses developing API connectors based on API libraries (i.e. documentation) that describe how to communicate with the ESB 102 (i.e. an external service) (see e.g. Lachaume, paragraphs 29-30; Fig. 1), Lachaume does not explicitly disclose these API libraries being provided from third-party services.
However, Grefenstette teaches:
provided by a third-party service provider system (see e.g. Grefenstette, paragraph 43: “A third party document service provider”) that is external to the information exchange platform (see e.g. Grefenstette, paragraph 43: “A third party document service provider may be granted permission by the Document Sole Coordinator/Scheduler to propose itself as a new service or a new document service provider for an existing service… the third party document service provider is given access to an already established data transmission protocol and possible new service services for that existing service. Will be registered as a provider”),
Lachaume and Grefenstette are analogous art because they are in the same field of endeavor: managing communications within an information exchange platform. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Lachaume with the teachings of Grefenstette. The motivation/suggestion would be to increase the extensibility and compatibility with different service providers; thus improving the overall flexibility and information exchange mechanism of the system.
Furthermore, Lachaume does not but Douglas teaches:
storing in a storage the API connector for the external service (see e.g. Douglas, paragraph 13: “a storage configured to store connector profile information”; and paragraph 76: “one or more connector profiles from at least one disk data store 450”);
Lachaume and Douglas are analogous art because they are in the same field of endeavor: utilizing API connectors to establish and manage communications with external services. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Lachaume with the teachings of Douglas. The motivation/suggestion would be to improve processing efficiency associated with establishing communications via the connectors (see e.g. Douglas, paragraphs 76-77).
Even further, Lachaume does not but Pfeil teaches:
according to an itinerary (see e.g. Pfeil, Fig. 5: “Itinerary 501”; paragraph 30: “compiles the identified travel services into one or more proposed itineraries 310”; and paragraph 35: “reservations for services during a current travel itinerary”), … wherein the itinerary is one of a plurality of itineraries (see e.g. Pfeil, paragraph 30: “itineraries 310 based on the available travel services”) and wherein the API connector is reusable for calling the external service (see e.g. Pfeil, paragraph 15: “integrate with a variety of travel service platforms (e.g., using Application Programming Interfaces (APIs), and reserve certain travel services”) according to the plurality of itineraries (see e.g. Pfeil, paragraph 25: “creation of a customized travel itinerary(ies) and may also act as a booking agent to reserve travel services (e.g., booking/reservations 320)”; and paragraph 15);
corresponding to the itinerary (see e.g. Pfeil, paragraph 30: “itineraries are simply filtered and automatically booked”; and paragraph 35: “monitors reservations for services during a current travel itinerary and will automatically book new services”),
obtaining, by the first service from the itinerary, a customer identifier for a customer associated with the external service (see e.g. Pfeil, paragraph 4: “reserve the one or more services for the user”; paragraph 25: “act as a booking agent to reserve travel services (e.g., booking/reservations 320”; and paragraph 30: “book appropriate travel services”);
Since Pfeil discloses reserving/booking services for a particular user/customer in a personalized manner (see e.g. Pfeil, paragraphs 4, 13, 25, 30), Pfeil inherently discloses providing a user/customer identifier to the service provider for the reservation/booking.
Lachaume and Pfeil are analogous art because they are in the same field of endeavor: establishing API connections to utilize external services. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Lachaume with the teachings of Pfeil. The motivation/suggestion would be to increase the user friendliness of the system (see e.g. Pfeil, paragraph 3).
With respect to claim 2, Lachaume as modified teaches: The method of claim 1, wherein a set of variables input to the API connector comprises an address of the external service (see e.g. paragraph 31: “App connectors 128, 130, 132 may be configured for communicating data objects to the ESB 102”) and authentication information for the external service (see e.g. Lachaume, paragraph 36: “preferences initially set up by the user or manager of an application… communicating the updated data to the identified channel(s) and the live application instance(s) of users approved (authorized) for updated data”; and paragraph 60: “authorization action from the customer may send a request to the ESB 102, which maintains the list of applications having agreed to communicate together”) and wherein transacting the set of services including the first service transacting with the external service further comprises:
calling the external service at the address of the external service (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be built from or include an API 129, 131, and 133, respectively. In this regard, the APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102”; paragraph 31: “App connectors 128, 130, 132 may be configured for communicating data objects to the ESB 102”; and paragraph 46); and
authenticating on the external service using the authentication information (see e.g. Lachaume, paragraph 36: “appropriate routing may be accomplished by checking any suitable identifying information associated with the data object, looking up the corresponding channel(s) and/or share group(s) associated with the identifying information (e.g., via suitable tables), identifying any live application instances that are associated with the identified share group(s) for data updates, e.g., excluding any offline applications or online applications that are precluded based on internal security policies (e.g., static or dynamic policies), and communicating the updated data to the identified channel(s) and the live application instance(s) of users approved (authorized) for updated data”; and paragraph 60: “ESB 102, which maintains the list of applications having agreed to communicate together”).
Since Lachaume discloses the API connectors 128, 130, 132 and ESB 102 establishing communication channels over a network 170 and exchanging messages (see e.g. Lachaume, paragraphs 30-31; Fig. 1), Lachaume inherently discloses the API connectors 128, 130, 132 comprising the address for the ESB 102.
With respect to claim 3, Lachaume as modified teaches: The method of claim 2, wherein the address of the external service comprises an address of an API of the external service (see e.g. Lachaume, Fig. 1: “Platform connector 134, 135, 136”; and paragraph 33: “platform connectors 134, 135 and 136 are virtual interfaces that are opened when an application instance of a client and the ESB 102 communicate. A platform connector may be created at connection time and contains the communication specifics for a given application instance, e.g., format of data, endpoint URLs, etc.”) and wherein calling the external service at the address of the external service further comprises:
calling the API of the external service at the address of the API (see e.g. Lachaume, paragraph 48: “app connector, e.g., 128, 130, 132 opens a connection, e.g., platform connector 134, 135, 136, to the ESB 102, and communicates data for the object to the ESB access layer 104”).
Since Lachaume discloses the API connectors 128, 130, 132 establishing communication channels over a network 170 with the Platform connectors 134, 135, 136 which are interfaces for application instances (see e.g. Lachaume, paragraphs 33, 48; and Fig. 1), Lachaume inherently discloses API connectors 128, 130, 132 communicating with corresponding addresses of the Platform connectors 134, 135, 136.
With respect to claim 4, Lachaume as modified teaches: The method of claim 1, wherein the API connector further comprises a set of input variables including the customer identifier (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be a client-specific (application-specific) module… app connectors however constructed may be configured to manage client specific metadata as well as object substantive data to facilitate the object updating and communication as described herein. Such metadata may include client identification information, client program preferences, and client contextual information”) and wherein calling the API connector comprising passing to the external service the value for the customer identifier further comprises:
passing to the external service other values for the set of variables and matching the values to inputs for the external service (see e.g. Lachaume, paragraph 31: “App connectors 128, 130, 132 may be configured for communicating data objects to the ESB 102, validating the object data structure and managing links to other ESB-side objects (e.g.: linking projects with assigned members), and retrieving ESB-side objects based on their identifiers, and retrieving a collection of ESB objects based on attributes values or range of values”).
With respect to claim 5, Lachaume as modified teaches: The method of claim 1, further comprising:
updating the API connector for the external service (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may also be configured to receive and process data received from a channel, e.g., updated data objects that have been updated by other application instance”; and paragraph 46: “The app connector, e.g., 128, 130, 132 can extract relevant fields from the new/updated object (e.g., name, surname and email address of a new employee) and can create a new data object using these fields. More generally, to facilitate the object creation process for the ESB side, the app connector, e.g., 128, 130, 132 may access existing transformation tables which may correlate the field names used for objects at the client (application) side and field names used for objects at the ESB side. The type of object (e.g., “employee”), can added to the data object by the app connector, e.g., 128, 130, 132 (e.g., using API functionality)”);
regenerating the set of services to transact on the orchestration engine (see e.g. Lachaume, paragraph 29: “compute service 120 may run multiple application instances, e.g., such as application instances 122, 124 and 126… each application instance 122, 124 and 126 may be associated with an application connector (app connector) 128, 130 and 132”; paragraph 30: “Each app connector 128, 130 and 132 may also be configured to receive and process data received from a channel, e.g., updated data objects that have been updated by other application instances”; and paragraph 46)
Lachaume does not but Douglas teaches:
storing in the storage the updated API connector for the external service (see e.g. Douglas, paragraph 13: “a storage configured to store connector profile information”; and paragraph 76: “one or more connector profiles from at least one disk data store 450”); and
including retrieving the updated API connector for the external service from the storage (see e.g. Douglas, paragraph 76: “request one or more connector profiles from at least one disk data store 450, and the at least one disk data store 450 is configured to provide at least one requested connector profile”).
Lachaume and Douglas are analogous art because they are in the same field of endeavor: utilizing API connectors to establish and manage communications with external services. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Lachaume with the teachings of Douglas. The motivation/suggestion would be to improve processing efficiency associated with establishing communications via the connectors (see e.g. Douglas, paragraphs 76-77).
With respect to claim 6, Lachaume as modified teaches: The method of claim 5, wherein updating the API connector for the external service is in response to receiving a notification that the external service has been updated (see e.g. Lachaume, paragraph 34: “ESB transport layer 106 may send updated data for objects, or messages notifying of updated data, to an individual client application, a group of client applications, or to all members of a share group via a broadcast communication. The ESB transport layer 106 may send updated object data to a group of client application instances”; and paragraph 55).
With respect to claim 7, Lachaume as modified teaches: The method of claim 1, wherein the API connector further comprises a set of input variables including the customer identifier (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be a client-specific (application-specific) module… app connectors however constructed may be configured to manage client specific metadata as well as object substantive data to facilitate the object updating and communication as described herein. Such metadata may include client identification information, client program preferences, and client contextual information”), the customer identifier passed directly into the orchestration engine (see e.g. Lachaume, paragraph 22: “application engine 110 may be under the control of a first entity or (e.g., a company like Maestrano, or an organization)”) and forwarded to the API connector (see e.g. Lachaume, paragraph 30: “app connectors however constructed may be configured to manage client specific metadata as well as object substantive data to facilitate the object updating and communication as described herein. Such metadata may include client identification information”; and Fig. 1) and one or more other services transacted by the orchestration engine (see e.g. Fig. 1: “Routing service 116”) generate and pass at least one other value in the set of input variables to the API connector (see e.g. Lachaume, paragraph 27: “Routing service 116 may be configured to link applications to the Internet and make them available to customers via a static URL”; and paragraph 30: “Each app connector 128, 130 and 132 may be a client-specific (application-specific) module and may be configured to permit an application to publish data to a channel… Each app connector 128, 130 and 132 may also be configured to receive and process data received from a channel”).
With respect to claims 8-14: Claims 8-14 are 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 for implementing active steps corresponding to the method disclosed in claims 1-7, respectively; please see the rejections directed to claims 1-7 above which also cover the limitations recited in claims 8-14. Note that, Lachaume also discloses a system comprising a processing system and a memory configured to implement the method disclosed in claims 1-7 (see e.g. Lachaume, paragraph 7).
With respect to claims 15-20: Claims 15-20 are directed to a computer program product comprising a non-transitory computer-readable medium storing instructions translatable by a processor for implementing active steps corresponding to the method disclosed in claims 1-5 and 7, respectively; please see the rejections directed to claims 1-5 and 7 above which also cover the limitations recited in claims 15-20. Note that, Lachaume also discloses a non-transitory computer readable medium including program instructions to implement the method disclosed in claims 1-5 and 7 (see e.g. Lachaume, paragraph 8).
Response to Arguments
Applicant's arguments filed 09/03/2025 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to the rejections under 35 U.S.C. §103 directed to claim 1 (Remarks, pages 10-12), the Examiner notes that the features upon which applicant relies (i.e., “API scalability”, “any-to-any connectors”, “minimizing or eliminating manual coding”, etc.) are not recited in the rejected claim(s). Claim 1 at most recites “the API connector for the external service based on documentation describing the external service provided by a third-party service provider system”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
As also noted by the Applicant, Lachaume discloses API connectors, such as API connector 128, that enables communications between application instances and an external enterprise service bus (ESB) which provides services to the application instances (see e.g. Lachaume, paragraph 30: “ Each app connector 128, 130 and 132 may be built from or include an API 129, 131, and 133, respectively. In this regard, the APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102”).
Note that, these connectors are based on APIs 129, 131, 133 which are libraries/documentations that describe how to communicate with the ESB (see e.g. Lachaume, paragraphs 29-30; Fig. 1).
That is, Lachaume discloses an API connector, such as the connector 128, based on a corresponding API documentation, such as API 129, that describes how to communicate with the ESB 102; which in return teaches the limitation “the API connector for the external service based on documentation describing the external service” as recited in the claims.
On the other hand, Lachaume does not explicitly disclose this documentation being “provided by a third-party service provider system”. However, Grefenstette discloses a third-party service provider system providing a document service (see e.g. Grefenstette, paragraph 43: “A third party document service provider may be granted permission by the Document Sole Coordinator/Scheduler to propose itself as a new service or a new document service provider for an existing service”).
Accordingly, Lachaume in view of Grefenstette teaches the limitation “the API connector for the external service based on documentation describing the external service provided by a third-party service provider system” as recited in claim 1, and the Examiner maintains the corresponding rejection. For more details, please see the rejection directed to claim 1 above.
(ii) Regarding claim 1, Applicant argues that Lachaume fails to teach the limitation “transacting the set of services… comprising: calling the API connector” as recited (Remarks, pages 11-12).
However, the Examiner notes that the limitation “calling the API connector” is now removed from the claim with the most recent amendments and, as discussed above, claim 1 does not provide the details regarding API scalability, A2A communications, reducing/elimination manual coding, etc.
As such, the Examiner will consider the limitations “the first service transacting with the external service through the API connector” and how Lachaume discloses these features.
Specifically, Lachaume discloses an application instance 1 122 communicating with the ESB 102 via a corresponding app connector 128 to utilize various services (see e.g. Lachaume, paragraph 30: “Each app connector 128, 130 and 132 may be built from or include an API 129, 131, and 133, respectively. In this regard, the APIs 129, 131, 133 may be considered client-specific (application-specific), as well as language-specific, libraries that provide out-of-the-box functions and suitable framework to facilitate communication with the ESB 102”; paragraph 32: “application instances 122, 124 and 126 of the application engine 110 may communicate with the ESB 102 via a network 170. According to the present disclosure, the ESB 102 is a primary component (along with various application connectors, platform connectors, and APIs) of data management and distribution functionality that may be implemented using software and one or more server computers to facilitate communication between hosted applications, cloud-based applications and web services”).
That is, app connector 128 enables transacting between the services and the application instance 1 112 through the ESB 102.
Consequently, Lachaume teaches the limitation “the first service transacting with the external service through the API connector” as recited in claim 1, and the Examiner maintains the corresponding rejection. For more details, please see the rejection directed to claim 1 above.
(iii) Applicant’s arguments with respect to claims 2-20 are fully considered; however, in view of the above discussions (i) and (ii), they are not found to be persuasive. Consequently, the Examiner maintains the rejections directed to claims 2-20. For details, please see the corresponding rejections above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
McCabe et al. (US 2005/0228677 A1) discloses a consumer agent that produces an itinerary providing links to one or more services (see paragraph 22).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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 L Young can be reached on (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.
/UMUT ONAT/Primary Examiner, Art Unit 2194