DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 12/30/2024.
In the instant Amendment: Claims 1, 4, 16-17 have been amended and claim 1, 16 and 17 are independent claims. Claims 1-17 have been examined and are pending. This Action is made FINAL.
Examiner’s Notes
To promote compact prosecution, the Examiner contacted applicant’s representative, Rowan Smith (Reg. No.: 64198) and proposed an examiner’s amendment. However, the Examiner and applicant’s representative were unable to reach an agreement.
Response to Arguments
Rejection under 35 U.S.C. 101 is withdrawn as the claims have been amended and applicant’s arguments are found persuasive.
Applicants’ arguments with respect to amended claims 1 has been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
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 discloses as set forth in section 102 of this title, 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-7, 9-12, 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Jing (“Jing,” US 20200363994, published Nov. 19, 2020), Nordstrom et al. (“Nordstrom,” US 20200175138, published June 4, 2020) and Baird, III (“Baird, III,” US 20200372015, published Nov. 26, 2020).
Regarding claim 1, Jing discloses A computer-implemented method comprising:
obtaining information describing a property (Jing FIG. 1, [0020]-[0021]. At block S110, a file to be stored is grouped to form a plurality of data packets. The file to be store may be a text, a picture, a video, an audio or other type of storable file (such as a compressed file in a zip format).);
dividing the information into at least two data items describing the property at [at least two different levels of precision] (Jing [0029]. For example, one file to be stored is divided into a plurality of data packets, and are distributed after formed into data fragments.);
obtaining a set of data items for generating a Merkle tree, the set of data items including the at least two data items (Jing [0043]. As illustrated in FIG. 2 b, four data packets (DATA BLOCK) are included, the hash value of each data packet is calculated respectively, leaf nodes (Hash-LEAF) of the original Merkle tree are formed in an order from left to right, and each two leaf nodes are combined to calculate a hash value as an upper-layer branch (Hash-BRANCH) until a root node (Hash-ROOT) of the original Merkle tree is calculated. The original Merkle tree not only records the hash value of each data packet, but also records the order of the data packets in a tree structure. In the original Merkle tree, taking a second data packet (DATA BLOCK2) as an example, three data fragments (DATA SHARD 1, DATA SHARD2 and DATA SHARD3) at which the second data packet stored are also recorded.);
applying a cryptographic hash function, separately, to the at least two data items to generate respective leaf nodes of a Merkle tree (Jing [0043]. As illustrated in FIG. 2 b, four data packets (DATA BLOCK) are included, the hash value of each data packet is calculated respectively, leaf nodes (Hash-LEAF) of the original Merkle tree are formed in an order from left to right, and each two leaf nodes are combined to calculate a hash value as an upper-layer branch (Hash-BRANCH) until a root node (Hash-ROOT) of the original Merkle tree is calculated. The original Merkle tree not only records the hash value of each data packet, but also records the order of the data packets in a tree structure. In the original Merkle tree, taking a second data packet (DATA BLOCK2) as an example, three data fragments (DATA SHARD 1, DATA SHARD2 and DATA SHARD3) at which the second data packet stored are also recorded.);
encoding the at least two data items into a Merkle root of a Merkle tree using the respective leaf nodes of the Merkle tree (Jing [0043]. As illustrated in FIG. 2 b, four data packets (DATA BLOCK) are included, the hash value of each data packet is calculated respectively, leaf nodes (Hash-LEAF) of the original Merkle tree are formed in an order from left to right, and each two leaf nodes are combined to calculate a hash value as an upper-layer branch (Hash-BRANCH) until a root node (Hash-ROOT) of the original Merkle tree is calculated. The original Merkle tree not only records the hash value of each data packet, but also records the order of the data packets in a tree structure. In the original Merkle tree, taking a second data packet (DATA BLOCK2) as an example, three data fragments (DATA SHARD 1, DATA SHARD2 and DATA SHARD3) at which the second data packet stored are also recorded.); and
storing at least one of: the Merkle tree; instructions for generating the Merkle tree from the set of data items (Jing [0047], [0050]-[0051]. At block S250, a hash value of a data packet included in the data fragment is recorded using a Merkle tree as a fragment Merkle tree. At block S260, a corresponding relationship between each fragment Merkle tree and a storage node located by each data fragment is recorded. Correspondingly, after the fragment Merkle tree corresponding to each data fragment is obtained, the corresponding relationship between each fragment Merkle tree and the storage node located by each data fragment may be recorded. Each data fragment corresponds to one fragment Merkle tree.).
Jing does not explicitly disclose: dividing the information into at least two data items describing the property at at least two different levels of precision.
However, in an analogous art, Nordstrom discloses a method, comprising the step of: dividing the information into at least two data items describing the property at at least two different levels of precision (Nordstrom [0082], [0113]. At step 302, a computing device having at least one memory including computer program instructions and one or more processors splits, a part of or the entire digital file into a plurality of tokens…The tokens may have all the same size or different size. Input files are split into multiple equal-sized blocks so that recovery files do not need to be the size of the largest input file. In present invention implementation could be equal-sized or different size block tokens.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Nordstrom and Jing to include the step of: dividing the information into at least two data items describing the property at at least two different levels of precision. One would have been motivated to provide users with a means for splitting a file into segments of same or different sizes for blockchain based data processing, storage, and retrieval. (See Nordstrom [0113].)
Jing and Nordstrom do not explicitly disclose:
and generating a digital signature by applying a cryptographic digital signature algorithm to the Merkle root of the Merkle tree together with a cryptographic private key of a first party.
However, in an analogous art, Baird III discloses a method, comprising the step of: generating a digital signature by applying a cryptographic digital signature algorithm to the Merkle root of the Merkle tree together with a cryptographic private key of a first party (Baird, III [0071], [0086]. Moreover, in some implementations, the timestamp, current address book, address book history, ledger identifier and/or any other portion of the state proof (or hash value of any portion of the state proof) can be signed by a predetermined number of distributed database devices implementing the distributed database (either separate or a combined aggregate signature). At 704, the root hash of the Merkle tree can be signed. Specifically, a compute device can digitally sign the hash of the root node of the Merkle tree with a private key of that compute device [that belongs to a user or a party to a transaction. See [0023]].).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Baird III, Wang and Jing to include the step of: signing the root value using a private key of a first party; and signing an address of a first party using the private key of the first party. One would have been motivated to provide users with a means for generating digital signatures associated with a blockchain Merkle tree. (See Baird, III [0086].)
Regarding claim 2, Jing, Nordstrom and Baird, III disclose the method of claim 1. Jing further discloses wherein obtaining the information describing the property comprises: based on a first value describing the property, determining a functionally equivalent value describing the property (Jing [0043]. As illustrated in FIG. 2 b, four data packets (DATA BLOCK) are included, the hash value of each data packet is calculated respectively, leaf nodes (Hash-LEAF) of the original Merkle tree are formed in an order from left to right, and each two leaf nodes are combined to calculate a hash value as an upper-layer branch (Hash-BRANCH) until a root node (Hash-ROOT) of the original Merkle tree is calculated. The original Merkle tree not only records the hash value of each data packet, but also records the order of the data packets in a tree structure. In the original Merkle tree, taking a second data packet (DATA BLOCK2) as an example, three data fragments (DATA SHARD 1, DATA SHARD2 and DATA SHARD3) at which the second data packet stored are also recorded.).
Regarding claim 4, Jing, Nordstrom and Baird, III disclose the method of claim 1.
Baird, III further discloses signing an address of a first party using the private key of the first party (Baird, III [0071], [0086]. Moreover, in some implementations, the timestamp, current address book, address book history, ledger identifier and/or any other portion of the state proof (or hash value of any portion of the state proof) can be signed by a predetermined number of distributed database devices implementing the distributed database (either separate or a combined aggregate signature). At 704, the root hash of the Merkle tree can be signed. Specifically, a compute device can digitally sign the hash of the root node of the Merkle tree with a private key of that compute device.).
The motivation is the same as that of claim 1 above.
Regarding claim 5, Jing, Wang and Baird, III disclose the method of claim 4. Baird, III further discloses wherein the method comprises: creating a transaction template, the transaction template comprising an output comprising the root value, the address of the first party and a signature of the first party(Baird, III [0071], [0086]. Moreover, in some implementations, the timestamp, current address book, address book history, ledger identifier and/or any other portion of the state proof (or hash value of any portion of the state proof) can be signed by a predetermined number of distributed database devices implementing the distributed database (either separate or a combined aggregate signature). At 704, the root hash of the Merkle tree can be signed. Specifically, a compute device can digitally sign the hash of the root node of the Merkle tree with a private key of that compute device.).
The motivation is the same as that of claim 4 above.
Regarding claim 6, Jing, Wang and Baird, III disclose the method of claim 5. Baird, III further discloses wherein the method comprises: sending, to a second party, the transaction template, the set of data items for generating the Merkle tree and instructions for generating the Merkle tree (Baird, III [0085]. The method 700 includes, at 702, defining a state of a distributed database as a Merkle tree. The state can be based on transactions and/or events exchanged between compute devices and/or distributed database devices implementing the distributed database and executed in a consensus order. Moreover, the state can be the result of a consensus algorithm and/or protocol implemented by the distributed database.).
The motivation is the same as that of claim 5 above.
Regarding claim 7, Jing, Wang and Baird, III disclose the method of claim 6. Baird, III further discloses
wherein the method comprises: checking, by the second party, a validity of the signature (Baird, III [0076]. Verifying that the Merkle tree root, the state proof, the data in the state proof, and/or the timestamp of the state proof is/are signed by a threshold number (based on total number or an amount of stake) of distributed database devices from the current address book of the distributed database.);
constructing, by the second party, a second Merkle tree having a second root value using the data for determining the Merkle tree and the instructions for generating the Merkle tree; checking that the second root value matches the root value signed by the first party; if the second root value matches the root value signed by the first party, adding an output locked to the second party to an unlocking script of the transaction template to complete the transaction (Baird, III, [0060]-[0061], [0089]. Specifically, based on the nodes in the Merkle path of Data W (i.e., nodes HX and HYZ) and the root node HWXYZ, a user can verify that Data W is in the Merkle tree 600. For example, HW can be calculated based on a hash of Data W; HWX can be calculated based on a hash of HW (previously calculated) and HX (provided as part of the Merkle path); and HWXYZ can be calculated based on a hash of HWX (previously calculated) and HYZ (provided as part of the Merkle path). Once HWXYZ is calculated, this can be compared to a previously stored and/or provided value of the root node. If the calculated root node corresponds to the previously stored and/or provided value of the root node, Data X is verified as being contained within the Merkle tree having that root node HWXYZ. The set of distributed database devices 310, 320, 330, 340 implementing a distributed database (or a subset thereof) can digitally sign the root node of a current Merkle tree (i.e., a Merkle tree containing the current state of the distributed database), along with a consensus timestamp for a date and time at which the data is valid. Such a transaction can be provided as part of an event of the distributed database. The event can be provided to the other compute devices and/or members of the distributed database such that a consensus order can be defined for the event and/or the transaction. The second set of compute devices can be the set of compute devices and/or members of the distributed database after the transaction is executed in its consensus order.),
sending, by the second party, the transaction to the first party or to a blockchain (Baird, III, [0089]. Such a transaction can be provided as part of an event of the distributed database. The event can be provided to the other compute devices and/or members of the distributed database such that a consensus order can be defined for the event and/or the transaction. The second set of compute devices can be the set of compute devices and/or members of the distributed database after the transaction is executed in its consensus order.).
The motivation is the same as that of claim 6 above.
Regarding claim 9, Jing, Wang and Baird, III disclose the method of claim 7. Baird, III further discloses wherein the method comprises: sending, by the first party, the transaction to the blockchain (Baird, III [0089]. The event can be provided to the other compute devices and/or members of the distributed database such that a consensus order can be defined for the event and/or the transaction. The second set of compute devices can be the set of compute devices and/or members of the distributed database after the transaction is executed in its consensus order.).
The motivation is the same as that of claim 7 above.
Regarding claim 10, Jing, Wang and Baird, III disclose the method of claim 7. Baird, III further discloses wherein the method comprises sending by at least one of the first party and the second party, to a the blockchain: the root value of the Merkle tree; and the signature of the first party (Baird, III, [0085]-[0086]. The method 700 includes, at 702, defining a state of a distributed database as a Merkle tree. The state can be based on transactions and/or events exchanged between compute devices and/or distributed database devices implementing the distributed database and executed in a consensus order. At 704, the root hash of the Merkle tree can be signed. Specifically, a compute device can digitally sign the hash of the root node of the Merkle tree with a private key of that compute device.).
The motivation is the same as that of claim 6 above.
Regarding claim 11, Jing, Wang and Baird, III disclose the method of claim 7. Baird, III further discloses: storing, by the first party and the second party: the data item for determining the Merkle tree (Baird, III, [0085]. The method 700 includes, at 702, defining a state of a distributed database as a Merkle tree. The state can be based on transactions and/or events exchanged between compute devices and/or distributed database devices implementing the distributed database and executed in a consensus order.);
at least one of: the Merkle tree and the instructions for generating the Merkle tree from the set of data items Specifically, based on the nodes in the Merkle path of Data W (i.e., nodes HX and HYZ) and the root node HWXYZ, a user can verify that Data W is in the Merkle tree 600. For example, HW can be calculated based on a hash of Data W; HWX can be calculated based on a hash of HW (previously calculated) and HX (provided as part of the Merkle path); and HWXYZ can be calculated based on a hash of HWX (previously calculated) and HYZ (provided as part of the Merkle path). Once HWXYZ is calculated, this can be compared to a previously stored and/or provided value of the root node.;
at least one of: transaction data and an identifier of the transaction (Baird, III [0041]. Each event can be a record containing a cryptographic hash of two earlier events (linking that event to the two earlier events and their ancestor events, and vice versa), payload data (such as transactions that are to be recorded), other information such as the current time, a timestamp (e.g., date and UTC time) that its creator asserts is the time the event was first defined, and/or the like.).
The motivation is the same as that of claim 7 above.
Regarding claim 12, Jing, Wang and Baird, III disclose the method of claim 7. Baird, III further discloses performing, by at least one of the first party and the second party: sharing, with a third party, a data field used for determining the Merkle tree; sending, to the third party, a Merkle proof of the data field (Baird, III, [0072], [0076], [0079]. Specifically, the user device can request the distributed database device (e.g., distributed database device 310, 320, 330, 340) to which it is connected to provide a state proof for a given piece of data. Verifying that the Merkle tree root, the state proof, the data in the state proof, and/or the timestamp of the state proof is/are signed by a threshold number (based on total number or an amount of stake) of distributed database devices from the current address book of the distributed database. A third party and/or user device can verify a piece of information and/or data if they are given a state proof for the piece of information and/or data, even if the state proof is constructed by an untrusted distributed database device or a malicious distributed database device.).
The motivation is the same as that of claim 6 above.
Regarding claim 16, claim 16 is directed to a computer equipment corresponding to the method of claim 1. Claim 16 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer-readable storage media corresponding to the method of claim 1. Claim 17 is similar to claim 1 and is therefore rejected under similar rationale.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Jing (“Jing,” US 20200363994, published Nov. 19, 2020), Nordstrom et al. (“Nordstrom,” US 20200175138, published June 4, 2020) and Baird, III (“Baird, III,” US 20200372015, published Nov. 26, 2020) and Wang et al. (“Wang,” US 20200145493, published May 7, 2020).
Regarding claim 3, Jing, Nordstrom and Bird, III disclose the method of claim 1. Jing, Nordstrom, and Bird, III do not explicitly disclose: wherein the first value comprises a numerical value and the functionally equivalent value comprises a descriptive term, wherein the method comprises: determining the descriptive term by determining a numerical range containing the numerical value, wherein the descriptive term corresponds to the numerical range.
However, in an analogous art, Wang discloses wherein the first value comprises a numerical value and the functionally equivalent value comprises a descriptive term, wherein the method comprises: determining the descriptive term by determining a numerical range containing the numerical value, wherein the descriptive term corresponds to the numerical range (Wang [0087], [0125]. The integrated sensor may employ different hash functions, …, at different times, for use with different types of messages, and for different message recipients. The integrated sensor may execute software that controls which hash function,… to use, depending upon time, type of message, and message recipient. The integrated sensor may receive instructions from an MDTU specifying conditions for the integrated sensor to use particular hash functions, pre-functions, encryption algorithms, and encryption keys. For example, hash function to provide a n digital bits may be implemented sequentially removing all odd digital bits, checking to determine of the result is less than 2n digits, and if so, truncating the result to the first n digital bits. And repeating the process for results larger than 2n digital bits until the number of bits is less than 2n. Another hash function may use the same algorithm, but chose a different value for n.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Wang, Jing, Nordstrom and Bird, III to include the step of: wherein the first value comprises a numerical value and the functionally equivalent value comprises a descriptive term, wherein the method comprises: determining the descriptive term by determining a numerical range containing the numerical value, wherein the descriptive term corresponds to the numerical range. One would have been motivated to provide users with a means for providing hashing algorithms with different truncation protocols according to system and network security requirements. (See Wang [0125].)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Jing (“Jing,” US 20200363994, published Nov. 19, 2020), Nordstrom et al. (“Nordstrom,” US 20200175138, published June 4, 2020) and Baird, III (“Baird, III,” US 20200372015, published Nov. 26, 2020) and Kreder, III et al., (“Kreder, III,” US 20230155839, filed Nov. 12, 2021).
Regarding claim 8, Jing, Nordstrom and Baird, III disclose the method of claim 6.
Jing, Nordstrom and Baird, III do not explicitly disclose: wherein the output comprises a public key infrastructure certificate for the signature of the first party, and wherein the method comprises: prior to sending, by the second party, the transaction to the first party or to a blockchain: checking, by the second party, a validity of the public key infrastructure certificate for the signature of the first party.
However, in an analogous art, Kreder, III discloses a method, comprising the steps of:
wherein the output comprises a public key infrastructure certificate for the signature of the first party, and wherein the method comprises (Kreder, III FIGs 4-5, [0029], [0107]. For example, if a PKI system is in use, the asset public key 118 may comprise is a public key that is associated with the asset private key 114. At 424 a secure channel 426 with attestation is established between the first secure device 130(1) and the second secure device 130(2). The attestation is provided by validating a public key provided by a participating secure device 130 has been signed by a common root certificate authority (CA).):
prior to sending, by the second party, the transaction to the first party or to a blockchain: checking, by the second party, a validity of the public key infrastructure certificate for the signature of the first party (Kreder, III FIGs 4-5, [0029], [0107], [0152]. For example, if a PKI system is in use, the asset public key 118 may comprise is a public key that is associated with the asset private key 114. At 424 a secure channel 426 with attestation is established between the first secure device 130(1) and the second secure device 130(2). The attestation is provided by validating a public key provided by a participating secure device 130 has been signed by a common root certificate authority (CA).)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Kreder, III, Baird III, Nordstrom and Jing to include the step of: wherein the output comprises a public key infrastructure certificate for the signature of the first party, and wherein the method comprises: prior to sending, by the second party, the transaction to the first party or to a blockchain: checking, by the second party, a validity of the public key infrastructure certificate for the signature of the first party. One would have been motivated to provide users with a means for incorporate PKI certificate validation for blockchain-based transactions. (See Kreder, III [0156].)
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Jing (“Jing,” US 20200363994, published Nov. 19, 2020), Nordstrom et al. (“Nordstrom,” US 20200175138, published June 4, 2020), Baird, III (“Baird, III,” US 20200372015, published Nov. 26, 2020) and Haber et al. (“Haber,” US 20170033933, published Feb. 2, 2017).
Regarding claim 13, Jing, Nordstrom and Baird, III disclose the method of claim 1.
Jing, Nordstrom and Baird, III do not explicitly disclose: wherein the method comprises: generating a set of misdirection data items; generating two or more leaf nodes of a further Merkle tree by hashing each data item in the set of misdirection data items; setting a leaf node in a specific position of the further Merkle tree to be a certain value to indicate that misdirection data items were used to generate the further Merkle tree; and storing the further Merkle tree, the further Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes.
However, in an analogous art, Haber discloses a method, comprising the step of:
generating a set of misdirection data items (Haber [0020]. At block 130, a plurality of dummy values is generated for the document. Dummy values can prevent analysis of the signature from revealing which or the number of subdocuments that have been redacted from a document. Dummy values are values that are indistinguishable from commitment values.) ;
generating two or more leaf nodes of a further Merkle tree by hashing each data item in the set of misdirection data items; setting a leaf node in a specific position of the further Merkle tree to be a certain value to indicate that misdirection data items were used to generate the further Merkle tree; and storing the further Merkle tree, the further Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes (Haber [0026]-[0027]. A signature value for the document is then calculated using the plurality of commitment values and the plurality of dummy values according to the order defined at block 150. Said differently, the plurality of commitment values and the plurality of dummy values are arranged in a sequence according to the order, and the signature value is calculated from the sequence. As a specific example, the plurality of commitment values and the plurality of dummy values can be assigned to leaf nodes of a binary hash tree such as a Merkle tree according to the order. The signature value for the document can then be calculated by ascending the binary hash tree, as follows. As an example, an intermediate hash value is calculated for each node in the binary hash tree. At the leaf nodes, the intermediate hash values are commitment values and dummy values assigned to the leaf nodes according to the order.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Haber, Baird, III, Nordstrom and Jing to include the step of: generating a set of misdirection data items; generating two or more leaf nodes of a further Merkle tree by hashing each data item in the set of misdirection data items; setting a leaf node in a specific position of the further Merkle tree to be a certain value to indicate that misdirection data items were used to generate the further Merkle tree; and storing the further Merkle tree, the further Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes. One would have been motivated to provide users with a means for improving the security of blockchain transactions through generating a Merkle hash tree with real and dummy values. (See Haber [0020].)
Claim 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Jing (“Jing,” US 20200363994, published Nov. 19, 2020), Nordstrom et al. (“Nordstrom,” US 20200175138, published June 4, 2020), Baird, III (“Baird, III,” US 20200372015, published Nov. 26, 2020) and Zhang et al. (“Zhang,” US 20200026699, published Jan. 23, 2020).
Regarding claim 14, Jing, Nordstrom and Baird, III disclose the method of claim 1. Zhang further discloses wherein the set of data items includes one or more data items describing an invoice (Zhang [0065], [0067]-[0069]. In some embodiments, the fast block contains one or more of the following: StateRoot: Hash root of the state Merkle tree, after all transactions are executed. Transactions root: Hash root of the Merkle tree with each transaction in the transactions list. ReceiptHash: Hash root of the Merkle tree with receipts of each transaction in the transactions list.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Zhang, Baird, III, Nordstrom and Jing to include the step of: wherein the set of data items includes one or more data items describing an invoice. One would have been motivated to provide users with a means for improving the security of blockchain transactions through generating a Merkle hash tree comprising receipt of transactions. (See Zhang [0069].)
Regarding claim 15, Jing, Nordstrom, and Baird, III disclose the method of claim 1. Zhang further discloses wherein each leaf node generated by hashing one of the one or more data items describing an invoice is paired with a leaf node generated by hashing a random value (Zhang [0069], [0153]. ReceiptHash: Hash root of the Merkle tree with receipts of each transaction in the transactions list. In some embodiments, the random (or pseudo-random) function uses (410) a random (or pseudo-random) number based on hash data used in a previous committee election. In some embodiments, the node generates (412) the random (or pseudo-random) number by using a periodically changing hash algorithm.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Zhang, Baird, III, Nordstrom and Jing to include the step of: wherein the set of data items includes one or more data items describing an invoice. One would have been motivated to provide users with a means for improving the security of blockchain transactions through generating a Merkle hash tree comprising receipt of transactions. (See Zhang [0069].)
Conclusion
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.
Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights