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
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 final rejection. 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, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 20 May 2026 has been entered
Response to Arguments
Applicant’s arguments with respect to claims 1-8, 10-15, 17-20, 23, and 24 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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-4, 11, 12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 2014/0201371, hereinafter Gupta’371) in view of Duong et al. (US 11,169,835, hereinafter Duong).
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, a second priority VM type, and an indication of a first region or a first zone within the first region for allocation of a VM of at least one of the first and the second priority VM types (paragraph [0043]: The receive module 446 can receive a request including a number of VMs; paragraph [0016]: The criteria can include a type, a priority, a nature, a number of instances (e.g., a particular number of VMs) … and/or locality criteria of the number of VMs; paragraph [0018]: Examples of priority classifications can include high priority… medium priority … and/or low priority; paragraph [0032]: the plurality of nodes … can be sorted by hop distance to the reference node … a group can … include all nodes … having a given hop distance; Note: Under BRI, GUPTA’s request including specific priority classifications (i.e., high/medium/low) maps to the first and second priority VM types. Furthermore, GUPTA’s “locality criteria” mapped to specific groups of nodes at a given “hop distance” constitutes receiving an indication of a first region or zone for allocation);
provision the request for the VM allocation with available VMs of the first priority VM type (paragraph [0045]: An assign module 450 … can simultaneously assign the number of VMs to a node of the plurality of nodes in response to the request based on a criteria of the request and the number of relationships of the nodes and a capacity of the node; paragraph [0035]: assignment of the number of VMs can depend upon available capacity of the plurality of nodes, topology … and/or priority of the number of VMs; Note: Under BRI, assigning the VMs to nodes based on the requested priority and capacity constitutes provisioning the request with available VMs of the first priority VM type);
determine a capacity shortage of VMs of the first priority VM type to fulfill the request for the VM allocation (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes … for example, monitoring for available capacities of the plurality of nodes; paragraph [0033]: if it is determined the capacity for the plurality of nodes having the given hop distance (e.g., one hop) are fulfilled and/or unsuitable to satisfy the criteria of the VM, then the VM can be assigned to a node of a group of the plurality of nodes with a comparatively greater hop distance; Note: Under BRI, dynamically monitoring capacities and determining that capacity is “fulfilled and/or unsuitable” at the requested locality/hop distance constitutes determining a capacity shortage).
Gupta’371 does not disclose provide to the entity a recommendation indicating available VMs of at least one of the first priority VM type, the second priority VM type, or a third priority VM type in a second region or a second zone within the second region; and based on receiving confirmation of acceptance of the recommendation, provision the VM allocation of the recommendation. Duong discloses provide to the entity a recommendation indicating available VMs of at least one of the first priority VM type, the second priority VM type, or a third priority VM type in a second region or a second zone within the second region; and based on receiving confirmation of acceptance of the recommendation, provision the VM allocation of the recommendation (col. 5, line 63-col. 6, line 3: a user approves a recommendation via a user interface … allows the user to view and approve a load balancing recommendation. This causes the recommendation to be sent to the migration executor, and the migration executor proceeds to execute the recommendation by migrating VM data associated with the recommendation; col. 6, lines 47-55: generate a set of recommendations that includes selections of one or more sets of VMs to be moved from their current storage device(s) to respective new destination storage device(s) … each recommendation identifies the VMs to move, the source storage device(s) of the VMs, the destination storage device(s) of the VMs; Note: Under BRI, DUONG’s teaching of generating a recommendation to move VMs to a new destination device, and executing that migration only after a user views and approves the recommendation via a UI, constitutes providing a recommendation for a second region/zone and provisioning based on receiving confirmation of acceptance). While DUONG does not explicitly use the exact terminology of “first, second, or third priority VM types,” Gupta’371 already discloses that the VMs being allocated are categorized by priority types (Gupta’371, paragraph [0018]: The number of VMs can be classified by priority … Examples of priority classifications can include high priority … medium priority … and/or low priority).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the automated, prioritized VM allocation method of Gupta’371 to include the user-approved recommendations and confirmation interface as taught by Duong. In the combined system, when a capacity shortage occurs for a requested prioritized VM (as in GUPTA), the system provides a recommendation to provision or migrate that specific priority VM type to an alternative destination device/zone and waits for user approval before executing the provisioning/migration (as in DUONG). The motivation would have been to provide the user with ultimate control and consent over where their specific workloads are provisioned or migrated during a capacity shortage or load balancing event, ensuring that VMs are not automatically moved to a different node or geographic zone that might violate the user’s constraints, while still optimizing overall system load (Duong col. 5, line 62-col. 6, line 3; col. 6, lines 23-30).
Regarding claim 11 referring to claim 1, Gupta’371 discloses A method comprising: … (See the rejection for claim 1).
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 1).
Regarding claim 2, Gupta’371 discloses
the request further comprising the third priority VM type, the resource manager further configured to (paragraph [0018]: Examples of priority classifications can include high priority … medium priority … and/or low priority; Note: Under BRI, GUPTA’s explicit listing of three distinct priority classifications (i.e., high, medium, and low) maps directly to the claimed first, second, and third priority VM types within the request):
determine a capacity shortage of VMs of the first priority VM type and the second priority VM type to fulfill the request for the VM allocation (paragraph [0019]: monitoring can refer to dynamically evaluating the plurality of nodes … 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; paragraph [0033]: if it is determined the capacity for the plurality of nodes … are fulfilled and/or unsuitable to satisfy the criteria of the VM; 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; Note: Under BRI, dynamically monitoring the nodes and determining that the available capacity for the higher priority VMs (e.g., high and medium priority) has been exhausted or is unsuitable constitutes determining a capacity shortage of the first and second priority VM types); and
provision the request for the VM allocation with available VMs of the third priority VM type (paragraph [0034]: Assignment of the number of VMs can continue recursively until each of the number of VMs have been assigned; paragraph [0035]: assignment of the number of VMs can depend upon available capacity of the plurality of nodes … and/or priority of the number of VMs; Note: Under BRI, GUPTA’s teaching of recursively continuing the assignment process based on priority and available capacity until all VMs are assigned constitutes provisioning the remainder of the request with the available VMs of the next tier, i.e., the third priority VM type, after the higher priorities experience a capacity shortage).
Regarding claim 3, Gupta’371 discloses
wherein the resource manager is configured to: notify an entity providing the request about the provisioning of the request (paragraph [0031]: a request… can be provided by a user via a graphical interface 232 of a client device; paragraph [0034]: A notification of success or failure of the assignment can be provided; Note: Under BRI, providing a notification of success of the assignment to the user via the interface constitutes notifying the entity about the provisioning of the request) including a quantity of the first priority VM type, and a quantity of the second priority VM type, and a quantity of the third priority VM type (paragraph [0016]: The criteria can include a type, a priority, a nature, a number of instances (e.g., a particular number of VMs); paragraph [0018]: Examples of priority classifications can include high priority … medium priority … and/or low priority; Note: Under BRI, because the user’s request includes the specific number/quantity of VMs for the different priority classifications, notifying the user of the successful assignment of that request inherently notifies them of the provisioning of those quantities).
Gupta’371 does not disclose notifying the entity about the provisioning of the request including a quantity of the VMs. Duong discloses notifying the entity about the provisioning of the request including a quantity of the VMs (col. 6, lines 4-15: Messages relating to migration such as progression, successful completion, errors, failures, and the like can be provided via the user interface… The progress of the migration of data within that pool can be represented in various text or graphical forms conveying information about the status or progression of migration such as how many VMs have been migrated and how many have not yet been migrated; Note: Under BRI, DUONG’s teaching of providing a UI message of successful completion that explicitly includes “how many VMs” (the quantity) have been migrated/provisioned reads on providing the quantity in the notification). While DUONG does not explicitly use the exact terminology of “first, second, or third priority VM types,” Gupta’371 already discloses that the VMs being allocated are categorized by priority types (Gupta’371, paragraph [0018]: The number of VMs can be classified by priority … Examples of priority classifications can include high priority … medium priority … and/or low priority).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the notification mechanism of Gupta’371 to include the detailed quantity breakdown in the user interface as taught by Duong. The motivation would have been to provide the user with transparent, granular feedback regarding the exact status and quantities of their prioritized workloads, ensuring the administrator can accurately verify that the requested number of high, medium, and low priority VMs were successfully provisioned (Duong col. 5, line 62-col. 6, line 3).
Regarding claims 4 and 12, Gupta’371 does not disclose further comprising 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.
Duong discloses further comprising 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. 1, lines 23-25: optimizes VM placement based on storage capacity and forecasted performance needs; col. 3, lines 28-35: the VM load balancing server obtains historical data corresponding to various VMs from the storage devices at which the VMs reside and use the historical data to generate predicted metrics (e.g., a probability that a particular event … may occur at any point within a window of time in the future) for each storage device based on the historical VM data; col. 6, lines 58-61: The VM load balancing server may include components to generate predicted metrics related to access rate or space usage such as by modelling predicted metrics; Note: Under BRI, DUONG’s VM load balancing server acts as the claimed “capacity analyzer.” DUONG’s teaching of using “historical VM data” (i.e., past VM creation/usage) to generate “predicted metrics related to … space usage” (i.e., predicted compute capacity) within a “window of time in the future” (i.e., predicted timeframe) reads directly on predicting a future request for VM capacity based on past VM creation). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Gupta’371 to include the predictive capacity analyzer as taught by Duong The motivation would have been to allow the system to proactively forecast performance needs and capacity shortages before they occur, thereby enabling the system to optimize VM placement and load balancing ahead of time to prevent system bottlenecks and improve overall resource utilization (Duong col. 1, lines 22-34; col. 3, lines 22-36]).
Claims 6, 7, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gupto’371 in view of Duong as applied to claims 4, 12, 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 Duong 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; and alert the entity if the predicted future compute capacity is less than the predicted compute capacity (paragraph [0054]: the feature engineering manager 204 can provide feature signals indicative of resource usage over some previous period of time… that the surplus prediction engine 206 is trained to receive as input and generate a model output including a prediction of surplus capacity for an upcoming period of time; paragraph [0066]: a scope signal indicating a scope of the capacity signal (e.g., a region of server nodes or specific cluster of a datacenter)… a count of available VMs for a given region of server nodes … a projected expected available capacity; paragraph [0033]: 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 … will not be met with allocation failures (e.g., based on lack of availability of computing resources); paragraph [0035]: generates and provides other information such as policies regarding new allocations, predictions of allocation failures; Note: Under BRI, YANG’s teaching of analyzing previous resource usage to predict available capacity for a specific region, and generating predictions of allocation failures when there is a lack of availability of computing resources, constitutes determining past VM creation, predicting future compute capacity for a region, and alerting the entity/system of an allocation failure if the predicted capacity is insufficient). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong to include the region-specific capacity prediction and allocation failure alerts as taught by Yang. The motivation would have been to intelligently schedule incoming VM requests based on highly accurate, region-specific capacity forecasts, thereby proactively alerting users or the system to potential allocation failures before they occur and minimizing the risk of over-allocating storage and computing resources during periods of peak demand (Yang paragraphs [0011] and [0034]).
Regarding claim 7, Gupta’371 in view of Duong 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 predicted 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 predicted future compute capacity (paragraph [0012]: determine predicted capacity information… that includes an indication of surplus capacity for an identified period of time (e.g., an upcoming period of time); paragraph [0061]: the inference engine 210 generates a signal indicating a predicted number of cores of capacity that will be available over an upcoming period of time; paragraph [0065]: inferences indicating properties of an upcoming capacity valley in which surplus computing resources will be available for a duration of time; paragraph [0066]: a predicted start of an interval (e.g., a first timestamp in a list of predictions). Another example may include a predicted interval; Note: Under BRI, YANG’s teaching of generating a signal or alert that indicates a specific upcoming time interval, a “capacity valley”, where surplus computing resources will be available constitutes alerting the entity about a future timeframe when the available compute capacity is sufficient/greater than the needed capacity). 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 predictive capacity allocation system of Gupta’371 and Duong to include the future timeframe surplus alerts as taught by Yang. The motivation would have been to allow the system or user to flexibly schedule deferrable workloads during specific periods of known capacity surplus, thereby optimizing overall resource utilization, avoiding allocation failures during peak hours, and reducing costs associated with hosting cloud computing services (Yang paragraphs [0014] and [0017]).
Claims 5, 8, 10, 13, 15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta’371 in view of Duong as applied to claims 6 and 15, and further in view of Gupta et al. (US 11,500,663, hereinafter Gupta’663).
Regarding claims 5 and 13, Gupta’371 in view of Duong does not disclose wherein the resource manager is further configured to: reserve the predicted compute capacity for the predicted timeframe before the resource manager receives the request for the VM allocation; and release the reserved predicted compute capacity for the predicted timeframe if the request for the VM allocation is not received within a time threshold based on a start time of the predicted timeframe.
Gupta’663 discloses wherein the resource manager is further configured to: reserve the predicted compute capacity for the predicted timeframe before the resource manager receives the request for the VM allocation (col. 5, lines 26-29: 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 release the reserved predicted compute capacity for the predicted timeframe if the request for the VM allocation is not received within a time threshold based on a start time of the predicted timeframe (col. 2, lines 50-56: The slots may be allocated to the user account for a temporary period of time (e.g., 15 minutes, 30 minutes, 1 hour, etc.), and if no launch requests are received for that particular user account within that specific time period, then the logical allocation of the slots to the user account is invalidated so that the slots in the hosts can be readily used for other users and user accounts; col. 7, line 40-col. 8, line 10: The allocation also may include a start time and a value indicative of an end time … 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; Note: Under BRI, invalidating the logical allocation of slots if a launch request is not received within a temporary period defined by a start and end time constitutes releasing the reserved capacity if the request is not received within a time threshold). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong to include the temporary reservation and timeout release mechanism as taught by GUPTA '663. The motivation would have been to prevent resource hoarding and avoid wasting valuable host capacity by ensuring that if a user fails to submit their predicted VM launch request, the unused pre-allocated slots are automatically freed up and returned to the available pool for other users to utilize (Gupta’663 col. 7, line 40-col. 8, line 10).
Regarding claim 18, Gupta’371 in view of Duong does not disclose the method further comprising: 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 for the predicted timeframe before the resource manager receives the request for the VM allocation; and releasing the reserved predicted compute capacity for the predicted timeframe if the request for the VM allocation is not received within a time threshold based on a start time of the predicted timeframe.
Gupta’663 discloses the method further comprising: 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. 2, lines 19-31: the inventory system monitors the virtual machine creations for each user account… Based on that historical virtual machine launch information, the inventory system generates a virtual machine usage prediction … Each usage prediction may comprise an indication as to when a user of particular user account is likely to generate a new virtual machine launch request in the future and the number of virtual machines likely to be requested); reserving the predicted compute capacity for the predicted timeframe before the resource manager receives the request for the VM allocation (col. 5, lines 26-29: 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 releasing the reserved predicted compute capacity for the predicted timeframe if the request for the VM allocation is not received within a time threshold based on a start time of the predicted timeframe (col. 2, lines 50-56: The slots may be allocated to the user account for a temporary period of time (e.g., 15 minutes, 30 minutes, 1 hour, etc.), and if no launch requests are received for that particular user account within that specific time period, then the logical allocation of the slots to the user account is invalidated so that the slots in the hosts can be readily used for other users and user accounts; col. 7, line 40-col. 8, line 10: The allocation also may include a start time and a value indicative of an end time … 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; Note: Under BRI, invalidating the logical allocation of slots if a launch request is not received within a temporary period defined by a start and end time constitutes releasing the reserved capacity if the request is not received within a time threshold). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong to include the predictive reservation and timeout release steps as taught by GUPTA '663. The motivation would have been to prevent resource hoarding and avoid wasting valuable host capacity by ensuring that if a user fails to submit their predicted VM launch request, the unused pre-allocated slots are automatically freed up and returned to the available pool for other users to utilize (Gupta’663 col. 7, line 40-col. 8, line 10).
Regarding claims 8 and 15, Gupta’371 in view of Duong does not disclose the resource manager further configured to: receive an indication that the entity participates in dynamic reservation of computing capacity for the VM allocation; and provision the request for the VM allocation with available VMs of at least one of the first, second, or third priority VM types from the reserved compute capacity before the resource manager receives the request for the VM allocation.
Gupta’663 discloses the resource manager further configured to: receive an indication that the entity participates in dynamic reservation of computing capacity for the VM allocation (col. 2, lines 2-3: Individuals or organizations can register themselves with the provider network to create user accounts; col. 3, lines 19-20: the user may have statically configured various location parameter settings within their account; Note: Under BRI, a user registering an account and configuring settings to utilize the provider network’s predictive allocation system constitutes receiving an indication that the entity participates in dynamic reservation of computing capacity); and provision the request for the VM allocation with available VMs of at least one of the first, second, or third priority VM types from the reserved compute capacity before the resource manager receives the request for the VM allocation (col. 5, lines 24-34: Once the inventory system 130 detects such virtual machine usage patterns… 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; Note: Under BRI, allocating the slots/hosts to the user account “in advance” so they are already reserved when the user “actually does submit the launch request” constitutes provisioning the request from reserved capacity before the request is actually received). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the prioritized capacity allocation system of Gupta’371 and Duong to include the user-account based pre-provisioning mechanism as taught by Gupta '663. The motivation would have been to drastically reduce VM launch latency and increase the probability that the cloud provider network can honor launch requests during peak times by intelligently reserving and pre-loading resources for participating users based on their predicted usage patterns before the actual requests are even submitted (Gupta'663 col. 5, lines 17-41).
Regarding claim 10, Gupta’371 in view of Duong does not disclose wherein the reservation is automatic based on a prediction by the capacity analyzer that the predicted future compute capacity will be less than the predicted compute capacity without the reservation.
Gupta’663 discloses wherein the reservation is automatic based on a prediction by the capacity analyzer that the predicted future compute capacity will be less than the predicted compute capacity without the reservation (col. 7, lines 51-64: if the capacity management system 134 determines that at the time specified in the prediction that the fleet of hosts will likely execute enough virtual machines that less than a threshold number of additional virtual machines will be able to launch and execute at that time, the capacity management system 134 may generate the allocation to ensure that the user account corresponding to the prediction will have sufficient slots available. However, if the capacity management system 134 determines that the fleet of hosts will likely be loaded with relatively few virtual machines such that more than the threshold number of additional virtual machines can still be launched, the capacity management system may opt not to create the allocation; Note: Under BRI, automatically generating the allocation/reservation only when the system predicts that the future host capacity will fall below a threshold to launch the needed VMs constitutes making the reservation based on a prediction that future compute capacity will be less than the predicted compute capacity). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong to include the conditional automatic reservation mechanism as taught by Gupta'663. The motivation would have been to optimize network resources by avoiding the waste of pre-allocating host slots during periods of low demand, while ensuring that users are guaranteed their required compute capacity during predicted periods of high network congestion and capacity shortages (Gupta’663 col. 7, line 40-col. 8, line 10).
Regarding claim 20, Gupta’371 in view of Duong does not disclose wherein the method further comprises: receiving an indication that the entity participates in dynamic reservation of computing capacity for the VM allocation; and provisioning the request for the 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 the VM allocation.
Gupta’663 discloses wherein the method further comprises: receiving an indication that the entity participates in dynamic reservation of computing capacity for the VM allocation (col. 2, lines 2-3: Individuals or organizations can register themselves with the provider network to create user accounts; col. 3, lines 19-20: the user may have statically configured various location parameter settings within their account; Note: Under BRI, a user registering an account and configuring settings to utilize the provider network’s predictive allocation system constitutes receiving an indication that the entity participates in dynamic reservation of computing capacity); and provisioning the request for the 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 the VM allocation (col. 5, lines 24-34: Once the inventory system 130 detects such virtual machine usage patterns… 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; Note: Under BRI, allocating the slots/hosts to the user account “in advance” so they are already reserved when the user “actually does submit the launch request” constitutes provisioning the request from reserved capacity before the request is actually received). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the prioritized capacity allocation system of Gupta’371 and Duong to include the user-account based pre-provisioning mechanism as taught by Gupta '663. The motivation would have been to drastically reduce VM launch latency and increase the probability that the cloud provider network can honor launch requests during peak times by intelligently reserving and pre-loading resources for participating users based on their predicted usage patterns before the actual requests are even submitted (Gupta'663 col. 5, lines 17-41).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Gupto’371 in view of Duong and Yang as applied to claims 14, and further in view of Gupta’663.
Regarding claim 23, Gupta’371 in view of Duong and Yang does not disclose automatically reserving the computing capacity based on a prediction that the predicted future compute capacity will be less than the predicted compute capacity without the reservation. Gupta’663 discloses automatically reserving the computing capacity based on a prediction that the predicted future compute capacity will be less than the predicted compute capacity without the reservation (col. 7, lines 51-64: if the capacity management system 134 determines that at the time specified in the prediction that the fleet of hosts will likely execute enough virtual machines that less than a threshold number of additional virtual machines will be able to launch and execute at that time, the capacity management system 134 may generate the allocation to ensure that the user account corresponding to the prediction will have sufficient slots available. However, if the capacity management system 134 determines that the fleet of hosts will likely be loaded with relatively few virtual machines such that more than the threshold number of additional virtual machines can still be launched, the capacity management system may opt not to create the allocation; Note: Under BRI, automatically generating the allocation/reservation only when the system predicts that the future host capacity will fall below a threshold to launch the needed VMs constitutes making the reservation based on a prediction that future compute capacity will be less than the predicted compute capacity). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong and Yang to include the conditional automatic reservation mechanism as taught by Gupta'663. The motivation would have been to optimize network resources by avoiding the waste of pre-allocating host slots during periods of low demand, while ensuring that users are guaranteed their required compute capacity during predicted periods of high network congestion and capacity shortages (Gupta’663 col. 7, line 40-col. 8, line 10).
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Gupto’371 in view of Duong and Gupta’663.as applied to claims 18, and further in view of Yang.
Regarding claim 24, Gupta’371 in view of Duong does not disclose wherein the method further comprises: predicting a future compute capacity for at least one of a region or a zone within a region during at least the predicted request timeframe; and automatically reserving the computing capacity based on a prediction that the predicted future compute capacity will be less than the predicted compute capacity without the reservation. Gupta’663 discloses automatically reserving the computing capacity based on a prediction that the predicted future compute capacity will be less than the predicted compute capacity without the reservation (col. 7, lines 51-64: if the capacity management system 134 determines that at the time specified in the prediction that the fleet of hosts will likely execute enough virtual machines that less than a threshold number of additional virtual machines will be able to launch and execute at that time, the capacity management system 134 may generate the allocation to ensure that the user account corresponding to the prediction will have sufficient slots available. However, if the capacity management system 134 determines that the fleet of hosts will likely be loaded with relatively few virtual machines such that more than the threshold number of additional virtual machines can still be launched, the capacity management system may opt not to create the allocation; Note: Under BRI, automatically generating the allocation/reservation only when the system predicts that the future host capacity will fall below a threshold to launch the needed VMs constitutes making the reservation based on a prediction that future compute capacity will be less than the predicted compute capacity). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371 and Duong and Yang to include the conditional automatic reservation mechanism as taught by Gupta'663. The motivation would have been to optimize network resources by avoiding the waste of pre-allocating host slots during periods of low demand, while ensuring that users are guaranteed their required compute capacity during predicted periods of high network congestion and capacity shortages (Gupta’663 col. 7, line 40-col. 8, line 10).
Yang discloses predicting a future compute capacity for at least one of a region or a zone within a region during at least the predicted request timeframe (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; paragraph [0066]: a scope signal indicating a scope of the capacity signal (e.g., a region of server nodes or specific cluster of a datacenter) … a count of available VMs for a given region of server nodes… a projected expected available capacity; Note: Under BRI, predicting capacity and available VMs for a specific “region of server nodes” during an upcoming period of time constitutes predicting future compute capacity for a region during the predicted timeframe). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the predictive capacity allocation system of Gupta’371, Duong, and Gupta’663 to include the region-specific capacity prediction as taught by Yang. The motivation would have been to intelligently schedule incoming VM requests based on highly accurate, location-specific capacity forecasts (Yang paragraph [0034]), thereby making localized reservation decisions to maintain less than a threshold measure of risk of allocation failures in specific geographic regions or clusters during periods of peak demand (Yang paragraphs [0033] and [0066]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Smith et al. (US 2013/0042123) discloses allocating virtual machines within specific geographic zones, and optimizing the topographical distribution of resources and workload throughout a zone or cloud computing environment by migrating virtual machines when a physical host or server exceeds a threshold level of power utilization or workload (paragraphs [0076], [0111], [0112], and [0117]).
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 9/16/2026
