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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In regards to claim 1, the claim(s) recite(s) A method comprising:
identifying a host to be added to a computing environment;
identifying physical resources available on the host;
determining a host cluster for the host from a plurality of host clusters in the computing environment based on the physical resources available on the host, wherein each host cluster of the plurality of host clusters promotes one or more physical resources over one or more other physical resources;
assigning the host to the host cluster.
The steps of “identifying a host to be added to a computing environment; identifying physical resources available on the host; determining a host cluster for the host from a plurality of host clusters in the computing environment based on the physical resources available on the host, wherein each host cluster of the plurality of host clusters promotes one or more physical resources over one or more other physical resources; assigning the host to the host cluster” are directed to an abstract idea specifically, the fundamental organizational practice of evaluating a resources characteristics and assigning it to a predefined category based on those characteristics. This concept can be performed entirely by a human administrator manually inspecting a server’s hardware and deciding which group it belongs to, requiring no computer. The claims do no not integrate the abstract idea into a practical application because no improvement to computer functionality is recited and the computing environment merely provides a context in which the abstract organizational method is applied (See MPEP 2106.04 (d)). The additional elements of computing environment, host clusters, and physical resources are generic computing constructs performing conventional functions and do no amount to significantly more than the abstract idea (See MPEP 2106.05).
In regards to claim 2, the claim(s) recite(s) “wherein the physical resources comprise memory resources and processing resources.” Claim 2 is rejected for the same reasons as claim 1. The additional limitation merely narrows the type of physical characteristics used as the organizational basis from arbitrary hardware attributes to memory and processing resources that amounts to mere instructions to apply (MPEP 2106.05(f).
In regards to claim 3, the claim(s) recite(s) “identifying host resource availability for one or more virtual machines on one or more other hosts in the host cluster; identifying a subset of virtual machines from the one or more virtual machines with the host resource availability that satisfy one or more criteria; and migrating the subset of virtual machines to the host.” Claim 3 is rejected under the same reasons as claim 1. The additional limitations recite the abstract concept of monitoring existing resources, selecting those meeting reassignment criteria, and reassigning them, which is a routine mental process performable by a human manager with a computer. Further Note MPEP 2106.05(g) and 2106.05(d) of conventional data transmission being WURC and insignificant extra-solution activity.
In regards to claim 4 the claim(s) recite(s) “wherein the host resource availability for each virtual machine of the one or more virtual machines comprises processor resource availability for the virtual machine or memory resource availability for the virtual machine.” Claim 4 is rejected under the same reasons as claims 1 and 3. This limitation merely narrows the resource metric used in the abstract evalutation and selection process to processor or memory availability without introducing and specific technical mechanism for measuring or acting on those metrics. See MPEP 2106.05(f).
In regards to claim 5, the claim(s) recite(s) “wherein the physical resources comprise networking resources or storage resources.” Claim 5 is rejected under the same reasons as claim 1. As with claim 2, this limitation narrows the type of physical characteristics forming the basis for the abstract categorization without introducing any technical improvement or non-conventional element. See MPEP 2106.05(f).
In regards to claim 6, the claim(s) recite(s) “identifying a second host to be added to the computing environment; identifying second physical resources available on the second host; determining that the second host requires a new host cluster different from the plurality of host clusters based on the second physical resources available on the second host; creating the new host cluster; and assigning the second host to the new host cluster.” Claim 6 is rejected under the same reasons as claim 1. The additional limitations extend the abstract method of a mental process to cover the scenario of creating a new category when existing categories are insufficient. A routine management decision performable by a human administrator with a computer.
In regards to claim 7, the claim(s) recite(s) “identifying resource requirements associated with a plurality of virtual machines on hosts in the plurality of host clusters; selecting one or more virtual machines from the plurality of virtual machines to be migrated to the new host cluster based on the resource requirements associated with the plurality of virtual machines; and migrating the one or more virtual machines to the new host cluster.” Claim 7 is rejected under the same reasons as claim 1 and 6. These limitations add the abstract concept of surveying existing resources, matching them to a newly created category based on their requirements and transferring them which is extending the organizational method of claim 6 without introducing any technical improvement or non-conventional element. Note MPEP 2106.05(g) and 2106.05(d) of conventional data transmission being WURC and insignificant extra-solution activity.
In regards to claim 8, the claim(s) recite(s) “identifying a virtual machine to be added to the computing environment; identifying resource requirements associated with the virtual machine; selecting a destination cluster for the virtual machine from the plurality of host clusters based on the resource requirements associated with the virtual machine.” Claim 8 is rejected under the same reasons as claim 1. The additional limitations recite the abstract concept of matching a new resource to the most appropriate predefined category based on its characteristics.
Claims 9-16 are directed to a computing apparatus and recite limitations that directly correspond to the method steps of claims 1-8 respectively. Claims 9-16 are rejected under the same reasons set forth by claims 1-8. The recitation of a storage system, at least one processor, and program instructions does not transform the abstract organizational method into patent eligible subject matter. These are merely generic computing components.
Claims 17-19 are directed to a system comprising a plurality of hosts in a plurality of clusters and a management computer. Claims 17-19 are rejected under the same reasons as claims 1, 2, and 5 respectively. The recitation of a system comprising generic host computers, generic clusters, and a generic management computer performing the same abstract organizational steps does not introduce patent-eligible subject matter.
Claim 20 adds the limitation that the first host is configured to communicate its physical resources to the management computer. This limitation recites the conventional and well understood operation of a computing device reporting its configuration to a management system, a basic network communication function that is entirely routine and conventional in datacenter management environments. Claim 20 is rejected under the same reason as claim 17.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 5-6, 9-10, 13-14, 16-19 is/are rejected under 35 U.S.C. 102(a)(1) as being UNPATENTABLE by OpenStack Nova Documentation “Host Aggregates” (https://web.archive.org/web/20191121082244/https://docs.openstack.org/nova/latest/admin/aggregates.html)
As to claim 1, OpenStack teaches a method comprising: identifying a host to be added to a computing environment; identifying physical resources available on the host; determining a host cluster for the host from a plurality of host clusters in the computing environment based on the physical resources available on the host, wherein each host cluster of the plurality of host clusters promotes one or more physical resources over one or more other physical resources; assigning the host to the host cluster. (See OpenStack, Section “Example: Specify Compute Hosts with SSDs” Command 3) “$openstack aggregate add host 1 node1… [u’node1’]” Openstack discloses adding a compute node (node1) to the computing environment via the “aggregate add host” command. (See OpenStack, Section “Configure Scheduler to Support Host Aggregates,” P. 1) “One common use case for host aggregates is when you want to support scheduling instances to a subset of compute hosts because they have a specific capability. For example, you may want to allow users to request compute hosts that have SSD drives if they need access to faster disk I/O, or access to compute hosts that have GPU cards to take advantage of GPU-accelerated code.” Openstack discloses identifying the physical hardware capability (SSD storage, GPU) available on each host as the basis for aggregate assignment. (See OpenStack, Section “Host Aggregates”, P. 1) “Host aggregates are a mechanism for partitioning hosts in an OpenStack cloud, or a region of an OpenStack cloud, based on arbitrary characteristics. Examples where an administrator may want to do this include where a group of hosts have additional hardware or performance characteristics.” Openstack discloses a plurality of host aggregates each defined by a specific hardware characteristic it promotes. The “fast-io” aggregate promotes SSD storage resources, GPU aggregates promote graphics processing resources, directly teaching a plurality of clusters each promoting there one or more physical resources over others. (See Openstack, Section “Example: Specify Compute Hosts with SSDs” Command 2) “$openstack aggregate add host 1 node1… $openstack aggregate add host 1 node2” Openstack explicitly discloses assigning hosts node1 and node2 to aggregate 1 (the “fast-io” SSD aggregate) via the “aggregate add host” command.
PNG
media_image1.png
460
558
media_image1.png
Greyscale
As to claim 2, OpenStack teaches wherein the physical resources comprise memory resources and processing resources. (See OpenStack, Section “Configure Scheduler to Support Host Aggregates,” P. 1) “$openstack flavor create -id 6 ram 8192 -disk 80 -vcpus 4 ssd.large” and (See OpenStack, Section “Example: Specefiy Compute Hosts with SSDs,” flavor creation command) “For example, you may want to allow users to request compute hosts that have SSD drives if they need access to faster disk I/O, or access to compute hosts that have GPU cards to take advantage of GPU-accelerated code.” (See OpenStack, Section “Host Aggregates” P. 1) “Host aggregates are a mechanism for partitioning hosts in an OpenStack cloud, or a region of an OpenStack cloud, based on arbitrary characteristics. Examples where an administrator may want to do this include where a group of hosts have additional hardware or performance characteristics.”
As to claim 5, OpenStack teaches wherein the physical resources comprise networking resources or storage resources. (See Section “Configure Scheduler to Support Host Aggregates” P. 1) “For example, you may want to allow users to request compute hosts that have SSD drives if they need access to faster disk I/O, or access to compute hosts that have GPU cards to take advantage of GPU-accelerated code.” and “ $openstack aggregate set –property ssd = true 1… properties” ssd= ‘true’”. SSD drives a re a storage resource directly teaching this limitation.
PNG
media_image2.png
285
472
media_image2.png
Greyscale
As to claim 6, OpenStack teaches identifying a second host to be added to the computing environment; identifying second physical resources available on the second host; determining that the second host requires a new host cluster different from the plurality of host clusters based on the second physical resources available on the second host; creating the new host cluster; and assigning the second host to the new host cluster. OpenStack teaches creating a new host aggregate when a new hardware type requires a new grouping: (See Section “Example: Specify Compute Hosts with SSDs” Command 1) “$openstack aggregate create – zone nova fast-io… name: fast-io” followed by (See Section “Example: Specify Compute Hosts with SSDs” Command 2) “$openstack aggregate set-property ssd=true 1” and then (See Section “Example: Specify Compute Hosts with SSDs” Command 3) “$openstack aggregate add host 1 node1” This sequence teaches identifying a second host with physical resources (SSD), determining it requires a new aggregate (fast-io) different from existing aggregates, creating that new aggregate via “aggregate create”, and assigning the host to it via “aggeregate add host”.
PNG
media_image3.png
818
652
media_image3.png
Greyscale
Claims 9-10, 13-14 are directed to a computing apparatus with a storage system, at least one processor, and a program instructions performing operations corresponding to claims 1, 2, 5, and 6 respectively. Claims 9-10, 13-14 are rejected for the same reasons as claims 1, 2, 5, and 6 above.
Claim 17 recites a system comprising: a plurality of hosts in a plurality of clusters, wherein each cluster of the plurality of clusters promotes one or more physical resources over one or more other physical resources; a management computer configured to: identify a first host to be added to the plurality of hosts; identify physical resources available on the first host; determine whether the first host qualifies for a cluster in the plurality of clusters based on the physical resources available on the first host, wherein each cluster of the plurality of clusters comprises one or more hosts of the plurality of hosts that promote one or more physical resources over one or more other physical resources; if the first host qualifies for a cluster in the plurality of clusters, assign the first host to the cluster; and if the first host does not qualify for a cluster in the plurality of clusters: creating a cluster different from the plurality of clusters; and assign the first host to the new cluster. OpenStack discloses; (See Section “Host Aggregates” P. 1)“Host aggregates are a mechanism for partitioning hosts in an OpenStack cloud, or a region of an OpenStack cloud, based on arbitrary characteristics. Examples where an administrator may want to do this include where a group of hosts have additional hardware or performance characteristics.” Directly teaching a plurality of hosts in a plurality of clusters each promoting specific physical resources. OpenStack discloses the Nova management system identifying hosts and their physical resource characteristics via the “openstack aggregate add host” mechanism and hardware characteristic metadata assignment: “$openstack aggregate set- property ssd=true1” OpenStack discloses: “the scheduler then endeavors to match user requests for instances of the given flavor to a host aggregate with the same key-value pair in its metadata.” Teaching the management system determining whether a hosts characteristics match an existing aggregates criteria. Openstack discloses “$openstack aggregate add host 1 node2” – directly teaching assigning qualifying hosts to an existing cluster. Openstack discloses “$openstack aggregate create -zone nova fast-io” followed by “$openstack aggregate add host 1 node1” directly teaching creating a new cluster for a host that does not qualify for existing clusters and assigning that host to the new cluster.
Claim 18 depends from claim 17 and recites the same limitation as claim 2 as a system claim. Claim 18 is rejected under the same reasons as claim 2.
As to claim 19, Openstack teaches wherein the physical resources comprise networking resources or storage resources. Openstack discloses storage resources as the physical resource type used to define the “fast-io” aggregate: (See Section “Configure Scheduler to Support Host Aggregates” P. 1) “For example, you may want to allow users to request compute hosts that have SSD drives if they need access to faster disk I/O…” and (See Section “Example: Specify Compute Hosts with SSDs” Command 2) “$openstack aggregate set – property ssd=true 1… properties: ssd=true.”
Claim Rejections - 35 USC § 103
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) 3, 4, 7-8, 11, 12, 15-16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over OpenStack Nova Documentation “Host Aggregates” (https://web.archive.org/web/20191121082244/https://docs.openstack.org/nova/latest/admin/aggregates.html) in view of ELYASHEV (US20100332657)
As to claim 3, ELYASHEV teaches identifying host resource availability for one or more virtual machines on one or more other hosts in the host cluster; identifying a subset of virtual machines from the one or more virtual machines with the host resource availability that satisfy one or more criteria; and migrating the subset of virtual machines to the host. (P. 0023) “For each host 109, the VM manager 120 also keeps track of the resources (e.g., the number of cores, physical memory size, processing speed, etc.) provided by the host, configurable data items of the host (e.g., host strength, memory over-commitment percentage, VCPU consumption percentage, etc), and configurable data items for the virtual machines 131 currently running on the host (e.g., requested number of VCPUs and requested memory size).” (P.0028) “the load monitor 210 monitors the CPU utilization (also referred to as "CPU usage") of the host 109, and the lengths of time during which the CPU utilization is above a high CPU utilization border (e.g., 80%) or under a low utilization border (e.g., 20%).” (P.0030) “a VM selection module 240 selects a virtual machine on the host to move to another host. In one embodiment, the VM selection module 240 selects the virtual machine that incurs the least amount of load on the host.” (P. 0039) “the load balancer 250 identifies a virtual machine on the host that creates the least amount of load (block 440). In one embodiment, the amount of load incurred by a virtual machine is calculated by a percentage value representing the CPU usage of the virtual machine.” (P. 0041) “The VM selected at block 440 is then migrated from the overloaded host to the host selected at block 450 (block 470).” (P.0010) “The host controller then selects a target host from the host cluster as a destination for migrating the selected virtual machine.”
It would have been obvious for one of ordinary skill in the art before the effective filing date to combine OpenStacks host cluster framework with ELYASHEVs load based VM selection and migration mechanism in order to host a virtual machine.
As to claim 4, ELYASHEV teaches, processor resource availability for the virtual machine or memory resource availability for the virtual machine. (P.0024) “In one embodiment, the load incurred by a virtual machine on a host 109 can be estimated from the number of VCPUs used by the virtual machine.” (P.0036) “the VM manager 120 confirms that the selected host has sufficient memory to accommodate the virtual machine (block 340).” (P.0041) “the load balancer 250 confirms that the selected host has sufficient resources; e.g., CPU resources and memory resources to accommodate the virtual machine (block 460).”
Obviousness rejection for the same reasons as claim 3 above.
As to claim 7, ELYASHEV teaches, identifying resource requirements associated with a plurality of virtual machines on hosts in the plurality of host clusters; selecting one or more virtual machines from the plurality of virtual machines to be migrated to the new host cluster based on the resource requirements associated with the plurality of virtual machines; and migrating the one or more virtual machines to the new host cluster. (P. 0033) “The VM manager 120 can also receive information of the virtual machine to be run; e.g., the number of VCPUs requested by the virtual machines and requested memory usage (block 320). The information may be received from the user, or from an internal storage (e.g., the host data module 220 of FIG. 2) if it is already known. In response to the request, the VM manager 120 selects a host from the cluster 103 according to a host selection rating that is given to each host 109 in the cluster 103 (block 330). The host selection rating is based on a combination of a host's current CPU load and an expected loaded incurred by the pending virtual machine.” (P. 0036) “After a host is selected, the VM manager 120 confirms that the selected host has sufficient memory to accommodate the virtual machine (block 340). The VM manager 120 may compare the requested memory size with an estimated host memory size, which is the physical memory size of the selected host multiplied by a configurable over-commitment percentage. If the requested memory size is larger, then the VM manager 120 finds another host that has the second lowest host selection rating. The VM manager 120 may continue the selection, in an increasing order of the host selection rating, until a host having sufficient memory is found. The VM manager 120 then assigns the virtual machine to the selected host (block 350).” (P. 0030) “a VM selection module 240 selects a virtual machine on the host to move to another host. In one embodiment, the VM selection module 240 selects the virtual machine that incurs the least amount of load on the host. If the host is still overloaded after unloading the virtual machine, the VM selection module 240 can select, from the remaining virtual machines on the host, a next virtual machine that incurs the least amount of load on the host. Thus, virtual machines can be unloaded from an overloaded host, in a sequence ordered by their respective load incurred on the host, until the host reaches a normal level of load.” (P. 0041) “The VM selected at block 440 is then migrated from the overloaded host to the host selected at block 450 (block 470).”
Obviousness rejection for the same reasons as claim 3.
As to claim 8, ELYASHEV teaches identifying a virtual machine to be added to the computing environment; identifying resource requirements associated with the virtual machine; selecting a destination cluster for the virtual machine from the plurality of host clusters based on the resource requirements associated with the virtual machine. (P.0032) “the method 300 begins when the VM manager 120 receives a request to run a virtual machine (block 310). The request can be received through the user interface device 260 from a user (e.g., a system administrator), or from a request internally generated by the host controller” (P.0033) “The VM manager 120 can also receive information of the virtual machine to be run; e.g., the number of VCPUs requested by the virtual machines and requested memory usage (block 320). The information may be received from the user, or from an internal storage (e.g., the host data module 220 of FIG. 2) if it is already known. In response to the request, the VM manager 120 selects a host from the cluster 103 according to a host selection rating that is given to each host 109 in the cluster 103 (block 330). The host selection rating is based on a combination of a host's current CPU load and an expected loaded incurred by the pending virtual machine. In one embodiment, the host selection rating can be formulated as follows:
Host_cpu.times.Host_cores/VcpuConsumptionPercentage+PendingVcpus,
where Host_cpu is a percentage value representing the average CPU utilization of a core, Host_cores is the number of cores on the host, and VcpuConsumptionPercentage is a configurable value representing the "VCPU consumption percentage," which is configurable percentage value that estimates the load on a core incurred by a single virtual machine. The value of "Host_cpu.times.Host_cores/VcpuConsumptionPercentage" represents an estimation of the current CPU consumption of the host. PendingVcpus is the number of VCPUS (or cores) to be used by the pending virtual machine, which represents the expected load incurred by the pending virtual machine on the host. The host having the lowest host selection rating can be selected.”
It would have been obvious for one of ordinary skill in the art before the effective filing date to combine OpenStacks resource type cluster framework with ELYASHEV’s explicit VM resource requirement identification and host selection mechanism in order to host a virtual machine.
Claims 11, 12, 15-16 are apparatus claims corresponding to the method claims 3, 4, 7-8 respectively and are rejected for the same reasons.
As to claim 20, ELYASHEV teaches the first host configured to communicate the physical resources to the management computer. (P.0028) “the load monitor 210 monitors the CPU utilization (also referred to as "CPU usage") of the host 109, and the lengths of time during which the CPU utilization is above a high CPU utilization border (e.g., 80%) or under a low utilization border (e.g., 20%).” (P.0036) “the VM manager 120 confirms that the selected host has sufficient memory to accommodate the virtual machine (block 340). The VM manager 120 may compare the requested memory size with an estimated host memory size, which is the physical memory size of the selected host…” (P.0041) “After a target host is selected, the load balancer 250 confirms that the selected host has sufficient resources; e.g., CPU resources and memory resources to accommodate the virtual machine…”
It would have been obvious for one of ordinary skill in the art before the effective filing date to configure the host to communicate its physical resources to the management computer to enable the resource tracking and migration function disclosed in ELYASHEV in order to host a virtual machine.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELMAN MOHAMED ABDULLAHI whose telephone number is (571)272-8556. The examiner can normally be reached 7:30-5:00 (Fri alternating).
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 at (571) 272-3759. 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.
/SELMAN MOHAMED ABDULLAHI/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights