DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant’s remarks filed October 1, 2025 have been fully considered but are not persuasive. Applicant argues that the claims are allowable because:
“The Office Action at page 7 cites to functionality performed by the storage management
service 103 in rejecting claim 3, but purports that "the claimed 'worker virtual machine' is
mapped to Roth's 'key management service 105"'. Thus, it is unclear from the rejection whether the key management service 105 or the storage management service 103 is intended to be analogous to the "worker virtual machine" of Applicant's claim 1. If the key management service 105 is intended to be analogous to the "worker virtual machine," the functionality attributed to the separate "storage management service 103" is improperly attributed to the key management service 105 without setting forth a sufficient rationale to modify the functionality of the key management service 105 as disclosed by Roth to arrive at the limitations of the pending claims.” (Applicant’s Remarks, Pgs. 8-9).
Examiner respectfully disagrees. Applicant’s argument mischaracterizes the mapping of claim 3. Examiner’s rejection of the “encrypting” step is mapped to the key management service. ([0068], the storage management service 103′ requests encryption of the plaintext volume key based on the destination region client key or its functional equivalent and retrieves a destination region encrypted volume key 512 corresponding to the volume… the storage management service 103′ can achieve this by making an API call to the key management service 105 of the destination region 501 in accordance with an applicable policy for utilizing the destination region client key for encryption of the plain text volume key)). With respect to the “storing” step of claim 3, Examiner’s mapping shows how Roth’s worker virtual machine (i.e. “key management service” provides keys to enable storage of the encrypted data to the destination storage block. ([0077], a key management service 105 can manage client keys internally and provide a set of APIs for performing client key related operations such as encryption or decryption with respect to encrypted volume keys). For example, the “key management service” facilitates the “storage” step.
Applicant’s remaining arguments are related to newly amended claim language and have been fully addressed in the rejections below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6,7, 9-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Roth et al. (US 20180150646) in view of Pappachan et al. (US 20170024570).
As per claim 1, Roth teaches the invention substantially as claimed including a method comprising:
receiving, by a source virtual machine managed by a hypervisor, ([0070], the request to migrate volume-specific data may be included in the client's request to initialize the virtual machine instance 114 or included in the client's communications with the virtual machine instance 114)[a measurement associated with a state of a firmware of the hypervisor,] a first identifier of a first storage block of the source virtual machine ([0070], the request to migrate volume-specific data may include metadata corresponding to the volume-specific data, such as a volume identifier, data descriptions, or snapshot identification information), and a second identifier of a second storage block of a destination virtual machine ([0043], physical storage space is allocated on corresponding storage system(s) and certain volume metadata information, such as a volume identifier corresponding to the volume is transmitted to the client 111, or to a virtual machine instance associated with the client 111);
transmitting, by the source virtual machine to a worker virtual machine ([0027], the key management service 105 is implemented by one or more virtual machines instances in a hosted computing environment), a first cryptographic key for use in copying data of the first storage block to the second storage block ([0072], the storage management service 103′ can provide the source region encrypted volume key; and [0073], this can be accomplished by an API call from one component to another within the service provider computer network 101. For example, the API call can be directed to the key management service 105′ of the source region 501′; Examiner Note: Roth’s “source region encrypted volume key” is used when copying the first storage block to the second storage block: [0022], a virtual machine manager or a storage management service in the service provider computer network obtains the source region encrypted volume key, causes decryption of the source region encrypted volume key based on source region client key, obtains plaintext volume key, and obtains a destination region encrypted volume key by causing encryption of the volume key based on destination region client key. The destination region encrypted volume key is then made available in the destination region. As such, the volume snapshot is copied from the source region to the destination region).
Roth fails to specifically teach, validating, by the source virtual machine, the measurement associated with the state of the firmware of the hypervisor.
However, Pappachan teaches, validating, by the source virtual machine, the measurement associated with the state of the firmware of the hypervisor ([0039], the TIO software components may be hosted by any other appropriate trusted execution environment. For example, in some embodiments, the TIO software components may be embodied as components inside a trusted virtual machine; and [0048], components inside a trusted virtual machine may use the measurement of the hosting VMM that was recorded at boot time).
Roth and Pappachan are analogous because they are each related to providing security in virtual environments. Roth teaches a method of copying data volumes attached to virtual machines from a source region to a destination region using encryption keys. ([0022], Besides copying the encrypted data portion of a volume snapshot from a source region to a destination region, cross-region snapshot copy can require a mechanism for obtaining an encrypted volume key corresponding to the destination region. In accordance with one embodiment, a virtual machine manager or a storage management service in the service provider computer network obtains the source region encrypted volume key, causes decryption of the source region encrypted volume key based on source region client key, obtains plaintext volume key, and obtains a destination region encrypted volume key by causing encryption of the volume key based on destination region client key. The destination region encrypted volume key is then made available in the destination region. As such, the volume snapshot is copied from the source region to the destination region). Pappachan teaches a “trusted virtual machine” for key management and security in a virtualized environment including validation of a hypervisor using measurements. (Abstract, computing device collects software attestation information for trusted software components loaded during secure enumeration. The computing device verifies the software attestation information. The computing device may collect firmware attestation information for firmware loaded in the I/O controllers and verify the firmware attestation information. The computing device may collect application attestation information for a trusted application that uses the trusted I/O usage and verify the application attestation information. Other embodiments are described and claimed; and [0039], TIO software components are illustratively embodied as secure enclaves protected by the secure enclave support 124 of the processor 120. It should be understood that in other embodiments, the TIO software components may be hosted by any other appropriate trusted execution environment. For example, in some embodiments, the TIO software components may be embodied as components inside a trusted virtual machine). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the teachings of Roth’s “key management service” would be modified with the hypervisor measuring mechanism of Roth’s “trusted virtual machine” resulting in a system that provides enhanced security by ensuring that a hypervisor has not been tampered. (Pappachan, [0003], SGX provides confidentiality, integrity, and replay-protection to the secure enclave data while the data is resident in the platform memory and thus provides protection against both software and hardware attacks). Therefore, it would have been obvious to combine the teachings of Roth and Pappachan.
As per claim 2, Roth teaches, further comprising:
transmitting, by the destination virtual machine to the worker virtual machine, a second cryptographic key for use in the copying the data of the first storage block to the second storage block ([0018], the encrypted volume key can be generated by a key management service based on information specific to a customer associated with a virtual machine instance (e.g., a client key) and the volume metadata; and [0022], a virtual machine manager or a storage management service in the service provider computer network …obtains a destination region encrypted volume key by causing encryption of the volume key based on destination region client key. The destination region encrypted volume key is then made available in the destination region. As such, the volume snapshot is copied from the source region to the destination region).
As per claim 3, Roth teaches, further comprising:
decrypting, by the worker virtual machine, using the first cryptographic key, the data of the first storage block ([0027], The key management service 105 may receive and respond to electronic requests to perform cryptographic operations, such as encryption of plaintext and decryption of ciphertext; and [0067], the storage management service 103′ requests decryption of the source region encrypted volume key 512′ based on the source region client key or its functional equivalent and retrieves the plaintext volume key from the key management service 105′ of the source region 501′; Examiner Note: the claimed “worker virtual machine” is mapped to Roth’s “key management service 105”: [0027], the key management service 105 is implemented by one or more virtual machines instances in a hosted computing environment);
encrypting, by the worker virtual machine, using the second cryptographic key, the decrypted data of the first storage block ([0068], the storage management service 103′ requests encryption of the plaintext volume key based on the destination region client key or its functional equivalent and retrieves a destination region encrypted volume key 512 corresponding to the volume… the storage management service 103′ can achieve this by making an API call to the key management service 105 of the destination region 501 in accordance with an applicable policy for utilizing the destination region client key for encryption of the plain text volume key); and
storing, by the worker virtual machine, the encrypted data to the second storage block ([0068], the storage management service 103′ causes encrypted data 514′ corresponding to the snapshot 510′ to be copied from the source region 501′ to the destination region 501. The storage management service 103′ also provides the destination region encrypted volume key to the destination region 501, to be associated with the copied data 514′ and thereby form a snapshot 510 in the destination region; Examiner Note: Roth’s worker virtual machine (i.e. “key management service” provides keys to enable storage of the encrypted data to the destination storage block: [0077], a key management service 105 can manage client keys internally and provide a set of APIs for performing client key related operations such as encryption or decryption with respect to encrypted volume keys).
As per claim 4, Pappachan teaches, wherein the measurement comprises a hash of a memory image of the firmware ([0045], the computing device 100 verifies the attestation information for the firmware. The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel® or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code).
As per claim 6, Roth teaches, wherein each of the first cryptographic key and the second cryptographic key is based on at least one of: a location-dependent cryptographic key ([0017], The volume is associated with a volume key for encrypting or decrypting data specific to the volume in which the encrypted data will be stored. For example, plaintext data associated with a virtual machine instance attached to the volume is encrypted by a process running on the host computing device according to the volume key and converted into corresponding ciphertext, which can then be written to the physical space allocated for the volume) or a common cryptographic key shared by the source virtual machine and the destination virtual machine.
As per claim 7, Roth teaches, wherein the first storage block is mapped to a guest memory page of the source virtual machine and the second storage block is mapped to a guest memory page of the destination virtual machine ([0016], aspects of the present disclosure are directed to management of the encrypted data stored in volumes in conjunction with one or more virtual machine instances hosted by one or more physical computing devices; [0017], The storage management service can allocate physical space for the volume according to information included in the request (e.g., factors corresponding to size, location, performance, or the like) and generate related volume metadata (e.g., volume id, volume pointers or logical paths, volume interface parameters, or the like). The volume is associated with a volume key for encrypting or decrypting data specific to the volume in which the encrypted data will be stored; and [0036], the encryption component 124 may encrypt data to be written to logical volumes 202, 202′ or 202″, that are attached to their respective virtual machine instances 114, 114′ or 114″ based on corresponding volume keys available for use by the encryption component 124).
As per claim 9, this is the “system claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 10, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 11, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 12, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 14, this claim is similar to claim 6 and is rejected for the same reasons.
As per claim 15, this claim is similar to claim 7 and is rejected for the same reasons.
As per claim 16, this is the “non-transitory machine-readable storage medium claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 17, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 18, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 19, this claim is similar to claim 4 and is rejected for the same reasons.
Claims 5, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Roth-Pappachan as applied to independent claims 1, 9, and 16 and in further view of Sancheti et al. (US 20180113632).
As per claim 5, the combination of Roth-Pappachan fails to specifically teach, wherein the copying is performed in response detecting a modification of the first storage block, and wherein the modification is applied to the second storage block after the copying.
However, Sancheti teaches, wherein the copying is performed in response detecting a modification of the first storage block ([0268], the data can be copied from source to destination in an incremental fashion, such that only changed blocks are transmitted, and in some cases multiple incremental backups are consolidated at the source so that only the most current changed blocks are transmitted to and applied at the destination), and wherein the modification is applied to the second storage block after the copying ([0269], destination media agent(s) 244b write the received backup/secondary copy data to the destination secondary storage device(s) 208b).
The combination of Roth-Pappachan and Sancheti are analogous because they are each related to providing security in virtual environments. Roth teaches a method of copying data volumes attached to virtual machines from a source region to a destination region using encryption keys. Pappachan teaches a “trusted virtual machine” for key management and security in a virtualized environment including validation of a hypervisor using measurements. Sancheti teaches a method of secure virtual machine migration. (Abstract, Based on physical location data of the one or more virtual machines received from the host computing device, a storage manager can control the performance of a secondary copy operation on one or more storage units that store virtual machine data associated with the one or more virtual machines and/or the performance of a secondary copy operation on the one or more virtual machines;[0153], Backup operations can include full backups, differential backups, incremental backups, “synthetic full” backups, and/or creating a “reference copy;” and [0187], System 100 in some cases is configured to process data (e.g., files or other data objects, primary data 112, secondary copies 116, etc.), according to an appropriate encryption algorithm (e.g., Blowfish, Advanced Encryption Standard (AES), Triple Data Encryption Standard (3-DES), etc.) to limit access and provide data security). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the migration process of combination of Roth- Pappachan would be modified by “backup” mechanisms taught by Sancheti in order to backup modified storage blocks to secondary systems resulting in a system that facilitates virtual machine backups to secondary systems. Therefore, it would have been obvious to combine the teachings of the combination of Roth- Pappachan and Sancheti.
As per claim 13, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
As per claim 20, this claim is similar to claim 5 and is rejected for the same reasons. The same motivation used in the rejection of claim 5 is applicable to the instant claim.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Roth- Pappachan as applied to independent claim 1 and in further view of Noel et al. (US 20150052323).
As per claim 8, the combination of Roth- Pappachan fails to specifically teach, wherein the first identifier of the first storage block comprises a guest physical memory address of a deduplicated memory page and the copying reduplicates the deduplicated memory page.
However, Noel teaches, wherein the first identifier of the first storage block comprises a guest physical memory address of a deduplicated memory page and the copying reduplicates the deduplicated memory page ([0009], a migration agent may copy the state of the virtual machine being migrated, including a plurality of memory pages, from the origin host to the destination host while the virtual machine is still running at the origin host; and [0012], upon receiving de-duplicated contents of several virtual memory pages, a conventional hypervisor executed by the destination host computer system would create several physical memory pages storing duplicates of the contents and map a virtual memory page to each of the physical memory pages).
The combination of Roth-Pappachan and Noel are analogous because they are each related to providing security in virtual machine migration/copying. Roth teaches a method of copying data volumes attached to virtual machines from a source region to a destination region using encryption keys. Pappachan teaches a “trusted virtual machine” for key management and security in a virtualized environment including validation of a hypervisor using measurements. Noel teaches a method of virtual machine migration and copying of deduplicated memory. (Abstract, systems and methods for memory de-duplication in a virtual machine undergoing live migration; and [0012], upon receiving de-duplicated contents of several virtual memory pages, a conventional hypervisor executed by the destination host computer system would create several physical memory pages storing duplicates of the contents and map a virtual memory page to each of the physical memory pages). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the migration process of combination of Roth- Pappachan would be modified by the memory migration mechanism taught by Noel resulting in a system that improves memory management related to virtual machines undergoing a live migration by copying deduplicated memory pages only once at a destination host. (Noel, [0022], the amount of data to be transmitted over the network in a live migration of a virtual machine may be reduced by memory de-duplication. Origin hypervisor 115 may identify memory pages having identical contents and transmit the contents of duplicate memory pages to destination host computer system 120 only once). Therefore, it would have been obvious to combine the teachings of the combination of Roth-Pappachan and Noel.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
Tsirkin (US 20140215459): Discusses live virtual machine migration including copying source storage to a destination storage.
Applicant's amendment necessitated the new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A. HEADLY/
Examiner Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights