DETAILED ACTION
The following claims are pending in this office action: 1-2, 4-12 and 14-20
Claims 1, 11 and 20 are independent claims.
The following claims are amended: 1, 5, 8-9, 11, 15 and 18-20
The following claims are new: -
The following claim is cancelled: 3 and 13
Claims 1-2, 4-12 and 14-20 are rejected. This rejection is FINAL.
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 .
Previous Rejections and/or Objections Withdrawn
The objections to claims 8 and 18 are withdrawn based on the amendments.
The 35 U.S.C. § 112(b) rejections to claims 5, 15 and 19 are withdrawn based on the amendments.
RESPONSE TO ARGUMENTS
Applicant’s arguments in the amendment filed 05/28/2026 have been fully considered but are moot in view of new grounds of rejection necessitated by amendment.
Applicant notes: Independent claim 1 is amended incorporate the subject matter of dependent claim 3 and to further clarify the generation of the cryptographic proof. This limitation is disclosed by Rogers et al. (US Pub. 2023/0297696) as explained below and rejected accordingly.
Independent claims 11 and 20 are amended in a similar way to claim 1. The amended limitations are disclosed by Rogers et al. (US Pub. 2023/0297696) as explained below and rejected accordingly.
Dependent claims 2, 4-10, 12 and 14-20 depend on independent claims 1 and 11. The amended elements in the claims are disclosed by Rogers et al. (US Pub. 2023/0297696) as explained below, and so any additional features to the dependent claims are rejected accordingly.
Additionally, Applicant’s arguments have been fully considered, but are not persuasive.
Applicant’s position is that the searched prior art does not using a cryptographic proving key to provide cryptographic proof regarding whether a TEE is correctly implemented.
…The Office Action appears to rely on equating data authenticity with computational integrity. The Office Action, p. 4, asserts that Wei teaches "generating, using the cryptographic proving key, a cryptographic proof that indicates whether the TEE is correctly implemented" by pointing to Wei's disclosure of a service TEE that "signs the encrypted result using a sign private key 406... so as to produce a signed result 466" (Wei at para. [0081]). However, Applicant asserts that Wei's "signed result 466" is a standard digital signature applied to output of a smart contract operation. While a digital signature can prove that a specific entity (the TEE holding the private key) produces a result, it does not provide cryptographic proof regarding whether the TEE itself is correctly implemented according to expected behavior specified by a verification circuit. That is, digitally signing a payload does not prove the structural or operational correctness of the signing environment's underlying microcode.
If an Applicant disagrees with any factual findings by the Office, an effective traverse of a rejection based wholly or partially on such findings must include a reasoned statement explaining why the Applicant believes the Office has erred substantively as to the factual findings. A mere statement or argument that the Office has not established a prima facie case of obviousness will not be considered substantively adequate to rebut the rejection or an effective traverse of the rejection under 37 CFR 1.111(b). See MPEP §2141. During patent prosecution, “claims must be given their broadest reasonable interpretation in light of the specification… Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitations that are not part of the claim.” See MPEP § 2111. "A person of ordinary skill in the art is also a person of ordinary creativity, not an automaton." KSR Int'l Co. sv. Teleflex Inc., 550 U.S. 398, 421, 82 USPQ2d 1385, 1397 (2007). "[I]n many cases a person of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle." Id. at 420, 82 USPQ2d 1397. Office personnel may also take into account "the inferences and creative steps that a person of ordinary skill in the art would employ." Id. at 418, 82 USPQ2d at 1396. Also see MPEP 2141.03. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Wei teaches a service TEE that usings a signing key to generate a signed result that is provided to a client to provide a verification of the TEE. Raghuram teaches that attestation allows a relying party to verify the integrity of a remote software. Raghuram, para. 0003. An attestation policy defines the criteria used to validate/attest the application. Raghuram, para. 0094. A trust service provider receives the attestation policy. Raghuram, para. 0104 and Fig. 4. Furthermore, Rogers teaches an attestation service that tracks valid software/hardware configurations for a TEE and verifying it in accordance with security policies using a signed attestation report. Rogers, para. 0050 and para. 0134. Together, the references teach using both a signing key (cryptographic proving key that proves the identity of the TEE) and an attestation service (verification circuit) to generate a signed report regarding whether a TEE is valid (the cryptographic proof).
Here, Applicant argues that the cited prior art does not teach “generating, using the cryptographic proving key, a cryptographic proof that indicates whether the TEE is correctly implemented” as a signature is an authentication/authorization function as opposed to “computational integrity” or “cryptographic proof regarding whether the TEE itself is correctly implemented.” However, this is an impermissibly narrow interpretation of the claim limitations. Wei clearly teaches that the signed result of Wei “allow later verification of the signed result.” A signing operation is plainly a cryptographic operation. The result of the signing operation is clearly also a cryptographic proof that indicates the authenticity of TEE. See, for example, authenticity as “cryptographic proof that the service TEE 306a exists.” The phrase “the TEE is correctly implemented” does not necessarily mean “computational integrity”, but could also mean whether the TEE may be correctly authenticated, which is another type of implementation. Furthermore, in combination with Raghuram and Rogers, its clear that a signed attestation report, which is also generated using a signing key, may also prove “computational integrity.” As Applicant does not take into consideration the broadest reasonable interpretation of the claim and the effect of the combination of the references, the argument is not persuasive.
Applicant further argues that Raghuram does not teach a verification circuit:
…To cure Wei's deficiency in teaching a "verification circuit," the Office Action, p. 4, relies on Raghuram - equating Raghuram's "attestation policy" with the claimed verification circuit. Applicant asserts that this mapping is technically flawed. In Raghuram, an attestation policy is a set of criteria used by a remote verifier (the Trust Authority) to appraise evidence (Raghuram at paras. [0094] and [0104]). However, it is not a cryptographic circuit (such as a zero-knowledge circuit) received by the prover (the data processing system) to generate a proof.
Raghuram teaches an attestation policy that defines the criteria used to validate/attest an application in a TEE which is obtained by a trust service provider which results in a cryptographic attestation token. Raghuram, para. 0094 and 0104-0105. The trust service provider is a data processing system. Raghuram, para. 0197. Applicant’s own specifications indicate: “verification circuit 122 specifies the instructions and correct operation in a manner that can be applied by a verifier system to ... indicates whether the TEE, as implemented by the data processing system, behaves as specified” Therefore, as the policy performs the same function as the verification circuit Raghuram teaches a “verification circuit” as claimed.
Here, Applicant argues that the attestation policy is not a “verification circuit” as it is not a cryptographic circuit. However, the function performed by the attestation policy is verification of parameters of a TEE. Furthermore, Applicant recites a “cryptographic circuit” which is not claimed. Nor is a “zero-knowledge circuit” claimed. Because Applicant’s interpretation clearly runs counter to the example in the instant specification for a verification circuit, the argument cannot be a reasoned statement. As Applicant does not take into consideration the broadest reasonable interpretation of the claim, the argument is not persuasive.
Finally, Applicant argues that Rogers does not teach the amended limitations:
… The Office Action, pp. 12-13, cites to Rogers for the limitation regarding microcode instructions. However, Applicant asserts that Rogers also has not been shown to cure the deficiencies of the proposed combination of Wei and Raghuram. The Office Action, p. 13, cites to Rogers for disclosing that an attestation service "may track valid software and/or hardware configurations" (Rogers at para. [0050]) and that measurements may correspond to software including "microcode on any device used to implement the composite TEE" (Rogers at para. [0146]). Tracking valid configurations and capturing measurements of microcode is different from Applicant's claims. Rogers has not been shown to teach or to suggest a verification circuit that specifies expected behavior of the TEE in response to triggering particular microcode instructions. Furthermore, Applicant asserts that Rogers has not been shown to teach or to suggest generating a cryptographic proof using the verification circuit to indicate whether the TEE is correctly implemented according to that expected behavior.
These limitations are taught by Rogers as explained below, and as a result, the argument presented here is moot.
In the interest of compact prosecution, Examiner notes that it appears the application is directed towards zero knowledge proofs and zero-knowledge proving keys to implement the verification but contains no limitations directed to these elements, except for claim 6 and 16 which recites “zero-knowledge proof” in an unconnected manner. For example, none of the elements of a zero-knowledge proof are described to interact or be used with the TEE, cryptographic proving key or the verification function. In particular para. 0027-0028 and para. 0044 specifies a TEE formal specification that is formed from an abstraction of microcode instructions to the TEE where the formal specification is generated without having to get access to the actual code used by the data processing system to implement the TEE which is used to generate, by the zero-knowledge verification engine the zero-knowledge verification circuit and the zero-knowledge verification key.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-5, 7-12, 14-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wei et al. (US Pub. 2021/0306164) (hereinafter “Wei”) in view of Raghuram et al. (US Pub. 2024/0160717) (hereinafter “Raghuram”) and in view of Rogers et al. (US Pub. 2023/0297696) (hereinafter “Rogers”).
As per claim 1, Wei teaches a computer-implemented method comprising: ([Wei, abstract] “Disclosed herein are methods ... operations in a trusted execution environment ... on the computing device”)
receiving a cryptographic proving key ([Wei, para. 0073] “the key management center 310 can provide ... a sign private key 406 to the KM TEE 308a of the node 304a”; [para. 0081] “the service TEE ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 ... This can allow later verification [cryptographic proving]”) at a data processing system having a trusted execution environment (TEE); ([para. 0051] “each node can be a computing device ... a server”; [para. 0052] “Node 304a includes a service TEE 306a ... the service TEE .. is a secure application environment implemented using a TEE technology”)
generating, using the cryptographic proving key, a cryptographic proof that indicates whether the TEE is correctly implemented; and ([Wei, para. 0081] “the service TEE ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 [a cryptographic proof] ... This can allow later verification [indicates whether the TEE is correctly implemented as the TEE signs the result]”)
providing, to a recipient system, the cryptographic proof. ([Wei, para. 0082] “the service TEE ... store the signed result ... in a blockchain [providing] ... the client [to a recipient system] ... can access ... the signed result [cryptographic proof]”)
Wei does not clearly teach receiving a verification circuit at a data processing system having a trusted execution environment (TEE); wherein the verification specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Raghuram teaches receiving a verification circuit ([Raghuram, para. 0003] “Attestation ... allows a relying party to verify the integrity of a remote software ... executing in a TEE”; [para. 0094] “The attestation policy defines the criteria used ... to validate/attest the application”; [para. 0104] “the trust service provider obtains ... an attestation policy [verification circuit]”) at a data processing system having a trusted execution environment (TEE). ([Fig. 4] The Trust SP/trust service provider includes a TEE; [para. 0197] “a computing system at a trust service provider”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei with the teachings of Raghuram to include receiving a verification circuit at a data processing system having a trusted execution environment (TEE). One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing a customer to indicate what policy needs to be verified as part of trust verification, providing improved security. (Raghuram, para. 0035; para. 0100)
Wei in view of Raghuram does not clearly teach wherein the verification specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Rogers teaches wherein the verification specifies expected behavior of the TEE ([Rogers, para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 ... the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”) in response to triggering particular microcode instructions used to implement the TEE; ([Para. 0146] “Measurements captured [in response to triggering] using an attestation report(s) may correspond to code ... used by the attestation service(s) 112 to verify the composite TEE 150 may capture measurements of all software that is running in and/or is to be run in the composite TEE 150 ... include ... microcode on any device used to implement the composite TEE 150”)
and generating, using the cryptographic proving key ([Rogers, para. 0072] “the secure processor 146 may obtain data ... and sign the data with the private key(s) [the cryptographic proving key] stored within the GPU 104”; [para. 0134] “a secure and/or measured boot sequence of the GPU 104 ... include ... enabling any of the properties of the GPU TEE 172 using GPU hardware firmware ... cryptographically signed record(s) of the version of firmware which are running on the GPU 104 [the TEE as the GPU is a TEE] ... generated into an attestation report”) and the verification circuit, ([para. 0050] “the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”; [para. 0134] “implementing, enabling, and/or configuring the protected region(s) 336 is part of a secure and/or measured boot sequence of the GPU 104, which ... include configuring and/or enabling any of the properties [using the verification circuit as the circuit tracks the properties] of the GPU TEE 172 using GPU hardware and firmware”) a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. ([Para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 [according to the expected behavior specified by the verification circuit] ... By verifying the properties of the composite TEE 150 ... entities may determine whether the composite TEE 150 is to operate in accordance with security policies” [indicates whether the TEE correctly implemented]”; [para. 0140] “The attestation manager 140 may use one or more attestation reports [cryptographic proof] generated ... to verify the one or more properties for the composite TEE [that indicates whether the TEE is correctly implemented according to the expected behavior]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei in view of Raghuram with the teachings of Rogers to include wherein the verification specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of blocking untrusted entities from accessing code inside the TEE to maintain confidentiality of user data and to protect data in transit as well as protecting data and code while it is in use that prevents unauthorized access or modification of applications and data while in use. (Rogers, para. 0002; para.0028; and para. 0050)
As per claim 2, Wei in view of Raghuram and Rogers teaches claim 1.
Wei in view of Rogers does not clearly teach wherein the verification circuit is generated by a trusted third party based on a TEE formal specification.
However, Raghuram teaches wherein the verification circuit is generated by a trusted third party ([Raghuram, para. 0082] “a TEE (Trusted Execution Environment) attestation service which is composed of ... a policy creator service”; [para. 0094] “creates [generate] an attestation policy [verification policy] for the application ... with the TEE policy creation operations”; [para. 0102] “a trust service provider [by a trusted third party] operating an attestation service”) based on a TEE formal specification. ([Para. 0041 types of attestation, based on what compute asset a user wants to verify ... such as ... Attestation of one or more TEEs ... includes the verification of a secure enclave (e.g., Intel® SGX enclave), trust domain-supported virtual machine (e.g., Intel® TDX VM), and other types of TEEs including AMD® SEV_SNP, and others [formal specification]”; [para. 0048] “User can define policies [verification circuit] ... used to verify against these compute assets [based on formal specifications”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Wei, Raghuram and Rogers for the same reasons as disclosed above.
As per claim 4, Wei in view of Raghuram and Rogers teaches claim 3.
Wei in view of Raghuram does not clearly teach wherein the generating the cryptographic proof is triggered each time the TEE is rebooted.
However, Rogers teaches wherein the generating the cryptographic proof is triggered each time the TEE is rebooted. ([Rogers, para. 0114-0115] “components of the system ... causes ... reset ... The reset ... initiate operations to ... instantiate ... the TEE ... On reset, the memory ...scrubbed”; [para. 0134] “implementing [triggered each time, as the reset initiates operations to set up the protected regions and instantiates the TEE] ... the protected region [the TEE - see para. 0118 describing the protected region as in the TEE – also see Fig. 6] ... is part of a ... measured boot sequence [time the TEE is rebooted] ... In a measured boot, a cryptographically signed record(s) of the versions of firmware ... may be generated into an attestation report(s) [the cryptographic proof] that can be requested and validated ... using the attestation manager”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei in view of Raghuram with the teachings of Rogers to include wherein the generating the cryptographic proof is triggered each time the TEE is rebooted. One of ordinary skill in the art would have been motivated to make this modification because such a technique of verifying the properties of the TEE would provide the benefit of ensuring that the devices of the system are operating in accordance with confidential computing. (Rogers, para. 0050)
As per claim 5, Wei in view of Raghuram and Rogers teaches claim 1.
Wei does not clearly teach wherein providing the cryptographic proof comprises providing the cryptographic proof that comprises a cryptographic primitive and enables the recipient system to verify, using the cryptographic primitive, a verification process for attestation data.
However, Raghuram teaches wherein providing the cryptographic proof comprises providing the cryptographic proof that comprises a cryptographic primitive ([Raghuram, para. 0106] “the attestation token [cryptographic primitive] is provided ... to the relying party as a proof of trust [cryptographic proof] ... the token ... serving as the proof of trust”) and enables the recipient system to verify, using the cryptographic primitive, a verification process for attestation data. ([Para. 0107] “additional operations ... performed to repeat the attestation evaluation and token generation operations [using the cryptographic primitive], on behalf of a relying party ... with the roles of the relying and requesting parties being reversed ... allow additional attestation evidence [for attestation data] providing additional trust claims for the originally relying party to be evaluated by the originally requesting party, to enable the two parties to perform mutual attestation [verify the verification process] with each other [enables the recipient system to verify]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei with the teachings of Raghuram to include wherein providing the cryptographic proof comprises providing the cryptographic proof that comprises a cryptographic primitive and enables the recipient system to verify, using the cryptographic primitive, a verification process for attestation data. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of ensuring that both services are running in a valid trusted environment such that the customers of service providers can independently verify the trustworthiness of their workloads on these service providers. (Raghuram, para. 0076; and para. 0085)
As per claim 7, Wei in view of Raghuram and Rogers teaches claim 1.
Wei also teaches wherein providing the cryptographic proof comprises providing, to the recipient system, the cryptographic proof ([Wei, para. 0082] “the service TEE ... store the signed result ... in a blockchain [providing] ... the client [to a recipient system] ... can access ... the signed result [cryptographic proof]”) to cause the recipient system to verify the cryptographic proof using a cryptographic verification key. ([Para. 0081] “This can allow later verification of the signed result [the cryptographic proof] by ... a client [recipient system] using the verification public key 416 [using a cryptographic verification key]”)
As per claim 8, Wei in view of Raghuram and Rogers teaches claim 7.
Wei also teaches wherein providing the cryptographic proof comprises providing, to the recipient system, the cryptographic proof ([Wei, para. 0082] “the service TEE ... store the signed result ... in a blockchain [providing] ... the client [to a recipient system] ... can access ... the signed result [cryptographic proof]”) to cause the recipient system to verify the cryptographic proof using the cryptographic verification key ([Para. 0081] “This can allow later verification of the signed result [the cryptographic proof] by ... a client [recipient system] using the verification public key 416 [using a cryptographic verification key]”) that was previously provided to the recipient system by a trusted third party system. ([Para. 0082] “the client 480 can retrieve [previously provided to the recipient system] the verification public key 416 from the key management center 310 [trusted third party system – see para. 0059 where the key management center is trusted as either a trusted central authority or a trusted decentralized management scheme] ... as previously described [previously provided] ... and can access and decrypt the signed result 466 using the verification public key 416 [verify the cryptographic proof]”)
Wei does not clearly teach a trusted third party system that generated the verification circuit.
However, Raghuram teaches a trusted third party system that generated the verification circuit. ([Raghuram, para. 0082] “a TEE (Trusted Execution Environment) attestation service which is composed of ... a policy creator service”; [para. 0094] “creates [generate] an attestation policy [verification policy/circuit] for the application ... with the TEE policy creation operations”; [para. 0102] “a trust service provider [by a trusted third party] operating an attestation service”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Wei, Raghuram and Rogers for the same reasons as disclosed above.
As per claim 9, Wei in view of Raghuram and Rogers teaches claim 7.
Wei also teaches generating, by a trusted third party system, the cryptographic proving key and the cryptographic verification key. ([Wei, para. 0059] “the key management center... authority [trusted third party] to deploy ... keys”; [para. 0073] “the key management center ... provide ... a sign private key 406 ... The key management center ... also hosts ... a verification public key”)
As per claim 10, Wei in view of Raghuram and Rogers teaches claim 1.
Wei also teaches wherein: the data processing system comprises trusted hardware that is configured to perform one or more data computations for the recipient system. ([Wei, para. 0082] “The client 480 [for the recipient system] can then request that the next operation [one or more computations] ... be executed by the service TEE [trusted hardware/data processing system]”)
As per claim 11, Wei teaches a system comprising: ([Wei, abstract] “Disclosed herein are ... systems ... operations in a trusted execution environment ... on the computing device”)
one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising: ([Wei, para. 0008] “The system includes one or more processors [computers], and a computer-readable storage medium [storage devices] coupled to the one or more processors having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein”)
receiving, at a data processing system, a cryptographic proving key ([Wei, para. 0073] “the key management center 310 can provide ... a sign private key 406 to the KM TEE 308a of the node 304a”; [para. 0081] “the service TEE ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 ... This can allow later verification [cryptographic proving]”) at a data processing system having a trusted execution environment (TEE); ([para. 0051] “each node can be a computing device ... a server”; [para. 0052] “Node 304a includes a service TEE 306a ... the service TEE .. is a secure application environment implemented using a TEE technology”)
generating, at the data processing system and using the cryptographic proving key, a cryptographic proof that indicates whether the TEE is correctly implemented; and ([Wei, para. 0081] “the service TEE [at the data processing system] ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 [a cryptographic proof] ... This can allow later verification [indicates whether the TEE is correctly implemented as the TEE signs the result]”)
providing, to a recipient system, the cryptographic proof. ([Wei, para. 0082] “the service TEE ... store the signed result ... in a blockchain [providing] ... the client [to a recipient system] ... can access ... the signed result [cryptographic proof]”)
Wei does not clearly teach receiving, at a data processing system, a verification circuit at a data processing system having a trusted execution environment (TEE); wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Raghuram teaches receiving, at a data processing system, a verification circuit ([Raghuram, para. 0003] “Attestation ... allows a relying party to verify the integrity of a remote software ... executing in a TEE”; [para. 0094] “The attestation policy defines the criteria used ... to validate/attest the application”; [para. 0104] “the trust service provider [at a data processing system] obtains ... an attestation policy [verification circuit]”) at a data processing system having a trusted execution environment (TEE). ([Fig. 4] The Trust SP/trust service provider includes a TEE; [para. 0197] “a computing system at a trust service provider”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei with the teachings of Raghuram to include receiving, at a data processing system, a verification circuit at a data processing system having a trusted execution environment (TEE). One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing a customer to indicate what policy needs to be verified as part of trust verification, providing improved security. (Raghuram, para. 0035; para. 0100)
Wei in view of Raghuram does not clearly teach wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Rogers teaches wherein the verification circuit specifies expected behavior of the TEE ([Rogers, para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 ... the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”) in response to triggering particular microcode instructions used to implement the TEE; ([Para. 0146] “Measurements captured [in response to triggering] using an attestation report(s) may correspond to code ... used by the attestation service(s) 112 to verify the composite TEE 150 may capture measurements of all software that is running in and/or is to be run in the composite TEE 150 ... include ... microcode on any device used to implement the composite TEE 150”)
and generating, using the cryptographic proving key ([Rogers, para. 0072] “the secure processor 146 may obtain data ... and sign the data with the private key(s) [the cryptographic proving key] stored within the GPU 104”; [para. 0134] “a secure and/or measured boot sequence of the GPU 104 ... include ... enabling any of the properties of the GPU TEE 172 using GPU hardware firmware ... cryptographically signed record(s) of the version of firmware which are running on the GPU 104 [the TEE as the GPU is a TEE] ... generated into an attestation report”) and the verification circuit, ([para. 0050] “the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”; [para. 0134] “implementing, enabling, and/or configuring the protected region(s) 336 is part of a secure and/or measured boot sequence of the GPU 104, which ... include configuring and/or enabling any of the properties [using the verification circuit as the circuit tracks the properties] of the GPU TEE 172 using GPU hardware and firmware”) a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. ([Para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 [according to the expected behavior specified by the verification circuit] ... By verifying the properties of the composite TEE 150 ... entities may determine whether the composite TEE 150 is to operate in accordance with security policies” [indicates whether the TEE correctly implemented]”; [para. 0140] “The attestation manager 140 may use one or more attestation reports [cryptographic proof] generated ... to verify the one or more properties for the composite TEE [that indicates whether the TEE is correctly implemented according to the expected behavior]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei in view of Raghuram with the teachings of Rogers to include wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of blocking untrusted entities from accessing code inside the TEE to maintain confidentiality of user data and to protect data in transit as well as protecting data and code while it is in use that prevents unauthorized access or modification of applications and data while in use. (Rogers, para. 0002; para.0028; and para. 0050)
As per claim 12, the claim language is identical or substantially similar to that of claim 2. Therefore, it is rejected under the same rationale applied to claim 2.
As per claim 14, the claim language is identical or substantially similar to that of claim 4. Therefore, it is rejected under the same rationale applied to claim 4.
As per claim 15, the claim language is identical or substantially similar to that of claim 5. Therefore, it is rejected under the same rationale applied to claim 5.
As per claim 17, the claim language is identical or substantially similar to that of claim 7. Therefore, it is rejected under the same rationale applied to claim 7.
As per claim 18, the claim language is identical or substantially similar to that of claim 8. Therefore, it is rejected under the same rationale applied to claim 8.
As per claim 19, the claim language is identical or substantially similar to that of claim 5. Therefore, it is rejected under the same rationale applied to claim 5.
As per claim 20, Wei teaches one or more non-transitory computer storage media encoded with computer program instructions that when executed by one or more computers cause the one or more computers to perform operations comprising: ([Wei, para. 0007] “one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors [computers], cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein”)
receiving a cryptographic proving key ([Wei, para. 0073] “the key management center 310 can provide ... a sign private key 406 to the KM TEE 308a of the node 304a”; [para. 0081] “the service TEE ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 ... This can allow later verification [cryptographic proving]”) at a data processing system having a trusted execution environment (TEE); ([para. 0051] “each node can be a computing device ... a server”; [para. 0052] “Node 304a includes a service TEE 306a ... the service TEE .. is a secure application environment implemented using a TEE technology”)
generating, using the cryptographic proving key, a cryptographic proof that indicates whether the TEE is correctly implemented; and ([Wei, para. 0081] “the service TEE ... signs the encrypted result using a sign private key 406 provided by the KM TEE 308a to the service TEE 306a, so as to produce a signed result 466 [a cryptographic proof] ... This can allow later verification [indicates whether the TEE is correctly implemented as the TEE signs the result]”)
providing, to a recipient system, the cryptographic proof. ([Wei, para. 0082] “the service TEE ... store the signed result ... in a blockchain [providing] ... the client [to a recipient system] ... can access ... the signed result [cryptographic proof]”)
Wei does not clearly teach receiving a verification circuit at a data processing system having a trusted execution environment (TEE); wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Raghuram teaches receiving a verification circuit ([Raghuram, para. 0003] “Attestation ... allows a relying party to verify the integrity of a remote software ... executing in a TEE”; [para. 0094] “The attestation policy defines the criteria used ... to validate/attest the application”; [para. 0104] “the trust service provider obtains ... an attestation policy [verification circuit]”) at a data processing system having a trusted execution environment (TEE). ([Fig. 4] The Trust SP/trust service provider includes a TEE; [para. 0197] “a computing system at a trust service provider”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei with the teachings of Raghuram to include receiving a verification circuit at a data processing system having a trusted execution environment (TEE). One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing a customer to indicate what policy needs to be verified as part of trust verification, providing improved security. (Raghuram, para. 0035; para. 0100)
Wei in view of Raghuram does not clearly teach wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit.
However, Rogers teaches wherein the verification circuit specifies expected behavior of the TEE ([Rogers, para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 ... the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”) in response to triggering particular microcode instructions used to implement the TEE; ([Para. 0146] “Measurements captured [in response to triggering] using an attestation report(s) may correspond to code ... used by the attestation service(s) 112 to verify the composite TEE 150 may capture measurements of all software that is running in and/or is to be run in the composite TEE 150 ... include ... microcode on any device used to implement the composite TEE 150”)
and generating, using the cryptographic proving key ([Rogers, para. 0072] “the secure processor 146 may obtain data ... and sign the data with the private key(s) [the cryptographic proving key] stored within the GPU 104”; [para. 0134] “a secure and/or measured boot sequence of the GPU 104 ... include ... enabling any of the properties of the GPU TEE 172 using GPU hardware firmware ... cryptographically signed record(s) of the version of firmware which are running on the GPU 104 [the TEE as the GPU is a TEE] ... generated into an attestation report”) and the verification circuit, ([para. 0050] “the attestation service 112 [verification circuit] may track valid software and/or hardware configurations for the composite TEE 150 that include the one or more properties ... verifying the properties of the composite TEE 150 [expected behavior of the TEE]”; [para. 0056] “this information may be used to generate an attestation report”; [para. 0134] “implementing, enabling, and/or configuring the protected region(s) 336 is part of a secure and/or measured boot sequence of the GPU 104, which ... include configuring and/or enabling any of the properties [using the verification circuit as the circuit tracks the properties] of the GPU TEE 172 using GPU hardware and firmware”) a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. ([Para. 0050] “the attestation service 112 may verify the data indicates one or more properties of the composite TEE 150 [according to the expected behavior specified by the verification circuit] ... By verifying the properties of the composite TEE 150 ... entities may determine whether the composite TEE 150 is to operate in accordance with security policies” [indicates whether the TEE correctly implemented]”; [para. 0140] “The attestation manager 140 may use one or more attestation reports [cryptographic proof] generated ... to verify the one or more properties for the composite TEE [that indicates whether the TEE is correctly implemented according to the expected behavior]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei in view of Raghuram with the teachings of Rogers to include wherein the verification circuit specifies expected behavior of the TEE in response to triggering particular microcode instructions used to implement the TEE; and generating, using the cryptographic proving key and the verification circuit, a cryptographic proof that indicates whether the TEE is correctly implemented according to the expected behavior specified by the verification circuit. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of blocking untrusted entities from accessing code inside the TEE to maintain confidentiality of user data and to protect data in transit as well as protecting data and code while it is in use that prevents unauthorized access or modification of applications and data while in use. (Rogers, para. 0002; para.0028; and para. 0050)
Claim 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Wei in view of Raghuram and Rogers as applied to claim 1 above and further in view of De Feo et al. (US Pub. 2024/0073039) (hereinafter “De Feo”).
As per claim 6, Wei in view of Raghuram and Rogers does not clearly teach wherein the cryptographic proof comprises a zero-knowledge proof.
However, De Feo teaches wherein the cryptographic proof comprises a zero-knowledge proof. ([De Feo, para. 0017] “the TEE of the device of controller B may check that the token owner is controller A via zero knowledge proof ZKP protocol at the device of controller B”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wei in view of Raghuram and Rogers with the teachings of De Feo to include wherein the cryptographic proof comprises a zero-knowledge proof. One of ordinary skill in the art would have been motivated to make this modification because this specific implementation of zero-knowledge transfer offers a maximum security with respect to any intrusion attempt. (De Feo, para. 0136)
As per claim 16, the claim language is identical or substantially similar to that of claim 6. Therefore, it is rejected under the same rationale applied to claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kuman (US Pub. 2024/0095375) discloses microcode on a processor that implements a secure execution environment.
Moriarty et al. (US Pub. 2022/0019670) discloses determining expected behaviors of a TEE area, securing these behaviors in an encrypted and signed envelope and sending to enact controls.
Wang et al. (US Pub. 2025/0080349) discloses MPC protocol that generates an attestation token including digital signatures for executing the TEE where the MPC add heavy zero-knowledge computations to prove to the other side the protocol has been followed.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHE LIU whose telephone number is (571) 272-3634. The examiner can normally be reached on Monday - Friday: 8:30 AM to 5:30 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, Carl Colin can be reached on (571) 272-3862. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (IN USA OR CANADA) or (571) 272-1000.
/ZHE LIU/Examiner, Art Unit 2493
