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 .
DETAILED ACTION
Claims 1-20 are pending.
Examiner Notes
Examiner cites particular paragraphs and/or columns and lines in the references as applied to Applicant’s claims for the 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 in 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. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Authorization for Internet Communications in a Patent Application
Applicant is encouraged to file an Authorization for Internet Communications in a Patent Application form (http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) along with the response to this office action to facilitate and expedite future communication between Applicant and the examiner. If the form is submitted then Applicant is requested to provide a contact email address in the signature block at the conclusion of the official reply.
Applicant’s Reply Not Fully Responsive
The reply filed on 06/16/2026 is not fully responsive to the prior Office action because of the following omission(s) or matter(s): Applicant’s arguments to the outstanding 35 U.S.C. 101 rejections fail to comply with 37 CFR 1.111(b)-(c) because they amount to a general allegation that the dependent claims are eligible without specifically pointing out how the language of the dependent claims makes the dependent claims eligible in view of the rejections made. Further, they do not show how the amendments avoid such rejections. Applicant’s Remarks are only directed to the independent claims and fail to address any of the abstract idea rejections to the dependent claims. Even if an independent claim is deemed eligible then it does not necessarily mean that all of the dependent claims are also eligible. The response appears to be bona fide, but through an apparent oversight or inadvertence, consideration of some matter or compliance with some requirement has been omitted. Applicant is required to supply the omission or correction to thereby provide a full response to the prior Office action.
Claim Objections
As per claim 1, in ll. 6, the colon at the end of the line should be a semicolon. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1: The claim is a process, machine, manufacture, or composition of matter:
Claim 1. A method of providing a functions as a service (FaaS), the method comprising.
Step 2A Prong One: The claim recites an abstract idea because it includes limitations that can be considered mental processes (concepts performed in the human mind including an observation, evaluation, judgment, and/or opinion). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind or via pen and paper, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea:
selecting, from the plurality of cloud providers, a particular cloud provider for executing the particular function (abstract idea mental process).
Step 2A Prong Two: The abstract idea is not integrated into a practical application because the abstract idea is recited but for generically recited additional computer elements (i.e. data storage, processor, memory, computer readable medium, etc.) which do not add meaningful limitations to the abstract idea amounting to simply implementing the abstract idea on a generic computer using generic computing hardware and/or software (e.g. generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The generic computing components are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using the recited generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea:
at a FaaS framework executing in a first cloud (generic computing components), the FaaS framework managing Application Programming Interfaces (APIs) of a plurality of cloud providers and providing, to applications invoking functions stored by the FaaS framework, a unified API for operations on the functions regardless of which of the plurality of cloud providers is selected to execute a particular function (generic computing components performing extra-solution activity of merely reciting the words "apply it" or an equivalent with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using the computer as a tool to perform the abstract idea):
receiving a first API call invoking a particular function that is stored by the FaaS framework (generic computing components performing extra-solution activity of receiving data/information);
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function (generic computing components performing extra-solution activity of generating data/information); and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function (generic computing components performing extra-solution activity of sending/transmitting data/information).
Step 2B: The claim includes limitations which can be considered extra-solution activity (see MPEP 2106.05(g)) insufficient to amount to significantly more than the abstract idea because the additional limitations only perform at least one of collecting, gathering, displaying, generating, modifying, updating, storing, retrieving, sending, and receiving data/information data which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d)II. The claim further includes limitations that do not integrate the judicial exception into a practical application because they merely recite the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f). Therefore, the claim, and its limitations when considered separately and in combination, is directed to patent ineligible subject matter:
the FaaS framework managing Application Programming Interfaces (APIs) of a plurality of cloud providers and providing, to applications invoking functions stored by the FaaS framework, a unified API for operations on the functions regardless of which of the plurality of cloud providers is selected to execute a particular function (extra-solution activity of merely reciting the words "apply it" or an equivalent with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using the computer as a tool to perform the abstract idea):
receiving a first API call invoking a particular function that is stored by the FaaS framework (extra-solution activity of receiving data/information);
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function (extra-solution activity of generating data/information); and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function (extra-solution activity of sending/transmitting data/information).
Claim 2. The method of claim 1 further comprising: receiving, from the particular cloud provider, a result of a desired operation of the particular function; and providing the result to a source of the first API call (extra-solution activity of receiving data/information).
Claim 3. The method of claim 2, wherein after the particular cloud provider provides the result to the FaaS framework, the particular cloud provider discards the particular function (extra-solution activity of modifying/updating data/information).
Claim 4. The method of claim 1, wherein the executable code is written in a particular programming language, wherein identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider that supports the particular programming language (abstract idea mental process).
Claim 5. The method of claim 4, wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a lowest cost for executing the particular function (abstract idea mental process).
Claim 6. The method of claim 4, wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a best set of performance metrics (abstract idea mental process).
Claim 7. The method of claim 4, wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider having a most geographically proximate cloud with respect to the first machine (abstract idea mental process).
Claim 8. The method of claim 4, wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises randomly selecting a cloud provider from the at least two different cloud providers (abstract idea mental process).
Claim 9. The method of claim 4, wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises using a set of user-defined selection rules (abstract idea mental process).
Claim 10. The method of claim 1, wherein the particular function is a first function in a plurality of functions stored by the FaaS framework, wherein to invoke the first function, the first API call comprises (i) a name of the first function, (ii) a particular programming language to be used at runtime of the first function, and (iii) a set of input values for the first function (extra-solution activity of receiving data/information).
Claim 11. The method of claim 10, wherein the second API call comprises (i) the executable code in the particular programming language, (ii) the set of input values, and (iii) a set of credentials that allow the FaaS framework to access the particular cloud provider (extra-solution activity of sending/transmitting data/information).
Claim 12. The method of claim 10, wherein the particular programming language is a first programming language in a plurality of programming language in which the plurality of functions stored by the FaaS framework are written (extra-solution activity of receiving data/information), the method further comprising:
at the FaaS framework (generic computing components):
receiving a third API call invoking a second function that is stored by the FaaS framework, the third API call comprising (i) a name of the second function, (ii) a second programming language to be used at runtime of the second function, and (iii) a set of input values for the second function (extra-solution activity of receiving data/information);
selecting, from the plurality of cloud providers, a second cloud provider for executing the second function (abstract idea mental process);
generating, based on the third API call and the selected second cloud provider, a fourth API call in a format compatible with the selected second cloud provider, the fourth API call comprising (i) a set of executable code for the second function in the second programming language, (ii) the set of input values for the second function, and (iii) a second set of credentials that allow the FaaS framework to access the second cloud provider (extra-solution activity of generating data/information); and
sending the fourth API call to the selected second cloud provider for the selected second cloud provider to instantiate and execute the second function (extra-solution activity of sending/transmitting data/information).
Claim 13. The method of claim 10, wherein the plurality of functions stored by the FaaS framework comprises a plurality of user-defined functions provided to the FaaS framework as part of a configuration of the FaaS framework (extra-solution activity of receiving and storing data/information).
As per claim 14, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 15, it has similar limitations as claims 2 and 3 and is therefore rejected using the same rationale.
As per claim 16, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
As per claim 17, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
As per claim 18, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
As per claim 19, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
As per claim 20, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
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 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over
Doan et al. (US 2024/0414071) (hereinafter Doan as previously cited) in view of
Saad et al. (US 2020/0341690) (hereinafter Saad) in view of
Araki (US 2018/0270392) in view of
Agarwal et al. (US 2020/0177476) (hereinafter Agarwal as provided in the Notice of References Cited dated 03/16/2026) in view of
Green (US 2018/0089005) in view of
Chud (US 10,379,838).
As per claim 1, Doan primarily teaches the invention as claimed including a method of providing a functions as a service (FaaS) ([0037] Function as a Service or FaaS), the method comprising:
at a FaaS framework executing in a first cloud (FaaS) ([0037] serverless functions are often dynamically invoked and could be deployed across multiple cloud providers e.g., in the form of Function as a Service or FaaS):
selecting, from the plurality of cloud providers, a particular cloud provider for executing the particular function ([0042] a decision engine or other deployment logic may leverage various algorithms selectable by the user for determining which provider, cloud region, and datacenter may be chosen to execute serverless functions); and
sending executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to execute the particular function ([0066] a decision engine or type of deployment logic can be used to make a decision on which cloud-based service provider is most suitable to receive the serverless function and [0042] a decision engine or other deployment logic may leverage various algorithms selectable by the user for determining which provider, cloud region, and datacenter may be chosen to execute serverless functions).
Doan does not explicitly teach:
the FaaS framework managing Application Programming Interfaces (APIs) of a plurality of cloud providers and providing, to applications invoking functions stored by the FaaS framework, a unified API for operations on the functions regardless of which of the plurality of cloud providers is selected to execute a particular function:
receiving a first API call invoking a particular function that is stored by the FaaS framework;
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function; and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function.
However, Saad teaches:
the FaaS framework managing Application Programming Interfaces (APIs) of a plurality of cloud providers ([0031] FaaS in the cloud and [0032] the system may expose an interface identical to a standard cloud object storage interface e.g., the AWS S3 interface leveraging Amazon Application Programming Interface “API” gateway-based functions). The global compression FaaS may work in the background, and may be transparent to applications that utilize the cloud storage) and providing, to applications invoking functions stored by the FaaS framework ([0030] applications invoke functions).
Saad and Doan are both concerned with FaaS and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Doan in view of Saad because it would provide a way of performing global object compression as a service implemented as a FaaS in the cloud. This means that the customer will need to pay for the storage consumed and for database services for storing some metadata, but the compute will only be charged when an object is stored or retrieved. By utilizing FaaS for this purpose, significant cost savings can be achieved as the implementation of global compression for object storage is optimized for the pricing model of the cloud.
Doan in view of Saad do not explicitly teach:
a unified API for operations on the functions regardless of which of the plurality of cloud providers is selected to execute a particular function:
receiving a first API call invoking a particular function that is stored by the FaaS framework;
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function; and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function.
However, Araki teaches a unified API for operations on the functions regardless of which of the plurality of cloud providers is selected to execute a particular function ([0051] the unified API module provides the APs with an API (function or method) of unified (common) format corresponding to a same (or similar) request/function supported by each of the cloud storages (even when an API of different format with respect to the same (or similar) request/function is provided by each of the cloud storages, the unified API module provides the APs with an API of common format). The common interface provided by the unified API module is referred to as a “unified API”).
Araki and Doan are both concerned with APIs and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Doan in view of Saad in view of Araki because it would provide for a service coordination module to facilitate use of cloud storage by calling unified APIs to access the cloud storage by way of the service coordination module and the service providing apparatus. Hence, the unified API module, the service coordination module, and the service providing apparatus act as a platform to facilitate access to the cloud storage.
Doan in view of Saad in view of Araki do not explicitly teach:
receiving a first API call invoking a particular function that is stored by the FaaS framework;
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function; and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function.
However, Agarwal teaches:
receiving a first API call invoking a particular function that is stored by the FaaS framework ([0041] generate or send an API call configured to invoke a function and [0079] FaaS).
Agarwal and Doan are both concerned with FaaS and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Doan in view of Saad in view of Araki in view of Agarwal because it would provide a way to store the transformed data into a first database component. By storing the data in this manner, as transformed appropriately for storage in the first database component, the above-mentioned transformation and storage may further facilitate use of unique functionality provided by the first database component and/or the first computing system or platform on which the first database component may reside, including access to additional computing resources, larger data sets or data stores, more advanced analytics, more cost-efficient processing, economizing volume or call quantity on cost-metered APIs, higher degrees of privacy, and other benefits that the first computing system or platform may be able to provide that the second computing system or platform otherwise cannot readily achieve. Any unique features of the second database component may also be preserved in the first database component, for example.
Doan in view of Saad in view of Araki in view of Agarwal do not explicitly teach:
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider, the second API call comprising executable code for the particular function; and
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function.
However, Green teaches:
generating, based on the first API and the selected particular cloud provider, a second API call in a format compatible with the selected particular cloud provider ([0013] API interpreter may interpret or translate the request from the application or process in the data request format into an API call which is in a format compatible with an API that is associated with the computing resources and data of the service provider environment and [0030] API interpreter is able to understand the request in the data request format and interpret or translate the request to an API call that is understood by or compatible with the API and further with the computing resources and data of the service provider environment), the second API call comprising executable code for the particular function ([0038] program code allows an API call to automatically trigger a complex operation or function that may beyond the abilities of an API call with commands such as CRUD commands. Thus, the program code may allow simple operations or commands in an API call to build up through a hierarchy to complete complex functions such as a modifying or managing a backend data schema).
Green and Doan are both concerned with APIs and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green because it would provide a way to generate an API specific to the computing resources and data made available by the customer and/or owner of the API and then the API may ultimately be made available to the client. The API may be described as a custom or customized API. The API may provide an interface that is customized or specific to the computing resources and data stores that are made accessible by a customer in the service provider environment.
Doan in view of Saad in view of Araki in view of Agarwal in view of Green do not explicitly teach:
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function.
However, Chud teaches:
sending the second API call comprising the executable code for the particular function to the selected particular cloud provider for the selected particular cloud provider to instantiate and execute the particular function (fig. 7, block 702 cloud-based storage system and col. 9, ll. 31-35 customer can utilize the API development tool to create an API that includes calls that can be utilized by the mobile application to access data and/or execute functions associated with the mobile application and col. 12, ll. 9-14 the service provider network can also receive API calls related to function requests. In response to receiving an API call related to a function request, the service provider network can access code corresponding to the function from a data store and execute the function in accordance with the API call).
Chud and Doan are both concerned with APIs and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud because it would provide one or more services to end-user devices on behalf of a customer of the service provider network. In these situations, updating a configuration of a computing resource that the service provider network is utilizing to implement a service on behalf of the customer can cause unexpected changes to or, in some cases, disruption of the service to the end-user devices. Rollback of the configuration of the computing resource to a previous version can restore the level of performance of the service to the end-user devices. Thus, the efficiency of utilization of the computing resource is improved, the overall number of computing resources utilized to implement the service on behalf of the customer decreases, and latency with respect to requests from the end-user devices decreases.
As per claim 14, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Johnson et al. (US 12,093,669) (hereinafter Johnson as previously cited).
As per claim 2, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud do not explicitly teach receiving, from the particular cloud provider, a result of a desired operation of the particular function; and providing the result to a source of the first API call.
However, Johnson teaches receiving, from the particular cloud provider, a result of a desired operation of the particular function (col. 7, ll. 4-8 execute code and return a result from cloud provider); and providing the result to a source of the first API call (col. 6, ll. 3-20 API call interface for sending requests and receiving responses).
Johnson and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Johnson because it would provide a way for improving compilation performance, refining price-to-performance ratios, and making various provider network services more attractive to developers. Data aggregated during compilation may be used to help inform developers about useful option combinations, which allows those combinations to be used more thoroughly. This could achieve a speed-up in compilation time by compiling a computing application in parallel without being limited by a number of processing cores or other hardware constraints. Further, the compiler application may collect usage data anonymously for developers that opt-in thorough submitted source code and command-line options, which is aggregated from different customers that build the same application. Developers may use a special compiler option to query the most frequently used compiler options for a given source file, which may reveal previously unknown optimizations. As such, the workload on a computing environment is reduced to pre-processing the source files, which a relatively fast procedure.
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Johnson in view of Zhang et al. (US 2022/0214908) (hereinafter Zhang as previously cited).
As per claim 3, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Johnson do not explicitly teach wherein after the particular cloud provider provides the result to the FaaS framework, the particular cloud provider discards the particular function.
However, Zhang teaches wherein after the particular cloud provider provides the result to the FaaS framework, the particular cloud provider discards the particular function ([0011] the function within the microVM can be deleted after the function completes execution).
Zhang and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Johnson in view of Zhang because it would provide a way to reduce cold start time of a serverless function by starting a new function instance from its memory snapshot and primary code segments as well as performing, in parallel, a memory snapshot cloning operation and the primary code segments retrieving operation. Parallelizing execution of these operations can reduce the function cold start latency. A size of the memory snapshot and the primary code segments added together can be much smaller than a size of the original function code package, thereby reducing data retrieval and access times. Cloning a function language runtime environment from a memory snapshot can be faster than creating the function language runtime environment from an original function code package.
As per claim 15, it has similar limitations as claims 2 and 3 and is therefore rejected using the same rationale.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum et al. (US 2021/0194971) (hereinafter Thum as previously cited).
As per claim 4, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud do not explicitly teach wherein the executable code is written in a particular programming language, wherein identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider that supports the particular programming language.
However, Thum teaches wherein the executable code is written in a particular programming language, wherein identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider that supports the particular programming language ([0110] the FaaS cloud may support various programming languages and invokes a corresponding function template which can be pre-configured in the FaaS cloud and identified by the invocation communication initiated by a trigger, and the payload can then be used in the function as executed by the FaaS cloud in function execution and in any further processing and referencing).
Thum and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum because it would provide for serverless computing in a cloud computing execution model in which a cloud provider runs a server, while a user of the cloud provider operates without a server managed by the user e.g., the user is serverless by relying on servers of a cloud provider. This allows dynamic management of machine resources from the cloud provider for improved serverless operations for two-way communication systems by combining event management and serverless code templates in a dynamically managed FaaS platform that can be accessed to improve real-time automation and machine assistance for agents in a two-way communication session. Additionally, unlike a SaaS platform that is explicitly based on calling a uniform resource locator (URL) over a wide area network (WAN) such as the Internet, the resulting system can allow flexible invocation that can correspond to an event in a two-way communication session, improving the operation of devices and networks in a two-way communication system.
As per claim 16, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Naveh et al. (US 2023/0032530) (hereinafter Naveh as previously cited).
As per claim 5, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum do not explicitly teach wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a lowest cost for executing the particular function.
However, Naveh teaches wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a lowest cost for executing the particular function ([0059] select a cloud computer for performing an execution task that optimizes a cost function and minimizes an incurred cost and [0135] a cloud computer that scores a best score e.g., a lowest cost may be selected for executing a program).
Naveh and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Naveh because it would provide a software tool to receive indications of available cloud computers, and an objective function defining weights, costs, or user preferences that are defined with respect to one or more performance parameters e.g., weights of a cost, an execution time, an error rate, or the like. The tool may be configured to decide, according to the disclosed solution, where to execute an execution task in a manner that optimizes the objective function. In some cases, the decision, or a list of cloud computers with their respective scores from the objective function, may be indicated to the users, enabling the user to decide how to handle the execution task in an informed manner and in a user friendly manner. In other cases, the tool may automatically execute the execution task on the best scoring cloud computer.
As per claim 17, it has similar limitations as claim 5 and is therefore rejected using the same rationale.
Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Diwakar (US 2013/0132457) (as previously cited).
As per claim 6, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum do not explicitly teach wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a best set of performance metrics.
However, Dwakar teaches wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider associated with a best set of performance metrics (claim 10 the second cloud computing service provider is determined by the cloud governance module to be selected based upon satisfying optimum performance metric conditions required for the execution of the at least one identified application).
Dwakar and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Dwakar because it would provide for a cloud governance module that can select cloud vendors that offer storage space at a lower cost while under the same compliance with policies as the prior cloud vendors or upon satisfying optimum performance metrics related to compliance with policies. The new selected cloud vendor may meet threshold performance metrics of being the most optimum cost effective cloud vendor with respect to the identified executing application. The cloud governance module can search for cloud vendors having resources that are acceptable according to the policies associated with applications/services. Such resources may be continuously searched, they may be searched at periodic time intervals, or at random instances of time on an "as-needed" basis. The cloud governance module may utilize policy module for searching for such resources. For example, cloud governance module may search for better resources in terms of cost of operation, security strength, support platform type, resource utilization, and/or other parameters useful for executing product in the best or optimum manner.
As per claim 18, it has similar limitations as claim 6 and is therefore rejected using the same rationale.
Claims 7 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Spiers et al. (US 2013/0339949) (hereinafter Spiers as previously cited).
As per claim 7, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum do not explicitly teach wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider having a most geographically proximate cloud with respect to the first machine.
However, Spiers teaches wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises identifying a cloud provider having a most geographically proximate cloud with respect to the first machine ([0039] provisioning system may select a geographically closest cloud provider data center to provision a VM to reduce the amount of time required to communicate data between the tenant data center and cloud provider data center).
Spiers and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Spiers because it would provide a way for cloud provider data centers to be placed in different geographic locations and include hardware optimized for performing certain computational tasks. For instance, cloud provider data center may be located in a first location and may include hardware optimized for performing software development tasks, and another cloud provider data center may be located in a different location and may include hardware optimized for performing product development tasks. Performance of some tasks may be time sensitive, and hence provisioning system may select a geographically closest cloud provider data center to provision a VM to reduce the amount of time required to communicate data between the tenant data center and cloud provider data center. The provisioning system may also balance network delay and hardware optimization when determining which cloud provider data center to select.
As per claim 19, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
Claims 8-9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Seago et al. (US 2014/0173112) (hereinafter Seago as previously cited).
As per claim 8, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum do not explicitly teach wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises randomly selecting a cloud provider from the at least two different cloud providers.
However, Seago teaches wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises randomly selecting a cloud provider from the at least two different cloud providers ([0052] the selection server randomly selects a cloud provider based on the selection policy).
Seago and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Seago because it would provide a server computer system which receives a request to launch a deployment and determines a set of matches from a pool of cloud providers that meets minimum requirements for the deployment. The server computer identifies a selection criteria comprising priority ranking criteria and probability ranking criteria for the deployment. The server computer then determines one of the cloud providers for the deployment from the set of matches based on the priority ranking criteria and the probability ranking criteria.
As per claim 9, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum do not explicitly teach wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises using a set of user-defined selection rules.
However, Seago teaches wherein when at least two different cloud providers support the particular programming language, identifying the particular cloud provider for executing the particular function comprises using a set of user-defined selection rules ([0027] the selection server uses a selection policy defined by an administrator or user to use for selecting a cloud provider for launch of a deployment and [0052] the selection server randomly selects a cloud provider based on the selection policy).
Seago and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Thum in view of Seago because it would provide a way of selecting the cloud provider with the highest priority ranking or the best match via a pluggable infrastructure which supports a user selection of one or more selection policy modules that may be combined to create a custom selection policy for implementation by the selection server. For example, the user may select one or more particular selection policy modules for the priority ranking criteria and one or more particular selection policy modules for the probability ranking criteria. The selection policy modules allow the user to specify parameters such as cost, performance, reliability, internal versus external cloud provider, provider type, provider capacity, and/or date/time of deployment.
As per claim 20, it has similar limitations as claim 8 and is therefore rejected using the same rationale.
Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine et al. (US 11,341,179) (hereinafter Brandwine as previously cited).
As per claim 10, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud do not explicitly teach wherein the particular function is a first function in a plurality of functions stored by the FaaS framework, wherein to invoke the first function, the first API call comprises (i) a name of the first function, (ii) a particular programming language to be used at runtime of the first function, and (iii) a set of input values for the first function.
However, Brandwine teaches wherein the particular function is a first function in a plurality of functions stored by the FaaS framework, wherein to invoke the first function, the first API call comprises (i) a name of the first function (col. 12, ll. 14-38 API calls include the name of the function), (ii) a particular programming language to be used at runtime of the first function (col. 11, ll. 37-60 API call invocation and triggered if the function being triggered is written in the Java programming language, the serverless compute service may allocate a Java Virtual Machine as the resource to run the coded function), and (iii) a set of input values for the first function (col. 12, ll. 14-38 API calls include additional parameters related to the function or metadata and results from one function are sent to another function as input).
Brandwine and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine because it would provide a way for dependent functions to be performed in parallel by different compute units, or depending on complexity of the function, to be performed by one compute unit to reduce delay and resources used in communicating results of one or more functions between different compute units.
As per claim 11, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud do not explicitly teach wherein the second API call comprises (i) the executable code in the particular programming language, (ii) the set of input values, and (iii) a set of credentials that allow the FaaS framework to access the particular cloud provider
However, Brandwine teaches wherein the second API call comprises (i) the executable code in the particular programming language (col. 11, ll. 37-60 API call invocation and triggered if the function being triggered is written in the Java programming language, the serverless compute service may allocate a Java Virtual Machine as the resource to run the coded function), (ii) the set of input values (col. 12, ll. 14-38 API calls include additional parameters related to the function or metadata and results from one function are sent to another function as input), and (iii) a set of credentials that allow the FaaS framework to access the particular cloud provider (col. 26, ll. 25-26 access rights information e.g., access control policies or other encodings of permissions are stored in the data store).
Brandwine and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine because it would provide a service that analyzes media and outputs an evaluation of the media based on inconsistencies within media and differences between source media and the media. A media file may be obtained at a computing resource service provider. The media may be analyzed to generate media results that indicate inconsistencies within the media file and/or differences between the media file and corresponding source media registered with the computing resource service provider. An indication of a significance of the inconsistencies within the media file and/or differences between the registered source media and the media may be generated based on the media results. Source media may be registered and one or more artifacts inserted into the media to enable more efficient comparisons of whether other media is consistent with the registered source media..
As per claim 12, it has similar limitations as claims 1, 10, and 11 and is therefore rejected using the same rationale.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine in view of Govindaraju et al. (US 2020/0186445) (hereinafter Govindaraju as previously cited).
As per claim 13, Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine do not explicitly teach wherein the plurality of functions stored by the FaaS framework comprises a plurality of user-defined functions provided to the FaaS framework as part of a configuration of the FaaS framework.
However, Govindaraju teaches wherein the plurality of functions stored by the FaaS framework comprises a plurality of user-defined functions provided to the FaaS framework as part of a configuration of the FaaS framework ([0114] infrastructure configuration engine configures the FaaS execution engine to use bootstrapped virtual machines for instantiating containers for execution of user-defined functions).
Govindaraju and Doan are both concerned with cloud environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doan in view of Saad in view of Araki in view of Agarwal in view of Green in view of Chud in view of Brandwine in view of Govindaraju because it would provide for an automated-application-installation subsystem that provisions, installs, and configures applications across cloud-computing providers, including applications that invoke functions provisioned and executed through a distributed-function-as-a-service feature of the automated-application-installation subsystem. The automated-application-installation subsystem employs application blueprints to identify components to provision. An application blueprint generally includes component specifications, constraints, and interdependencies. The automated-application-installation subsystem then determines a cost-effective provisioning of the identified components across available cloud-computing providers and installs the application according to the cost-effective provisioning.
Response to Arguments
All of Applicant's arguments have been considered.
Applicant’s arguments with respect to the 35 U.S.C. 103 prior art rejections on pg. 9-11 of the Remarks have been considered but are moot in view of the new grounds of rejection necessitated by Applicant’s amendments because the new grounds 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.
Applicant's arguments regarding the 35 U.S.C. 101 abstract idea rejections on pg. 8-9 of the Remarks have been fully considered but they are not persuasive.
In the Remarks on pg. 8, Applicant argues that the claims are not directed merely to cloud-provider selection. The examiner respectfully traverses. The examiner contends that the main inventive core concept of the invention is directed to the selection of a cloud provider (i.e., see Applicant’s abstract, newly amended title dated 06/16/2026, and dependent claims 4-9 and 16-20). Although the independent claims may involve other features as described by the Applicant, those features are merely considered tangential insignificant extra-solution activity (i.e., executing a FaaS framework, receiving a first API call, generating a second API call, and sending the second API call to the selected cloud provider) executed by generic computing components (i.e., first cloud and cloud provider). Thus, for at least the reasons provided above, Applicant’s arguments are unpersuasive and the rejections are sustained.
On pg. 9 of the Remarks, Applicant alleges that the claims provide an improvement. The examiner respectfully disagrees. If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification (see MPEP 2106.05(a)). That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement and the claim itself must reflect the improvement in technology (emphasis added by the examiner). An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art. The claim must be evaluated to ensure the claim itself reflects the improvement in technology (emphasis added by the examiner). An important consideration in determining whether a claim is directed to an improvement in technology is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or outcome. It is important to note that in order for a method claim to improve computer functionality, the broadest reasonable interpretation of the claim must be limited to computer implementation. That is, a claim whose entire scope can be performed mentally, cannot be said to improve computer technology. Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 120 USPQ2d 1473 (Fed. Cir. 2016) (a method of translating a logic circuit into a hardware component description of a logic circuit was found to be ineligible because the method did not employ a computer and a skilled artisan could perform all the steps mentally). Similarly, a claimed process covering embodiments that can be performed on a computer, as well as embodiments that can be practiced verbally or with a telephone, cannot improve computer technology. See RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1328, 122 USPQ2d 1377, 1381 (Fed. Cir. 2017) (process for encoding/decoding facial data using image codes assigned to particular facial features held ineligible because the process did not require a computer). To show that the involvement of a computer assists in improving the technology, the claims must recite the details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Applicant states in the Remarks that the claims are directed to “abstracting heterogeneous cloud-provider APIs behind a unified interface”, however, the claims do not recite that exact language. Applicant states in the Remarks that the claims are directed to “automatically generating a provider-compatible API call for execution of a function by the selected cloud provider” but fails to explain how or why exactly that provides any sort of improvement. Applicant is reminded of In re Buchner, 929 F.2d 660, 661, 18 USPQ2d 1331, 1332 (Fed. Cir. 1991) (“expert’s opinion on the ultimate legal conclusion must be supported by something more than a conclusory statement”). It appears that Applicant is merely making a conclusory statement. Attorney argument is not evidence unless it is an admission, in which case, an examiner may use the admission in making a rejection (see MPEP § 2129 and § 2144.03 for a discussion of admissions as prior art). The arguments of counsel cannot take the place of evidence in the record. In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965); In re Geisler, 116 F.3d 1465, 43 USPQ2d 1362 (Fed. Cir. 1997) ("An assertion of what seems to follow from common experience is just attorney argument and not the kind of factual evidence that is required to rebut a prima facie case of obviousness."). See MPEP § 716.01(c) for examples of attorney statements which are not evidence and which must be supported by an appropriate affidavit or declaration. The examiner asserts that merely selecting a cloud provider, generating an API call in a format compatible with the selected cloud provider and sending that API call to the selected cloud provider fails to indicate any improvement because it is not being claimed that the API call is actually executing the particular function on the selected cloud provider. Hence, for at least the rationale provided above, Applicant’s arguments are not persuasive and the rejections are maintained.
In the Remarks on pg. 9, Applicant argues that generation of the second API call is not a mental process. The examiner respectfully disagrees because the aforementioned limitation is not being interpreted as a mental process, but instead extra-solution activity of generating data. Thus, for at least the reasons provided above, Applicant’s arguments are unpersuasive and the rejections are sustained.
On pg. 9 of the Remarks, Applicant alleges that the claims provide a specific technological solution. The examiner respectfully traverses. Applicant’s attempt to show that the recited abstract idea is very narrow and specific is not persuasive. A specific abstract idea is still an abstract idea and is not eligible for patent protection without significantly more recited in the claim. An abstract idea does not become non-abstract by limiting the invention to a particular field of use or technological environment, such as the Internet or a computer. Applicant argues that the claims recite “instantiation and execution of a function at the selected cloud provider”. In contrast, the claims actually recite “to instantiate and execute the particular function” (i.e., a mere intention “to” instantiate and execute the particular function absent any actual instantiation and execution). Hence, for at least the rationale provided above, Applicant’s arguments are not persuasive and the rejections are maintained.
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Haghighat et al. (US 2021/0263779) disclose FaaS system enhancements.
Smith et al. (US 2019/0042315) disclose secure edge-cloud function as a service.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Adam Lee whose telephone number is (571) 270-3369. The examiner can normally be reached on M-TH 8AM-5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pierre Vital can be reached on 571-272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/Adam Lee/Primary Examiner, Art Unit 2198 June 26, 2026
Prosecution Insights