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 .
Claim Status
As of the Office Action dated February 24, 2026 claims 1-9 were pending and claims 1-9 stood rejected. Claims 1, 5 and 7 have been amended. Claims 2 and 3 have been cancelled. No claims have been added. Claims 1 and 4-9 are therefore currently pending and are presented for examination on the merits.
Response to Arguments
Applicant’s argument with regard to the 35 U.S.C. § 101 rejection of claims 1-3 has been fully considered and is persuasive. Accordingly the rejection is being withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112(b) rejection of claim 2 has been fully considered and is persuasive. Accordingly the rejection is being withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112(a) rejection of claim 2 has been fully considered and is persuasive. Accordingly the rejection is being withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112(b) rejection of claim 7 has been fully considered and is persuasive. Accordingly the rejection is being withdrawn.
Applicant’s argument with regard to the 35 U.S.C. § 112(a) rejection of claim 7 has been fully considered but is not persuasive. Applicant argues on page 7 “that the Office Action has adopted an overly narrow interpretation of the term ‘enclave key’ by equating it strictly to the CPU-fused, hardware-bound sealing key”. However Applicant did not point to any portion of the specification that would lend itself to an alternate interpretation and as the term “enclave key” is a term with a particular meaning as understood by those of ordinary skill in the art as noted by the prior art Johnson et al. and El Hindi et al. references cited in the previous Office Action and even the Bao et al. reference cited in Applicant’s Information Disclosure Statement Examiner would respectfully maintain that Examiner is making an interpretation that is consistent with the teachings of the prior art. In fact the Bao reference explicitly describes the platform key as being the “sealing key” (Section (III)(A) in the section labeled “Data Sealing”). Therefore Examiner maintains that in order to be consistent with the established terms “platform key” and “enclave key” that the function of data sealing would have to be assigned to the platform key which is in contrast to the Applicant’s argument. As it applies to the claim itself both Johnson and Bao teach that the data within an enclave can only be shared between a group of HSEs by using the platform root key, not the enclave key which remains tied to the specific enclave. However Applicant’s claim is claiming that the enclave key itself is being transferred which is not taught by the prior art and as Applicant did not point to any particular section within the specification that allegedly teaches this feature (other than simply stating an obtained result) or any alteration to the SGX structure that would allow for the transfer of an enclave key to other CPUs on the same platform it is clear that the written description provides insufficient support for the claiming of the obtained result. Therefore the Examiner’s interpretation of the term “enclave key” is not “overly narrow” as argued by Applicant but is consistent with the established meaning for the term as it would be understood by those skilled in the art. Therefore Applicant’s argument must be held as unpersuasive and the rejection will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 1-6 and 8-9 as being unpatentable over Wang et al. “SPDS: A Secure and Auditable Private Data Sharing Scheme for Smart Grid Based on Blockchain”, IEEE Transaction on Industrial Informatics, Vol. 17, No. 11, November 2021, pp. 7788-7699, hereinafter referred to as Wang, in view of TEE Sockets API Specification Version 1.0, GlobalPlatform Device Technology, Public Release June 2015, 33 pages, hereinafter referred to as TEE Sockets API has been fully considered but is not persuasive. Whether or not Wang discloses merely attesting to the program or describes additional data being included in the attestation does not negate the finding that the Wang reference teaches what is actually in the claim which does not exclude other data from being present in the attestation request. Furthermore the written disclosure does not specify anything with regard to the nature of a “universal” attestation request and the properties of the attestation request Applicant is describing in argument have no root in the specification itself but are being fabricated post filing in order to attempt to disqualify legitimate prior art. Therefore there is no “fundamental frustration” of Wang and is simply an attempt by Applicant to use a baseless conclusory argument to overcome the cited combination of references.
Applicant’s further argument with regard to the 35 U.S.C. § 103 rejection of claims 1-6 and 8-9 as being unpatentable over Wang in view of TEE Sockets API has been fully considered but is not persuasive with regard to the verification via a light client or state proof. Applicant’s specification does not provide any discussion on what Applicant considers to be a state proof. Wang teaches atomic delivery of computing result result to Uc and payment p(α) to DO. “To prevent UC from acquiring the computing results without finishing the payment to DO, a two-phase atomic delivery protocol is developed as follows. When off-chain computation ends, the TEE delivers the encrypted results εhch with its signature to the UC via a secure channel. After UC checks the authenticity of the signature and sends a response message as an acknowledgment of the receipt, the TEE sends a computation completion message compM sg with its signature to the blockchain. Finally after observing a proof of publication of compM sg, i.e., σcomp, TEE sends the decryption key kCA to UC. Here, σcomp is the multisignature of validators on compM sg, and it is valid after signed by over two thirds of validators. As TEE’s delivery of compM sg can be verified by σcomp, only if σcomp has been generated (i.e., DO will get the payment according to the DAUC contract), the description key is then released (i.e. UC acquires the computing results). Thereby, the atomic delivery is ensured.” (Wang at (IV)(C)). Given that there is no description in the specification of a state proof Examiner deems that the combination of proof of publication of compM sg in conjunction with the verification of compM sg with σcomp this recitation can be viewed as a state proof sufficient to read on the claim. Therefore Applicant’s argument is not persuasive.
The remainder of the arguments rely on alleged deficiencies of Wang which have been shown by Examiner to be entirely without merit. Therefore these arguments are also not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 7 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 7 recites “The method of claim 5, comprising further steps to ensure said data will not be lost in case of a first Software Guard Extensions (SGX) central processing unit (CPU), said method enabling transfer of said enclave key between a group of HSEs, such that if the first CPU becomes non-operational, one or more other CPUs can recover said data and enable continued operation of the system, the system being configured such that said enclave key cannot be extracted from said HSEs.” Software Guard Extensions first supported multi-socket platforms when the 3rd Gen Intel® Xeon® Processor (Ice Lake) was released (see Johnson et al., Supporting Intel® SGX on Multi-Socket Platforms, Intel, March 24, 2021, 8 pages, retrieved from https://jonahrosenblum.com/static/sgx-scalable.pdf and required an updated version of SGX known as Second Generation Intel SGX, also referred to as SGXv2 (per El-Hindi et al. “Benchmarking the Second Generation of Intel SGX Hardware”, DaMoN ’22: Proceedings of the 18th International Workshop on Data Management on New Hardware (June 2022), June 13, 2022, 9 pages, retrieved from https://dl.acm.org/doi/10.1145/3533737.3535098). Johnson teaches that there are two events that must occur “as part of the platform bring-up” to support multi-socket platforms: Platform Establishment and Platform Registration (2.2).
PNG
media_image1.png
464
310
media_image1.png
Greyscale
(Examiner’s note: Examiner would call attention to the derived “platform key” common to each of the sockets in a multi-socket configuration)
PNG
media_image2.png
252
304
media_image2.png
Greyscale
PNG
media_image3.png
690
312
media_image3.png
Greyscale
In summary the master key common to each of the sockets in a multi-socket platform is formed when the platform is initialized. Johnson states in the abstract that “Intel has made several enhancements in upcoming dual-socket 3rd Gen Intel® Xeon® Processor-based server platforms (code-named Ice Lake) to deliver Intel SGX for Data Center.” There is no teaching in either Johnson or El-Hindi that an enclave key is exchanged between sockets (HSEs) either in the event of a CPU failure as claimed or in any circumstance as Johnson and El-Hindi each describe a platform key and an enclave key that are distinct entities and if data is to be shared it must be encrypted using the common platform key and not the enclave key unique to each socket (or for that matter the cited Bao reference named in the information disclosure statement and incorporated by reference into the application “When Blockchain Meets SGX: An Overview, Challenges, and Open Issues” which at section (III)(A) in the recitation with regard to data sealing makes the same distinction between an enclave key which binds the information to a specific socket and the platform key that allows for sharing between sockets). In fact if there were some form of failure in one of the sockets of a multi-socket platform a fair read on Johnson would indicate that the platform key would not be formed during the key exchange protocol as this would be an inconsistency that would preclude Intel SGX from being enabled. Therefore as the claim is not supported by the documentation provided by the manufacturer of either the multi-socket processor (Xeon) or the extensions (SGX) it would be necessary under MPEP § 2161.01 (I) for the inventor to supply the algorithm or structure necessary to modify the combination of Xeon and SGX as they are known in the art in order to arrive at a combination necessary for the claim to be operable. However the inventor has disclosed no such modification or improvement and merely claims the improvement without a sufficient teaching in the written description and therefore has failed to actually establish possession of the claimed invention. Therefore claim 7 is rejected under 35 U.S.C. § 112 (a) or 35 U.S.C. § 112 (pre-AIA ) first paragraph for failing to satisfy the written description requirement.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-6 and 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. “SPDS: A Secure and Auditable Private Data Sharing Scheme for Smart Grid Based on Blockchain”, IEEE Transaction on Industrial Informatics, Vol. 17, No. 11, November 2021, pp. 7788-7699, hereinafter referred to as Wang, in view of TEE Sockets API Specification Version 1.0, GlobalPlatform Device Technology, Public Release June 2015, 33 pages, hereinafter referred to as TEE Sockets API.
As per claims 1 and 4
Wang discloses a server-based blockchained system for monetizing access to data, comprising: a. at least one computer-readable memory; (III (A) “Cloud server: The cloud server (e.g., AWS and Azure) hosts unlimited data storage space and powerful computing capacity for off-chain data storage and processing. For efficient data lookup and matching, a distributed key-value table is maintained by the cloud, where the key refers to the unique hash pointer of the stored private dataset”)
Wang discloses b. at least one non-transitory computer-readable medium (CRM); (III (A) “TEE Enclave: Instead of delivering the sensitive raw data, the TEE implemented by Intel SGX hosted on the cloud enables that only the computing results (i.e., extracted knowledge) of raw data are delivered to the service provider via efficient offchain smart contract execution. TEE provides hardware-level guarantees for integrity and confidentiality of computations on sensitive data. The loaded key codes and sensitive information are processed in a secure container (i.e., enclave) [7]. The correctness of configurations and program execution within the enclave can be checked via remote attestation [25], [26] by establishing encrypted and authenticated channels between the enclave and users.”)
Wang disclose c. at least one processor (III (A) “Cloud server: The cloud server (e.g., AWS and Azure) hosts unlimited data storage space and powerful computing capacity for off-chain data storage and processing. For efficient data lookup and matching, a distributed key-value table is maintained by the cloud, where the key refers to the unique hash pointer of the stored private dataset”)
Wang discloses d. a hardware secure enclave (HSE) implemented within said at least one processor; said HSE configured to provide a signed blockchain account for receipt of payment for a data storage module within said HSE (III (A) “TEE Enclave: Instead of delivering the sensitive raw data, the TEE implemented by Intel SGX hosted on the cloud enables that only the computing results (i.e., extracted knowledge) of raw data are delivered to the service provider via efficient offchain smart contract execution. TEE provides hardware-level guarantees for integrity and confidentiality of computations on sensitive data. The loaded key codes and sensitive information are processed in a secure container (i.e., enclave) [7]. The correctness of configurations and program execution within the enclave can be checked via remote attestation [25], [26] by establishing encrypted and authenticated channels between the enclave and users.”, Figure 2 and “The framework of blockchain and TEE based private data sharing illustrated in Fig. 2 is summarized as follows…Once the UC and DO further reach an agreement on data utility and payment, a data access and usage smart contract (DAUC) is created in the form of executable computer codes and is signed by both parties (steps 2_− 4 _). 3) Next, when the transaction built by the smart contract code is mutually verified by the majority of full nodes, a contract account of DAUC is created and all nodes in blockchain can access it. UC can lookup the DAUC contract and invoke it by sending enough deposits to the contract account (steps 5_− 6 _).”)
PNG
media_image4.png
200
400
media_image4.png
Greyscale
Fig. 2. System overview of blockchain-based personal energy data
management with smart contract and TEE
Wang discloses e. a data monetizing application implemented within said HSE; (Figure 2 and III (A) “Finally, when the TEE execution finishes, the computation results are delivered to the UC while the financial settlement is performed automatically. Thereafter, the smart contract ends and the states (e.g., account balance) of involved parties are updated (step 8 _).”)
Wang discloses f. an enclave API for rendering said data or cryptographic proof of properties of said data, inaccessible except through said enclave API having a function for retrieving said data or cryptographic proof of properties of the data (Figure 2 and III (A) “Afterwards, to tackle the confidentiality and poor performance in smart contracts, the execution of DAUC contract is separated into the on-chain state tracking part and off-chain TEE computation part. The correctness and integrity of TEE execution are ensured by the issued proofs (i.e., attestations), while the atomicity of operations (i.e., either both computing result delivery and payment are completed or none of them) is acquired by the proposed two-step atomic delivery protocol (step 7 _).”)
Wang discloses g. machine-readable instructions stored on said at least one CRM for execution by said at least one processor via said at least one memory configured to: (III (A) “TEE Enclave: Instead of delivering the sensitive raw data, the TEE implemented by Intel SGX hosted on the cloud enables that only the computing results (i.e., extracted knowledge) of raw data are delivered to the service provider via efficient offchain smart contract execution. TEE provides hardware-level guarantees for integrity and confidentiality of computations on sensitive data. The loaded key codes and sensitive information are processed in a secure container (i.e., enclave) [7]. The correctness of configurations and program execution within the enclave can be checked via remote attestation [25], [26] by establishing encrypted and authenticated channels between the enclave and users.”)
Wang discloses i. submit funds on-chain into a smart contract with stated intent to access specific data via an on-chain data policy (Figure 2 and III (A) “3) Next, when the transaction built by the smart contract code is mutually verified by the majority of full nodes, a contract account of DAUC is created and all nodes in blockchain can access it. UC can lookup the DAUC contract and invoke it by sending enough deposits to the contract account (steps 5_− 6 _).”)
Wang discloses iii. provide said smart contract with a unique enclave signature enabling notifications based on said unique enclave signature to be accepted (IV (C) “In the existing blockchain, data and computation involved in smart contracts (e.g., user input and contract state) need to be replicated for all validators to publicly verify whether the contract is correctly executed. As the user input, e.g., private energy data, generally contains sensitive user information, the lack of privacy fundamentally impedes the adoption of smart contracts for personal data computation. A TEE-based off-chain smart contract execution mechanism is proposed to tackle this challenge. Here, the computation of sensitive personal data is executed within the TEE enclave to ensure data confidentiality, and the delivery of computing results and data payment can be facilitated with the smart contract. The detailed workflow is illustrated in Fig. 3… In remote attestation [25], a proof of correct configuration and execution (i.e., a digital signature using a secret key which is only known by the hardware) can be generated by the TEE. Attestation is a type of challenge-response protocol, where the enclave generates a digital signature on the current configuration and replies to the challenger, meanwhile the challenger can verify the authenticity of the signature and check whether configurations are as expected. By establishing encrypted and authenticated channels to the enclave, both sides of contracting entities can remotely attest the loaded program and data1 (including smart contract configurations, API program (from the UC), encrypted private subdatasets (from the cloud), and the computation to be executed) in TEE and validate its correctness and authenticity. Only if both DO and UC reach an agreement on the loaded program and data and the compliances of operations to be performed within the TEE enclave via remote attestation (step 1 _), the off-chain smart contract execution will continue. Then, DO delivers its decryption keys ki,_ = {ki,1, . . . , ki,l, . . . , ki,L_ } of the encrypted datasets_Di,_ to TEE, and CA delivers the symmetric key kCA to TEE for encryption of computing results (step 2 _). Next, TEE performs the off-chain contract execution and obtains the computing results result (i.e., extracted knowledge from the personal datasets) (step 3 _). Here, result = op(Dki,_ (_Di,_)), where op is the contractual operations for data processing, and D(.) is the decryption function.”)
PNG
media_image5.png
200
400
media_image5.png
Greyscale
Wang discloses iv. provide said data owner with a signed blockchain account (III (A) “3) Next, when the transaction built by the smart contract code is mutually verified by the majority of full nodes, a contract account of DAUC is created and all nodes in blockchain can access it. UC can lookup the DAUC contract and invoke it by sending enough deposits to the contract account (steps 5_− 6 _).”)
Wang discloses v. store said data off-chain in said HSE (III (A) “TEE provides hardware-level guarantees for integrity and confidentiality of computations on sensitive data. The loaded key codes and sensitive information are processed in a secure container (i.e., enclave) [7]. The correctness of configurations and program execution within the enclave can be checked via remote attestation [25], [26] by establishing encrypted and authenticated channels between the enclave and users.”)
Wang discloses the ii. locking of off chain data sent by a data owner into an HSE (II (A) “TEE Enclave: Instead of delivering the sensitive raw data, the TEE implemented by Intel SGX hosted on the cloud enables that only the computing results (i.e., extracted knowledge) of raw data are delivered to the service provider via efficient offchain smart contract execution. TEE provides hardware-level guarantees for integrity and confidentiality of computations on sensitive data. The loaded key codes and sensitive information are processed in a secure container (i.e., enclave) [7]. The correctness of configurations and program execution within the enclave can be checked via remote attestation [25], [26] by establishing encrypted and authenticated channels between the enclave and users.”, IV (A) “To alleviate the storage overhead while improving the scalability of blockchain, the off-chain storage mechanism is applied by moving the large volume of private energy datasets to an external online repository and retaining the metadata (including a hash pointer) of each raw dataset on the blockchain. The cloud database (DB) with powerful computing and storage capacity is employed as the off-chain repository. Each DO i encrypts her personal energy datasets before storing them in the cloud DB. Then, an off-chain data storage transaction (dsTx) is generated in the form as dsTx=_Di||metai||tStamp||pki||pkDB||MS{ski,skDB}(ψd)_, (2) where _Di = {_Di,1, . . . ,_Di,l, . . . ,_Di,Li } is the encrypted form of the raw dataset Di, metai = {metai,1, . . . , metai,l, . . . , metai,Li} is the metadata of dataset Di, tStamp is the timestamp of dsTx creation, MS(.) is the multisignature function, (pkDB, skDB) is the public/secret key pair of the cloud DB, and ψd is the hash digest of dsTx.”)
Wang discloses vi. call a triggering function off-chain, by a data accessor, from said HSE; said triggering function including a signed blockchain account representing the party accessing said data (III (A) “3) Next, when the transaction built by the smart contract code is mutually verified by the majority of full nodes, a contract account of DAUC is created and all nodes in blockchain can access it. UC can lookup the DAUC contract and invoke it by sending enough deposits to the contract account (steps 5_− 6 _).”, IV (B) “When UC finds its interested subdatasets Di,= {Di,1, . . . ,Di,l, . . . ,Di,L } of DO i, it sends a request to DO i for data access and usage as follows: reqMsg = pki||pk||contractMenu||tStamp||Ssk(ψr)
(4) where Lis the number of requested datasets owned by DO i, (pk, sk) is the public/secret key pair ofUC , contractMenu is a set of contract menus (i.e., data utility and payment combinations) for all types of DOs, tStamp is the timestamp of reqMsg creation, S(.) is the BLS short signature function, and ψr is the hash digest of reqMsg. The data access policies specify who can access what kind of data at what price, while the data usage policies specify how the data can be processed.”)
Wang discloses vii. notify, by said triggering function, said smart contract on-chain when a data access request is received (III (A) “3) Next, when the transaction built by the smart contract code is mutually verified by the majority of full nodes, a contract account of DAUC is created and all nodes in blockchain can access it. UC can lookup the DAUC contract and invoke it by sending enough deposits to the contract account (steps 5_− 6 _).”, IV (B) “When UC finds its interested subdatasets Di,= {Di,1, . . . ,Di,l, . . . ,Di,L } of DO i, it sends a request to DO i for data access and usage as follows: reqMsg = pki||pk||contractMenu||tStamp||Ssk(ψr)
(4) where Lis the number of requested datasets owned by DO i, (pk, sk) is the public/secret key pair ofUC , contractMenu is a set of contract menus (i.e., data utility and payment combinations) for all types of DOs, tStamp is the timestamp of reqMsg creation, S(.) is the BLS short signature function, and ψr is the hash digest of reqMsg. The data access policies specify who can access what kind of data at what price, while the data usage policies specify how the data can be processed.”)
Wang discloses viii. submit, by said HSE, a universal attestation request to a processor manufacturer attestation module; said universal attestation request comprising the same HSE code attested for all data access requests (IV (C) “In remote attestation [25], a proof of correct configuration and execution (i.e., a digital signature using a secret key which is only known by the hardware) can be generated by the TEE. Attestation is a type of challenge-response protocol, where the enclave generates a digital signature on the current configuration and replies to the challenger, meanwhile the challenger can verify the authenticity of the signature and check whether configurations are as expected. By establishing encrypted and authenticated channels to the enclave, both sides of contracting entities can remotely attest the loaded program and data1 (including smart contract configurations, API program (from the UC), encrypted private subdatasets (from the cloud), and the computation to be executed) in TEE and validate its correctness and authenticity. Only if both DO and UC reach an agreement on the loaded program and data and the compliances of operations to be performed within the TEE enclave via remote attestation (step 1 _), the off-chain smart contract execution will continue”)
Wang discloses ix. receive, by said smart contract, on-chain verification that said HSE is to be accessed by said blockchain account holder and said smart contract charges for access by transferring tokens from said data accessor to said data owner’s aid payment may be taken in one step, escrowed by said smart contract; (IV (C) “Then, DO delivers its decryption keys ki,_ = {ki,1, . . . , ki,l, . . . , ki,L_ } of the encrypted datasets_Di,_ to TEE, and CA delivers the symmetric key kCA to TEE for encryption of computing results (step 2 _). Next, TEE performs the off-chain contract execution and obtains the computing results result (i.e., extracted knowledge from the personal datasets) (step 3 _). Here, result = op(Dki,_ (_Di,_)), where op is the contractual operations for data processing, and D(.) is the decryption function. The next challenge is the atomic delivery of computing result to UC and payment p(α) to DO. To prevent UC from acquiring the computing results without finishing the payment to DO, a two-phase atomic delivery protocol is developed as follows. When off-chain computation ends, the TEE delivers the encrypted results EkCA (result) with its signature to the UC via a secure channel (step 4 _). After UC checks the authenticity of the signature and sends a response message as an acknowledgment of the receipt (step 5 _), the TEE sends a computation completion message compMsg with its signature to the blockchain (step 6 _ ). Finally, after observing a proof of publication of compMsg, i.e., σcomp (step 7 _), TEE sends the decryption key kCA to UC (step 8 _). Here, σcomp is the multisignature of validators on compMsg, and it is valid after signed by over two thirds of validators. As TEE’s delivery of compMsg can be verified by σcomp, only if σcomp has been generated (i.e., DO will get the payment according to the DAUC contract), the description key is then released (i.e., UC acquires the computing results).”)
Wang discloses x. notify, by a blockchain relayer, said HSE on receipt of payment (IV (C) “After UC checks the authenticity of the signature and sends a response message as an acknowledgment of the receipt (step 5 _), the TEE sends a computation completion message compMsg with its signature to the blockchain (step 6 _ ). Finally, after observing a proof of publication of compMsg, i.e., σcomp (step 7 _), TEE sends the decryption key kCA to UC (step 8 _). Here, σcomp is the multisignature of validators on compMsg, and it is valid after signed by over two thirds of validators. As TEE’s delivery of compMsg can be verified by σcomp, only if σcomp has been generated (i.e., DO will get the payment according to the DAUC contract), the description key is then released (i.e., UC acquires the computing results).”, see also IV (B) section with algorithm 1 lines 20-26 with regard to receiving σcomp from the blockchain and performing the verification)
PNG
media_image6.png
200
400
media_image6.png
Greyscale
PNG
media_image7.png
200
400
media_image7.png
Greyscale
Wang discloses xi. verify, by said data monetizing application, said transaction by means of a light client or state proofs (IV (C) “After UC checks the authenticity of the signature and sends a response message as an acknowledgment of the receipt (step 5 _), the TEE sends a computation completion message compMsg with its signature to the blockchain (step 6 _ ). Finally, after observing a proof of publication of compMsg, i.e., σcomp (step 7 _), TEE sends the decryption key kCA to UC (step 8 _). Here, σcomp is the multisignature of validators on compMsg, and it is valid after signed by over two thirds of validators. As TEE’s delivery of compMsg can be verified by σcomp, only if σcomp has been generated (i.e., DO will get the payment according to the DAUC contract), the description key is then released (i.e., UC acquires the computing results).”, see also IV (B) section with algorithm 1 lines 20-26 with regard to receiving σcomp from the blockchain and performing the verification)
Wang discloses xii. provide requested data or cryptographic proof of properties of said data to said data accessor (IV (C) “After UC checks the authenticity of the signature and sends a response message as an acknowledgment of the receipt (step 5 _), the TEE sends a computation completion message compMsg with its signature to the blockchain (step 6 _ ). Finally, after observing a proof of publication of compMsg, i.e., σcomp (step 7 _), TEE sends the decryption key kCA to UC (step 8 _). Here, σcomp is the multisignature of validators on compMsg, and it is valid after signed by over two thirds of validators. As TEE’s delivery of compMsg can be verified by σcomp, only if σcomp has been generated (i.e., DO will get the payment according to the DAUC contract), the description key is then released (i.e., UC acquires the computing results).”, see also IV (B) section with algorithm 1 lines 20-26 with regard to receiving σcomp from the blockchain and performing the verification)
Wang does not explicitly disclose lock data off-chain sent by a data owner into said HSE by sending encrypted data utilizing Hypertext Transfer Protocol Secure (HTTPS) to said HSE. Tee Sockets API teaches lock data off-chain sent by a data owner into said HSE by sending encrypted data utilizing Hypertext Transfer Protocol Secure (HTTPS) to said HSE (3.1.1 “Network software that changes the level of trust of the data stream SHALL execute within the TEE. Other network software MAY execute within the TEE. For example, the implementation of the SSL/TLS algorithm ensures that the data received is that sent by the originator and hence improves its level of trust. Thus, TLS (or any other security protocol) SHALL be implemented within the Trusted OS component, while pure transport protocols, which do not change the level of trust of the data stream, MAY be implemented in the REE. See for example Figure 3-2” (Proprietary Channel))
PNG
media_image8.png
200
400
media_image8.png
Greyscale
Wang does not explicitly disclose or enable said HSE to securely and privately retrieve owner data from a third- party application programming interface (API) off-chain by making an HTTPS request to said third-party API. TEE Sockets API teaches or enable said HSE to securely and privately retrieve owner data from a third- party application programming interface (API) off-chain by making an HTTPS request to said third-party API. (Figure 2 and 3.1.1 as recited above from TEE Sockets API with regard to the TEE Client API as shown above in Figure 2).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the secure and auditable private data sharing scheme of Wang with the TEE Sockets API Specification of TEE Sockets API for the purpose of allowing trusted applications (TAs) to perform the common requirement of communicating with remote servers that is small and easily layered as the needs of the user change and new communication media are added to the device (2).
As per claim 5
Wang discloses sealing said data by encrypting said data using said enclave key and storing said encrypted data in a file system, such that only said HSE, or an enclave with said key can decrypt said sealed data (III (B) “1) The enclave inside TEE (i.e., SGX) is assumed to be secure for off-chain smart contract execution via remote attestations. Besides, the sealed data (e.g., keys and program codes) in the enclave of SGX is assumed to be secure, namely, it is infeasible for any entity other than the SGX to decrypt the sealed data.”)
As per claim 6
TEE Sockets API teaches further steps of said data owner digitally signing and enabling a secure and encrypted HTTPS call directly from said HSE to a third-party service to retrieve said data on behalf of said data owner 3.1.1 “Network software that changes the level of trust of the data stream SHALL execute within the TEE. Other network software MAY execute within the TEE. For example, the implementation of the SSL/TLS algorithm ensures that the data received is that sent by the originator and hence improves its level of trust. Thus, TLS (or any other security protocol) SHALL be implemented within the Trusted OS component, while pure transport protocols, which do not change the level of trust of the data stream, MAY be implemented in the REE. See for example Figure 3-2” (Proprietary Channel)) (Via Client API)
PNG
media_image8.png
200
400
media_image8.png
Greyscale
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the secure and auditable private data sharing scheme of Wang with the TEE Sockets API Specification of TEE Sockets API for the purpose of allowing trusted applications (TAs) to perform the common requirement of communicating with remote servers that is small and easily layered as the needs of the user change and new communication media are added to the device (2).
As per claim 8
Neither Wang nor TEE Sockets API explicitly disclose wherein said blockchain is a forked blockchain. However as no actual method step is recited the limitation is not entitled to patentable weight (“Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation, MPEP § 2103 (C)). Furthermore as those skilled in the art familiar with blockchain would understand that any blockchain could potentially be a forked blockchain the language does not distinguish the claim from the prior art.
As per claim 9
Wang, while disclosing the limitations of claim 4, does not explicitly disclose wherein there are a plurality of blockchain relayers. However simply having a plurality of prior art components where the prior art teaches an individual component has no patentable significance unless a new and unexpected result is produced which has not been shown (MPEP § 2144.04 (VI)(B)).
Statement Regarding the Prior Art with regard to claim 7
Examiner does not see where the prior art fairly teaches the limitations of claim 7 as the prior art references cited above (Johnson, El-Hindi) and the reference cited by Application (Bao et al.) teach separate and distinct enclave keys that are specific to a socket that can only encrypt and decrypt information within that specific socket and platform keys that are common to sockets operating in a multi-socket environment and allow each socket within the multi-socket environment to share encrypted information between the sockets in the multi-socket environment. However as other issues exist with claim 7 Examiner cannot provide any indication that incorporating the subject matter of claim 7 into the independent claims would result in a claim that could held as allowable. Therefore while no prior art rejection is being made on claim 7 Examiner will not make any indication of allowable subject matter at this time.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Deploying and Protecting Digital Services with Chains of Trust, GlobalPlatform, May 2018, 15 pages describes how device manufacturers can create a secure Root of Trust (RoT) using GlobalPlatform and highlights the architecture used to form the RoT.
Intel® Registration Service for Scalable Platforms, retrieved from https://web.archive.org/web/20220630155504/https://api.portal.trustedservices.intel.com/registration, June 30, 2022, 2 pages, describes the registration service provided by Intel for registering platform root keys
Trusted Execution Environment (TEE) 101: Primer, Secure Technology Alliance, Version 1.0, April 2018, 24 pages provides an overview of the TEE and the environment in which TEE is intended to operate.
Wang (U.S. Patent Publication 2021/0097528) discloses a hot wallet operating in a secure enclave employing multi-signature authorization.
Wang et al. (U.S. Patent Publication 2020/0327250) discloses the secure exchange of health information involving secure enclaves employing SGX.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 5 AM to 2 PM Monday through Thursday.
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, Neha Patel can be reached at (571) 270-1492. 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.
/JAMES D NIGH/Senior Examiner, Art Unit 3699
Prosecution Insights