DETAILED ACTION
Claims 1-19 are pending. Applicant has amended claims 1, 13 and 19.
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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7, 13-15 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Yi (CN 111061561 A – English translation is provided by IP.com) in view of Azaria et al. (US 2022/0147380 A1).
As to claim 1, Yi teaches a provisioning method performed by at least one computing device for a cloud service (The full-stage load sharing comprehensive optimization method of the cloud computing management platform; page 6, paragraph 7th), the provisioning method comprising:
collecting resource utilization rates of individual cloud nodes of a plurality of cloud nodes, wherein a resource utilization rate of an individual cloud node includes a resource utilization rate for at least one of a processor or a memory of the individual cloud node (collects resource utilization conditions of all physical hosts, the number of residual resources of each physical host is obtained by calculating original resource capacity data of the physical hosts stored in a database, the central processor resource utilization rate, the memory utilization rate and the hard disk utilization rate of each physical host are further obtained; page 6, paragraph 7th);
receiving a regular instance request from at least one client (creating a virtual machine request; page 6, paragraph 6 and the virtual machine creation queue stores virtual machine creation requests, and when a virtual machine creation request exists; page 9, 1st paragraph);
determining whether there is a cloud node among the plurality of cloud nodes that satisfies a first condition, in which the collected resource utilization rate is less than a first threshold value (acquiring threshold information of all physical hosts; calculating to obtain a central processing unit utilization rate threshold value, a memory utilization rate threshold value, a hard disk utilization rate threshold value and a full disk comprehensive utilization rate threshold value of the cloud computing management platform; page 9, paragraph 6; and calculating a weight value of a physical host; according to the fact that the comprehensive load rate of the whole disk is taken as a main consideration factor, the result of (-1) multiplied by the comprehensive utilization rate of the whole disk is returned to be used as the weight of the physical host, and the lower the comprehensive utilization rate of the physical host is, the larger the weight of the physical host is; page 9, paragraph 10); and
provisioning a requested regular instance in the specific cloud node (executing the task of creating a virtual machine; selecting the physical host with the largest weight as the target host according to the weight of the physical host calculated in the eleventh step; if the virtual machine task is created, a virtual machine instance is created on the physical host; page 9, paragraph 11).
Yi does not teach designating a specific cloud node from among the plurality of cloud nodes based on a determination that there is no cloud node among the plurality of cloud nodes that satisfies the first condition; and terminating at least some of spot instances pre-provisioned and operating on the specific cloud node and provisioning a requested regular instance in the specific cloud node.
However, Azaria teaches designating a specific cloud node from among the plurality of cloud nodes based on a determination that there is no cloud node among the plurality of cloud nodes that satisfies the first condition; and terminating at least some of spot instances pre-provisioned and operating on the specific cloud node and provisioning a requested regular instance in the specific cloud node (Process flow 700 begins with 702, and moves to operation 704. Operation 704 depicts determining that more computing resources are needed. In some examples, this can comprise VM spot manager 108a of FIG. 1 determining to instantiate another VM instance, and determining that on-premises nodes 106a lack the available computing resources to host this VM instance (or that hosting the VM instance would take node resource usage above a predetermined threshold). After operation 704, process flow 700 moves to operation 706. Operation 706 depicts determining that another entity's spot VM is running on premises. In some examples, VM spot manager 108a can maintain a list of VMs running on on-premises nodes 106a, along with an indication of what entity owns that VM instance. In such examples, VM spot manager 108a can identify whether any of these running VMs have an associated owner different from the customer that owns (or leases) customer system 110a. After operation 706, process flow 700 moves to operation 708. Operation 708 depicts selecting a spot VM to terminate. This can comprise a VM running on on-premises nodes 106a that has an owner different from the customer that owns (or leases) customer system 110a. In some examples, various criteria can be used to select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time, and a VM that is consuming the most computing resources; paragraphs [0075]-[0077]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Azaria to the system of Yi because Azaria teaches a method that uses a data-driven approach to predict resource consumption and help minimize interrupt events where a cloud provider will kill its VMs and return on-premises computing resources to the resource providing customer (paragraph [0018]).
As to claim 2, Yi as modified by Azaria teaches the provisioning method of claim 1, wherein the collecting the resource utilization rate comprises:
collecting a resource utilization rate of the specific cloud node through a node agent (see Azaria: The cloud spot manager can run in the cloud and can communicate with multiple VM spot mangers to monitor resource utilization of the VM spot managers' respective hardware, and to create resource consumer customer VMs); and
collecting a resource utilization rate of a specific cloud instance through an instance agent operating on the specific cloud instance of the specific cloud node (see Azaria: A VM spot manager can connect to a cloud spot manager and allow the cloud spot manager to deploy resource consumer customer VMs on available computing resources of a resource producing customer's hardware. A VM spot manager can also monitor resource utilization of the local resource producing customer's VMs to report back usage statistics to the cloud spot manager, and to kill resource consumer customer VMs if the resource producing customer needs more resources; paragraph [0025]).
As to claim 3, Yi as modified by Azaria teaches the provisioning method of claim 1, wherein the provisioning the requested regular instance comprises:
designating a termination target from a list of the pre-provisioned spot instances (see Azaria: VM spot manager 108a can maintain a list of VMs running on on-premises nodes 106a, along with an indication of what entity owns that VM instance. In such examples, VM spot manager 108a can identify whether any of these running VMs have an associated owner different from the customer that owns (or leases) customer system 110a; paragraph [0076]);
predicting a resource utilization rate of the specific cloud node according to termination of the designated spot instance (see Azaria: Operation 510 forecasting future resource usage from a historical time series of the resource load score. In some examples, operation 510 can comprise implementing a forecasting technique, a regression model, or other techniques to forecast near future behavior of a particular system. Factors that can be considered in this forecasting can include seasonality, a day of the week, an hour of the day, holidays and more; paragraph [0069]); and
terminating the designated spot instance based on a determination that the predicted resource utilization rate is less than the first threshold value (see Azaria: Operation 708 depicts selecting a spot VM to terminate. This can comprise a VM running on on-premises nodes 106a that has an owner different from the customer that owns (or leases) customer system 110a. In some examples, various criteria can be used to select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time, and a VM that is consuming the most computing resources; paragraph [0077] and Operation 512 depicts assigning a spot instance to an installation based on the forecast. In some examples, operation 512 can comprise assigning the spot instance to the installation based on forecasting that that installation will have a lowest resource load score of the installations (e.g., customer system 110a and customer system 110b) over a given future time period.; paragraph [0069]).
As to claim 4, Yi as modified by Azaria teaches the provisioning method of claim 3, wherein the termination target is designated based on a resource utilization rate of a spot instance (see Azaria: select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time, and a VM that is consuming the most computing resources; paragraph [0077]).
As to claim 5, Yi as modified by Azaria teaches the provisioning method of claim 3, wherein the termination target is designated based on at least one of a bid price or a used period of a spot instance (see Azaria: select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time; paragraph [0077]).
As to claim 7, Yi as modified by Azaria teaches the provisioning method of claim 1, further comprising:
receiving a spot instance request from a client (see Azaria: requesting the cloud spot manager to deploy the spot instance. This can comprise a VM spot manager requesting that the cloud spot manager deploy a particular spot instance; paragraph [0084]);
determining whether there is a cloud node among the plurality of cloud nodes that satisfies a second condition (see Azaria: where the cloud spot manager will determine the customer system where the instance is to be deployed; paragraph [0084], and operation 904
depicts determining a charge for on-premises nodes. A customer can lease some of its on-premises nodes (e.g., nodes of on-premises nodes 106a of FIG. 1). This lease can involve a set charge for a set period of time, and a stored indication of this lease arrangement can by maintained by cloud spot manager 102, which can access this in implementing operation 904; paragraph [0087]); and
performing provisioning for a requested spot instance based on a result of the determining whether there is the cloud node that satisfies the second condition (see Azaria: the VM spot manager can send the cloud spot manager a stored image of the instance, which can be deployed to an on-premises node and then executed without further configuration; paragraph [0084]).
Yi as modified by Azaria does not teach in which the collected resource utilization rate is less than a second threshold value, and wherein the second threshold value is set to a value greater than the first threshold value.
However, Yi teaches obtaining resource utilization of nodes and VM instances (collects resource utilization conditions of all physical hosts, the number of residual resources of each physical host is obtained by calculating original resource capacity data of the physical hosts stored in a database, the central processor resource utilization rate, the memory utilization rate and the hard disk utilization rate of each physical host are further obtained; page 6, paragraph 7th).
Azaria teaches user can request for regular instance(s) and spot instance(s) (paragraphs [0075] and [0084]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that requests to deploy different types of instances would require different amount of resources, and resource required for a regular instance would be more than resource required for a spot instance, which is the same as the collected resource utilization rate is less than a second threshold value, and wherein the second threshold value is set to a value greater than the first threshold value.
As to claim 13, Yi teaches a provisioning method performed by at least one computing device for a cloud service (The full-stage load sharing comprehensive optimization method of the cloud computing management platform; page 6, paragraph 7th), the provisioning method comprising:
collecting resource utilization rates of individual cloud nodes of a plurality of cloud nodes, wherein a resource utilization rate of an individual cloud node includes a resource utilization rate for at least one of a processor or a memory of the individual cloud node (collects resource utilization conditions of all physical hosts, the number of residual resources of each physical host is obtained by calculating original resource capacity data of the physical hosts stored in a database, the central processor resource utilization rate, the memory utilization rate and the hard disk utilization rate of each physical host are further obtained; page 6, paragraph 7th);
receiving a regular instance request from at least one client (creating a virtual machine request; page 6, paragraph 6 and the virtual machine creation queue stores virtual machine creation requests, and when a virtual machine creation request exists; page 9, 1st paragraph);
determining whether there is a cloud node among the plurality of cloud nodes that satisfies a first condition, in which the collected resource utilization rate is less than a first threshold value (acquiring threshold information of all physical hosts; calculating to obtain a central processing unit utilization rate threshold value, a memory utilization rate threshold value, a hard disk utilization rate threshold value and a full disk comprehensive utilization rate threshold value of the cloud computing management platform; page 9, paragraph 6; and calculating a weight value of a physical host; according to the fact that the comprehensive load rate of the whole disk is taken as a main consideration factor, the result of (-1) multiplied by the comprehensive utilization rate of the whole disk is returned to be used as the weight of the physical host, and the lower the comprehensive utilization rate of the physical host is, the larger the weight of the physical host is; page 9, paragraph 10); and
provisioning a requested regular instance in the source cloud node (executing the task of creating a virtual machine; selecting the physical host with the largest weight as the target host according to the weight of the physical host calculated in the eleventh step; if the virtual machine task is created, a virtual machine instance is created on the physical host; page 9, paragraph 11).
Yi further teaches migrating spot VM from overload physical host to reduce the load on the physical host (page 6, paragraph 8).
Yi does not teach determining a source cloud node from among the plurality of cloud nodes based on a determination that there is no cloud node among the plurality of cloud nodes that satisfies the first condition; and migrating at least some of spot instances pre-provisioned and operating on the source cloud node and provisioning a requested regular instance in the specific cloud node.
However, Azaria teaches determine a specific cloud node from among the plurality of cloud nodes based on a determination that there is no cloud node among the plurality of cloud nodes that satisfies the first condition; and terminating at least some of spot instances pre-provisioned and operating on the specific cloud node and provisioning a requested regular instance on the source cloud node (Process flow 700 begins with 702, and moves to operation 704. Operation 704 depicts determining that more computing resources are needed. In some examples, this can comprise VM spot manager 108a of FIG. 1 determining to instantiate another VM instance, and determining that on-premises nodes 106a lack the available computing resources to host this VM instance (or that hosting the VM instance would take node resource usage above a predetermined threshold). After operation 704, process flow 700 moves to operation 706. Operation 706 depicts determining that another entity's spot VM is running on premises. In some examples, VM spot manager 108a can maintain a list of VMs running on on-premises nodes 106a, along with an indication of what entity owns that VM instance. In such examples, VM spot manager 108a can identify whether any of these running VMs have an associated owner different from the customer that owns (or leases) customer system 110a. After operation 706, process flow 700 moves to operation 708. Operation 708 depicts selecting a spot VM to terminate. This can comprise a VM running on on-premises nodes 106a that has an owner different from the customer that owns (or leases) customer system 110a. In some examples, various criteria can be used to select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time, and a VM that is consuming the most computing resources; paragraphs [0075]-[0077]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply and modify/improve the teaching of Azaria to the system of Yi because Azaria teaches a method that uses a data-driven approach to predict resource consumption and help minimize interrupt events where a cloud provider will kill its VMs and return on-premises computing resources to the resource providing customer (paragraph [0018]), and instead of terminate the spot instance, the spot instance could be migrated to another host to continue execution, so improve the performance of the system and users.
As to claim 14, Yi as modified by Azaria teaches the provisioning method of claim 13, wherein the determining the source cloud node comprises:
determining whether a first cloud node among the plurality of cloud nodes satisfies the first condition according to spot instance migration or termination; and determining the first cloud node as the source cloud node based on a determination that the first cloud node satisfies the first condition (see Yi: selecting the physical host with the largest weight as the target host according to the weight of the physical host calculated in the eleventh step; if the virtual machine task is created, a virtual machine instance is created on the physical host; page 9, paragraph 11).
As to claim 15, Yi as modified by Azaria teaches the provisioning method of claim 14, wherein the determining the source cloud node further comprises:
determining, based on the first cloud node not satisfying the first condition, whether a second cloud node among the plurality of cloud nodes satisfies the first condition according to the spot instance migration or the termination (see Azaria: Operation 708 depicts selecting a spot VM to terminate. This can comprise a VM running on on-premises nodes 106a that has an owner different from the customer that owns (or leases) customer system 110a. In some examples, various criteria can be used to select a VM to terminate, such as a VM that has been running for the longest amount of time, a VM that has been running for a shortest amount of time, and a VM that is consuming the most computing resources; paragraphs [0075]-[0077]).
As to claim 18, see rejection of claim 7 above.
As to claim 19, it is the same as the method claim 1 above except this is a provisioning system for a cloud service, and therefore is rejected under the same ground of rejection.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Yi (CN 111061561 A – English translation is provided by IP.com) in view of Azaria et al. (US 2022/0147380 A1) further in view of Shahane et al. (US 11,714,682 B1 – cited in the previous Office action).
As to claim 6, Yi as modified by Azaria does not teach the provisioning method of claim 3, wherein the provisioning the requested regular instance further comprises: further designating another termination target from the list of the pre-provisioned spot instances based on a determination that the predicted resource utilization rate is equal to or greater than the first threshold value.
However, Shahane teaches designating another termination target from the list of the pre-provisioned spot instances based on a determination that the predicted resource utilization rate is equal to or greater than the first threshold value (the routine 400 may determine a quantity of memory that needs to be reclaimed in order to meet current or pending resource demands, and the determination at decision block 414 may be as to whether the quantity of memory that can be reclaimed from this virtual machine instance is sufficient to meet the demand. If not, then the routine 400 may branch to block 410, identify another virtual machine instance, and iterate until a sufficient quantity of the computing resource is identified as reclaimable; col. 23, lines 34-43).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Shahane to the system of Yi as modified by Azaria because Shahane teaches a resource reclamation system may reclaim the underutilized computing resources and reallocate them to other uses. The resource reclamation system may interact with a reclaimable resource identification process that executes within the virtual machine instance, which may identify unused or underused computing resources, claim them, and then allow the resource reclamation system to reallocate them.
Claims 8-10 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Yi (CN 111061561 A – English translation is provided by IP.com) in view of Azaria et al. (US 2022/0147380 A1) further in view of Elliott et al. (US 9,639,875 B1 – cited in the previous Office action).
As to claim 8, Yi as modified by Azaria does not teach the provisioning method of claim 1, further comprising: receiving, from a client, a plurality of spot instance requests within a current time window; and performing, at a last point of the current time window, provisioning for requested plurality of spot instances.
However, Elliott teaches receiving, from a client, a plurality of spot instance requests within a current time window (Based on the listings, purchase client may identify one or more listings to reserve (purchase) and send a reserve instance reservation request 540 to resource manager 210. If the reservation request is successful (e.g., a requested listing has not been purchased by another client), then a reservation response 550 indicating success may be sent. Such a response may include access information for purchase client 202 to use the reserved instance; col. 14, lines 57-65); and performing, at a last point of the current time window, provisioning for requested plurality of spot instances (In some embodiments, the original usage rate may be averaged with a new usage rate for the remaining time period (e.g., based on current usage rates for the specified configuration of instance); col. 19, lines 37-40. Since the resale resources are unused resources, it must be occurred at the end of the time window.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching Elliott to the system of Yi as modified by Azaria because both are directed to reclaim/reuse unused resources to service a client request, and by applying the teaching of Elliott, the system can also implement in the market to obtain money/currency when the resources are not needed, thus, reduce the cost of operation.
As to claim 9, Yi as modified by Azaria and Elliott teaches the provisioning method of claim 8, wherein the performing the provisioning for the requested plurality of spot instances comprises: excluding, from a provisioning target, an instance that exceeds an allowable waiting time of a corresponding client among the requested plurality of spot instances (see Elliott: a reserved compute instance available for resale may be selected in order to evaluate whether it is reconfigurable to satisfy a specified configuration, in various embodiments. Resale marketplace rules or policies may, in some embodiments, eliminate some listings that may otherwise be reconfigurable. Lack of authorization, as noted above, length of time listed (recently listed), insufficient remaining term length, or specially priced (e.g., originally discounted) reserved compute instances are some examples of policies that might be used, in various embodiments, to exclude some listings from evaluation.; col. 17, lines 39-49).
As to claim 10, Yi as modified by Azaria and Elliott teaches the provisioning method of claim 8, wherein the performing the provisioning for the requested plurality of spot instances comprises: determining at least one spot instance among the requested plurality of spot instances based on a bid price; and provisioning the at least one determined spot instance (see Elliott: A spot pricing policy may allow a client to specify the maximum hourly price … using a spot instance; col. 7, line 59 – col. 8, line 3).
As to claim 16, Yi as modified by Azaria does not clearly teach the provisioning method of claim 13, wherein the migrating the at least some of the spot instances of the source cloud node comprises: determining the target cloud node from among the plurality of cloud nodes based on a number of spot instances that can be provisioned in the target cloud node; and migrating the at least some of spot instances of the source cloud node to the determined target cloud node.
However, Elliott teaches a reconfiguration operation to move a reserved compute instance from one location to another may be restricted based on a policy that limits number reserved compute instances in a particular location (col. 12, lines 10-13).
Given the teaching of Elliott above, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Elliott to the system of Yi as modified by Azaria to determine a node that has not reached the limit number as a target node to migrate the instance.
As to claim 17, Yi as modified by Azaria does not clearly teach the provisioning method of claim 16, wherein the migrating to the determined target cloud node comprises: migrating spot instances of the source cloud node as many as the number of spot instances that can be provisioned in the determined target cloud node; wherein spot instances remaining on the source cloud node are terminated before the requested regular instance is provisioned.
However, Elliott teaches a reconfiguration operation to move a reserved compute instance from one location to another may be restricted based on a policy that limits number reserved compute instances in a particular location (col. 12, lines 10-13).
Given the teaching of Elliott above, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement to system of Yi as modified by Azaria and Elliott to migrating spot instances of the source cloud node as many as the number of spot instances that can be provisioned in the determined target cloud node.
As for spot instances remaining on the source cloud node are terminated before the requested regular instance is provisioned, it is just an option among two options, terminate the migrated spot instances before or after the spot instances provisioned in the target node.
Allowable Subject Matter
Claims 11-12 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s arguments with respect to claims 1-19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 37 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEM K CAO whose telephone number is (571)272-3760. The examiner can normally be reached Monday-Friday 8:00am-4:00pm.
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 Blair can be reached at 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.
/DIEM K CAO/Primary Examiner, Art Unit 2196
DC
March 9, 2026