DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 08/10/2026.
Claims 1-50 are currently pending and have been examined.
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 .
Response to Arguments
Applicant’s arguments filed with respect to the rejections under 35 USC § 103 have been fully considered but they are not persuasive.
On pg. 16, Applicant essentially argues regarding the rejections to claims 1, 29, and 40:
“This passage from Weiser does not disclose a TEE configured on a VM. To the contrary, Weiser expressly discloses that its VM hosts the untrusted OS, while the trusted stack, including the hypervisor and the SGX enclaves, is kept isolated from and outside of that VM. Weiser at 263-64, § 5.1, Figure 2. As shown in Weiser 's Figure 2, the trusted stack and the VM are distinct components: the VM operates the untrusted OS, while the hypervisor confines the untrusted OS within the VM precisely so that the trusted stack remains outside of it. Weiser therefore teaches the opposite of what is claimed. Rather than a TEE being configured on a VM, Weiser 's architecture keeps its trusted components isolated from the VM.”
Applicant notes that “Weiser expressly discloses that its VM hosts the untrusted OS”, but Weiser further there discloses that secure user applications (apps) are run on the OS hosted on the VM the sentence continues stating “OS hosted on the VM runs secure user applications, also abbreviated with user apps.” Weiser further expressly discloses the user app “is executed within an enclave” (§5.2). Furthermore, Fig. 2 clearly illustrates the user app trusted enclave (TEE) is configured on the VM; Figure 2 (annotated):
PNG
media_image1.png
394
436
media_image1.png
Greyscale
On pg. 17, Applicant essentially argues regarding the combination of Volos/Weiser:
“The Examiner states that it would have been obvious to modify Volos to implement the CPU TEE on a VM as taught by Weiser "to protect applications from compromised OS." Office Action at 14. This rationale is drawn from Weiser 's own stated purpose of protecting user applications against a subverted or malicious operating system.
However, Volos 's CPU-side TEE already provides this protection without any need for Weiser 's VM/hypervisor architecture. Volos discloses a threat model in which "a strong adversary ... controls the entire system software, including the device drivers, the guest operating system, and the hypervisor" … Because Volos 's existing architecture already isolates its CPU TEE from a compromised operating system, the Examiner has not identified any deficiency in Volos that would have motivated a person of ordinary skill in the art to import Weiser 's VM/hypervisor architecture. The stated rationale, protecting against a compromised OS, describes a problem Volos has already solved through its own enclave-based design. Modifying Volos to add Weiser's VM and hypervisor layer for that stated purpose would therefore have been unnecessary.”
Examiner respectfully disagrees. Volos’s protection scheme requires accelerator/GPU I/O devices with specifically configured HW for supporting TEEs. Weiser protects secure apps communicating with generic I/O devices from a compromised OS. Accordingly, Weiser’s protection is not redundant or “unnecessary” with respect to Volos for at least extending protection, against a weaker adversary, to app communications that are not protected by Volos.
On pg. 18, Applicant further argues regarding the combination of Volos/Weiser:
“This absence of motivation is reinforced by the differing problem domains of the two references. Volos is directed to extending TEEs to GPU compute accelerators for offloaded computation. Volos at 681. Weiser, in contrast, is directed to a generic trusted input/output path for human-facing 1/0 devices, with its abstract identifying use cases such as protecting against kernel-level keyloggers and screenloggers, and digital rights management. Weiser at 261. A person of ordinary skill seeking to improve Volos 's GPU TEE architecture would have had little reason to consult Weiser 's unrelated trusted-path architecture for user input/output devices, which addresses a different threat surface entirely.”
Examiner respectfully disagrees. The references fall into the same field of endeavor of systems and methods to establish secure communication between a CPU TEEs (specifically an SGX enclaves) and I/O devices. Volos cites Weiser (Ref. [48], pg. 694, 696), and at the time of this writing, 26 academic publications tracked by Google Scholar cite both Volos and Weiser (search record included).
On pg. 18-19, Applicant essentially argues regarding the rejections to claims 4, 18, 32, and 43:
The Examiner states that these claims "essentially repeat the subject matter of the independent claims but for a second request/second TEE/second VM/second TEE," and asserts that "Volos supports multiple GPU TEEs/contexts and GPU sharing ... and accordingly implicitly discloses performing the process a second time either serially or concurrently with respect to a first time."…no cited portion of Volos or Weiser discloses even a single TEE configured on a VM in the first instance. A rejection premised on an implicit disclosure of repeating a structure a second time cannot establish that the structure was disclosed by the reference, where there is no first instance of that structure disclosed to repeat. For these reasons, Volos does not disclose the second TEE and second VM limitations of Claims 4, 18, 32, and 43, and these claims are allowable for at least this additional reason.
Which is unpersuasive for essentially the same reasons as described above in response to the arguments for to claims 1, 29, and 40. However, regarding Applicant’s argument on pg. 19 that
“Volos do not disclose two concurrently-active composed TEEs, each including its own complete VM, configured on the same processor and device as claimed. General support for multiple GPU TEEs or contexts is not the same as a specific disclosure of a second request establishing a second TEE on a second VM while a first TEE on a first VM remains configured on that same processor and device”
Examiner maintains Volos discloses multiple concurrently active GPU TEEs/contexts each connected via an encrypted channel to a respective CPU TEE (i.e. composed TEEs) and said CPU TEEs being on VMs in view of Weiser. But Examiner additionally notes that the claims do not recite or require “two concurrently-active composed TEEs” or “a second TEE on a second VM while a first TEE on a first VM remains configured”; nor is there any description in AppSpec to indicated such interpretation to be either inherently required as AppSpec does not provide any explicit description of “a first TEE on a first VM” and “a second TEE on a second VM” as claimed. Accordingly, Volos/Weiser teach the limitation operating in a serial fashion (“Graviton guarantees that once a secure context has been created, its resources can only be accessed by a user application/runtime in possession of the corresponding private key...hosted in a CPU TEE...The command processor also ensures that the resources are correctly initialized on allocation to a secure context, and cleaned up on destruction (pg. 682, col. 1)...Resources are allocated to contexts to run a compute task and are freed when a context is destroyed” (pg. 683, col. 1)).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time-wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to:
www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-50 of the instant Application (“AppClaims”) are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 2, 5-10, 12, 13, 45, and 46 U.S. Patent No. US 12,079,341 B2 (“PatClaims”) as shown in the mapping below.
INDEPENDENT APPCLAIMS 1, 14, 29, 40 unpatentable over PATCLAIMs 1, 45, and 46:
AppClaim 1 Anticipated by --------------->
Broader limitations directed to essentially same subject matter.
A device, comprising: input/output (I/O) circuitry to communicate over an interconnect; and processing circuitry to:
receive, via the I/O circuitry, a request to configure the device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM),
wherein the TEE is to be configured on a processor and the device, and
wherein the TEE is to include an encrypted data stream for communication over the interconnect between the processor and the device; and configure, based on the request, the device to be included in the TEE.
AppClaim 14 Anticipated by --------------->
Broader limitations directed to same essential subject matter
A system, comprising: input/output (I/O) circuitry to communicate with one or more devices over an interconnect;
and processing circuitry to: receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically attests a configuration of the first device; and configure a composed trusted execution environment (TEE) on a virtual machine (VM), wherein the composed TEE is distributed across the processing circuitry and the first device,
and wherein an encrypted data stream is configured for communication over the interconnect between the processing circuitry and the first device within the composed TEE.
PatClaim 45 +46
A device, comprising: input/output (I/O) circuitry to communicate with a host device over an interconnect, wherein the host device comprises a processor and a memory; the device to:
receive, via the I/O circuitry, a request from the host device to add the device to a composed trusted execution environment (TEE), wherein the composed TEE is to include: a first TEE on the processor; a second TEE on the device; a protected area of the memory to store data associated with the composed TEE; and
an encrypted data stream for communication over the interconnect between the host device and the device;… and configure the second TEE on the device, wherein the second TEE is to be included in the composed TEE…wherein the composed TEE is to be configured on a virtual machine (VM) hosted on the processor.
PatClaim 1
An apparatus, comprising: input/output (I/O) circuitry to communicate with one or more devices over an interconnect; memory circuitry; and processing circuitry to: receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically attests a configuration of the first device; and configure a composed trusted execution environment (TEE) on a virtual machine (VM), wherein the composed TEE is distributed across the apparatus and the first device, and wherein the composed TEE comprises:
and an encrypted data stream for communication over the interconnect between the apparatus and the first device.
AppClaim 29 Obvious Variation of ------------->
Broader limitations directed to same essential subject matter, different statutory category
29. A method, comprising:
receiving, via input/output (I/O) circuitry, a request to configure a device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM), wherein the TEE is to be configured on a processor and the device, and
wherein the TEE is to include an encrypted data stream for communication over an interconnect between the processor and the device;
sending, via the I/O circuitry, a device signature for the device to the processor, wherein the device signature cryptographically attests a configuration of the device; and
configuring the device to be included in the TEE.
PatClaim 45 +46
A device…
receive, via the I/O circuitry, a request from the host device to add the device to a composed trusted execution environment (TEE), wherein the composed TEE is to include: a first TEE on the processor; a second TEE on the device; a protected area of the memory to store data associated with the composed TEE; and
an encrypted data stream for communication over the interconnect between the host device and the device;
send, via the I/O circuitry, a device signature for the device to the host device, wherein the device signature cryptographically attests a configuration of the device; and configure the second TEE on the device, wherein the second TEE is to be included in the composed TEE.…wherein the composed TEE is to be configured on a virtual machine (VM) hosted on the processor.
AppClaim 40 Obvious Variation of ------------->
Broader limitations directed to essentially same subject matter from reciprocal perspective, differing in statutory category.
At least one non-transitory computer-readable medium having instructions…cause the processing circuitry to: receive, via input/output (I/O) circuitry, a request to configure the device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM), wherein the TEE is to be configured on a processor and the device, and wherein the TEE is to include
an encrypted data stream for communication over an interconnect between the processor and the device;
send, via the I/O circuitry, a device signature for the device to the processor, wherein the device signature cryptographically attests a configuration of the device; and configure the device to be included in the TEE.
PatClaim 45 +46
device…
receive, via the I/O circuitry, a request from the host device to add the device to a composed trusted execution environment (TEE), wherein the composed TEE is to include: a first TEE on the processor; a second TEE on the device; a protected area of the memory to store data associated with the composed TEE; and
an encrypted data stream for communication over the interconnect between the host device and the device;
send, via the I/O circuitry, a device signature for the device to the host device, wherein the device signature cryptographically attests a configuration of the device; and configure the second TEE on the device, wherein the second TEE is to be included in the composed TEE.…wherein the composed TEE is to be configured on a virtual machine (VM) hosted on the processor.
AppClaim 1 Obvious Variation of ------------->
Broader limitations directed to same essential subject matter described from the reciprocal perspective.
A device, comprising:
input/output (I/O) circuitry to communicate over an interconnect; and processing circuitry to:
receive, via the I/O circuitry, a request to configure the device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM), wherein the TEE is to be configured on a processor and the device, and
wherein the TEE is to include an encrypted data stream for communication over the interconnect between the processor and the device; and configure, based on the request, the device to be included in the TEE.
PatClaim 1
An apparatus, comprising:
input/output (I/O) circuitry to communicate with one or more devices over an interconnect; memory circuitry; and processing circuitry to: … configure a composed trusted execution environment (TEE) on a virtual machine (VM), wherein the composed TEE is distributed across the apparatus and the first device…
and an encrypted data stream for communication over the interconnect between the apparatus and the first device.
AppClaim 29 Obvious variation --------------->
Broader limitations directed to same essential subject matter from the reciprocal perspective
A method, comprising:
receiving, via input/output (I/O) circuitry, a request to configure a device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM), wherein the TEE is to be configured on a processor and the device, and wherein the TEE is to include an encrypted data stream for communication over an interconnect between the processor and the device;
sending, via the I/O circuitry, a device signature for the device to the processor, wherein the device signature cryptographically attests a configuration of the device; and configuring the device to be included in the TEE
PatClaim 1
An apparatus, comprising:
configure a composed trusted execution environment (TEE) on a virtual machine (VM), wherein the composed TEE is distributed across the apparatus and the first device,
and an encrypted data stream for communication over the interconnect between the apparatus and the first device, and wherein the composed TEE comprises:
receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically attests a configuration of the first device;
AppClaim 40 Obvious variation of -------------->
Broader limitations directed to same essential subject matter from the reciprocal perspective
At least one non-transitory computer-readable medium having instructions stored thereon, wherein the instructions, when implemented or executed on processing circuitry of a device, cause the processing circuitry to:
receive, via input/output (I/O) circuitry, a request to configure the device for inclusion in a trusted execution environment (TEE) on a virtual machine (VM), wherein the TEE is to be configured on a processor and the device, and wherein the TEE is to include an encrypted data stream for communication over an interconnect between the processor and the device;
send, via the I/O circuitry, a device signature for the device to the processor, wherein the device signature cryptographically attests a configuration of the device; and configure the device to be included in the TEE.
PatClaim 1
An apparatus, comprising:
configure a composed trusted execution environment (TEE) on a virtual machine (VM), wherein the composed TEE is distributed across the apparatus and the first device, and wherein the composed TEE comprises…
and an encrypted data stream for communication over the interconnect between the apparatus and the first device
receive, via the I/O circuitry, a device signature from a first device of the one or more devices, wherein the device signature cryptographically attests a configuration of the first device;
DEPENDENT APPCLAIMS 2-13, 15-28, 30-39 and 41-50 unpatentable over PATCLAIMs 2, 5-10, 12, 13:
AppClaims 2, 16, 30, and 41:
Obvious variation of -------------------->
Limitation recited.
PatClaim 9
AppClaims 3, 15, 31, and 42:
Obvious variation of -------------------->
Limitation recited.
PatClaim 7
AppClaims Claims 4, 18, 32, and 43:
Obvious variation of -------------------->
Limitation recited.
PatClaim 12
AppClaims Claims 5, 19, 33, and 44:
Obvious variation of -------------------->
Limitation directed to intended use as written. The TEEs being ‘associated’ with tenants does not affect the structure of the apparatus claims nor does it affect how any method is performed
wherein: the first TEE is associated with a first tenant; and the second TEE is associated with a second tenant.
PatClaim 1
AppClaims 6, 20, 21, 34, and 45:
Obvious variation of -------------------->
Limitation recited.
PatClaim 13
AppClaims Claim 7, 8, 22, 35, 36, 46 and 47
Obvious variation of -------------------->
Limitation recited.
PatClaim 1 + 2
AppClaims 9, 25, 37, and 48:
PatClaim 7
AppClaims 10, 26, 38, and 49:
Obvious variation of -------------------->
Limitation recited.
PatClaim 8
AppClaims 11:
Obvious variation of -------------------->
Limitation recited.
PatClaim 1
AppClaims 12, 17, 27, 39, and 50:
Obvious variation of -------------------->
Limitation recited.
PatClaim 10
AppClaims 13 and 28
Obvious variation of -------------------->
inherent.
PatClaim 1
AppClaims 23:
Obvious variation of -------------------->
Limitation recited.
PatClaim 5
AppClaims 24:
Obvious variation of -------------------->
Limitation recited.
PatClaim 6
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-4, 6-9, 11-18, 20-25, 27-32, 34-37, 39-43, 45-48, and 50 are rejected under 35 U.S.C. 103 as being unpatentable over Volos et al. (“Graviton: Trusted Execution Environments on GPUs”, 2018) in view of Weiser et al. (“SGXIO: Generic Trusted I/O Path for Intel SGX”, 2017).
Claims 1, 11, 29, 40:
Volos discloses the limitations as shown in the rejections below:
A device (GPU), comprising: input/output (I/O) circuitry to communicate over an interconnect (pg. 682, § 2.1 and Fig. 1);
processing circuitry to: receive, via the I/O circuitry, a request to configure the device for inclusion in a trusted execution environment (TEE)…wherein the TEE is to be configured on a processor (CPU TEE/enclave) and the device, (GPU TEE/secure context) (pg. 681-682, § 1, para. 4-9; pg. 685 col. 1)
wherein the TEE is to include an encrypted data stream for communication over the interconnect between the processor and the device; (pg. 686) “secure channel is created…On receiving the request, the command processor generates a fresh channel encryption key (CEK) for encrypting commands posted to this channel.”
[claim 11, 29, 40]: send, via the I/O circuitry, a device signature (attestation key (AK)) for the device to the processor, wherein the device signature cryptographically attests a configuration of the device (pg. 685, § 5.1).
configure, based on the request, the device to be included in the TEE (see pg. 686-689) for detailed discussion.
Volos only briefly describes the CPU-side TEE and does not specifically disclose it is on a virtual machine (VM).
Weiser, however, discloses (pg. 263-264, § 5.1 – 5.4 and Fig. 2) an analogous system and method of creating a secure communication channel between a CPU TEE/enclave and an accelerator/GPU wherein (emphasis added) “SGXIO is composed of two parts: a trusted stack and a Virtual Machine (VM)...The VM hosts an untrusted commodity OS like Linux, which runs secure user applications...To achieve memory isolation of the user app, it is executed within an enclave. SGX isolates all enclave memory from the untrusted OS. To achieve memory isolation for the trusted stack, the hypervisor confines the untrusted OS in a VM.” Examiner additionally refers to the Response to Arguments above.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Volos to implement the CPU TEE on a VM as taught by Weiser to protect applications from compromised OS while using generic I/O devices. (Weiser pg. 261, 264).
Claims 2, 3, 30, 31, 41, and 42
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses wherein the interconnect comprises a Peripheral Component Interconnect Express (PCIe) interconnect…wherein: the processor is a central processing unit (CPU); and the device is a graphics processing unit (GPU) (pg. 682, § 2.1 and Fig. 1).
Claims 4, 32, and 43:
The combination of Volos/Weiser discloses the limitations as shown above. Claims 4, 32, and 43 essentially repeat the subject matter of the independent claims but for a second request/second TEE/second VM/second TEE. Volos supports multiple GPU TEEs/contexts and GPU sharing (pg. 681-682, § 1, para. 5; pg. 684, col. 1, para. 5; pg. 687, col. 2) and accordingly implicitly discloses performing the process a second time either serially or concurrently with respect to a first time.
Claims 6, 34, and 45:
The combination of Volos/Weiser discloses the limitations as shown above. Claims 4, 32, and 43 essentially repeat the subject matter of the independent claims but for a second request/second CPU/second VM/second TEE. Volos supports multiple GPU TEEs/contexts and GPU sharing (pg. 681-682, § 1, para. 5-6; pg. 684, col. 1, para. 5; pg. 685; pg. 687, col. 2) and accordingly implicitly discloses performing the process a second time either serially or concurrently with respect to a first time. See also pg. 692, § 7.2 describing an example testbed setup that employs an 8 core processor (second CPU).
Claim 7, 8, 35, 36, 46, and 47:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses wherein the TEE is a composed TEE, wherein the composed TEE is a cryptographically-isolated execution environment distributed across the CPU and the GPU and includes: a first TEE on the CPU (CPU TEE/enclave); a second TEE on the GPU (GPU TEE/context); and the encrypted data stream (channel or stream) for communication between the first TEE and the second TEE (pg. 681-682, § 1, para. 5-6; pg. 685, col. 1; pg. 694, col. 1, last paragraph; pg. 690, col. 2, last paragraph). “In Graviton, a TEE takes the form of a secure context, a collection of GPU resources (e.g., device memory, command queues, registers) that are cryptographically bound to a public/private key pair and isolated from untrusted software on the host (including the driver) and all other GPU contexts…the key is hosted in a CPU TEE (pg. 681)…In Graviton, we use TEEs to host the user application and the GPU runtime” (pg. 685).
Claims 9, 37, and 48:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses wherein the processing circuitry is further to execute one or more workloads in the second TEE on the GPU (see pg. 693, § 7.3).
Claims 12, 39, and 50:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses wherein the device is: a graphics processing unit (GPU); an artificial intelligence accelerator; a cryptography accelerator; a compression accelerator; a field-programmable gate array (FPGA); or a network interface controller (see pg. 681, col. 1).
Claims 13 and 28:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses a memory coupled to the processing circuitry to store instructions, (command processor firmware) wherein the instructions, when executed by the processing circuitry, cause the processing circuitry to: receive, via the I/O circuitry, the request to configure the device for inclusion in the TEE on the VM; and configure, based on the request, the device to be included in the TEE (see pg. 682, Fig. 1; pg. 686, § 5.2).
Claim 14:
Volos discloses the limitations as shown in the rejections below:
A system, comprising: input/output (I/O) circuitry to communicate with one or more devices (GPU) over an interconnect (pg. 682, § 2.1 and Fig. 1);
processing circuitry to: receive, via the I/O circuitry, a device signature (attestation key (AK)) from a first device of the one or more devices, wherein the device signature cryptographically attests a configuration of the first device (pg. 685, § 5.1).
configure a composed trusted execution environment (TEE)…wherein the composed TEE is distributed across the processing circuitry (CPU TEE/enclave) and the first device (GPU TEE/secure context) (pg. 681-682, § 1, para. 4-9; pg. 685 col. 1; pg. 694, col. 1, last paragraph: “Graviton effectively extends the trust boundary of TEEs on the CPU to rich devices, such as GPUs.”)
wherein an encrypted data stream is configured for communication over the interconnect between the processing circuitry and the first device within the composed TEE (pg. 686) “secure channel is created…On receiving the request, the command processor generates a fresh channel encryption key (CEK) for encrypting commands posted to this channel.”
Volos only briefly describes the CPU-side TEE and does not specifically disclose it is on a virtual machine (VM).
Weiser, however, discloses (pg. 263-264, § 5.1 – 5.4 and Fig. 2) an analogous system and method of creating a secure communication channel between a CPU TEE/enclave and an accelerator/GPU wherein (emphasis added) “SGXIO is composed of two parts: a trusted stack and a Virtual Machine (VM)...The VM hosts an untrusted commodity OS like Linux, which runs secure user applications...To achieve memory isolation of the user app, it is executed within an enclave. SGX isolates all enclave memory from the untrusted OS. To achieve memory isolation for the trusted stack, the hypervisor confines the untrusted OS in a VM.” Examiner additionally refers to the Response to Arguments above.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Volos to implement the CPU TEE on a VM as taught by Weiser to protect applications from compromised OS while using generic I/O devices. (Weiser pg. 261, 264).
Claim 15 and 17:
Recite the same essential subject matter and stand rejected under the same rationale as Claim 3 as shown in the rejections above.
Claim 16:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 2 as shown in the rejections above.
Claim 18:
Recites the same essential subject matter and stand rejected under the same rationale as Claims 4 respectively as shown in the rejections above.
Claim 20:
Recites the same essential subject matter and stand rejected under the same rationale as Claims 6 respectively as shown in the rejections above.
Claim 21:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 6 as shown in the rejections above.
Claim 22:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 8 as shown in the rejections above.
Claim 23:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses wherein the processing circuitry is further to: authenticate, based on the device signature, a hardware identity or a firmware identity of the first device (pg. 685-686, § 5.1).
Claim 24:
The combination of Volos/Weiser discloses the limitations as shown above. Volos further discloses configure a memory controller to encrypt data stored in memory assigned to the composed TEE (pg. 684, § 2.2 “SGX includes a memory encryption engine that encrypts and authenticates enclave data evicted to memory, and ensures integrity and freshness.”
Claim 25:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 9 as shown in the rejections above.
Claim 27:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 12 as shown in the rejections above.
Claim 28:
Recites the same essential subject matter and stand rejected under the same rationale as Claim 13 as shown in the rejections above.
Claims 5, 10, 19, 26, 33, 38, 44 and 49 are rejected under 35 U.S.C. 103 as being unpatentable over Volos in view of Weiser in further view of Zhang (“G-NET: Effective GPU Sharing in NFV Systems”, 2018)
Claims 5, 10, 19, 26, 33, 38, 44 and 49:
The combination of Volos/Weiser discloses the limitations as shown above. Volos/Weiser do not describe multiple users1 running applications and does not specifically disclose wherein the first TEE is associated with a first tenant; and the second TEE is associated with a second tenant. Volos/Weiser also do specifically disclose wherein the one or more workloads include: a virtual network function (VNF) workload; a Function-as-a-Service (FaaS) workload; a Platform-as-a-Service (PaaS) workload; an Infrastructure-as-a-Service (IaaS) workload; or a Software-as-a-Service (SaaS) workload.
Zhang, however, discloses (pg. 187-188, § 1, para. 2-4; pg. 190, Fig. 4; pg. 191, § 4.1) an analogous environment for GPU sharing with data isolation considerations, where the GPU receives VNF workloads from multiple different users (first tenant, second tenant).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Zhang’s G-NET system to employ the GPU TEE architecture of Volos/Weiser to improve data security and alleviate data isolation issues (Zhang pg. 187-188, § 1, para. 4; pg. 190, col. 1; pg. 192, col. 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
US 2020/0004993 A1 patent corresponding to Volos.
“Secure I/O with Intel SGX” Weiser master thesis.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
08/20/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
1 Examiner notes the limitations appears to be intended use as written but in the interests of expediting prosecution it has been treated as limiting.
Prosecution Insights