DETAILED ACTION
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 .
This written action is responding to the amendment dated on 01/08/2026.
Claims 1, 9 and 20 have been amended and all other claims are previously presented.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Priority
This application filed on September 20, 2022 claims priority of Provisional application 63/353,301 filed on June 17, 2022.
Response to Arguments
Applicant’s amendment, filed on January 08, 2026, claims 1, 9 and 20 amended and all other claims previously presented. Among the amended claims, claim 1 and 9 are independent claims.
The prior objections of claims 1 and 9 have been withdrawn in view of the amendment received on January 08, 2026.
Applicant’s remark, filed on January 08, 2026 on bottom of page 4 and top of page 5 regarding, “For example, the combination, as cited, does not appear to at least describe "TEE logic to support TEE usage, wherein the TEE logic is configured to at least in part: determine that a TEE feature is supported based at least on a value of a bit position in a data structure." has been considered, however is not found persuasive. Li teaches, “FIG. 6 is a block diagram of a trusted execution environment (TEE), according to one or more examples of the present specification. In the example of FIG. 6, memory 620 is addressable by n-bits, ranging in address from 0 to 2.sup.n−1. Within memory 620 is an OS 622, enclave 640, application stack 628, and application code 630. enclave 640 is a specially-designated portion of memory 620 that cannot be entered into or exited from except via special instructions, such as Intel® SGX or similar. Enclave 640 is provided as an example of a secure environment which, in conjunction with a secure processing engine 610, forms a trusted execution environment (TEE) 600 on a client device. A TEE 600 is a combination of hardware, software, and/or memory allocation that provides the ability to securely execute instructions without interference from outside processes, in a verifiable way. By way of example, TEE 600 may include memory enclave 640 or some other protected memory area, and a secure processing engine 610, which includes hardware, software, and instructions for accessing and operating on enclave 640. Nonlimiting examples of solutions that either are or that can provide a TEE include Intel® SGX, ARM TrustZone, AMD Platform Security Processor, Kinibi, securiTEE, OP-TEE, TLK, T6, Open TEE, SierraTEE, CSE, VT-x, MemCore, Canary Island, Docker, and Smack. Thus, it should be noted that in an example, secure processing engine 610 may be a user-mode application that operates within enclave 640. TEE 600 may also conceptually include processor instructions that secure processing engine 610 may utilize to operate within enclave 640”. (Fig. 6, ¶64-¶65). “Enclave 640 provides a protected memory area that cannot be accessed or manipulated by ordinary computer instructions. Enclave 640 is described with particular reference to an Intel® SGX™ enclave by way of example, but it is intended that enclave 640 encompass any secure processing area with suitable properties, regardless of whether it is called an “enclave. One feature of an enclave is that once an enclave region 640 of memory 620 is defined, as illustrated, a program pointer cannot enter or exit enclave 640 without the use of special enclave instructions or directives, such as those provided by Intel® SGX architecture. For example, SGX processors provide the ENCLU[EENTER], ENCLU[ERESUME], and ENCLU[EEXIT]. These are the only instructions that may legitimately enter into or exit from enclave 640”. (¶68-¶69). Chang teaches, “Each of the system entities in the system 100 is assigned a unique AID (e.g., AID1-AID7) stored in a corresponding AID register. In one embodiment, the AIDs are generated by a system boot and AID initialization (SBAI) unit 181. In one embodiment, the SBAI unit 181 is a trusted process in a TEE (e.g., TEE_1) and is executed by one of the CPUs in the system 100 (e.g., CPU_1). In one embodiment, the SBAI unit 181 may include a random number generator to generate AIDs when the system 100 is powered on. In one embodiment, each AID may be a sequence of random numbers. Each of the system entities includes a corresponding SRPU (e.g., SRPU 151-157). In one embodiment, each SRPU includes a combination of hardware and software components to enforce secured memory access. Each SRPU includes a data structure to keep track of the AIDs that are allowed to access memory locations allocated to its corresponding system entity. The term “data structure” herein refers to a collection of tables, lists, and/or other data organizations. the data structure is built by a scheduler 191, which may be a trusted process in a TEE (e.g., TEE_1) and is executed by one of the CPUs in the system 100 (e.g., CPU_1). The scheduler 191 schedules and assigns tasks (e.g., processes and/or trusted processes) to a system entity or across multiple system entities. For example, the scheduler 191 may distribute the processes of a task to multiple system entities such as multiple TEEs or multiple REEs. The scheduler 191 configures data structures of these multiple system entities to allow access among the multiple system entities for executing the task”. (¶22-¶24). “Secure user applications may be executed by the system 100 in TEEs; e.g., by CPU_1 and/or CPU_2. A secure user application may include one or more of the trusted processes 161 and 162. In one embodiment, each secure user application in a TEE is assigned an AID alias, which may be derived from the AID of the TEE. For example, the trusted OS 102 in TEE_2 may generate AID aliases from AID2 (the AID of TEE_2), and assigns each AID alias to a secure user application running in TEE_2. The trusted OS 102 may further generate access control information for each secure user application to indicate memory address space allocation and access restrictions to the secure user application. In the example of TEE_2, the per-application access control information is used by SRPU 152 to determine whether a source entity can access the allocated memory address space of a secure user application in TEE_2. In one embodiment, SRPU 152 first uses a data structure (e.g., a data structure 200 to be described in FIG. 2) to determine whether a source entity is allowed to access the target entity (e.g., TEE_2). If the source entity is allowed to access TEE_2 according to the data structure, SRPU 152 further determines whether the memory address space of the target user application in TEE_2 can be accessed by the source entity according to the access control information of the target user application. As such, the system resource owned by (e.g., allocated to) a user application in any TEE totally belongs to that user application, and cannot be accessed by any other application in the same TEE, other TEEs or REEs. In one embodiment, the system resource is allocated to a user application only during its execution. The allocation is released after the execution of the user application. When a user application residing in multiple TEEs, the multiple TEEs collaborate to ensure consistent access across the system resources allocated to the user application. These allocated system resources cannot be accessed by other applications in any of the TEEs or REEs. FIG. 2 illustrates a data structure 200 used by each of SRPUs 151-157 of FIG. 1 according to one embodiment. For ease of description, TEE_2 in FIG. 1 is used as an example of a target entity, which hosts SRPU 152 and the data structure 200. The data structure 200 includes an AID_allowed table 210, which stores information about entities allowed to access memory locations allocated to the target entity (e.g., TEE_2 in this example). It is understood that the same or analogous data structure may be used in any TEE, REE, co-processing module, I/O subsystem, and memory subsystem in the system 100 of FIG. 1. The AID_allowed table 210 includes at least three fields: an AID field, a privilege field, and a pointer to list field. These fields may be arranged into three columns of the AID_allowed table 210; however, alternative arrangements may be used. SRPU 152 uses the AID_allowed table 210 to identify the entities (by their AIDS) allowed to access the TEE_2 memory 112. For each AID in the first column of the AID_allowed table 210, its privilege is also identified. In one embodiment, there may be four privilege levels, from low to high: user code/data has a privilege level=0, a Rich OS has a privilege level=1, a hypervisor has a privilege level=2, and a monitor of a TEE has a privilege level=3. The privilege level provides information about the requestor (i.e., the entity sending an access request). The information can be used by the target entity receiving the access request (specifically, the target SRPU) to determine whether to grant or to reject the access request.”. (¶31-¶34). “The third column of the AID_allowed table 210 includes a pointer that points to a list of memory page addresses. In one embodiment, the memory page addresses are physical addresses. In another embodiment, the memory page addresses may be a memory address range. For each AID in the first column of the AID_allowed table 210, the pointer points to (e.g., by providing the address of) the head of a list of memory page addresses. For example, the first row of the AID_allowed table 210 includes AID_p, a privilege level=0, and a pointer Ptr_1 that points to a list_memory_page 220 (also referred to as the “list 220”). That is, a user process or application in the system entity identified by AID_p is allowed to access the memory pages in the list 220. In the example of FIG. 2, the list 220 includes four memory page entries, also referred to as entries (for simplicity, only the first entry 225 is labeled). Each entry in the list 220 includes a host AID 235, the address of a memory page, and an allowed/disallowed indicator (“A/D indicator 230”). The host AID 235 in the entry (e.g., AID_p or AID_q), identifies the entity that owns (i.e., is allocated with) the memory page. The default setting of the A/D indicator 230 is “allowed” (e.g., represented by a value of “1”), which indicates that the memory page in the same entry is accessible. A user or system administrator may, via an application programming interface (API), change the default setting of the A/D indicator 230 to indicate “disallowed” (e.g., represented by a value of “0”). The “disallowed” indication may be applied to the access requests coming from a higher-privileged entity, software, or process. For example, when the A/D indicator 230 is 0 for a given memory page of user data, the target SRPU rejects all access requests coming from entities with privilege levels 1, 2, and 3 for that given memory page. For example, in the AID_allowed table 210, access requests to user data from AID_s (which has a privilege level=3) are rejected as AID_s has a privilege level of 3. As such, user data can be protected from access by higher-privileged software”. (¶36). “At step 410, a source SRPU detects an access request from a source entity to access memory locations allocated to a target entity. At step 420, the source SRPU checks the AID_allowed table of the source entity for memory access information corresponding to the target AID. At step 430, the source SRPU determines whether the source entity can access the memory locations allocated to the target entity; e.g., the access is allowed if the target AID and the memory location to be accessed are in the AID_allowed table. The source SRPU rejects the access request at step 440 if it determines that the access request is disallowed. If the source SRPU determines that the access request is allowed, the source entity sends the access request to the target entity at step 450. At step 460, the target SRPU checks the AID_allowed table of the target entity for memory access information corresponding to the source AID. Based on the information, the target SRPU at step 470 determines whether the source entity can access the memory locations allocated to the target entity; e.g., the access is allowed if the source AID and the memory location to be accessed are in the AID_allowed table. The access is disallowed otherwise. Additionally, the access may be disallowed if the source AID has a privilege level greater than 0 and the A/D indicator corresponding to the memory location is 0 (“disallowed”), where the memory location stores user data. The target SRPU rejects the access request at step 480 if it determines that the access request is disallowed. The target SRPU grants the access request to the target entity at step 490 if it determines that the access request is allowed”. (Fig. 4, ¶43-¶44). “At step 810, the scheduler receives an indication to disallow access to a target entity's user data by higher-privileged software. The higher-privileged software is executed by a source entity identified by a source AID. In one embodiment, a user or an administrator may provide the indication of disallowed access to the system via an API. The scheduler executes, at step 820, AID_disallow on the data structure of the target entity (referred to as the “target data structure”) by setting the A/D indicators corresponding to the source AID to 0. More specifically, AID_disallow overwrites the default setting of the A/D indicators corresponding to the source AID in the target data structure; e.g., the default setting may be 1 to indicate “allowed,” and the new setting may be 0 to indicate “disallowed.” The target SRPU controls access from higher-privileged software based on, at least in part, the setting of the A/D indicators. At step 830, the target SRPU determines whether to disallow an access request based on the A/D indicators corresponding to the source AID and the requested memory location, and the privilege of the source AID. For example, the access request may indicate (source AID, target AID, requested memory_page_address). The target SRPU finds, from the target data structure, the source AID has a privilege level=3 and the A/D indicator of the requested memory_page_address is 0. As a result, the SRPU rejects the access request to protect the user data from access by a higher-privileged software.”. (Fig. 8, ¶49). Examiner submits that the applicant has argued regarding the different features of the TEEs, however none of the features is recited in the claim limitations and Chang clearly teaches, preventing a TEE entry instructions to access a TEE when the bit position of the data structure is reserved, as explained above. Thus combination of Li and Chang teaches the recited claim limitations, “TEE logic to support TEE usage, wherein the TEE logic is configured to at least in part: determine that a TEE feature is supported based at least on a value of a bit position in a data structure”. The motivation/suggestion for doing so would be to provide a reliable, effective, and scalable security mechanism for a secure computing system.
Applicant’s remark, filed on January 08, 2026 on the middle of page 5 regarding, “For example, the combination, as cited, does not appear to at least describe "TEE logic to support TEE usage, wherein the TEE logic is configured to at least in part: ... prevent a TEE entry instruction to access to a TEE when the bit position of the data structure is reserved." has been considered and addressed in above paragraph 10.
Applicant further recites similar remarks as listed above for dependent claims. Please see response for remarks in above paragraph 10 that clearly shows how the cited prior arts Li and Chang clearly teaches the claimed limitations.
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-3, 5-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US PGPUB. # US 2021/0034546, hereinafter “Li”), and further in view of Chang et al. (US PGPUB. # US 2021/0192056, hereinafter “Chang”).
Referring to Claims 1 and 9:
Regarding Claim 1, Li teaches,
An apparatus comprising:
execution circuitry configured to execute trusted execution environment (TEE) entry instructions; (Fig. 6, ¶65, “portion of memory 620 that cannot be entered into or exited from except via special instructions”, “Enclave 640 is provided as an example of a secure environment which, in conjunction with a secure processing engine 610, forms a trusted execution environment (TEE) 600”, ¶68-¶69, i.e. an execution circuitry is configured to execute a trusted execution environment)
TEE logic to support TEE usage, wherein the TEE logic is configured to at least in part: (Fig. 6, ¶65, “A TEE 600 is a combination of hardware, software, and/or memory allocation that provides the ability to securely execute instructions without interference from outside processes, in a verifiable way”, ¶68-¶69, “a program pointer cannot enter or exit enclave 640 without the use of special enclave instructions or directives”, i.e. a TEE logic that supports TEE usage)
Li does not teach explicitly,
determine that a TEE feature is supported based at least on a value of a bit position in a data structure; and
prevent a TEE entry instruction to access to a TEE when the bit position of the data structure is reserved.
However, Chang teaches,
determine that a TEE feature is supported based at least on a value of a bit position in a data structure; (Abstract, “Each of the TEEs and the REEs is identified by a corresponding access identifier (AID)”, ¶5, “TEE using a data structure including allowed AIDs and pointers to memory locations accessible by the allowed AIDs”, Fig. 1, ¶22-¶23, ¶31, Fig. 2, ¶33-¶34, ¶36, i.e. Examiner submits that a data structure has AIDs which are interpreted as bits and based on the value of the bit TEE feature are accessed (supported)) and
prevent a TEE entry instruction to access to a TEE when the bit position of the data structure is reserved. (Fig. 2, ¶36, “when the A/D indicator 230 is 0 for a given memory page of user data, the target SRPU rejects all access requests coming from entities with privilege levels 1, 2, and 3 for that given memory page”, Fig. 4(430, 440), ¶43, “The source SRPU rejects the access request at step 440 if it determines that the access request is disallowed”, Fig. 4(470, 480), ¶44, “The access is disallowed otherwise. Additionally, the access may be disallowed if the source AID has a privilege level greater than 0 and the A/D indicator corresponding to the memory location is 0 (“disallowed”)”, Fig. 8, ¶49, i.e. Examiner submits that TEE entry is rejected (not allow) for higher privileges (bits are > 0) when AID (bit position) in a data structure is 0 (reserved)).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Chang with the invention of Li.
Li teaches, an execution circuitry executes a trusted execution environment (TEE). Chang teaches, a data structure having AIDs controls access to the TEE based on the value of the AIDs. Therefore, it would have been obvious to have a data structure having AIDs controls access to the TEE based on the value of the AIDs of Chang with an execution circuitry executes a trusted execution environment (TEE) of Li to provide a reliable, effective, and scalable security mechanism for a secure computing system.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 9, it is a system claim of above apparatus claim 1 and therefore Claim 9 is rejected with the same rationale as applied against Claim 1 above.
Lee teaches, memory store a trusted execution environment (TEE). (Fig. 6, ¶64-¶65).
Referring to Claims 2 and 10:
Regarding Claim 2 rejection of Claim 1 is included and for the same motivation Li teaches,
The apparatus of claim 1, wherein the TEE logic is microcode. (¶65, ¶109).
Regarding Claim 10 rejection of Claim 9 is included and Claim 10 is rejected with the same rationale as applied against Claim 2 above.
Referring to Claims 3 and 11:
Regarding Claim 3 rejection of Claim 1 is included and for the same motivation Li teaches,
The apparatus of claim 1, wherein the TEE logic software stored in memory. (¶65).
Regarding Claim 11 rejection of Claim 9 is included and Claim 11 is rejected with the same rationale as applied against Claim 3 above.
Referring to Claims 5 and 13:
Regarding Claim 5 rejection of Claim 1 is included and for the same motivation Li does not teach explicitly,
The apparatus of claim 1, wherein the data structure is an attributes field.
However, Chang teaches,
The apparatus of claim 1, wherein the data structure is an attributes field. (¶23, Fig. 2, ¶33-¶34).
Regarding Claim 13 rejection of Claim 9 is included and Claim 13 is rejected with the same rationale as applied against Claim 5 above.
Referring to Claims 6 and 14:
Regarding Claim 6 rejection of Claim 1 is included and for the same motivation Li does not teach explicitly,
The apparatus of claim 1, wherein the data structure is a feature-disabled structure.
However, Chang teaches,
The apparatus of claim 1, wherein the data structure is a feature-disabled structure. (Fig. 2, ¶34, ¶36, Fig. 4(470, 480), ¶44, “The access is disallowed otherwise. Additionally, the access may be disallowed if the source AID has a privilege level greater than 0 and the A/D indicator corresponding to the memory location is 0 (“disallowed”)”)
Regarding Claim 14 rejection of Claim 9 is included and Claim 14 is rejected with the same rationale as applied against Claim 6 above.
Referring to Claims 7 and 15:
Regarding Claim 7 rejection of Claim 1 is included and for the same motivation Li does not teach explicitly,
The apparatus of claim 1, wherein the data structure is to be updated upon a microcode patch rollback to make the bit position reserved.
However, Chang teaches,
The apparatus of claim 1, wherein the data structure is to be updated upon a microcode patch rollback to make the bit position reserved. (¶40).
Regarding Claim 15 rejection of Claim 9 is included and Claim 15 is rejected with the same rationale as applied against Claim 7 above.
Referring to Claims 8 and 16:
Regarding Claim 8 rejection of Claim 1 is included and for the same motivation Li does not teach explicitly,
The apparatus of claim 1, wherein the data structure is to be updated upon a microcode update to make the bit position indicate support for the TEE feature.
However, Chang teaches,
The apparatus of claim 1, wherein the data structure is to be updated upon a microcode update to make the bit position indicate support for the TEE feature. (¶40).
Regarding Claim 17 rejection of Claim 9 is included and for the same motivation Li does not teach explicitly,
The system of claim 9, wherein the data structure is to be updated upon a microcode update to make the bit position indicate support for the TEE feature.
However, Chang teaches,
The system of claim 9, wherein the data structure is to be updated upon a microcode update to make the bit position indicate support for the TEE feature. (¶31-¶32).
Regarding Claim 18 rejection of Claim 9 is included and for the same motivation Li does not teach explicitly,
The system of claim 9, wherein the memory is to store a feature-disabled structure.
However, Chang teaches,
The system of claim 9, wherein the memory is to store a feature-disabled structure. (Fig. 2, ¶34, ¶36, Fig. 4(470, 480), ¶44).
Regarding Claim 19 rejection of Claim 9 is included and for the same motivation Li does not teach explicitly,
The system of claim 9, wherein the memory is to store a feature-enabled structure.
However, Chang teaches,
The system of claim 9, wherein the memory is to store a feature-enabled structure. (Fig. 2, ¶34, ¶36, Fig. 6, ¶46).
Regarding Claim 20 rejection of Claim 9 is included and for the same motivation Li does not teach explicitly,
The system of claim 9, wherein the data structure further comprises a plurality of reserved bits.
However, Chang teaches,
The system of claim 9, wherein the data structure further comprises a plurality of reserved bits. (Fig. 2, ¶33-¶36).
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US PGPUB. # US 2021/0034546, hereinafter “Li”), and further in view of Chang et al. (US PGPUB. # US 2021/0192056, hereinafter “Chang”), and further in view of Caspi et al. (US PGPUB. 3 US 2019/0042671, hereinafter “Caspi”).
Referring to Claims 4 and 12:
Regarding Claim 4 rejection of Claim 1 is included and combination of Li and Chang does not teach explicitly,
The apparatus of claim 1, wherein the data structure is a thread control structure.
However, Caspi teaches,
The apparatus of claim 1, wherein the data structure is a thread control structure. (Fig. 2, ¶46, ¶59).
As per KSR vs Teleflex, combining prior art elements according to known methods (device, product) to yield predictable results may be used to create a prima facie case of obviousness.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Caspi with the invention of Li in view of Chang.
Li in view of Chang teaches, an execution circuitry executes a trusted execution environment (TEE) and a data structure having AIDs controls access to the TEE based on the value of the AIDs. Caspi teaches, control page as a thread data structure. Therefore, it would have been obvious to have control page as a thread data structure of Caspi into the teachings of Li in view of Chang for ensuring security and integrity of private memory contents.
KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007).
Regarding Claim 12 rejection of Claim 9 is included and Claim 12 is rejected with the same rationale as applied against Claim 4 above.
Conclusion
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Briongos (US # 2022/0284098) discloses, a method for detecting a microarchitectural attack on a trusted execution environment (TEE) and/or a violation of an expected execution flow of an application running in the TEE includes implementing a counting thread. An eviction set is loaded in a transaction. The eviction set corresponds to a cache set used by an operation of the application such that a transactional abort is received upon the operation being executed. A value of the counting thread is read upon receiving the transactional abort. These steps are repeated for a next operation of the application running in the TEE and an execution time is measured for the operation based on a difference between the values of the counting thread. The measured execution time for the operation is compared with an expected execution time to detect one or more variations that indicate the microarchitectural attack and/or the violation of the expected execution flow.
Stopp et al. (WO # 2022/128142) discloses, an apparatus and a method for protection of a data memory. The apparatus comprises a processor coupled to the data memory. The processor and the data memory are configured to implement a kernel in which an operating system is executed. The kernel is configured to execute a memory manager that determines access that the kernel has to the data memory. The processor is configured to provide a higher-privilege execution environment that is managed by the memory manager that controls access that one or more executable codes have to one or more portions of the data memory. The kernel is further configured to support a plurality of data contexts that are accessible to the one or more executable codes, while denying the one or more executable codes access to data contexts that are unrelated to the one or more executable codes.
Bursell et al. (US # 2022/0171847) discloses, a method for detecting and handling attacks on processes executing within a trusted execution environment (TEE) are disclosed. In one implementation, a processing device may detect by a first process an event indicating that a first process executing in a TEE of a host computer system is under attack from a second process executing on the host computer system. the processing device may set a flag within a memory region of the TEE indicating that the first process is under attack. The processing device may further perform, in view of an attack response policy associated with the first process, an action responsive to detecting the event.
Tsirkin et al. (US # 2022/0129593) discloses, a system includes a memory, a processor in communication with the memory, a supervisor, and a trusted execution environment (“TEE”). The TEE includes an introspection module and is configured to execute the introspection module on a workload according to an introspection security policy. Additionally, the TEE is configured to generate an introspection result for the workload. The introspection security policy specifies at least one of (i) a portion of the TEE that is exposed to the introspection module and (ii) at least one of an accelerator and a device the introspection module has access to. Additionally, the introspection module is configured to validate the workload. The introspection result is one of a passing result and a failing result.
Li et al. (US # 2021/0397698) discloses, a method for performing a remote attestation for creation of a trusted execution environment (TEE) using a virtual secure enclave device running in a virtualized environment utilizes a trusted bootloader appliance in a TEE virtual computing instance, which is created in response to a request for a TEE from a software process running in the system. The trusted bootloader appliance manages the provisioning of a TEE in the TEE virtual computing instance for the software process. The remote attestation includes performing a first stage attestation on the trusted bootloader appliance by a hardware platform of the computer system and performing a second stage attestation on the provisioned TEE by the trusted bootloader appliance.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARSHAN I DHRUV whose telephone number is (571)272-4316. The examiner can normally be reached M-F 9:00 AM-5:00 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/DARSHAN I DHRUV/ Primary Examiner, Art Unit 2498