DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-10, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6-10, 24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The linking relationship of the dependent claims 6-20, 24 is unclear. The limitation as recited is “he method of claim 1 any preceding claim” which seems to which is an improper multiple dependent claim as recited. The marking of the amended claim are also incomplete when compared with the preliminary amendment filed on 3/2/24.
Allowable Subject Matter
Claims 17, 20, 22 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
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.
Claim(s) 1-7, 10, 15-17, 28-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karame et al., US 20200125269 A1 (hereafter referred to as Karame) in view of Aschauer et al., EP 3340527 A1 (hereafter referred to as Aschauer).
Claim 28, Karame teaches computer equipment, comprising:
memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when run on the processing apparatus, the processing apparatus performs a method comprising:
obtaining, from a blockchain, a first blockchain transaction, the first blockchain transaction (p. 17, “A blockchain network is typically composed nodes which are computer devices in the blockchain network that can assume the role of either regular clients or miners. Clients send and receive transactions, and contribute to the blockchain by relaying to their neighbors every transaction and block that they receive.”) comprising one or more respective scripts comprising respective target data to be redacted (p. 43, “This is achieved by the miner storing the hashes of the headers of the current set of active blocks and hashes of the code of the current set of active smart contracts in respective Merkle trees and adding the Merkle trees in the body of the new genesis block…”);
for at least one of the one or more respective scripts, constructing a respective Merkle tree based on the at least one of the one or more respective scripts (p. 10, “The method includes creating an active blocks commitments Merkle tree from hashes of active blocks and creating an active smart contracts commitments Merkle tree from hashes of active smart contracts. The Merkle trees are created after an amount of blocks created in the blockchain has reached a threshold set by a pruning threshold parameter stored in the blockchain network.”), wherein the respective target data is divided across one or more of the respective leaves of the respective Merkle tree (p. 35, “Merkle trees are binary trees of hashes. The tree is built by pairing and hashing its leaves, and then hashing the results until a single hash remains: the tree's root. If there are an odd number of leaves, then the leaf without an assigned companion is hashed with a copy of itself. The root value is what will be added to the blocks' headers.”), and
generating a redacted version of the first blockchain transaction by replacing the at least one respective script of the one or more respective scripts with a respective Merkle root of the respective Merkle tree (p. 53, “this new block is created as a new genesis block and differs from an ordinary block as the node 22 in that the node 22 adds the root hashes of the Merkle tree to its header and also preferably stores the created Merkle trees together with the ordinary Merkle tree for transactions in its body. After creating the new genesis block, the node 22 broadcasts it into the blockchain network in a fourth step S4 so that consensus can be reached on it in a fifth step S5.”).
Karame teaches smart contracts which comprise scripts for smart contract script redaction is a configuration. Aschauer, teaches that smart contracts redact the scripts of transactions (p. 72, “With the method according to the invention, a provided clear text block transaction information (e.g. the first clear text program code/smart contract or a first transaction data record comprising the first clear text program code/smart contract) can be transformed into a cryptographically protected obfuscated and/or encrypted form (obfuscated and/or encrypted second program code/smart contract, second transaction data record)…” Smart contract is a special locking/unlocking transaction determining whether the transaction conditions are met. The locking script is interpreted as partial locking script.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Karame by incorporating Aschauer’s redactions enabling further protection for transactions and the scripts.
Claim 1, a computer-implemented method of redacting data of a blockchain transaction comprising steps similar to claim 28 above. Claim 1 is rejected on a similar rationale.
Claim 29, a computer program embodied on non-transitory computer- readable storage media and configured so as, when run on one or more processors, the one or more processors Claim 16 perform a method comprising steps similar to claim 1 above. Claim 29 is rejected on a similar rationale.
Claim 2, Karame-Aschauer teaches the method of claim 1, wherein each respective script of one or more respective scripts comprises one or more functions (Karame, p. 43, “… the code of the current set of active smart contracts “) , wherein said constructing of the respective Merkle tree comprises grouping one or more respective sequences of consecutive functions as respective leaves of the Merkle tree (Karame, p. 43, “hashes of the code of the current set of active smart contracts in respective Merkle trees”).
Claim 3, Karame-Aschauer teaches the method of claim 2, wherein each respective script of the one or more respective scripts comprises a respective data function configured to indicate the respective target data when executed , and wherein said constructing of the respective Merkle tree comprises including the respective data function as part of a respective leaf of the respective Merkle tree.
Claim 4, Karame-Aschauer teaches the method of claim 3, wherein each respective script of the one or more respective scripts comprises a respective data length of the respective target data (Karame, p. 40, “a new network-wide parameter is introduced and referred to herein as “a pruning threshold” with a double meaning: 1) The amount of blocks to keep after pruning the local copy of the blockchain. 2) The minimum amount of blocks between two consecutive pruning events.”) , and wherein said constructing of the respective Merkle tree is based on the respective data length (Karame, p. 40, “minimum blocks” to prune).
Claim 5, Karame-Aschauer teaches the method of claim 4, wherein said constructing of the respective Merkle tree comprises including the respective data length as part of the same respective leaf of the respective Merkle tree as the respective data function (Karame, p. 42, “A separate counter keeps track of the number of blocks created from the previous pruning event. Once it becomes greater or equal then the pruning threshold, a new pruning event starts. The counter is reset after each pruning cycle.”).
Claim 6, Karame-Aschauer teaches the method of claim 1 any preceding claim, wherein the respective target data is divided across a plurality of the respective leaves of the respective Merkle tree (Karame, p. 36, “Merkle tree 10 comprising five blocks 12 indicated as Blk1, Blk2, Blk3, Blk4 and Blk5 each containing transaction data would be built. The tree's leaves 14 are hashes of the blocks 12 indicated in FIG. 12 by the letter H followed by the blocks which are hashed (e.g., H1 is the hash of block 1, H12 is the combination of the hashes of blocks 1 and 2, H1234 is the combination of the hashes of blocks 1-4, H55 is the combination of the hash of block 5 with itself, and so on). The hashes of the leaves 14 are then paired and hashed toward the root 16 of the Merkle tree 10 until the root 16 remains.”).
Claim 7, Karame-Aschauer teaches the method of claim 1 any preceding claim, wherein the first blockchain transaction comprises a plurality of respective scripts comprising respective target data (Karame, p. 20, “The pruning process starts after a miner successfully generates the following: (i) an active blocks commitment Merkle tree, (ii) an active smart contracts Merkle tree, and (iii) a new block as usual. This new block is a regular block with the addition of the active blocks commitment Merkle tree and the active smart contracts commitment Merkle tree.”), and wherein the method comprises:
for each respective script of the plurality of respective scripts, constructing a respective Merkle tree based on the respective script, wherein the respective target data is divided across one or more of the respective leaves of the respective Merkle tree (Karame, p. 20, “The pruning process starts after a miner successfully generates the following: (i) an active blocks commitment Merkle tree, (ii) an active smart contracts Merkle tree, and (iii) a new block as usual. This new block is a regular block with the addition of the active blocks commitment Merkle tree and the active smart contracts commitment Merkle tree.”);
generating the redacted version of the first blockchain transaction by replacing each respective script with a respective Merkle root of the respective Merkle tree (Karame, p. 5, “Additionally, the header of the new block includes the root hashes of each of those two Merkle trees.” In the case associated with paragraph 20 multiple smart contracts.).
Claim 10, Karame-Aschauer teaches the method of claim 1 any preceding claim, comprising storing the redacted version of the first blockchain transaction in memory (Karame, p. 18, “Regardless of the role covered, each network node has to store a local copy of the entire blockchain in order to validate new transactions and blocks, and detect double-spending. The redundancy also helps against denial of service attacks.” And p. 43, “These smart contracts are stored in the bodies of invoked transactions.”).
Claim 15, Karame-Aschauer teaches the method of claim 1, wherein the method is performed by a transaction validator (Karame, p. 37, “Specifically, to validate a transaction, only the Merkle root 16 and a list of the intermediate hashes are needed. For example, to validate a transaction in the block 12 indicated as Blk3 of FIG. 2, a node only needs a copy of the H4, H34, and H1234 hashes in addition to the Merkle root 16.”).
Claim 16, Karame-Aschauer teaches the method of claim 15, comprising:
extracting a signature from an input of the first blockchain transaction (Karame, p. 43, “The body of the new genesis block contains the active blocks commitment Merkle tree and the active smart contracts commitment Merkle tree. This is achieved by the miner storing the hashes of the headers of the current set of active blocks.” Using hashes as a signature.); and
verifying the signature for a message, wherein one or more parts of the message are based on the redacted version of the first blockchain transaction Karame, (p. 45, “The network “accepts” the new genesis block by the nodes reaching consensus on the new genesis block, or in other words having the same values for the hashes of the Merkle trees. In this case, the other miners will build on top of the new genesis block, that is, they will append their newly generated blocks after it.”.
Claim 24, Karame-Aschauer teachs the method of claim 1, wherein the redacted transaction comprises a plurality of fields (Karame, p. 17, “A blockchain network is typically composed nodes which are computer devices in the blockchain network that can assume the role of either regular clients or miners. Clients send and receive transactions, and contribute to the blockchain by relaying to their neighbors every transaction and block that they receive.”), and wherein the method comprises:
generating a transaction Merkle tree, wherein respective a plurality of respective leaves of the transaction Merkle tree are formed from one or more fields of the redacted transaction (Karame, p. 20, “The pruning process starts after a miner successfully generates the following: (i) an active blocks commitment Merkle tree, (ii) an active smart contracts Merkle tree, and (iii) a new block as usual.”); and
generating a secondary transaction identifier of the redacted transaction, wherein the secondary transaction identifier comprises a Merkle root of the transaction Merkle tree (Karame, p. 34, “FIG. 1(a) shows a block header before introducing the Merkle Tree commitments. FIG. 1(b) shows a block header after introducing the Merkle tree commitments. Blk commit is the root hash of the active blocks commitment Merkle tree …”).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karame and Aschauer as applied to claims 1 above, and further in view of Lee et al., US 20200265530A1 (hereafter referred to as Lee).
Claim 9, Karame-Aschauer teaches the method of claim 1, as cited above. Does not specifically teach comprising transmitting the redacted version of the blockchain transaction to an entity in response to a request for the first blockchain transaction. However, in the same field of endeavor, Lee teaches comprising transmitting the redacted version of the blockchain transaction to an entity in response to a request for the first blockchain transaction (p. 132, “The distributed-ledger system may send the cryptographic document obfuscation value, the time value, and/or other information (such as a block number, for example) to the registry system and/or the electronic device.” The document obfuscation value is sent to the registry and a link the registry allows retrieval. And p. 135, “For example, a linking component may be configured to associate one record with one or more other records in the trade secret registry.” “the link may correspond to a selectable portion of the user interface that, when selected, may cause the linked record and/or a portion thereof to be displayed.” The document obfuscation value is sent to the registry and a link in the registry allows retrieval.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Karame-Aschauer to incorporate Lee providing the redacted version upon request for the Karame-Aschauer blockchain to facilitate access to the protected information of the blockchain and thereby utilizing blockchain stored transactions.
Claim(s) 8 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karame and Aschauer as applied to claim 1 above, and further in view of Wu et al., US 20190188711 A1 (hereafter referred to as Wu).
Claim 8, Karame- Aschauer teaches the method of claim 1, comprising steps as cited above. Karame-Aschauer does not specifically teach generating a primary transaction identifier of the redacted version of the first blockchain transaction by hashing the redacted version of the blockchain transaction. However, in the same field of endeavor, Wu teaches generating a primary transaction identifier of the redacted version of the first blockchain transaction by hashing the redacted version of the blockchain transaction (p. 49, “A transaction in the distributed ledger may include a list of inputs and a list of outputs. A transaction hash may be constructed by hashing all of the data within a transaction. A transaction hash may be used to reference a transaction (i.e. as a transaction identifier or tx id).”). It would have been obvious to one of ordinary skill in the art to modify Karame-Aschauer to incorporate transaction identifier from Wu for the transaction identifier in Karame-Aschauer to provide better access to the blockchain transaction by organizing a key for locating the transaction and thereby improving efficiency and utility.
Claim 19, Karame-Aschauer-Wu teaches the method of claim 8, wherein the method comprises:
wherein at least one of the respective scripts is a first locking script of a first output of the first blockchain transaction (Aschauer, p. 72, “With the method according to the invention, a provided clear text block transaction information (e.g. the first clear text program code/smart contract or a first transaction data record comprising the first clear text program code/smart contract) can be transformed into a cryptographically protected obfuscated and/or encrypted form (obfuscated and/or encrypted second program code/smart contract, second transaction data record)…” Smart contract is a special locking/unlocking transaction determining whether the transaction conditions are met.); and
storing, in a database, the respective Merkle root mapped to a modified primary transaction and a respective index of the first output (Wu, p. 64, “Components of a cross-ledger transaction 205 that are written into the target distributed ledger 200T are depicted FIG. 2 in accordance with an embodiment of the invention.” And p. 68, “Note also that the transaction hash (which may be referred to as a transaction identifier or tx id) is a hash value derived from the referenced transaction 213 by applying a hash function to the contents of the referenced transaction. The transaction hash may be hashed with the Merkle branch hashes to form a Merkle root. This Merkle root may be matched against the Merkle root of the block within the source distributed ledger 200S to prove the transaction 213 exists in the source distributed ledger 200S.”).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karame and Aschauer and Wu as applied to claim 8 above, and further in view of Mullins et al.., US 11295359 B1 (hereafter referred to as Mullins).
Claim 21, Karame-Aschauer-Wu teaches the method of claim 8, wherein at least one of the respective scripts is a first locking script of a first output of the first blockchain transaction, and wherein the method comprises:
storing, in a database, a partial locking script mapped to the modified primary transaction identifier and a respective index of the first output (Wu, p. 49, “A transaction in the distributed ledger may include a list of inputs and a list of outputs. A transaction hash may be constructed by hashing all of the data within a transaction. A transaction hash may be used to reference a transaction (i.e. as a transaction identifier or tx id).).
Karame-Aschauer-Wu does not specifically teach wherein the partial locking script comprises at least some of the first locking script but not the target data. However, Mullins teaches the partial locking script comprises at least some of the first locking script but not the target data (Step 530, “The locking script may be included in the previous transaction referenced by the transaction record 502a and may specify one or more conditions that must be met for establishing control or ownership over the output of the referenced previous transaction. The unlocking script may be constructed by the node 501a based at least in part on the locking script, a public key associated with the node 501a, and a digital signature created based on a private key associated with the node 501a. Each node 501b may validate the transaction record 502a by executing the unlocking script and the locking script in sequence, which may return a Boolean value.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Karame-Aschauer-Wu to incorporate first locking script without target data from Mullins to improve effectiveness by separate the conditions determining access from the data related to the protect data and thereby improve security.
Allowable Subject Matter
Claims 17, 20 and 22 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Praus et al., US 10608824 B1, Merle signature scheme tree formed by signing keys.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICE L WINDER whose telephone number is (571)272-3935. The examiner can normally be reached M-F 10am-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/Patrice L Winder/Primary Examiner, Art Unit 2453
Prosecution Insights