DETAILED ACTION
This is the initial Office action based on the application filed on June 11, 2024.
Claims 1-20 are pending.
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 Objections
Claims 1, 8, and 15 are objected to because of the following informalities:
Claims 1, 8, and 15 in line 3, line 5, and line 8 respectively, recite “VM.” It should read – virtual machine (VM) --.
Claims 1, 8, and 15 in line 9, line 11, and line 13 respectively, recite “has resources.” It should read – has the resources --.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 8, and 15 recite, in line 3, line 5, and line 7 respectively, the limitation “the contents.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as -- contents – in Claims 1, 8, and 15.
Claims 2-7 depend on Claim 1. Therefore, Claims 2-7 suffer the same deficiency as Claim 1.
Claims 9-14 depend on Claim 8. Therefore, Claims 9-14 suffer the same deficiency as Claim 8.
Claims 16-20 depend on Claim 15. Therefore, Claims 16-20 suffer the same deficiency as Claim 15.
Claims 1, 8, and 15 recite, in line 10, line 12, and line 15 respectively, the limitation “the software.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets the limitation as -- software – in Claims 1, 8, and 15.
Claims 2-7 depend on Claim 1. Therefore, Claims 2-7 suffer the same deficiency as Claim 1.
Claims 9-14 depend on Claim 8. Therefore, Claims 9-14 suffer the same deficiency as Claim 8.
Claims 16-20 depend on Claim 15. Therefore, Claims 16-20 suffer the same deficiency as Claim 15.
Claim 7 recites, in line 1, the limitation “the priority.” The claims are rendered vague and indefinite because it is unclear to the Examiner whether the limitation is referring back to “valid assigned priority” recited in line 4 of Claim 1, “lowest priority” recited in lines 7-8 of Claim 1, or “a next higher priority” recited in line 8 of Claim 1. In the interest of compact prosecution, the Examiner interprets this limitation as referring back to “lowest priority” recited in lines 7-8 of Claim 1.
Claim 20 recites, in line 1, the limitation “the priority.” The claims are rendered vague and indefinite because it is unclear to the Examiner whether the limitation is referring back to “valid assigned priority” recited in line 8 of Claim 15, “lowest priority” recited in line 12 of Claim 15, or “a next higher priority” recited in line 12 of Claim 15. In the interest of compact prosecution, the Examiner interprets this limitation as referring back to “lowest priority” recited in line 12 of Claim 15.
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.
Claims 1, 3-4, 8, 10-12, 15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0146780 (hereinafter “Barrat”) in view of US 2019/0012208 (hereinafter “Ganesan”), WO 2017/028907 (hereinafter “Formanek”), and US 2014/0007097 (Provided by Applicant’s IDS, hereinafter “Chin”).
As per Claim 1, Barrat discloses:
A computer-implemented method (abstract, “Technical solutions are described for performing a live update of an operating system. An example method includes […].”) to perform operating system live update in a resource constrained computer system, the computer-implemented method comprising:
[…] to create a new [partition] corresponding to an original [partition] (paragraph [0018], “In one or more examples, the technical solutions described herein creates a surrogate partition to mirror an original partition on which the operating system is to be patched. The root volume group of the surrogate partition (surr-boot-rootvg) is a cloned image of the root volume group (orig-rootvg) of the original (emphasis added).”);
the new [partition] has resources corresponding to the original [partition] (paragraph [0018], “In one or more examples, the technical solutions described herein creates a surrogate partition to mirror an original partition on which the operating system is to be patched.”; paragraph [0020], “In the technical solutions described herein, when the transfer of the data from the Original to the surrogate partition is being done, the Original LPAR is removed. And the remaining resources are moved to the Surrogate Partition (emphasis added).”);
updating the software on a root volume group of the original [partition] (abstract, “An example method includes cloning an original root volume group associated with an operating system instance executing in a first logical partition to generate a cloned root volume group for booting a second logical partition. The method further includes applying the update to the cloned root volume group, and booting the second logical partition (emphasis added).”; paragraph [0018], “Any other utility may be used in other examples, where the utility clones the root volume group and updates the root volume group with a received patch to update the operating system.”);
exporting the root volume group of the original [partition] and assigning the exported root volume group as the root volume group of the new [partition] (Figure 3; paragraph [0059], “The update is applied to the cloned root volume group to generate an updated cloned volume group, as shown at 440. The updated cloned volume group is used to boot the new surrogate LPAR2 340, as shown at 450 (emphasis added).”; paragraph [0018], “In one or more examples, the technical solutions described herein creates a surrogate partition to mirror an original partition on which the operating system is to be patched. The root volume group of the surrogate partition (surr-boot-rootvg) is a cloned image of the root volume group (orig-rootvg) of the original (emphasis added).”);
activating the new [partition] (paragraph [0018], “In one or more examples, the technical solutions described herein creates a surrogate partition to mirror an original partition on which the operating system is to be patched. The root volume group of the surrogate partition (surr-boot-rootvg) is a cloned image of the root volume group (orig-rootvg) of the original (emphasis added).”; paragraph [0019], “Further, the technical solutions facilitate moving running workloads from the original partition to the surrogate partition. In one or more examples, while a workload is running, the orig-rootvg of the original partition is mirrored into the surr-mir-rootvg (emphasis added).”; paragraph [0069], “[...] the surrogate LPAR2 340 takes over as the primary, by taking over the IP of the original LPAR1 310 and starts receiving the data packets from the clients directly […].”); and
following non-disruptive migrating of a workload from the original [partition] to the new [partition], terminating the operating system live update (paragraph [0069], “[...] the surrogate LPAR2 340 takes over as the primary, by taking over the IP of the original LPAR1 310 and starts receiving the data packets from the clients directly [...] Both, the original LPAR1 310 and the surrogate LPAR2 340 are removed from the multicast group, and the LPAR1 310 is shut down, completing the migration and the update of the operating system (emphasis added).”; paragraph [0041], “When the update of the operating system is complete, the new LPAR stands in for the old LPAR, however the new LPAR has the update applied to the operating system via the update being performed on the cloned copy of the root volume group from the old LPAR, where the root volume group comprises the operating system image, shared libraries, OS commands, user definitions, device configuration database, and the like. Thus, a seamless live update of the operating system is made possible without having to restart workloads or otherwise significantly disrupt already executing applications and workloads (emphasis added).”; paragraph [0074], “The technical solutions described herein thus improve existing computer technology, specifically updating operating systems without having to restart the operating system or freezing services provided by applications executing on the operating system (emphasis added).”).
Barrat does not explicitly disclose:
verifying, by an orchestrator, that the contents of a profile definition of each VM includes a valid assigned priority;
VM.
However, Ganesan discloses:
verifying, by an orchestrator, that the contents of a profile definition of each VM includes a valid assigned priority (Figure 2; paragraph [0024], “In some examples, each device profile in the list of device profiles is assigned a priority (e.g., in the range of 1-N, with 1 being the highest priority). In such cases, the compliance of the device profiles may be checked according to the assigned priority (emphasis added).”; paragraph [0028], “Further, device profile manager 106 may perform a management operation to migrate or clone the virtual devices and associated configurations between the host computing systems to support the compliance of the device profiles assigned to VMs 1-4 in the order of the priority of the device profiles (emphasis added).”) [Examiner’s Remarks: Note that Ganesan discloses device profiles being assigned priorities and checking compliance based on the assigned priority. Ganesan also discloses that the device profiles are assigned to VMs. One of ordinary skill in the art would readily comprehend that in order to check the compliance of device profiles assigned to VMs based on the assigned priority, the device profile manager (orchestrator) must also verify that the device profile includes the assigned priority.];
VM (paragraph [0008], “FIG. 2 is an example system view of a virtualized computing environment illustrating assigning the device profiles to virtual machines (VMs) in the cluster.”).
Barrat is within the same field of endeavor as the claimed invention regarding performing operating system live updates. Ganesan is within the same field of endeavor as the claimed invention regarding the utilization of profiles with priorities that are associated with virtual machines.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ganesan into the teaching of Barrat to include “verifying, by an orchestrator, that the contents of a profile definition of each VM includes a valid assigned priority; VM.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize virtual machines for more efficient use of hardware resources through computer virtualization and assign profiles with priorities to VMs in order to help ensure the required backend virtual devices and configurations are available to the VM as well as support compliance based on priority (Ganesan, paragraphs [0004, 0019, & 0024]).
The combination of Barrat and Ganesan discloses “[…] to create a new VM corresponding to an original VM,” but does not explicitly disclose:
verifying, by the orchestrator, that sufficient free resources are available in the computer system to create a new VM corresponding to an original VM.
However, Formanek discloses:
verifying, by the orchestrator, that sufficient free resources are available in the computer system to create a new VM (page 14 lines 14-18, “When a virtual machine 104 is to be instantiated, the resource controller 112 may first determine a computing unit 102 in the cloud computing environment 100 that has sufficient free resources for instantiating the virtual machine 104 and may then instruct the hypervisor 106 of the corresponding computing unit 102 to instantiate the virtual machine 104 accordingly (emphasis added).”).
Formanek is within the same field of endeavor as the claimed invention regarding the creation of VMs.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Formanek into the combined teachings of Barrat and Ganesan to include “verifying, by the orchestrator, that sufficient free resources are available in the computer system to create a new VM corresponding to an original VM.” The modification would be obvious because one of ordinary skill in the art would be motivated to verify there are sufficient free resources available in order to ensure the new VM is properly created with the required amount of resources (Formanek, page 14).
The combination of Barrat, Ganesan, and Formanek discloses “the new VM has resources corresponding to the original VM,” but does not explicitly disclose:
based on there not being sufficient free resources, beginning with a donor VM having a lowest priority and continuing to the donor VM having a next higher priority, moving resources from the donor VM to the new VM until the new VM has resources corresponding to the original VM.
However, Chin discloses:
based on there not being sufficient free resources, beginning with a donor VM having a lowest priority and continuing to the donor VM having a next higher priority, moving resources from the donor VM to the new VM until the new VM has resources corresponding to the [requisite amount] (paragraph [0060], “The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM. As described above, resources may be dynamically allocated to a VM from available resources pool 120. In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority (emphasis added).”; paragraph [0123], “At 704, a list of VMs is determined having priority levels lower than the priority level determined in 702. At 706, the list of VMs [donor VMs] determined in 704 is ordered based upon the priority levels (emphasis added).”; paragraph [0125], “Per 710, 712, 714, 716, and 722, starting with the lowest priority VM in the list, the VMs in the ordered list are iterated to determine, for each VM, the amount of the resource that can be freed from the VM. This iteration continues until the requisite amount of the resource that is to be allocated can be freed and made available for allocation. Accordingly, at 710, starting with the lowest priority VM in the ordered list, the amount of the resource that can be freed from VM.sub.P is determined. While making this determination, the base limit of the resource for VM.sub.P may be considered to ensure that, after the freeing of the resource, the total amount of the resource still allocated to VM.sub.P does not fall below the base limit for that VM.sub.P (emphasis added).”).
Chin is within the same field of endeavor as the claimed invention regarding VMs donating resources.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “based on there not being sufficient free resources, beginning with a donor VM having a lowest priority and continuing to the donor VM having a next higher priority, moving resources from the donor VM to the new VM until the new VM has resources corresponding to the original VM.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that frees resources from VMs to allocate those resources to another VM in order to perform allocations and deallocations in real time without severely impacting any VM while enabling better utilization of limited resources between the VMs (Chin, paragraph [0119]).
As per Claim 3, the rejection of Claim 1 is incorporated; and the combination of Barrat, Ganesan, and Formanek does not explicitly disclose:
wherein the resources include CPU, memory, I/O, and storage.
However, Chin discloses:
wherein the resources include CPU, memory, I/O, and storage (paragraph [0048], “Portions of other resources, including I/O devices 106, networking resources, and other hardware resources 108, may also be allocated to the VMs when the VMs are created.”; paragraph [0055], “In Table A, the resources specified for each VM include CPU cores (i.e., processing resource), memory, network bandwidth, network ports, and non-volatile memory.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “wherein the resources include CPU, memory, I/O, and storage.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that frees resources (CPU, memory, I/O, and storage) from VMs to allocate those resources to another VM that needs them in order to perform allocations and deallocations in real time without severely impacting any VM while enabling better utilization of limited resources between the VMs (Chin, paragraph [0119]).
As per Claim 4, the rejection of Claim 1 is incorporated; and the combination of Barrat, Ganesan, and Formanek does not explicitly disclose:
wherein the resources are selected from a pool of free resources.
However, Chin discloses:
wherein the resources are selected from a pool of free resources (paragraph [0060], “As described above, resources may be dynamically allocated to a VM from available resources pool 120.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “wherein the resources are selected from a pool of free resources.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that frees resources from VMs into a resource pool and allocate those resources to another VM in order to perform allocations and deallocations in real time without severely impacting any VM while enabling better utilization of limited resources between the VMs (Chin, paragraph [0119]).
As per Claim 8, Barrat discloses:
A computer program product to perform operating system live update in a resource constrained computer system, wherein the computer program product comprises a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processing unit to cause the processing unit to perform a method (paragraph [0005], “According to one or more embodiments, an example computer program product includes a computer readable storage medium having program instructions embodied therewith, the program instructions are executable by a processing circuit to cause the processing circuit to perform a live update of an operating system in a data processing system.”) comprising: […].
Claim 8 is a computer program product claim corresponding to method Claim 1 and the remainder of Claim 8 is rejected for the same reasons as given in the rejection of Claim 1.
As per Claim 10, the rejection of Claim 8 is incorporated; and the combination of Barrat, Formanek, and Chin does not explicitly disclose:
wherein a profile definition of each virtual machine includes a priority.
However, Ganesan discloses:
wherein a profile definition of each virtual machine includes a priority (Figure 2; paragraph [0024], “In some examples, each device profile in the list of device profiles is assigned a priority (e.g., in the range of 1-N, with 1 being the highest priority). In such cases, the compliance of the device profiles may be checked according to the assigned priority (emphasis added).”; paragraph [0028], “Further, device profile manager 106 may perform a management operation to migrate or clone the virtual devices and associated configurations between the host computing systems to support the compliance of the device profiles assigned to VMs 1-4 in the order of the priority of the device profiles (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ganesan into the combined teachings of Barrat, Formanek, and Chin to include “wherein a profile definition of each virtual machine includes a priority.” The modification would be obvious because one of ordinary skill in the art would be motivated to assign profiles with priorities to VMs in order to help ensure the required backend virtual devices and configurations are available to the VM and support compliance based on priority (Ganesan, paragraphs [0019 & 0024]).
Claims 11-12 are computer program product claims corresponding to method Claims 3-4 respectively and are rejected for the same reasons as given in the rejections of those claims.
As per Claim 15, Barrat discloses:
A computer system to perform operating system live update in a resource constrained computer system, the computer-implemented method comprising: one or more processors; a memory coupled to at least one of the processors; a set of computer program instructions stored in the memory and executed by at least one of the processors to perform actions of (paragraph [0004], “According to one or more embodiments a system includes a memory, and a processor coupled with the memory, the processor performing a live update of an operating system in a data processing system.”; paragraph [0076], “The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device […] A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM) […].”): […].
Claim 15 is a system claim corresponding to method Claim 1 and the remainder of Claim 15 is rejected for the same reasons as given in the rejection of Claim 1.
Claim 17 is a system claim corresponding to computer program product Claim 10 and is rejected for the same reasons as given in the rejection of that claim.
Claims 18-19 are system claims corresponding to method Claims 3-4 respectively and are rejected for the same reasons as given in the rejections of those claims.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Barrat in view of Ganesan, Formanek, and Chin as applied to Claims 1, 8, and 15 above, and further in view of US 2018/0109605 (hereinafter “Stephens”).
As per Claim 2, the rejection of Claim 1 is incorporated; and Barrat discloses “deactivating and deleting the original [partition] (paragraph [0056], “After all applications and associated resources have been transferred over to the new LPAR2 340, the original LPAR 310 is deactivated and its resources are freed up for reuse (emphasis added).”; paragraph [0020], “In the technical solutions described herein, when the transfer of the data from the Original to the surrogate partition is being done, the Original LPAR is removed. And the remaining resources are moved to the Surrogate Partition (emphasis added).”),” but the combination of Barrat, Ganesan, and Formanek does not explicitly disclose:
deactivating and deleting the original VM;
returning to each donor VM the resources assigned to the new VM, according to a priority order; and
returning resources corresponding to the original VM to a pool of free resources.
However, Chin discloses:
each donor VM (paragraph [0123], “At 704, a list of VMs is determined having priority levels lower than the priority level determined in 702. At 706, the list of VMs [donor VMs] determined in 704 is ordered based upon the priority levels (emphasis added).”; paragraph [0060], “In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority (emphasis added).”);
resources assigned to the new VM (paragraph [0060], “The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM. As described above, resources may be dynamically allocated to a VM from available resources pool 120. In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority (emphasis added).”);
[…] according to a priority order (paragraph [0060], “The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM. As described above, resources may be dynamically allocated to a VM from available resources pool 120. In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority (emphasis added).”; paragraph [0123], “At 704, a list of VMs is determined having priority levels lower than the priority level determined in 702. At 706, the list of VMs determined in 704 is ordered based upon the priority levels (emphasis added).”);
returning resources corresponding to the [VM] to a pool of free resources (paragraph [0059], “The deallocated and unused resources are returned to the available resource pool 120.”; paragraph [0060], “The priority value for a VM may be used to allocate and deallocate one or more resources for a VM.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “deactivating and deleting the original VM; each donor VM; resources assigned to the new VM; […] according to a priority order; returning resources corresponding to the original VM to a pool of free resources.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that frees resources from VMs to allocate those resources to another VM and returns resources to a resource pool in order to perform allocations and deallocations in real time without severely impacting any VM while enabling better utilization of limited resources between the VMs (Chin, paragraph [0119]).
The combination of Barrat, Ganesan, Formanek, and Chin does not explicitly disclose:
returning to each donor VM the resources assigned to the new VM, according to a priority order.
However, Stephens discloses:
returning to [the cloud] the resources assigned to the [application], according to [historical data] (paragraph [0033], “Deallocating a resource includes returning the resource to the cloud environment. Returning a resource to the cloud inventory allows the resource to be obtained for use by other applications.”; paragraph [0036], “Accordingly, efficiency can be gained by making deallocation decisions based on historical allocation/deallocation data, including the giveback period.”; abstract, “As discussed herein, cloud services can be made more efficient by deallocating resources based on delays incurred between when resources are requested to be deallocated and reallocated and when they actually are deallocated and allocated, and for how long the resource would be returned to the cloud before needing to be reallocated.”).
Stephens is within the same field of endeavor as the claimed invention regarding resource allocation and returning resources.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Stephens into the combined teachings of Barrat, Ganesan, Formanek, and Chin to include “returning to each donor VM the resources assigned to the new VM, according to a priority order.” The modification would be obvious because one of ordinary skill in the art would be motivated to deallocate resources based on historical data including the giveback period in order to deallocate resources more efficiently and improve performance (Stephens, abstract & paragraph [0036]).
Claim 9 is a computer program product claim corresponding to method Claim 2 and is rejected for the same reasons as given in the rejection of that claim.
Claim 16 is a system claim corresponding to method Claim 2 and is rejected for the same reasons as given in the rejection of that claim.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Barrat in view of Ganesan, Formanek, and Chin as applied to Claims 1 and 8 above, and further in view of US 2014/0068613 (hereinafter “Iriguchi”).
As per Claim 5, the rejection of Claim 1 is incorporated; and the combination of Barrat, Ganesan, and Formanek does not explicitly disclose:
wherein the profile definition defines a maximum amount of resources that the donor VM can donate such that the donor VM remains operating.
However, Chin discloses:
amount of resources that the donor VM can donate such that the donor VM remains operating (paragraph [0125], “While making this determination, the base limit of the resource for VM.sub.P may be considered to ensure that, after the freeing of the resource, the total amount of the resource still allocated to VM.sub.P does not fall below the base limit for that VM.sub.P.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “amount of resources that the donor VM can donate such that the donor VM remains operating.” The modification would be obvious because one of ordinary skill in the art would be motivated to make sure donating resources doesn’t fall below the base limit for the VM in order to ensure the VM functions adequately and does not donate resources it needs (Chin, paragraph [0125]).
The combination of Barrat, Ganesan, Formanek, and Chin does not explicitly disclose:
wherein the profile definition defines a maximum amount of resources that the donor VM can donate such that the donor VM remains operating.
However, Iriguchi discloses:
wherein the profile definition defines a maximum amount of resources (Figure 5; paragraph [0078], “A virtual machine management table 111 is stored in the storage unit 110. The virtual machine management table 111 includes the following fields: Virtual Machine, Maximum Resource Assignment, Current Resource Assignment, and Priority.”).
Iriguchi is within the same field of endeavor as the claimed invention regarding virtual machines and tracking resource-related information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Iriguchi into the combined teachings of Barrat, Ganesan, Formanek, and Chin to include “wherein the profile definition defines a maximum amount of resources that the donor VM can donate such that the donor VM remains operating.” The modification would be obvious because one of ordinary skill in the art would be motivated to keep track of a max amount of resources in order to help prevent over-assigning resources (Iriguchi, paragraph [0078]).
Claim 13 is a computer program product claim corresponding to method Claim 5 and is rejected for the same reasons as given in the rejection of that claim.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Barrat in view of Ganesan, Formanek, and Chin as applied to Claims 1 and 8 above, and further in view of US 2020/0341746 (hereinafter “Mehra”).
As per Claim 6, the rejection of Claim 1 is incorporated; and Barrat discloses “the live update (abstract, “Technical solutions are described for performing a live update of an operating system.”),” but the combination of Barrat, Ganesan, Formanek, and Chin does not explicitly disclose:
wherein a backup of the operating system and any application software is completed prior to initiating the live update.
However, Mehra discloses:
wherein a backup of the operating system and any application software is completed prior to initiating the [update] (paragraph [0007], “For example, the sets may include a main operating system space, which may include the OS binaries, as well as data, applications, user data, and driver sets.”; paragraph [0008], “In an embodiment, a snapshot may be taken of all the sets. In one embodiment, the snapshots may be taken when system setup is started or at other opportunistic times for those sets that are read-only, since these sets will not be changed during the course of operation of the computing system. The operating system update may then begin.”).
Mehra is within the same field of endeavor as the claimed invention regarding saving backups of an OS.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Mehra into the combined teachings of Barrat, Ganesan, Formanek, and Chin to include “wherein a backup of the operating system and any application software is completed prior to initiating the live update.” The modification would be obvious because one of ordinary skill in the art would be motivated to save snapshots/backups of the operating system so that the operating system can be reverted in the event of a failure of the updated operating system (Mehra, paragraph [0009]).
Claim 14 is a computer program product claim corresponding to method Claim 6 and is rejected for the same reasons as given in the rejection of that claim.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Barrat in view of Ganesan, Formanek, and Chin as applied to Claims 1 and 15 above, and further in view of US 2018/0026885 (hereinafter “Jeuk”).
As per Claim 7, the rejection of Claim 1 is incorporated; and the combination of Barrat, Ganesan, and Formanek does not explicitly disclose:
wherein the priority is based on service level agreement, uptime, performance requirements, and workload.
However, Chin discloses:
the priority (paragraph [0060], “The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chin into the combined teachings of Barrat, Ganesan, and Formanek to include “the priority.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a system that frees resources from VMs to allocate those resources to another VM based on priority in order to perform allocations and deallocations in real time without severely impacting any VM while enabling better utilization of limited resources between the VMs (Chin, paragraphs [0060 & 0119]).
The combination of Barrat, Ganesan, Formanek, and Chin does not explicitly disclose:
wherein the priority is based on service level agreement, uptime, performance requirements, and workload.
However, Jeuk discloses:
wherein the [feedback] is based on service level agreement, uptime, performance requirements, and workload (paragraph [0025], “The feedback can include data on bandwidth and/or throughput, jitter, latency, QoS, performance, resource consumption, uptime or responsiveness, errors, cost, packet loss, packet duplication, availability, SLA related metrics, connectivity, error rate, response time, pricing requirements, changes or rates of change on one or more of these factors within the environment and/or specifically related to the workload, etc.”).
Jeuk is within the same field of endeavor as the claimed invention regarding the utilization of data based on service level agreement, uptime, performance requirements, and workload.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Jeuk into the combined teachings of Barrat, Ganesan, Formanek, and Chin to include “wherein the priority is based on service level agreement, uptime, performance requirements, and workload.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize data based on service level agreement, uptime, performance requirements, and workload in order to get a comprehensive view that leverages relevant factors in order to make an informed decision or take an appropriate action such as dynamic routing for increased efficiency (Jeuk, paragraphs [0007, 0010, & 0025]).
Claim 20 is a system claim corresponding to method Claim 7 and is rejected for the same reasons as given in the rejection of that claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Feven H. Huruy whose telephone number is (571) 272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3: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, Wei Mui can be reached at (571) 272-3708. 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.
/F.H.H./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights