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 Rejections
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 3-9, 11-12 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter regarding which the inventor regards as the invention. (MPEP 21703.05(e)
Regarding claim 3, it recites wherein the encrypted version of the state data maintained in the authenticated storage is encrypted using a network symmetric key belonging to the blockchain network. Claim 1, which claim 3 depends on (through claim 2), only establishes "a storage of a smart contract," never "authenticated storage" as an element. The usage of "the" before "authenticated storage" (to the understanding of the examiner) is either to refer to a previously introduced element that doesn't exist in the claim or its parents, or is meant to introduce an entirely new element. Both of which would leave the claim indefinite, leaving this claim to lack antecedent basis
Regarding claim 4, it depends on rejected claim 3 and inherits the rejection of its parent
and recites wherein each node in the plurality of nodes holds a secret share of the network symmetric key, which relies only on antecedent bases properly established in claims 2 and 3 ("the plurality of nodes" and "the network symmetric key," respectively) and does not itself introduce any additional indefinite term; claim 4 is indefinite only by virtue of depending from indefinite claim 3.
Regarding claim 5, it recites adding the encrypted version of the state data as a map entry to a map within the memory of the smart contract. Claim 1 only establishes a memory of the BVM”, the computer system implementing the blockchain virtual machine, as the memory element in which the encrypted state data is loaded. Claim 1 doesn’t recite that a smart contract itself possesses or has its own “memory”. Under the architecture set out in claim1, the smart contract has “a storage”, while the BVM has “a memory”. Additionally, the usage of “the” before “smart memory” (to the understanding on the examiner) is to refer to a previously introduced element that doesn’t exist in the claim or its parents is meant to introduce an entirely new element. Both of which would leave the claim indefinite, leaving this claim to be inconsistent to information established in its parent claim.
Claim 6 depends on rejected claim 5 and inherits the rejection of its parent. Claim 6 recites checking whether the encrypted version of the state data is mapped to the execution depth of the method in the map, which relies only on antecedent bases properly established in claim 5 ("the map" and "the execution depth of the method") and does not itself introduce any additional indefinite term.
Claim 7 depends on rejected claim 6 and inherits the rejection of its parent. Claim 7 recites wherein the converting is performed by invoking the MPC protocol, which relies only on antecedent bases properly established in claim 6 ("the converting") and claim 1 ("the MPC protocol") and does not itself introduce any additional indefinite term.
Regarding claim 8, it recites, “offboarding the garbled output from the garbled execution environment to the memory”. Claim 5, which it depends on already has the issue of an unresolved ambiguity, as claim 8 furthers this issue by stating “the memory”. This would leave the claim indefinite, leaving this claim to lack antecedent basis
Regarding claim 9, it recites, “storing the encrypted version of the result in the storage wherein the storing comprises…writing…in the storage of the smart contract; and writing…in the storage of the second smart contract”. Here there are two distinct storage elements. The opening clause uses the definite article before either of the two specific storages is named in that clause, only in the sub steps that follow does the claim clarify that it means both storages, written to individually, leaving the opening clause, when read by its own, ambiguous.
Regarding claim 11, it recites, the method of claim 1 further comprising, in response to the method calling another method of another smart contract: ensuring that the map does not contain any map entries corresponding to an execution depth of said another method. “A map is first introduced in claim 5, which depends on claim 1. However, claim 11 depends on claim 1 directly, which itself has no recitation of any “map”. Because of this, the mention of “the map” in claim 11, refers to an element that has no antecedent basis in claim 11’s chain of dependency. Regarding claim 12, it depends on rejected claim 11 and inherits the rejection of its parent. Claim 12 recites removing any map entries in the map corresponding to the execution depth of said another method, which uses "the map" in the same sense, and with the same absence of antecedent basis, as claim 11; claim 12 does not itself introduce any additional indefinite term
.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 7, 10, 19, and 20 are rejected under 35 U.S.C. 103(a)(2) as being unpatentable over Wei et al. (US 2021/0119774 A1), aka "Wei 1," in view of Wei et al. (US 2020/0342092 A1), aka "Wei 2," and Peled (US 2022/0172647 A1).
Regarding claim 1, Wei 1 teaches
maintaining, at a storage location in a storage of a smart contract, an encrypted version of state data associated with the smart contract by disclosing "the global state includes a mapping between addresses and states of a plurality of blockchain accounts of the blockchain," that contract accounts each "include[] a storage root," and that "the storage root includes a hash of a root node of an MPT, and wherein the MPT encodes hash of storage contents of the corresponding contract account" [0061-0062].
and at a time of executing a method of the smart contract that manipulates the state data: loading the encrypted version of the state data from the storage to a memory of the BVM by disclosing "determining, by a virtual machine in the TEE, data associated with one or more blockchain accounts to execute the one or more software instructions based on the request; traversing, by the virtual machine, a global state of a blockchain stored in the TEE to locate the data" [0072].
However, Wei fails to teach onboarding the encrypted version of the state data from the memory into a garbled execution environment of the BVM, the onboarding resulting in a garbled version of the state data in the garbled execution environment. Wei 2, however, teaches "decrypting the client encryption key with the first private key... in response to decrypting the request, executing, by the blockchain node in the service TEE, the one or more software instructions to produce an execution result; encrypting, by the blockchain node in the service TEE, the execution result with a client encryption key... to produce an encrypted result" [0080-0081]. It is understood by the examiner that this confirms the general maintain/onboard (decrypt)/compute/offboard (encrypt) pattern was well known for confidential smart-contract execution.
However, Wei fails to teach invoking a secure multi-party computation (MPC) protocol for executing an operation of the smart contract method on the garbled version of the state data, the invoking resulting in a garbled output in the garbled execution environment, wherein the garbled output is a garbled version of a result generated by the operation when the operation is executed using the state data as input. Peled teaches converting protected data into a garbled form for secure computation: "a first 'garbling' party may analyze, in depth-first order, the various gates 132 included in a garbling circuit 131, creating, for each gate 132, a corresponding garbled gate 136 and encryption table 137," producing "the garbled circuit 135 resulting from the application of the garbling technique" [0010]. Peled further teaches invoking a garble-and-evaluate protocol to produce an output from protected input: "the evaluation... may provide for computation, by a second, evaluating party, of a Boolean circuit, garbled... of the output... based on the... parties' joint inputs" [0012], i.e., invoking a secure multi-party garble-and-evaluate computation on garbled data to yield a garbled/computed output.
A person of ordinary skill, starting from Wei 1's and Wei 2's TEE-based architecture for maintaining, loading, and processing encrypted smart-contract state, would have been motivated to implement Peled's garbled-circuit MPC technique for the TEE-based decrypt-and-execute step, because garbled-circuit MPC was a known alternative technique for secure computation on protected data that avoids reliance on trusted hardware and its associated side-channel/trust limitations.
Regarding claim 2, Wei 2 teaches
wherein the computer system is a node in a blockchain network comprising a plurality of nodes by disclosing "system 300 includes a blockchain network 302 including blockchain nodes 304a-d," each of which "is [a] blockchain node participating in the blockchain network 302" [0046]. This limitation does not require any reference beyond those already applied to claim 1.
Regarding claim 7, Peled teaches
wherein the converting is performed by invoking the MPC protocol by teaching that converting data into (and evaluating) a garbled form is performed via a garble-and-evaluate MPC protocol: gates are "garbled... into a garbled circuit," and the "evaluation... may provide for computation, by a second, evaluating party" [0012] of the garbled circuit's output. This limitation is disclosed by Peled, already applied to claim 1, without requiring any additional reference.
Regarding claim 10, Wei 2 teaches
decrypting the garbled output, the decrypting resulting in a plain text version of the result in the memory by teaching the identical decrypt-to-plaintext step recited in claim 10, applied to a protected output: after the TEE "encrypt[s] the execution result... to produce an encrypted result" [0066], a party holding the corresponding key "can decrypt the result 466 in order to inspect" it, i.e., recovering a plain text version of the result. This limitation does not require any reference beyond those already applied to claim 1.
Regarding claims 19-20, each recites substantially the same limitations as those recited in claim 1, applied respectively to a non-transitory computer readable storage medium (claim 19) and a computer system comprising one or more processors and a non-transitory computer readable medium (claim 20). Thus, for the same reasons presented with respect to claim 1, claims 19-20 are rejected as being unpatentable over Wei 1 in view of Wei 2 and Peled for the same reasons presented with respect to claim 1, without requiring any additional reference.
Claims 3 and 4 are rejected under 35 U.S.C. 103(a)(2) as being unpatentable over Wei 1, in view of Wei 2 and Peled, and further in view of Deshpande (US 2020/0082399 A1).
Regarding claim 3, while Wei 1 and Wei 2 fail to teach
wherein the encrypted version of the state data maintained in the authenticated storage is encrypted using a network symmetric key belonging to the blockchain network, Deshpande discloses generation of a single, network-wide symmetric secret used across the participant set: "the creation of a system-wide public/private key pair, and the generation and distribution of shares si of the system-wide private key ('secret') S." This system-wide secret S, shared across the network's participants, corresponds to the claimed "network symmetric key belonging to the blockchain network" [0029].
A person of ordinary skill would've been motivated to encrypt Wei's teaching of persistently-stored contract state using Deshpande's known network-wide shared-secret architecture specifically because a network-wide key, rather than a single node's key, is necessary to allow any node in a distributed blockchain network to participate in decrypting/processing the state, which is the whole premise of Wei's multi-node consensus architecture.
Regarding claim 4, Deshpande teaches
wherein each node in the plurality of nodes holds a secret share of the network symmetric key by teaching "the dealer first generates a respective share si for each participant Pi, encrypts the share using that participant's registered public key and, for each participant Pi, the dealer provides the encrypted share Ei(si)" [0030]. Each participant (node) thus holds its own secret share of the system-wide secret, directly disclosing this limitation.
Claims 5, 6, 8, 9, and 11-18 are rejected under 35 U.S.C. 103(a)(2) as being unpatentable over Wei 1, in view of Wei 2 and Peled, and further in view of Liu (US 2020/0184093 A1).
Regarding claim 5, Liu teaches
checking whether the encrypted version of the state data is also present at the same storage location in a storage of a second smart contract associated with the smart contract, the second smart contract being a dummy smart contract that does not have any program code; and upon determining that the encrypted version of the state data is also present at the same storage location in the storage of the second smart contract, adding the encrypted version of the state data as a map entry to a map within the memory of the smart contract, the map entry mapping the encrypted data to an execution depth of the method by disclosing the general problem this limitation addresses: nested smart-contract calls sharing execution context within a single secure environment: "A multi-nested structure can be implemented between smart contracts. For example, code in smart contract 1 calls smart contract 2, and code in smart contract 2 points to contract address 3 generated by smart contract creation code. As such, when calling the code in smart contract 1, a privacy transaction directly calls the code in smart contract 2 and indirectly calls smart contract code at contract address 3. Therefore, the code of smart contract 1, smart contract 2, and smart contract 3 is all executed in the EVM deployed in the TEE" [0050]. This establishes that (i) multiple smart contracts' code executes within the same secure/protected environment during a single call chain and (ii) tracking and updating the state of each involved contract account within that shared secure execution is a known problem addressed in the art. A POSITA would've been motivated to adopt a call-context-keyed tracking structure as a predictable, conventional means of solving this because per-call-frame indexing is a finite, known solution to tracking nested, re-entrant execution context.
Regarding claim 6, Liu teaches
checking whether the encrypted version of the state data is mapped to the execution depth of the method in the map; and upon determining that the encrypted version of the state data is mapped to the execution depth of the method, converting the encrypted version of the state data into the garbled version of the state data by disclosing the same general problem discussed with respect to claim 5, above: "A multi-nested structure can be implemented between smart contracts... the code of smart contract 1, smart contract 2, and smart contract 3 is all executed in the EVM deployed in the TEE" [0050]. A person with ordinary skill in the art would've found known techniques for disambiguating nested, re-entrant execution context, of which indexing by call depth is one solution. Applying a depth-indexed tracking structure to Liu's individually-tracked per-contract state would've yielded the result of allowing the execution environment to correctly attribute and avoid redundantly re-onboarding state across nested contract calls, a predictable result. Peled, already applied to claim 1, supplies the underlying "converting... into the garbled version" step itself, per the garbling technique discussed above.
Regarding claim 8, Liu teaches
offboarding the garbled output from the garbled execution environment to the memory, the offboarding resulting in an encrypted version of the result in the memory, wherein the offboarding comprises: converting the garbled output into the encrypted version of the result; and adding the encrypted version of the result as a second map entry to the map, the second map entry mapping the encrypted version of the result to the execution depth of the method by disclosing the same general problem discussed with respect to claim 5, above: "A multi-nested structure can be implemented between smart contracts... the code of smart contract 1, smart contract 2, and smart contract 3 is all executed in the EVM deployed in the TEE" [0050].
Regarding claim 9, Liu teaches
storing the encrypted version of the result in the storage, wherein the storing comprises: checking whether the encrypted version of the result is mapped to the execution depth of the method in the map; and upon determining that the encrypted version of the result is mapped to the execution depth of the method: writing the encrypted version of the result at the storage location in the storage of the smart contract; and writing the encrypted version of the result at the storage location in the storage of the second smart contract by disclosing the same general problem discussed with respect to claim 5, above: "A multi-nested structure can be implemented between smart contracts... the code of smart contract 1, smart contract 2, and smart contract 3 is all executed in the EVM deployed in the TEE" [0050].
Regarding claim 11, Liu teaches
in response to the method calling another method of another smart contract: ensuring that the map does not contain any map entries corresponding to an execution depth of said another method by teaching the underlying multi-nested-contract-call scenario these claims manage: "code in smart contract 1 calls smart contract 2, and code in smart contract 2 points to contract address 3" [0050]. Here, Liu discloses the triggering event, one contract's code calling another smart contract's method within a single shared secure execution environment, and discloses that each contract's state is individually and separately tracked, encrypted, and written back rather than commingled.
A person with ordinary skill would combine Liu's individually-tracked, per-contract state architecture with a depth-indexed map and would've been motivated to validate the map at the point of entry into a nested call, since Liu establishes that one contract's state must not be conflated with another's, and a stale map entry left over from an earlier use of the same execution-depth value would produce that conflation.
Regarding claim 12, Liu teaches
in response to said another method completing its execution: removing any map entries in the map corresponding to the execution depth of said another method by teaching the underlying multi-nested-contract-call scenario these claims manage: "code in smart contract 1 calls smart contract 2, and code in smart contract 2 points to contract address 3" [0050].
Regarding claim 13, Liu teaches
wherein the method is invoked via a transaction that is initiated by a user of blockchain network to which the computer system belongs, and wherein the method takes as input an input value that is private to the user by teaching that transactions are user/client-initiated ("a user can submit the transaction to the blockchain node through the client" [0030]) and that a transaction initiator can supply private, encrypted input: "transaction content of the privacy transaction is encrypted by a transaction initiator... transaction initiator can hold a symmetric encryption key, and encrypt the transaction content based on the key... so that the privacy transaction contains encrypted ciphertext transaction content" [0040].
Regarding claim 14, Liu teaches
receiving a secure version of the input value from the transaction, the secure version of the input value including an encrypted version of the input value that is encrypted using a user symmetric key of the user by teaching that the transaction initiator "hold[s] a symmetric encryption key and encrypt[s] the transaction content based on the key" [0041].
However, Liu fails to teach a signature over the encrypted version of the input value that is signed using a private key of the user. Here, Wei 2, already applied to claim 1, discloses the general digital signature mechanism applied by a message's sender using their own private key: "Participant A appends the digital signature to the message and sends the message with digital signature to Participant B" [0038]. Applying this well-known sender-side signing technique to a transaction initiator's encrypted input value, so that the initiator both encrypts the input with a symmetric key and signs the encrypted result with the initiator's own private key, is the combination of two known cryptographic techniques.
However, Liu and Wei fail to teach onboarding the secure version of the input value into the garbled execution environment. Here, Peled's garbling mechanism, already applied to claim 1, is applied to the input value rather than the contract state [0003].
Regarding claim 15, Wei 2 teaches
verifying the signature using a public key of the user by teaching "Participant B decrypts the digital signature using the public key of Participant A, and extracts the hash. Participant B hashes the message and compares the hashes. If the hashes are same, Participant B can confirm that the message was indeed from Participant A" [0038], i.e., verifying a signature using the sender's public key.
However, Wei fails to teach decrypting the encrypted version of the input value using the user symmetric key. Liu teaches "the blockchain node to decrypt the privacy transaction in the trusted execution environment to obtain plaintext transaction content" [0041], using the same symmetric key mechanism disclosed for encryption.
However, both Wei and Liu fail to teach converting a result of the decrypting into a garbled version of input value. Here, Peled's garbling technique, already applied to claim 1, is applied to the decrypted input value rather than the contract state.
Regarding claim 16, Peled teaches
wherein the decrypting and converting are performed by invoking the MPC protocol, by teaching that the garbling and evaluation operations are themselves the MPC protocol invoked to process protected data.
Regarding claim 17, Liu teaches
further comprising offboarding the garbled output from the garbled execution environment for transmission to the user, the offboarding resulting in an encrypted version of the result in the memory that is encrypted using the user symmetric key by disclosing exactly this return-path encryption using the same symmetric key mechanism: "the blockchain node can encrypt a transaction execution result in the TEE by using the symmetric encryption key [held by the transaction initiator]... and a client of the transaction initiator can perform decryption accordingly" [0044].
Regarding claim 18, Peled teaches
wherein the MPC protocol is a garbling scheme-based MPC protocol by teaching "a method for use in garbling a circuit in a memory-limited environment" using garble-and-evaluate techniques, which Peled expressly characterizes as one of the two major categories of general-purpose MPC: "a first 'garbling' party may analyze, in depth-first order, the various gates 132 included in a garbling circuit 131, creating, for each gate 132, a corresponding garbled gate 136 and encryption table," producing "the garbled circuit 135 resulting from the application of the garbling technique" [0010], which is then evaluated by a second party to jointly compute an output from the parties' protected inputs. This limitation does not require any reference beyond those already applied to claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL NWUHA whose telephone number is (571)272-9367. The examiner can
normally be reached Monday-Friday; 7:30 am - 5:00pm.
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,
Kevin Young can be reached at (571) 270-3180. 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.
/SAMUEL OBINNA NNAJI NWUHA/
Examiner, Art Unit 2194
/KEVIN L YOUNG/ Supervisory Patent Examiner, Art Unit 2194
