Detailed Action
Claims 1-12 are pending and are examined.
Status of Claims
Claims 1, 5, and 9 are currently amended.
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 Objections
Claim 5 is objected to for lack of clarity, as it is unclear if the “one or more hardware processors” constitute the system or not. Accordingly, the office requests amendments to the claims addressing the same.
Response to Remarks
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Agrawal fails to disclose the amended claim limitation of claim 1, "wherein the CH-PRE performs computations on transformed encrypted data that is specified with conditions or predicates to be satisfied during encryption to enhance transaction privacy and auditing, wherein the CH-PRE includes a setup algorithm which takes security parameter as an input and outputs a public parameter set, a key generation algorithm which takes the public parameter set as an input and generates a public and private key pair, an encryption function to encrypt an originator's message using a public key of the originator and predicate, wherein the predicate ensure that all other ciphertexts expect the one that is intended to be sent are not decrypted by a target entity, a re-encryption function which takes a re-encryption key as an input to transform a ciphertext encrypted under originator's public key to decrypted by the target entity under some predicate, a re-encryption transforms the ciphertext encrypted under originator's public key to its secret key, a decryption function performed on re-encrypted ciphertext using the target entity's private key". On pages 12-15 of the Office Action, regarding the claim limitation "generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate" the Examiner contends that Ito disclose this limitation as the key generation section 421 of the key generation apparatus 401 performs private key generation in functional encryption, based on inputs of a master private key and a public parameter, stored in the master key information storage section 411, and of the received user attribute. As a result, an attribute private key on which the user attribute (one of the pieces of user attribute information) is set is generated. Further, the re-encryption apparatus 301 receives ciphertext on which a decryption condition is set, then re- encrypts the received ciphertext for a specific user, and sends it to a user terminal 601. The re encryption apparatus 301 includes a public parameter storage section 311, a re-encryption key storage section 312, a re-encryption section 321 and a communication section 331.”. (Applicant Arguments, 2025-11-04).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Agrawal and Ito) still teach currently amended claim 1; regarding the newly added limitations related to the CH-PRE, the citations to Agrawal in paragraph 5 of this action are related to part (a), as the claim requires one of (a) or (b). Indeed, claim 1 is interpreted as reciting contingent alternative functionality. Under MPEP 2111.04(II), ‘the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. Thus, for the method claims, the Office need only show prior art for one operative path established by the claim. As to the system claims, the Office does not rely on the reference for the actual performance of both pairs; rather, the Office relies on the reference for disclosing the claimed structure, including structure capable of performing the contingent functionality should the condition occur. Accordingly, the contentions are unpersuasive.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Agrawal et al. (US20190164153A1) (hereinafter “Agrawal”) in view of Ito et al. (US20160330022A1) (hereinafter “Ito”).
As per Claim 1, Agrawal teaches:
A processor implemented method for transaction privacy and auditing, the method comprising: detecting, by a subnetwork within a blockchain network controlled by one or more hardware processors, initiation of a bilateral transaction request comprising one of: (a) an inter-bank fund transfer from a first customer of a first bank to a second customer of a second bank with a privacy enabled auditing by a verifier, and (b) privacy enabled inter-bank settlements between the first bank and the second bank, wherein the first bank, the second bank and the verifier participate in the subnetwork via an associated node, and wherein the first bank, the second bank and the verifier individually own a Conditional Homomorphic Proxy Re-encryption (CH-PRE) key pair comprising a public key stored on the blockchain and a secret key; wherein the CH-PRE includes a setup algorithm which takes security parameter as an input and outputs a public parameter set, a key generation algorithm which takes the public parameter set as an input and generates a public and private key pair, an encryption function to encrypt an originator's message using a public key of the originator and predicate, wherein the predicate ensure that all other ciphertexts expect the one that is intended to be sent are not decrypted by a target entity, a re-encryption function which takes a re-encryption key as an input to transform a ciphertext encrypted under originator's public key to decrypted by the target entity under some predicate, a re-encryption transforms the ciphertext encrypted under originator's public key to another ciphertext with the same underlying message that is decrypted by the target entity using its secret key, a decryption function performed on re-encrypted ciphertext using the target entity's private key; (regarding the newly added limitations related to the CH-PRE, the following citations are related to part (a), as the claim requires one of (a) or (b): “The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The techniques described herein may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.” (Para. 0287)
executing, by the first bank and the second bank via the associated node controlled by the one or more hardware processors, a smart contract, if the bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the smart contract is executed to i) deduct an encrypted first current balance of a first customer by an encrypted transaction amount encrypted at a first encryption instance to obtain an encrypted first updated balance, and ii) add the first encrypted transaction amount to an encrypted second current balance to obtain an encrypted second updated balance for the second customer; (“The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The Transfer function is used to transfer an amount of tokens from one public key to another. The Lock function is used to lock a public key (and its associated account) to an address such as an address of an application smart contract or another account. Once a public key is locked, transfer of tokens associated with the public key and unlocking of the public key cannot be performed unless the operation came from the address that the public key is locked to. The Unlock function is used to unlock a locked public key, and can be only effective if called by the address that the public key is locked to. The Burn function is used to convert tokens (e.g., ZTH) associated with a public key back to a cryptocurrency amount for a cryptocurrency account (e.g., ETH for an Ethereum address)..” (Para. 0080), “Application smart contract 240 can be executed to perform its underlying functions, causing one or more transactions to be performed on the locked public keys. Application smart contract 240 can then send the one or more transactions to platform smart contract 210 to be processed, and unlock the locked public keys.” (Para. 0089))
encrypting, by the first bank and the second bank via the associated node controlled by the one or more hardware processors, the transaction amount, wherein i) the first bank uses a CH-PRE function having a first predicate comprising a tuple (a transaction Identifier (txid), a user ID and a bank ID) and ii) the second bank uses the CH-PRE function having the second predicate comprising the tuple, to obtain an encrypted transaction amount associated with a second encryption instance; (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “The transaction is then posted as a pending transaction to each of the additional public keys and the public keys of the sender and receiver. When the pending transaction is rolled over, the first operand ciphertext (representing a negative of the transaction amount) is added to the encrypted balance of the sender, the second operand ciphertext (representing a positive of the transaction amount) is added to the encrypted balance of the receiver, and the additional operand ciphertexts (encryption of zero by corresponding public key) are added to the respective balances of the additional public keys.” (Para. 0088), “the signature can be generated, for example, by encrypting the smart contract address and a nonce (e.g., counter value or epoch base). In some embodiments, the lock request can be received during a particular epoch, and locking of the account can occur or take effect in a subsequent epoch after the particular epoch. In some embodiments, while an account is locked to the application smart contract, only the application smart contract is permitted to unlock the account.” (Para. 0092))
storing, via the associated node controlled by the one or more hardware processors, i) by the first bank the encrypted first updated balance and the encrypted transaction amount associated with the second encryption instance, and ii) by the second bank the encrypted second updated balance and the encrypted transaction amount associated with the second encryption instance; and (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “A transaction can transfer wei between accounts or trigger the execution of smart contract code. Smart contracts can send messages to other smart contracts, mimicking function calls. Every transaction and code execution is replicated on all nodes in the network. Every executed operation has a specified cost expressed in terms of gas units. For example, storing 256 bits of data costs 20,000 units of gas while changing it costs 5,000 units and reading it costs 200 units. The sender pays for all smart contract operations that the transaction calls.” (Para. 0041), “Homomorphic commitments such as Pedersen commitments can be used to make transactions confidential. Though Pedersen commitments are simple and efficient, the opening of these commitments are transferred to the recipient so that the recipient can subsequently use the funds. This randomness can be stored on-chain in some encrypted manner or sent directly to the recipient through a separate channel. In the UTXO model, if the recipient is unable to recover the randomness (an incorrect value was encrypted/sent, nothing sent at all, etc.), then the recipient cannot spend the UTXO later.” (Para. 0047))
performing, by the verifier via the associated node in the subnetwork, the privacy enabled auditing for the inter-bank fund transfer if the detected bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the privacy enabled auditing comprising steps of: (“The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
a) challenging, the first bank and the second bank by the verifier on the inter-bank fund transfer using the transaction IDs and a challenge nonce; . . .; c) re-encrypting, by the verifier, the second encrypted transaction amount for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted transaction amount for each of the first bank and the second bank; d) retrieving the transaction amount by the verifier from the re-encrypted transaction amount using the predicate and a verifier secret key; e) generating, a verifier tag for each of the first bank and the second bank, by the verifier based on retrieved transaction amount and the challenge nonce; and f) declaring an audit of the transaction amount as successful, by the verifier, if the generated verifier tag of each of the first bank and the second bank match, else declaring the audit as failure. (“A game can be defined between a challenger Chal and an adversary Adv to capture the requirements, where Chal represents the honest users in the network. Both Chal and Adv have access to an oracle Figure US20190164153A1-20190530-P00006 SC who maintains the smart contract SC. Adv has full view of the oracle: it can see all the transactions sent by Chal to SC, how the state of SC changes, etc. Adv is provided with substantial control over SC's state. It can instruct any honest party at any time (via the challenger) to publish a transaction. It can create its own malformed transactions based on the transactions of honest parties, and then push the former into the blockchain ahead of the latter. In particular, it can arbitrarily delay the transactions of honest parties.” (Para. 0130), “At block 306, the application smart contract is executed to perform its underlying functions resulting in one or more transactions to be performed on the locked accounts. For example, the one or more transactions resulting from execution of the application smart contract may cause the first balance of the first account to be decremented by a first amount, and the second balance of the second account to be incremented by a second amount. The transaction data of each transaction may include a cryptographic proof and a signature generated based on a nonce (e.g., counter, or an epoch base derived from hashing a predetermined string and an epoch number of an epoch during which the transaction is initiated). It should be noted that the application smart contract still relies on the user device to generate the underlying transaction data (e.g., cryptographic proof, signature), because only the user device has access to the necessary private key used in generation of the transaction data. In some embodiments, the transaction can be stored as a pending transfer transaction of the first account during a particular epoch, and roll over of the pending transfer transaction to the first account can occur in a subsequent epoch after the particular epoch. The roll over can be performed in response to receiving a subsequent transaction involving the first account.” (Para. 0093), “Additionally, a public key may be able to verify a digital signature created with the corresponding private key. The public key may be distributed throughout a network in order to allow for verification of messages signed using the corresponding private key. Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC). In some embodiments, a key pair may be generated using an asymmetric key pair algorithm.” (Para. 0023); “Once a validation node has received the message, the validation node may distribute the message to the other validation nodes in blockchain network 102. Each of the validation nodes 106A-D may include the transaction represented by the message in a block of transactions and attempt to validate or cryptographically solve the block. The first validation node that solves the block may provide the solution to the other validation nodes for verification, and ledger 104 maintained at each of validation nodes 106A-D can be updated to add the block to ledger 104 to effect the transaction.” (Para. 0030))
Agrawal does not disclose:
“b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate, wherein the re-encryption key is generated using public keys, private keys and the predicate of the originating party and obtain a re-encrypted ciphertext by applying the re-encryption key and the predicate to the ciphertext encrypted under the public keys;” (claim 1).
However, as per Claim 1, Ito in the analogous art of encrypted digital transmissions, teaches: “b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate”. (The banks secret key is analogous to an attribute private key (‘sk’) generated for the entity by the key generation apparatus, see “The key generation section 421 of the key generation apparatus 401 performs private key generation in functional encryption, based on inputs of a master private key and a public parameter, stored in the master key information storage section 411, and of the received user attribute. As a result, an attribute private key on which the user attribute (one of the pieces of user attribute information) is set is generated.” (Para. 0119); see also “Referring to the above example, with respect to Ms. Hanako Sato whose user ID is uid2, an attribute private key sk2 is generated based on an input of the user attribute. . .” (Para. 0120); the banks public key is analogous to the systems public parameter (‘pk’) used with that entity’s scheme, see Fig. 15 “611: Public Parameter Storage Section . . ‘pk’ (Fig. 15).”; the verifier public key and predicate is analogous to the verifiers identifier (e.g. User Private Key ID = ‘ukid’) bound as a decryption condition/predicate that targets the re-encryption to the verifier, see “The key generation section 421 of the key generation apparatus 401 generates a unique user secret ID (one of the pieces of key information) in the key information storage section 412. Herein, ukid is assumed to be generated.” (Para. 0122); the verifier is analogous to the re-encryption apparatus 301, receiving and using the re-encryption key to gate access and return transformed outputs, see “The re-encryption apparatus 301 receives ciphertext on which a decryption condition is set, then re-encrypts the received ciphertext for a specific user, and sends it to a user terminal 601. The re-encryption apparatus 301 includes a public parameter storage section 311, a re-encryption key storage section 312, a re-encryption section 321 and a communication section 331.” (Para. 0066); here, bank A (‘uid_1’) and bank B (‘uid_2’) can correspond to two source entities in the system for whom keys are issued and re-encryption keys are stored per user ID, see the multi-user re-encryption-key table of Fig. 28 (“312: Re-encryption key storage section. . .” (Fig. 28); the step of generating the re-encryption key is taught by “(S206) The key generation section 421 of the key generation apparatus 401 performs re-encryption key generation in functional encryption, based on inputs of the public parameter, the attribute private key and a decryption condition “User private key ID=ukidi” (the other piece of key information). As a result, a re-encryption key is” generated. . . the re-encryption key generated herein is a key to re-encrypt the ciphertext that can be decrypted with the received attribute private key, into the ciphertext that can be decrypted with the user private key on which the received user private key ID is set. (Para. 0124 and 0126); the step of sharing the re-encryption key is taught by “The communication section 431 of the key generation apparatus 401 sends the public parameter, the user private key and the re-encryption key to the attribute management apparatus 501. With reference to the above example, uk2 and rk2 are sent as the user private key and the re-encryption key.” (Para. 0131-0132); note that the same ‘share-to-verifier’ flow is taught again during updates, as “The communication section 431 of the key generation apparatus 401 sends the newly generated re-encryption key to the attribute management apparatus 501. With reference to the above example, rk202 is sent as the re-encryption key.” (Para. 0239 and 0240); the step of generating and sharing with the verifier is taught at least in Para. 0163, where the datastore is analogous to a blockchain query and the ciphertext is queried/acquired from a remote ciphertext store by data ID and then sent onward for processing, “The communication section 631 of the user terminal 601 sends the data ID of data to be acquired to the ciphertext storage apparatus 201. The ciphertext storage apparatus 201, upon receipt of the data ID, acquires the ciphertext related to the data ID from the ciphertext storage section 211, and sends the ciphertext to the user terminal 601.” (Para. 0163); the re-encryption apparatus transforms the encrypted amounts conditioned on a predicate (e.g. user private key ID = ukid_2) and returns it, “The re-encryption section 321 of the re-encryption apparatus 301 performs re-encryption in functional encryption based on inputs of the public parameter stored in the public parameter storage section 311, the re-encryption key acquired from the re-encryption key storage section 312 and the received ciphertext. As a result, the ciphertext (re-ciphertext) that can be decrypted with the user private key is generated. With reference to the above example, the ciphertext c1 is re-encrypted with the re-encryption key rk2 to generate ciphertext C1 with the decryption condition “User private key ID=ukid2” (Para. 0170-0171); and the verifier apparatus first acquires the re-encryption key to do this conversion (confirming the role of the verifier in the flow), “The re-encryption apparatus 301, upon receipt of the user ID and the ciphertext, acquires the re-encryption key related to the user ID from the re-encryption key storage section 312.” (Para. 0168).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Agrawal with the technique of Ma to include the functionality of secure delegation of ciphertext transformation between parties. Therefore, the incentives of providing enhanced data confidentiality and privacy-preserving transaction auditing provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Agrawal teaches:
The processor implemented method of claim 1, wherein if the bilateral transaction request is privacy enabled inter-bank settlements between the first bank and the second bank, the method performs the steps comprising: executing a smart contract querying encrypted debits and credits of the first bank and the second bank to obtain encrypted sum of credits and sum of debits for each of the first bank and the second bank in a settlement cycle, encrypted under a first public key of the first bank and a second public key of the second bank from the CH-PRE key pair; (“At block 306, the application smart contract is executed to perform its underlying functions resulting in one or more transactions to be performed on the locked accounts.” (Para. 0093); “Each of the entries may include a public key associated with an account and a balance ciphertext representing a balance of the account. The balance ciphertext can be generated, for example, by encrypting the balance with the public key of the corresponding account.” (Para. 0091); “The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086))
storing the encrypted sum of credits and sum of debits for each of the first bank and the second bank on the blockchain; (“a blockchain system may include storing a set of entries representing a state of a platform smart contract in a blockchain network. The set of entries may including at least a first entry comprising a first public key associated with a first account, and a first ciphertext representing a first balance of the first account; a second entry comprising a second public key associated with a second account, and a second ciphertext representing a second balance of the second account; and a third entry comprising a third public key associated with a third account, and a third ciphertext representing a third balance of the third account.” (Para. 0004); “Each of the validation nodes 106A-D may be a computing device associated with an entity or a user participating in blockchain network 102, and may maintain a ledger 104 (e.g., a blockchain) distributed amongst the group of validation nodes 106A-D in blockchain network 102. In some embodiments, ledger 104 may contain records of transactions conduct between cryptocurrency accounts in blockchain network 102.” (Para. 0029); “The transactions can be verified and extended by any entity, making them open and transparent.” (Para. 0002))
challenging the first bank and the second bank by the verifier for the privacy enabled inter-bank settlement using a settlement challenge nonce; (“The transaction data of each transaction may include a cryptographic proof and a signature generated based on a nonce (e.g., counter, or an epoch base derived from hashing a predetermined string and an epoch number of an epoch during which the transaction is initiated). It should be noted that the application smart contract still relies on the user device to generate the underlying transaction data (e.g., cryptographic proof, signature), because only the user device has access to the necessary private key used in generation of the transaction data.” (Para. 0093); “In some embodiments, the nonce can be a counter that is incremented for each transaction associated with the public key, or an epoch base that is unique for each epoch (e.g., can be derived from hashing a predetermined string and an epoch number of an epoch during which the corresponding transaction is initiated). The ReadBalance function is used to obtain the balance associated with the user's public key from platform smart contract state 230.” (Para. 0085); “A similar nonce protection as for the anonymous transfer can be used to prevent that a user claims the same winning lottery ticket twice.” (Para. 0229))
generating by each of the first bank and the second bank and sharing with the verifier i) a settlement bank tag by using the settlement challenge nonce and a decryption of encrypted sum of credits and sum of debits using the bank secret key, and ii) a re-encryption key using the bank secret key, the bank public key, verifier public key and the predicate; (“The user would keep these variables secret and prove various statements using them. Only one of s1, . . . , sn and one of t1, . . . , tn should be 1. This could be shown by proving that each of these variables is either 0 or 1, Σisi=1 and Σiti=1.” (Para. 0151); “These statements can be proved more efficiently using techniques from one-out-of-many proofs and in particular the extension to EIGamal encryptions. These proofs are Σ protocols that can be used to show that a decryption of one out of n ciphertexts has certain properties, e.g. they are 0.” (Para. 0154); “The user proves that she knows a private key which won the lottery instead of revealing her stake. A similar nonce protection as for the anonymous transfer can be used to prevent that a user claims the same winning lottery ticket twice.” (Para. 0229))
re-encrypting, by the verifier, a decryption of encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted sum of credits and sum of debits for each of the first bank and the second bank; (“Suppose a user wants to transfer an amount b* from a public key y to a public key y. Let (CL, CR) be the encryption of balance associated with y. The smart contract needs to deduct b* from y's balance and add the same amount to y's balance. Since b* is hidden in this process, user will encrypt b* under both y and y to get (C, D) and (C, D), respectively. A proof is provided to show that: 1. both ciphertexts are well formed and encrypt the same value; 2. b* is a positive value; and, 3. the remaining balance of y, say b′, is positive too.” (Para. 0140-0143); “Now the verifier creates commitment P to l(X), r(X) from A, S, y, z and checks the following condition . . . Note that second condition requires that T and the Vi's are additively homomorphic. Therefore T and Vi cannot be simply replaced with EIGamal encryptions as they are not homomorphic if done under different keys.” (Para. 0190-0191); “Bulletproofs enables proofs on Pedersen committed values by computing a linear combination of commitments and opening that combination. This uses the homomorphic property of Pedersen commitments that use the same commitment key. The core idea of Σ-Bullets is to replace this linear combination with a Σ-protocol. The Σ-protocol ensures that the linear combination of encoded values is equal to some public value. The efficient composability of Σ-protocols allows the opening to be combined with other proofs.” (Para. 0184))
retrieving sum of debits and sum of credits for each of the first bank and the second bank by the verifier from the re-encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the verifier secret key; (“Consider a burn transaction where a user needs to verifiably decrypt his Zether balance. It can certainly do this by revealing its secret key to the smart contract. However, an adversary can use the secret key to decrypt all previous balances and transactions of the user, thus completely breaking its privacy. So, instead of decrypting in the clear, the user creates a ZK-proof.” (Para. 0138); “an extractor can compute the witness from two accepting transcripts with the same first round message Ay, AC R , Au. The transcripts also contain (c, ssk) and (c′, ssk′) respectively. If both transcripts are accepting then the extractor can output =ssk-ssk′c-c′ as a valid witness.” (Para. 0194); “similar ZK-proof can be used as the anonymous Zether transfer. The user proves that she knows a private key which won the lottery instead of revealing her stake.” (Para. 0229))
generating a settlement verifier tag for each of the first bank and the second bank, by the verifier from the retrieved sum of debits and sum of credits for each of the first bank and the second bank, and the settlement challenge nonce; and (“instead of decrypting in the clear, the user creates a ZK-proof for the following statement: stburn:{(y,C L ,C R ,u,b,g,g epoch ;sk):y=g sk ∧C L =g b C R sk ∧u=g epoch sk} (1) The statement shows that the user knows an sk such that y is indeed the public key corresponding to sk, CL, CR is a valid encryption of b under y, and u is the correct nonce with respect to sk for the current epoch.” (Para. 0138-0139); “To prove special-soundness an extractor can compute the witness from two accepting transcripts with the same first round message Ay, AC R , Au. The transcripts also contain (c, ssk) and (c′, ssk′) respectively. If both transcripts are accepting then the extractor can output =ssk-ssk′c-c′ as a valid witness.” (Para. 0194); “a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210.” (Para. 0086))
declaring the inter-bank settlement complete, by the verifier, if the generated settlement verifier tag for sum of debits of the first bank and the sum of credits of the second bank match, and settlement verifier tag for sum of credits of the first bank and the sum of debits of the second bank match, else declaring the inter-bank settlement as failure. (“If both transcripts are accepting then the extractor can output =ssk-ssk′c-c′ as a valid witness.” (Para. 0194); “it can be seen that transfer transactions cannot be used to increase the overall Zether balance of the accounts involved. Further note that the nonce along with the soundness of the proof system, enforce that an adversary will at most be able to do a single transfer per account per epoch.” (Para. 0282); “The following section provides a formal description of the correctness property. Honestly-Generated Transactions . . . Let TX=(TX1, TX2, . . . , TXm) be a group of transactions such that for every i∈[m], TXi=(txi,1, txi,2, . . . ) is a sequence of transactions which are processed in that order into the block at height hi (h1<h2< . . . <hm). Define the k-th transaction in TX to be the k-th transaction in the sequence (tx1,1, tx2,1, . . . , tx2,1, tx2,2, . . . , . . . , txm,1, txm,2). These transactions were generated honestly if all of the following are true.” (Para. 0230-0231))
As per Claim 3, Agrawal teaches:
The processor implemented method of claim 1, wherein the encrypted first current balance and the encrypted transaction amount at the first encryption instance is obtained by encrypting a first current balance of the first customer using the bank public key from the CH-PRE key pair and a dummy predicate with unity value; and wherein the encrypted second current balance and the encrypted transaction amount at first encryption instance is obtained by encrypting a second current balance of the second customer using the bank public key of the second bank from the CH-PRE key pair and the dummy predicate with unity value. (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
As per Claim 4, Agrawal teaches:
The processor implemented method of claim 1, wherein the tuple enables privacy enabled auditing by the verifier, and wherein transaction ID is used to validate a challenged transaction ID sent by the verifier, the user ID is used to retrieve all transactions pertaining to a challenged customer and bank ID is used to retrieve all transactions performed by a bank. (“Platform smart contract interface 260 may include a set of user algorithms that implement various functions to interact with platform smart contract 210. The set of user algorithms may implement the following functions: CreateAddress; CreateFundTx; CreateTransferTx; CreateBurnTx; CreateLockTx; CreateUnlockTx; and ReadBalance. The CreateAddress user function is used to generate a public and private key pair. The generated public key can be used as an address to reference the account of the user in platform smart contract 210. The public key is shared with other users participating in platform smart contract 210. The private key is kept private, and is used to generate signatures and proofs. The CreateFundTx, CreateTransferTx, CreateBurnTx, CreateLockTx, and CreateUnlockTx are used to invoke their counterparts in platform smart contract 210. These user algorithms may output transaction data to request their corresponding functions in platform smart contract 210. The transaction data may include a set of public keys of the accounts involved in the transaction, ciphertexts representing amounts if a transfer is involved, a signature generated by signing nonce 290 with private key 280, and a proof that is validated by validation node computing device 206 to effect the transaction. In some embodiments, the nonce can be a counter that is incremented for each transaction associated with the public key, or an epoch base that is unique for each epoch (e.g., can be derived from hashing a predetermined string and an epoch number of an epoch during which the corresponding transaction is initiated). The ReadBalance function is used to obtain the balance associated with the user's public key from platform smart contract state 230. Additional details of the platform smart contract algorithms and user algorithms are further described in sections 5 and 6 below.” (Para. 0085), “The case of two consistent transfer instructions is left. A transfer transaction consists of an anonymity set y, a list of commitments C, a blinding value D, a nonce u, and πtransfer. Two consistent transactions could have two different senders, so the nonce values could be different. However, gepoch x (for any x) is indistinguishable from random under the DDH assumption since both y and gepoch are random (when Figure US20190164153A1-20190530-P00041 is modeled as a random oracle). Further, ciphertexts (Ci, D) for honest i are indistinguishable from the encryption of random messages. Now, let the receivers for the two instructions be j and k. If neither of them are under the control of Adv, then all the ciphertexts Adv can decrypt are just encryptions of 0. Otherwise, both j and k must be corrupt. In this case, Adv can decrypt (Cj, D) and (Ck, D) too, but then they must decrypt to the same amount.” (Para. 0285)
As per Claim 5, Agrawal teaches:
A system for transaction privacy and auditing, the system comprising: a subnetwork, within a blockchain network controlled by one or more hardware processors, comprising a first bank, a second bank and a verifier participating in the subnetwork via an associated node coupled, wherein the one or more hardware processors is coupled to a memory via one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to: detect initiation of a bilateral transaction request comprising one of: (a) an inter-bank fund transfer from a first customer of the first bank to a second customer of the second bank with a privacy enabled auditing by the verifier, and (b) privacy enabled inter-bank settlements between the first bank and the second bank, wherein the first bank, the second bank and the verifier individually own a Conditional Homomorphic Proxy Re-encryption (CH-PRE) key pair comprising a public key stored on the blockchain and a secret key; wherein the CH-PRE performs computations on transformed encrypted data that is specified with conditions or predicates to be satisfied during encryption to enhance transaction privacy and auditing, wherein the CH-PRE includes a setup algorithm which takes security parameter as an input and outputs a public parameter set, a key generation algorithm which takes the public parameter set as an input and generates a public and private key pair, an encryption function to encrypt an originator's message using a public key of the originator and predicate, wherein the predicate ensure that all other ciphertexts expect the one that is intended to be sent are not decrypted by a target entity, a re-encryption function which takes a re-encryption key as an input to transform a ciphertext encrypted under originator's public key to decrypted by the target entity under some predicate, a re-encryption transforms the ciphertext encrypted under originator's public key to another ciphertext with the same underlying message that is decrypted by the target entity using its secret key, a decryption function performed on re-encrypted ciphertext using the target entity's private key; (regarding the newly added limitations related to the CH-PRE, the following citations are related to part (a), as the claim requires one of (a) or (b): “The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The techniques described herein may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.” (Para. 0287)
execute, by the first bank and the second bank via the associated node controlled by the one or more hardware processors, a smart contract, if the bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the smart contract is executed to i) deduct an encrypted first current balance of a first customer by an encrypted transaction amount encrypted at a first encryption instance to obtain an encrypted first updated balance, and ii) add the first encrypted transaction amount to an encrypted second current balance to obtain an encrypted second updated balance for the second customer; (“The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The Transfer function is used to transfer an amount of tokens from one public key to another. The Lock function is used to lock a public key (and its associated account) to an address such as an address of an application smart contract or another account. Once a public key is locked, transfer of tokens associated with the public key and unlocking of the public key cannot be performed unless the operation came from the address that the public key is locked to. The Unlock function is used to unlock a locked public key, and can be only effective if called by the address that the public key is locked to. The Burn function is used to convert tokens (e.g., ZTH) associated with a public key back to a cryptocurrency amount for a cryptocurrency account (e.g., ETH for an Ethereum address)..” (Para. 0080), “Application smart contract 240 can be executed to perform its underlying functions, causing one or more transactions to be performed on the locked public keys. Application smart contract 240 can then send the one or more transactions to platform smart contract 210 to be processed, and unlock the locked public keys.” (Para. 0089))
encrypt by the first bank and the second bank via the associated node controlled by the one or more hardware processors, the transaction amount, wherein i) the first bank uses a CH-PRE function having a first predicate comprising a tuple (a transaction Identifier (txid), a user ID and a bank ID) and ii) the second bank uses the CH-PRE function having the second predicate comprising the tuple, to obtain an encrypted transaction amount associated with a second encryption instance; (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “The transaction is then posted as a pending transaction to each of the additional public keys and the public keys of the sender and receiver. When the pending transaction is rolled over, the first operand ciphertext (representing a negative of the transaction amount) is added to the encrypted balance of the sender, the second operand ciphertext (representing a positive of the transaction amount) is added to the encrypted balance of the receiver, and the additional operand ciphertexts (encryption of zero by corresponding public key) are added to the respective balances of the additional public keys.” (Para. 0088), “the signature can be generated, for example, by encrypting the smart contract address and a nonce (e.g., counter value or epoch base). In some embodiments, the lock request can be received during a particular epoch, and locking of the account can occur or take effect in a subsequent epoch after the particular epoch. In some embodiments, while an account is locked to the application smart contract, only the application smart contract is permitted to unlock the account.” (Para. 0092))
store via the associated node controlled by the one or more hardware processors, i) by the first bank the encrypted first updated balance and the encrypted transaction amount associated with the second encryption instance, and ii) by the second bank the encrypted second updated balance and the encrypted transaction amount associated with the second encryption instance; and (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “A transaction can transfer wei between accounts or trigger the execution of smart contract code. Smart contracts can send messages to other smart contracts, mimicking function calls. Every transaction and code execution is replicated on all nodes in the network. Every executed operation has a specified cost expressed in terms of gas units. For example, storing 256 bits of data costs 20,000 units of gas while changing it costs 5,000 units and reading it costs 200 units. The sender pays for all smart contract operations that the transaction calls.” (Para. 0041), “Homomorphic commitments such as Pedersen commitments can be used to make transactions confidential. Though Pedersen commitments are simple and efficient, the opening of these commitments are transferred to the recipient so that the recipient can subsequently use the funds. This randomness can be stored on-chain in some encrypted manner or sent directly to the recipient through a separate channel. In the UTXO model, if the recipient is unable to recover the randomness (an incorrect value was encrypted/sent, nothing sent at all, etc.), then the recipient cannot spend the UTXO later.” (Para. 0047))
perform by the verifier via the associated node in the subnetwork, the privacy enabled auditing for the inter-bank fund transfer if the detected bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the privacy enabled auditing comprising steps of: (“The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
a) challenging, the first bank and the second bank by the verifier on the inter-bank fund transfer using the transaction IDs and a challenge nonce;. . .; c) re-encrypting, by the verifier, the second encrypted transaction amount for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted transaction amount for each of the first bank and the second bank; d) retrieving the transaction amount by the verifier from the re-encrypted transaction amount using the predicate and a verifier secret key; e) generating, a verifier tag for each of the first bank and the second bank, by the verifier based on retrieved transaction amount and the challenge nonce; and f) declaring an audit of the transaction amount as successful, by the verifier, if the generated verifier tag of each of the first bank and the second bank match, else declaring the audit as failure. (“A game can be defined between a challenger Chal and an adversary Adv to capture the requirements, where Chal represents the honest users in the network. Both Chal and Adv have access to an oracle Figure US20190164153A1-20190530-P00006 SC who maintains the smart contract SC. Adv has full view of the oracle: it can see all the transactions sent by Chal to SC, how the state of SC changes, etc. Adv is provided with substantial control over SC's state. It can instruct any honest party at any time (via the challenger) to publish a transaction. It can create its own malformed transactions based on the transactions of honest parties, and then push the former into the blockchain ahead of the latter. In particular, it can arbitrarily delay the transactions of honest parties.” (Para. 0130), “At block 306, the application smart contract is executed to perform its underlying functions resulting in one or more transactions to be performed on the locked accounts. For example, the one or more transactions resulting from execution of the application smart contract may cause the first balance of the first account to be decremented by a first amount, and the second balance of the second account to be incremented by a second amount. The transaction data of each transaction may include a cryptographic proof and a signature generated based on a nonce (e.g., counter, or an epoch base derived from hashing a predetermined string and an epoch number of an epoch during which the transaction is initiated). It should be noted that the application smart contract still relies on the user device to generate the underlying transaction data (e.g., cryptographic proof, signature), because only the user device has access to the necessary private key used in generation of the transaction data. In some embodiments, the transaction can be stored as a pending transfer transaction of the first account during a particular epoch, and roll over of the pending transfer transaction to the first account can occur in a subsequent epoch after the particular epoch. The roll over can be performed in response to receiving a subsequent transaction involving the first account.” (Para. 0093), “Additionally, a public key may be able to verify a digital signature created with the corresponding private key. The public key may be distributed throughout a network in order to allow for verification of messages signed using the corresponding private key. Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC). In some embodiments, a key pair may be generated using an asymmetric key pair algorithm.” (Para. 0023); “Once a validation node has received the message, the validation node may distribute the message to the other validation nodes in blockchain network 102. Each of the validation nodes 106A-D may include the transaction represented by the message in a block of transactions and attempt to validate or cryptographically solve the block. The first validation node that solves the block may provide the solution to the other validation nodes for verification, and ledger 104 maintained at each of validation nodes 106A-D can be updated to add the block to ledger 104 to effect the transaction.” (Para. 0030))
Agrawal does not disclose:
“b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate, wherein the re-encryption key is generated using public keys, private keys and the predicate of the originating party and obtain a re-encrypted ciphertext by applying the re-encryption key and the predicate to the ciphertext encrypted under the public keys;” (claim 5).
However, as per Claim 5, Ito in the analogous art of encrypted digital transmissions, teaches: “b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate”. (The banks secret key is analogous to an attribute private key (‘sk’) generated for the entity by the key generation apparatus, see “The key generation section 421 of the key generation apparatus 401 performs private key generation in functional encryption, based on inputs of a master private key and a public parameter, stored in the master key information storage section 411, and of the received user attribute. As a result, an attribute private key on which the user attribute (one of the pieces of user attribute information) is set is generated.” (Para. 0119); see also “Referring to the above example, with respect to Ms. Hanako Sato whose user ID is uid2, an attribute private key sk2 is generated based on an input of the user attribute. . .” (Para. 0120); the banks public key is analogous to the systems public parameter (‘pk’) used with that entity’s scheme, see Fig. 15 “611: Public Parameter Storage Section . . ‘pk’ (Fig. 15).”; the verifier public key and predicate is analogous to the verifiers identifier (e.g. User Private Key ID = ‘ukid’) bound as a decryption condition/predicate that targets the re-encryption to the verifier, see “The key generation section 421 of the key generation apparatus 401 generates a unique user secret ID (one of the pieces of key information) in the key information storage section 412. Herein, ukid is assumed to be generated.” (Para. 0122); the verifier is analogous to the re-encryption apparatus 301, receiving and using the re-encryption key to gate access and return transformed outputs, see “The re-encryption apparatus 301 receives ciphertext on which a decryption condition is set, then re-encrypts the received ciphertext for a specific user, and sends it to a user terminal 601. The re-encryption apparatus 301 includes a public parameter storage section 311, a re-encryption key storage section 312, a re-encryption section 321 and a communication section 331.” (Para. 0066); here, bank A (‘uid_1’) and bank B (‘uid_2’) can correspond to two source entities in the system for whom keys are issued and re-encryption keys are stored per user ID, see the multi-user re-encryption-key table of Fig. 28 (“312: Re-encryption key storage section. . .” (Fig. 28); the step of generating the re-encryption key is taught by “(S206) The key generation section 421 of the key generation apparatus 401 performs re-encryption key generation in functional encryption, based on inputs of the public parameter, the attribute private key and a decryption condition “User private key ID=ukidi” (the other piece of key information). As a result, a re-encryption key is” generated. . . the re-encryption key generated herein is a key to re-encrypt the ciphertext that can be decrypted with the received attribute private key, into the ciphertext that can be decrypted with the user private key on which the received user private key ID is set. (Para. 0124 and 0126); the step of sharing the re-encryption key is taught by “The communication section 431 of the key generation apparatus 401 sends the public parameter, the user private key and the re-encryption key to the attribute management apparatus 501. With reference to the above example, uk2 and rk2 are sent as the user private key and the re-encryption key.” (Para. 0131-0132); note that the same ‘share-to-verifier’ flow is taught again during updates, as “The communication section 431 of the key generation apparatus 401 sends the newly generated re-encryption key to the attribute management apparatus 501. With reference to the above example, rk202 is sent as the re-encryption key.” (Para. 0239 and 0240); the step of generating and sharing with the verifier is taught at least in Para. 0163, where the datastore is analogous to a blockchain query and the ciphertext is queried/acquired from a remote ciphertext store by data ID and then sent onward for processing, “The communication section 631 of the user terminal 601 sends the data ID of data to be acquired to the ciphertext storage apparatus 201. The ciphertext storage apparatus 201, upon receipt of the data ID, acquires the ciphertext related to the data ID from the ciphertext storage section 211, and sends the ciphertext to the user terminal 601.” (Para. 0163); the re-encryption apparatus transforms the encrypted amounts conditioned on a predicate (e.g. user private key ID = ukid_2) and returns it, “The re-encryption section 321 of the re-encryption apparatus 301 performs re-encryption in functional encryption based on inputs of the public parameter stored in the public parameter storage section 311, the re-encryption key acquired from the re-encryption key storage section 312 and the received ciphertext. As a result, the ciphertext (re-ciphertext) that can be decrypted with the user private key is generated. With reference to the above example, the ciphertext c1 is re-encrypted with the re-encryption key rk2 to generate ciphertext C1 with the decryption condition “User private key ID=ukid2” (Para. 0170-0171); and the verifier apparatus first acquires the re-encryption key to do this conversion (confirming the role of the verifier in the flow), “The re-encryption apparatus 301, upon receipt of the user ID and the ciphertext, acquires the re-encryption key related to the user ID from the re-encryption key storage section 312.” (Para. 0168).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Agrawal with the technique of Ma to include the functionality of secure delegation of ciphertext transformation between parties. Therefore, the incentives of providing enhanced data confidentiality and privacy-preserving transaction auditing provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 6, Agrawal teaches:
The system of claim 5, wherein the one or more hardware processors are configured to perform, if the bilateral transaction request is privacy enabled inter-bank settlements between the first bank and the second bank, the steps comprising: executing a smart contract querying encrypted debits and credits of the first bank and the second bank to obtain encrypted sum of credits and sum of debits for each of the first bank and the second bank in a settlement cycle, encrypted under a first public key of the first bank and a second public key of the second bank from the CH-PRE key pair; (“When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
storing the encrypted sum of credits and sum of debits for each of the first bank and the second bank on the blockchain; (“Platform smart contract state 230 may include a set of entries representing accounts participating in platform smart contract. Each entry may include a public key that can be used to reference an account, an encrypted balance represent the amount of tokens available for the public key, a lock status of the public key, and pending transaction(s) associated with the public key. The lock status indicates whether a public key (and its associated account) is locked. If the public key is locked, the lock status may indicated the address that the public key is being locked to. If the public key is not locked, the lock status may indicate an unlocked status Pending transactions store pending transactions associated with a public key. A transaction (e.g., transfer, and/or lock, etc.) initiated in a particular epoch can initially be considered a pending transition and is recorded as such in platform smart contract state 230. The pending transaction associated with a public key can take effect or be rolled over to the corresponding account in a subsequent epoch (e.g., at later epoch when a new transaction involving that public key is invoked).” (Para. 0082)
challenging the first bank and the second bank by the verifier for the privacy enabled inter-bank settlement using a settlement challenge nonce; generating by each of the first bank and the second bank and sharing with the verifier i) a settlement bank tag by using the settlement challenge nonce and a decryption of encrypted sum of credits and sum of debits using the bank secret key, and ii) a re-encryption key using the bank secret key, the bank public key, verifier public key and the predicate; (“A transfer transaction will now be described. For intuition, valid transactions will first be described with reference to the purely confidential variant of Zether which does not provide any additional anonymity. Suppose a user wants to transfer an amount b* from a public key y to a public key y. Let (CL, CR) be the encryption of balance associated with y. The smart contract needs to deduct b* from y's balance and add the same amount to y's balance. Since b* is hidden in this process, user will encrypt b* under both y and y to get (C, D) and (C, D), respectively. A proof is provided to show that: 1. both ciphertexts are well formed and encrypt the same value; 2. b* is a positive value; and, 3. the remaining balance of y, say b′, is positive too.” (Para. 0140-0143)
re-encrypting, by the verifier, a decryption of encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted sum of credits and sum of debits for each of the first bank and the second bank; (“To handle such a complex statement efficiently without revealing j. . ., b* and b′, new binary variables s1, . . . , sn and t1, . . . , tn are introduced. Value 1 for an si denotes that money is being transferred from yi and value 1 for a tj denotes that money is being transferred to yj. The user would keep these variables secret and prove various statements using them. Only one of s1, . . . , sn and one of t1, . . . , tn should be 1. This could be shown by proving that each of these variables is either 0 or 1, Σisi=1 and Σiti=1.” (Para. 0151)
retrieving sum of debits and sum of credits for each of the first bank and the second bank by the verifier from the re-encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the verifier secret key; generating a settlement verifier tag for each of the first bank and the second bank, by the verifier from the retrieved sum of debits and sum of credits for each of the first bank and the second bank, and the settlement challenge nonce; and declaring the inter-bank settlement complete, by the verifier, if the generated settlement verifier tag for sum of debits of the first bank and the sum of credits of the second bank match, and settlement verifier tag for sum of credits of the first bank and the sum of debits of the second bank match, else declaring the inter-bank settlement as failure. (“Given that exactly one of s1, . . . , sn is 1 and rest are 0, Eq (3) shows that the ciphertext for non-zero si is a valid encryption of b*. Subtracting Eq (3) from Eq (4) yields Πi=1 nCi t i =g−b*Πi=1 ny1 r·t i , which shows that the ciphertext for non-zero ti is a valid encryption of −b*. Thus, Eq (3) and (4) together show that the ciphertexts that encode non-zero quantities are valid. These statements can be proved more efficiently using techniques from one-out-of-many proofs and in particular the extension to EIGamal encryptions. These proofs are Σ protocols that can be used to show that a decryption of one out of n ciphertexts has certain properties, e.g. they are 0. The proof size is only logarithmic in n. This is achieved by writing i in its binary representations and constructing n products such that only the ith is 1 and all other are 0.” (Para. 0154)
As per Claim 7, Agrawal teaches:
The system as claimed in claim 5, wherein the encrypted first current balance and the encrypted transaction amount at the first encryption instance is obtained by encrypting a first current balance of the first customer using the bank public key from the CH-PRE key pair and a dummy predicate with unity value; and wherein the encrypted second current balance and the encrypted transaction amount at first encryption instance is obtained by encrypting a second current balance of the second customer using the bank public key of the second bank from the CH-PRE key pair and the dummy predicate with unity value. (“The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The case of two consistent transfer instructions is left. A transfer transaction consists of an anonymity set y, a list of commitments C, a blinding value D, a nonce u, and πtransfer. Two consistent transactions could have two different senders, so the nonce values could be different. However, gepoch x (for any x) is indistinguishable from random under the DDH assumption since both y and gepoch are random (when Figure US20190164153A1-20190530-P00041 is modeled as a random oracle). Further, ciphertexts (Ci, D) for honest i are indistinguishable from the encryption of random messages. Now, let the receivers for the two instructions be j and k. If neither of them are under the control of Adv, then all the ciphertexts Adv can decrypt are just encryptions of 0. Otherwise, both j and k must be corrupt. In this case, Adv can decrypt (Cj, D) and (Ck, D) too, but then they must decrypt to the same amount.” (Para. 0285)
As per Claim 8, Agrawal teaches:
The system as claimed in claim 5, wherein the tuple enables privacy enabled auditing by the verifier, and wherein transaction ID is used to validate a challenged transaction ID sent by the verifier, the user ID is used to retrieve all transactions pertaining to a challenged customer and bank ID is used to retrieve all transactions performed by a bank. (“The transaction data may include a set of public keys of the accounts involved in the transaction, ciphertexts representing amounts if a transfer is involved, a signature generated by signing nonce 290 with private key 280, and a proof that is validated by validation node computing device 206 to effect the transaction. In some embodiments, the nonce can be a counter that is incremented for each transaction associated with the public key, or an epoch base that is unique for each epoch (e.g., can be derived from hashing a predetermined string and an epoch number of an epoch during which the corresponding transaction is initiated). The ReadBalance function is used to obtain the balance associated with the user's public key from platform smart contract state 230. Additional details of the platform smart contract algorithms and user algorithms are further described in sections 5 and 6 below.” (Para. 0085), “To conduct a confidential and anonymous transaction, the transaction data of the transfer transaction request may further include additional public keys of other accounts not involved in the transaction, and additional operand ciphertexts corresponding to the additional public keys by encrypting a value of zero. The transaction is then posted as a pending transaction to each of the additional public keys and the public keys of the sender and receiver. When the pending transaction is rolled over, the first operand ciphertext (representing a negative of the transaction amount) is added to the encrypted balance of the sender, the second operand ciphertext (representing a positive of the transaction amount) is added to the encrypted balance of the receiver, and the additional operand ciphertexts (encryption of zero by corresponding public key) are added to the respective balances of the additional public keys. A public view of platform smart contract state 230 would not be able to determine which parties are the sender and receiver because the balances associated with a larger group of public keys are all being updated.” (Para. 0088), “FIG. 3 illustrates a flow diagram of a process 300 for transacting in a platform smart contract, according to some embodiments. Process 300 may begin at block 302 by storing a set of entries representing a state of a platform smart contract (e.g., Zether) in a blockchain network. Each of the entries may include a public key associated with an account and a balance ciphertext representing a balance of the account. The balance ciphertext can be generated, for example, by encrypting the balance with the public key of the corresponding account. For example, the set of entries may include a first entry having a first public key associated with a first account, and a first balance ciphertext representing a first balance of the first account; a second entry having a second public key associated with a second account, and a second ciphertext representing a second balance of the second account; and a third entry having a third public key associated with a third account, and a third ciphertext representing a third balance of the third account.” (Para. 0091))
As per Claim 9, Agrawal teaches:
One or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause: detecting, by a subnetwork within a blockchain network controlled by one or more hardware processors, initiation of a bilateral transaction request comprising one of: (a) an inter-bank fund transfer from a first customer of a first bank to a second customer of a second bank with a privacy enabled auditing by a verifier, and (b) privacy enabled inter-bank settlements between the first bank and the second bank, wherein the first bank, the second bank and the verifier participate in the subnetwork via an associated node, and wherein the first bank, the second bank and the verifier individually own a Conditional Homomorphic Proxy Re-encryption (CH-PRE) key pair comprising a public key stored on the blockchain and a secret key; wherein the CH-PRE performs computations on transformed encrypted data that is specified with conditions or predicates to be satisfied during encryption to enhance transaction privacy and auditing, wherein the CH-PRE includes a setup algorithm which takes security parameter as an input and outputs a public parameter set, a key generation algorithm which takes the public parameter set as an input and generates a public and private key pair, an encryption function to encrypt an originator's message using a public key of the originator and predicate, wherein the predicate ensure that all other ciphertexts expect the one that is intended to be sent are not decrypted by a target entity, a re-encryption function which takes a re-encryption key as an input to transform a ciphertext encrypted under originator's public key to decrypted by the target entity under some predicate, a re-encryption transforms the ciphertext encrypted under originator's public key to another ciphertext with the same underlying message that is decrypted by the target entity using its secret key, a decryption function performed on re-encrypted ciphertext using the target entity's private key; (regarding the newly added limitations related to the CH-PRE, the following citations are related to part (a), as the claim requires one of (a) or (b): “A “node” or “network node” may refer to a connection point in a communication network. A network node can be a physical electronic device that is capable of creating, receiving, or transmitting data. In some embodiments, a network node may be a computing device within a record-keeping network (e.g., a blockchain network). A network node may be able to create a data package (e.g., a data payload), transfer a data package, receive a data package, validate a data package, access a central record, and/or perform any other suitable functions. Different types of network nodes may be able to perform different sets of functions within a recording network. In some embodiments, a network node may be associated with and/or operated by a resource provider such as an online service provider, a content provider, a certificate authority, a financial institution (e.g., a bank), a merchant, a transaction processing network, or any other suitable entity.” (Para. 0021, emphasis added); Agrawal describes the verifier as an integral participant, specifically as a node performing cryptographic and validation operations; “Validation node computing device 206 may include a processor and a memory storing computer executable code. In some embodiments, validation node computing device 206 may include one or more cryptoprocessors with specialized arithmetic logic units dedicated for performing cryptographic operations such as encryption, decryption, proof validation, and the like. The computer executable code stored in the memory can implement a platform smart contract 210 (e.g., a Zether smart contract) and maintain a local copy of a blockchain 220 that stores validated transaction data records in the blockchain system.” (Para. 0078); “The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
executing, by the first bank and the second bank via the associated node controlled by the one or more hardware processors, a smart contract, if the bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the smart contract is executed to i) deduct an encrypted first current balance of a first customer by an encrypted transaction amount encrypted at a first encryption instance to obtain an encrypted first updated balance, and ii) add the first encrypted transaction amount to an encrypted second current balance to obtain an encrypted second updated balance for the second customer; (“The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The Transfer function is used to transfer an amount of tokens from one public key to another. The Lock function is used to lock a public key (and its associated account) to an address such as an address of an application smart contract or another account. Once a public key is locked, transfer of tokens associated with the public key and unlocking of the public key cannot be performed unless the operation came from the address that the public key is locked to. The Unlock function is used to unlock a locked public key, and can be only effective if called by the address that the public key is locked to. The Burn function is used to convert tokens (e.g., ZTH) associated with a public key back to a cryptocurrency amount for a cryptocurrency account (e.g., ETH for an Ethereum address)..” (Para. 0080), “Application smart contract 240 can be executed to perform its underlying functions, causing one or more transactions to be performed on the locked public keys. Application smart contract 240 can then send the one or more transactions to platform smart contract 210 to be processed, and unlock the locked public keys.” (Para. 0089))
encrypting, by the first bank and the second bank via the associated node controlled by the one or more hardware processors, the transaction amount, wherein i) the first bank uses a CH-PRE function having a first predicate comprising a tuple (a transaction Identifier (txid), a user ID and a bank ID) and ii) the second bank uses the CH-PRE function having the second predicate comprising the tuple, to obtain an encrypted transaction amount associated with a second encryption instance; (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “The transaction is then posted as a pending transaction to each of the additional public keys and the public keys of the sender and receiver. When the pending transaction is rolled over, the first operand ciphertext (representing a negative of the transaction amount) is added to the encrypted balance of the sender, the second operand ciphertext (representing a positive of the transaction amount) is added to the encrypted balance of the receiver, and the additional operand ciphertexts (encryption of zero by corresponding public key) are added to the respective balances of the additional public keys.” (Para. 0088), “the signature can be generated, for example, by encrypting the smart contract address and a nonce (e.g., counter value or epoch base). In some embodiments, the lock request can be received during a particular epoch, and locking of the account can occur or take effect in a subsequent epoch after the particular epoch. In some embodiments, while an account is locked to the application smart contract, only the application smart contract is permitted to unlock the account.” (Para. 0092))
storing, via the associated node controlled by the one or more hardware processors, i) by the first bank the encrypted first updated balance and the encrypted transaction amount associated with the second encryption instance, and ii) by the second bank the encrypted second updated balance and the encrypted transaction amount associated with the second encryption instance; and (“To conduct a confidential transaction hiding the amount of the transaction, a user may first use the CreatAddresss function to generate a private and public key pair. The CreateFundTx function can then be called to generate a fund transaction request to convert a cryptocurrency amount into tokens for platform smart contract 210. When platform smart contract 210 receives the fund transaction request, platform smart contract 210 may validate the cryptographic proof in the fund transaction request and invoke the Fund function. When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “A transaction can transfer wei between accounts or trigger the execution of smart contract code. Smart contracts can send messages to other smart contracts, mimicking function calls. Every transaction and code execution is replicated on all nodes in the network. Every executed operation has a specified cost expressed in terms of gas units. For example, storing 256 bits of data costs 20,000 units of gas while changing it costs 5,000 units and reading it costs 200 units. The sender pays for all smart contract operations that the transaction calls.” (Para. 0041), “Homomorphic commitments such as Pedersen commitments can be used to make transactions confidential. Though Pedersen commitments are simple and efficient, the opening of these commitments are transferred to the recipient so that the recipient can subsequently use the funds. This randomness can be stored on-chain in some encrypted manner or sent directly to the recipient through a separate channel. In the UTXO model, if the recipient is unable to recover the randomness (an incorrect value was encrypted/sent, nothing sent at all, etc.), then the recipient cannot spend the UTXO later.” (Para. 0047))
performing, by the verifier via the associated node in the subnetwork, the privacy enabled auditing for the inter-bank fund transfer if the detected bilateral transaction request is the inter-bank fund transfer for a transaction amount, wherein the privacy enabled auditing comprising steps of: (“The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
a) challenging, the first bank and the second bank by the verifier on the inter-bank fund transfer using the transaction IDs and a challenge nonce; . . . c) re-encrypting, by the verifier, the second encrypted transaction amount for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted transaction amount for each of the first bank and the second bank; d) retrieving the transaction amount by the verifier from the re-encrypted transaction amount using the predicate and a verifier secret key; e) generating, a verifier tag for each of the first bank and the second bank, by the verifier based on retrieved transaction amount and the challenge nonce; and f) declaring an audit of the transaction amount as successful, by the verifier, if the generated verifier tag of each of the first bank and the second bank match, else declaring the audit as failure. (“A game can be defined between a challenger Chal and an adversary Adv to capture the requirements, where Chal represents the honest users in the network. Both Chal and Adv have access to an oracle Figure US20190164153A1-20190530-P00006 SC who maintains the smart contract SC. Adv has full view of the oracle: it can see all the transactions sent by Chal to SC, how the state of SC changes, etc. Adv is provided with substantial control over SC's state. It can instruct any honest party at any time (via the challenger) to publish a transaction. It can create its own malformed transactions based on the transactions of honest parties, and then push the former into the blockchain ahead of the latter. In particular, it can arbitrarily delay the transactions of honest parties.” (Para. 0130), “At block 306, the application smart contract is executed to perform its underlying functions resulting in one or more transactions to be performed on the locked accounts. For example, the one or more transactions resulting from execution of the application smart contract may cause the first balance of the first account to be decremented by a first amount, and the second balance of the second account to be incremented by a second amount. The transaction data of each transaction may include a cryptographic proof and a signature generated based on a nonce (e.g., counter, or an epoch base derived from hashing a predetermined string and an epoch number of an epoch during which the transaction is initiated). It should be noted that the application smart contract still relies on the user device to generate the underlying transaction data (e.g., cryptographic proof, signature), because only the user device has access to the necessary private key used in generation of the transaction data. In some embodiments, the transaction can be stored as a pending transfer transaction of the first account during a particular epoch, and roll over of the pending transfer transaction to the first account can occur in a subsequent epoch after the particular epoch. The roll over can be performed in response to receiving a subsequent transaction involving the first account.” (Para. 0093), “Additionally, a public key may be able to verify a digital signature created with the corresponding private key. The public key may be distributed throughout a network in order to allow for verification of messages signed using the corresponding private key. Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC). In some embodiments, a key pair may be generated using an asymmetric key pair algorithm.” (Para. 0023); “Once a validation node has received the message, the validation node may distribute the message to the other validation nodes in blockchain network 102. Each of the validation nodes 106A-D may include the transaction represented by the message in a block of transactions and attempt to validate or cryptographically solve the block. The first validation node that solves the block may provide the solution to the other validation nodes for verification, and ledger 104 maintained at each of validation nodes 106A-D can be updated to add the block to ledger 104 to effect the transaction.” (Para. 0030))
Agrawal does not disclose:
“b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate, wherein the re-encryption key is generated using public keys, private keys and the predicate of the originating party and obtain a re-encrypted ciphertext by applying the re-encryption key and the predicate to the ciphertext encrypted under the public keys;” (claim 9).
However, as per Claim 9, Ito in the analogous art of encrypted digital transmissions, teaches: “b) generating by each of the first bank and the second bank, and sharing with the verifier i) a tag computed by bank using the challenge nonce and the second encrypted transaction amount queried from the blockchain, and ii) a re-encryption key using a bank secret key, a bank public key, a verifier public key and the predicate”. (The banks secret key is analogous to an attribute private key (‘sk’) generated for the entity by the key generation apparatus, see “The key generation section 421 of the key generation apparatus 401 performs private key generation in functional encryption, based on inputs of a master private key and a public parameter, stored in the master key information storage section 411, and of the received user attribute. As a result, an attribute private key on which the user attribute (one of the pieces of user attribute information) is set is generated.” (Para. 0119); see also “Referring to the above example, with respect to Ms. Hanako Sato whose user ID is uid2, an attribute private key sk2 is generated based on an input of the user attribute. . .” (Para. 0120); the banks public key is analogous to the systems public parameter (‘pk’) used with that entity’s scheme, see Fig. 15 “611: Public Parameter Storage Section . . ‘pk’ (Fig. 15).”; the verifier public key and predicate is analogous to the verifiers identifier (e.g. User Private Key ID = ‘ukid’) bound as a decryption condition/predicate that targets the re-encryption to the verifier, see “The key generation section 421 of the key generation apparatus 401 generates a unique user secret ID (one of the pieces of key information) in the key information storage section 412. Herein, ukid is assumed to be generated.” (Para. 0122); the verifier is analogous to the re-encryption apparatus 301, receiving and using the re-encryption key to gate access and return transformed outputs, see “The re-encryption apparatus 301 receives ciphertext on which a decryption condition is set, then re-encrypts the received ciphertext for a specific user, and sends it to a user terminal 601. The re-encryption apparatus 301 includes a public parameter storage section 311, a re-encryption key storage section 312, a re-encryption section 321 and a communication section 331.” (Para. 0066); here, bank A (‘uid_1’) and bank B (‘uid_2’) can correspond to two source entities in the system for whom keys are issued and re-encryption keys are stored per user ID, see the multi-user re-encryption-key table of Fig. 28 (“312: Re-encryption key storage section. . .” (Fig. 28); the step of generating the re-encryption key is taught by “(S206) The key generation section 421 of the key generation apparatus 401 performs re-encryption key generation in functional encryption, based on inputs of the public parameter, the attribute private key and a decryption condition “User private key ID=ukidi” (the other piece of key information). As a result, a re-encryption key is” generated. . . the re-encryption key generated herein is a key to re-encrypt the ciphertext that can be decrypted with the received attribute private key, into the ciphertext that can be decrypted with the user private key on which the received user private key ID is set. (Para. 0124 and 0126); the step of sharing the re-encryption key is taught by “The communication section 431 of the key generation apparatus 401 sends the public parameter, the user private key and the re-encryption key to the attribute management apparatus 501. With reference to the above example, uk2 and rk2 are sent as the user private key and the re-encryption key.” (Para. 0131-0132); note that the same ‘share-to-verifier’ flow is taught again during updates, as “The communication section 431 of the key generation apparatus 401 sends the newly generated re-encryption key to the attribute management apparatus 501. With reference to the above example, rk202 is sent as the re-encryption key.” (Para. 0239 and 0240); the step of generating and sharing with the verifier is taught at least in Para. 0163, where the datastore is analogous to a blockchain query and the ciphertext is queried/acquired from a remote ciphertext store by data ID and then sent onward for processing, “The communication section 631 of the user terminal 601 sends the data ID of data to be acquired to the ciphertext storage apparatus 201. The ciphertext storage apparatus 201, upon receipt of the data ID, acquires the ciphertext related to the data ID from the ciphertext storage section 211, and sends the ciphertext to the user terminal 601.” (Para. 0163); the re-encryption apparatus transforms the encrypted amounts conditioned on a predicate (e.g. user private key ID = ukid_2) and returns it, “The re-encryption section 321 of the re-encryption apparatus 301 performs re-encryption in functional encryption based on inputs of the public parameter stored in the public parameter storage section 311, the re-encryption key acquired from the re-encryption key storage section 312 and the received ciphertext. As a result, the ciphertext (re-ciphertext) that can be decrypted with the user private key is generated. With reference to the above example, the ciphertext c1 is re-encrypted with the re-encryption key rk2 to generate ciphertext C1 with the decryption condition “User private key ID=ukid2” (Para. 0170-0171); and the verifier apparatus first acquires the re-encryption key to do this conversion (confirming the role of the verifier in the flow), “The re-encryption apparatus 301, upon receipt of the user ID and the ciphertext, acquires the re-encryption key related to the user ID from the re-encryption key storage section 312.” (Para. 0168).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Agrawal with the technique of Ma to include the functionality of secure delegation of ciphertext transformation between parties. Therefore, the incentives of providing enhanced data confidentiality and privacy-preserving transaction auditing provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 10, Agrawal teaches:
The one or more non-transitory machine-readable information storage mediums of claim 9, performing steps, if the bilateral transaction request is privacy enabled inter-bank settlements between the first bank and the second bank, the steps comprising: executing a smart contract querying encrypted debits and credits of the first bank and the second bank to obtain encrypted sum of credits and sum of debits for each of the first bank and the second bank in a settlement cycle, encrypted under a first public key of the first bank and a second public key of the second bank from the CH-PRE key pair; storing the encrypted sum of credits and sum of debits for each of the first bank and the second bank on the blockchain; challenging the first bank and the second bank by the verifier for the privacy enabled inter-bank settlement using a settlement challenge nonce; generating by each of the first bank and the second bank and sharing with the verifier i) a settlement bank tag by using the settlement challenge nonce and a decryption of encrypted sum of credits and sum of debits using the bank secret key, and ii) a re-encryption key using the bank secret key, the bank public key, verifier public key and the predicate; re-encrypting, by the verifier, a decryption of encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the re-encryption key shared by each of the first bank and the second bank to obtain re-encrypted sum of credits and sum of debits for each of the first bank and the second bank; retrieving sum of debits and sum of credits for each of the first bank and the second bank by the verifier from the re-encrypted sum of credits and sum of debits for each of the first bank and the second bank using the predicate and the verifier secret key; generating a settlement verifier tag for each of the first bank and the second bank, by the verifier from the retrieved sum of debits and sum of credits for each of the first bank and the second bank, and the settlement challenge nonce; and declaring the inter-bank settlement complete, by the verifier, if the generated settlement verifier tag for sum of debits of the first bank and the sum of credits of the second bank match, and settlement verifier tag for sum of credits of the first bank and the sum of debits of the second bank match, else declaring the inter-bank settlement as failure. (“The user may then invoke the CreateTransferTx to generate a transfer transaction request to transfer an amount of tokens from the user's public key to another user's public key. The transaction data of the transfer transaction request may include the public keys of the sender and receiver, a first operand ciphertext encrypting the negative of the transfer amount using the sender's public key, and a second operand ciphertext encrypting the transfer amount using the receiver's public key. When platform smart contract 210 receives the transfer transaction request, platform smart contract 210 may validate the cryptographic proof in the transfer transaction request and invoke the Transfer function. The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087), “The case of two consistent transfer instructions is left. A transfer transaction consists of an anonymity set y, a list of commitments C, a blinding value D, a nonce u, and πtransfer. Two consistent transactions could have two different senders, so the nonce values could be different. However, gepoch x (for any x) is indistinguishable from random under the DDH assumption since both y and gepoch are random (when Figure US20190164153A1-20190530-P00041 is modeled as a random oracle). Further, ciphertexts (Ci, D) for honest i are indistinguishable from the encryption of random messages. Now, let the receivers for the two instructions be j and k. If neither of them are under the control of Adv, then all the ciphertexts Adv can decrypt are just encryptions of 0. Otherwise, both j and k must be corrupt. In this case, Adv can decrypt (Cj, D) and (Ck, D) too, but then they must decrypt to the same amount.” (Para. 0285)
As per Claim 11, Agrawal teaches:
The one or more non-transitory machine-readable information storage mediums of claim 9, wherein the encrypted first current balance and the encrypted transaction amount at the first encryption instance is obtained by encrypting a first current balance of the first customer using the bank public key from the CH-PRE key pair and a dummy predicate with unity value; and wherein the encrypted second current balance and the encrypted transaction amount at first encryption instance is obtained by encrypting a second current balance of the second customer using the bank public key of the second bank from the CH-PRE key pair and the dummy predicate with unity value. (“When the Fund function is invoked for the first time for a public key, a new entry is created in platform smart contract state 230, and the public key and an encrypted balance representing the amount of tokens being funded from the cryptocurrency account are stored in the entry. The encrypted balance can be derived from encrypting the balance using the public key. If the public key already exists in platform smart contract state 230 already when the Fund function is invoked, the funding amount is encrypted using the public key and added to the encrypted balance using homomorphic encryption.” (Para. 0086), “Having conducted one or more transactions in platform smart contract 210, a user can convert the user's account balance from tokens back to cryptocurrency by invoking the CreateBurnTx function to generate a burn transaction. When platform smart contract 210 receives the burn transaction request, platform smart contract 210 can validate the burn transaction request, and call the Burn function. The Burn function may validate the balance, credit the cryptocurrency account of the user with the balance in the cryptocurrency, and update platform smart contract state 230 by adding a ciphertext representing the negative of the balance to the current encrypted balance of the corresponding public key.” (Para. 0090)
As per Claim 12, Agrawal teaches:
The one or more non-transitory machine-readable information storage mediums of claim 9, wherein the tuple enables privacy enabled auditing by the verifier, and wherein transaction ID is used to validate a challenged transaction ID sent by the verifier, the user ID is used to retrieve all transactions pertaining to a challenged customer and bank ID is used to retrieve all transactions performed by a bank. (“The transaction data may include a set of public keys of the accounts involved in the transaction, ciphertexts representing amounts if a transfer is involved, a signature generated by signing nonce 290 with private key 280, and a proof that is validated by validation node computing device 206 to effect the transaction. In some embodiments, the nonce can be a counter that is incremented for each transaction associated with the public key, or an epoch base that is unique for each epoch (e.g., can be derived from hashing a predetermined string and an epoch number of an epoch during which the corresponding transaction is initiated). The ReadBalance function is used to obtain the balance associated with the user's public key from platform smart contract state 230. Additional details of the platform smart contract algorithms and user algorithms are further described in sections 5 and 6 below.” (Para. 0085), “The Transfer function may then roll over any pending transactions on the public keys of the sender and receiver from prior epochs, verify that the public keys of sender and receiver are not locked (or are locked to the sender's address), verify the signature on the transfer transaction request, and post the transfer transaction as a pending transaction on the public keys of the sender and receiver. At a later epoch when another transaction is initiated on the public keys, the pending transaction is rolled over by adding the first operand ciphertext (representing a negative of the transaction amount) to the encrypted balance of the sender and adding the second operand ciphertext (representing a positive of the transaction amount) to the encrypted balance of the receiver. Because the transaction amount and updated balances are encrypted, a public view of platform smart contract state 230 would not be able to determine the transaction amount, thus creating confidentiality for the transaction.” (Para. 0087)
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20190034923A1 (Greco), discussing “A system, device and method of confidential secure custodial transfers of asset between entities utilizing a zero knowledge protocol, that can optionally leverage distributed ledger-based technologies such as blockchain and transaction agents (e.g. smart contracts). In particular, the transaction agents (or technology such as chain-code or database programs) securely record each of the transactions on the ledger utilizing obfuscated or proxy data state such that information about the transactions cannot be gleaned from the ledger. In particular, the transaction agents are able to enforce business rules of the system by requesting zero-knowledge proofs from participants to the transaction (e.g. sender and recipient) in place of actual data for the transaction. The zero-knowledge proofs are able to be designed to prevent an observer of the distributed ledger from determining any information of the transaction that is taking place. Yet, the transaction agent can use the proofs to verify access rights, correctness of the transaction and compliance of the operation according to the defined business rules and system state. Such proofs are also used to update the system state without disclosing on the distributed ledger information about the participants to the transactions, the identifier that is subject of the transaction and logical links across participants, identifiers and transactions. Thus, the system eliminates the possibility of mining the data from the ledger to extract undesired data correlations and it protects against leak of business intelligence on the distributed ledger.” (Para. 0004)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697