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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on July 6, 2026 has been entered.
Information Disclosure Statement
The IDS filed July 6, 2026 has been considered.
Allowable Subject Matter
The indicated allowability of claims 21-40 is withdrawn in view of the newly discovered reference(s) in the IDS filed July 6, 2026. Rejections based on the newly cited reference(s) follow.
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) 21-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhandari et al. (US 11934854, hereinafter referred to as “Bhandari”) in view of Anderson et al., (US 8769531, hereinafter referred to “Anderson”).
Regarding claim 21, Bhandari teaches a method implemented by a cloud platform that manages at least one data center, wherein the method comprises:
receiving, from a tenant, a service request comprising information about a total amount of resources required by the tenant (abstract - a computer system can receive a request to provision a virtual machine (VM) in a host cluster), wherein the information comprises a total amount of central processing units (CPUs) and a total amount of memory (abstract - where the VM is associated with a virtual graphics processing unit (GPU) profile indicating a desired or required framebuffer memory size of a virtual GPU of the VM), wherein the total amount of CPUs comprises a number of virtual CPUs (vCPUs) occupied by an instance combination required by the tenant in the at least one data center (col. 3, lines 29-36: Each host system 106 of host cluster 104 also includes, in software, a hypervisor 112 that provides an environment in which one or more VMs can run. For purposes of this disclosure, it is assumed that host systems 106(1)-(N) implement a GPU virtualization technology such as Nvidia's GRID vCPU or AMD's Multiuser GPU and thus the VMs that are run on hypervisors 112(1)-(N) can include virtual GPU-configured VMs.),
wherein the total amount of memory comprises a size of memory occupied by the instance combination (col. 2, lines 41-50: Embodiments of the present disclosure are directed to techniques for placing virtual GPU-configured VMs on physical GPUs that support multiple virtual GPU profiles (i.e., multi-profile physical GPUs). As used herein, the phrase “placing a virtual GPU-configured VM on a physical GPU” refers to the act of allocating (or reserving) a portion of the framebuffer memory of the physical GPU to that VM, where the size of the allocated/reserved portion equals the framebuffer memory size indicated by the VM's virtual GPU profile.);
wherein the instance specification is published by the cloud platform and comprises the number of vCPUs and a size of memory of the instance, wherein the number of vCPUs of each instance combination meets the total amount of CPUs, and wherein the size of memory of each instance combination meets the total amount of memory (abstract - In response, the computer system can execute an algorithm that identifies, from among a plurality of physical GPUs installed in the host cluster, a physical GPU on which the VM may be placed, where the identified physical GPU has sufficient free framebuffer memory to accommodate the desired or required framebuffer memory size, and where the algorithm allows multiple VMs associated with different virtual GPU profiles to be placed on a single physical GPU in the plurality of physical GPUs. The computer system can then place the VM on the identified physical GPU.);
However, Bhandari does not explicitly teach providing, to the tenant, at least one cloud service solution, wherein each of the at least one cloud service solution corresponds to a different instance combination, wherein each instance combination comprises an instance specification of at least one type of instance and a quantity of instances corresponding to each instance specification, and
determining a target cloud service solution selected by the tenant from the at least one cloud service solution, wherein the target cloud service solution corresponds to a target instance combination, and wherein the target instance combination comprises at least two target instances.
In an analogous art, Anderson teaches providing, to the tenant, at least one cloud service solution, wherein each of the at least one cloud service solution corresponds to a different instance combination, wherein each instance combination comprises an instance specification of at least one type of instance and a quantity of instances corresponding to each instance specification, and determining a target cloud service solution selected by the tenant from the at least one cloud service solution, wherein the target cloud service solution corresponds to a target instance combination, and wherein the target instance combination comprises at least two target instances (abstract - Embodiments of the present invention provide an approach for optimizing a configuration of virtual machine (VM) instances. In a typical embodiment, such optimization comprises either the splitting of a single VM instance into multiple VM instances or the consolidation of multiple VM instances into fewer (e.g., a single) VM instance. Along these lines, it will first be determined which VM instances would be good candidates for reconfiguration. Under one approach, VM instances that are candidates for reconfiguration are identified based upon an analysis of applicable/associated service level agreement (SLA) terms versus the performance of the VM instances. For example, VM instances can be reconfigured if such reconfiguration will maximize a benefit provided by the applicable SLA terms (e.g., if the splitting of a single VM instance into multiple VM instances would cause a workload to be processed more efficiently, resulting in a more favorable cost/benefit ratio). In another embodiment, candidate VM instances can be identified based upon a commonality of an entity (e.g., a consumer) associated therewith. For example, if a single entity is utilizing multiple VM instances, such VM instances could be considered candidates for consolidation to avoid unnecessary computing resource consumption.).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the teaching of Anderson into the teaching of Bhandari so that, prior to provisioning, the system determines one or more suitable VM instance configurations satisfying the requested resource requirements, thus improving resource utilization, reducing waste, and increasing deployment flexibility.
Regarding claim 22, Bhandari does not explicitly teach the method of claim 21, further comprising: creating, in the at least one data center, the at least two target instances for the tenant based on the target instance combination in the target cloud service solution; or receiving a modification of the target instance combination by the tenant, and creating, in the at least one data center, one or more instances comprised in a modified instance combination for the tenant based on a modified target instance combination.
Anderson teaches creating, in the at least one data center, the at least two target instances for the tenant based on the target instance combination in the target cloud service solution; or receiving a modification of the target instance combination by the tenant, and creating, in the at least one data center, one or more instances comprised in a modified instance combination for the tenant based on a modified target instance combination (abstract - Embodiments of the present invention provide an approach for optimizing a configuration of virtual machine (VM) instances. In a typical embodiment, such optimization comprises either the splitting of a single VM instance into multiple VM instances or the consolidation of multiple VM instances into fewer (e.g., a single) VM instance. Along these lines, it will first be determined which VM instances would be good candidates for reconfiguration. Under one approach, VM instances that are candidates for reconfiguration are identified based upon an analysis of applicable/associated service level agreement (SLA) terms versus the performance of the VM instances. For example, VM instances can be reconfigured if such reconfiguration will maximize a benefit provided by the applicable SLA terms (e.g., if the splitting of a single VM instance into multiple VM instances would cause a workload to be processed more efficiently, resulting in a more favorable cost/benefit ratio). In another embodiment, candidate VM instances can be identified based upon a commonality of an entity (e.g., a consumer) associated therewith. For example, if a single entity is utilizing multiple VM instances, such VM instances could be considered candidates for consolidation to avoid unnecessary computing resource consumption.).
The motivation to combine the reference is the same as claim 21.
Regarding claim 23, Bhandari does not teach the method of claim 21, wherein the service request further comprises resource performance information, and wherein performance of the instance combination in each cloud service solution meets the resource performance information.
Anderson teaches wherein the service request further comprises resource performance information, and wherein performance of the instance combination in each cloud service solution meets the resource performance information (col. 2, lines 5-14: a performance of the set of VM instances with respect to a set of service level agreement (SLA) terms, or a commonality of an entity associated with the set of VM instances; and optimizing the set of VM instances by performing at least one of the following actions: splitting a single instance of the set of VM instances into multiple instances, or consolidating multiple instances of the set of VM instances into a single instance.).
The motivation to combine the reference is the same as claim 21.
Regarding claim 24, Bhandari teaches the method of claim 23, wherein the resource performance information comprises a performance parameter of underlying resources, and wherein the performance parameter comprises a CPU model, a CPU frequency, a memory model, a memory frequency, a graphics processing unit (GPU) parameter, network performance, or storage read/write performance (col. 5, lines 10-29: In another set of embodiments (detailed in section (4) below), placement manager 114 can use its multi-profile aware placement algorithm 116 and local database 118 to optimally place virtual GPU-configured VMs within host cluster 104 in the case where the host system's physical GPUs support multiple virtual GPU profiles and are heterogeneous in nature (i.e., are instances of two or more different GPU models or architectures). By way of example, a first set of physical GPUs may be Nvidia A100 GPUs and a second set of physical GPUs may be Nvidia V100 GPUs. In these embodiments, each physical GPU model/architecture type can be associated with a predefined priority value indicating the desirability of that model/architecture type as a placement target. For instance, a relatively newer GPU model/architecture type may be associated with a higher priority value (because it is likely to be more performant and/or have more features) while a relatively older GPU model/architecture type may be associated with a lower priority value (because it is likely to be less performant and/or have less features).
Regarding claim 25, Bhandari teaches the method of claim 23, wherein the resource performance information comprises at least one of an instance capability type or a service scenario type, wherein the instance capability type indicates computing capabilities, storage capabilities, and network capabilities of an instance, and wherein the service scenario type indicates a service scenario to which the instance is applicable (col. 7, lines 37-51: To provide a concrete example of the operation of workflow 300, FIG. 4A depicts a scenario in which (a) host cluster 104 comprises two host systems 106(1) and 106(2), and (b) host systems 106(1) and 106(2) include a total of eight homogeneous physical GPUs (400-406 on 106(1) and 408-412 on 106(2)), each with 4 GB of total framebuffer memory. Further, FIG. 4B depicts the results of applying workflow 300 on host cluster 104 of FIG. 4A with respect to the set of VM provisioning requests presented in Table 1. As shown in FIG. 4B, VMs V1-V4 and V11 are successfully placed on physical GPUs 400-406 of host system 106(1) and VMs V5-V10, V12, and V13 are successfully placed on physical GPUs 408-412 of host system 106(2) in accordance with their respective virtual GPU profiles.).
Regarding claim 26, Bhandari teaches the method of claim 21, wherein providing the at least one cloud service solution comprises querying inventory resources based on the information, wherein the inventory resources are available instances in the at least one data center, and wherein the available instances comprise virtual machines (col. 5, lines 9-28: In another set of embodiments (detailed in section (4) below), placement manager 114 can use its multi-profile aware placement algorithm 116 and local database 118 to optimally place virtual GPU-configured VMs within host cluster 104 in the case where the host system's physical GPUs support multiple virtual GPU profiles and are heterogeneous in nature (i.e., are instances of two or more different GPU models or architectures). By way of example, a first set of physical GPUs may be Nvidia A100 GPUs and a second set of physical GPUs may be Nvidia V100 GPUs. In these embodiments, each physical GPU model/architecture type can be associated with a predefined priority value indicating the desirability of that model/architecture type as a placement target. For instance, a relatively newer GPU model/architecture type may be associated with a higher priority value (because it is likely to be more performant and/or have more features) while a relatively older GPU model/architecture type may be associated with a lower priority value (because it is likely to be less performant and/or have less features).
Regarding claim 27, Bandhari teaches the method of claim 23 , wherein providing the at least one cloud service solution comprises: querying, according to the resource performance information in the service request, an inventory resource that meets the resource performance information, wherein the inventory resource is an available instance in the at least one data center, and wherein the available instance comprises a virtual machine (col. 5, lines 9-28: In another set of embodiments (detailed in section (4) below), placement manager 114 can use its multi-profile aware placement algorithm 116 and local database 118 to optimally place virtual GPU-configured VMs within host cluster 104 in the case where the host system's physical GPUs support multiple virtual GPU profiles and are heterogeneous in nature (i.e., are instances of two or more different GPU models or architectures). By way of example, a first set of physical GPUs may be Nvidia A100 GPUs and a second set of physical GPUs may be Nvidia V100 GPUs. In these embodiments, each physical GPU model/architecture type can be associated with a predefined priority value indicating the desirability of that model/architecture type as a placement target. For instance, a relatively newer GPU model/architecture type may be associated with a higher priority value (because it is likely to be more performant and/or have more features) while a relatively older GPU model/architecture type may be associated with a lower priority value (because it is likely to be less performant and/or have less features).
However, Bandhari does not teach combining inventory resources according to the information in the service request to generate at least one instance combination; and providing the at least one cloud service solution to the tenant, wherein each cloud service solution comprises one of the at least one instance combination.
Anderson teaches combining inventory resources according to the information in the service request to generate at least one instance combination; and providing the at least one cloud service solution to the tenant, wherein each cloud service solution comprises one of the at least one instance combination (abstract - Embodiments of the present invention provide an approach for optimizing a configuration of virtual machine (VM) instances. In a typical embodiment, such optimization comprises either the splitting of a single VM instance into multiple VM instances or the consolidation of multiple VM instances into fewer (e.g., a single) VM instance. Along these lines, it will first be determined which VM instances would be good candidates for reconfiguration. Under one approach, VM instances that are candidates for reconfiguration are identified based upon an analysis of applicable/associated service level agreement (SLA) terms versus the performance of the VM instances. For example, VM instances can be reconfigured if such reconfiguration will maximize a benefit provided by the applicable SLA terms (e.g., if the splitting of a single VM instance into multiple VM instances would cause a workload to be processed more efficiently, resulting in a more favorable cost/benefit ratio). In another embodiment, candidate VM instances can be identified based upon a commonality of an entity (e.g., a consumer) associated therewith. For example, if a single entity is utilizing multiple VM instances, such VM instances could be considered candidates for consolidation to avoid unnecessary computing resource consumption.).
The motivation to combine the reference is the same as claim 21.
Regarding claim 28, Bhandari teaches the method of claim 27, wherein the service request further comprises a filtering rule, wherein the filtering rule is a geographical priority, and wherein the geographical priority indicates instances in each cloud service solution correspond to resources in same geographical area or availability zone (col. 4, lines 46-61: To address this and other similar problems, operating environment 100 of FIG. 1 includes a multi-profile aware VM placement manager (hereinafter referred to as simply “placement manager”) 114 that is communicatively coupled with cluster management server 102. As shown, placement manager 114 implements a multi-profile aware placement algorithm 116 and a local database 118. Local database 118 is configured to maintain an up-to-date inventory of the physical GPUs in host cluster 104 that can include, for each physical GPU 108: (a) the host system where the physical GPU is installed/resides, (b) the GPU model/architecture type of the physical GPU, (c) a priority value (if applicable) for the physical GPU, (d) the total amount of framebuffer memory of the physical GPU, and (e) the current amount of available/free (i.e., unallocated) framebuffer memory of the physical GPU.).
Regarding claim 29, Bhandari does not teach the method of claim 27, wherein the service request further comprises a filtering rule, wherein the filtering rule further comprises price priority or performance priority, wherein the price priority indicates that the cloud platform preferentially returns a cloud service solution with a lower price, and wherein the performance priority indicates that the cloud platform preferentially returns a cloud service solution with better performance.
Anderson teaches wherein the service request further comprises a filtering rule, wherein the filtering rule further comprises price priority or performance priority, wherein the price priority indicates that the cloud platform preferentially returns a cloud service solution with a lower price, and wherein the performance priority indicates that the cloud platform preferentially returns a cloud service solution with better performance (abstract - Embodiments of the present invention provide an approach for optimizing a configuration of virtual machine (VM) instances. In a typical embodiment, such optimization comprises either the splitting of a single VM instance into multiple VM instances or the consolidation of multiple VM instances into fewer (e.g., a single) VM instance. Along these lines, it will first be determined which VM instances would be good candidates for reconfiguration. Under one approach, VM instances that are candidates for reconfiguration are identified based upon an analysis of applicable/associated service level agreement (SLA) terms versus the performance of the VM instances. For example, VM instances can be reconfigured if such reconfiguration will maximize a benefit provided by the applicable SLA terms (e.g., if the splitting of a single VM instance into multiple VM instances would cause a workload to be processed more efficiently, resulting in a more favorable cost/benefit ratio). In another embodiment, candidate VM instances can be identified based upon a commonality of an entity (e.g., a consumer) associated therewith. For example, if a single entity is utilizing multiple VM instances, such VM instances could be considered candidates for consolidation to avoid unnecessary computing resource consumption.).
The motivation to combine the reference is the same as claim 21.
Regarding claim 30, Bhandari does not teach the method of claim 27, wherein the service request further comprises price information specified by the tenant, and wherein price of each cloud service solution meets the price information.
Anderson teaches wherein the service request further comprises price information specified by the tenant, and wherein price of each cloud service solution meets the price information (abstract - Embodiments of the present invention provide an approach for optimizing a configuration of virtual machine (VM) instances. In a typical embodiment, such optimization comprises either the splitting of a single VM instance into multiple VM instances or the consolidation of multiple VM instances into fewer (e.g., a single) VM instance. Along these lines, it will first be determined which VM instances would be good candidates for reconfiguration. Under one approach, VM instances that are candidates for reconfiguration are identified based upon an analysis of applicable/associated service level agreement (SLA) terms versus the performance of the VM instances. For example, VM instances can be reconfigured if such reconfiguration will maximize a benefit provided by the applicable SLA terms (e.g., if the splitting of a single VM instance into multiple VM instances would cause a workload to be processed more efficiently, resulting in a more favorable cost/benefit ratio). In another embodiment, candidate VM instances can be identified based upon a commonality of an entity (e.g., a consumer) associated therewith. For example, if a single entity is utilizing multiple VM instances, such VM instances could be considered candidates for consolidation to avoid unnecessary computing resource consumption.).
The motivation to combine the reference is the same as claim 21.
Regarding claim 31, Bhandari teaches the method of claim 21, wherein the total amount of CPUs comprises total CPU quantity, a maximum value of the total CPU quantity, a minimum value of the total CPU quantity, and wherein the total amount of memory comprises total memory quantity, a maximum value of the total memory quantity, and a minimum value of the total memory quantity (col. 3, line 56 to col. 4, line 14: In addition, at the time of provisioning such virtual GPU-configured VMs within host cluster 104, a placement algorithm is executed for “placing” the VMs on the cluster's physical GPUs, which involves (a) identifying, for each VM, a physical GPU that has sufficient free framebuffer memory to accommodate (i.e., fit) the VM's desired/required framebuffer memory size, as defined by the VM's virtual GPU profile, and (b) allocating (or reserving) that amount of the physical GPU's framebuffer memory to the VM. For instance, consider the example scenario shown in FIG. 2A where host cluster 104 comprises two host systems 106(1) and 106(2) and these host systems include a total of four physical GPUs 200-206 (two on 106(1) and another two on 106(2)), each with 4 GB of framebuffer memory. In this scenario, if a cluster administrator submits requests to provision three virtual GPU-configured VMs V1, V2, and V3—each with a virtual GPU profile of 4 GB—in host cluster 104, V1 can be successfully placed on physical GPU 200 of host system 106(1), V2 can be successfully placed on physical GPU 202 of host system 106(1), and V3 can be successfully placed on physical GPU 204 of host system 106(2) as depicted in FIG. 2B. Further, if the cluster administrator subsequently submits a request to provision a fourth virtual GPU-configured VM V4 with a virtual GPU profile of 2 GB, V4 can be successfully placed on physical GPU 206 of host system 106(2) as depicted in FIG. 2C.).
Regarding claim 32, Bhandari does not teach the method of claim 21, further comprising providing the tenant with a unit price for each cloud service solution, wherein the unit price refers to an average price of instances in each cloud service solution, and wherein the average price includes a price for purchasing one month or one hour of the cloud service solution on a yearly/monthly or pay-as-you-go basis.
Anderson teaches providing the tenant with a unit price for each cloud service solution, wherein the unit price refers to an average price of instances in each cloud service solution, and wherein the average price includes a price for purchasing one month or one hour of the cloud service solution on a yearly/monthly or pay-as-you-go basis (col. 8, lines 28-49: In one example, management layer 64 may provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and pricing provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources may comprise application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. Consumer portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provides prearrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA. Further shown in management layer is VM instance optimization, which represents the functionality that is provided under the embodiments of the present invention.).
The motivation to combine is the same as claim 21.
Claims 33-38 are similar to claims 21-25, respectively, therefore are rejected under the same rationale.
Claims 39-40 are similar to claims 21 and 23, respectively, therefore are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pai, US 20160381128 - computing system instances may include an instance type indicating an amount of computing resources allocated to computing system instance of the instance type. The instance service may obtain requirement and/or constraints associated with the workload and determine a configuration of instance types to include in a set of instances configured to execute the customer workload.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/ Primary Examiner, Art Unit 2458
Prosecution Insights