DETAILED ACTION
This Office Action is in response to claims filed on 12/18/2025.
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 pages 7-8 of remarks, filed 12/18/2025, with respect to 35 U.S.C. 112(b) rejection of claim 1 and subsequent claims 2-20 have been fully considered and are persuasive. The rejection of 08/27/2025 has been withdrawn.
Applicant's arguments filed 12/18/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
Applicant respectfully submits that nowhere does the cited art teach or suggest amended claim 1. Specifically, nowhere does the cited art teach or suggest “multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUs) of the one or more duplicate VMs, the interrupt associated with instructions to execute an operation with respect to the initial cryptographic secret, wherein the interrupt is generated by the hypervisor” as recited in amended claim 1. (emphasis added). Tsirkin discloses “the programming instruction directs interrupts associated with the virtual device event to a VCPU that was identified in the provided hint” and the “hint is a list of all, or subset of, the VCPUs running on the VM ranked in order of topological closeness to the host CPU originating the event.” Tsirkin, Col. 6-7, ln. 50-67 and 1-3. (emphasis added). Accordingly, nowhere does Tsirskin teach or suggest amended claim 1. Furthermore, the Office Action concedes that Robinson does not “explicitly teach multicasting an interrupt to a plurality of vCPUs associated with instructions to execute an operation,” and therefore fails to cure the deficiencies of Tsirkin. Office Action, p. 4.
For at least the foregoing reasons, Applicant submits that claim 1 is patentably distinct from the cited art.
With regard to point (a), Examiner respectfully disagrees. Applicant’s argument contends that the Tsirkin reference fails to disclose the limitation recited above, with particular emphasis placed on the limitations of “multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units”. In view of the instant specification, Examiner has not identified a narrower construction of the term “multicast”, and thus applies the broadest reasonable interpretation. Under its plain and ordinary meaning, “multicast” refers to the delivery of a signal or message from one source to multiple destinations simultaneously. As such, the Tsirkin references reasonably teaches an identification of a list of vCPUs associated with a particular event and directs an interrupt to the plurality of identified vCPUs, as substantially recited in the claim. Particularly, Tsirkin discloses that the hypervisor references a “VCPU-to-host mapping” such that the hypervisor may direct “any interrupts associated with the programming instructions are sent to the correct VCPU 1 202 and/or 2 204 for the virtual device event” (Col. 6, lines 1-3).
Further, Applicant’s argument contends that Tsirkin reference fails to disclose the newly added limitation of “wherein the interrupt is generated by the hypervisor” recited in claims 1, 8 and 15. However, the Tsirkin reference further reasonably teaches the limitation reciting “Hypervisor 115 is then responsible for providing the event to VM 120 via an interrupt” (Col. 5, lines 23-24).
The Examiner seeks to clarify that the embodiment disclosing a hint listing the vCPUs ranked in order of topological closeness is cited solely to further establish that the Tsirkin reference teaches a plurality of vCPUs as targets for interrupt by the hypervisor. The multicasting limitation as a whole is taught by Tsirkin’s disclosure of the hypervisor’s responsibility for providing an interrupt to a plurality of vCPUs simultaneously as demonstrated above.
Accordingly, the Tsirkin reference reasonably teaches the claimed limitation under the broadest reasonable interpretation of the term “multicasting”, as the hypervisor coordinates and delivers interrupt signals to a plurality of specified vCPUs in association with a virtual device event. The cited prior art continues to teach the amended limitations and the rejection is maintained.
Argument has not been found to be persuasive.
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-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 Patent No. US 9,411,624 B2 (hereinafter Tsirkin) 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 teaches multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUs) of one or more duplicate VMs (Col. 6-Col. 7, lines 50-67 and lines 1-3, at block 320, a VCPU-to-host mapping in the hypervisor’s memory is referenced in order to identify one or more VCPU(s) that are running on the host CPU that sent the virtual device event. The one or more VCPU(s) are running on the VM to which the event is directed. Subsequently, at block 330, the identified one or more VCPU(s) are provided to the VM as a hint. In one embodiment, the VCPU hint is provided along with the event to the VM. In one embodiment, the hint is a list of all, or a subset of, the VCPUs running on the VM ranked in order of topological closeness to the host CPU originating the event), the interrupt associated with instructions to execute an operation (Col. 7, lines 4-19, At block 340, a programming instruction is intercepted from the VM by the hypervisor. In one embodiment, the programming instruction directs interrupts associated with the virtual device event to a VCPU that was identified in the provided hint … At block 350, the programming instruction is interpreted by the hypervisor 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) …, wherein the interrupt is generated by the hypervisor (Col. 5, lines 23-24, In embodiments of the invention, hypervisor 115 implements optimized virtual device interrupts for VM 120; Col. 5, lines 30-31, Hypervisor 115 is then responsible for providing the event to VM 120 via an interrupt; Col. 6, lines 1-3, interrupts associated with the programming instructions are sent to the correct VCPU 1 202 and/or 2 204 for the virtual device event)
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 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 teaching with Robinson teaching is to provide a method that allows for improvement in request handling for virtual machines by delivering interrupts only to virtual machines specified, thereby overcoming the inefficiencies of unnecessary routing and needless processing or configuration changes in other virtual machines (Tsirkin, Col. 1). Robinson and Tsirkin are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with Robinson to teach the claimed invention in order to provide precise, distributed request handling.
Robinson and Tsirkin 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 and Tsirkin in order to provide a method that teaches virtual machines maintaining cryptographic secrets and instructions to operate on such cryptographic secrets. The motivation for applying Brooker teaching with Robinson and Tsirkin 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, 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 Tsirkin with Brooker and Robinson 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 and Tsirkin 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 and Tsirkin 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, 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 and Tsirkin 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 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 and Tsirkin 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 and Tsirkin 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, 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 and Tsirkin 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 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 for each duplicate VM of a set of two or more duplicate VMs; 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 (Col. 3, lines 43-59, Embodiments of the invention provide a mechanism for virtual device interrupt hinting in virtualization systems. Embodiments of the invention utilize a virtual device interrupt optimization applicable to situations where a host machine is running multiple host central processing units (CPUs) and a hypervisor is managing one or more virtual machines (VMs) on the host machine that utilize multiple virtual CPUs (VCPUs). When a virtual device event on one of the host CPUs is received at the hypervisor from the host CPU, the hypervisor determines which one or more VCPUs (of the VM that the virtual device event is directed to) runs on the host CPU; Col. 5, lines 23-35, In embodiments of the invention, hypervisor 115 implements optimized virtual device interrupts for VM 120 … Hypervisor 11 5 is then responsible for provide the event to VM 120 via an interrupt. Embodiments of the invention utilize a hint, sent along with the virtual device event, to notify the VM 210 of which of its VCPUs 202, 204 are topologically closest to the host CPU).
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 with the teachings of Robinson and Brooker 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 teaching with Robinson and Brooker teaching is to provide a method that allows for interrupts to be directed to a host CPU, translated between host CPU and VCPU of the corresponding VM, thereby enabling the precise signaling of a VM intended to receive the interrupt (Tsirkin, Col. 6). Robinson, Brooker, and Tsirkin are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with Robinson and Brooker to teach the claimed invention in order to provide precise signaling of interrupts on vCPUs of target VMs.
With regard to claim 4, Tsirkin teaches further comprising:
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 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 with the teachings of Robinson and Brooker in order to provide a method that teaches determining and multicasting the interrupt direct to the VM clones. The motivation for applying Tsirkin teaching with Robinson and Brooker 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, and Tsirkin are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with Robinson and Brooker to teach the claimed invention in order to provide targeted to vCPUs registered to act on the instruction.
With regard to claim 5, Tsirkin 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)
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 with the teachings of Robinson in order to provide a method that teaches multicasting an interrupt associated with instructions to execute an operation. The motivation for applying Tsirkin teaching with Robinson teaching is to provide a method that allows for improvement in request handling for virtual machines by delivering interrupts only to virtual machines specified, thereby overcoming the inefficiencies of unnecessary routing and needless processing or configuration changes in other virtual machines (Tsirkin, Col. 1). Robinson and Tsirkin are analogous art directed towards virtualization arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Tsirkin with Robinson to teach the claimed invention in order to provide precise, 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 and Tsirkin 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 and Tsirkin 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, 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 and Tsirkin 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 and Tsirkin in order to provide a method that teaches cryptographic secret regeneration upon virtual machine cloning. The motivation for applying Brooker teaching with Robinson and Tsirkin 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, 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 and Tsirkin 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 and Tsirkin 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 and Tsirkin 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, 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 and Tsirkin 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 teaches multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUS) of the one or more duplicate VMs (Col. 6-Col. 7, lines 50-67 and lines 1-3, at block 320, a VCPU-to-host mapping in the hypervisor’s memory is referenced in order to identify one or more VCPU(s) that are running on the host CPU that sent the virtual device event. The one or more VCPU(s) are running on the VM to which the event is directed. Subsequently, at block 330, the identified one or more VCPU(s) are provided to the VM as a hint. In one embodiment, the VCPU hint is provided along with the event to the VM. In one embodiment, the hint is a list of all, or a subset of, the VCPUs running on the VM ranked in order of topological closeness to the host CPU originating the event), the interrupt associated with instructions to execute an operation (Col. 7, lines 4-19, At block 340, a programming instruction is intercepted from the VM by the hypervisor. In one embodiment, the programming instruction directs interrupts associated with the virtual device event to a VCPU that was identified in the provided hint … At block 350, the programming instruction is interpreted by the hypervisor 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) …, wherein the interrupt is generated by the hypervisor (Col. 5, lines 23-24, In embodiments of the invention, hypervisor 115 implements optimized virtual device interrupts for VM 120; Col. 5, lines 30-31, Hypervisor 115 is then responsible for providing the event to VM 120 via an interrupt; Col. 6, lines 1-3, 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 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 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 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 for each duplicate VM of a set of two or more duplicate VMs (Col. 3, lines 43-59, Embodiments of the invention provide a mechanism for virtual device interrupt hinting in virtualization systems. Embodiments of the invention utilize a virtual device interrupt optimization applicable to situations where a host machine is running multiple host central processing units (CPUs) and a hypervisor is managing one or more virtual machines (VMs) on the host machine that utilize multiple virtual CPUs (VCPUs). When a virtual device event on one of the host CPUs is received at the hypervisor from the host CPU, the hypervisor determines which one or more VCPUs (of the VM that the virtual device event is directed to) runs on the host CPU) 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 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 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 12, Tsirkin 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 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.
multicasting, by the hypervisor, an interrupt to a plurality of virtual central processing units (vCPUs) of the VM (Col. 6-Col. 7, lines 50-67 and lines 1-3, at block 320, a VCPU-to-host mapping in the hypervisor’s memory is referenced in order to identify one or more VCPU(s) that are running on the host CPU that sent the virtual device event. The one or more VCPU(s) are running on the VM to which the event is directed. Subsequently, at block 330, the identified one or more VCPU(s) are provided to the VM as a hint. In one embodiment, the VCPU hint is provided along with the event to the VM. In one embodiment, the hint is a list of all, or a subset of, the VCPUs running on the VM ranked in order of topological closeness to the host CPU originating the event), the interrupt associated with instructions to execute an operation (Col. 7, lines 4-19, At block 340, a programming instruction is intercepted from the VM by the hypervisor. In one embodiment, the programming instruction directs interrupts associated with the virtual device event to a VCPU that was identified in the provided hint … At block 350, the programming instruction is interpreted by the hypervisor 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) …, wherein the interrupt is generated by the hypervisor (Col. 5, lines 23-24, In embodiments of the invention, hypervisor 115 implements optimized virtual device interrupts for VM 120; Col. 5, lines 30-31, Hypervisor 115 is then responsible for providing the event to VM 120 via an interrupt; Col. 6, lines 1-3, 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 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 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 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.
With regard to claim 18, Tsirkin 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.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195