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 .
Priority
CONTINUATION
This application is a continuation application of international application no. PCT/IL2023/050771 filed on July 24, 2023 (“Parent Application”). See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents).
Applicant’s claim for the benefit of U.S. provisional patent application 63/395,105 filed August 4, 2022 under 35 U.S.C. 119(e) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on April 1, 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
Claim 1 recites in limitation (g)(x) “…notify, by a blockchain relayer, said HSE on receipt of payment”. Claim 4 contains a similar recitation in limitation (j). In order to determine the scope of the term “relayer” Examiner found these definitions:
Felt “What is a Relayer”, retrieved from https://eco.com/support/en/articles/11011375-what-is-a-relayer, 2025: A relayer in cryptocurrency is an off-chain or third-party entity that facilitates the transmission of data, messages, or transactions between parties, blockchain networks, or protocol layers. Think of relayers as digital messengers that help different blockchains communicate with each other when they otherwise couldn't.
Pixelplex Relayer, retrieved from https://pixelplex.io/glossary/relayer/, May 22, 2025: A relayer in the context of blockchain technology is an intermediary entity or system that facilitates communication or transactions, often between different blockchains or between an off-chain system and a blockchain. Relayers help enable interoperability and improve the functionality of decentralized applications (dApps) and blockchain networks, making them important in smart contract development. They essentially “relay” messages or data from one point to another, often performing a necessary action in the process.
Messari retrieved from https://messari.io/copilot/share/understanding-relayers-477b9279-d5ba-4ef8-804e-10b9637d0c82, No date “What is a relayer?”: A relayer is an off-chain or third-party entity that facilitates the transmission of data, messages, or transactions between parties, blockchain networks, or protocol layers. Relayers are essential for various interoperability and scaling solutions, including decentralized finance (DeFi) protocols, Layer 2 scaling, cross-chain bridges, and oracle networks.
Seres “On Blockchain Metatransactions, 2020 IEEE International Conference on Blockchain, October 29, 2020, pp. 178-187 in section 2.1 recites a particular capability for a relayer: “a metatransaction design might involve one or more non-trusted intermediaries that assist in the transaction processing” and in section 2.4 describes a relayer performing fee delegation (but does not describe any of the functions being performed from the other definitions cited above).
From the perspective of claim interpretation these definitions with respect to the term “relayer” as applied to the term present in the cited limitations do not appear to place any meaningful limit on the claim because the definitions are only functional in nature and apparently require no particular structure in order to implement the function, nor is there any particular alteration of the data by a relayer that would place any clear impact on operation (g)(x) of the server of claim 1 or on operation (j) of method claim 4 as any notification in any form with regard to receipt of payment from any source would satisfy the limitation and any source providing the notification could under these broad definitions be viewed as some form of “relayer”. As the written disclosure indicates that the invention utilizes the Internet it is noted that even a common device such as a modem or router can be viewed as facilitating the transmission of data, messages or transactions between parties, blockchain networks or protocol layers as recited in Felt, Pixelplex and Messari and as such even a modem or router would appear to read on the term relayer. Therefore for purposes of claim interpretation the term relayer in limitation (g)(x) of claim 1 and limitation (j) of claim 4 will be given only limited weight.
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: a blockchain relayer module in claim 2.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1 recites in limitation (b) “at least one computer-readable medium (CRM)”. The claim does not fall within at least one of the four categories of patent eligible subject matter because the written disclosure does not describe any particular type of medium and does not contain any limits to the nature of the medium and is broad enough in scope to encompass transitory signals. As such a claim has been held as being outside the scope of a machine or tangible article under the definition of manufacture the claim does not fall within any of the four categories of statutory subject matter and therefore is rejected under section 101 (MPEP § 2106.03(I)).
Claims 2-3 are also rejected as being dependent upon claim 1.
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.
Claims 2 and 7 are 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 2 has been held as indefinite under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph for having invoked 35 U.S.C. 112 (f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph for involving a computer-implemented means-plus-function limitation (MPEP § 2181 (II)(B)) as the written disclosure does not describe the structure of the blockchain relayer module or any algorithm used in programming the module assuming that the module is software based which cannot be ascertained given the limited description provided. Per (MPEP § 2181 (IV)) “…When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).” Therefore claim 2 is rejected under the written description requirement.
Claim 7 recites “The method of claim 5, comprising further steps to ensure said data will not be lost in case of a failed Software Guard Extensions (SGX) central processing unit (CPU), said method enabling transfer of said enclave key between a group of HSEs, such that if one CPU fails, the other CPUs can recover said data and enable continued operation of said system 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.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation “blockchain relayer module” which invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph as the claims recites the function of notifying said HSE that payment of said charge was made and is not modified by structure sufficient for performing the function. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The written description at page 6, lines 13-15 only repeats language similar to that of the claim but does not provide any structural description of the blockchain relayer module or any algorithm for performing the function of notifying the HSE that payment was made. Therefore, claim 2 is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim 7 recites “The method of claim 5, comprising further steps to ensure said data will not be lost in case of a failed Software Guard Extensions (SGX) central processing unit (CPU), said method enabling transfer of said enclave key between a group of HSEs, such that if one CPU fails, the other CPUs can recover said data and enable continued operation of said system configured such that said enclave key cannot be extracted from said HSEs.” The word “failed” is both a relative term and a term of degree as in the extreme a “failed” CPU would be inoperable and would not be capable of performing any operation, much less a transfer of an enclave key and as such the term “failed” can only encompass events that are recoverable (which establishes that the term is one of degree). Similarly an event such as a memory overrun can be viewed as a form of failure or simply as an event that requires some form of attention (by for example clearing active memory by writing lesser used portions to disk such that space become available for current operations (which speaks to the relative nature of the term). The written disclosure provides no treatment on either what constitutes a failure that would trigger the transfer nor what types of events would or would not be considered as failures. Therefore claim 7 is held as being indefinite.
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-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 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 = { } 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 L is 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 = { } 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 L is 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 2
Wang discloses wherein said system comprises a blockchain relayer module for notifying said HSE that payment of said charge was made. (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)
As per claim 3
Wang discloses wherein said enclave application is programmed to verify the fee payment transfer transaction using a light client, state proofs, before enabling requested data (or cryptographic proof of properties of the data), to be retrieved by 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)
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.
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 6:00 to 9:45 and 10:30 to 2:45.
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