DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 5/22/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1-6, 12-15, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez et al. (US 20210200527) in view of Jung et al. (US 11042405).
Regarding claims 1 and 17, Sanchez teaches: A non-transitory machine readable medium storing a program for execution by a set of processing units / A method of providing functions as a service (FaaS) (events triggering execution requests of serverless functions, which may be provided by FaaS providers par. 0052), the method comprising: at a FaaS framework executing in a first cloud (function management engine, which is part of a public cloud computing environment, being used to provide serverless function control and deployment par. 0047): generating, from the first API call, a second API call that directs a set of machines in a second cloud to invoke a second function that performs a desired operation of the first function in the second cloud (the serverless functions executed by one or more cloud providers including AWS Lambdas, Azure functions, or GCP functions par. 0052 - 0055, if the serverless function has not been deployed before, the serverless function definition deployment engine will deploy the serverless function to the FaaS provider and execute the serverless function par. 0062 – 0066); and forwarding the second API call to the second cloud for the set of machines to instantiate the second function after receiving the second API call, to use the second function to perform the desired operation (the serverless function definition deployment engine deploying the different and un-deployed serverless function to the Faas provider and executing the function par. 0052 – 0066), and to discard the second function after performing the desired operation (deletion of instances, which may be implicit based on a timeout or a specific implementation of the FaaS provider par. 0064, which allows for instances to be deleted after execution).
Sanchez does not explicitly state that the API calls invoking the functions are defined by the framework, just that API calls are used to invoke functions.
However, Jung teaches: receiving a first API (Application Programming Interface) call invoking a first function that is defined by the framework (upload component invoking an appropriate API of each registered FaaS infrastructure to ‘create’ the function in that infrastructure Col. 4 Lines 29 - 37);
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sanchez with the teachings of Jung since Jung would enhance the framework/methods of Sanchez by providing advantages such as supporting scheduling and execution of functions across multiple different Faas infrastructures by utilizing spanning FaaS service platforms that can be implemented with any private cloud or public cloud-based infrastructure.
Regarding claim 2, Sanchez teaches: at the FaaS framework: receiving a result of the desired operation from the set of machines in the second cloud (returning indication that serverless function has deployed, needs updating, or various other results returned par. 0063 - 0067); and providing the result of the desired operation to a source of the first API call (the creation of instances or returning of code is to the FaaS provider that had created the request par. 0066 – 68).
Regarding claim 3, Sanchez teaches: wherein the second cloud discards the second function after providing the result (old instances are deleted when new instances are deployed par. 0064).
Regarding claims 4 and 19, Jung teaches: wherein receiving the first API call comprises receiving the first API call from a first application executing on a first machine in the first cloud (upload component receives a function artifact from a registered FaaS infrastructure and invokes the appropriate API Col. 4 lines 29 – 37).
For motivation to combine see claim 1 above.
Regarding claims 5 and 20, Sanchez teaches: wherein said receiving, generating, and forwarding are performed by a software development kit (SDK) that is implemented on the first machine along with the first application and that interfaces with the first application (i) to receive the first API call and (ii) to provide to the first application a result of the desired operation (the serverless function management engine can correspond to the SDK based on the specified functionality par. 0056 – 0067).
Regarding claim 6, Jung teaches: wherein the first API call comprises a first format and the second API call comprises a second format that is compatible with the second cloud (upload component ensures that artifacts are formatted correctly and the specific format and content of metadata can be specified by administrators of FaaS service platform Col. 5 Line 45 – Col. 6 Line 12).
For motivation to combine see claim 1 above.
Regarding claim 12, Sanchez teaches: wherein the first cloud is of a first cloud provider and the second cloud is of a second cloud provider (cloud service providers can be of any type such ones provided by Google, AWS, and Microsoft par. 0002).
Regarding claim 13, Sanchez teaches: wherein the first and second clouds comprise a same cloud (instances created by cloud provider can interact with the same serverless functions/resources par. 0053 – 0055).
Regarding claim 14, Sanchez teaches: wherein the first and second clouds are clouds of a same cloud provider (cloud service providers can be of any type par. 0002).
Regarding claim 15, Jung teaches: wherein the first and second functions comprise user-defined functions (application developers define criterion and policy for given functions Col. 5 Lines 5 – 14).
For motivation to combine see claim 1 above.
Regarding claim 18, Sanchez teaches: receiving a result of the desired operation from the set of machines in the second cloud (returning indication that serverless function has deployed, needs updating, or various other results returned par. 0063 - 0067); and providing the result of the desired operation to a source of the first API call (the creation of instances or returning of code is to the FaaS provider that had created the request par. 0066 – 68), wherein the second cloud discards the second function after providing the result (old instances are deleted when new instances are deployed par. 0064).
Claim(s) 7-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez and Jung and further in view of Sanchez et al. (US 20210200596) hereby known as “Sanchez 596”.
Regarding claim 7, Sanchez 596 teaches: the first API call invokes the first function by including (i) a name of the first function (name attribute of function par. 0043), (ii) a particular programming language to be used at runtime of the first function (programming language used to code function definition par. 0099), and (iii) a set of input values for the first function (input variables par. 0043); and the second API call that directs the set of machines in the second cloud to invoke the second function by including (i) the second function as a set of executable code in the particular programming language that when executed performs the desired operation of the first function (serverless function in some language that executes in an FaaS provider par. 0042 – 0045), (ii) the set of input values (input variables par. 0043), and (iii) a set of credentials that allow the FaaS framework to access the second cloud (attributes relating to description which may obviously include credentials allowing access par. 0042 – 0045 and 0059).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sanchez and Jung with the teachings of Sanchez 596 since the identifier information provided by Sanchez 596 would enhance the FaaS providers by allowing further management of which functions have been instantiated, the status of FaaS provider functions, as well as including other necessary/important information regarding the functions, providing further management options for users.
Regarding claim 8, Sanchez 596 teaches: wherein: the second cloud is provided by a first cloud provider in a plurality of cloud providers (cloud providers can be multiple types par. 0045); and the set of credentials is a first set of credentials in a plurality of sets of credentials stored by the FaaS framework and used by the FaaS framework to access the plurality of cloud providers (function definition may obviously include attributes relating to credentials allowing access par. 0043 and 0059).
For motivation to combine see claim 7 above.
Regarding claim 9, Sanchez 596 teaches: wherein each particular set of credentials is further associated with a particular account for accessing a particular cloud provider in the plurality of cloud providers (credentials issued by cloud computing provider par. 0059).
For motivation to combine see claim 7 above.
Regarding claim 10, Sanchez 596 teaches: wherein generating the second API call further comprises: selecting the first cloud provider from the plurality of cloud providers (choosing FaaS provider from list of examples par. 0045); and using the first set of credentials associated with the first cloud provider to generate the second API call (using credentials issued by cloud computing provider for API calls par. 0059).
For motivation to combine see claim 7 above.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez, Jung, and Sanchez 596 further in view of Heuts et al. (US 11044257).
Regarding claim 11, Heuts teaches: wherein: each set of credentials in the plurality of sets of credentials comprises a set of key value pairs (key value pairs used to obtain resource credentials for protected application resources Col. 10 Lines 41 – 58); and each key value pair in each set of key value pairs comprises at least (i) an identifier of a particular cloud provider for which the set of key value pairs grants access (identifier as key portion of key-value pair Col. 10 Lines 41 – 58), and (ii) an account identifier for use in distinguishing between different accounts associated with a same cloud provider (key portion of API may obviously include identifier that determines different credentials allowing for different access parameters Col. 10 Lines 41 – 58).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sanchez, Jung, and Sanchez 596 with the teachings of Heuts since Heuts provides an enhancement through allowing requests through a resource security API which protects/provides access to protected resources, thereby allowing for account data for hosts to be used as credentials allowing for accessing backend application resources.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez and Jung and further in view of Govindaraju et al. (US 20200186445)
Regarding claim 16, Govindaraju teaches: wherein the FaaS framework is a distributed FaaS framework that executes a plurality of functions for a plurality of applications executing on a plurality of machines in the first cloud (distributed FaaS service that executes one or more FaaS services provided by one or more cloud computing providers par. 0034 – 0037), each application having an associated interface through which to access the distributed FaaS framework (cloud management facility developed to provide administrative and development interface to multiple multi-tenant cloud-computing facilities par. 0014), the plurality of functions defined using a plurality of programming languages (workflow defined by different languages par. 0067).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Sanchez and Jung with the teachings of Govindaraju since the teachings of Govindaraju provides an automated-application-installation subsystem that provisions, installs, and configures applications across a distributed FaaS framework, further providing cost-effective provisioning of components within the framework.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Adams et al. (US 11310335) which discloses using FaaS gateways providing function codes to available serverless computing platforms based on parameters of said platform.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 a.m. - 4:30 p.m..
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, Pierre Vital can be reached at 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 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.
/J.S.M./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198