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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-8, 10-15, 17-22 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Objections
Claim 6 is objected to because of the following informalities:
Claim 6 discloses “Determine” (line 3), however, it is recommended that this is revised to “determine.”
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 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 of this title, 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-5, 11-13, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 2014/0201371, hereinafter Gupta’371) in view of Gupta et al. (US 11,500,663, hereinafter Gupta’663).
Regarding claim 1, Gupta’371 discloses
A system, comprising:
a processor; and a memory device (paragraph [0038]: The hardware, for example, can include processing resources 440, memory resources 442, and/or machine readable medium (MRM) 444 (e.g., computer readable medium (CRM), database, etc.) that stores program code configured to be executed by the processor, the program code comprising a resource manager (paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) configured to:
receive a request by an entity for virtual machine (VM) allocation, the request comprising a number of VMs, a first priority VM type, and a second priority VM type (paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications);
provision the request for VM allocation with available VMs of the first priority VM type (paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted; paragraph [0035]: assignment of the number of VMs can depend upon available capacity of the plurality of nodes, topology (e.g., proximity relationships of the plurality of nodes), node homogeneity (e.g., homogeneity relationships of the plurality of nodes), and/or priority of the number of VMs, among other);
determine a capacity shortage of VMs of the first priority VM type to fulfill the request for VM allocation (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users)); and
provision the request for VM allocation with available VMs of the second priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request).
Gupta’371 does not disclose a capacity analyzer configured to: predict a future request for VM creation by the entity, including predicted compute capacity and a predicted timeframe, based on a past VM creation; and the resource manager further configured to: reserve the predicted compute capacity at the predicted timeframe before the resource manager receives the request for VM allocation; and release the reserved predicted compute capacity at the predicted timeframe if the request for VM allocation is not received within a time threshold based on a start time of the predicted timeframe. Gupta’663 discloses a capacity analyzer configured to: predict a future request for VM creation by the entity, including predicted compute capacity and a predicted timeframe, based on a past VM creation (col. 5, lines 17-29: The inventory system 130 in FIG. 1 retrieves and examines the records from the history database and detects cyclical virtual machine usage patterns on an individual user account basis. In the example of FIG. 2, the inventory system 130 would determine that every Thursday at around 5:00 pm user account abcd123 is likely to request 5 or 6 virtual machines of type xyz and request that those 5 or 6 virtual machines be launched in different racks. Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines); and the resource manager further configured to: reserve the predicted compute capacity at the predicted timeframe before the resource manager receives the request for VM allocation (col. 5, lines 24-36: Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines. Thus, when the user actually does submit the launch request for the virtual machines, the hosts to be used to execute the requested virtual machines has already been reserved for the user account and the placement service 120 need only cause the relevant machine images to be loaded on the hosts whose slots have been allocated to the user account and the virtual machines to be executed); and release the reserved predicted compute capacity at the predicted timeframe if the request for VM allocation is not received within a time threshold based on a start time of the predicted timeframe (co. 7, lines 40-48: The allocation also may include a start time and a value indicative of an end time. The start time may be the day and time included in the prediction (5 pm every Thursday in the example above). The start time may comprise a time earlier than the prediction's time value (e.g., 4:45 pm) to account for variations in when users may submit launch requests; col. 8, lines 8-10: Upon expiration of the end time, the allocation is considered invalid and the allocated slots in the specified hosts can be used to launch virtual machines for any user accounts).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 by incorporating Gupta’663’s generating a virtual machine usage prediction for each of the user accounts in advance of the weekly time period in which the user is predicted to likely launch the VMs, creating allocation of slots including start time and end time before the user actually submits the launch request for the VMS, and allocating the slots to other user upon expiration of the end time. The motivation would have been to increase the probability that the provider network will be able to honor more launch requests (Gupta’663 paragraph [0034]).
Regarding claim 11, Gupta’371 discloses
A method comprising:
receiving a request by an entity for virtual machine (VM) allocation, the request comprising a number of VMs, a first priority VM type, and a second priority VM type (paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications);
provisioning the request for VM allocation with available VMs of the first priority VM type (paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted; paragraph [0035]: assignment of the number of VMs can depend upon available capacity of the plurality of nodes, topology (e.g., proximity relationships of the plurality of nodes), node homogeneity (e.g., homogeneity relationships of the plurality of nodes), and/or priority of the number of VMs, among other);
Gupta’371 does not disclose predicting a future request for VM creation by the entity, including predicted compute capacity and a predicted timeframe, based on a past VM creation; reserving the predicted compute capacity at the predicted timeframe before the resource manager receives the request for VM allocation; and releasing the reserved predicted compute capacity at the predicted timeframe if the request for VM allocation is not received within a time threshold based on a start time of the predicted timeframe. Gupta’663 discloses predicting a future request for VM creation by the entity, including predicted compute capacity and a predicted timeframe, based on a past VM creation (col. 5, lines 17-29: The inventory system 130 in FIG. 1 retrieves and examines the records from the history database and detects cyclical virtual machine usage patterns on an individual user account basis. In the example of FIG. 2, the inventory system 130 would determine that every Thursday at around 5:00 pm user account abcd123 is likely to request 5 or 6 virtual machines of type xyz and request that those 5 or 6 virtual machines be launched in different racks. Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines); reserving the predicted compute capacity at the predicted timeframe before the resource manager receives the request for VM allocation (col. 5, lines 24-36: Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines. Thus, when the user actually does submit the launch request for the virtual machines, the hosts to be used to execute the requested virtual machines has already been reserved for the user account and the placement service 120 need only cause the relevant machine images to be loaded on the hosts whose slots have been allocated to the user account and the virtual machines to be executed); and releasing the reserved predicted compute capacity at the predicted timeframe if the request for VM allocation is not received within a time threshold based on a start time of the predicted timeframe (co. 7, lines 40-48: The allocation also may include a start time and a value indicative of an end time. The start time may be the day and time included in the prediction (5 pm every Thursday in the example above). The start time may comprise a time earlier than the prediction's time value (e.g., 4:45 pm) to account for variations in when users may submit launch requests; col. 8, lines 8-10: Upon expiration of the end time, the allocation is considered invalid and the allocated slots in the specified hosts can be used to launch virtual machines for any user accounts).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 by incorporating Gupta’663’s generating a virtual machine usage prediction for each of the user accounts in advance of the weekly time period in which the user is predicted to likely launch the VMs, creating allocation of slots including start time and end time before the user actually submits the launch request for the VMS, and allocating the slots to other user upon expiration of the end time. The motivation would have been to increase the probability that the provider network will be able to honor more launch requests (Gupta’663 paragraph [0034]).
Regarding claim 17 referring to claim 1, Gupta’371 discloses A computer-readable storage medium having program instructions recorded thereon that, when executed by a processor, implements a method comprising: … (paragraph [0038]: The hardware, for example, can include processing resources 440, memory resources 442, and/or machine readable medium (MRM) 444 (e.g., computer readable medium (CRM), database, etc.); See the rejection for claim 11).
Regarding claim 2, Gupta’371 discloses
the request further comprising a third priority VM type (paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications), the resource manager (paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) further configured to:
determine a capacity shortage of VMs of the first priority VM type and the second priority VM type to fulfill the request for VM allocation (paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users)); and
provision the request for VM allocation with available VMs of the third priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request; paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted).
Regarding claim 3, Gupta’371 discloses
wherein the resource manager may be (e.g., further) configured to: notify an entity (paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) providing the request about the provisioning of the request including a quantity of the first priority VM type and a quantity of the second priority VM type (paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications); paragraph [0031]: a request (e.g., including a non-high performance (non-HPC) type of VM) can be provided by a user via a graphical interface 232 of a client device (e.g., client devices 228-1, . . . , 228-M)).
Regarding claims 4 and 12, Gupta’371 discloses
the request further comprising an indication of the first and second priority VMs in a first region or a first zone within the first region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes), the resource manager further configured to: recommend to an entity (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users); paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) providing the request available VMs of at least one of the first priority VM type or the second priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request; paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted) in a second region or a second zone within the second region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes).
Regarding claims 5 and 13, Gupta’371 discloses
the request further comprising an indication of the first and second priority VMs in a first region or a first zone within the first region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes), the resource manager further configured to: recommend to an entity (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users); paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) providing the request available VMs of a third priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request; paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted) in at least one of the first region, the first zone, a second region, or a second zone within the second region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes).
Regarding claim 18, Gupta’371 discloses
the request further comprising an indication of the first and second priority VMs in a first region or a first zone within the first region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes), recommending to an entity providing the request available VMs of at least one of the first priority VM type or the second priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request; paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted; paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) in a second region or a second zone within the second region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes); or
recommending to an entity (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users); paragraph [0038]: The program instructions (e.g., machine-readable instructions (MRI) 458) can include instructions stored on the MRM 444 and executable by the processing resources 440 to implement a desired function) providing the request available VMs of a third priority VM type (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request; paragraph [0017]: the request can include a priority corresponding to the number of VM; paragraph [0018]: Examples of priority classifications can include high priority (e.g., corresponding to a synchronous HPC set of VMs), medium priority (e.g., corresponding to a synchronous non-HPC set of VMs and/or an asynchronous HCP set of VMs), and/or low priority (e.g., a non-synchronous non-HPC set of VMs), among other priority classifications; paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned to the plurality of nodes or the plurality of nodes satisfying the criteria (e.g., capacity) of the number of VMs have been exhausted) in at least one of the first region, the first zone, a second region, or a second zone within the second region (paragraph [0007]: availability zones; paragraph [0025]: a request can be received including a number of VMs to be assigned to a plurality of nodes (not shown) in a cloud system 233. The cloud system 233 can include server devices (e.g., servers 226-1, . . . , 226-N). The server devices (e.g., servers 226-1, . . . , 226-N) represent generally any suitable computing devices to include the plurality of nodes).
Claims 6-8, 10, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupto’371 in view of Gupta’663 as applied to claims 1, 11, and 17, and further in view of Yang et al. (US 2022/0327002, hereinafter Yang).
Regarding claims 6, 14, and 19, Gupta’371 in view of Gupta’663 does not disclose the program code further comprising: the capacity analyzer configured to: determine the past VM creation by the entity, including past compute capacity and a past timeframe; predict a future compute capacity for at least one of a region or a zone within a region during at least the predicted timeframe; and alert the entity if the predicted future compute capacity is less than the predicted compute capacity.
Yang discloses the program code further comprising: the capacity analyzer configured to: determine the past VM creation by the entity, including past compute capacity and a past timeframe; predict a future compute capacity for at least one of a region or a zone within a region during at least the predicted timeframe; and alert the entity if the predicted future compute capacity is less than the predicted compute capacity (paragraph [0033]: In addition to predicting utilization and capacity generally, in one or more embodiments, the prediction and inference system 106 can predict a surplus capacity of computing resources associated with an identified period of time … the prediction and inference system 106 can determine a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests) will not be met with allocation failures (e.g., based on lack of availability of computing resources; paragraph [0034]: the resource management systems 110a-n may include components that manage receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system 106 and policy rules. In one or more embodiments, the resource management systems 110a-n intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules); and alert the entity if the predicted future compute capacity is less than the predicted compute capacity (paragraph [0033]: allocation failures (e.g., based on lack of availability of computing resources); paragraph [0053]: the feature engineering manager 204 can evaluate the refined cluster data and determine any number of feature signals that the surplus prediction engine 206 is trained to receive or otherwise recognizes as valid input to use in generating a failure prediction for the node cluster). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 in view of Gupta’663 by incorporating Yang’s determining a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests), managing receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system and policy rules, and generating allocation failures based on lack of availability of computing resource. The motivation would have been to intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules (Yang paragraph [0034]).
Regarding claim 7, Gupta’371 in view of Gupta’663 does not disclose the capacity analyzer further configured to: alert the entity about a future timeframe when the predicted compute capacity is equal to or greater than the future compute capacity.
Yang discloses the capacity analyzer further configured to: alert the entity about a future timeframe when the predicted compute capacity is equal to or greater than the future compute capacity (paragraph [0033]: In addition to predicting utilization and capacity generally, in one or more embodiments, the prediction and inference system 106 can predict a surplus capacity of computing resources associated with an identified period of time … the prediction and inference system 106 can determine a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests) will not be met with allocation failures (e.g., based on lack of availability of computing resources; paragraph [0034]: the resource management systems 110a-n may include components that manage receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system 106 and policy rules. In one or more embodiments, the resource management systems 110a-n intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules; paragraph [0054]: the surplus prediction engine 206 can receive information about historical usage on a node cluster and determine a predicted surplus capacity for an upcoming period of time). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 in view of Gupta’663 by incorporating Yang’s determine a predicted surplus capacity for an upcoming period of time, determining a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests), managing receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system and policy rules. The motivation would have been to intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules (Yang paragraph [0034]).
Regarding claims 8 and 15, Gupta’371 does not disclose the resource manager further configured to: receive an indication that the entity participates in dynamic reservation of computing capacity for VM allocation; provision the request for VM allocation with available VMs of the first or second priority VM types from the reserved compute capacity before the resource manager receives the request for VM allocation.
Gupta’663 discloses provision the request for VM allocation with available VMs of the first or second … VM types from the reserved compute capacity before the resource manager receives the request for VM allocation (col. 4, lines 21-23: A launch request may specify the number (1 or more) of virtual machines that the user desires to be created on hosts, the type of virtual machine; col. 5, lines 24-36: Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines. Thus, when the user actually does submit the launch request for the virtual machines, the hosts to be used to execute the requested virtual machines has already been reserved for the user account and the placement service 120 need only cause the relevant machine images to be loaded on the hosts whose slots have been allocated to the user account and the virtual machines to be executed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 by incorporating Gupta’663’s generating a virtual machine usage prediction for each of the user accounts in advance of the weekly time period in which the user is predicted to likely launch the type of VMs, creating allocation of slots including start time and end time before the user actually submits the launch request for the type of VMs, and allocating the slots to other user upon expiration of the end time. The motivation would have been to increase the probability that the provider network will be able to honor more launch requests (Gupta’663 paragraph [0034]).
Yang discloses the resource manager further configured to: receive an indication that the entity participates in dynamic reservation of computing capacity for VM allocation and provision the request for VM allocation with available VMs of the first or second priority VM types from the reserved compute capacity … (paragraph [0033]: In addition to predicting utilization and capacity generally, in one or more embodiments, the prediction and inference system 106 can predict a surplus capacity of computing resources associated with an identified period of time … the prediction and inference system 106 can determine a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests) will not be met with allocation failures (e.g., based on lack of availability of computing resources; paragraph [0034]: the resource management systems 110a-n may include components that manage receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system 106 and policy rules. In one or more embodiments, the resource management systems 110a-n intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules; paragraph [0054]: the surplus prediction engine 206 can receive information about historical usage on a node cluster and determine a predicted surplus capacity for an upcoming period of time). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 in view of Gupta’663 by incorporating Yang’s determine a predicted surplus capacity for an upcoming period of time, determining a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests), managing receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system and policy rules. The motivation would have been to intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules (Yang paragraph [0034]).
Regarding claim 10, Gupta’371 in view of Gupta’663 does not disclose wherein the reservation is automatic based on a prediction by the capacity analyzer that the future compute capacity will be less than the predicted compute capacity without the reservation.
Yang discloses wherein the reservation is automatic based on a prediction by the capacity analyzer that the future compute capacity will be less than the predicted compute capacity without the reservation (paragraph [0033]: allocation failures (e.g., based on lack of availability of computing resources; paragraph [0053]: the feature engineering manager 204 can evaluate the refined cluster data and determine any number of feature signals that the surplus prediction engine 206 is trained to receive or otherwise recognizes as valid input to use in generating a failure prediction for the node cluster). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 in view of Gupta’663 by incorporating Yang’s generating allocation failures based on lack of availability of computing resource. The motivation would have been to intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules (Yang paragraph [0034]).
Regarding claim 20, Gupta’371 does not disclose wherein the method further comprises: receiving an indication that the entity participates in dynamic reservation of computing capacity for VM allocation; and provisioning the request for VM allocation with available VMs of the first or second priority VM types from the reserved predicted request compute capacity before the resource manager receives the request for VM allocation.
Gupta’663 discloses provision the request for VM allocation with available VMs of the first or second … VM types from the reserved compute capacity before the resource manager receives the request for VM allocation (col. 4, lines 21-23: A launch request may specify the number (1 or more) of virtual machines that the user desires to be created on hosts, the type of virtual machine; col. 5, lines 24-36: Once the inventory system 130 detects such virtual machine usage patterns, as explained below, the inventory system can create an allocation of slots in specific host computers to the user account in advance of the weekly time period in which the user is predicted to likely launch the virtual machines. Thus, when the user actually does submit the launch request for the virtual machines, the hosts to be used to execute the requested virtual machines has already been reserved for the user account and the placement service 120 need only cause the relevant machine images to be loaded on the hosts whose slots have been allocated to the user account and the virtual machines to be executed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 by incorporating Gupta’663’s generating a virtual machine usage prediction for each of the user accounts in advance of the weekly time period in which the user is predicted to likely launch the type of VMs, creating allocation of slots including start time and end time before the user actually submits the launch request for the type of VMs, and allocating the slots to other user upon expiration of the end time. The motivation would have been to increase the probability that the provider network will be able to honor more launch requests (Gupta’663 paragraph [0034]).
Yang discloses wherein the method further comprises: receiving an indication that the entity participates in dynamic reservation of computing capacity for VM allocation; and provisioning the request for VM allocation with available VMs of the first or second priority VM types from the reserved predicted request compute capacity … (paragraph [0033]: In addition to predicting utilization and capacity generally, in one or more embodiments, the prediction and inference system 106 can predict a surplus capacity of computing resources associated with an identified period of time … the prediction and inference system 106 can determine a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests) will not be met with allocation failures (e.g., based on lack of availability of computing resources; paragraph [0034]: the resource management systems 110a-n may include components that manage receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system 106 and policy rules. In one or more embodiments, the resource management systems 110a-n intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Gupta’371 by incorporating Yang’s determining a quantity of computing resources that, if allocated, would maintain less than a threshold measure of risk that incoming VM requests (e.g., non-deferrable VM requests) and managing receipt of VM requests (e.g., deferrable and/or non-deferrable VM requests) based on a combination of information received from the prediction and inference system and policy rules. The motivation would have been to intelligently schedule the VM requests (e.g., deferrable VM requests) based on the information received from the prediction and inference system 106 and based on the policy rules (Yang paragraph [0034]).
Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Gupto’371 in view of Gupta’663 as applied to claims 11, and 17, and further in view of Bhardwaj et al. (US 2015/0248418, hereinafter Bhardwaj).
Regarding claims 21 and 22, Gupta’371 discloses the further comprising: determining a capacity shortage of VMs of the first priority VM type to fulfill the request for VM allocation (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes and/or the number of VMs assigned thereto using any suitable means, for example, monitoring for available capacities of the plurality of nodes … the priority of the number of VMs can be dynamically changed during runtime based upon monitoring the number of VMs. Such a change of priority can enable dynamic updating of the assignment and/or prioritizing of the number of VMs that can affect individuals (e.g., real users)); and provisioning the request for VM allocation with available VMs of the second priority VM type …. (paragraph [0015]: assigning the number of VMs can include assigning the non-HPC type of VM to a node of the plurality of nodes having an HPC type of VM assigned thereto (e.g., assigned from a previous request).
Gupta’371 in view of Gupta’663 does not disclose the further comprising: determining a capacity shortage of VMs of the first priority VM type to fulfill the request for VM allocation; and provisioning the request for VM allocation with available VMs of the second priority VM type based on the capacity shortage.
Bhardwaj discloses the further comprising: determining a capacity shortage of VMs of the first priority VM type to fulfill the request for VM allocation; and provisioning the request for VM allocation with available VMs of the second priority VM type based on the capacity shortage (paragraph [0033]: an SMP may prioritize parameters requiring compliance with factors of an SLA, data importance, etc. over other parameters such as minimum dormant usage threshold and/or threshold access limit. Thus for example, an SMP may be configured such that storage may not be designated as obsolete and suitable for management if data contained in that storage is designated as important and/or reclamation/reallocation would result in non-compliance with the terms of an SLA. Likewise, if data is designated as important (e.g., with an indicator flag), management of storage containing that data may not be permitted … an SMP may permit the management of storage containing important data allocated to a relatively low priority VM in instances where free storage allocated to a relatively high priority VM has become scarce (e.g., less than or equal to about 10%, 5%, or even about 1% of the storage allocated to the high priority VM is free)). This is an explicit teaching of the conditional “detect scarcity of higher-priority capacity → permit use/management/reclamation of lower-priority resources” policy.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the VM allocation framework of Gupta’371 in view of Gupta’663 by incorporating Bhardwaj’s scarcity-triggered fallback policy permitting management/reclamation of lower-priority VM when higher-priority VM become scarce to allow provisioning via available lower-priority VMs when higher-priority VM capacity is insufficient. The motivation would have been to improve capacity management by increasing utilization through reallocation and/or reclamation processes (Bhardwaj paragraph [0091]).
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 [0037] 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 extension fee pursuant to [0037] 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 date of this final action
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 02/06/2026