DETAILED ACTION
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 6-7, 9-13, 15-16, 18-22, 24-25, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Unknown author (“OpenStack Docs: Compute Schedulers”, docs.openstack.org/nova/train/admin/configuration/schedulers.html, July 15, 2019) (Hereafter as “Nova Scheduler”), Unknown Author (“Live-migrate instances”, docs.openstack.org/nova/latest/admin/live-migration-usage.html, July 1, 2022) (hereafter as “Nova Scheduler II”), in view of Sharma et al. (US PGPUB 2018/0191859).
As for claim 1, Nova Scheduler teaches hosting a virtual machine in a source computing node (Page 2, “…the scheduler chooses a new host when an instance is migrated…” prior art teaches moving a virtual machine instance to a different compute server. Thus, the virtual machine instance executing compute server before the migration is understood as source computing node the virtual machine is hosted on.different than the destination compute server.);
responding to a virtual machine migration request (Page 1-2, “…compute uses the nova-scheduler service to determine how to dispatch compute requests….for example, the nova-scheduler service determines on which host a VM should launch…the scheduler chooses a new host when an instance is migrated…” teaching compute requests includes migration requests) by:
selecting a target computing node for migration (Pg. 2, “…scheduler chooses a new host when an instance is migrated…”).
While Nova Scheduler teaches an instance is migrated and teaching the live migration of instances (Pg. 2 and 25). Thus, it would have been obvious to a person of ordinary skill in the art to recognize the Nova scheduler teaches migrating the virtual machine from the source computing node to the target computing node because doing so allows for the VM to be migrated and/or perform live migration of an VM instance. Nevertheless, in the interest of compact prosecution, Examiner note Nova Scheduler does not explicitly state migrating the virtual machine from the source computing node to the target computing node.
However, Nova Scheduler II teaches migrating the virtual machine from the source computing node to the target computing node (Pg. 3, Section - Automatic selection of the destination host, “…migrate the instance…”).
It would be obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate Nova Scheduler II’s teaching of migrating the virtual machine from the source computing node to the target computing node into Nova Scheduler with nova scheduler performing live migration of virtual instances because they are directed to the same nova scheduler and because doing so allows for improved automated selection of destination hosts (Nova scheduler II, Pg. 3).
While Nova Scheduler teaches host resource records in the form of compute node records and that they are updated with different configurations of allocation (See, e.g., Pg. 23, 26, etc.). Nova Scheduler and Nova Scheduler II do not explicitly teach establishing a placeholder at a target computing node of the virtualized high-availability multi-node computing cluster, where the placeholder corresponds to reserved resources of the target computing node.
However, Sharma teaches Nova Scheduler operation including a non-transitory computer readable medium having stored thereon a sequence of instructions which, when stored in memory and executed by a processor cause the processor to perform acts (paragraph 8) comprising:
hosting a virtual machine in a virtualized high-availability multimode computing cluster (Abstract, “plurality of hosts ….available to host a …virtual machine…” and paragraph 48, “…placement….in a high availability (HA) configuration…may choose ….different host aggregates or different availability zones….such that a single host failure, or a single rack failure, or a host aggregate failure or availability zone failure can be tolerated…” teaching the scheduler operates placement of virtual machine instances to maximize availability of the virtual machine execution between the plurality of hosts. Thus, the plurality of hosts are understood as a form of high-availability multimode computing cluster) ; and
establishing a placeholder at a target computing node of the virtualized high-availability multi-node computing cluster, where the placeholder corresponds to reserved resources of the target computing node (paragraph 51-71, “…for each host (or compute node) ….the compute_nodes database stores inventory records …colors…vCPU…RAM…Disk…PCI devices…NUMA…Topology…” and paragraph 162, “…after scheduling the requested HA virtual machine to run on the selected host, the NOVA scheduler 1002 updates the color value stored in the compute_nodes record for the selected host to indicate that the requested HA virtual machine is ….scheduled to run on the selected host….” Teaching the use of “compute_nodes record to establish a placeholder at the selected host because it can be done for virtual machines scheduled to run (thus, understood as not yet run, i.e., before it runs), thus it is a place holder for a VM to run in the future and not an indication of already executing VM.)
It would be obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate Sharma’s teaching of hosting a virtual machine in a virtualized high-availability multimode computing cluster and establishing a placeholder at a target computing node of the virtualized high-availability multi-node computing cluster, where the placeholder corresponds to reserved resources of the target computing node into Nova Scheduler and Nova Scheduler II with nova scheduler performing live migration of virtual instances because they are directed to the same nova scheduler and because doing so allows for improved elasticity to allow for improved dynamic resource allocation (Sharma, Paragraph 3).
As for claim 2, Sharma also teaches the virtual machine migration request corresponds to a placement to satisfy a high-availability requirement (paragraph 15, “…the first virtual machine maybe a high availability virtual machine….determine that two or more hosts are available to host the first virtual machine….select a host from among the two or more hosts based on a number of high availability virtual machines currently hosted on each …of the hosts….selected host maybe the host currently hosting a least number…” ).
As for claim 3, Sharma teaches high-availability requirement including at least one of, any number of anti-affinity rules, or any number of high-availability reboot rules (paragraph 48, active/standby module pair on different hosts can be understood as form of anti-affinity rule and are also related to the reboot/recovery rule for high-availability).
In addition, Nova Scheduler also teaches at least one of, any number of anti-affinity rules, or any number of high-availability reboot rules (Pg. 8-11, “…DifferentHost Filter…” and “NUMATopologyFilter” can be understood as teaching affinity/anti-affinity rule based requirements.).
As for claim 4, Sharma also teaches establishing the placeholder at the target computing node prevents allocating the reserved resources of the target computing node to any entity other than the virtual machine (paragraph 77, “…once a HA virtual machine is scheduled to run on a given host, …flips the bit of the color value….for the given host in the compute_nodes database. By changing the bit…this host is then filtered out for scheduling a HA virtual machine in a subsequent stack with a color…” teaching preventing allocation of same host/reserved resources to another entity besides the just scheduled virtual machine).
As for claim 6, Nova scheduler also teaches the virtual machine migration request corresponds to a requirement to satisfy a placeholder placement rule (Pg. 2, “…scheduler chooses a new host when an instance is migratedprefilters….augment the request that is sent to placement…” Pg. 3-14, “filter scheduler…filtering and weighting to make informed decisions on where ….”applies filters to determine which hosts…Compute Filters …. AggregateCoreFilter … AggregateMultiTenancyIsolaton … AggregateTypeAffinityFilter … Differenthosefilter … IsolatedHostsFilter …” are variety of rules for placement of to be deployed instances (i.e., placeholder for scheduling but not yet deployed instance).
As for claim 7, Nova Scheduler also teaches placeholder placement rule corresponds to at least one of, a scheduler resource reservation awareness rule, or a hypervisor resource reservation awareness rule (Pg. 4-14, “…IsolaAggregateCoreFilter … AggregateDiskFilter … AggregateIOOpsFilter… AggregateMultiTenancyIsolation… AggregateNumInstancesFilter … AggregateRamFilter… tedHostsFilter ….” Numerous filters used by scheduler can be understood as resource resource reservation awareness rules.)
As for claim 9, Sharma also teaches the migrating of the virtual machine from the source computing node to the target computing node using the reserved resources observes high-availability requirements (paragraph 48, …if an application has an active/standby module…placing…different hosts, different racks, different …aggregates…such that a single host failure…or availability zone failure can be tolerated…” teaching migration of vm to a standby instance can be based on high-availability requirements.).
As for claims 10-13, 15-16, 18, and 19-22, 24-25, and 27 contain similar limitations as claims 1-4, 6-7, and 9 above respectively, thus, they are rejected under the same rationales.
Claim(s) 5, 8, 14, 17, 24, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Nova Scheduler, Nova Scheduler II, and Sharma, further in view of Mansur et al. (US PGPUB 2021/0042139).
As for claim 5, Nova Scheduler, Nova Scheduler II, and Sharma do not explicit teach migration request correspond to a resource demand to increase resource available to the VM when source node does not have sufficient resource to fulfill the demand.
However, Mansur teaches a known method of virtual machine migration between networked nodes including the virtual migration request corresponds to a resource demand to increase resource available to the virtual machine when the source computing node cannot fulfill the resource demand using resources available at the source computing node (paragraph 13, “…on-demand …scalability for virtual machines….system requirements of a virtual machine exceed the capacity of the server on which the virtual machine is deployed (e.g., the source host….allows for the virtual machine to be migrated to another server with more available resources (e.g., the destination host…” teaching whenever the system resource requirement of VM exceeds capacity, in an on demand manner, migration can be triggered in response to it). This known technique is applicable to the system of Nova Scheduler, Nova Scheduler II, and Sharma as they both share characteristics and capabilities, namely, they are directed to VM migration in networked hosts.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Mansur would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Mansur to the teachings of Nova Scheduler, Nova Scheduler II, and Sharma would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such VM migration features into similar systems. Further, applying the virtual migration request corresponds to a resource demand to increase resource available to the virtual machine when the source computing node cannot fulfill the resource demand using resources available at the source computing node to Nova Scheduler, Nova Scheduler II, and Sharma with migration request to perform migration of VM instance from a source node to a destination node accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow better utilization of different performances of different computing nodes. (Mansur, paragraph 2)
As for claim 8, Mansur also teaches the target computing node has fewer available resources than the source computing node and further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of migrating a further virtual machine from the target computing node to a further target computing node (paragraph 13, “…on-demand …scalability for virtual machines….system requirements of a virtual machine exceed the capacity of the server on which the virtual machine is deployed (e.g., the source host….allows for the virtual machine to be migrated to another server with more available resources (e.g., the destination host…”. While the prior art does not explicitly teach a second migration from the target computing node to a further target computing node, the prior art teaches the migration is performed on-demand, whenever system requirements of a virtual machine exceed the capacity of the server on which the VM is currently deployed, thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application that the system is capable of migrating the VM more than one time because doing so allows for on-demand migration of VM whenever the migration condition is met to effectively perform the process in an on demand, non-limited to single instance of determination).
As for claims 14 and 17, and 24 and 26 contain similar limitations as claims 5 and 8 above respectively, thus, they are rejected under the same rationales.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199