DETAILED ACTION
This Office Action is in response to claims filed on 04/30/2026.
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 .
Response to Arguments
Applicant’s arguments, see page 8 of applicant's remarks, filed 04/30/2026, with respect to the rejection of claims 1, 8, and 15 under 35 U.S.C. have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Tsirkin Pub. No. US 2020/0341792 A1 and Yin et al. Pub. No. US 2012/0346976 A1.
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, 5-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Robinson et al. Pub. No. US 2013/0346976 A1 (hereinafter Robinson) in view of Tsirkin Pub. No. US 2020/0341792 (hereinafter Tsirkin '792) in view of Yin et al. Pub. No. US 2012/0066484 A1 (hereinafter Yin) in view of Brooker et al. "Restoring Uniqueness in MicroVM Snapshots" (hereinafter Brooker).
With regard to claim 1, Brooker teaches a method comprising ([0006], Techniques and systems are disclosed herein for creating thin clones (e.g., clones that do not have copies of all files associated with a base VM) of a virtual machine (VM) to copy and deduplicate storage for the VMs):
executing, by a hypervisor running on a host computer system ([0002], In a computing environment, virtual machines may be used to concurrently run multiple operating systems on a single physical computing system … Physical servers can be converted into virtual servers running a hypervisor, which allows one or more virtual machines to run on a single physical server. A cluster of virtual servers may be linked to a storage volume that can be used to back up data from the plurality of virtual servers … Virtual machines operate in a hypervisor environment, whereby a hypervisor interacts with physical devices, such as processors, input/output devices, memory and storage and the hypervisor emulates a capability of these devices to the virtual machines), a virtual machine (VM) ([0022], The exemplary method 200 begins at 202 and involves creating a base VM in a directory of a storage container (e.g. ,a data store) attached to a hypervisor, at 204. For example, a VM hosting server may be operating a hypervisor, and may also be acting as a storage server in a storage system. In this example, a base VM can be created in the VM hosting server that may be a “gold standard” VM for an enterprise, and the VM can be listed in the directory of the server) …;
creating, by the hypervisor, a snapshot of the VM ([0024], At 208, VM files can be copied into one or more desired locations in the storage container, using a snapshot of the files. For example, a snapshot can be locally retained, read-only, point-in-time image of data);
executing, by the hypervisor, one or more duplicate VMs from the snapshot of the VM ([0031], at 216, in the exemplary embodiment 200, one or more of the cloned VMs can be registered within a hypervisor environment. VM registration … can allow the hypervisor to recognize a cloned VM as a valid entity within the hypervisor environment, for example (Examiner notes: Such that the cloned VMs begin executing in this environment); and
Robinson explicitly teaches that one or more cloned VMs can be customized by issuing commands to cloned virtual machines through embodiments not limited by the disclosure and known by those skilled in the art (Robinson, [0028] and [0030]). Robinson does not explicitly teach multicasting an interrupt to a plurality of vCPUs associated with instructions to execute an operation.
Tsirkin ’792 teaches multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUs) of one or more duplicate VMs ([0041], the hypervisor may multicast the IPI to a subset of the plurality of the virtual processors … multicasting the IPI may cause the IPI to be sent to a subset of the virtual processors in an environment), the interrupt associated with instructions to execute an operation ([0042], At block 340, the hypervisor may check whether at least one vCPU of the plurality of vCPUs is in an active state. A vCPU may be in the active state if the vCPU is performing a task or executing an IPI, as described in more detail herein above.)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin ‘792 with the teachings of Robinson in order to provide a method that teaches multicasting an interrupt associated with instructions to execute an operation to vCPUs of duplicated VMs. The motivation for applying Tsirkin ‘792 teaching with Robinson teaching is to provide a method that allows for reducing inter-processor interrupt overhead (Tsirkin ‘792, [0020]). Robinson and Tsirkin ‘792 are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin ‘792 with Robinson to teach the claimed invention in order to provide simulataneous, distributed request handling.
However, Robinson and Tsirkin ‘792 do not explicitly teach executing the operation simultaneously.
Yin teaches executing, by the plurality of vCPUs ([0009], An embodiment of the present invention provides a patching method in a multi-core environment, where the method includes: sending an inter-core non-maskable interrupt to each target VCPU in a target VCPU group which share a code segment, so that said each target VCPU enters a patch synchronization state, in response to the inter-core non-maskable interrupt), the operation with respect to the initial cryptographic secret simultaneously ([0041], It can be seen that, in the patching device of the target VCPU according to the embodiment of the present invention, the synchronization of VCPUs which share a code segment is realized in the mode of synchronization of inter-core non-maskable interrupts, and after all the target VCPUs which share the original function have entered the patch synchronization state, the first instruction of the original functions to be patched of all the target VCPUs are modified into abnormal instructions, so that the patching device of the target VCPUs enables the original function to be patched to jump to the new patch function in the exception handling process, and thus simultaneous effectiveness of patches of all the target VCPUs which share the code segment is realized when activating the patches in the multi-core environment.)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Yin with the teachings of Robinson and Tsirkin ‘792 in order to provide a method that teaches simultaneous execution of an operation by a plurality of vCPUs. The motivation for applying Yin teaching with Robinson and Tsirkin ‘792 teaching is to provide a method that allows for improvements directed towards lower synchronization time and high reliability when activating patches (Yin, [0041]). Robinson and Tsirkin ‘792 and Yin are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Yin with Robinson and Tsirkin ‘792 to teach the claimed invention in order to provide coordinated simultaneous execution of operations in a plurality of VCPUs.
Robinson, Tsirkin ‘792, and Yin teach VM configurations and interrupt multicasting for instruction execution of a VCPU. However, the combination does not explicitly teach cryptographic secrets that identify the VM or that the instruction to be executed are operations that can be performed with respect to cryptographic secrets.
Brooker teaches an initial cryptographic secret identifying the VM (Pg. 2, Challenges, This data (Examiner notes: In context of a virtual machine and the data that it copies to snapshots) can include cryptographic secrets and other high-value tokens);
…
operation with respect to the initial cryptographic secret (Pg. 3, Userspace Interfaces for Uniqueness, Solving the uniqueness problem strongly enough for cryptographic purposes requires a mechanism which can deterministically reseed userspace PRNGs with new entropy at restore time; Pg. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeros in the child processes after the call to fork, clone and related calls)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brooker with the teachings of Robinson, Tsirkin ‘792, and Yin in order to provide a method that teaches virtual machines maintaining cryptographic secrets and instructions to Tsirkin ‘792 on such cryptographic secrets. The motivation for applying Brooker teaching with Robinson, Tsirkin ‘792, and Yin teaching is to provide a method that allows for the known benefits of providing confidentiality and authentication properties offered by cryptographic keys used for storage encryption and secure communication protocols to be implemented in a virtualized computing environment. Robinson, Tsirkin ‘792, Yin, and Brooker are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Booker with Robinson, Tsirkin ‘792, and Yin to teach the claimed invention in order to provide secure encryption practices to virtual machines.
With regard to claim 2, Brooker teaches wherein the operation comprises at least one of erasing the initial cryptographic secret, modifying the initial cryptographic secret, and generating a new cryptographic secret (Pg. 3, The Value of Uniqueness, Widely-deployed cryptographically secure PRNGs (Examiner notes: Pseudo-random number generators) include NIST’s CTR_DRBG, Java’s SecureRandom, and Javascript’s getRandomValues. Most of these PRNGs are deterministic algorithms that get their seeds from the kernel or hardware RNGs, either at startup or periodically; Pg. 3, Fork and MADV_WIPEONFORK, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Operation erases initial cryptographic secret and regenerates a new cryptographic secret from PRNGs above). This does not require additional system calls, and adds only the overhead of a single memory access per call to the number generation library).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brooker with the teachings of Robinson, Tsirkin ‘792, and Yin in order to provide a method that teaches operations that manipulate cryptographic secrets including erasing, modifying and generating secrets. The motivation for applying Brooker teaching with Robinson, Tsirkin ‘792, and Yin teaching is to provide a method that allows for interfaces to perform configurations of cryptographic material on a per-VM basis, such that prevents correctness issues, data corruption, incorrect traces and behavior errors (Brooker, Pg. 2). Robinson, Tsirkin ‘792, Yin, and Brooker are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brooker with Robinson, Tsirkin ‘792, and Yin to teach the claimed invention in order to provide mechanisms to implement security best practices in maintaining unique secrets across virtualized environments.
With regard to claim 3, Robinson reasonably teaches command issuing to one or more duplicate virtual machines in a hypervisor environment (Robinson, [0028]). However, Robinson and Brooker do not explicitly discuss multicasting of an interrupt to the plurality of vCPUs of one or more VMs.
Tsirkin ‘792 teaches wherein multicasting the interrupt to the plurality of vCPUs of the one or more duplicate VMs comprises:
multicasting the interrupt to respective pluralities of vCPUs ([0030], Computer system 100 may run one or more virtual machines 170A-170B, by executing a virtual machine manager 180, often referred to as “hypervisor”, above the hardware and below the virtual machines, as schematically illustrated by FIG. 1 … virtual machine 170 may execute a guest operating system 196 which may utilize underlying virtual processors (also referred to as virtual central processing units (vCPUS)) 190 … A number of vCPUs 190 from different virtual machines may be mapped to one processor 120) for each duplicate VM of a set of two or more duplicate VMs ([0019], In an illustrative example, a first VM with two vCPUs (vCPU1 and vCPU2) and a second VM with two vCPUs (vCPU3 and vCPU4) may be running concurrently on a host with two physical CPUs (hCPU1 ad hCPU2); [0034], In an illustrative example, at operation 205 the hypervisor may detect an IPI received by a physical processor of the host computer and addressed to a vCPU of a virtual machine running on the host computer system (e.g., vCPU 190a of VM170a). Subsequently the hypervisor, at operation 210, may broadcast the IPI to at least a subset of vCPUs of the VM170A (e.g., vCPU 190a and vCPU190N). The subset of vCPUs may be constructed to include two or more vCPUs frequently communication with each other.); or
multicasting the interrupt to a plurality of vCPUs for the VM and to respective pluralities of vCPUs for each duplicate VM of a set of two or more duplicate VMs.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin ‘792 with the teachings of Robinson, Yin, and Booker in order to provide a method that teaches multicasting an interrupt to a plurality of designated vCPUs associated with duplicate VMs. The motivation for applying Tsirkin ‘792 teaching with Robinson, Yin, and Booker teaching is to provide a method that allows for distribution of a single interrupt message across all associated vCPUs of Tsirkin ‘792 with the duplicated virtual machines of Robinson such that enables a reduction in inter-processor interrupt overhead for duplicated virtual machines (Tsirkin ‘792, [0038]). Robinson, Brooker, Yin, and Tsirkin ‘792 are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin ‘792 with Robinson, Yin, and Booker to teach the claimed invention in order to provide simultaneous signaling of interrupts on vCPUs of target VMs.
With regard to claim 5, Tsirkin ‘792 teaches wherein multicasting the interrupt causes ([0041], the hypervisor may multicast the IPI to a subset of the plurality of the virtual processors … multicasting the IPI may cause the IPI to be sent to a subset of the virtual processors in an environment
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin ‘792 with the teachings of Robinson, Brooker, and Yin in order to provide a method that teaches multicasting an interrupt associated with instructions to execute an operation. The motivation for applying Tsirkin ‘792 teaching with Robinson, Brooker, and Yin teaching is to provide a method that allows for reducing inter-processor interrupt overhead (Tsirkin ‘792, [0020]). Robinson, Brooker, Yin and Tsirkin ‘792 are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin ‘792 with Robinson, Brooker, and Yin to teach the claimed invention in order to provide simultaneous, distributed request handling.
However, Tsirkin does not explicitly teach that the instructions associated with the interrupt are directed to generating a new cryptographic secret for a duplicate VM of the one or more duplicate VMs.
Brooker teaches a new cryptographic secret to be generated for a duplicate VM of the one or more duplicate VMs (Fig. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK, was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeroes in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that the system call MADV_WIPEONFORK triggers for a new cryptographic secret to be generated in the cloned VM).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brooker with the teachings of Robinson, Tsirkin ‘792, and Yin in order to provide a method that teaches operations to generate new cryptographic secrets on newly duplicated VMs. The motivation for applying Brooker teaching with Robinson, Tsirkin ‘792, and Yin teaching is to provide a method that allows for maintaining the confidentiality and authenticity properties of data offered by cryptography such that renewal continuously secures storage and network communications on a system (Brooker, Pg. 2). Robinson, Tsirkin ‘792, Yin, and Brooker are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brooker with Robinson, Tsirkin ‘792, and Yin to teach the claimed invention in order to provide cryptographic secret maintenance.
With regard to claim 6, Brooker teaches wherein the new cryptographic secret is generated responsive to a triggering event, the triggering event provided by one of (Pg. 3, The Value of Uniqueness, Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments … Hardware RNGs, such as Intel’s RDSEED and RDRAND … can also provide high-quality entropy inside cloned MicroVMs):
executing the one or more duplicate VMs (Pg. 2, Introduction, When a cold start is needed the snapshot is cloned and restored; Pg. 3, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that when a cold start virtual machine is invoked for execution, the VM wipes and regenerates cryptographic material upon cloning);
at least one VM of the one or more duplicate VMs being connected to a network; and
at least one VM of the one or more duplicate VMs sending a request to establish secure communication.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brooker with the teachings of Robinson, Tsirkin ‘792, and Yin in order to provide a method that teaches cryptographic secret regeneration upon virtual machine cloning. The motivation for applying Brooker teaching with Robinson, Tsirkin ‘792, and Yin teaching is to provide a method that allows for cryptographic secret renewal upon execution of a cloned VM utilizing applications requiring security such that prevents well-known security vulnerabilities including replay and Sybil attacks (Brooker, Pg. 2). Robinson, Tsirkin ‘792, Yin, and Brooker are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brooker with Robinson, Tsirkin ‘792, and Yin to teach the claimed invention in order to provide automatic cryptographic secret renewal upon VM cloning to maintain security posture of a system.
With regard to claim 7, Brooker teaches wherein the new cryptographic secret is generated by an operation of a duplicate VM of the one or more duplicate VMs an operation of the hypervisor, or a combined operation of the hypervisor and the duplicate VM (Pg. 3, The Value of Uniqueness, These properties – the need for unique IVs and keys with both low predictability and very small probability duplication – require that even cloned MicroVMs have access to high-quality entropy, and the means to use it. In some cases, such as AES_GCM, these values need only be unique and not random, so access to unique per-VM identifier is sufficient. Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments. Typically, entropy is injected into the guest, where it can be accessed using devices (like /dev/urandom/) or system calls (like getrandom) … Many applications don’t obtain their entropy directly from the kernel or hardware, and instead deploy userspace pseudo-random number generators (PRNGs) or deterministic random bit generators (DRBGs) (Examiner notes: Where cryptographic secrets are generated by operations that can be performed by a VM).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brooker with the teachings of Robinson, Tsirkin ‘792, and Yin in order to provide a method that teaches cryptographic secret generation occurring within a VM resulting from execution of a provided operation. The motivation for applying Brooker teaching with Robinson, Tsirkin ‘792, and Yin teaching is to provide a method that allows for VMs to consume their own unique entropy to be used in cryptographic secret generation, thereby benefitting from isolation such that compromise of one VM’s entropy pool does not affect the security of other VMs (Brooker, Pg. 2-Pg. 3). Robinson, Tsirkin ‘792, Yin and Brooker are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brooker with Robinson, Tsirkin ‘792, and Yin to teach the claimed invention in order to provide cryptographic secret generation in through execution of operations in isolated VMs.
With regard to claim 8, Robinson teaches a system comprising ([0006], Techniques and systems are disclosed herein for creating thin clones (e.g., clones that do not have copies of all files associated with a base VM) of a virtual machine (VM) to copy and deduplicate storage for the VMs):
a memory device ([0002], Virtual machines operate in a hypervisor environment, whereby a hypervisor interacts with physical devices, such as … memory and storage; [0072], Computer readable media include … volatile and non-volatile memory, such as read-only memory (ROM), random-access memory (RAM) … which can be used to store data);
a processing device operatively coupled to the memory device, to perform operations comprising ([0002], Virtual machines operate in a hypervisor environment, whereby a hypervisor interacts with physical devices, such as processors; [0074], One or more components may reside within a process and/or thread of execution and a component may be localized one computer and/or distributed between two or more computers):
executing, by a hypervisor running on a host computer system ([0002], In a computing environment, virtual machines may be used to concurrently run multiple operating systems on a single physical computing system … Physical servers can be converted into virtual servers running a hypervisor, which allows one or more virtual machines to run on a single physical server. A cluster of virtual servers may be linked to a storage volume that can be used to back up data from the plurality of virtual servers … Virtual machines operate in a hypervisor environment, whereby a hypervisor interacts with physical devices, such as processors, input/output devices, memory and storage and the hypervisor emulates a capability of these devices to the virtual machines), a virtual machine (VM) ([0022], The exemplary method 200 begins at 202 and involves creating a base VM in a directory of a storage container (e.g. ,a data store) attached to a hypervisor, at 204. For example, a VM hosting server may be operating a hypervisor, and may also be acting as a storage server in a storage system. In this example, a base VM can be created in the VM hosting server that may be a “gold standard” VM for an enterprise, and the VM can be listed in the directory of the server) …;
creating, by the hypervisor, a snapshot of the VM ([0024], At 208, VM files can be copied into one or more desired locations in the storage container, using a snapshot of the files. For example, a snapshot can be locally retained, read-only, point-in-time image of data);
executing, by the hypervisor, one or more duplicate VMs from the snapshot of the VM ([0031], at 216, in the exemplary embodiment 200, one or more of the cloned VMs can be registered within a hypervisor environment. VM registration … can allow the hypervisor to recognize a cloned VM as a valid entity within the hypervisor environment, for example (Examiner notes: Such that the cloned VMs begin executing in this environment)
Robinson explicitly teaches that one or more cloned VMs can be customized by issuing commands to cloned virtual machines through embodiments not limited by the disclosure and known by those skilled in the art (Robinson, [0028] and [0030]). Robinson does not explicitly teach multicasting an interrupt to a plurality of vCPUs associated with instructions to execute an operation.
Tsirkin ‘792 teaches multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUS) of the one or more duplicate VMs ([0041], the hypervisor may multicast the IPI to a subset of the plurality of the virtual processors … multicasting the IPI may cause the IPI to be sent to a subset of the virtual processors in an environment), the interrupt associated with instructions to execute an operation ([0042], At block 340, the hypervisor may check whether at least one vCPU of the plurality of vCPUs is in an active state. A vCPU may be in the active state if the vCPU is performing a task or executing an IPI, as described in more detail herein above.)
Rationale to claim 1 applied here.
However, Robinson and Tsirkin ‘792 do not explicitly teach executing the operation simultaneously.
Yin teaches executing, by the plurality of vCPUs ([0009], An embodiment of the present invention provides a patching method in a multi-core environment, where the method includes: sending an inter-core non-maskable interrupt to each target VCPU in a target VCPU group which share a code segment, so that said each target VCPU enters a patch synchronization state, in response to the inter-core non-maskable interrupt), the operation with respect to the initial cryptographic secret simultaneously ([0041], It can be seen that, in the patching device of the target VCPU according to the embodiment of the present invention, the synchronization of VCPUs which share a code segment is realized in the mode of synchronization of inter-core non-maskable interrupts, and after all the target VCPUs which share the original function have entered the patch synchronization state, the first instruction of the original functions to be patched of all the target VCPUs are modified into abnormal instructions, so that the patching device of the target VCPUs enables the original function to be patched to jump to the new patch function in the exception handling process, and thus simultaneous effectiveness of patches of all the target VCPUs which share the code segment is realized when activating the patches in the multi-core environment.)
Rationale to claim 1 applied here.
Robinson, Tsirkin, and Yin do not explicitly teach cryptographic secrets that identify the VM nor operations that can be performed with respect to cryptographic secrets.
Brooker teaches an initial cryptographic secret identifying the VM (Pg. 2, Challenges, This data (Examiner notes: In context of a virtual machine and its data copied to snapshots) can include cryptographic secrets and other high-value tokens);
…
operation with respect to the initial cryptographic secret (Pg. 3, Userspace Interfaces for Uniqueness, Solving the uniqueness problem strongly enough for cryptographic purposes requires a mechanism which can deterministically reseed userspace PRNGs with new entropy at restore time; Pg. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeros in the child processes after the call to fork, clone and related calls) which is substantially similar to claim 1 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 1 is being substantially recited again as limitations for the system of claim 8.
With regard to claim 9, Brooker teaches wherein the interrupt is associated with instructions to execute the operation comprising at least one of: erasing the initial cryptographic secret, modifying the initial cryptographic secret, and generating a new cryptographic secret (Pg. 3, The Value of Uniqueness, Widely-deployed cryptographically secure PRNGs (Examiner notes: Pseudo-random number generators) include NIST’s CTR_DRBG, Java’s SecureRandom, and Javascript’s getRandomValues. Most of these PRNGs are deterministic algorithms that get their seeds from the kernel or hardware RNGs, either at startup or periodically; Pg. 3, Fork and MADV_WIPEONFORK, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Operation erases initial cryptographic secret and regenerates a new cryptographic secret from PRNGs above). This does not require additional system calls, and adds only the overhead of a single memory access per call to the number generation library) which is substantially similar to claim 2 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 2 is being substantially recited again as limitations for the system of claim 9.
With regard to claim 10, Tsirkin ’792 teaches wherein the multicasting the interrupt to the plurality of vCPUs of the one or more duplicate VMs comprises multicasting the interrupt to respective pluralities of vCPUs ([0030], Computer system 100 may run one or more virtual machines 170A-170B, by executing a virtual machine manager 180, often referred to as “hypervisor”, above the hardware and below the virtual machines, as schematically illustrated by FIG. 1 … virtual machine 170 may execute a guest operating system 196 which may utilize underlying virtual processors (also referred to as virtual central processing units (vCPUS)) 190 … A number of vCPUs 190 from different virtual machines may be mapped to one processor 120) for each duplicate VM of a set of two or more duplicate VMs ([0019], In an illustrative example, a first VM with two vCPUs (vCPU1 and vCPU2) and a second VM with two vCPUs (vCPU3 and vCPU4) may be running concurrently on a host with two physical CPUs (hCPU1 ad hCPU2); [0034], In an illustrative example, at operation 205 the hypervisor may detect an IPI received by a physical processor of the host computer and addressed to a vCPU of a virtual machine running on the host computer system (e.g., vCPU 190a of VM170a). Subsequently the hypervisor, at operation 210, may broadcast the IPI to at least a subset of vCPUs of the VM170A (e.g., vCPU 190a and vCPU190N). The subset of vCPUs may be constructed to include two or more vCPUs frequently communication with each other.) which is substantially similar to claim 3 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 3 is being substantially recited again as limitations for the system of claim 10.
With regard to claim 12, Tsirkin ’792 teaches wherein multicasting the interrupt causes (Col. 5-Col. 6, lines 57-67 and lines 1-3, In one embodiment, when VM 120 receives the event, it retrieves the hint and implements it in such a way that the event will be delivered to VCPU 1 202 … the hypervisor 115 captures and interprets these programming instructions so that any interrupts associated with the programming instructions are sent to the correct VCPU 1 202 and/or 2 204 for the virtual device event)
Rationale to claim 5 applied here.
However, Tsirkin ’792 does not explicitly teach that the instructions associated with the interrupt are directed to generating a new cryptographic secret for a duplicate VM of the one or more duplicate VMs.
Brooker teaches a new cryptographic secret to be generated for a duplicate VM of the one or more duplicate VMs (Fig. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK, was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeroes in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that the system call MADV_WIPEONFORK triggers for a new cryptographic secret to be generated in the cloned VM) which is substantially similar to claim 5 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 5 is being substantially recited again as limitations for the system of claim 12.
With regard to claim 13, Brooker teaches wherein the new cryptographic secret is generated responsive to a triggering event, the triggering event provided by one of (Pg. 3, The Value of Uniqueness, Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments … Hardware RNGs, such as Intel’s RDSEED and RDRAND … can also provide high-quality entropy inside cloned MicroVMs):
executing the one or more duplicate VMs (Pg. 2, Introduction, When a cold start is needed the snapshot is cloned and restored; Pg. 3, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that when a cold start virtual machine is invoked for execution, the VM wipes and regenerates cryptographic material upon cloning);
at least one VM of the one or more duplicate VMs being connected to a network; and
at least one VM of the one or more duplicate VMs sending a request to establish secure communication
which is substantially similar to claim 6 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 6 is being substantially recited again as limitations for the system of claim 13.
With regard to claim 14, Brooker teaches wherein the new cryptographic secret is generated by an operation of a duplicate VM of the one or more duplicate VMs, an operation of the hypervisor, or a combined operation of the hypervisor and the duplicate VM (Pg. 3, The Value of Uniqueness, These properties – the need for unique IVs and keys with both low predictability and very small probability duplication – require that even cloned MicroVMs have access to high-quality entropy, and the means to use it. In some cases, such as AES_GCM, these values need only be unique and not random, so access to unique per-VM identifier is sufficient. Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments. Typically, entropy is injected into the guest, where it can be accessed using devices (like /dev/urandom/) or system calls (like getrandom) … Many applications don’t obtain their entropy directly from the kernel or hardware, and instead deploy userspace pseudo-random number generators (PRNGs) or deterministic random bit generators (DRBGs) (Examiner notes: Where cryptographic secrets are generated by operations that can be performed by a VM) which is substantially similar to claim 7 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 7 is being substantially recited again as limitations for the system of claim 1.
With regard to claim 15, Robinson teaches a non-transitory computer-readable media storing instructions that, when executed, cause a processing device to perform operations comprising ([0067], An exemplary computer-usable medium that may be devices in these ways is illustrated in FIG. 8, wherein the implementation 800 comprises a computer-usable medium 808 … In one such embodiment, the processor-executable instructions 804 may be configured to perform the steps described in exemplary method 200 of FIG. 2):
executing, by a hypervisor running on a host computer system ([0002], In a computing environment, virtual machines may be used to concurrently run multiple operating systems on a single physical computing system … Physical servers can be converted into virtual servers running a hypervisor, which allows one or more virtual machines to run on a single physical server. A cluster of virtual servers may be linked to a storage volume that can be used to back up data from the plurality of virtual servers … Virtual machines operate in a hypervisor environment, whereby a hypervisor interacts with physical devices, such as processors, input/output devices, memory and storage and the hypervisor emulates a capability of these devices to the virtual machines), a virtual machine (VM) ([0022], The exemplary method 200 begins at 202 and involves creating a base VM in a directory of a storage container (e.g. ,a data store) attached to a hypervisor, at 204. For example, a VM hosting server may be operating a hypervisor, and may also be acting as a storage server in a storage system. In this example, a base VM can be created in the VM hosting server that may be a “gold standard” VM for an enterprise, and the VM can be listed in the directory of the server)
…;
creating, by the hypervisor, a snapshot of the VM ([0024], At 208, VM files can be copied into one or more desired locations in the storage container, using a snapshot of the files. For example, a snapshot can be locally retained, read-only, point-in-time image of data); and
executing, by the hypervisor, one or more duplicate VMs from the snapshot of the VM ([0031], at 216, in the exemplary embodiment 200, one or more of the cloned VMs can be registered within a hypervisor environment. VM registration … can allow the hypervisor to recognize a cloned VM as a valid entity within the hypervisor environment, for example (Examiner notes: Such that the cloned VMs begin executing in this environment).
Robinson explicitly teaches that one or more cloned VMs can be customized by issuing commands to cloned virtual machines through embodiments not limited by the disclosure and known by those skilled in the art (Robinson, [0028] and [0030]). Robinson does not explicitly teach multicasting an interrupt to a plurality of vCPUs associated with instructions to execute an operation.
Tsirkin ‘792 teaches multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUs) of the VM ([0041], the hypervisor may multicast the IPI to a subset of the plurality of the virtual processors … multicasting the IPI may cause the IPI to be sent to a subset of the virtual processors in an environment), the interrupt associated with instructions to execute an operation ([0042], At block 340, the hypervisor may check whether at least one vCPU of the plurality of vCPUs is in an active state. A vCPU may be in the active state if the vCPU is performing a task or executing an IPI, as described in more detail herein above.)
Rationale to claim 1 applied here.
However, Robinson and Tsirkin do not explicitly teach executing the operation simultaneously.
Yin teaches executing, by the plurality of vCPUs ([0009], An embodiment of the present invention provides a patching method in a multi-core environment, where the method includes: sending an inter-core non-maskable interrupt to each target VCPU in a target VCPU group which share a code segment, so that said each target VCPU enters a patch synchronization state, in response to the inter-core non-maskable interrupt), the operation with respect to the initial cryptographic secret simultaneously ([0041], It can be seen that, in the patching device of the target VCPU according to the embodiment of the present invention, the synchronization of VCPUs which share a code segment is realized in the mode of synchronization of inter-core non-maskable interrupts, and after all the target VCPUs which share the original function have entered the patch synchronization state, the first instruction of the original functions to be patched of all the target VCPUs are modified into abnormal instructions, so that the patching device of the target VCPUs enables the original function to be patched to jump to the new patch function in the exception handling process, and thus simultaneous effectiveness of patches of all the target VCPUs which share the code segment is realized when activating the patches in the multi-core environment.)
Rationale to claim 1 applied here.
Robinson and Tsirkin do not explicitly teach cryptographic secrets that identify the VM nor operations that can be performed with respect to cryptographic secrets.
Brooker teaches with an initial cryptographic secret identifying the VM (Pg. 2, Challenges, This data (Examiner notes: In context of a virtual machine and its data copied to snapshots) can include cryptographic secrets and other high-value tokens);
…
with respect to the initial cryptographic secret (Pg. 3, Userspace Interfaces for Uniqueness, Solving the uniqueness problem strongly enough for cryptographic purposes requires a mechanism which can deterministically reseed userspace PRNGs with new entropy at restore time; Pg. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeros in the child processes after the call to fork, clone and related calls) which is substantially similar to claim 1 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 1 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 15.
With regard to claim 16, Brooker teaches wherein the interrupt is associated with instructions to execute the operation comprising at least one of: erasing the initial cryptographic secret, modifying the initial cryptographic secret, and generating a new cryptographic secret (Pg. 3, The Value of Uniqueness, Widely-deployed cryptographically secure PRNGs (Examiner notes: Pseudo-random number generators) include NIST’s CTR_DRBG, Java’s SecureRandom, and Javascript’s getRandomValues. Most of these PRNGs are deterministic algorithms that get their seeds from the kernel or hardware RNGs, either at startup or periodically; Pg. 3, Fork and MADV_WIPEONFORK, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Operation erases initial cryptographic secret and regenerates a new cryptographic secret from PRNGs above). This does not require additional system calls, and adds only the overhead of a single memory access per call to the number generation library) which is substantially similar to claim 2 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 2 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 16.
With regard to claim 18, Tsirkin ’792 teaches wherein multicasting the interrupt causes (Col. 5-Col. 6, lines 57-67 and lines 1-3, In one embodiment, when VM 120 receives the event, it retrieves the hint and implements it in such a way that the event will be delivered to VCPU 1 202 … the hypervisor 115 captures and interprets these programming instructions so that any interrupts associated with the programming instructions are sent to the correct VCPU 1 202 and/or 2 204 for the virtual device event)
Rationale to claim 5 applied here.
However, Tsirkin does not explicitly teach that the instructions associated with the interrupt are directed to generating a new cryptographic secret for a duplicate VM of the one or more duplicate VMs.
Brooker teaches a new cryptographic secret to be generated for the VM (Fig. 3, Fork and MADV_WIPEONFORK, A new madvise flag, MADV_WIPEONFORK, was introduced in Linux 4.14 in 2017. Memory pages marked MADV_WIPEONFORK are set to all zeroes in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that the system call MADV_WIPEONFORK triggers for a new cryptographic secret to be generated in the cloned VM) which is substantially similar to claim 5 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 5 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 18.
With regard to claim 19, Brooker teaches wherein the new cryptographic secret is generated responsive to a trigger event, the trigger event provided by one of (Pg. 3, The Value of Uniqueness, Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments … Hardware RNGs, such as Intel’s RDSEED and RDRAND … can also provide high-quality entropy inside cloned MicroVMs):
initiating a creation of the snapshot of the VM (Pg. 4, Suspend and MADV_WIPEONSUSPEND, by analogy to MADV_WIPEONFORK, we have contributed a new MADV_WIPEONSUSPEND flag to the Linux kernel, which marks pages to be wiped when a VM is suspended (a precursor to snapshotting). We expect that PRNGs and cryptographic libraries mark their state or guard variables as both MADV_WIPEONFORK and MADV_WIPEONSUSPEND and use the same reseeding logic to handle both the fork and VM clone cases);
executing the one or more duplicate VMs (Pg. 2, Introduction, When a cold start is needed the snapshot is cloned and restored; Pg. 3, Memory pages marked MADV_WIPEONFORK are set to all zeros in the child process after the call to fork, clone and related calls. PRNGs which mark their internal state this way, or put a guard variable in a page marked this way, can deterministically detect they have been forked, and reseed from kernel or hardware randomness (Examiner notes: Such that when a cold start virtual machine is invoked for execution, the VM wipes and regenerates cryptographic material upon cloning);
at least one VM of the one or more duplicate VMs being connected to a network; and
at least one VM of the one or more duplicate VMs sending a request to establish secure communication
which is substantially similar to claim 6 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 6 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 19.
With regard to claim 20, Brooker wherein the new cryptographic secret is generate by an operation of the VM, an operation of a duplicative VM of the one or more duplicate VMs, an operation of the hypervisor, or a combined operation of the hypervisor and either the VM or the duplicate VM (Pg. 3, The Value of Uniqueness, These properties – the need for unique IVs and keys with both low predictability and very small probability duplication – require that even cloned MicroVMs have access to high-quality entropy, and the means to use it. In some cases, such as AES_GCM, these values need only be unique and not random, so access to unique per-VM identifier is sufficient. Solutions to the entropy problem are well-understood, and widely deployed in virtualized environments. Typically, entropy is injected into the guest, where it can be accessed using devices (like /dev/urandom/) or system calls (like getrandom) … Many applications don’t obtain their entropy directly from the kernel or hardware, and instead deploy userspace pseudo-random number generators (PRNGs) or deterministic random bit generators (DRBGs) (Examiner notes: Where cryptographic secrets are generated by operations that can be performed by a VM) which is substantially similar to claim 7 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 7 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 20.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Robinson in view of Tsirkin '792 in view of Yin in view of Brooker as applied to claim 1, 8, and 15 above, and further in view of Tsirkin Patent No. US 9,411,624 B2 (hereinafter Tsirkin '624).
With regard to claim 4, Tsirkin ‘792 teaches further comprising:
multicasting the interrupt to the at least two vCPUs ([0041], In this example multicasting the IPI may cause the IPI to be sent to a subset of the virtual processors in an environment)
Rationale to claim 1 applied here.
However, the combination does not explicitly teach vCPU interrupt registration.
Tsirkin ‘624 teaches determining, for each vCPU of the plurality of vCPUS, whether the vCPU is registered to receive the interrupt (Col. 5, lines 46-52, For instance, in embodiments of the invention, when hypervisor 115 receives a request to notify VM 120 of a device 150 event, then VM device manager 118 may first access VCPU-to-host CPU mappings 235 stored in hypervisor memory 230 to determine if there are any VCPUs 202, 204 running on VM 120 that are associated with host CPU 2 224 (i.e., topological proximity); and
responsive to determining that at least two vCPUs of the plurality of vCPUs are registered to receive the interrupt, multicasting [transmitting] the interrupt to the at least two vCPUs (Col. 6, lines 18-24, In some embodiments, the hint may encompass more than one VCPU on the VM 120. For instance, the hypervisor 115 may identify all of, or a subset of, the VCPUs 202, 204 on VM 120 and rank them according to topological proximity to the event-delivering host CPU 224. The VM device manager 118 may the send this list of VCPUs to the VM 120 as the hint, and the VM 120 processes this list accordingly).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tsirkin ‘624 with the teachings of Robinson, Brooker, Yin and Tsirkin ‘792 in order to provide a method that teaches determining and multicasting the interrupt direct to the VM clones. The motivation for applying Tsirkin ‘624 teaching with of Robinson, Brooker, Yin and Tsirkin ‘792 teaching is to provide a method that allows for improvement in request handling such that determining which vCPUs are subscribed to receive an interrupt reduces unnecessary resource consumption and time delays over generic interrupt broadcasting. Robinson, Brooker, Yin, Tsirkin ‘792 and Tsirkin ‘624 are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin ‘624 with of Robinson, Brooker, Yin and Tsirkin ‘792 to teach the claimed invention in order to provide targeted to vCPUs registered to act on the instruction.
With regard to claim 11, Tsirkin teaches wherein the operations further comprise:
determining, for each vCPU of the plurality of vCPUs, whether the vCPU is registered to receive the interrupt (Col. 5, lines 46-52, For instance, in embodiments of the invention, when hypervisor 115 receives a request to notify VM 120 of a device 150 event, then VM device manager 118 may first access VCPU-to-host CPU mappings 235 stored in hypervisor memory 230 to determine if there are any VCPUs 202, 204 running on VM 120 that are associated with host CPU 2 224 (i.e., topological proximity); and
responsive to determining that at least two vCPUs of the plurality of vCPUs are registered to receive the interrupt, multicasting [transmitting] the interrupt to the at least two vCPUs (Col. 6, lines 18-24, In some embodiments, the hint may encompass more than one VCPU on the VM 120. For instance, the hypervisor 115 may identify all of, or a subset of, the VCPUs 202, 204 on VM 120 and rank them according to topological proximity to the event-delivering host CPU 224. The VM device manager 118 may the send this list of VCPUs to the VM 120 as the hint, and the VM 120 processes this list accordingly) which is substantially similar to claim 4 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 4 is being substantially recited again as limitations for the system of claim 11.
With regard to claim 17, Tsirkin teaches where the operations further comprise:
determining, for each vCPU of the plurality of vCPUs, whether the vCPU is registered to receive the interrupt (Col. 5, lines 46-52, For instance, in embodiments of the invention, when hypervisor 115 receives a request to notify VM 120 of a device 150 event, then VM device manager 118 may first access VCPU-to-host CPU mappings 235 stored in hypervisor memory 230 to determine if there are any VCPUs 202, 204 running on VM 120 that are associated with host CPU 2 224 (i.e., topological proximity); and
responsive to determining that at least two vCPUs of the plurality of vCPUs are registered to receive the interrupt, multicasting [transmitting] the interrupt to the at least two vCPUs (Col. 6, lines 18-24, In some embodiments, the hint may encompass more than one VCPU on the VM 120. For instance, the hypervisor 115 may identify all of, or a subset of, the VCPUs 202, 204 on VM 120 and rank them according to topological proximity to the event-delivering host CPU 224. The VM device manager 118 may the send this list of VCPUs to the VM 120 as the hint, and the VM 120 processes this list accordingly) which is substantially similar to claim 4 and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that the method of claim 4 is being substantially recited again as limitations for the non-transitory computer-readable media of claim 17.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM 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, Aimee Li can be reached at (571) 272-4169. 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.
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
/I.A.C./Examiner, Art Unit 2195
Prosecution Insights