DETAILED ACTION
This Action is in consideration of the Applicant’s response on April 14, 2026. Claims 1, 9, 17, and 19 are amended by the Applicant. Claims 1 – 20, where Claims 1, 9, and 17 are in independent form, are presented for examination.
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 April 14, 2026 have been fully considered but they are moot based on the new grounds of rejection necessitated by amendment.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1 – 5, 7, 9 – 13, 15 and 17 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over PGPub. 2016/0191246 (hereinafter “Varadarajan”), in view of PGPub. 2016/0381005 (hereinafter “Vij”).
1. Regarding Claim 1, Varadarajan discloses a computer-implemented method for creating and managing trusted execution environments (TEEs) based on different hardware TEE mechanisms using a
transmitting an enclave command to the transmits a request to the TEE host process 400 to open a session. The request may include an identifier of a specific TA. In some embodiments, the identifier is a Unique Universal Identifier (UUID) of the TA. The request may be sent via the IPC mechanism], ;
in response to the enclave command received at the untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403]; and
requesting a TEE backend module to interact with a particular hardware TEE mechanism among the different hardware TEE mechanisms that is included in the computer system so that the enclave operation for the software process is executed by the particular hardware TEE mechanism [Para. 0025 i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock]. Vardarajan, however, does not specifically disclose that the software process is running in a virtual computing instance supported by a virtualization software in the computer system, wherein the virtual secure enclave device is provided by the virtualization software to the virtual computing instance.
Vij discloses a system and method for providing virtualized services access to a hardware security engine [Abstract]. Vij further discloses that the computer system can comprise of virtualization software that supports a virtual computing instance (e.g., VM) running a software process (e.g., application within VM) [Fig. 2; Para. 0021-22]. Vij further discloses that the virtual secure enclave device is provided by the virtualization software to the virtual computing instance [Fig. 2; Para. 0026-27; virtual security engine module executed as part of VMM]. It would have been obvious to one skilled in the art before the effective date of the current invention to incorporate the teachings of Vij with Vardarajan since both systems provide access to secure execution environment to applications established outside a secure environment. The combination utilizes known virtualization techniques to implement computing functions within a virtual machine. The motivation to do so is to improve security by logically separating multiple system that are hosted by and accessing the same hardware components [obvious to one skilled in the art].
2. Regarding Claim 2, Vardarajan, in view of Vij, discloses the limitations of Claim 1. The combination of Varadarajan and Vij further discloses that transmitting an enclave command to the virtual secure enclave device includes communicating with the virtual secure enclave device through a device driver for the virtual secure enclave device, wherein communications between the device driver and the virtual secure enclave device are executed using a universal application programming interface regardless of which of the different hardware TEE mechanisms is included in the computer system [Para. 0024-25 i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
3. Regarding Claim 3, Vardarajan, in view of Vij, discloses the limitations of Claim 2. Varadarajan further discloses that communications between the TEE backend module and the particular hardware TEE mechanism in the computer system are executed using a particular application programming interface specific to the particular hardware TEE mechanism [Para. 0024-25 i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
4. Regarding Claim 4, Vardarajan, in view of Vij, discloses the limitations of Claim 1. The combination of Varadarajan and Vij further discloses that transmitting the enclave command to the virtual secure enclave device includes inserting the enclave command into a command queue in the virtual secure enclave device [Fig. 3, step 307, Para. 0023; i.e. At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403].
5. Regarding Claim 5, Vardarajan, in view of Vij, discloses the limitations of Claim 4. The combination of Varadarajan and Vij further discloses that retrieving the enclave command from the virtual secure enclave device includes trapping an operation of inserting the enclave command into the command queue in the virtual secure enclave device [Fig. 3, step 307; Para. 0023; i.e. At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403].
6. Regarding Claim 7, Vardarajan, in view of Vij, discloses the limitations of Claim 5. The combination of Varadarajan and Vij further discloses that retrieving the enclave command from the virtual secure enclave device further includes emulating the command queue to retrieve the enclave command in the command queue of the virtual secure enclave device Para. 0026; i.e. At Block 311, when execution of commands is completed, the client process 300 transmits a request to the GP trusted services enclave 402 to close the session and at Block 312, the GP trusted services enclave 402 processes information related to the session and unloads the TA enclave 401.sub.n associated with the identifier. In one embodiment, the GP trusted services enclave 402 processes information related to the session includes locating and removing all session specific information].
7. Regarding Claim 9, Vardarajan discloses a non-transitory computer-readable storage medium containing program instructions for creating and managing trusted execution environments (TEEs) based on different hardware TEE mechanisms using a
transmitting an enclave command to the virtual secure enclave device from a software process running in the computer system [Para. 0023; i.e. At Block 303, the client process 300 transmits a request to the TEE host process 400 to open a session. The request may include an identifier of a specific TA. In some embodiments, the identifier is a Unique Universal Identifier (UUID) of the TA. The request may be sent via the IPC mechanism], ;
in response to the enclave command received at the virtual secure enclave device, retrieving the enclave command from the virtual secure device; parsing the retrieved enclave command to extract a description of an enclave operation to be executed from the retrieved enclave command [Para. 0023; i.e. At Block 304, the GP Trusted Services enclave 402 receives the request and determines a TA enclave associated with the identifier. The GP trusted services enclave 402 is included in the TEE host process 400. At Block 305, the GP trusted services enclave 402 loads in the TEE host process 400 the TA enclave 401.sub.n associated with the identifier to establish the session. In one embodiment, when the TA enclave 401.sub.n associated with the identifier is previously loaded, the GP trusted services enclave 402 selects the TA enclave 401.sub.n associated with the identifier. At Block 306, once the session is established, the client process 300 transmits to the TEE host process 400 commands to be invoked in the TA enclave 401.sub.n and a set of parameters needed for the commands. The commands and the set of parameters may be transmitted via an IPC channel (e.g., IPC channel 20.sub.1). At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403]; and
requesting a TEE backend module to interact with a particular hardware TEE mechanism among the different hardware TEE mechanisms that is included in the computer system so that the enclave operation for the software process is executed by the particular hardware TEE mechanism [Para. 0025; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
Vardarajan, however, does not specifically disclose that the software process is running in a virtual computing instance supported by a virtualization software in the computer system, wherein the virtual secure enclave device is provided by the virtualization software to the virtual computing instance.
Vij discloses a system and method for providing virtualized services access to a hardware security engine [Abstract]. Vij further discloses that the computer system can comprise of virtualization software that supports a virtual computing instance (e.g., VM) running a software process (e.g., application within VM) [Fig. 2; Para. 0021-22]. Vij further discloses that the virtual secure enclave device is provided by the virtualization software to the virtual computing instance [Fig. 2; Para. 0026-27; virtual security engine module executed as part of VMM]. It would have been obvious to one skilled in the art before the effective date of the current invention to incorporate the teachings of Vij with Vardarajan since both systems provide access to secure execution environment to applications established outside a secure environment. The combination utilizes known virtualization techniques to implement computing functions within a virtual machine. The motivation to do so is to improve security by logically separating multiple system that are hosted by and accessing the same hardware components [obvious to one skilled in the art].
8. Regarding Claim 10, Vardarajan, in view of Vij, discloses the limitations of Claim 9. The combination of Varadarajan and Vij further discloses that transmitting an enclave command to the virtual secure enclave device includes communicating with the virtual secure enclave device through a device driver for the virtual secure enclave device, wherein communications between the device driver and the virtual secure enclave device are executed using a universal application programming interface regardless of which of the different hardware TEE mechanisms is included in the computer system [Para. 0024-25; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
9. Regarding Claim 11, Vardarajan, in view of Vij, discloses the limitations of Claim 10. Varadarajan further discloses that communications between the TEE backend module and the particular hardware TEE mechanism in the computer system are executed using a particular application programming interface specific to the particular hardware TEE mechanism [Para. 0024-25; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
10. Regarding Claim 12, Vardarajan, in view of Vij, discloses the limitations of Claim 9. The combination of Varadarajan and Vij further discloses that transmitting the enclave command to the virtual secure enclave device includes inserting the enclave command into a command queue in the virtual secure enclave device [Fig. 3, step 307; Para. 0023; i.e. At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403].
11. Regarding Claim 13, Vardarajan, in view of Vij, discloses the limitations of Claim 12. The combination of Varadarajan and Vij further discloses that retrieving the enclave command from the virtual secure enclave device includes trapping an operation of inserting the enclave command into the command queue in the virtual secure enclave device [Fig. 3, step 307; Para. 0023; i.e. At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403].
12. Regarding Claim 15, Vardarajan, in view of Vij, discloses the limitations of Claim 13. The combination of Varadarajan and Vij further discloses that retrieving the enclave command from the virtual secure enclave device further includes emulating the command queue to retrieve the enclave command in the command queue of the virtual secure enclave device [Para. 0026; i.e. At Block 311, when execution of commands is completed, the client process 300 transmits a request to the GP trusted services enclave 402 to close the session and at Block 312, the GP trusted services enclave 402 processes information related to the session and unloads the TA enclave 401.sub.n associated with the identifier. In one embodiment, the GP trusted services enclave 402 processes information related to the session includes locating and removing all session specific information].
13. Regarding Claim 17, Vardarajan discloses a computer system [Figs. 2 and 5] comprising:
memory [Fig. 5; Para. 0028, 0037]; and
at least one processor [Fig. 5; Para. 0028, 0037] configured to:
transmit an enclave command to the virtual secure enclave device from a software process running in the computer system [Para. 0023; i.e. At Block 303, the client process 300 transmits a request to the TEE host process 400 to open a session. The request may include an identifier of a specific TA. In some embodiments, the identifier is a Unique Universal Identifier (UUID) of the TA. The request may be sent via the IPC mechanism], ;
in response to the enclave command received at the virtual secure enclave device, retrieving the enclave command from the virtual secure device; parse the retrieved enclave command to extract a description of an enclave operation to be executed from the retrieved enclave command [Para. 0023; i.e. At Block 304, the GP Trusted Services enclave 402 receives the request and determines a TA enclave associated with the identifier. The GP trusted services enclave 402 is included in the TEE host process 400. At Block 305, the GP trusted services enclave 402 loads in the TEE host process 400 the TA enclave 401.sub.n associated with the identifier to establish the session. In one embodiment, when the TA enclave 401.sub.n associated with the identifier is previously loaded, the GP trusted services enclave 402 selects the TA enclave 401.sub.n associated with the identifier. At Block 306, once the session is established, the client process 300 transmits to the TEE host process 400 commands to be invoked in the TA enclave 401.sub.n and a set of parameters needed for the commands. The commands and the set of parameters may be transmitted via an IPC channel (e.g., IPC channel 20.sub.1). At Block 307, the OS services 403 included in the TEE host process 400 queues the commands and at Block 308, GP trusted services enclave 402 validates the parameters. In one embodiment, the parameters are untrusted. After validation, at Block 309, the commands are dispatched in sequence to the TA enclave 401.sub.n associated with the identifier from the OS services 403]; and
request a TEE backend module to interact with a particular hardware TEE mechanism among the different hardware TEE mechanisms that is included in the computer system so that the enclave operation for the software process is executed by the particular hardware TEE mechanism [Para. 0025; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
Vardarajan, however, does not specifically disclose that the software process is running in a virtual computing instance supported by a virtualization software in the computer system, wherein the virtual secure enclave device is provided by the virtualization software to the virtual computing instance.
Vij discloses a system and method for providing virtualized services access to a hardware security engine [Abstract]. Vij further discloses that the computer system can comprise of virtualization software that supports a virtual computing instance (e.g., VM) running a software process (e.g., application within VM) [Fig. 2; Para. 0021-22]. Vij further discloses that the virtual secure enclave device is provided by the virtualization software to the virtual computing instance [Fig. 2; Para. 0026-27; virtual security engine module executed as part of VMM]. It would have been obvious to one skilled in the art before the effective date of the current invention to incorporate the teachings of Vij with Vardarajan since both systems provide access to secure execution environment to applications established outside a secure environment. The combination utilizes known virtualization techniques to implement computing functions within a virtual machine. The motivation to do so is to improve security by logically separating multiple system that are hosted by and accessing the same hardware components [obvious to one skilled in the art].
14. Regarding Claim 18, Vardarajan, in view of Vij, discloses the limitations of Claim 17. The combination of Varadarajan and Vij further discloses that the software process communicates with the virtual secure enclave device through a device driver for the virtual secure enclave device using a universal application programming interface regardless of which of the different hardware TEE mechanisms is included in the computer system [Para. 0024-25; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
15. Regarding Claim 19, Vardarajan, in view of Vij, discloses the limitations of Claim 18. Varadarajan further discloses that the TEE backend module communicates with the particular hardware TEE mechanism in the computer system using a particular application programming interface specific to the particular hardware TEE mechanism [Para. 0024-25; i.e. In the embodiment in FIG. 4B, executing the commands in the TA enclave 401.sub.n includes establishing a secure channel (e.g., IPC channel 20.sub.2) between the TEE host process 400 to one of the AEs 501.sub.m included in the AES process 500 (Block 421). At Block 422, the TEE host process 400 transmits a request including at least one of the commands to the one of the AEs 501.sub.m and at Block 423, a secure channel is established between the one of the AEs 501.sub.m with a security processor 600. For example, the TA wanting to utilize secure time would call the internal time APIs defined in the TEE specification. Since the secure time services is provided by external architectural enclave 501.sub.m, the SGX RTS first establishes a secure channel to route the request outside the TEE host process 400. After connecting through the secure channel (e.g., IPC channel 20.sub.2), AE 501.sub.m acknowledges the request and provides the secure time service. The AE 501.sub.m, in turn, establishes a secure channel with the security processor 600 (e.g., CSE) to provide secure time utilizing the hardware clock].
Claim(s) 6, 8, 14, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Varadarajan, in view Vij, in further view of U.S. Patent 8,166,474 (hereinafter “Delco”).
16. Regarding Claim 6, Vararajan, in view of Vij, discloses the limitations of claim 5. Vararajan, however, does not specifically disclose of trapping an operation of inserting the enclave command into the command queue is performed by a virtual machine monitor (VMM) running in a VMkernel in the virtualized environment.
Delco teaches wherein trapping an operation of inserting the enclave command into the command queue is performed by a virtual machine monitor (VMM) running in a VMkernel in the virtualized environment [Col. 7, lines 40-49; i.e. as shown in FIG. 4. While architecturally similar to the hosted virtualization framework 40, the dedicated virtualization framework 80 implements a dedicated kernel (VMKernel) 82 to support execution of the virtual machines 54.sub.1-N. As with the hosted virtualization framework 40, the dedicated kernel 82 implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines 54.sub.1-N].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Vararajan in view of Delco to have used a dedicated virtualization framework implements a dedicated kernel (VMKernel) to support execution of the virtual machines in which the dedicated kernel implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines. Therefore one would have been motivated to have used VMkernel to implement VMX processes that manage the restricted memory spaces defined for the individual virtual machines.
17. Regarding Claim 8, Vardarajan, in view of Vij and Delco, discloses the limitations of Claim 7. Delco further discloses that emulating the command queue is performed by a virtual machine executable (VMX) module running in the virtualized environment [Col. 7, lines 40-49; i.e. as shown in FIG. 4. While architecturally similar to the hosted virtualization framework 40, the dedicated virtualization framework 80 implements a dedicated kernel (VMKernel) 82 to support execution of the virtual machines 54.sub.1-N. As with the hosted virtualization framework 40, the dedicated kernel 82 implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines 54.sub.1-N].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Vararajan in view of Delco to have used a dedicated virtualization framework implements a dedicated kernel (VMKernel) to support execution of the virtual machines in which the dedicated kernel implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines. Therefore one would have been motivated to have used VMkernel to implement VMX processes that manage the restricted memory spaces defined for the individual virtual machines.
18. Regarding Claim 14, Vararajan, in view of Vij,discloses the limitations of Claim 13. Varadarajan, however, does not specifically disclose that trapping an operation of inserting the enclave command into the command queue is performed by a virtual machine monitor (VMM) running in a VMkernel in the virtualized environment
Delco teaches wherein trapping an operation of inserting the enclave command into the command queue is performed by a virtual machine monitor (VMM) running in a VMkernel in the virtualized environment [Col. 7, lines 40-49; i.e. as shown in FIG. 4. While architecturally similar to the hosted virtualization framework 40, the dedicated virtualization framework 80 implements a dedicated kernel (VMKernel) 82 to support execution of the virtual machines 54.sub.1-N. As with the hosted virtualization framework 40, the dedicated kernel 82 implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines 54.sub.1-N].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Vararajan in view of Delco to have used a dedicated virtualization framework implements a dedicated kernel (VMKernel) to support execution of the virtual machines in which the dedicated kernel implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines. Therefore one would have been motivated to have used VMkernel to implement VMX processes that manage the restricted memory spaces defined for the individual virtual machines.
19. Regarding Claim 16, Vararajan, in view of Vij, discloses the limitations of Claim 15. Vararajan, however, does not specifically disclose that emulating the command queue is performed by a virtual machine executable (VMX) module running in the virtualized environment.
Delco teaches wherein emulating the command queue is performed by a virtual machine executable (VMX) module running in the virtualized environment [Col. 7, lines 40-49; i.e. as shown in FIG. 4. While architecturally similar to the hosted virtualization framework 40, the dedicated virtualization framework 80 implements a dedicated kernel (VMKernel) 82 to support execution of the virtual machines 54.sub.1-N. As with the hosted virtualization framework 40, the dedicated kernel 82 implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines 54.sub.1-N].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Vararajan in view of Delco to have used a dedicated virtualization framework implements a dedicated kernel (VMKernel) to support execution of the virtual machines in which the dedicated kernel implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines. Therefore one would have been motivated to have used VMkernel to implement VMX processes that manage the restricted memory spaces defined for the individual virtual machines.
20. Regarding Claim 20, Vararajan, in view of Vij, discloses the limitations of Claim 17. Vararajan further discloses of retrieving the enclave command from the virtual secure enclave device further includes emulating the command queue to retrieve the enclave command in the command queue of the virtual secure enclave device [Para. 0026; i.e. At Block 311, when execution of commands is completed, the client process 300 transmits a request to the GP trusted services enclave 402 to close the session and at Block 312, the GP trusted services enclave 402 processes information related to the session and unloads the TA enclave 401.sub.n associated with the identifier. In one embodiment, the GP trusted services enclave 402 processes information related to the session includes locating and removing all session specific information]
Vararajan, however, does not specifically disclose that the enclave command is retrieved from the virtual secure enclave device by a virtual machine executable (VMX) module running in the virtualized environment.
Delco teaches wherein the enclave command is retrieved from the virtual secure enclave device by a virtual machine executable (VMX) module running in the virtualized environment [Col. 7, lines 40-49; i.e. as shown in FIG. 4. While architecturally similar to the hosted virtualization framework 40, the dedicated virtualization framework 80 implements a dedicated kernel (VMKernel) 82 to support execution of the virtual machines 54.sub.1-N. As with the hosted virtualization framework 40, the dedicated kernel 82 implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines 54.sub.1-N]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Vararajan in view of Delco to have used a dedicated virtualization framework implements a dedicated kernel (VMKernel) to support execution of the virtual machines in which the dedicated kernel implements VMX processes to manage the restricted memory spaces defined for the individual virtual machines. Therefore, one would have been motivated to have used VMkernel to implement VMX processes that manage the restricted memory spaces defined for the individual virtual machines.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAE K KIM whose telephone number is (571)270-1979. The examiner can normally be reached M-F 9:30-5:30.
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, Jorge Ortiz-Criado can be reached at 5712727642. 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.
/TAE K KIM/Primary Examiner, Art Unit 2496
Prosecution Insights