DETAILED ACTION
Claims 1, 3, 5-7,165, 167, 169-173, and 175-182 are pending in this application.
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
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, 165, 172 and 179-182 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2016/0147553 A1 to Palavalli et al. (hereinafter referred to as Palavalli’553) in view of U.S. Pub. No. 2016/0180063 A1 to Blandaru et al.
As to claim 1, Palavalli’553 teaches a method comprising:
the license (Guest OS Licensing Module 116) to activate the first permit activation of one or more dormant hardware features (physical processor) of the first server (First Host Computing System) (“…Guest OS licensing module 116 may then determine whether a physical processor of a first host computing system exists that is licensed to execute the OS based on the computing resource requirements of the VM VM1, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 then determines whether there is a licensed physical core available in a first host computing system in the virtual datacenter that has a spare capacity to run the VM based on the computing resource requirements of the VM, the physical core/processor based license, and/or assigned affinity to physical cores in the first host computing system 106A to run a first type of guest OS…Guest OS optimization module 116 may then migrate/place the VM VM1 to/on the physical core of the first host computing system if a physical processor of a first host computing system exists that is licensed to execute the OS based on the computing resource requirements of the VM VM1, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiment, guest OS cost optimization module 116 places the VM VM1 on the available physical core of the first host computing system 106A if a licensed physical core is available in first host computing system 106A in the virtual datacenter that has spare capacity to run the VM. Guest OS cost optimization module 116 then powers on the VM VM1 on first host computing system 106A…” paragraphs 0015/0016);
transferring the license to a second server to cause the second server based on the first to activate one or more dormant hardware features of the second server based on the license (Block 210) (“…Guest OS optimization module 116 may then migrate/place VM VM1 to/on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 places the VM VM1 on a physical core of second host computing system 106B by assigning a physical core/processor based license if a licensed physical core is not available in first host computing system 106A in the virtual datacenter that has spare capacity to run the VM. Guest OS cost optimization module 116 then powers on the placed VM VM1 on the physical core of second host computing system 106B…Based on the outcome of determination at block 206, process 200 goes to block 210 and migrates/places the VM on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system…” paragraphs 0017/0025); and
migrating a virtual machine (VM) from the first server to the second server (Block 210) (“…Guest OS optimization module 116 may then migrate/place VM VM1 to/on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 places the VM VM1 on a physical core of second host computing system 106B by assigning a physical core/processor based license if a licensed physical core is not available in first host computing system 106A in the virtual datacenter that has spare capacity to run the VM. Guest OS cost optimization module 116 then powers on the placed VM VM1 on the physical core of second host computing system 106B…Based on the outcome of determination at block 206, process 200 goes to block 210 and migrates/places the VM on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system…” paragraphs 0017/0025); and
executing the VM based on the activated one of the first or more hardware features of the second server (“…Guest OS optimization module 116 may then migrate/place VM VM1 to/on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 places the VM VM1 on a physical core of second host computing system 106B by assigning a physical core/processor based license if a licensed physical core is not available in first host computing system 106A in the virtual datacenter that has spare capacity to run the VM. Guest OS cost optimization module 116 then powers on the placed VM VM1 on the physical core of second host computing system 106B…” paragraph 0017).
Palavalli”553 does not explicitly teach obtaining a license associated with a first server.
Blandaru teaches obtaining a license associated with a first server (Operations 500/502) (“…In operation 500, the license agent requests, via an associated SEC, a license from the license server. This involves sending the metadata of the client host, such as the MAC-address, host-name, IP-address and time of the client to the license server using a secure clock. This information is transmitted securely through the SEC, as discussed above. In operation 502, the license server creates the license using the metadata of the client and sends the license to the license agent. The license includes the expiration time based on the client time and a lease period, as well as an expiration time based on the server time and the lease period. The license also includes the host-name, MAC-address, and IP-address of the client, as well as the server-time-stamp. The license is saved in the license database, then signed with an attached certificate and issued to the license agent. When the license agent receives the license in operation 502, it validates the license signature and caches the license in the SEC associated with the license agent. As long as the client expire time is less than the actual client time, the license is valid and may be used by the client…” paragraph 0023).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Palavalli’553 with the teaching of Blandaru because the teaching of Blandaru would improve the system of Palavalli’553 by providing a a license management system in a cloud environment for verifying licenses (Blandaru paragraphs 0012/0013).
As to claims 165 and 172, see the rejection of claim 1 above, expect for interface circuitry, machine readable instructions, and at least one non-transitory machine-readable storage medium.
Palavalli”553 teaches interface circuitry, machine readable instructions, and at least one non-transitory machine-readable storage medium (“…Furthermore, in some embodiments, some or all of the components of VMS 112, guest OS cost optimization module 116, and DRS may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to one or more application-specific integrated circuits (“ASICs”), standard integrated circuits, controllers executing appropriate instructions, and including microcontrollers and/or embedded controllers, field-programmable gate arrays (“FPGAs”), complex programmable logic devices (“CPLDs”), and the like. Some or all of the system components and/or data structures may also be stored as contents (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., as a hard disk; a memory; a computer network or cellular wireless network or other data transmission medium; or a portable media article to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) so as to enable or configure the computer-readable medium and/or one or more associated computing systems or devices to execute or otherwise use or provide the contents to perform at least some of the described techniques…” paragraph 0029).
As to claim 178, Palavalli”553 teaches the method of claim 1, wherein the one or more dormant hardware features of the first server include at least one of (i) one or more dormant processor cores (physical processor), or (ii) one or more dormant hardware accelerators (“…Guest OS licensing module 116 may then determine whether a physical processor of a first host computing system exists that is licensed to execute the OS based on the computing resource requirements of the VM VM1, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 then determines whether there is a licensed physical core available in a first host computing system in the virtual datacenter that has a spare capacity to run the VM based on the computing resource requirements of the VM, the physical core/processor based license, and/or assigned affinity to physical cores in the first host computing system 106A to run a first type of guest OS…” paragraph 0015).
As to claims 179 and 181, see the rejection of claim 178 above.
As to claim 180, Palavalli”553 teaches the apparatus of claim 165, wherein the one or more dormant hardware features of the second server are unusable until activated based on the license (then powers on the placed VM VM1 on the physical core) (“…Further in sonic embodiments, VMS 112 may then create the VM VM1 based on compute, network and/or storage demand requirements upon receiving the request to migrate/place the first VM VM1 running on a first type of guest OS. In some embodiments, guest OS cost optimization module 116 installs/builds the first type of guest OS on the VM VM1 associated with first host computing system 106A in virtual datacenter 100. Guest OS cost optimization module 116 then keeps VM VM1 having the first type of guest OS in a powered off mode to avoid violation of licensing terms…Guest OS optimization module 116 may then migrate/place VM VM1 to/on a physical core of a second host computing system by assigning a physical processor based license if a physical processor of a first host computing system does not exist that is licensed to execute the OS based on the computing resource requirements of the VM, the physical processor based license, and/or assigned affinity to physical processors of the first host computing system. In some embodiments, guest OS cost optimization module 116 places the VM VM1 on a physical core of second host computing system 106B by assigning a physical core/processor based license if a licensed physical core is not available in first host computing system 106A in the virtual datacenter that has spare capacity to run the VM. Guest OS cost optimization module 116 then powers on the placed VM VM1 on the physical core of second host computing system 106B…” paragraphs 0014/0017).
As to claim 182, see the rejection of claim 180 above.
Claims 3, 167 and 173 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2016/0147553 A1 to Palavalli et al. (hereinafter referred to as Palavalli’553) in view of U.S. Pub. No. 2016/0180063 A1 to Blandaru et al. as applied to claims 1, 165 and 172 above, and further in view of U.S. Pub. No. 2017/0255890 A1 to Palavalli et al. (hereinafter referred to as Palavalli’890).
As to claim 3, Palavalli’553 as modified by Blandaru teaches the method of claim 1, however it is silent with reference to
generating a recommendation to improve execution of a workload, the recommendation including a change of a set of active the first features of the first server; and
determining to migrate the VM based on the recommendation.
Palavalli’890 teaches generating a recommendation to improve execution of a workload, the recommendation including a change of a set of active the first features of the first server (Guest OS Cost Optimization Module 1204); and
determining to migrate the VM based on the recommendation (Steps 1601-1612) (“…The guest OS cost optimization module 1204 includes methods to calculate configuration recommendations that optimize the cost to data center customers while deploying new services. The input is a plan for new application services, which includes types of VMs, the type of licensed software, the types of guest OSs. Method generate a plan to optimize server computer utilization based on licensing, including recommendations to buy new computer hardware…The guest OS cost optimization module 1204 provides VM placement recommendations to data center customers while a customer attempts to manually performing VM migration. FIG. 16 shows a control-flow diagram of a method to generate VM placement recommendations. In block 1601, a VM is selected by a data center customer for migration to a target server computer. In block 1602, the target server computer is identified. In block 1603, the guest OS of the VM is identified. In block 1604, the target server computer OS license is identified. In decision block 1605, if the target server computer is licensed for the guest OS of the VM, control flows to block 1610. Otherwise, control flows to block 1606. In block 1606, a search is conducted to identify server computer with an OS that is licensed for the guest OS of the VM selected for migration and has additional computational and storage capacity to support the VM. In decision block 1607, if a target server computer has been identified, control flows to decision block 1608. Otherwise, control Lows to block 1609. In decision block 1608, the customer is asked if the customer approves of an alternative target server computer. If the customer approves, control flows to block 1610. If the customer does not approve, control flows to block 1609. In block 1609, an alert is generated indicating that the migration cannot be completed because the target server computer does not have a license that is compatible with the guest OS of the VM. In block 1610, migration of the VM to the target server computer is completed. In decision block 1611, if the customer decides to purchase a license for the target server computer, control flows to block 1610. If the customer decides not to purchase the license, control flows to decision block 1612. In decision block 1612, if the data center customer has selected another VM for migration, control returns to block 1601…” paragraph 0065/0066).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Palavalli’553 and Blandaru with the teaching of Palavalli’890 because the teaching of Palavalli’890 would improve the system of Palavalli’553, Palavalli’553 and Blandaru by providing a guest OS cost optimization module that includes methods to calculate configuration recommendations that optimize the cost to data center customers while deploying new services (Palavalli’890 paragraph 0065).
As to claims 167 and 173, see the rejection of claim 3 above.
Claims 5, 169 and 175 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2016/0147553 A1 to Palavalli et al. (hereinafter referred to as Palavalli’553) in view of U.S. Pub. No. 2016/0180063 A1 to Blandaru et al. as applied to claims 1, 165 and 172 above, and further in view of U.S. Pub. No. 2006/0005189 A1 to Vega et al.
As to claim 5, Palavalli’553 as modified by Blandaru teaches the method of claim 1, however it is silent with reference to obtaining a VM state associated with execution of the VM on the first server from a secure storage, the VM state including at least one of a hardware counter, a software counter, or a progress of execution of a workload; and
deploying the VM state to the second server to resume execution of the workload on the server.
Vega teaches obtaining the VM state from the storage (disk), the VM state including at least one of a hardware counter, a software counter, or a progress of execution of the workload (the device state and memory state of VM A); and
deploying the VM state to the second server to resume execution of the workload on the server (a copy runs in a new location. One way to implement migration involves saving the device state and the entire memory state of the virtual machine to a file on disk, then copying the file to the new host and restoring the machine state) (“…In the event that a need arises to migrate VM A from host OS 104 to host OS 104', such as for load balancing, software upgrades, hardware maintenance, or for reasons of disaster recovery, the device state and memory state of VM A are transferred to host OS 104', according to Microsoft patent application 20040010787,entitled, "Method for forking or migrating a virtual machine," via a standard network connection between computer hardware 102 and computer hardware 102'. The '787 patent application, incorporated herein by reference, describes that, when a virtual machine is migrated, the original virtual machine is permanently suspended, and a copy runs in a new location. One way to implement migration involves saving the device state and the entire memory state of the virtual machine to a file on disk, then copying the file to the new host and restoring the machine state…At step 134, the migration process is initiated (either manually or automatically for initiation as well as for any or all steps herein indicated) by pausing the VM A 108 on host OS 104 and transferring its device and memory states to host OS 104', according to the '787 patent application. At this point in time, VM A 108 and VM A' 108' both exist briefly in a paused state, for a period of time long enough to transfer critical device state and critical memory state information from VM A 108 to VM A' 108'. For example, the state of the processor registers, the state of the virtual hardware, and a small amount of working memory are migrated from VM A 108 to VM A' 108'. The memory is transferred incrementally by use of a "demand paging" process, wherein the memory of VM A 108 is prioritized, based on what VM A' 108' actively requires, as is described in the '787 patent application…” paragraphs 0038/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Palavalli’553 and Blandaru with the teaching of Vega because the teaching of Vega would improve the system of Palavalli’553 and Blandaru by providing a technique for resuming workload/task execution after a migration.
As to claims 169 and 175, see the rejection of claim 5 above.
Claims 6, 7, 170, 171, 176 and 177 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2016/0147553 A1 to Palavalli et al. (hereinafter referred to as Palavalli’553) in view of U.S. Pub. No. 2016/0180063 A1 to Blandaru et al. as applied to claims 1, 165 and 172 above, and further in view of U.S. Pub. No. 2022/0283836 A1 to Goud et al.
As to claim 6, Palavalli’553 as modified by Blandaru teaches the method of claim 1, however it is silent with reference to wherein the first server provides a first set of one or more active features prior to the migrating of the VM and including:
reconfiguring the first server to provide a second set of one or more active features;
storing data associated with the second server in a secure storage, the data including a VM state associated with execution of the VM on the second server; and
migrating the VM from the second server to the first server after the reconfiguring of the first server.
Goud teaches wherein the first server provides a first set of one or more active features prior to the migrating of the VM and including:
Reconfiguring (Once the offline host 102 is powered back on) the first server to provide a second set of one or more active features the first server based on a change of the first features (“…More specifically, HA module(s) 114 will restart the VMs 105 that were allocated for that particular host 102 into other, healthy hosts 102, and when DRS 142 is configured on top of HA, DRS 142 makes sure that the protected VMs 105 get properly balanced to the remaining hosts 102. Once the offline host 102 is powered back on, DRS 142 recommends migration of one or more VMs 105 to the host 102, keeping the cluster balanced. Without DRS 142, an administrator would manually balance out the VMs 105 around the cluster…” paragraph 0044);
storing (register) data associated with the second server in a secure storage, the data including a VM state associated with execution of the VM on the second server (“…As shown in FIG. 4, at 410, the VM 105 is registered for a restart or placement on a host 102. For example, a master HA 114 registers the VM 105 for restart/placement on the current host 102, on another host 102 within the host cluster 101, or on another host 102 within another host cluster…” paragraph 0054); and
migrating (DRS 142) the VM from the second server to the first server after the reconfiguring of the first server (“…More specifically, HA module(s) 114 will restart the VMs 105 that were allocated for that particular host 102 into other, healthy hosts 102, and when DRS 142 is configured on top of HA, DRS 142 makes sure that the protected VMs 105 get properly balanced to the remaining hosts 102. Once the offline host 102 is powered back on, DRS 142 recommends migration of one or more VMs 105 to the host 102, keeping the cluster balanced. Without DRS 142, an administrator would manually balance out the VMs 105 around the cluster…” paragraph 0044).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Palavalli’553 and Blandaru with the teaching of Goud because the teaching of Goud would improve the system of Palavalli’553 and Blandaru by providing a technique for resuming workload/task execution after an offline host becomes active or comes back online.
As to claim 7, Palavalli’553 as modified by Goud teaches the method of claim 6, however it is silent with reference to (BUT, Blandaru teaches) obtaining the VM state from the storage, the VM state including at least one of a hardware counter, a software counter, or a progress of execution of a workload (“…In an alternative embodiment, a license authorization during a migration of VMs/VNFs can be transparently handled by the network of SECs when a VM is migrated. In such a case, the license activation is triggered by the cloud OS at the same time that the cloud OS is enacting the VM/VNF migration. A license server aware cloud may transmit a secure message to the license server indicating a VM migration event. The cloud OS would be aware if a special VM launch is used, as in the case of service-VMs (e.g., fire-walls, load-balancers, etc.). Since the SEC has different and unique keys that are never exposed outside the SEC, the license server will assume no unauthorized use of those credentials. Hence, each SEC associated with each VM/VNF has a unique communication connection with the SEC license server, and the license attestation is protected by non-repudiation…” paragraph 0021);
deploying second license to first server to cause the first server to provide the second set of one or more active features (Operation 504); and
deploying the VM state to the first server to resume execution of the workload (Operation 504) (“…In operation 500, the license agent requests, via an associated SEC, a license from the license server. This involves sending the metadata of the client host, such as the MAC-address, host-name, IP-address and time of the client to the license server using a secure clock. This information is transmitted securely through the SEC, as discussed above. In operation 502, the license server creates the license using the metadata of the client and sends the license to the license agent. The license includes the expiration time based on the client time and a lease period, as well as an expiration time based on the server time and the lease period. The license also includes the host-name, MAC-address, and IP-address of the client, as well as the server-time-stamp. The license is saved in the license database, then signed with an attached certificate and issued to the license agent. When the license agent receives the license in operation 502, it validates the license signature and caches the license in the SEC associated with the license agent. As long as the client expire time is less than the actual client time, the license is valid and may be used by the client…In operation 504, a license renew request is sent from the license agent to the license server, as discussed above. If the license metadata matches the license data stored in the license database, and the license has not yet expired, then the license is renewed. If the license has expired, then a return expired message is sent to the license agent, the license is harvested, and the licensed-ID is disabled. If the license metadata and/or signature do not match that stored in the license database, then it is possible a clone or migration of a VM is attempting to use the license. During a clean VM migration, as discussed above, the license server is informed and the license is harvested and re-issued on a request from a new client host. Either the license-refresh or an error code is sent to the license agent in operation 506. All requests, responses, and errors are logged by the license server and may be saved in the license database…” paragraphs 0023/0026).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Palavalli’553 and Goud with the teaching of Blandaru because the teaching of Blandaru would improve the system of Palavalli’553 and Goud by providing a technique for resuming workload/task execution after a migration based on a deployment for a virtual machine and its license.
As to claims 170 and 175, see the rejection of claim 6 above.
As to claims 171 and 177, see the rejection of claim 7 above.
Response to Arguments
Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection relies on different combination of references not applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights