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 .
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.
DETAILED ACTION
This action is in response to applicant’s original submittal made on 02/07/2025. Claims 1-20 are cancelled. Claims 21-40 are new and pending.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21, 31 and 40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 15 of U.S. Patent No. 12,158,980 and 980’ hereinafter. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are drawn to the following:
(18931324) Claim 21: a processing system; andmemory comprising computer executable instructions that, when executed, perform operations comprising:encrypting, by a first hardware security module using a public transfer key, a cryptographic security key stored by the first hardware security module to generate an encrypted cryptographic security key, wherein the first hardware security module is executed by first processing circuitry;determining that a transfer condition has been met for transferring a virtual machine (VM) to second processing circuitry, wherein the VM is associated with a first virtual security module that is an instance of the first hardware security module, the first virtual security module having state data associated with the VM that includes a cryptographic storage key that encrypts data of a virtual disk of the VM, the state data describing a current execution of the first virtual security module and being encrypted with the cryptographic security key; andtransferring the VM to the second processing circuitry; maps to (980’) Claim 1 A method, performed by a computing system that includes first processing circuitry, a first hardware security module corresponding to the first processing circuitry, second processing circuitry, and a second hardware security module corresponding to the second processing circuitry, the method comprising: encrypting, by the first hardware security module using a public transfer key received from the second hardware security module, a cryptographic security key stored by the first hardware security module, wherein a private transfer key corresponding to the public transfer key is stored by the second hardware security module; providing the encrypted cryptographic security key to the second hardware security module; determining that a transfer condition has been met for transferring a virtual machine (VM) to be executed by the second processing circuitry, wherein the VM is associated with a first virtual security module that is an instance of the first hardware security module, the first virtual security module having state data associated with the VM that includes a cryptographic storage key that encrypts data of a virtual disk of the VM, the state data describing a current execution of the first virtual security module and being encrypted with the cryptographic security key; decrypting, by the second hardware security module and using the private transfer key, the encrypted cryptographic security key; decrypting the state data for the second virtual security module using the cryptographic security key; and executing the VM at the second processing circuitry using a second virtual security module that is an instance of the second hardware security module.
(18931324) Claim 31: and memory comprising computer executable instructions that, when executed, perform operations comprising: providing, by a first hardware security module, a public transfer key to a second hardware security module, wherein the first hardware security module is associated with a first virtual security module that is an instance of the first hardware security module; receiving, by the first hardware security module, an encrypted cryptographic security key from the second hardware security module; receiving, by the first hardware security module, from the second hardware security module: a virtual machine (VM); and encrypted state data for a second virtual security module that is an instance of the second hardware security module; decrypting, using a private transfer key, the encrypted cryptographic security key to generate a cryptographic security key; decrypting, using the cryptographic security key, the encrypted state data to generate state data; and executing the VM using the first virtual security module based on the state data; maps to (980’) Claim 15: a first hardware security module corresponding to the first processing circuitry, second processing circuitry, and a second hardware security module corresponding to the second processing circuitry, perform a method, the method comprising: encrypting, by the first hardware security module using a public transfer key received from the second hardware security module, a cryptographic security key stored by the first hardware security module, wherein a private transfer key corresponding to the public transfer key is stored by the second hardware security module; providing the encrypted cryptographic security key to the second hardware security module; determining that a transfer condition has been met for transferring a virtual machine (VM) to be executed by the second processing circuitry, wherein the VM is associated with a first virtual security module that is an instance of the first hardware security module, the first virtual security module having state data associated with the VM that includes a cryptographic storage key that encrypts data of a virtual disk of the VM, the state data describing a current execution of the first virtual security module and being encrypted with the cryptographic security key; and decrypting, by the second hardware security module and using the private transfer key, the encrypted cryptographic security key; decrypting the state data for the second virtual security module using the cryptographic security key and executing the VM at the second processing circuitry using a second virtual security module that is an instance of the second hardware security module.
(18931324) Claim 40: providing, by a first hardware security module, a public transfer key to a second hardware security module, wherein the first hardware security module is associated with a first virtual security module that is an instance of the first hardware security module; receiving, by the first hardware security module, an encrypted cryptographic security key from the second hardware security module; receiving, by the first hardware security module, from the second hardware security module: a virtual machine (VM); and encrypted state data for a second virtual security module that is an instance of the second hardware security module; decrypting, using a private transfer key, the encrypted cryptographic security key to generate a cryptographic security key; decrypting, using the cryptographic security key, the encrypted state data to generate state data; and executing the VM using the first virtual security module based on the state data; maps to (980’) Claim 15: a first hardware security module corresponding to the first processing circuitry, second processing circuitry, and a second hardware security module corresponding to the second processing circuitry, perform a method, the method comprising: encrypting, by the first hardware security module using a public transfer key received from the second hardware security module, a cryptographic security key stored by the first hardware security module, wherein a private transfer key corresponding to the public transfer key is stored by the second hardware security module; providing the encrypted cryptographic security key to the second hardware security module; determining that a transfer condition has been met for transferring a virtual machine (VM) to be executed by the second processing circuitry, wherein the VM is associated with a first virtual security module that is an instance of the first hardware security module, the first virtual security module having state data associated with the VM that includes a cryptographic storage key that encrypts data of a virtual disk of the VM, the state data describing a current execution of the first virtual security module and being encrypted with the cryptographic security key; and decrypting, by the second hardware security module and using the private transfer key, the encrypted cryptographic security key; decrypting the state data for the second virtual security module using the cryptographic security key and executing the VM at the second processing circuitry using a second virtual security module that is an instance of the second hardware security module.
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.
Claim(s) 21-30 are rejected under 35 U.S.C. 103 as being unpatentable over Scarlata (US Patent Publication No. 2007/0094719) in view of Challener et al. (US Patent Publication No. 2008/0244569 and Challener hereinafter).
As to claim 21, Scarlata teaches a system comprising: a processing system (i.e., …illustrates in figure 1 memory and a processor);
and memory comprising computer executable instructions that (i.e., …illustrates in figure 1 memory and a processor), when executed, perform operations comprising:
encrypting, by a first hardware security module using a public transfer key, a cryptographic security key stored by the first hardware security module to generate an encrypted cryptographic security key (i.e., …teaches in par. 0129 the following: “the wrapped key returned by the VTPM may be referred to as a VTPM double wrapped key.”),
wherein the first hardware security module is executed by first processing circuitry (i.e., …figure 6 figure element 30 illustrates a first hardware security module. …teaches in par. 0187 the following: “the basic mechanism for migration is that the PSS 112 in the VTPM framework of the source platform 20 transfers the state of a migratable VTPM to the PSS 412 in the destination platform 420. In destination platform 420,” …teaches in par. 0188 & 0189 the following: “Source platform 20 acquires the migration credential of destination platform 420, as indicated by arrow 2a. This credential can be exchanged at time of transfer, pre-exchanged, or provisioned in bulk by the environment owner. [0189] 2. Then, in source platform 20, VTPM manager 110 verifies (a) that the signature on the migration credential was created with a private key of the destination's VMA, and (b) that the destination's VMA is either the same as the source's VMA, or there exists a trust relationship between the source VMA and destination VMA. For instance, source platform 20 may keep a list of trusted VMAs, including VMAs with trust relationships, and source platform 20 may consult that list to determine whether the destination's VMA should be trusted.”.),
wherein the VM is associated with a first virtual security module that is an instance of the first hardware security module (i.e., …teaches in par. 0187 the following: “VTPM framework of the source platform 20”),
the first virtual security module having state data associated with the VM that includes a cryptographic storage key that encrypts data of a virtual disk of the VM (i.e., …teaches in par. 0189 the following: “source platform 20 then sends the newly encrypted VTPM state to destination platform 420.”),
the state data describing a current execution of the first virtual security module (i.e., …teaches in par. 00158 the following: “the state of a VTPM may include various keys, credentials, counters, etc. For purposes of this disclosure, generating a significant portion of the state data for a VTPM may be considered creating a VTPM.”)
and being encrypted with the cryptographic security key (i.e., …teaches in par. 0189 the following: “source platform 20 then sends the newly encrypted VTPM state to destination platform 420.”);
and transferring the VM to the second processing circuitry (i.e., …teaches in par. 0189 the following: “source platform 20 then sends the newly encrypted VTPM state to destination platform 420.
7. Source platform 20 then deletes the state for VTPM 44A from PSS 112, while destination platform 420 uses migration key 407 to decrypt the VTPM state, and uses PSS 412 to protect the VTPM state.”).
Scarlata does not expressly teach:
“determining that a transfer condition has been met for transferring a virtual machine (VM) to second processing circuitry”.
In this instance the examiner notes the teachings of prior art reference Challener.
Challener teaches in par. 0050 the following: “Migration processing commences at 710 when the hypervisor receives a request from another system (e.g., another hypervisor, another information handling system, etc.) to migrate a virtual machine that is running under the hypervisor. At step 715, the hypervisor receives the state of the requester (e.g., digest values). At step 720, the received state is compared to migration requirements stored in either the hardware based PCRs or the vTPM's virtual PCRs (vPCRs). A determination is made as to whether the requesting system meets the migration requirements (decision 725). If the requesting system meets the migration requirements, then decision 735 branches to "yes" branch 730 whereupon, at step 735, the virtual machine and the virtual machine's TPM (the vTPM) are packaged (encrypted) and transmitted to the requesting system. In one embodiment, the packaging is performed by using the public portion of the requesting system's Endorsement Key (EKpu). On the other hand, if the requesting system does not meet the migration requirements, then decision 725 branches to "no" branch 740 whereupon, at step 745 and error response is transmitted back to the requestor.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Scarlata with the teachings of Challener by having their system comprise an enhanced data migration process. One would have been motivated to do so to provide a simple and effective means to ensure proper migration of data, wherein the enhanced data migration process helps facilitate data access control within the network and makes it easier to ensure communication integrity.
As to claim 22, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein the first hardware security module receives the public transfer key from a second hardware security module associated with the second processing circuitry (i.e., …teaches in par. 0129 the following: “the wrapped key returned by a hardware TPM is a TCG_KEY structure containing the TPM version, PCR bindings, public key, encrypted private key, and other information that is returned to the requester.”).
As to claim 23, the system of Scarlata and Challener as applied to claim 22 above teaches virtual TPM, specifically Scarlata teaches a system of claim 22, wherein the second hardware security module stores a private transfer key corresponding to the public transfer key (i.e., …teaches in par. 0203 the following: “store its private keys in protected host memory”).
As to claim 24, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, the operations further comprising: providing the encrypted cryptographic security key to the second processing circuitry (i.e., …teaches in par. 0189 the following: “in source platform 20, VTPM manager 110 verifies (a) that the signature on the migration credential was created with a private key of the destination's VMA,”).
As to claim 25, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein the first hardware security module and the first virtual security module are managed by a first hypervisor implemented in a first computing environment comprising the first processing circuitry (i.e., …teaches in par. 0009 the following: “The VMs may be managed by virtualization products such as a virtual machine monitor (VMM) or hypervisor.”).
As to claim 26, the system of Scarlata and Challener as applied to claim 25 above teaches virtual TPM, specifically Scarlata teaches a system of claim 25, wherein the second processing circuitry is implemented in a second computing environment comprising a second hypervisor that manages a second hardware security module and a second virtual security module (i.e., …teaches in par. 0009 the following: “The VMs may be managed by virtualization products such as a virtual machine monitor (VMM) or hypervisor.”).
As to claim 27, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein the transfer condition corresponds to one of:a scheduled migration of the VM;a scheduled maintenance of the VM; or an unscheduled downtime of the VM (i.e., …teaches in par. 0036 the following: “the PSS authorizes and processes VTPM migrations under direction of a VTPM management authority.”).
As to claim 28, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein transferring the VM to the second processing circuitry causes the VM to be executed by the second processing circuitry (i.e., …teaches in par. 0189 the following: “destination platform 420 may load and use the migrated VTPM state like it would any other VTPM. For example, destination platform 420 may load and use the migrated state as a VTPM 444.”).
As to claim 29, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein the first hardware security module comprises a key generator that generates the cryptographic security key (i.e., …teaches in par. 0148 the following: “provisioner generates the new VTPM and all keys needed within the VTPM.”).
As to claim 30, the system of Scarlata and Challener as applied to claim 21 above teaches virtual TPM, specifically Scarlata teaches a system of claim 21, wherein the first hardware security module comprises a certificate associated with the public transfer key, wherein the certificate is validated by the first processing circuitry prior to encrypting the cryptographic security key (i.e.,…teaches in par. 0093 the following: “certification from VTPM factory 101 meaningful, VTPM factory 101 first convinces an external entity (e.g., an external CA) that the configuration of VTPM factory 101 is trustworthy and that the signing key of VTPM factory 101 is protected by a TPM. This external entity may be considered a virtual manufacturer certifying authority (VMCA) or a VTPM Management Authority (VMA) 79. In essence, VMA 79 is an entity trusted by privacy CAs to determine which VTPM environments are trustworthy enough to manufacture reliable virtual TPMs. The same entity can serve as the privacy CA and the VMA, or, as depicted in FIG. 1, privacy CA 76 and VMA 79 may be separate entities, with privacy CA 76 trusting VMA 79 to accurately assess VTPM frameworks and DMs.”).
Allowable Subject Matter
Independent claims 31 and 40 would be allowable if rewritten or amended to overcome the rejection(s) made under Double Patenting, set forth in this Office action. The applicant is advised that an approved Terminal Disclaimer will overcome the Double Patenting rejection.
The examiner notes that dependent claims 32-39 respectively depend on independent claim 31. and are rejected based on their dependency upon independent claim 31.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRYAN F WRIGHT/Examiner, Art Unit 2497