DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/16/25 has been entered.
Response to Amendments
The amendment to claim 13 overcomes the 112(b) rejection issued in the final rejection.
Response to Arguments
Applicant’s arguments, see pages 10-12, filed on 10/16/25, with respect to the 103 rejection(s) of the amended claims have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lopez Pascual US 20230168911.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 3 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 3 recites “wherein the verifying further uses one or more second attestation reports of at least one of the one or more PPUs.” The verifying step in parent claim 1 recites, “the receiving being based at least on verifying one or more properties of the first TEE by at least one VM executing within the first TEE and one or more attestation reports of at least one of the one or more processors.” Claim 3 in view of claim appears to define that the one or more properties of the first TEE are verified using one or more second attestation reports of at least one of the one or more PPUs in addition to the one or more first attestation reports of at least one of the one or more processors. However, the relevant portions of the specification (para 40, 50 and 140) only disclose using the first attestation reports of the one or more processors and the second attestation reports of the one or more PPUs to verify the composite TEE, i.e., the combined trusted environment encompassing both the first and second TEE.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 3 recites the limitation “wherein the verifying further uses one or more second attestation reports of at least one of the one or more PPUs.” It is unclear whether the claim limitation defines the attestation reports of at least one of the one or more PPUs are used to verify one or more properties of the first TEE as recited in parent claim 1, or to be used for an undefined purpose.
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-8 and 10-20 are rejected under 103 as being unpatentable over Lal et al. US 20190311123 (hereinafter Lal ‘123) in view of Atamli et al. US 20230273808 (hereinafter Atamli ‘808) and Lopez Pascual US 20230168911 (Lopez Pascual ‘911).
As per claim 1, Lal ‘123 discloses a method comprising:
establishing one or more secure communication channels (para 0046, “In block 404, the TIO device 216 performs an authenticated key exchange protocol with the PA 204, such as an authenticated Diffie-Hellman key exchange. In block 406, the TIO device 216 receives one or more encryption keys that may be used for protecting control messages. Illustratively, the TIO device 216 and the PA 204 exchange a shared secret key K.sub.a. The TIO device 216 receives a provisioning key K.sub.p from the PA 204 that is wrapped by the key K.sub.a. As described further below, control messages may be protected by the provisioning key K.sub.p. In block 408, the TIO device 216 stores the encryption keys (e.g., K.sub.a and K.sub.p) in protected storage accessible to the TIO device 216. For example, the keys may be stored in private memory of the TIO device 216”; para 0065, “In some embodiments, in block 622 the PA 204 may securely provision one or more link encryption keys to the TIO device 216. The link encryption keys may be used to protect I/O data transferred to and/or from the TIO device 216 from certain hardware attacks.”)
between one or more virtual machines (VMs) executing within a first trusted execution environment (TEE) corresponding to one or more processors (fig. 2, reference no. 100, 204, 208a-b; para 0034, “The provisioning agent 204 may be embodied as a trusted execution environment or other trusted agent of the computing device 100”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O.”) and a second [TEE] corresponding to one or more parallel processing units (PPUs) (para 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”; para 0038, “Each TIO device 216 may be embodied as an I/O device capable of secure configuration and trusted I/O operations as described further below. For example, the TIO devices 216 may include one or more data storage devices 130, network interface controllers 132, accelerators 134…”; para 0051, “In some embodiments, in block 424 the TIO device 216 may enter or exit the TIO mode based on the configuration command. As described above, when operating in the TIO mode, the TIO device 216 may perform certain additional checks before processing configuration commands. In some embodiments, in block 426, the TIO device 216 may lock or unlock a configuration register identified in the configuration command. As described above, when a register is locked, commands to change that register may be allowed only from the PA 204”; para. 0078, “In block 814, the PA 204 commands the TIO device 216 to atomically release the global lock on the configuration registers and to set a fine-grained lock on one or more sensitive configuration registers. The fine-grained lock may be set on any registers that may impact trusted I/O if misconfigured. For example, the fine-grained lock may be set on one or more PCI base address registers (BARs) of the TIO device 216. As another example, the fine-grained lock may prevent privileged software from changing ACS settings for PCIe switches. As described above, the TIO device 216 verifies that the atomic unlock/lock command originated with the PA 204. Because the global lock is released and the fine-grained lock is set in one atomic operation, the device configuration of the TIO device 216 may not be changed before setting the fine-grained lock. After setting the fine-grained lock, the TIO device 216 will reject any changes to the locked registers that do not originate from the PA 204. Other configuration registers may be changed during trusted I/O by other entities, such as the TEE 208”; para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”);
receiving, using the one or more secure communication channels, data from the one or more virtual machines (VMs) executing within the first TEE corresponding to the one or more processors (para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”),
the receiving being based at least on verifying (para 0036, “The provisioning agent 204 may be further configured to perform an attestation protocol with the TIO device 216 to generate a device attestation report, verify the device attestation report, and securely provision the I/O device with the provisioning key in response to verifying the device attestation report. The provisioning agent 204 may be further configured to sign the device attestation report with a private key to generate a signed device attestation report, to include the signed device attestation report and a trusted agent attestation report in an attestation report; and to provide the combined attestation report to the TEE 208”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”; para. 0071, “As described further below in connection with FIG. 9, the TEE 208 (e.g., the paravirtualized guest device driver 212, the guest application 210, or other component of the TEE 208) may use the signed attestation report to verify both the PA 204 and the TIO device 216”; para 0072, “The request may be received after the PA 204 has attested and verified both the TEE 208…”); para 0089, “In block 920, the TEE 208 verifies the device configuration information and associated host configuration data. For example, the device configuration information may include one or more PCI base address registers (BARs) associated with the TIO device 216. The TEE 208 may verify that MMIO registers mapped by the VMM 214 into the guest address space of the TEE 208 match the device configuration information.”); and
processing the data within the second [TEE] corresponding to the one or more PPUs using the one or more PPUs (para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”; para 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”).
Lal ‘123 discloses a TIO device corresponding to the auxiliary device, whereby the TIO device can be configured by a provisioning agent to enter a trusted I/O mode. See para 0035. However, Lal ‘123 does not explicitly disclose, but Atamli ‘808 discloses a second trusted execution environment, and processing the received data within the second TEE (fig. 1, reference no. 132Z “Trusted Execution Environment”; para 0014, “The data processing performed by the auxiliary device may replace or supplement the data processing performed by the CPU of the host device. In one example, the auxiliary device may be represented by a Data Processing Unit (DPU) that uses hardware accelerators to process data that is in-use by the primary TEE and can store the processed data in a persistent storage device (e.g., Solid-state Storage Drive (SSD)).”; para 0029, “In other embodiments, auxiliary device 120Z may be or include one or more Infrastructure Processing Units (IPU), Smart Network Interface Controller (NIC), storage controller (e.g., Hard Drive Device (HDD) controller or Solid-State Storage Drive (SSD) controller), Tensor Processing Unit (TPU), Graphical Processing Units (GPUs)…”; para 0031, “In the example illustrated in FIG. 1, trusted computing base 130 may initially include the computing resources of trusted execution environment 132A (e.g., primary processor and main memory) and trusted computing base 130 may be expanded to include trusted communication link 134 and trusted execution environment 132Z (e.g., auxiliary processor and memory)”).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Lal ‘123 such that the auxiliary device includes a second TEE and the processing of received data is within the second TEE as taught by Atamli ‘808. One would have been motivated to do so to avoid compromising the security of the primary TEE by establishing a security environment within the auxiliary processing device that parallels the primary TEE. See Atamli ‘808, para. 0013.
Moreover, Atamli ‘808 further discloses performing a local attestation of the device implementing a TEE (para 0085, “Attestation module 512 may enable device 120 to perform an attestation to verify the integrity of device 120 (e.g., integrity of computing resources 520, operating system 126, and/or processor 122). Attestation may enable a trusting resource (e.g., program) to check the capabilities of a trusted resource (e.g., processor 122 of device 120) and to detect unauthorized changes to programs, hardware devices, other portions of computing device, or a combination thereof.”;
para 0086, “Local attestation may involve enabling a program executed locally on device 120 to verify the integrity of device 120.”;
para 0087, “Attestation data 515A-B may be based on the configuration of device 120 and may represent the capabilities of the computing resources, trusted execution environment, executable code, or a combination thereof.”;
Para 0088, “The program that receives the attestation data may use the attestation data to verify the capabilities of device 120. The program may execute a verification function to verify the device 120 in view of the attestation data. The verification function may take as input the attestation data and provide output that indicates whether the device 120 is verified (e.g., trusted). In one example, the attestation data may include integrity data (e.g., a message authentication code (MAC)) and the verification function may analyze a portion of attestation data to generate validation data. The verification function may then compare the received integrity data with the generated validation data to perform the attestation (e.g., compare received MAC with generate MAC).”
para 0089, “Attestation module 512 may perform operations before, during, or after trusted execution environment 132 is established on device 120 and may provide attestation data that is specific to the initiation, configuration, or execution of the trusted execution environment 132. In one example, attestation may involve performing a key exchange, establish hardware root of trust, and/or provide measurement and configuration values of trusted execution environment 132.”
However, neither Lal ‘123 nor Atamli et al. ‘808 disclose, but Lopez Pascual ‘911 discloses the receiving being based at least on verifying one or more properties of the first TEE by at least one VM executing within the first TEE and one or more attestation reports of at least one of the one or more processors (Para 0036, “Attestation module 210 may perform an attestation process that involves one or more local attestations, remote attestations, or a combination thereof. A local attestation may involve enabling a program executed locally on computing device 110A to verify the integrity of computing device 110A”; para 0076 “Virtual machines 114A-C may be unaware they are executing in a trusted execution environment because the TEE features can be provided by hardware processors at a lower level. However, the hardware platform (e.g., CPU) may provide an API with instructions that enable a virtual machine or program executed by the virtual machine to determine it is running in a trusted execution environment (e.g., see local attestation above)”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the invention of Lal ‘123 in view of Atamli et al. ‘808 such that the VM performs a local attestation of the computing device as taught by Lopez Pascual ‘911. By enabling the VM to verify the integrity and configuration of its execution environment, the VM does not need to rely on another process to verify the VM’s environment and can directly communicate these findings with a requesting entity.
As per claim 2, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). Lal ‘123 does not expressly disclose, but Atamli ‘808 discloses the method further comprising: decrypting, within the TEE corresponding to the one or more PPUs, the data received using the one or more secure communication channels to generate decrypted data; and storing the decrypted data in one or more protected memory regions of the TEE corresponding to the one or more PPUs, wherein the processing the data includes accessing the decrypted data from the one or more protected memory regions (Atamli ‘808, para 0035, “Transmitting data between trusted execution environments 132A and 132Z may involve one or more changes to the data encryption being used. In one example, the data may be encrypted using a first cryptographic technique (e.g., a first key) when stored in memory 124A, a second cryptographic technique when transmitted over trusted communication link 134 (e.g., a second key), and a third cryptographic technique when stored in memory 124Z (e.g., a third key). When switching between cryptographic techniques the data may be decrypted and then encrypted”; para 0071, “FIG. 4 depicts an example of a trusted execution environment 132 within a device 120, in accordance with an embodiment of the present disclosure. … In another example, device 120 may be the same as auxiliary device 120Z or 325 and trusted execution environment 132 may be the same as auxiliary trusted execution environment 132Z or TEE 426A-426B”; para 0074, “Memory 124 may be capable of storing data 146 associated with one or more of the computing constructs 433A-C. In one example, data of computing construct 433A may be received from a device that is internal or external to device 120. The data may be encrypted using a cryptographic key that was provided (e.g., determined, derived, generated, or assigned) by device 120 or by a different computing device. The received data may be decrypted using the same cryptographic key or a derivative of the cryptographic key and the decrypted data may be loaded into the trusted execution environment 132 (as shown by data 146) before, during or after being re-encrypted”; fig. 4, reference nos.132).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Lal ‘123 by storing the decrypted data within the TEE corresponding to the one or more PPUs as taught by Atamli ‘808. One would have been motivated to do so to improve processing efficiency within the PPU.
As per claim 3, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 2 (supra). In addition, Lal ‘123 discloses wherein the verifying further uses one or more second attestation reports of at least one of the one or more PPUs, the one or more second attestation reports being received from the second TEE over at least one of the one or more secure communication channels (Lal ‘123, para 0036, “The provisioning agent 204 may be further configured to perform an attestation protocol with the TIO device 216 to generate a device attestation report, verify the device attestation report, and securely provision the I/O device with the provisioning key in response to verifying the device attestation report. The provisioning agent 204 may be further configured to sign the device attestation report with a private key to generate a signed device attestation report, to include the signed device attestation report and a trusted agent attestation report in an attestation report; and to provide the combined attestation report to the TEE 208.”; para 0040, “ Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100. … Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O.”; para 0071, “In block 710, the PA 204 provides the combined, signed attestation report to the TEE 208. The PA 204 may provide the signed attestation report to the TEE 208 via the host device driver 206 or other components of the computing device 100. For example, the PA 204 may provide the signed report to the host device driver 206, which in turn may provide the response to the paravirtualized guest device driver 212 of the TEE 208. As described further below in connection with FIG. 9, the TEE 208 (e.g., the paravirtualized guest device driver 212, the guest application 210, or other component of the TEE 208) may use the signed attestation report to verify both the PA 204 and the TIO device 216. ”; para 0084, “In block 904, the TEE 208 requests attestation of a TIO device 216 from the provisioning agent (PA) 204.”; para 0085, “In response to the request, in block 906, the TEE 208 receives an attestation report from the PA 204. ”; para 0086, “In block 908, the TEE 208 verifies the attestation report.”).
As per claim 4, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). Lal ‘123 does not expressly disclose, but Atamli ‘808 and Lopez Pascual ‘911 disclose wherein the one or more attestation reports are generated and provided to the at least one VM by the one or more processors using at least one chain of trust rooted in the one or more processors (Atamli ‘808, para 0089, “In one example, attestation may involve performing a key exchange, establish hardware root of trust, and/or provide measurement and configuration values of trusted execution environment 132.”; Lopez Pascual ‘911, para 0076 “Virtual machines 114A-C may be unaware they are executing in a trusted execution environment because the TEE features can be provided by hardware processors at a lower level. However, the hardware platform (e.g., CPU) may provide an API with instructions that enable a virtual machine or program executed by the virtual machine to determine it is running in a trusted execution environment (e.g., see local attestation above)). It would have been obvious to one of ordinary skill in the art to modify the system of Lal ‘123 such that the VM verifies the integrity of the processors as taught by Lopez Pascual ‘911 to enable the VM to directly provide the result to a requesting entity; and moreover, to use a hardware chain of trust as taught by Atamli ‘808, to verify the hardware execution environment to ensure an immutable, tamper-resistant security that generally cannot be altered by executing software.
As per claim 5, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). In addition, Lal ‘123 discloses wherein the at least one VM includes at least one of the one or more VMs (para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”; para. 0085, “In response to the request, in block 906, the TEE 208 receives an attestation report from the PA 204. As described above, the attestation report may be received from the PA 204 via the host device driver 206 and the guest device driver 212. As also described above, the attestation report includes device attestation report information associated with the TIO device 216 as well as PA attestation report information associated with the PA 204”; para. 0086, “The TEE 208 may also verify the information included in the device attestation report (e.g., the type, manufacturer, firmware version, or other attributes of the TIO device 216)”).
Regarding claim 6, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 discloses the method of claim 1. In addition, Atamli ‘808 discloses wherein the receiving of the data is from one or more bounce buffers outside of the TEE corresponding to the one or more PPUs and the TEE corresponding to the one or more processors (para. 0049, “Data transfer module 222 may enable auxiliary device 120Z to send or receive data of the primary TEE over one or more of the trusted communication links. The data may be transferred to or from the host memory (e.g., main memory), host processor (e.g., CPU), other computing resource of the host device, or a combination thereof. The data of the primary TEE may be stored in a portion of host memory associated with the primary TEE and may or may not be copied to one or more data structures (e.g., queue or buffer) before being received by data transfer module 222. The data structures may be stored at a location that is internal to the primary TEE (e.g., in the enclave), external to the primary TEE (e.g., bounce buffer in host memory or auxiliary memory), other storage location, or a combination thereof.”).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Lal ‘123 such that data is received from one or more bounce buffers outside of the TEE as taught by Atamli ‘808. One would have been motivated to do so to bridge devices having different addressing capabilities as known to one of ordinary skill in the art.
As per claim 7, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 discloses the method of claim 1 (supra). In addition, Lal ’123 discloses wherein the one or more secure communication channels correspond to one or more interfaces, the one or more interfaces being provided to the one or more VMs using one or more hypervisors (para. 0033, “The VMM 214 may be embodied as any virtual machine monitor, hypervisor …”) external to the first TEE corresponding to the one or more processors and the second TEE corresponding to the one or more PPUs (para 0024, “the computing device 100 includes a virtual machine monitor (VMM) and one or more trusted execution environments (TEE). The VMM and the TEE do not mutually trust each other (e.g., the VMM is not included in the trusted computing base (TCB) of the TEE)”; para. 0042, “In interaction 306, the VMM 214 launches the TEE 208 and assigns the TIO device 216 to the TEE 208”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”; para. 0056, “In block 510, the VMM 214 manages requests issued between the TEE 208, the PA 204, and the physical TIO device 216. As described further below, the PA 204 and the TEE 208 may securely configure the TIO device 216 and then perform trusted I/O between the TEE 208 and the TIO device 216. During those interactions, the VMM 214 manages direct access to hardware such as the TIO devices 216. Commands between the TEE 208 and the PA 204 may be transferred or otherwise processed by components of the VMM 214, the host partition 202, and/or the host device driver 206. To maintain control over the TIO device 216, the VMM 214 may drop or otherwise deny commands that are submitted by the TEE 208 and/or the PA 204.”; para. 0074, “The VMM 214 retains the ability to approve or disapprove all configuration commands sent by the PA 204 to the TIO device 216. For example, the PA 204 may send configuration commands to the TIO device 216 via the host device driver 206, which in turn may access the TIO device 216 using the host partition 202 and/or the VMM 214”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”).
As per claim 8, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). In addition, Lal ‘123 discloses wherein the one or more properties correspond to one or more of: the one or more secure communication channels being encrypted, one or more hardware state configurations, one or more software state configurations, one or more fuse settings, one or more device modes, version information, code measurements, data measurements, or ordering of one or more of loading, launching, or booting of one or more elements (para. 0062, “As part of the attestation protocol, the PA 204 receives an attestation report from the TIO device 216 that includes one or more verifiable assertions such as the type, manufacturer, firmware version, or other attributes of the TIO device 216”).
As per claim 10, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). In addition, Lal ‘123 discloses wherein the one or more PPUs include one or more graphics processing units (GPUs) (para. 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU)…”) and the one or more processors include one or more central processing units (CPUs) (para. 0026, “The processor 120 may be embodied as any type of processor capable of performing the functions described herein. For example, the processor 120 may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit.”)
As per claim 11, Lal ‘123 discloses a system comprising:
one or more processors to perform operations (fig. 1, reference no. 120) including:
receiving, by one or more virtual machines (VMs) in a first trusted execution environment (TEE) corresponding to the one or more processors (fig. 2, reference no. 100, 204, 208a-b; para 0034, “The provisioning agent 204 may be embodied as a trusted execution environment or other trusted agent of the computing device 100”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”), access to one or more parallel processing units (PPUs) over one or more interfaces (fig. 3, reference no. 304, “ATTEST/PROVISION,” ref. no. 306 “LAUNCH/ASSIGN I/O”);
verifying (fig. 3, ref. no. 308, “ATTEST/VERIFY”; para 0036, “The provisioning agent 204 may be further configured to perform an attestation protocol with the TIO device 216 to generate a device attestation report, verify the device attestation report, and securely provision the I/O device with the provisioning key in response to verifying the device attestation report. The provisioning agent 204 may be further configured to sign the device attestation report with a private key to generate a signed device attestation report, to include the signed device attestation report and a trusted agent attestation report in an attestation report; and to provide the combined attestation report to the TEE 208”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”; para. 0071, “As described further below in connection with FIG. 9, the TEE 208 (e.g., the paravirtualized guest device driver 212, the guest application 210, or other component of the TEE 208) may use the signed attestation report to verify both the PA 204 and the TIO device 216”; para 0072, “The request may be received after the PA 204 has attested and verified both the TEE 208…”); para 0089, “In block 920, the TEE 208 verifies the device configuration information and associated host configuration data. For example, the device configuration information may include one or more PCI base address registers (BARs) associated with the TIO device 216. The TEE 208 may verify that MMIO registers mapped by the VMM 214 into the guest address space of the TEE 208 match the device configuration information.”);
encrypting, in the first TEE corresponding to the one or more processors, data associated with the one or more virtual machines (VMs) VMs to generate encrypted data (para 0046, “In block 404, the TIO device 216 performs an authenticated key exchange protocol with the PA 204, such as an authenticated Diffie-Hellman key exchange. In block 406, the TIO device 216 receives one or more encryption keys that may be used for protecting control messages. Illustratively, the TIO device 216 and the PA 204 exchange a shared secret key K.sub.a. The TIO device 216 receives a provisioning key K.sub.p from the PA 204 that is wrapped by the key K.sub.a. As described further below, control messages may be protected by the provisioning key K.sub.p. In block 408, the TIO device 216 stores the encryption keys (e.g., K.sub.a and K.sub.p) in protected storage accessible to the TIO device 216. For example, the keys may be stored in private memory of the TIO device 216”; para 0065, “In some embodiments, in block 622 the PA 204 may securely provision one or more link encryption keys to the TIO device 216. The link encryption keys may be used to protect I/O data transferred to and/or from the TIO device 216 from certain hardware attacks”; para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”);
providing, based at least on the verifying of the one or more properties, the encrypted data over the one or more interfaces to cause:
decryption of the encrypted data in a second [TEE] corresponding to the one or more PPUs to generate decrypted data (para 0099, “Performing trusted I/O may include securely transferring I/O data using a link encryption key (e.g., encrypting or decrypting the I/O data using the link encryption key)”); and
processing of the decrypted data in the second [TEE] corresponding to the one or more PPUs using the one or more PPUs (para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”; para 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”).
Furthermore, Lal ‘123 discloses a TIO device corresponding to the auxiliary device, whereby the TIO device can be configured by a provisioning agent to enter a trusted I/O mode. See para 0035. However, Lal ‘123 does not explicitly disclose, but Atamli ‘808 discloses a second trusted execution environment, and processing the decrypted data in a second TEE (fig. 1, reference no. 132Z “Trusted Execution Environment”; para 0014, “The data processing performed by the auxiliary device may replace or supplement the data processing performed by the CPU of the host device. In one example, the auxiliary device may be represented by a Data Processing Unit (DPU) that uses hardware accelerators to process data that is in-use by the primary TEE and can store the processed data in a persistent storage device (e.g., Solid-state Storage Drive (SSD)).”; para 0029, “In other embodiments, auxiliary device 120Z may be or include one or more Infrastructure Processing Units (IPU), Smart Network Interface Controller (NIC), storage controller (e.g., Hard Drive Device (HDD) controller or Solid-State Storage Drive (SSD) controller), Tensor Processing Unit (TPU), Graphical Processing Units (GPUs)…”; para 0031, “In the example illustrated in FIG. 1, trusted computing base 130 may initially include the computing resources of trusted execution environment 132A (e.g., primary processor and main memory) and trusted computing base 130 may be expanded to include trusted communication link 134 and trusted execution environment 132Z (e.g., auxiliary processor and memory)”; para 0035, “Transmitting data between trusted execution environments 132A and 132Z may involve one or more changes to the data encryption being used. In one example, the data may be encrypted using a first cryptographic technique (e.g., a first key) when stored in memory 124A, a second cryptographic technique when transmitted over trusted communication link 134 (e.g., a second key), and a third cryptographic technique when stored in memory 124Z (e.g., a third key). When switching between cryptographic techniques the data may be decrypted and then encrypted. In another example, the data that is stored in memory 124A may be encrypted using a cryptographic technique that is available to both trusted execution environments and can be accessed without changing the encryption.”).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Lal ‘123 such that the auxiliary device includes a second TEE and processing the decrypted data in the second TEE as taught by Atamli ‘808. One would have been motivated to do so to avoid compromising the security of the primary TEE by establishing a security environment within the auxiliary processing device that parallels the primary TEE. See Atamli ‘808, para. 0013.
Moreover, Atamli ‘808 further discloses performing a local attestation of the device implementing a TEE (para 0085, “Attestation module 512 may enable device 120 to perform an attestation to verify the integrity of device 120 (e.g., integrity of computing resources 520, operating system 126, and/or processor 122). Attestation may enable a trusting resource (e.g., program) to check the capabilities of a trusted resource (e.g., processor 122 of device 120) and to detect unauthorized changes to programs, hardware devices, other portions of computing device, or a combination thereof.”;
para 0086, “Local attestation may involve enabling a program executed locally on device 120 to verify the integrity of device 120. ”;
para 0087, “Attestation data 515A-B may be based on the configuration of device 120 and may represent the capabilities of the computing resources, trusted execution environment, executable code, or a combination thereof.”;
Para 0088, “The program that receives the attestation data may use the attestation data to verify the capabilities of device 120. The program may execute a verification function to verify the device 120 in view of the attestation data. The verification function may take as input the attestation data and provide output that indicates whether the device 120 is verified (e.g., trusted). In one example, the attestation data may include integrity data (e.g., a message authentication code (MAC)) and the verification function may analyze a portion of attestation data to generate validation data. The verification function may then compare the received integrity data with the generated validation data to perform the attestation (e.g., compare received MAC with generate MAC).”
para 0089, “Attestation module 512 may perform operations before, during, or after trusted execution environment 132 is established on device 120 and may provide attestation data that is specific to the initiation, configuration, or execution of the trusted execution environment 132. In one example, attestation may involve performing a key exchange, establish hardware root of trust, and/or provide measurement and configuration values of trusted execution environment 132.”
However, neither Lal ‘123 nor Atamli et al. ‘808 disclose, but Lopez Pascual ‘911 discloses verifying one or more properties of the first TEE by at least one VM executing within the first TEE and one or more attestation reports of at least one of the one or more processors (Para 0036, “Attestation module 210 may perform an attestation process that involves one or more local attestations, remote attestations, or a combination thereof. A local attestation may involve enabling a program executed locally on computing device 110A to verify the integrity of computing device 110A”; para 0076 “Virtual machines 114A-C may be unaware they are executing in a trusted execution environment because the TEE features can be provided by hardware processors at a lower level. However, the hardware platform (e.g., CPU) may provide an API with instructions that enable a virtual machine or program executed by the virtual machine to determine it is running in a trusted execution environment (e.g., see local attestation above)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the invention of Lal ‘123 in view of Atamli et al. ‘808 such that the VM performs a local attestation of the computing device as taught by Lopez Pascual ‘911. By enabling the VM to verify the integrity and configuration of its execution environment, the VM does not need to rely on another process to verify the VM’s environment and can directly communicate these findings with a requesting entity.
As per claim 12, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the system of claim 11 (supra). In addition, Lal ‘123 discloses wherein the access is provided using one or more hypervisors outside of the first TEE corresponding to the one or more processors, and encrypting is performed using one or more cryptographic keys that are inaccessible to the one or more hypervisors (para. 0033, “The VMM 214 may be embodied as any virtual machine monitor, hypervisor …”) external to the first TEE corresponding to the one or more processors and the second TEE corresponding to the one or more PPUs (para 0024, “the computing device 100 includes a virtual machine monitor (VMM) and one or more trusted execution environments (TEE). The VMM and the TEE do not mutually trust each other (e.g., the VMM is not included in the trusted computing base (TCB) of the TEE)”; para. 0042, “In interaction 306, the VMM 214 launches the TEE 208 and assigns the TIO device 216 to the TEE 208”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”; para. 0056, “In block 510, the VMM 214 manages requests issued between the TEE 208, the PA 204, and the physical TIO device 216. As described further below, the PA 204 and the TEE 208 may securely configure the TIO device 216 and then perform trusted I/O between the TEE 208 and the TIO device 216. During those interactions, the VMM 214 manages direct access to hardware such as the TIO devices 216. Commands between the TEE 208 and the PA 204 may be transferred or otherwise processed by components of the VMM 214, the host partition 202, and/or the host device driver 206. To maintain control over the TIO device 216, the VMM 214 may drop or otherwise deny commands that are submitted by the TEE 208 and/or the PA 204.”; para. 0074, “The VMM 214 retains the ability to approve or disapprove all configuration commands sent by the PA 204 to the TIO device 216. For example, the PA 204 may send configuration commands to the TIO device 216 via the host device driver 206, which in turn may access the TIO device 216 using the host partition 202 and/or the VMM 214”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”).
As per claim 13, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the system of claim 11 (supra). In addition, Lal ‘123 in view of Atamli ‘808 discloses wherein the operations further include: receiving in the first TEE corresponding to the one or more processors and over the one or more interfaces, one or more encrypted results corresponding to the processing of the decrypted data using the one or more PPUs; decrypting, in the first TEE corresponding to the one or more processors, the one or more encrypted results to generate one or more unencrypted results; and processing the one or more unencrypted results using the one or more VMs in the first TEE corresponding to the one or more processors (Lal ‘123, para 0024, “Referring now to FIG. 1, a computing device 100 for secure I/O with an accelerator device”; para. 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100”; para. 0064-65, “In block 618, the PA 204 provisions one or more encryption keys to the TIO device 216. As described above, those encryption keys may be used for protecting control messages issued by the PA 204 to the TIO device 216 and corresponding responses. The PA 204 may use any technique to securely provision the encryption keys. In some embodiments, in block 620 the PA 204 may perform an authenticated key exchange protocol with the TIO device 216, such as an authenticated Diffie-Hellman key exchange. Illustratively, the TIO device 216 and the PA 204 exchange a shared secret key K.sub.a. The PA 204 then wraps a provisioning key K.sub.p with the key K.sub.a and provides the wrapped provisioning key K.sub.p to the TIO device 216. As described above, control messages and responses may be integrity-protected using the provisioning key K.sub.p. … in block 622 the PA 204 may securely provision one or more link encryption keys to the TIO device 216. The link encryption keys may be used to protect I/O data transferred to and/or from the TIO device 216 from certain hardware attacks. The link encryption keys may be different from the provisioning key K.sub.p used to protect configuration commands”; para. 0099, “Performing trusted I/O may include securely transferring I/O data using a link encryption key (e.g., encrypting or decrypting the I/O data using the link encryption key)”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”; Atamli ‘808, para 0035, “Transmitting data between trusted execution environments 132A and 132Z may involve one or more changes to the data encryption being used. In one example, the data may be encrypted using a first cryptographic technique (e.g., a first key) when stored in memory 124A, a second cryptographic technique when transmitted over trusted communication link 134 (e.g., a second key), and a third cryptographic technique when stored in memory 124Z (e.g., a third key). When switching between cryptographic techniques the data may be decrypted and then encrypted. In another example, the data that is stored in memory 124A may be encrypted using a cryptographic technique that is available to both trusted execution environments and can be accessed without changing the encryption.”).
As per claim 14, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the system of claim 11 (supra). In addition, Lal ‘123 discloses wherein the system is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for 3D assets; a system for performing generative AI operations; a system for performing operations using a large language model; a system for performing deep learning operations; a system implemented using an edge device; a system implemented using a robot; a system for performing conversational AI operations; a system for generating synthetic data; a system for presenting at least one of virtual reality content, augmented reality content, or mixed reality content; a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources (para 0024, “The computing device 100 does not require that the VMM be within the TCB of the TEE and is thus suitable for datacenter use or other multi-tenant systems.”).
As per claim 15, Lal ‘123 discloses at least one processor comprising: one or more circuits to process data using one or more parallel processing units (PPUs) in a second [trusted execution environment (TEE)] corresponding to the one or more PPUs (para 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”; para 0038, “Each TIO device 216 may be embodied as an I/O device capable of secure configuration and trusted I/O operations as described further below. For example, the TIO devices 216 may include one or more data storage devices 130, network interface controllers 132, accelerators 134…”) based at least on:
receiving, using one or more secure communication channels between one or more virtual machines (VMs) executing within a first TEE corresponding to one or more processors and the second [TEE] corresponding to the one or more PPUs, data from the one or more virtual machines (VMs) (fig. 2, reference no. 100, 204, 208a-b; para 0034, “The provisioning agent 204 may be embodied as a trusted execution environment or other trusted agent of the computing device 100”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”; para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”),
the receiving being based at least on at least one VM executing within the first TEE verifying (para 0036, “The provisioning agent 204 may be further configured to perform an attestation protocol with the TIO device 216 to generate a device attestation report, verify the device attestation report, and securely provision the I/O device with the provisioning key in response to verifying the device attestation report. The provisioning agent 204 may be further configured to sign the device attestation report with a private key to generate a signed device attestation report, to include the signed device attestation report and a trusted agent attestation report in an attestation report; and to provide the combined attestation report to the TEE 208”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100… Each TEE 208 is configured to verify the attestation report received from the provisioning agent 204 and, in response, to request the provisioning agent 204 to prepare an assigned TIO device 216 for trusted I/O”; para. 0071, “As described further below in connection with FIG. 9, the TEE 208 (e.g., the paravirtualized guest device driver 212, the guest application 210, or other component of the TEE 208) may use the signed attestation report to verify both the PA 204 and the TIO device 216”; para 0072, “The request may be received after the PA 204 has attested and verified both the TEE 208…”); para 0089, “In block 920, the TEE 208 verifies the device configuration information and associated host configuration data. For example, the device configuration information may include one or more PCI base address registers (BARs) associated with the TIO device 216. The TEE 208 may verify that MMIO registers mapped by the VMM 214 into the guest address space of the TEE 208 match the device configuration information.”).
Lal ‘123 discloses a TIO device corresponding to the auxiliary device, whereby the TIO device can be configured by a provisioning agent to enter a trusted I/O mode. See para 0035. However, Lal ‘123 does not explicitly disclose, but Atamli ‘808 discloses a second trusted execution environment, and processing the received data within the second TEE (fig. 1, reference no. 132Z “Trusted Execution Environment”; para 0014, “The data processing performed by the auxiliary device may replace or supplement the data processing performed by the CPU of the host device. In one example, the auxiliary device may be represented by a Data Processing Unit (DPU) that uses hardware accelerators to process data that is in-use by the primary TEE and can store the processed data in a persistent storage device (e.g., Solid-state Storage Drive (SSD)).”; para 0029, “In other embodiments, auxiliary device 120Z may be or include one or more Infrastructure Processing Units (IPU), Smart Network Interface Controller (NIC), storage controller (e.g., Hard Drive Device (HDD) controller or Solid-State Storage Drive (SSD) controller), Tensor Processing Unit (TPU), Graphical Processing Units (GPUs)…”; para 0031, “In the example illustrated in FIG. 1, trusted computing base 130 may initially include the computing resources of trusted execution environment 132A (e.g., primary processor and main memory) and trusted computing base 130 may be expanded to include trusted communication link 134 and trusted execution environment 132Z (e.g., auxiliary processor and memory)”).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Lal ‘123 such that the auxiliary device includes a second TEE and the processing of received data is within the second TEE as taught by Atamli ‘808. One would have been motivated to do so to avoid compromising the security of the primary TEE by establishing a security environment within the auxiliary processing device that parallels the primary TEE. See Atamli ‘808, para. 0013.
Moreover, Atamli ‘808 further discloses performing a local attestation of the device implementing a TEE (para 0085, “Attestation module 512 may enable device 120 to perform an attestation to verify the integrity of device 120 (e.g., integrity of computing resources 520, operating system 126, and/or processor 122). Attestation may enable a trusting resource (e.g., program) to check the capabilities of a trusted resource (e.g., processor 122 of device 120) and to detect unauthorized changes to programs, hardware devices, other portions of computing device, or a combination thereof.”;
para 0086, “Local attestation may involve enabling a program executed locally on device 120 to verify the integrity of device 120.”;
para 0087, “Attestation data 515A-B may be based on the configuration of device 120 and may represent the capabilities of the computing resources, trusted execution environment, executable code, or a combination thereof.”;
Para 0088, “The program that receives the attestation data may use the attestation data to verify the capabilities of device 120. The program may execute a verification function to verify the device 120 in view of the attestation data. The verification function may take as input the attestation data and provide output that indicates whether the device 120 is verified (e.g., trusted). In one example, the attestation data may include integrity data (e.g., a message authentication code (MAC)) and the verification function may analyze a portion of attestation data to generate validation data. The verification function may then compare the received integrity data with the generated validation data to perform the attestation (e.g., compare received MAC with generate MAC).”;
para 0089, “Attestation module 512 may perform operations before, during, or after trusted execution environment 132 is established on device 120 and may provide attestation data that is specific to the initiation, configuration, or execution of the trusted execution environment 132. In one example, attestation may involve performing a key exchange, establish hardware root of trust, and/or provide measurement and configuration values of trusted execution environment 132.”
However, neither Lal ‘123 nor Atamli et al. ‘808 disclose, but Lopez Pascual ‘911 discloses the receiving being based at least on at least one VM executing within the first TEE verifying one or more properties of the first TEE using one or more attestation reports of at least one of the one or more processors (Para 0036, “Attestation module 210 may perform an attestation process that involves one or more local attestations, remote attestations, or a combination thereof. A local attestation may involve enabling a program executed locally on computing device 110A to verify the integrity of computing device 110A”; para 0076 “Virtual machines 114A-C may be unaware they are executing in a trusted execution environment because the TEE features can be provided by hardware processors at a lower level. However, the hardware platform (e.g., CPU) may provide an API with instructions that enable a virtual machine or program executed by the virtual machine to determine it is running in a trusted execution environment (e.g., see local attestation above)”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the invention of Lal ‘123 in view of Atamli et al. ‘808 such that the VM performs a local attestation of the computing device as taught by Lopez Pascual ‘911. By enabling the VM to verify the integrity and configuration of its execution environment, the VM does not need to rely on another process to verify the VM’s environment and can directly communicate these findings with a requesting entity.
As per claim 16, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the at least one processor of claim 15 (supra). In addition, Atamli ‘808 discloses wherein the data is accessed, for the processing, from one or more protected memory regions of the second TEE corresponding to the one or more PPUs (Atamli ‘808, para 0071, “FIG. 4 depicts an example of a trusted execution environment 132 within a device 120, in accordance with an embodiment of the present disclosure. … In another example, device 120 may be the same as auxiliary device 120Z or 325 and trusted execution environment 132 may be the same as auxiliary trusted execution environment 132Z or TEE 426A-426B”; para 0074, “Memory 124 may be capable of storing data 146 associated with one or more of the computing constructs 433A-C. In one example, data of computing construct 433A may be received from a device that is internal or external to device 120. The data may be encrypted using a cryptographic key that was provided (e.g., determined, derived, generated, or assigned) by device 120 or by a different computing device. The received data may be decrypted using the same cryptographic key or a derivative of the cryptographic key and the decrypted data may be loaded into the trusted execution environment 132 (as shown by data 146) before, during or after being re-encrypted”; fig. 4, reference nos.132).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Lal ‘123 by storing the decrypted data within the TEE corresponding to the one or more PPUs as taught by Atamli ‘808. One would have been motivated to do so to improve processing efficiency within the PPU.
As per claim 17, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the at least one processor of claim 15 (supra). In addition, Lal ‘123 discloses wherein the data is received using one or more secure processors corresponding to the one or more PPUs (para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”; para 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”).
As per claim 18, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the at least one processor of claim 15 (supra). In addition, Lal ‘123 discloses wherein the one or more secure communication channels correspond to one or more interfaces, the one or more interfaces being provided to the one or more VMs using one or more hypervisors external to the first TEE corresponding to the one or more processors and the second TEE corresponding to the one or more PPUs (para. 0033, “The VMM 214 may be embodied as any virtual machine monitor, hypervisor …”; para 0024, “the computing device 100 includes a virtual machine monitor (VMM) and one or more trusted execution environments (TEE). The VMM and the TEE do not mutually trust each other (e.g., the VMM is not included in the trusted computing base (TCB) of the TEE)”; para. 0042, “In interaction 306, the VMM 214 launches the TEE 208 and assigns the TIO device 216 to the TEE 208”; para. 0056, “In block 510, the VMM 214 manages requests issued between the TEE 208, the PA 204, and the physical TIO device 216. As described further below, the PA 204 and the TEE 208 may securely configure the TIO device 216 and then perform trusted I/O between the TEE 208 and the TIO device 216. During those interactions, the VMM 214 manages direct access to hardware such as the TIO devices 216. Commands between the TEE 208 and the PA 204 may be transferred or otherwise processed by components of the VMM 214, the host partition 202, and/or the host device driver 206. To maintain control over the TIO device 216, the VMM 214 may drop or otherwise deny commands that are submitted by the TEE 208 and/or the PA 204.”; para. 0074, “The VMM 214 retains the ability to approve or disapprove all configuration commands sent by the PA 204 to the TIO device 216. For example, the PA 204 may send configuration commands to the TIO device 216 via the host device driver 206, which in turn may access the TIO device 216 using the host partition 202 and/or the VMM 214”; para. 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys”).
As per claim 19, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the at least one processor of claim 15 (supra). In addition, Lal ‘123 discloses further comprising providing one or more results of the processing to the one or more virtual machines (VMs) using the one or more secure communication channels (para 0024, “Referring now to FIG. 1, a computing device 100 for secure I/O with an accelerator device”; para. 0030, “The accelerator 134 may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processor unit (GPU), a coprocessor, an I/O device, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions)”; para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100”; para. 0064-65, “In block 618, the PA 204 provisions one or more encryption keys to the TIO device 216. As described above, those encryption keys may be used for protecting control messages issued by the PA 204 to the TIO device 216 and corresponding responses. The PA 204 may use any technique to securely provision the encryption keys. In some embodiments, in block 620 the PA 204 may perform an authenticated key exchange protocol with the TIO device 216, such as an authenticated Diffie-Hellman key exchange. Illustratively, the TIO device 216 and the PA 204 exchange a shared secret key K.sub.a. The PA 204 then wraps a provisioning key K.sub.p with the key K.sub.a and provides the wrapped provisioning key K.sub.p to the TIO device 216. As described above, control messages and responses may be integrity-protected using the provisioning key K.sub.p. … in block 622 the PA 204 may securely provision one or more link encryption keys to the TIO device 216. The link encryption keys may be used to protect I/O data transferred to and/or from the TIO device 216 from certain hardware attacks. The link encryption keys may be different from the provisioning key K.sub.p used to protect configuration commands”; para. 0099, “Performing trusted I/O may include securely transferring I/O data using a link encryption key (e.g., encrypting or decrypting the I/O data using the link encryption key)”).
As per claim 20, Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 disclose the at least one processor of claim 15 (supra). In addition, Lal ‘123 discloses wherein the processor is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for 3D assets; a system for performing generative AI operations; a system for performing operations using a large language model; a system for performing deep learning operations; a system implemented using an edge device; a system implemented using a robot; a system for performing conversational AI operations; a system for generating synthetic data; a system for presenting at least one of virtual reality content, augmented reality content, or mixed reality content; a system incorporating one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources (para 0024, “The computing device 100 does not require that the VMM be within the TCB of the TEE and is thus suitable for datacenter use or other multi-tenant systems.”).
Claim 9 is rejected under 103 as being unpatentable over Lal ‘123 in view of Atamli ‘808 and Lopez Pascual ‘911, and further in view of Li et al. US 20200220713 (hereinafter Li ‘713).
As per claim 9, Lal ‘123 in view of Atamli ‘808 and Lopez Pascual ‘911 disclose the method of claim 1 (supra). In addition, Lal ‘123 in view of Atamli ‘808 discloses wherein the one or more VMs establish the one or more secure communication channels using one or more cryptographic keys, the one or more cryptographic keys being (Lal ‘123, “para 0040, “Each of the TEEs 208 may be embodied as a trust domain, virtual machine, virtual network function (VNF), guest operating system, or other trusted environment of the computing device 100”; para 0091, “In block 926, the TEE 208 performs trusted I/O operations with the TIO device 216. The TEE 208 (e.g., the guest device driver 212) may program one or more direct memory access (DMA) registers of the TIO device 216 and cause the TIO device 216 to perform TIO operations. Data transferred by the TIO operations may be protected from software and/or hardware attacks. For example, the TEE 208 and the TIO device 216 may encrypt or otherwise protected transferred I/O data with one or more link keys or other encryption keys.”; Atamli ‘880, para 0035, “Transmitting data between trusted execution environments 132A and 132Z may involve one or more changes to the data encryption being used. In one example, the data may be encrypted using a first cryptographic technique (e.g., a first key) when stored in memory 124A, a second cryptographic technique when transmitted over trusted communication link 134 (e.g., a second key), and a third cryptographic technique when stored in memory 124Z (e.g., a third key). When switching between cryptographic techniques the data may be decrypted and then encrypted. In another example, the data that is stored in memory 124A may be encrypted using a cryptographic technique that is available to both trusted execution environments and can be accessed without changing the encryption.”; para 0038, “Trusted execution environments 132A-Z can each have the same or different levels of granularity and protect a respective computing construct 133A-Z. The level of granularity of a TEE can depend on the computing construct that is being protected can be a Virtual Machine (VM), a container, a process, a thread, other stream of execution, or a combination thereof. A trusted execution environment for executing and protecting a VM may be referred to as Trusted Virtual Machine (TVM)”; para 0047, “The set of trusted communication links may include a link between the primary TEE and an intermediate computing resource (e.g., device interface) and a link between the intermediate computing resource and the auxiliary TEE. In either example, the one or more trusted communication links can be initiated by the primary processor, auxiliary processor, primary TEE, auxiliary TEE, other computing resource, or a combination thereof.”).
Lal ‘123 in view of Atamli ‘808 and Lopez Pascual ‘911 do not disclose, but Li ‘713 discloses the one or more cryptographic keys being generated and maintained within the first TEE (Para 0053, “At 214, the TEE component 128 may generate a symmetric cryptographic key (sometimes referred to as “s-n key”) and/or send the symmetric cryptographic key to the component(s) 124. In examples, the symmetric cryptographic key (s-n key) may be a randomly generated key. Further, in examples, the symmetric cryptographic key (s-n key) may be encrypted using the public cryptographic key (NIC_public_key), and then, sent to the component(s) 124. In examples, such use of the public cryptographic key (NIC_public_key) may facilitate a first secure communication channel. In examples, the first secure communication channel is associated with an asymmetric key (RSA) encryption. Here, once a second secure communication channel is established as discussed below, the TEE component 128 and the component(s) 124 no longer use the first secure communication channel because the asymmetric key (RSA) based secure channel may have a larger computing overhead as opposed to symmetric key based secure channel (which may be used for the second secure communication channel established between the TEE component 128 and the component(s) 124)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the invention of Lal ‘123 in view of Atamli et al. ‘808 and Lopez Pascual ‘911 such that the cryptographic keys are generated and maintained within the first TEE. One would have been motivated to do so to avoid exposing the keys outside the trusted environments.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNG W KIM whose telephone number is (571)272-3804. The examiner can normally be reached Monday-Friday, 10 a.m. - 6 p.m..
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, Amy Cohen Johnson can be reached at 271-272-2238. 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.
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494