DETAILED ACTION
Claims 1-24 are pending in this 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 .
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.
Claims 1, 3-6, 8, 10, 11, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. 11,917,012 B2 issued to Wilson et al. in view of U.S. Pub. No. 2023/0030187 A1 to Shankar et al.
As to claim 1, Wilson teaches a method of enabling user access of cloud services provided by multiple distinct cloud computing systems, the method comprising:
receiving, via an application programming interface (API) gateway of a cloud-connected system, an initial API call (Step 200) to a target cloud service (target CSP) (“…Turning to FIG. 2A, in step 200, an application programming interface (API) request is obtained from an application in the CSP. In one or more embodiments of the invention, the API call includes a request to utilize a function for the operation of the application. The function may provide functionalities of, for example, performing data processing, monitoring network traffic for a specified period of time, managing the logins of users for the application, performing security functions, and/or any other functions without departing from the invention…In one or more embodiments of the invention, the API call includes a function call and a set of parameters. The function call and the set of parameters may be in a format readable using a CSP protocol of the CSP in which the function operates…” Col. 5 Ln. 13-27);
determining, via an API hub of the cloud-connected system, a cloud provider identity corresponding to brand-specific API formatting for the target cloud service (Step 202) (“…In step 202, a target CSP analysis is performed to identify a target CSP to perform the API call. In one or more embodiments of the invention, the target CSP analysis includes analyzing the historical API call database to determine potential CSP-specific functions that may service the API call. For example, the historical API call database may specify a function, operating in a second CSP, capable of servicing the API call. The historical API call database may further specify the financial cost, latency cost of the function in the second CSP servicing the API call. The CSP application broker may use the aforementioned information to determine that the function, operating in the second CSP, is the optimal function to service the API call. Following the determination, the second CSP is identified as the target CSP…” Col. 5 Ln. 28-42);
transforming, via a microservice of a transformation and communication engine of the cloud-connected system, the initial API call into a brand-specific API call using brand-specific API formatting corresponding to the cloud provider identity (Step 204) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…” Col. 5 Ln. 43-51); and
communicating, via the transformation and communication engine, the brand- specific API call to the target cloud service (“…In step 206, the CSP API call is sent to the identified target CSP. In one or more embodiments of the invention, the CSP API call may be sent directly to the CSP-specific function operating in the identified target CSP. Alternatively, the CSP API call may be sent to a second CSP application broker operating in the target CSP…” Col. 5 Ln. 52-57).
Wilson is silent with reference to an initial API call in a universal API format.
Shankar teaches an initial API call in a universal API format (“…REST API is a simple and powerful web service based on REST principles. REST API is based on representational state transfer, which is a language-independent architectural style for API and approach to communications often used in web services development. REST API supports both XML and JSON. REST APIs are a resource-oriented alternative to SOAP and use clean URLs (or REST URLs). Unlike SOAP, REST applications use the HTTP build-in headers to carry meta information. REST API uses HTTP requests to access and use data. That data can be used to perform create, read, update, and delete (CRUD) operations concerning resources (e.g., create, read, update, and delete records), which are referred to as GET, POST, PUT, and DELETE operations in REST API parlance. Because REST API calls are stateless, nothing can be retained by a REST service between executions. This is an advantage for distributed internet applications because stateless components can be freely redeployed if something fails, and they can quickly be scaled to accommodate load changes. Today, many APIs are REST in order to accommodate the various types of syntax and platforms that different servers use. The REST model is useful when used, for example, in conjunction with cloud services because binding to a service through an API controls how the URL will be decoded…” paragraph 0064)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson with the teaching of Shankar because the teaching of Shankar would improve the system of Wilson by providing an architectural style (REST API) for designing networked applications, primarily used to build web APIs that enable communication between clients (like browsers, mobile apps) and servers over HTTP.
As to claim 2, Shankar teaches the method of claim 1, wherein the brand- specific API call is formatted according to a brand-specific API format corresponding to the cloud provider identity wherein the initial API call is received in a universal API format without brand-specific API formatting (Step 204) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…” Col. 5 Ln. 43-51).
Shankar teaches wherein the universal API format is a representational state transfer (REST) API format, (“…REST API is a simple and powerful web service based on REST principles. REST API is based on representational state transfer, which is a language-independent architectural style for API and approach to communications often used in web services development. REST API supports both XML and JSON. REST APIs are a resource-oriented alternative to SOAP and use clean URLs (or REST URLs). Unlike SOAP, REST applications use the HTTP build-in headers to carry meta information. REST API uses HTTP requests to access and use data. That data can be used to perform create, read, update, and delete (CRUD) operations concerning resources (e.g., create, read, update, and delete records), which are referred to as GET, POST, PUT, and DELETE operations in REST API parlance. Because REST API calls are stateless, nothing can be retained by a REST service between executions. This is an advantage for distributed internet applications because stateless components can be freely redeployed if something fails, and they can quickly be scaled to accommodate load changes. Today, many APIs are REST in order to accommodate the various types of syntax and platforms that different servers use. The REST model is useful when used, for example, in conjunction with cloud services because binding to a service through an API controls how the URL will be decoded…” paragraph 0064).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson with the teaching of Shankar because the teaching of Shankar would improve the system of Wilson by providing an architectural style (REST API) for designing networked applications, primarily used to build web APIs that enable communication between clients (like browsers, mobile apps) and servers over HTTP.
As to claim 3, teaches the method of claim 2, further comprising:
receiving, via input of a user device or client application server, a desired cloud operation to be performed on the target cloud service (Step 200) (“…Turning to FIG. 2A, in step 200, an application programming interface (API) request is obtained from an application in the CSP. In one or more embodiments of the invention, the API call includes a request to utilize a function for the operation of the application. The function may provide functionalities of, for example, performing data processing, monitoring network traffic for a specified period of time, managing the logins of users for the application, performing security functions, and/or any other functions without departing from the invention…In one or more embodiments of the invention, the API call includes a function call and a set of parameters. The function call and the set of parameters may be in a format readable using a CSP protocol of the CSP in which the function operates…” Col. 5 Ln. 13-27); and
transforming, via the universal API hub of the cloud-connected system, the desired cloud operation into the API format (Step 204) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…” Col. 5 Ln. 43-51).
As to claim 4, Shankar teaches the method of claim 3, wherein the input of the user device or client application server is received via a web browser or a client application on the user device or client application server (Client 210) (“…For example, customer systems 240 of a client 210 can pass requests to standard APIs 224 with one or more key-value pairs for custom data (e.g., custom objects and/or custom fields, for example), and can receive responses from standard APIs 224 with one or more key-value pairs for custom data (e.g., custom objects and/or custom fields). Non-limiting examples of such requests and responses will be described below with reference to FIGS. 5-8…” paragraph 0075).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson with the teaching of Shankar because the teaching of Shankar would improve the system of Wilson by providing a client for initiating requests or api invocation for cloud services.
As to claim 5, Wilson teaches the method of claim 1, wherein the initial API call is transformed via one or more microservices of the transformation and communication engine corresponding each correspond to a different target cloud service (Step 204) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…” Col. 5 Ln. 43-51).
As to claim 6, Wilson teaches the method of claim 1, wherein the brand-specific API call is communicated via the one or more microservices of the transformation and communication engine corresponding to the target cloud service (target CSP) (“…In step 206, the CSP API call is sent to the identified target CSP. In one or more embodiments of the invention, the CSP API call may be sent directly to the CSP-specific function operating in the identified target CSP. Alternatively, the CSP API call may be sent to a second CSP application broker operating in the target CSP…” Col. 5 Ln. 52-57).
As to claim 8, Wilson teaches the method of claim 1, further comprising:
receiving, via the transformation and communication engine, a response from the target cloud service corresponding to the cloud-brand brand-specific API call (Step 208) (“…In step 208, a CSP API response is obtained from the target CSP. In one or more embodiments of the invention, the CSP API response specifies the servicing (or lack thereof) of the API call. Further, the CSP API response may specify additional metrics corresponding to the servicing. For example, the additional metrics may include a timestamp indicating when the API call was serviced, the computing resources used to perform the CSP-specific function, the financial cost for the CSP-specific function to service the API call, and/or any other metrics without departing from the invention. The CSP API response may be in a format readable to the CSP hosting the CSP-specific function…” Col. 5 Ln. 58-67, Col. 6 Ln. 1-2);
transforming, via a microservice of the transformation (“…In step 210, a CSP API response modification is performed to obtain a modified API response. The modified API response may be generated by populating an API response that matches the protocol of the CSP in which the application sending the API call operates. The modified API response may specify the information included in the obtained CSP response…” Col. 6 Ln. 3-9) and
communication engine, the response into a API formatted response (“…In step 212, the modified API response is sent to the CSP application. In one or more embodiments of the invention, by sending the modified API response, the application is notified of the servicing (or, in some occasions, the lack thereof) of the API call initially sent by the application. By providing the modified API response in a format readable to the protocol of the CSP in which the application operates, the application has no need to be aware of the function servicing the API call as one being in a different CSP…” Col. 6 Ln. 10-18); and
returning the universal API formatted response through the API gateway and a web server to a source of the initial API call (Step 212) (“…In step 212, the modified API response is sent to the CSP application. In one or more embodiments of the invention, by sending the modified API response, the application is notified of the servicing (or, in some occasions, the lack thereof) of the API call initially sent by the application. By providing the modified API response in a format readable to the protocol of the CSP in which the application operates, the application has no need to be aware of the function servicing the API call as one being in a different CSP…” Col. 6 Ln. 10-18).
As to claim 10, Wilson teaches the method of claim 8, further comprising: storing the initial API call in an entry of a database of the cloud-connected system; and updating the entry of the database to include the universal API formatted response corresponding to the initial API call (“…In step 214, the historical API call database is updated based on the modified API response. In one or more embodiments of the invention, the historical API call database is updated based on the obtained additional metrics discussed above…” Col. 6 Ln. 19-23).
As to claim 11, see the rejection of claim 1 and 10 above, expect for a processor, and a storage.
Wilson teaches a processor (Processor(s) 402), and a storage (Persistent Storage 406).
As to claim 15, see the rejection of claim 10 above.
As to claim 17, see the rejection of clam 8 above.
Claims 7, 9, 12-14, 16, 22 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. 11,917,012 B2 issued to Wilson et al. in view of U.S. Pub. No. 2023/0030187 A1 to Shankar et al. as applied to claims 1, 11 above, and further in view of U.S. Pat. No. 10,320,983 B2 issued to Fahlgren et al.
As to claim 7, Wilson as modified by Shankar teaches the method of claim 1, however it does not explicitly teaches receiving, via the API gateway of the cloud-connected system, one or more further initial API calls to one or more target cloud services; and
passing the initial API call and the one or more further initial API calls to a message queue of the cloud-connected system for processing.
Fahlgren teaches receiving, via the API gateway of the cloud-connected system, one or more further initial API calls to one or more target cloud services (HTTP request); and
passing the initial API call and the one or more further initial API calls to a message queue of the cloud-connected system for processing (API 120) (“…The API 120 with queue targeted interfaces functions to enable programmatic interaction with queued items. An API 120 is preferably a REST API. The API preferably works according to an HTTP request and response model. HTTP requests (or any suitable request communication) to the communication platform 100 and/or the queue management resource 110 preferably observe the principles of a RESTful design. RESTful is understood in this document to describe a Representational State Transfer architecture as is known in the art. The RESTful HTTP requests are preferably stateless. The components of the communication platform and/or the interface service preferably do not need to remember or store previous communications to be aware of the state. Additionally or alternatively, the API 120 may be used or accessed through application instructions. The API 120 preferably works around a queue instance resource that allows users to query and manage the state of individual call queues. Call queues can be referenced using a queue identifier. When using a REST API, a particular queue may be referenced by a resource URI with the following pattern: “/2010-04-01/Accounts/{AccountSid}/Queues/{QueueSid}”. A queue resource may include various properties such as an identifier, a friendly name (i.e., a user-provided string that identifies the queue), a current size metric, maximum size, average wait time, and/or any suitable property. A queue resource can additionally include a members sub-resource. The members sub-resource is preferably a list of communication sessions currently in the queue. A member instance is preferably the construct or proxy for an enqueued communication session. A member resource can include properties such as data enqueued, wait time, position, queue-state application configuration, and/or any suitable properties. The API 120 is preferably used to query information of the queue resources, but may additionally be used to manipulate or modify aspects of the queue. When the queue resources are used in application instructions, a call router or other suitable communication processor can add, remove, connect, and/or manage members of the queue (i.e., communication sessions of the queue). In one implementation, there is an enqueue instruction, which can be used to add a communication session as a member resource. Attributes of the enqueue instruction can include an action-state application configuration, a wait-state application configuration, other queue-state application configuration, and/or any suitable attribute. The name of the queue may additionally be specified to identify which queue is to be used. If no queue is specified, a default queue can be used. A queue-state application configuration is preferably an absolute or relative URI, but the configuration can alternatively be application logic, an application data file, or any suitable application configuration. Queue-state applications may be limited in their functionality. For example, a wait-state application may be limited to play, say, pause, hangup, redirect, leave, and gather instructions during a telephony communication. Accessing queued members preferably involves using a queue instruction. The queue instruction is preferably specified within a dial instruction. When invoking a queue instruction within a dial instruction, the queue is accessed and the first enqueued communication session is connected. If the queue is empty, one variation may include the dialing entity or agent waiting until a new communication session joins the queue. Alternatively, an error or other suitable response may be returned if the queue is empty or does not exist. An application configuration can be configured with the queue instruction to specify an application to be invoked directly preceding, during, or directly after dequeuing a communication session…” Col. 5 Ln. 40-67, Col. 6 Ln. 1-39).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson and Shankar with the teaching of Fahlgren because the teaching of Fahlgren would improve the system of Wilson and Shankar by providing a queue for temporarily storing data for later retrieval and use.
As to claim 9, Wilson as modified by Shankar teaches the method of claim 8, however it does not explicitly teaches queueing, via a message queue of the cloud-connected system, the universal API formatted response for processing, wherein the universal API formatted response is queued for processing along with further API calls or further responses.
Fahlgren teaches queueing, via a message queue of the cloud-connected system, the API formatted response for processing, wherein the API formatted response is queued for processing along with further API calls or further responses (API 120) (“…The API 120 with queue targeted interfaces functions to enable programmatic interaction with queued items. An API 120 is preferably a REST API. The API preferably works according to an HTTP request and response model. HTTP requests (or any suitable request communication) to the communication platform 100 and/or the queue management resource 110 preferably observe the principles of a RESTful design. RESTful is understood in this document to describe a Representational State Transfer architecture as is known in the art. The RESTful HTTP requests are preferably stateless. The components of the communication platform and/or the interface service preferably do not need to remember or store previous communications to be aware of the state. Additionally or alternatively, the API 120 may be used or accessed through application instructions. The API 120 preferably works around a queue instance resource that allows users to query and manage the state of individual call queues. Call queues can be referenced using a queue identifier. When using a REST API, a particular queue may be referenced by a resource URI with the following pattern: “/2010-04-01/Accounts/{AccountSid}/Queues/{QueueSid}”. A queue resource may include various properties such as an identifier, a friendly name (i.e., a user-provided string that identifies the queue), a current size metric, maximum size, average wait time, and/or any suitable property. A queue resource can additionally include a members sub-resource. The members sub-resource is preferably a list of communication sessions currently in the queue. A member instance is preferably the construct or proxy for an enqueued communication session. A member resource can include properties such as data enqueued, wait time, position, queue-state application configuration, and/or any suitable properties. The API 120 is preferably used to query information of the queue resources, but may additionally be used to manipulate or modify aspects of the queue. When the queue resources are used in application instructions, a call router or other suitable communication processor can add, remove, connect, and/or manage members of the queue (i.e., communication sessions of the queue). In one implementation, there is an enqueue instruction, which can be used to add a communication session as a member resource. Attributes of the enqueue instruction can include an action-state application configuration, a wait-state application configuration, other queue-state application configuration, and/or any suitable attribute. The name of the queue may additionally be specified to identify which queue is to be used. If no queue is specified, a default queue can be used. A queue-state application configuration is preferably an absolute or relative URI, but the configuration can alternatively be application logic, an application data file, or any suitable application configuration. Queue-state applications may be limited in their functionality. For example, a wait-state application may be limited to play, say, pause, hangup, redirect, leave, and gather instructions during a telephony communication. Accessing queued members preferably involves using a queue instruction. The queue instruction is preferably specified within a dial instruction. When invoking a queue instruction within a dial instruction, the queue is accessed and the first enqueued communication session is connected. If the queue is empty, one variation may include the dialing entity or agent waiting until a new communication session joins the queue. Alternatively, an error or other suitable response may be returned if the queue is empty or does not exist. An application configuration can be configured with the queue instruction to specify an application to be invoked directly preceding, during, or directly after dequeuing a communication session…” Col. 5 Ln. 40-67, Col. 6 Ln. 1-39).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson and Shankar with the teaching of Fahlgren because the teaching of Fahlgren would improve the system of Wilson and Shankar by providing a queue for temporarily storing data for later retrieval and use.
As to claim 12, see the rejection of claim 7 above.
As to claim 13, see the rejection of claim 9 above.
As to claim 14, see the rejection of claim 8 and 9 above.
As to claim 16, see the rejection of claim 9 above.
As to claim 22, see the rejection of claims 7 and 9 above.
As to claim 24, see the rejection of claims 1 and 7 above.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. 11,917,012 B2 issued to Wilson et al. in view of U.S. Pub. No. 2023/0030187 A1 to Shankar et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2016/0342453 A1 to Khan et al.
As to claim 21, Wilson as modified by Shankar and Fahlgren teaches the method of claim 1, however it is silent with reference to monitoring, via the universal API hub, a state of each active API call within the cloud-connected system; and storing state information of each active API call in a database communicatively coupled to the universal API hub, wherein the state information is updated as each active API call progresses through the transformation and communication engine and as a response is received from the target cloud service.
Khan teaches monitoring, via the universal API hub, a state of each active API call within the cloud-connected system; and storing state information of each active API call in a database communicatively coupled to the universal API hub, wherein the state information is updated as each active API call progresses through the transformation and communication engine and as a response is received from the target cloud service (“…The state anomaly module 143 may include a software module configured to notify an administrator when an anomaly is identified and provide error parameters associated with the anomaly to assist an administrator in identifying the root cause of an anomaly. The state anomaly module may receive an indication of an anomaly from the log state comparison module and may obtain error parameters associated with the last successful state of the API to identify potential root causes for the anomaly. For example, the state anomaly module may collect potential error parameters or other sources of error associated with the differences identified by the log state comparison module, generate a notification based on the one or more differences between the at least one reference sequence and the state identifiers, and provide information to the graphical user interface module that can be used to provide a graphical presentation of the source of the errors in a API request or other operation of the system. Further, in some embodiments, the state anomaly module may update the state library with new sequences of state identifiers for discovered system interactions that are not errors or new error parameters associated with particular state identifiers. Accordingly, the system can learn from anomalies discovered during operation and can update the reference state library in response to actual log messages and results of API calls. In some embodiments, approval from an administrator may be obtained before updating the state library. Alternatively or additionally, in some embodiments, the anomaly detection system may update the state library automatically as new sequences of state identifiers, API events, and interactions between services and systems are identified… For example, for the API call shown in FIG. 3, the API call has two possible successful sequences of states for the API. Each of the state identifiers indicates a particular API event or operational state for the API call. When the service reaches the particular state triggering an event, the corresponding log message is sent to the log. An event represents a particular activity of the corresponding service. The event may also be referred to as a state or an operational state. A sequence of graph nodes can be used to represent the sequence of state identifiers in a log file interconnected with each API event. A sequence is reflected by arrows showing which state identifier will come after a preceding sequence of state identifiers. Through a service graph, an optional sequence of events can also be represented. For example, for the API call shown in the service graph of FIG. 3, there are two different sequences of state identifiers for the API call. For instance, after state identifier 1 310, state identifier 2 320, state identifier 3 330, and state identifier 4 340 can occur. Alternatively, state identifier 1 can be followed by state identifier 4 340. Displaying alternative sequences of state identifiers is particularly helpful in identifying service behaviors where multiple options can be specified with a single API call. Thus, for example, an API call can be made with varying levels of options resulting in different events being triggered and different state identifiers being generated in different sequences, that can be displayed in a single service graph (as shown in FIG. 3)…Additionally, log messages often contain status messages of various components which are triggered periodically and that may have nothing to do with the operations being carried out. In the process of verification of logs messages against service policy graphs, these noise messages can create discrepancies for actual operation call monitoring. Accordingly, these log messages may be represented as noise calls 322 in a particular event or state. For example, at state identifier 2 320, three periodic messages P1, P2 and P3 can come in any order before or after the state identifier 2 320 is reached. Thus, the three periodic log messages are shown as calling the same state identifier 320. In order to make the anomaly detection more concrete, these periodic log messages can be represented with special state identifiers 322 that do not affect the sequence of state identifiers…” paragraphs 0033/0037/0038).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson and Shankar with the teaching of Khan because the teaching of Kahn would improve the system of Wilson and Shankar by providing an audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of a sequence of activities that have affected at any time a specific operation, procedure, event, or device.
Claims 18-20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. No. 11,917,012 B2 issued to Wilson et al. in view of U.S. Pub. No. 2023/0030187 A1 to Shankar et al. and further in view of U.S. Pub. No. 2012/0311157 A1 to Erickson et al.
As to claim 18, Wilson teaches a method of adding further microservices to a cloud-connected system for accessing cloud services provided by multiple distinct cloud computing systems, the method comprising:
receiving, from a developer user, API call translation information for a new cloud provider and/or a new cloud service of an existing cloud provider specifying at least API call parameters, authentication requirements (managing the logins of users for the application, performing security functions), for the new cloud provider or the new cloud service (Step 200) (“…Turning to FIG. 2A, in step 200, an application programming interface (API) request is obtained from an application in the CSP. In one or more embodiments of the invention, the API call includes a request to utilize a function for the operation of the application. The function may provide functionalities of, for example, performing data processing, monitoring network traffic for a specified period of time, managing the logins of users for the application, performing security functions, and/or any other functions without departing from the invention…In one or more embodiments of the invention, the API call includes a function call and a set of parameters. The function call and the set of parameters may be in a format readable using a CSP protocol of the CSP in which the function operates…” Col. 5 Ln. 13-27);
identifying, via the cloud-connected system, the cloud brand a cloud provider identity and a cloud service corresponding to the API call translation information (Step 202) (“…In step 202, a target CSP analysis is performed to identify a target CSP to perform the API call. In one or more embodiments of the invention, the target CSP analysis includes analyzing the historical API call database to determine potential CSP-specific functions that may service the API call. For example, the historical API call database may specify a function, operating in a second CSP, capable of servicing the API call. The historical API call database may further specify the financial cost, latency cost of the function in the second CSP servicing the API call. The CSP application broker may use the aforementioned information to determine that the function, operating in the second CSP, is the optimal function to service the API call. Following the determination, the second CSP is identified as the target CSP…” Col. 5 Ln. 28-42); and
establishing a new microservice of a transformation and communication engine for the cloud service, the new microservice comprising instructions for bidirectional transformation of API calls and responses between al API format and a brand-specific API format of the new cloud provider or the new cloud service using the API call translation information with instructions for transformation of API calls using the API call translation information (Step 204/Step 208) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…In step 208, a CSP API response is obtained from the target CSP. In one or more embodiments of the invention, the CSP API response specifies the servicing (or lack thereof) of the API call. Further, the CSP API response may specify additional metrics corresponding to the servicing. For example, the additional metrics may include a timestamp indicating when the API call was serviced, the computing resources used to perform the CSP-specific function, the financial cost for the CSP-specific function to service the API call, and/or any other metrics without departing from the invention. The CSP API response may be in a format readable to the CSP hosting the CSP-specific function…” Col. 5 Ln. 43-51, Col. 5 Ln. 58-67, Col. 6 Ln. 1-2).
Wilson is silent with reference to instructions for bidirectional transformation of API calls and responses between a universal API format and a brand-specific API format of the new cloud provider or the new cloud service and
receiving, from a developer user, API call for a new cloud provider and/or a new cloud service of an existing cloud provider specifying at least API call parameters, and response formats for the new cloud provider or the new cloud service.
Shankar teaches instructions for bidirectional transformation of API calls and responses between a universal API format and a brand-specific API format of the new cloud provider or the new cloud service (“…REST API is a simple and powerful web service based on REST principles. REST API is based on representational state transfer, which is a language-independent architectural style for API and approach to communications often used in web services development. REST API supports both XML and JSON. REST APIs are a resource-oriented alternative to SOAP and use clean URLs (or REST URLs). Unlike SOAP, REST applications use the HTTP build-in headers to carry meta information. REST API uses HTTP requests to access and use data. That data can be used to perform create, read, update, and delete (CRUD) operations concerning resources (e.g., create, read, update, and delete records), which are referred to as GET, POST, PUT, and DELETE operations in REST API parlance. Because REST API calls are stateless, nothing can be retained by a REST service between executions. This is an advantage for distributed internet applications because stateless components can be freely redeployed if something fails, and they can quickly be scaled to accommodate load changes. Today, many APIs are REST in order to accommodate the various types of syntax and platforms that different servers use. The REST model is useful when used, for example, in conjunction with cloud services because binding to a service through an API controls how the URL will be decoded…” paragraph 0064)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson with the teaching of Shankar because the teaching of Shankar would improve the system of Wilson by providing an architectural style (REST API) for designing networked applications, primarily used to build web APIs that enable communication between clients (like browsers, mobile apps) and servers over HTTP.
Erickson teaches receiving, from a developer user, API call (developer requests) for a new cloud provider and/or a new cloud service of an existing cloud provider specifying at least API call parameters (input parameters), and response formats (output parameters for the new cloud provider or the new cloud service (cloud service provider website) (“…Once the level of control parameters, input parameters, and output parameters have been defined for each cloud resource component of the cloud resource interface, the parameters are processed to create an API function which is responsive to developer requests on the API function input side, and cloud resource component modification on the API function output side. Block 315 is may be a graphical user-interface API editor for generating API functions in such generic programming languages as C or C#. Alternatively, the API functions have a pre-defined structure for each cloud resource component with arguments for inputs and a fixed expected output type. In this exemplary implementation, block 315 would be automated with a software function capable of generating API functions for each cloud resource component from a set of inputs provided to the block…A completed API function may include an input method, such as an argument input, for receiving input from any software application written by an external software application developer, a level of control parameter value to gauge the level of modification provided to an associated cloud resource component, and an output method to provide modification values in an embedded computer-code, or as plain values to the cloud resource component. Each completed API function is presented in a library of API functions and is stored in an API database (block 325) for use by software application developers and testers. This is illustrated in the exemplary embodiment of FIG. 3, as block 320. The cloud resource management interface that is displayed on a cloud service provider website, upon login by a software application developer, will provide the developer with a link to the list of API functions and tutorials, where applicable, as shown in block 330. The software application developer is restricted to using certain API functions by virtue of login restrictions applicable to the developer based on the developer's SLA with the cloud service provider….” Paragraphs 0044/0045).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Wilson and Shankar with the teaching of Erickson because the teaching of Erickson would improve the system of Wilson and Shankar by providing a technique for allowing developers to request and access cloud services.
As to claim 19, Wilson as modified by Shankar and Ericson teaches the method of claim 18, further comprising: receiving, from a user device or client application server, an initial API call in the API format and a target cloud service, wherein the target cloud service corresponds to the new microservice (Step 200) (“…Turning to FIG. 2A, in step 200, an application programming interface (API) request is obtained from an application in the CSP. In one or more embodiments of the invention, the API call includes a request to utilize a function for the operation of the application. The function may provide functionalities of, for example, performing data processing, monitoring network traffic for a specified period of time, managing the logins of users for the application, performing security functions, and/or any other functions without departing from the invention…In one or more embodiments of the invention, the API call includes a function call and a set of parameters. The function call and the set of parameters may be in a format readable using a CSP protocol of the CSP in which the function operates…” Col. 5 Ln. 13-27).
transforming, via the new microservice of the transformation and communication engine, the initial API call into a brand-specific API call using the API call translation information; and
communicating, via the new microservice of the transformation and communication engine, the brand-specific API call to the target cloud service (Step 204/Step 208) (“…In step 204, a CSP API modification is performed on the API call based on the target CSP to obtain a CSP API call. In one or more embodiments of the invention, the CSP API modification is a process for generating the CSP API call using the function call and parameters of the API call. The function call and parameters are used to populate the CSP API call that matches the protocol of the target CSP in which the function operates. In this manner, the CSP API call is readable to the aforementioned function…In step 208, a CSP API response is obtained from the target CSP. In one or more embodiments of the invention, the CSP API response specifies the servicing (or lack thereof) of the API call. Further, the CSP API response may specify additional metrics corresponding to the servicing. For example, the additional metrics may include a timestamp indicating when the API call was serviced, the computing resources used to perform the CSP-specific function, the financial cost for the CSP-specific function to service the API call, and/or any other metrics without departing from the invention. The CSP API response may be in a format readable to the CSP hosting the CSP-specific function…” Col. 5 Ln. 43-51, Col. 5 Ln. 58-67, Col. 6 Ln. 1-2).
As to claim 20, Wilson teaches the method of claim 19, further comprising:
receiving, via the new microservice of the transformation and communication engine, a response from the target cloud service corresponding to the cloud-brand brand-specific API call (Step 208) (“…In step 208, a CSP API response is obtained from the target CSP. In one or more embodiments of the invention, the CSP API response specifies the servicing (or lack thereof) of the API call. Further, the CSP API response may specify additional metrics corresponding to the servicing. For example, the additional metrics may include a timestamp indicating when the API call was serviced, the computing resources used to perform the CSP-specific function, the financial cost for the CSP-specific function to service the API call, and/or any other metrics without departing from the invention. The CSP API response may be in a format readable to the CSP hosting the CSP-specific function…” Col. 5 Ln. 58-67, Col. 6 Ln. 1-2);
transforming, via the new microservice of the transformation and communication engine, the response into a universal API formatted response using the API call translation information (“…In step 210, a CSP API response modification is performed to obtain a modified API response. The modified API response may be generated by populating an API response that matches the protocol of the CSP in which the application sending the API call operates. The modified API response may specify the information included in the obtained CSP response…” Col. 6 Ln. 3-9); and
returning the universal API formatted response to the user device or client application server (Step 212) (“…In step 212, the modified API response is sent to the CSP application. In one or more embodiments of the invention, by sending the modified API response, the application is notified of the servicing (or, in some occasions, the lack thereof) of the API call initially sent by the application. By providing the modified API response in a format readable to the protocol of the CSP in which the application operates, the application has no need to be aware of the function servicing the API call as one being in a different CSP…” Col. 6 Ln. 10-18).
As to claim 23, Wilson teaches the method of claim 18, wherein establishing the new microservice comprises:
generating a brand-specific API call transformer within the new microservice, the brand-specific API call transformer configured to convert API calls in a universal API format into brand-specific API calls for the new cloud provider or new cloud service, and to convert responses from the new cloud provider or new cloud service into universal API formatted responses (“…In step 210, a CSP API response modification is performed to obtain a modified API response. The modified API response may be generated by populating an API response that matches the protocol of the CSP in which the application sending the API call operates. The modified API response may specify the information included in the obtained CSP response…” Col. 6 Ln. 3-9); and
generating a cloud service communicator within the new microservice, the cloud service communicator configured to transmit the brand-specific API calls to the new cloud provider or new cloud service and to receive responses therefrom (Step 212) (“…In step 212, the modified API response is sent to the CSP application. In one or more embodiments of the invention, by sending the modified API response, the application is notified of the servicing (or, in some occasions, the lack thereof) of the API call initially sent by the application. By providing the modified API response in a format readable to the protocol of the CSP in which the application operates, the application has no need to be aware of the function servicing the API call as one being in a different CSP…” Col. 6 Ln. 10-18).
Response to Arguments
Applicant’s arguments with respect to claims 1-24 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2013/0291121 A1 to Iovanov et al. and directed to techniques to allow optimal use of various cloud service providers.
U.S. Pat. No. 10,416,996 B1 issued to Babu et al. and directed to a method involving receiving a request to call a requested application programming interface (API) at a target cloud platform.
U.S. Pub. No. 2013/0132584 A1 to Palladino et al. and directed to cloud-based hub for facilitating distribution and consumption of application programming interfaces.
U.S. Pat. No. 11,423,111 B2 issued to Vaishnavi et al. and directed to client API for rest based endpoints for a multi-tenant identify cloud service,
U.S. Pub. No. 2023/0123860 A1 to Marquie et al. and directed to facilitating access to api integrations.
U.S. Pub. No. 20230023981 A1 to Wilson et al. and directed to a system for cloud service providers and client(s).
U.S. Pat. No. 9,098,346 B2 issued to Robb et al. and directed to a network device receives a first file having a service-specific Application Programming Interface (API) definition for a first cloud service, and loads the service-specific API definition for the first cloud service into a Cloud Services Layer (CSL) API. The network device receives a service request involving the first cloud service, and handles, at the CSL API, the service request using the service-specific API definition for the first cloud service.
U.S. Pub. No. 20230185645 A1 to Krishnan and directed to a method for receiving, at a first application programming interface (API) endpoint of a first computing system positioned before an egress point of a private network in which an application is executing, an API call from the application; sending, by the first computing system, the API call over the internet to a second API endpoint; and initiating at least a first action based at least in part on a response to the API call being indicative of a deficiency in execution of the API call by the second API endpoint.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights