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 .
DETAILED ACTION
1. This action is in response to the amendment filed 10/12/2023.
2. Claims 1-20 have been examined and are pending in the application.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
3. Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Chandrashekar U.S Patent No. 12,282,540.
As to claim 1, Chandrashekar teaches an apparatus comprising:
a system interface (Programmatic interface 177, Fig. 1 and associated specifications) and
a device (Fig. 1 and associated specifications) comprising:
circuitry configured to:
based on attestation of the device (…The host at which the parent compute instance of an IRE is launched may comprise a physical hardware security device (such as a physical TPM) in at least some cases. If present, such a physical hardware security device may be used to verify the state of the virtualization host (e.g., the hardware of the virtualization host, as well as the software of the VMCs) prior to the launch of the compute instance used for the IRE in some embodiments. For example, messages containing log records of the host startup and the VMC startup, encrypted or signed using a cryptographic key of the physical hardware security device, may be sent to one or more external host resource verifiers or attesters…, lines 56-67 column 3), assignment of an emulated device to a trust domain, and attestation of a device configuration associated with the emulated device, provide trusted and secure access to the emulated device to a virtual execution environment (…For each compute instance launched at a given virtualization host or virtualization server, a set of emulated hardware devices is typically created as part of the initial configuration procedure for the compute instance by the VMCs of the virtualization host. Such a collection of emulated hardware devices may be referred to as a virtual motherboard, as it emulates at least a subset of the hardware devices that would typically be attached to a physical motherboard of the server used for the compute instance…, lines 41-49 column 3), wherein:
the device configuration is associated with one or more circuitry and software associated with the device (…as part of the initial configuration procedure for the compute instance by the VMCs of the virtualization host…, lines 43-45 column 3),
the emulated device is accessible via a device interface to the virtual execution environment (…VMCs 137 may include, for example, a hypervisor and/or an administrative virtual machine (which may run at a higher privilege level than the compute instances set up for VCS clients at the virtualization host). The VMCs may for example act as intermediaries between the compute instances 134 launched at the VHs and at least some of the hardware elements of the VHs…, lines 38-45 column 9), and
the device configuration comprises one or more of: register access, a network interface device, a storage controller, an accelerator, processor, or a memory device (…at least some of the hardware elements of the VHs, including for example physical processors (e.g., central processing units (CPUs), graphical processing units (GPUs), etc.), memory, persistent storage devices, networking cards, peripheral devices and the like…, lines 44-49 column 9).
As to claim 2, Chandrashekar further teaches the circuitry is to perform attestation and signing of an emulated device key and provide data based on the emulated device key for communications between the virtual execution environment and the emulated device (…Immutable cryptographic keys assigned to the emulated hardware security device at the time that the emulated device is initialized may, for example, be used to encrypt and/or sign messages containing identification information of the software to be verified, and the messages may be sent to external resource verifiers/attesters selected in advance by the VCS client on whose behalf the IRE was set up…, lines 6-12 column 4).
As to claim 3, Chandrashekar further teaches the circuitry is to provide a secure and trusted environment to perform: emulated device key generation, provisioning and/or generation of an attestation key, and signing of the emulated device key and the attestation key (…eHSM key sources 118 (which generate and/or provide unique immutable cryptography keys to each of the eHSMs 138)…, lines 10-12 column 10).
As to claim 4, Chandrashekar further teaches the circuitry is to execute trusted device firmware to: generate an attested quote based on one or more of: identifiers of the one or more circuitry and software associated with the device, first bootable device firmware, executable device firmware, device configuration, endpoint emulated device firmware, or endpoint emulated device configuration and assignments and verify the attested quote prior to provide trusted access to the emulated device to a virtual execution environment (…If present, such a physical hardware security device may be used to verify the state of the virtualization host (e.g., the hardware of the virtualization host, as well as the software of the VMCs) prior to the launch of the compute instance used for the IRE in some embodiments. For example, messages containing log records of the host startup and the VMC startup, encrypted or signed using a cryptographic key of the physical hardware security device, may be sent to one or more external host resource verifiers or attesters…, lines 58-67 column 3).
As to claim 5, Chandrashekar further teaches a memory device, wherein the circuitry is to cause the memory device to: store code, data, and context state for the emulated device in the TD associated with a tenant so that the code, data, and context state continue to be stored based on the TD associated with the tenant going offline and resuming emulated device state based on attestation of the emulated device and scheduling the TD and the attested emulated device for use (…such attestation may be performed when a parent compute instance is stopped/terminated/restarted/migrated, and/or when the virtualization host itself is restarted or rebooted. In at least one embodiment, a client may specify the set of operation types for which host and/or CI attestation is required - e.g., whether attestation is only required for initial launch of an IRE and migrations of the IRE, or whether attestation is required any time the host reboots, etc. In some embodiments, the VCS may support a programmatic interface that can be used for on-demand host or CI attestation - e.g., a client may request that the configuration of a virtualization host being used for the client be attested by an ARV at any desired point in time…, lines 50-62 column 13).
As to claim 6, Chandrashekar further teaches the device interface is consistent with Peripheral Component Interconnect express (PCIe) (…at least a portion of virtualization management responsibilities may be offloaded from the hypervisor to a hardware card (e.g., a card linked to the CPUs of the host via a Peripheral Connect Interface or PCI-Express interconnect)…, lines 49-53 column 9).
As to claim 7, Chandrashekar further teaches the device comprises one or more of: the network interface device, the storage controller, the accelerator, the processor, or the memory device (…at least some of the hardware elements of the VHs, including for example physical processors (e.g., central processing units (CPUs), graphical processing units (GPUs), etc.), memory, persistent storage devices, networking cards, peripheral devices and the like…, lines 44-49 column 9).
As to claim 8, Chandrashekar further teaches the emulated device comprises endpoint circuitry (…at least some of the hardware elements of the VHs, including for example physical processors (e.g., central processing units (CPUs), graphical processing units (GPUs), etc.), memory, persistent storage devices, networking cards, peripheral devices and the like…, lines 44-49 column 9).
As to claim 9, Chandrashekar further teaches the virtual execution environment comprises virtual machine (…A given software enclave or IRE may be linked to a compute instance or guest virtual machine via a secure communication channel, e.g., by virtualization management components (VMCs) of a virtualization host selected for the IRE by administrative components of a virtualized computing service (VCS). The VMCs may for example include a hypervisor and/or an administrative virtual machine…, lines 19-25 column 3).
As to claim 10, Chandrashekar further teaches a server, wherein the server communicatively coupled to the system interface and wherein the server is to execute the virtual execution environment to access the emulated device (…For each compute instance launched at a given virtualization host or virtualization server, a set of emulated hardware devices is typically created as part of the initial configuration procedure for the compute instance by the VMCs of the virtualization host. Such a collection of emulated hardware devices may be referred to as a virtual motherboard, as it emulates at least a subset of the hardware devices that would typically be attached to a physical motherboard of the server used for the compute instance…, lines 41-49 column 3).
As to claims 11-15, note the discussions of claims 1-2, 4-5 and 8 above, respectively.
As to claim 16, Chandrashekar further teaches the controller is attested at manufacture (…preparatory operations that may be performed prior to instantiating isolated runtime environments within compute instances whose software components' state is to be attested, according to at least some embodiments. Using programmatic interfaces 677 of VCS 620 (such as APIs, command-line tools, graphical user interfaces or a web-based console), a VCS client 610 may submit an ARV registration request in the depicted embodiment, e.g., indicating a network address of host attester 670, an automated resource verifier (ARV) selected by the client for virtualization host attestation. In scenarios in which different ARVs are going to be used for virtualization host attestation and for compute instance software stack attestation, respective registration requests may be sent for each type of ARV. Additional information required to secure communications with the ARV, such as a security key or credential, may also be provided in the registration request 601 in some embodiments. An ARV used for attesting host state may be referred to as a host attester, and an ARV used for attesting the compute instance software may be referred to as a CI software stack attester…, lines 14-34 column 20).
As to claim 17, note the discussions of claims 1 and 8 above.
As to claims 18-20, note the discussions of claims 1-2 and 4 above, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S Patent No. 7,222,062 discloses emulating a trusted platform module to execute trusted operations.
U.S Patent No. 12,309,294 discloses a clustered virtual trusted platform module domain services system.
U.S Publication No. 2011/0126268 discloses receiving a request for initial instantiation or reconnection of an emulated device with a virtual device and determining whether the emulated device and the virtual device are allowed to communicate based on the authorization record datastore.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andy Ho whose telephone number is (571) 272-3762. A voice mail service is also available for this number. The examiner can normally be reached on Monday – Friday, 8:30 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Kevin Young can be reached on (571) 270-3180.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is 571-272-2100.
Any response to this action should be mailed to:
Commissioner for Patents
P.O Box 1450
Alexandria, VA 22313-1450
Or fax to:
AFTER-FINAL faxes must be signed and sent to (571) 273 - 8300.
OFFICAL faxes must be signed and sent to (571) 273 - 8300.
NON OFFICAL faxes should not be signed, please send to (571) 273 – 3762
/Andy Ho/
Primary Examiner
Art Unit 2194
Prosecution Insights