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 .
Claims 1, 2, 4-6, 10, 12, 15, 17, and 19 have currently been amended. No claims have been canceled. No claims have been newly added. Claims 1-10 and 12-21 are currently pending for examination. A claim 11 has not been presented.
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 5/27/2026 has been entered.
Response to Arguments
As per applicant’s arguments, pgs.11-14, that the cited prior art of record does not disclose the following amended limitation of the independent claims : "configuring ... one or more memory management units (MMUs) of the PPU to use one or more hardware firewalls to isolate internal memory paths of a memory system of the PPU that are respectively assigned to the plurality of instances of the PPU, based at least on verifying, for a memory access request, one or more address translations performed using one or more virtual MMUs (VMMUs) fall within one or more partitioned memory boundaries assigned to a PPU instance of the plurality of instances that corresponds to the memory access request" and "transmitting data received from the second TEE ..., the transmitting causing the one or more hardware firewalls to perform the verifying in response to the memory access request being generated by the data being processed within the first TEE using the PPU instance”, the examiner has carefully considered these arguments and concedes. Neither Pappachan, Jain, nor Harty discloses a hardware firewall verifying that an address generated by a virtual MMU falls within a partitioned memory boundary. However, in an updated search and consideration it was found that Hong (US 20180129525 A1) discloses these limitations. Harty is no longer relied upon to disclose the hardware firewall. As such, the amended independent claims are maintained to be rejected under 35 USC 103.
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-2, 4, 7-8, 10, 12, 14, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain (US 20220188386 A1) in further view of Hong (US 20180129525 A1).
As per claim 1, Pappachan discloses:
A method comprising: configuring for a first trusted execution environment (TEE) corresponding to one or more parallel processing unit (PPU) instances of a plurality of instances of a PPU ("Certain secure processing requires the user of a trusted execution environment (TEE), such as trusted domains (TDs) in Trusted Domain Extensions (TDX) technology, where TDX is a TEE for virtual machines running in virtualized environments ", 0003 ; “In some embodiments, the computing device 600 includes one or more processors including one or more processors cores and a TEE 614 to enable maintenance of security of data, as TEE 212 in FIG. 2 or TEE 412 in FIG. 4.”, 0067 ; Examiner Note: The processors (610) of figure 6 equate to parallel processors with multiple cores (612), and the trusted execution environments for the virtual machines are necessarily configured)
providing, to a second TEE corresponding to one or more computing devices, access to the one or more PPU instances using one or more virtual interfaces corresponding to one or more physical interfaces to the PPU (“A GPU trusted agent (GTA) may include, but is not limited to, a trusted security controller that can attest to its firmware measurement. The GTA may be viewed as an analog of the host's trusted agent for TDX (SEAM). In some embodiments, the GTA is to ensure proper allocation/deallocation of GPU local memory to various virtual functions (VFs—referring to virtual functions within a GPU device) assigned to trusted domains (TDs)”, 0024 ; “In some embodiments, an apparatus, system, or process is to utilize GPU memory resources in a trusted manner, while preserving the role of the KMD as the manager of those resources.”, 0017 ; “In some embodiments, an encryption engine supporting multiple keys, such as Multi-Key Total Memory Encryption Engine (MKTME), is implemented to enable to the separation of workloads for security purposes. The technology supports confidentiality and integrity (such as MKTME used for TDX). “, 0026 ; “For convenience, the processor cores 612, the graphics processor circuitry 630, the wireless I/O interface 644, the wired I/O interface 646, the storage device 642, and the network interface 648 are illustrated as communicatively coupled to each other via the bus 616, thereby providing connectivity between the above-described components.”, 0081 ; see fig.6 ; Examiner Note: the GPU with a trusted agent and MKTME equates to a second TEE, and has access to the cores (612) of the PPU (processors-610) )
Pappachan discloses the above limitations of claim 1, but does not explicitly disclose the interfaces being virtual, nor disclose the transmission of data between TEEs, or the transmission of data to a TEE resulting in the data being processed by the TEE using a PPU.
However, Jain discloses:
transmitting data received from the second TEE corresponding to the one or more computing devices using the one or more virtual interfaces ("The SiL system may include a secured environment or secured area within a processor (e.g., a trusted execution environment or “TEE”) to provide a high level of trust, including security and privacy, when executing simulation code, executing code or accessing data within models, or executing code or transmitting data between models. ", 0023 ; ". For instance, the security and communication protections may be applied to data provided as inputs or parameters to the simulation and data exchanged between the models (e.g., between sensor model 206 and ECU model 212) over the secure virtual communication bus 222.", 0028 ; “The decrypted secured model may then be executed within the one or more TEEs. The at least one secured model may be operable to process incoming data and outgoing data.”, 0003 ; Examiner Note: the models, which are executed within trusted execution environments, equate to trusted execution environments.)
transmitting causing processing of the data within the first TEE using the one or more PPU instances and the one or more hardware firewalls ("For instance, the security and communication protections may be applied to data provided as inputs or parameters to the simulation and data exchanged between the models (e.g., between sensor model 206 and ECU model 212) over the secure virtual communication bus 222. The security and communication protections can be achieved by encrypting the transmitted data with keys that are available only to the TEEs that operate on, or use, the data.", 0028 ; "Or, it is also contemplated the TEE may be implemented using a combination of TEE and field programmable gate array (FPGA), a FPGA alone, or even one or more application specific integrated circuits (ASIC) or processors such as graphic processing units (GPUs)", 0023)
The system of Pappachan in view of Jain would be capable of processing the data which was received in the first TEE using the one or more PPUs associated with that TEE (Pappachan, [0003]). It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the systems of Pappachan and Jain in order to achieve a higher level of security and communication protections between TEEs and other computing components of the system (Jain, [0028]).
Pappachan in view of Jain discloses the above limitations of claim 1, but does not disclose a hardware firewall which isolates internal memory paths.
However, Hong discloses:
one or more memory management units (MMUs) of the PPU to use one or more hardware firewalls to isolate internal memory paths of a memory system of the PPU that are respectively assigned to the plurality of instances of the PPU, based at least on verifying, for a memory access request, one or more address translations performed using one or more virtual MMUs (VMMUs) fall within one or more partitioned memory boundaries assigned to a PPU instance of the plurality of instances that corresponds to the memory access request (“To ensure isolation between normal virtual machine group 110 and privilege virtual machine group 130, hypervisor 150 may control the accesses for hardware 170 requested by normal virtual machine group 110 and privilege virtual machine group 130. In some example embodiments, hypervisor 150 may selectively block a hardware access request generated in normal virtual machine group 110 (e.g., by using a hardware firewall 400 of FIG. 4) such that at least one hardware resource allocated only to privilege virtual machine group 130 is not accessed by normal virtual machine group 110. “, 0029 ; “However, in computing system 200 according to example embodiments, the normal virtual machine group (or normal virtual machines) and the privilege virtual machine group (or privilege virtual machines) manage intermediate physical address spaces that are the same as an actual physical address space of memory device 240. Accordingly, the hypervisor may use the intermediate physical address as an actual physical address of memory device 240 without the address translation for the intermediate physical address, and the hypervisor may control STG2 MMU 214 and hardware firewalls 260 and 270 to check only whether each virtual machine group (or each virtual machine) is permitted to access a physical page of memory device 240 having the physical address. For example, the hypervisor may perform an access permission check on an access request output from processor 210 by using the STG2 MMU 214, may perform an access permission check on an access request output from device 220 by using hardware firewall 260, and may perform an access permission check on an access request output from device 230 by using hardware firewall 270.”, 0040 ; “Devices 220 and 230 may include a graphics processing unit (GPU) and/or a non-GPU 230. For example, non-GPU 230 may include a hardware accelerator, a display device, an external subsystem, etc. In some example embodiments, devices 220 and 230 may include STG1 MMUs 222 and 232, respectively.”, 0036 ; Examiner Note: a physical page allocated only to a privileged virtual machine group equates to a memory partition. A virtual machine group of a GPU equates to an instance of a PPU.
transmitting causing the one or more hardware firewalls to perform the verifying in response to the memory access request being generated by the data being processed within the first TEE using the one or more PPU instances and the one or more hardware firewalls PPU instance. (“In some example embodiments, hypervisor 150 may selectively block a hardware access request generated in normal virtual machine group 110 (e.g., by using a hardware firewall 400 of FIG. 4) such that at least one hardware resource allocated only to privilege virtual machine group 130 is not accessed by normal virtual machine group 110.“, 0029 ; “According to example embodiments, a computing system includes a processor, and provides a rice execution environment (REE) and a trusted execution environment (TEE).”, 0007 ; “Thus, as illustrated in FIG. 6C, in a case where hardware firewall 400 includes normal access rule table 610 and privilege access rule table 620 illustrated in FIGS. 6A and 6B, hardware firewall 400 may not block read and write access requests for ‘page X’ 640 and a write access request for ‘page Y’ 650 from the normal virtual machine group NVMG.”, 0051 ; Examiner Note: it is inherent that a memory write request is generated by data being processed. The privileged virtual machine group operates within a TEE.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain with the hardware firewall and virtual MMUs of Hong in order to more reliably prevent data of a secure application executed in a privileged virtual machine group, or TEE, from being leaked to a normal virtual machine group (Hong, [0042]).
As per claim 2, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1.
Furthermore, Pappachan discloses:
internal memory paths of the memory system are respectively assigned to the plurality of instances of the PPU by a graphics processing unit (GPU) hypervisor of the PPU, and the plurality of instances directly access assigned memory resources using the internal memory paths ("The memory 220 includes local memory 232 for the GPU 230. The local memory 232 is partitioned into a plurality of protection regions, wherein the protection regions may include a hidden region 234, a protected region 236, and an unprotected region 238.”, 0043 ; “In some embodiments, the GPU 230 include a GPU trusted agent (GTA) 240 to ensure proper allocation/deallocation of GPU local memory to various virtual functions assigned to trusted domains and verify that the translation from device guest physical address (GPA) to device physical address (PA) is correct.”, 0044 ; Examiner Note: as a trusted agent is a feature of the hypervisor, the GTA performing allocation equates to the GPU hypervisor assigning memory paths
As per claim 7, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1.
Furthermore, Pappachan discloses:
providing, to a third TEE corresponding to the one or more computing devices, access to one or more second PPU instances of the plurality of instances using one or more second virtual interfaces corresponding to the one or more physical interfaces to the PPU (“Operations may include virtualized GPU operations in which multiple secure containers for GPU compute kernel execution may be implemented.”, 0002 ; “The processor cores 612 may include any number, type, or combination of currently available or future developed devices capable of executing machine-readable instruction sets. The processor cores 612 may include (or be coupled to) but are not limited to any current or future developed single- or multi-core processor or microprocessor, such as: on or more systems on a chip (SOCs); central processing units (CPUs); digital signal processors (DSPs); graphics processing units (GPUs)", 0073 ; see fig.6 ; Examiner Note: the multiple secure containers for GPU compute kernel execution comprise a third TEE, and are provided the same access to the PPUs)
Pappachan discloses the above limitations of claim 7, but does not disclose the transmission of data from a third TEE using a second virtual interface, or the transmission of this data causing the second TEE to process the data using a second PPU instance.
However, Jain discloses:
transmitting second data received from the third TEE corresponding to the one or more computing devices using the one or more second virtual interfaces, the transmitting causing processing of the second data within a second TEE corresponding to the one or more second PPU instances using the one or more second PPU instances ("The SiL system may include a secured environment or secured area within a processor (e.g., a trusted execution environment or “TEE”) to provide a high level of trust, including security and privacy, when executing simulation code, executing code or accessing data within models, or executing code or transmitting data between models. ", 0023 ; ". For instance, the security and communication protections may be applied to data provided as inputs or parameters to the simulation and data exchanged between the models (e.g., between sensor model 206 and ECU model 212) over the secure virtual communication bus 222.", 0028 ; "The decrypted secured model may then be executed within the one or more TEEs.", 0003 ; "For instance, the security and communication protections may be applied to data provided as inputs or parameters to the simulation and data exchanged between the models (e.g., between sensor model 206 and ECU model 212) over the secure virtual communication bus 222. The security and communication protections can be achieved by encrypting the transmitted data with keys that are available only to the TEEs that operate on, or use, the data.", 0028 ; "Or, it is also contemplated the TEE may be implemented using a combination of TEE and field programmable gate array (FPGA), a FPGA alone, or even one or more application specific integrated circuits (ASIC) or processors such as graphic processing units (GPUs)", 0023 ; Examiner Note: the virtual bus provides a first interface between the first two models, and a second virtual interface between the second and third models (see fig.2))
The system of Pappachan in view of Jain in further view of Hong would be capable of processing a second data which was received in the second TEE using a second PPU.
As per claim 8, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1.
Furthermore, Pappachan discloses:
based at least on providing access to the one or more PPU instances to the second TEE, revoking, from an instance manager used in the configuring the first TEE, access to the one or more PPU instances ("The GMPT may be viewed as the analog of the physical address metadata table (PAMT) on the host side for TDX (Trusted Domain Extensions). The table is maintained by the GTA. Each physical page in local memory that is allocated to a VF assigned to a TD has an entry in the GMPT. Each entry in the GMPT records a VF # (virtual function number), a device GPA that maps to the VF, and attributes such as access permissions (RWX (Read Write Execution)). The entry is created when a physical page is allocated to a VF (assigned to a TD) and invalidated when the physical page is deallocated", 0036 ; ”The GTA then uses the GMPT to ensure that the page has not been allocated elsewhere and the mapping is performed correctly (i.e., there is no remapping across different contexts or many-to-one mapping inside of a context).”, 0040 ; "A GPU trusted agent (GTA) may include, but is not limited to, a trusted security controller that can attest to its firmware measurement. The GTA may be viewed as an analog of the host's trusted agent for TDX (SEAM). In some embodiments, the GTA is to ensure proper allocation/deallocation of GPU local memory to various virtual functions (VFs—referring to virtual functions within a GPU device) assigned to trusted domains (TDs) and verify that the translation from device guest physical address (GPA) to device physical address (PA) is correct.", 0024 ; Examiner Note: The VFs running on the processors equate to PPU instances. The GPU trusted agent, or GTA, equates to an instance manager configuring the memory access of the first TEE. Invalidating the entry in the GPU memory permission table, or GMPT, equates to revoking access of the TEE to the PPU)
As per claim 10, it is a system claim comprised of substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
As per claim 12, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 10.
Furthermore, Hong discloses:
verifying includes using a corresponding entity ID and segment mask indicted by the memory access request to lookup one or more segment masks that are compared to the segment mask to determine whether to block or allow the memory request. (“In some example embodiments, as illustrated in FIG. 9, context table 764 may include a context index CI for at least one context stored in context table 764, a matching mask MM that is used in bit-wise masking for a request identification (ID) included in the access request REQ, a matching value MV that is bit-wise matched with the request ID on which the bit-wise masking is performed, and the operation mode OPMODE for the access request REQ including the request ID that is bit-wise matched with the matching value MV.”, 0056 ; “Once hardware privilege generator 760 including context table 764 of FIG. 9 receives the access request REQ from the one master of the plurality of masters 710, 720, 730 and 740 via interconnect 750, hardware privilege generator 760 may perform the bit-wise masking with the matching mask MM on the request ID of the access request REQ.“, 0057 ; Examiner Note: a request identification equates to an entity ID in this context)
As per claim 14, it is a system claim comprised of substantially the same limitations as claim 4, and as such, it is rejected for substantially the same reasons.
As per claim 16, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 10.
Furthermore, Jain discloses:
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 Al operations; a system for performing operations using a 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 Al 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 ("A system and method is disclosed for securing a software-in-the-loop simulation of a real-world system using one or more trusted execution environments (TEEs).", 0003 ; "SiL systems can be designed so that physical components (e.g., sensors, actuators) or target ECU hardware (e.g., vehicle controller) are not even required. SiL simulation may even represent the integration of compiled production source code into a mathematical model simulation that provide engineers with a practical, virtual simulation environment for the development and testing of detailed control strategies for large and complex systems.", 0002)
As per claim 20, it is a processor claim comprised of substantially the same limitations as claim 16, and as such, it is rejected for substantially the same reasons.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain (US 20220188386 A1) in further view of Hong (US 20180129525 A1) in further view of Kim (US 20200257794 A1) in further view of Hoppert (US 20180218473 A1).
As per claim 3, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1, but does not disclose providing a TEE with access to a PPU using a PPU hypervisor.
However, Kim discloses:
the access is provided to the second TEE corresponding to one or more computing devices using a PPU hypervisor that performs access control for the plurality of instances of the PPU ("In particular, the system uses a hardware-assisted virtualization scheme to implement the TEEs with acceleration with GPUs.", 0019 ; "The GPU driver is executed in a hypervisor, thereby the GPU driver can be isolated from a compromised operating system. Between the enclave and the GPU driver, the transmitted code and data are protected by encryption (for example, based on enclave-driver trusted channel establishment 140, and driver-device trusted channel establishment 150). Between the GPU driver and GPU hardware, the hardware spaces used to transmit the code and data are monitored by the hypervisor. The hypervisor ensures that only the GPU driver in the hypervisor can access the hardware spaces. Any other accesses are disallowed and cause the hypervisor to generate a page fault.", 0028 ; see fig.4 -enclave (i.e., TEE) accessing GPU driver accessing GPUs; "Moreover, the system ensures that only the GPU driver in the hypervisor can access the GPU hardware. In particular, the system 100 uses a hardware-assisted virtualization scheme, to execute the device driver in a tiny, dynamically loadable hypervisor. The system 100 can thereby implement acceleration with GPUs.", 0031 ; Examiner Note: a GPU equates to a PPU. The numerous hardware spaces equate to a plurality of instances)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Harty with those of Kim in order to provide an efficient and scalable method of secured communication between the TEE and GPU (i.e., PPU) (Kim, [0031]).
Pappachan in view of Jain in further view of Harty in further view of Kim fully discloses the above limitations of claim 3, but does not explicitly disclose partitions of a GPU which appear to be individual GPUs.
However, Hoppert discloses:
the plurality of instances of the PPU comprise a plurality of partitions of a graphics processing unit (GPU), each partition of the partitions appearing as a respective GPU to external devices (“In accordance with one or more implementations, the host device 104 and/or the other host device 106 may be configured with a virtual peripheral component interconnect (PCI) infrastructure. In such scenarios, the GPU partitioning manager 118 can use the virtual PCI infrastructure to expose partitions of the GPUs 116 to the virtual machines 110 in a way that appears like a physical GPU (because the partition is attached to PCI) would appear. In so doing, the GPU partitioning manager 118 may expose partitions of the GPUs by presenting virtual devices in a way that mimics PCI Express (PCIe) devices. Additionally, this allows a same operating system infrastructure to be utilized for configuration and driver loading in connection with leveraging GPU partitions.”, 0030)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Harty in further view of Kim with those of Hoppert, in order to allow for the same operating system to be utilized for configuration and driver loading with regard to GPU partitions (Hoppert, [0030]).
As per claim 13, it is a system claim comprised of substantially the same limitations as claim 3, and as such, it is rejected for substantially the same reasons.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain (US 20220188386 A1) in further view of Hong (US 20180129525 A1) in further view of Cho (US 20230089925 A1).
As per claim 4, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1.
Furthermore, Cho discloses:
internal memory paths are separated and isolated through on-chip crossbar ports, one or more cache banks, one or more memory controllers, and one or more address busses of the memory system of the PPU. (“In the implementations described herein, each application can have separate and isolated paths through the entire memory system (e.g., on-chip crossbar ports, second level (L2) cache banks, memory controllers, dynamic random access memory (DRAM) addresses busses). “, 0022)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Hong with those of Cho in order to prevent applications/instances from interfering with other applications/instances when they have high demands for DRAM bandwidth or oversubscribed requests to the L2 cache (Cho, [0022]).
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain (US 20220188386 A1) in further view of Hong (US 20180129525 A1) in further view of Loh (US 20150277949 A1).
As per claim 5, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1, but does not disclose configuring one or more hardware firewalls which are implemented with the memory management unit of the PPU to isolate the PPU memory.
However, Loh discloses:
the one or more hardware firewalls are to check at least one of one or more segment identifiers or one or more partition identifiers of the memory access request to block access when the at least one of the one or more segment identifiers or the one or more partition identifiers indicate that the memory access request fall outside of the one or more partitioned memory boundaries assigned to the PPU instance ("In one embodiment, interconnected may include a memory firewall 124 to control those transactions directed to interconnect 112 and subsequently to memory 110 (memory may be RAM or block storage such as embedded multimedia controller (eMMC)). Memory firewall 124 may include controller 120 of interconnect 112 and rule-based policies to control the access to the memory 110. Controller 120 may implement one or more rules to determine if the received transaction (PU transaction or BM transaction) may be executed according to the one or more rules of memory firewall 124. In one embodiment, the one or more rules may include the allowable one or more identifiers and their corresponding memory address ranges.”, 0035)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Hong with those of Loh in order to provide a means for providing security to the memory locations of the PPU using a method which improves virtual address translation speed (Loh, [0059]).
As per claim 15, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 10, but does not disclose internal memory paths comprising paths to one or more cache partitions and one or more RAM partitions of the PPU.
However, Loh discloses:
internal memory paths comprise physical paths to one or more cache partitions and one or more RAM partitions of the PPU, the physical paths allocated amongst the plurality of instances by a PPU hypervisor of the PPU (“A shared cache (not shown) may be included in either processor or outside of both processors, yet connected with the processors via P-P interconnect, such that either or both processors' local cache information may be stored in the shared cache if a processor is placed into a low power mode.”, 0079 ; “ In one embodiment, interconnected may include a memory firewall 124 to control those transactions directed to interconnect 112 and subsequently to memory 110 (memory may be RAM or block storage such as embedded multimedia controller (eMMC)). Memory firewall 124 may include controller 120 of interconnect 112 and rule-based policies to control the access to the memory 110”, 0035 ; “The CPU may execute the VMM 118 to assign the VMID to the bus master at the initiation of the virtual machine.”, 0033 ; “In one embodiment, each virtual machine at creation may be assigned by VMM 118 to use a specific portion of the memory.”, 0034 ; Examiner Note: a shared cache is necessarily partitioned)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Hong with those of Loh in order to provide a means for providing security to the memory locations of the PPU using a method which improves virtual address translation speed (Loh, [0059]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain ( US 20220188386 A1) in further view of Hong (US 20180129525 A1) in further view of Avetisov (US 20220255931 A1).
As per claim 6, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1, but does not disclose decrypting the data within the first TEE, storing the data in a protected region, or accessing the decrypted data from one of the protected regions.
However, Avetisov discloses:
decrypting the data within the first TEE to generate decrypted data; and storing the decrypted data in one or more protected memory regions of the first TEE, where the data is processed by the PPU instance accessing the decrypted data from the one or more protected memory regions accessing the decrypted data from the one or more protected memory regions ("Likewise, the TEE co-processor 105 may decrypt other data, such by decrypting that data with a generated key, received key, a cryptographic key of a hardware component, or combination thereof (such as in instances where some data is encrypted based on a generated private key and stored subsequent to further encryption based on a cryptographic key of a hardware component).", 0091 ; “In some embodiments, the TEE 103 may be configured to isolate different data within the TEE 103.”, 0092 ; see fig.1- TEE memory (107) is protected "Some embodiments may process one or more rules and associated data within a TEE 103 of the mobile device 101. ", 0130 ; Examiner Note: The data is stored within the protected memory region of the TEE before and after the decryption)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Hong with those of Avetisov in order to provide a method for secure data handling which provides an improvement to the security and functioning of the TEE as a whole (Avetisov, [0033])
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Pappachan (US 20200134208 A1) in view of Jain (US 20220188386 A1) in further view of Hong (US 20180129525 A1) in further view of Franke (US 20230195653 A1).
As per claim 9, Pappachan in view of Jain in further view of Hong fully discloses the limitations of claim 1, but does not disclose data received from a bounce buffer outside of the TEEs.
However, Franke discloses:
the receiving of the data is from one or more bounce buffers outside of the first TEE and the second TEE ("In order to facilitate the encryption and decryption operations for the devices, a bounce buffer is utilized that is accessible by both the guest and the host and encrypted with the host key. While memory can be encrypted on a per VM basis or per-host basis, I/O operations only have one translation layer using the bounce buffer.", 0023 ; Examiner Note: the bounce buffer being accessible to the guest and host equates to being outside of the guest and host)
The system of Pappachan in view of Jain in further view of Hong in further view of Franke would be capable of sending and receiving data between TEEs or computing units using the bounce buffer (Jain, [0023]). It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Pappachan in view of Jain in further view of Hong with those of Franke in order to provide a method for providing data security which lowers the risk of exposing the data to other components of the system while also offering a higher degree of control to the user (Franke, [0003]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US 20180189092 A1) in view of Hong (US 20180129525 A1).
As per claim 17, Sanchez discloses:
A processor comprising: one or more circuits to implement at least a portion of: a first trusted execution environment (TEE) comprising one or more first instances of a plurality of instances of a parallel processing unit (PPU) and one or more first virtual machines (VMs) executing on one or more processors; and a second TEE comprising one or more second plurality of instances of the PPU and one or more second VMs executing on the one or more processors. (“Following a request for secure execution of a series of instructions of an application by a requesting virtual machine, it comprises allocating said secure execution at least one available secure hardware portion belonging to one of the interconnected processors, loading the secure execution environment (TEE1) associated with the requesting virtual machine (VM1) in the allocated secure hardware portion(s). The allocated secure hardware portion is used for the secure execution of the sequence of instructions.”, abstract ; “For example, in the example of FIG. 2, a first request 33 is sent, for a secure execution of the application APP.sub.1 in its secure execution environment TEE.sub.1, as well as a second request 35 for a secure execution of the application APP.sub.2 in its secure execution environment TEE.sub.2.”, 0070 ; “A method for secure execution of virtual machines by a set of interconnected programmable devices, each programmable device including at least one computing processor having one or several cores”, clm.1 ; “The application executed within the TEE (sometimes called “trustlet”) is made up of several sequences of instructions, which, depending on the design of the code (division into several threads), are optionally executed on several processor cores in parallel within a same TEE”, 0013)
Sanchez discloses the above limitations of claim 17, but does not disclose a hardware firewall implemented using one or more memory management units.
However, Hong discloses:
one or more hardware firewalls implemented using one or more memory management units (MMUs) of the PPU to isolate internal memory paths of a memory system of the PPU that are respectively assigned to the plurality of instances of the PPU for processing data within the first TEE and the second TEE (“the hypervisor may control STG2 MMU 214 and hardware firewalls 260 and 270 to check only whether each virtual machine group (or each virtual machine) is permitted to access a physical page of memory device 240 having the physical address. For example, the hypervisor may perform an access permission check on an access request output from processor 210 by using the STG2 MMU 214, may perform an access permission check on an access request output from device 220 by using hardware firewall 260, and may perform an access permission check on an access request output from device 230 by using hardware firewall 270.”, 0040 ; “According to example embodiments, a computing system includes a processor, and provides a rice execution environment (REE) and a trusted execution environment (TEE).”, 0007)
verifying, for a memory access request, one or more address translations performed using one or more virtual MMUs (VMMUs) fall within one or more partitioned memory boundaries assigned to a PPU instance of the plurality of instances that corresponds to the memory access request. (“ the access request including the virtual address may be translated into an access request including an intermediate physical address in the intermediate physical address spaces by STG1 MMUs 212, 222 and 232 controlled by the operating systems.”, 0038 ; “the hypervisor may control STG2 MMU 214 and hardware firewalls 260 and 270 to check only whether each virtual machine group (or each virtual machine) is permitted to access a physical page of memory device 240 having the physical address.”, 0040)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Sanchez with the hardware firewall and virtual MMUs of Hong in order to more reliably prevent data of a secure application executed in a privileged virtual machine group, or TEE, from being leaked to a normal virtual machine group (Hong, [0042]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US 20180189092 A1) in view of Hong (US 20180129525 A1) in further view of Pappachan (US 20200134208 A1).
As per claim 18, Sanchez in view of Hong fully discloses the limitations of claim 17, but does not disclose the communication between PPU and VM using cryptographic keys which are inaccessible to the other TEEs.
However, Pappachan discloses:
the one or more first instances of the PPU communicate with the one or more first VMs using one or more first cryptographic keys that are inaccessible to the second TEE, and the one or more second instances of the PPU communicate with the one or more second VMs using one or more second cryptographic keys that are inaccessible to the first TEE. ("In some embodiments, the GPU 230 further includes an encryption engine supporting multiple keys for encryption 244, such as MKTME. The protected region 236 is partitioned into multiple protection domains, with each protection domain being encrypted by a unique symmetric key, and with each key being associated with a key ID. The encryption engine 244 is to maintain a table that maps each key ID to the respective key.", 0045 ;"In some embodiments, the GPU is to select the correct key ID for each local memory access request.", 0047 ; "FIG. 3A is an illustration of a process for access from a host to GPU local memory utilizing encryption and access control according to some embodiments.", 0049 ; see fig.3; “For secure acceleration of workloads that are offloaded from host TEEs to the virtualized GPU, it is essential to protect compute kernels and data that is within the local memory of the GPU.”, 0003 ; Examiner Note: the host comprises the first and second instances of the PPU, and the multiple kernels of the virtualized GPU/TEE correspond to the first and second virtual machine. The symmetric encryption keys equate to cryptographic keys. Upon each memory access request, the GPU selects the correct key associated with the memory location/VM and utilizes it, thus the key for the region used by the first requesting core would be inaccessible to the second requesting core)
The combination of Sanchez in view of Hong with Pappachan would provide a system capable of communication between a first and second VM and first and second PPU, each connection having its own cryptographic key inaccessible to the other. See Pappachan, [0097]: “Additionally, it is typical to allocate a set of memory resources, for example buffers, for the executions implemented in secure hardware mode that will be used to communicate with the client virtual machine of this TEE. This is how the secure applications yield results to the standard applications”.
It would have been obvious to one of ordinary skill in the art to combine the system of Sanchez in view of Hong with the communication using cryptographic keys of Pappachan in order to provide secure execution environments which are protected against software attacks originating from either the host or other parallel workloads (Pappachan, [0017]).
As per claim 19, Sanchez in view of Hong fully discloses the limitations of claim 17, but does not disclose the isolation of PPU memories.
However, Pappachan discloses:
one or more VMMUs configure first level page tables based at least on which PPU instances of the plurality of instances have access to which physical pages of memory and the one or more MMUs configure corresponding page table mappings within the PPU instance.
(“ For memory accesses to graphics local memory from the host, the process is performed as follows: A guest VM (Virtual Machine) or TD's virtual address is translated to guest physical address by the first level host page tables, and then to host physical address targeting graphics memory. This host physical address is in the VF LMEM (Local Memory) BAR (Base Address Registers) region. When this host physical address reaches the GPU, the Gunit translates the host physical address to the device physical address using the LMTT. For memory accesses to graphics local memory from within the GPU, there are two levels of address translation. The first level of address translation, performed using the PPGTT, translates graphics virtual address to graphics guest physical address. The PPGTT tables for this first translation are set up by the VM or TD; in the case of the TD, these PPGTT tables reside in protected memory and are not accessible to untrusted host software. The second level of address translation is from graphics guest physical address to device physical address and is performed using the LMTT, which is verified and set up jointly by the KMD and the GTA. The LMTT also resides in protected memory.”, 0039 ; “In some embodiments, programming of the PPGTT (Per-Process Graphics Translation Tables) is performed by the VF KMD, which is trusted in the TDX model.“, 0040 ; “The GTA 240 is to maintain the GMPT 242 to record data regarding each physical page in local memory that is allocated to a virtual function assigned to a TEE. Further, the computing system 200 provides for trusted programming of GPU page tables.”, 0044)
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US 20180189092 A1) in view of Hong (US 20180129525 A1) in further view of Sood (US 20190220601 A1).
As per claim 21, Sanchez in view of Hong fully discloses the limitations of claim 17, but does not explicitly disclose a multi-tenant environment.
However, Sood discloses:
the first TEE corresponds to a first tenant of a multi-tenant environment and the second TEE corresponds to a second tenant of the multi-tenant environment. (“This disclosure relates in general to the field of secure execution environments, and more particularly, though not exclusively, to composable trustworthy execution environments (CTEEs) for heterogeneous and/or multi-tenant workloads.”, 0002 ; see fig.1 – tenants a (114a/114c) and tenants b (114b/114d))
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Sanchez in view of Hong with that of Sood in order to provide the ability to securely scale heterogenous multi-tenant workloads flexibly and efficiently (Sood, [0022]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kegel (US 20140173236 A1) – discloses a method for preventing peripheral devices and/or processor cores from accessing restricted portions of system memory using a security processor coupled to the host bridge via a memory access bus that allows the security processor to access system memory and to access the peripheral device.
SHCHERBINA (US 20220276966) – discloses a data processing system in which varying numbers of channels for accessing a memory can be configured, the communications channel to use for an access to the memory is determined by mapping a memory address associated with the memory access to an intermediate address within an intermediate address space, selecting, based on the number of channels configured for use to access the memory, a mapping operation to use to determine from the intermediate address which channel to use for the memory access, and using the selected mapping operation to determine from the intermediate address which channel to use for the memory access.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights