DETAILED ACTION
This office action is in response to claims filed 20 April 2023.
Claims 1-20 are pending.
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 .
Drawings
The drawings are objected to because in Fig. 3, certain text and elements are illegible. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 20 is objected to because of the following informalities: Claim 20 depends on claim 20 (typo). Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 20, the term “the list of ABX actions” lacks antecedent basis. For examination purposes, the examiner will interpret this as a list of ABX actions similar to those described in claim 15.
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-7, 9-11, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over LAM et al. Patent No.: US 11,082,333 B1 (hereafter LAM), in view of TODD et al. Patent No.: US 10,484,341 B1 (hereafter TODD).
Regarding claim 1, LAM teaches the invention substantially as claimed, including:
A method, comprising:
receiving an indication of a resource type…via an interface of a cloud automation platform ([Column 17, Lines 45-54] In a first step 402, the management system 120 (e.g., the path-identifying module 146) may identify multiple routing paths (i.e., management system 120 receives information used to identify the multiple routing paths via interface/gateway 126), each associated with a serverless execution entity (or a container) for executing a function in the application. In a second step 404, the management system 120 (e.g., the information-acquisition module 148) may determine traffic information on each routing path and/or a characteristic (e.g., a data-transfer cost, a response time and/or a capacity) associated with the serverless execution entity (or container) on each routing path. [Column 12, Lines 13-19] The serverless platform may include one or more serverless execution entities 104 (e.g., instances, virtual machines, containers and/or physical computers), a datastore 106, and hardware resources 108 configured to control and support operations of the serverless execution entities 104 in the cloud environment (i.e., characteristics of serverless execution entities or containers on routing paths indicate the “type” of entity used to fulfil the requested function; for example, virtual machines, containers and/or physical computers comprising CPU, memory, and storage volumes (grouped by “type” as described in [Column 22, Lines 51-53])));
receiving an indication of an Action Based Extensibility (ABX) action via the interface; associating the resource type with the ABX action to create a resource action responsive to an input via the interface ([Column 17, Lines 36-41] FIG. 4 is a flow chart illustrating an exemplary procedure 400 for allocating resources to an application having multiple application components for executing one or more functions that have been uploaded to a serverless service provider 102 or a container provider via, for example, the terminal 124 and/or interface 126. [Column 6, Lines 23-27] The container system may include a Kubernetes container system, and the function(s) may include an AWS LAMBDA function, a Google cloud function, a Microsoft Azure function, an IBM OpenWhisk function, an Oracle Cloud function, and/or a Kubernates-based Knative function (i.e., the function uploaded to the serverless service provider or container provider represents an “Action Based Extensibility Action” because it represents a “serverless” computer program or script (see claim 4), made to an Amazon Web Services lambda service (see claim 5) or a Microsoft Azure service (see claim 6))); and
deploying a blueprint containing a resource of the resource type ([Column 13, Lines 32-38] The memory 134 may include instructions, such as a path-identifying module 146 for identifying multiple routing paths, each associated with a serverless execution entity and/or a container (or a cluster of containers) for executing a function in a computing application, and deploying equivalent functions onto the serverless execution entities located on the routing paths (i.e., deploying functions onto selected resource types deploys a “blueprint” specifying the association between functions and resources)), wherein the resource action is executable to modify an internal state of the resource ([Column 17, Lines 54-64] In a third step 406, the management system 120 (e.g., the path-selection module 150) may select one of the routing paths and its associated serverless execution entity or container based at least in part on the determined traffic information and/or characteristic of the serverless execution entity (or container) on each routing path (i.e., selection of the routing path creates the “resource action” which represents an action to deploy the selected serverless execution entity or container using the serverless extensibility action). In a fourth step 408, the management system 120 (e.g., the recommendation module 152) may cause the computing function requester to access the serverless execution entity (or container) on the selected routing path and execute the function thereon (i.e., execution of the function using the serverless execution entity or container changes the “state” of serverless execution entity or container from not executing the function to now executing the function)).
While LAM discusses deployment of functions on serverless execution resources of cloud providers, LAM does not explicitly teach deployment of functions on resources of:
a software-defined datacenter (SDDC).
However, in analogous art that similarly teaches deployment of functions on computing resources, TODD teaches deployment of those functions on resources of:
a software-defined datacenter (SDDC) ([Column 3, Lines 56-64] An information processing system that comprises cloud infrastructure and a platform stack used for development, management, and deployment of applications hosted by computing resources that are part of the cloud infrastructure. The cloud infrastructure in one embodiment comprises an infrastructure-as-a-service (IaaS) approach with a plurality of clouds that form a plurality of data centers (e.g., software defined data centers or SDDCs) (i.e., applications representing “functions” execute on resources of the SDDC));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined TODD’s teaching of executing applications on resources of a software defined data center, with LAM’s teaching of executing application functions on resources provided by serverless execution resources, to realize, with a reasonable expectation of success, a system that executes applications on serverless execution resources, as in LAM, which are provided by a SDDC, as in TODD. A person having ordinary skill would have been motivated to make this combination so that benefits of SDDCs, such as enhanced scalability, lower cost, and simplified management.
Regarding claim 2, LAM further teaches:
the resource action is a custom resource action defined by a user for the resource type ([Column 12, Lines 40-43] The management system 120 is configured to enable users to use one or more service providers 102 to develop and deploy a computing application via user devices and/or terminals 122 (i.e., user terminal enables users to specify a customized computing application/function for deployment and execution using the serverless execution entity or container)).
Regarding claim 3, LAM further teaches:
the resource action is a predefined resource action ([Column 6, Lines 23-27] The container system may include a Kubernetes container system, and the function(s) may include an AWS LAMBDA function, a Google cloud function, a Microsoft Azure function, an IBM OpenWhisk function, an Oracle Cloud function, and/or a Kubernates-based Knative function (i.e., predefining the type of function predefines the extensibility action)).
Regarding claim 4, LAM further teaches:
the ABX action is a serverless script of code ([Column 17, Lines 36-41] FIG. 4 is a flow chart illustrating an exemplary procedure 400 for allocating resources to an application having multiple application components for executing one or more functions that have been uploaded to a serverless service provider 102 or a container provider via, for example, the terminal 124 and/or interface 126. [Column 6, Lines 23-27] The container system may include a Kubernetes container system, and the function(s) may include an AWS LAMBDA function, a Google cloud function, a Microsoft Azure function, an IBM OpenWhisk function, an Oracle Cloud function, and/or a Kubernates-based Knative function (i.e., the function uploaded to the serverless service provider or container provider represents an “Action Based Extensibility Action” because it represents a “serverless” computer program or script)).
Regarding claim 5, LAM further teaches:
the ABX action is an Amazon Web Services lambda ([Column 17, Lines 36-41] FIG. 4 is a flow chart illustrating an exemplary procedure 400 for allocating resources to an application having multiple application components for executing one or more functions that have been uploaded to a serverless service provider 102 or a container provider via, for example, the terminal 124 and/or interface 126. [Column 6, Lines 23-27] The container system may include a Kubernetes container system, and the function(s) may include an AWS LAMBDA function, a Google cloud function, a Microsoft Azure function, an IBM OpenWhisk function, an Oracle Cloud function, and/or a Kubernates-based Knative function (i.e., the function uploaded to the serverless service provider or container provider represents an “Action Based Extensibility Action” because it represents a “serverless” computer program or script, made to an Amazon Web Services lambda service)).
Regarding claim 6, LAM further teaches:
the ABX action is a Microsoft Azure Function ([Column 17, Lines 36-41] FIG. 4 is a flow chart illustrating an exemplary procedure 400 for allocating resources to an application having multiple application components for executing one or more functions that have been uploaded to a serverless service provider 102 or a container provider via, for example, the terminal 124 and/or interface 126. [Column 6, Lines 23-27] The container system may include a Kubernetes container system, and the function(s) may include an AWS LAMBDA function, a Google cloud function, a Microsoft Azure function, an IBM OpenWhisk function, an Oracle Cloud function, and/or a Kubernates-based Knative function (i.e., the function uploaded to the serverless service provider or container provider represents an “Action Based Extensibility Action” because it represents a “serverless” computer program or script, made to a Microsoft Azure service)).
Regarding claim 7, it comprises limitations similar to those of claim 1, and is therefore rejected for at least similar rationale.
Regarding claim 9, LAM further teaches:
a fifth portion configured to receive a description of the resource action ([Column 17, Lines 45-54] In a first step 402, the management system 120 (e.g., the path-identifying module 146) may identify multiple routing paths, each associated with a serverless execution entity (or a container) for executing a function in the application. In a second step 404, the management system 120 (e.g., the information-acquisition module 148) may determine traffic information on each routing path and/or a characteristic (e.g., a data-transfer cost, a response time and/or a capacity) (i.e., characteristics represent a “description” of the eventual deployment action) associated with the serverless execution entity (or container) on each routing path).
Regarding claim 10, LAM further teaches:
the first portion is configured to receive the indication of the resource type via a selection of the resource type from a list of resource types ([Column 17, Lines 45-54] In a first step 402, the management system 120 (e.g., the path-identifying module 146) may identify multiple routing paths (i.e., a “list” of routing paths), each associated with a serverless execution entity (or a container) for executing a function in the application. In a second step 404, the management system 120 (e.g., the information-acquisition module 148) may determine traffic information on each routing path and/or a characteristic (e.g., a data-transfer cost, a response time and/or a capacity) associated with the serverless execution entity (or container) on each routing path. [Column 17, Lines 54-60] In a third step 406, the management system 120 (e.g., the path-selection module 150) may select one of the routing paths and its associated serverless execution entity or container based at least in part on the determined traffic information and/or characteristic of the serverless execution entity (or container) on each routing path (i.e., routing path including resource types are selected from the list of routing paths)).
Regarding claim 11, LAM further teaches:
the list of resource types includes:
a disk; a virtual computing instance; and a volume ([Column 12, Lines 13-19] The serverless platform may include one or more serverless execution entities 104 (e.g., instances, virtual machines, containers and/or physical computers), a datastore 106, and hardware resources 108 configured to control and support operations of the serverless execution entities 104 in the cloud environment (i.e., characteristics of serverless execution entities or containers on routing paths indicate the “type” of entity used to fulfil the requested function; for example, virtual machines, containers and/or physical computers comprising CPU, memory, and storage volumes/disks))).
Regarding claims 16, 18, and 19, they comprise limitations similar to claims 1, 4, and 11 above, and are therefore rejected for at least similar rationale.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over LAM, in view of TODD, as applied to claim 7 above, and in further view of JING et al. Pub. No.: US 2023/0214251 A1 (hereafter JING)
Regarding claim 8, while LAM and TODD discuss performing resource actions, LAM and TODD do not explicitly teach:
a fourth portion configured to receive a name of the resource action.
However, in analogous art that similarly teaches resource allocation in response to a request, JING teaches:
a fourth portion configured to receive a name of the resource action ([0138] In an embodiment, the first resource allocation request may carry a resource name (i.e., resource name represents a name associated with the resource allocation “action”), and a quantity of computing resources, a quantity of storage resources, a quantity of network resources, and the like that the user expects to purchase. In addition, a first resource allocation request may further carry a type of a computing resource, a type of a storage resource, a type of a network resource, and the like that are specified by the user).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined JING’s teaching of specifying a name associated with a request to allocate a quantity of computing resources of different types, with LAM and TODD’s teaching of allocating and deploying functions on serverless resources, to realize, with a reasonable expectation of success, a system that allocates and deploys functions on serverless resources, as in LAM and TODD, associated with names specified in a request for the resources, as in JING. A person having ordinary skill would have been motivated to make this combination to facilitate easier identification and lookup of resource actions via names.
Claims 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over LAM, in view of TODD, as applied to claim 7 above, and in further view of “Create a Lambda Function with the console” Available at https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html. Available on 21 January 2022 (hereafter AWS LAMBDA).
Regarding claim 12, while LAM and TODD discuss execution of ABX lambda actions, LAM and TODD do not explicitly teach:
the second portion is configured to receive the indication of the ABX action via a selection of the ABX action from a list of ABX actions.
However, in analogous art that similarly teaches execution of ABX lambda actions, AWS LAMBDA teaches:
the second portion is configured to receive the indication of the ABX action via a selection of the ABX action from a list of ABX actions
PNG
media_image1.png
414
1768
media_image1.png
Greyscale
(i.e., user chooses to create a function from a list of functions on the functions page”)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined AWS LAMBDA’s teaching of a function list allowing users to select ABX functions to implement in serverless AWS Lambda services, with the combination of LAM and TODD’s teaching of executing ABX functions in serverless AWS lambda services, to realize, with a reasonable expectation of success, a system that executes ABX functions in serverless AWS lambda services, as in LAM and TODD, based on a user selection of the ABX functions, as in AWS LAMBDA. A person having ordinary skill would have been motivated to make this combination to give a user more control over functions performed by the serverless system.
Regarding claim 14, AWS LAMBDA further teaches:
the list of ABX actions is determined based on the resource type.
PNG
media_image2.png
343
1235
media_image2.png
Greyscale
(i.e., when the resource type is a container, the lambda function is determined to be a container image)
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over LAM, in view of TODD, in view of AWS LAMBDA as applied to claim 12 above, and in further view of “AWS Classic” Available at https://www.pulumi.com/registry/packages/aws/api-docs/lambda/getfunction/. Available on 13 August 2022 (hereafter PULUMI).
Regarding claim 13, AWS LAMBDA further teaches:
the list of ABX actions includes:
create;
PNG
media_image1.png
414
1768
media_image1.png
Greyscale
update;
PNG
media_image3.png
438
1752
media_image3.png
Greyscale
(i.e., saving changes to the function “updates” the function)
delete; and
PNG
media_image4.png
274
1662
media_image4.png
Greyscale
While AWS LAMBDA discloses various ABX actions, LAM, TODD, and AWS LAMBDA do not explicitly teach:
the list of ABX actions includes…get.
However, in analogous art which similarly describes various ABX actions, PULUMI teaches:
the list of ABX actions includes…get.
PNG
media_image5.png
836
1427
media_image5.png
Greyscale
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined PULUMI’s teaching of a lambda getFunction, with the combination of LAM, TODD, and AWS LAMBDA’s teaching of a list of lambda ABX actions, to realize, with a reasonable expectation of success, a system having a list of lambda ABX actions, as in LAM, TODD, and AWS LAMBDA, having a getFunction, as in PULUMI. A person having ordinary skill would have been motivated to make this combination to enable the system to use a getFunction to gather information on a lambda function to make more optimal decisions.
Claims 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over LAM, in view of TODD, in view of AWS LAMBDA as applied to claim above, and in further view of “Set up Start VM on Connect” Available at https://learn.microsoft.com/en-us/azure/virtual-desktop/start-virtual-machine-connect?tabs=azure-portal. Available on 26 December 2022 (hereafter AZURE).
Regarding claim 15, LAM further teaches:
the resource type is a virtual computing instance ([Column 12, Lines 13-19] The serverless platform may include one or more serverless execution entities 104 (e.g., instances, virtual machines, containers and/or physical computers), a datastore 106, and hardware resources 108 configured to control and support operations of the serverless execution entities 104 in the cloud environment)
While LAM teaches performing ABX actions when the resource type is a virtual machine, LAM, TODD, and AWS LAMBDA does not explicitly teach that those ABX actions include:
wherein the list of ABX actions includes: power on; power off; and shut down guest operating system.
However, in analogous art that similarly teaches performing ABX actions when the resource is a virtual machine, AZURE teaches:
wherein the list of ABX actions includes: power on; power off; and shut down guest operating system.
PNG
media_image6.png
670
1900
media_image6.png
Greyscale
(i.e., Start VM on Connect represents an Azure ABX action that configures start up and shut down of a VM and corresponding guest OS)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined AZURE’s teaching of ABX actions including startup and shutdown of VMs and corresponding guest OS’s, with the combination of LAM, TODD, and AWS LAMBDA’s teaching of ABX actions based on resource type, to realize, with a reasonable expectation of success, a system that performs ABX actions based on a virtual machine resource type, as in LAM, TODD, and AWS LAMBDA, which include startup, and shutdown of VMs and guest OS’s. A person having ordinary skill in the art would have been motivated to make this combination to enable improved control over virtual machines to reduce costs.
Regarding claim 20, it comprises limitations similar to those of claim 15, and therefore stand rejected in view of the art and motivations applied to claims 12, 14, and 15. These have been omitted for the sake of brevity.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195