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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 10/21/2023 and 2/28/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-8, 10-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Halperin (US 20140189816 A1) in view of Voccio (US 9015709 B2).
Regarding claim 1, Yang teaches:
A computerized method of securely persisting transient data between virtual machine restarts, the method comprising: (Claim 2. A method comprising: )
terminating, by a first virtual machine (VM) during a shutdown process for the first VM, execution of user-space processes on the first VM; ([0032] When a user decides to log off of their session with their desktop, any remaining differences between delta disk 144 and delta disk 134 are resolved by transferring final changes. After completion of communication between client system 120 and server system 110, changes represented in delta disk 144 may be written to virtual disk 142. In one embodiment, this would occur after operation of VM 118 is terminated to ensure a steady state of VM 118 while updating virtual disk 142. Termination of operation of VM 118 may include powering down VM 118, or suspending operation of VM 118. Powering down a VM typically involves executing a power-down procedure of the guest operating system running in the VM. In this procedure, processes are ended and any transient or cached data currently residing in memory is written to disk. Little or no state information is present when a VM is powered down, whereas a suspend operation involves stopping execution and preserving the state of the virtual machine by writing to VM state file 146.)
writing, by a first agent executing on the first VM and after user-space processes are terminated on the first VM, protected data from transient memory of the first VM to a virtual disk accessible by the first VM; shutting down the first VM;. ([0019] In one embodiment, virtualization software 127 comprises hosted virtualization software, which runs in conjunction with the client's host operating system as previously described. Virtual disk 132 can be initially copied from virtual disk 142 (or vice versa) such that, in one particular state, virtual disks 132 and 142 are identical or logically equivalent but not identical. By logically equivalent, it is meant that each virtual disk contains the same file system and data files, which are logically related in identical file system structures, although the actual disk sectors may not be ordered the same. Two identical disks are also logically equivalent.[0032])
delete the protected data from the virtual disk. ([0033] Once delta disk 144 is merged with virtual disk 142, delta disk 144 may be erased, marked for deletion, or otherwise identified as no longer being valid. Making virtual disk 132 consistent with virtual disk 142 and any changes made to either virtual disk is referred to as synchronization. The user's virtual machines may be synchronized in this way after local execution of VM 128 has terminated in the same manner as described above with reference to terminating operation of virtual machine 118 described above.)
Halperin does not appear to explicitly teach: initiating a startup process of a second VM, the second VM mounting the virtual disk; and executing, at the second VM and prior to execution of user-space processes, a second agent, the second agent being configured to: read the protected data from the virtual disk into transient memory of the second VM; and
However, Voccio teaches: Referring now to col 7, line 29-34. When a subsequent virtual machine 622 with virtual machine disk 626 is to be configured with the same setup as virtual machine 602, the configuration information corresponding to the configuration disk 604, now available as stored configuration disk 614, is downloaded from the online storage 610 and added to the new instance. Col 18, line 7-25. Referring now to FIG. 8, shown therein is a flowchart 800 illustrating aspects of the exemplary methods discussed above with respect to FIGS. 5-7. As shown, the flowchart 800 begins at step 802 where the system uploads a configuration disk to cloud storage and registers the configuration disk with a service provider. When a new instance of a virtualization product having the configuration defined by the configuration disk is desired, the system downloads, at step 804, the configuration disk from the cloud storage and adds it to the new instance. At step 806, the system adds the configuration disk to the hypervisor associated with the new instance. At step 808, an script processor 220 associated with the hypervisor reads the configuration disk and modifies the virtualization product of the hypervisor in accordance with the configuration parameters of the configuration disk. Subsequently, the new instance of the virtualization product will run on the hypervisor with the configuration parameters defined by the configuration disk.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Halperin and Voccio before them, to modify Halperin with Voccio’s method of mounting a configuration disk on a new virtual machine instance and reading that disk before the VM runs. Halperin teaches transient VM data to disk during shutdown, while Voccio teaches how such disk information can be attached o and read by a successor VM during startup. Combining these would have predictably improve VM restart and migration by allowing preserved information from the first VM to be automatically applied to the second VM.
Regarding claim 3, Voccio teaches:
The computerized method of claim 1, further comprising: receiving, by the first agent, a storage request message from a user-space application executing on the first VM, the storage request message representing a request for the first agent to store the protected data, the storage request message including the protected data; allocating a segment of the transient memory by the first agent on the first VM; and storing the protected data in the segment of the transient memory. (col 9, line 62 – col 10, line 14. At step 320, the network interface card associated with the information processing system 210 hosting the VM receives the message. At step 330, the message is evaluated for whether it is a wakeup-only message, an indicator message, or a content message. If the message is a wakeup-only message, processing moves to step 360. Otherwise, processing moves to step 340. At step 340, a first script processor 220 examines the message. If the message is a content message, then it is put into a buffer 222 and processing moves to step 360. Otherwise, processing moves to step 350. At step 350, the received indicator message is evaluated, any indicated values are retrieved and processed before moving on to step 360. It may occur that one or more values are placed into a buffer 222 for the VM. At step 360, the hypervisor activates the logical container 132 associated with the VM. At step 370, the hypervisor, acting in concert with the activated logical container 132, activates the associated operating environment 134. At step 380, any buffer contents are evaluated, and processed or forwarded on to the operating environment 134. At step 390, the process ends.)
Regarding claim 4, Voccio teaches:
The computerized method of claim 3, further comprising: receiving, by the second VM, a recovery request message from the user-space application executing on the second VM, the recovery request message representing a request for the second agent to provide the protected data to the user-space application; and transmitting the protected data from the second agent to the user-space application in response to the recovery request message. ( col 9, line 52- col 10, line 14)In this embodiment, a suspended VM may be powered on automatically when there is a request destined for that VM. Because the VM already has been provisioned, the identifying information for the VM (the MAC address, IP address, and/or any other unique identifiers) are already known. At step 310, a message is formatted addressing the VM. In a first embodiment, this is a magic packet, or a subnet-directed broadcast. In another embodiment, another message format is used, such as one of the formats described above. At step 320, the network interface card associated with the information processing system 210 hosting the VM receives the message. At step 330, the message is evaluated for whether it is a wakeup-only message, an indicator message, or a content message. If the message is a wakeup-only message, processing moves to step 360. Otherwise, processing moves to step 340. At step 340, a first script processor 220 examines the message. If the message is a content message, then it is put into a buffer 222 and processing moves to step 360. Otherwise, processing moves to step 350. At step 350, the received indicator message is evaluated, any indicated values are retrieved and processed before moving on to step 360. It may occur that one or more values are placed into a buffer 222 for the VM. At step 360, the hypervisor activates the logical container 132 associated with the VM. At step 370, the hypervisor, acting in concert with the activated logical container 132, activates the associated operating environment 134. At step 380, any buffer contents are evaluated, and processed or forwarded on to the operating environment 134. At step 390, the process ends.)
Same motivation as claim 1
Regarding claim 5, Voccio teaches:
The computerized method of claim 1, wherein the first VM is shut down on a first compute node, wherein the second VM is started on a second compute node different than the first compute node, wherein the shutdown process on the first VM and the startup process on the second VM are part of a virtual machine migration of a particular virtual machine between the first and second compute nodes. (col 15, line 5-44. At step 460, the hypervisor on Host Machine A suspends the VM. In one embodiment, the VM is suspended by placing the VM in ACPI power state S4 or S5. At step 470, an incremental snapshot is transferred from Host Machine A to Host Machine B, updating the state of Host Machine B so that it matches the state of Host Machine A. At step 480, the hypervisor on Host Machine B activates the VM. In one embodiment, the activation is performed by placing the VM in power state G0. At step 490, the cluster is updated to reflect the new location of the VM. In one embodiment, updating information within or associated with one of the cluster controller 218, the network routing element 216, the cluster monitor 214, a hypervisor 130 or in a non-sleeping operating environment 134. At step 499, the migration is complete and the process ends. FIG. 4b shows a second embodiment wherein a VM is migrated from Host Machine A to Host Machine B. Where steps have the same number as in FIG. 4a, they are the same; primary differences are highlighted below. The VM (logical container 132 and operating environment 134) are of any type previously described. In one embodiment, steps 410-450 are performed as described above. At step 460, the hypervisor on Host Machine A suspends the VM. In one embodiment, the VM is suspended by using the hypervisor to stop all processing within the VM; the disk and memory contents are briefly frozen in a consistent state without the VM being aware. At step 470, an incremental snapshot is transferred from Host Machine A to Host Machine B, updating the state of Host Machine B so that it matches the state of Host Machine A. At step 475, the memory state of the VM on Host Machine A is transferred to Host Machine B. At step 480, the hypervisor on Host Machine B activates the VM. In one embodiment, the activation is performed by resuming processing of the VM on Host Machine B from the previously-frozen consistent state. At step 490, the cluster is updated to reflect the new location of the VM. In one embodiment, updating information within or associated with one of the cluster controller 218, the network routing element 216, the cluster monitor 214, a hypervisor 130 or in a non-sleeping operating environment 134. At step 499, the migration is complete and the process ends.)
Same motivation as claim 1
Regarding claim 6, Voccio teaches:
The computerized method of claim 1, wherein the shutdown process on the first VM and the startup process on the second VM are part of a reboot process of a particular virtual machine on a single compute node. (col 5, line 10-25. A VM in state S5 is written out to disk and requires rebooting of the operating system. The systems and methods described below allow a VM to be moved in S3, S4, or S5 state while being on-line for most of the transfer. In the suspended state, the virtual machine and its memory state are moved to another machine and on resuming of the virtual machine, the virtual machine appears to have never been powered off to the user except for a brief period of network loss. Because of the nature of the virtual machine environment, it is possible to snapshot a running VM, including memory state, without the cooperation of the underlying operating system. Further, the transferred VM will still appear to have the identical hardware, MAC address, IP address, and other underlying information as at the previous host, allowing the experience from a VM perspective as well as a user perspective to only be one of a brief loss of network connectivity.)
Regarding claim 7, Yang teaches:
The computerized method of claim 1, wherein the writing of the protected data on the first VM is performed after the user-space processes are terminated, wherein the reading of the protected data on the second VM is performed before the user-space processes are started. ([0032] When a user decides to log off of their session with their desktop, any remaining differences between delta disk 144 and delta disk 134 are resolved by transferring final changes. After completion of communication between client system 120 and server system 110, changes represented in delta disk 144 may be written to virtual disk 142. In one embodiment, this would occur after operation of VM 118 is terminated to ensure a steady state of VM 118 while updating virtual disk 142. Termination of operation of VM 118 may include powering down VM 118, or suspending operation of VM 118. Powering down a VM typically involves executing a power-down procedure of the guest operating system running in the VM. In this procedure, processes are ended and any transient or cached data currently residing in memory is written to disk. Little or no state information is present when a VM is powered down, whereas a suspend operation involves stopping execution and preserving the state of the virtual machine by writing to VM state file 146.)
Regarding claim 8, Yang teaches:
A computer system comprising at least one compute node, each compute node of the at least one compute node comprising. (Claim 16. A server system comprising: a processor; and a non-transitory computer readable medium having stored thereon instructions that, when executed by the processor, cause the processor to: )
The claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 11, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 15,
A non-transitory computer storage medium having stored thereon program code executable by a processor, the program code embodying a program code method comprising. (Claim 9. A non-transitory computer readable medium having stored thereon computer software executable by a processor of a server system, the computer software embodying a method comprising: )
The claim recites similar limitation as corresponding claim x and is rejected for similar reasons as claim x using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Halperin (US 20140189816 A1) in view of Voccio (US 9015709 B2) and further view of Thomas (US 20090241192 A1).
Regarding claim 2, Yang or Voccio do not appear to explicitly teach:
The computerized method of claim 1, wherein the first agent and the second agent implement malware services on the first VM and the second VM respectively, wherein the protected data includes configuration information associated with the malware services, wherein the second agent uses the configuration information to configure at least one aspect of the malware services.
However, Thomas teaches: [0095] In embodiments, the sharing information may be associated with malware security and control. The malware security and control may not be included in the virtual computing machine 204A or the virtual computing machine 204B. In embodiments, the malware security and control scanning time may be reduced by offsetting the scan related to the virtual computing machine 204A or the virtual computing machine 204B. In embodiments, security and control scan results may be shared between the virtual computing machine 204A and the virtual computing machine 204B. [0096] In embodiments, the virtual computing machine 204A may not replicate scanning, if it has been executed on the virtual computing machine 204B. For example, if the host computer security facility 152A has performed scanning of files, then the scanning information may be shared with guest computer security facility 152B. In this case, the guest computer security facility 152B may not rescan files and may utilize the shared information received from the host computer security facility 152A. See also [0110-0111]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Halperin and Thomas before them, to include Thomas’s method of scanning VM information. Doing so would allow the restarted or migrated VM to reuse the configuration or security information thereby reducing reconfiguration time and improving reliability.
Regarding claim 9, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
ConclusionAny inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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 JR 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights