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 .
DETAILED ACTION
1. Claims 1 - 20 are pending. Claims 1, 11 are independent.
2. This application was filed on 1-9-2025.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1 - 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter as follows.
Claims 1 - 10 are to be construed as a computer system in the preamble without any hardware structural element in the body of the claim, therefore, is directed to software per se. under broadest reasonable interpretation. Examiner suggests amending the claim to recite at least one hardware structural element to overcome the 35 U.S.C 101 rejection. Dependent claims 2-10 are also rejected under the same rationale.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
6. Initially it should be noted that the present application is a continuation application of application 16/226684, now Patent No. 12,198,149, having the same inventive entity. The Assignee in both applications is the same. The entire disclosures of the instant application and the patent are identical.
Claims 1 - 20 are rejected under the judicially created doctrine of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1 - 10 of U.S. Patent No. 12,198,149. Although the conflicting claims are not identical, they are not patentably distinct from each other.
Claims 1, 11 of the instant application (19/015469) are almost the same as Patent (12,198,149) Claims 1, 3, 6. Claim 1 of the 12,198,149 Patent as shown in the table below contains every element of Claim 1 of the instant application and as such the difference is not enough to distinguish the two claims. Claims 1, 11 of the instant application therefore are not patently distinct from the earlier patent claims and as such are unpatentable over obvious-type double patenting. The limitations recited in the independent of instant application are anticipated by the claims recited in the parent claims (see example below). A later patent/application claim is not patentably distinct from an earlier claim, if the later claim is unpatentable over the earlier claim.
Application 19/015469
Claim 1
Patent (12,198,149)
Claim 1
” a relational Merkle tree data store comprising a child node and an additional child node”
“a relational Merkle tree data store comprising at least one a child node and an additional child node”
“the child node has a linked parent node of a first Merkle tree, the linked parent node is tagged with a hash of the child node”
“the child node has a linked parent node of a first Merkle tree, the linked parent node is tagged with a hash of the child node”
“the child node and the additional child node are each tagged with an inverse hash of the linked parent node prior to the relational Merkle tree data store receiving a request for a product history of a product, wherein the inverse hash is exclusively a cryptographic hash of the linked parent node, wherein the inverse hash is used to perform a bi-directional traversal of the relational Merkle tree data store to retrieve the product history for the request, and wherein the relational Merkle tree data store comprises the product history of the product”
“the child node and the additional child node are each tagged with an inverse hash of the linked parent node prior to the relational Merkle tree data store receiving a request for a product history of a product, wherein the inverse hash is exclusively a cryptographic hash of the linked parent node, wherein the inverse hash is used to perform a bi-directional traversal of the relational Merkle tree data store to retrieve the product history for the request, and wherein the relational Merkle tree data store comprises the product history of the product”
and a noSQL data store comprising at least one replicated child node, at least one replicated parent node, at least one replicated hash, and at least one replicated inverse hash, wherein the at least one replicated child node, the at least one replicated parent node, the at least one replicated hash, and the at least one replicated inverse hash are copied from and synchronized to a portion of the relational Merkle tree data store, and wherein authenticity of [[a]] the product is validated using data retrieved from the relational Merkle tree data store or the noSQL data store based on different retrieval methods and data retrieval performance of the relational Merkle tree data store and the noSQL data store, wherein the first Merkle tree originates from a first root node and a second Merkle tree originates from a second root node, and wherein the child node of the first Merkle tree and a second child node of the second Merkle tree each correspond to different data blocks comprising different content, wherein the child node of the first Merkle tree and [[a]] the second child node of the second Merkle tree are each tagged with a same single lateral hash labeling a peer relationship between the child node of the first Merkle tree and the second child node of the second Merkle tree.
Claim Rejections - 35 USC § 103
7. 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.
8. Claims 1 - 3, 7 - 13, 17 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cantwell et al. (US PGPUB No. 20150244795) in view of Dequen et al. (US PGPUB No. 20180115427) and further in view of Anton et al. (US PGPUB No. 20160344737).
Regarding Claims 1, 11, Cantwell discloses a system and a method comprising:
a) a relational Merkle tree data store comprising a child node and an additional child node, (see Cantwell paragraph [0030]: data structured as leaves (i.e. child nodes) of a hash tree such as a Merkle tree, metadata includes the hash tree; paragraph [0053]: Merkle tree comparison operations utilized to determine modified blocks of data; paragraph [0033]: hash tree has any number of child nodes (i.e. associated with a set of parent nodes); (Merkle tree))
wherein:
b) the child node has a linked parent node of a first Merkle tree, c) the linked parent node is tagged with a hash of the child node, (see Cantwell paragraph [0033]: hash tree has any number of child nodes (i.e. associated with a set of parent nodes), block identifiers are utilized as identifiers that each uniquely identify a particular set of data blocks; hash tree entity includes leaves structured as an ordered list indexed by its parent nodes (child node utilizing a link (i.e. hash) associated with parent); block identifiers are hashes based on content of corresponding data block(s); values stored by non-leaf nodes are a hash for that particular node’s child values; paragraph [0051]: Merkle Trees (first, second) can be used to minimize the amount of data that is required to be transferred between the source system and the replica server; paragraph [0041]: using trees (first, second Merkle trees), backup server may retrieve the metadata from a metadata server by requesting only child nodes whose parent node has changed) and
d)
Cantwell does not specifically disclose for d) the inverse hash is used to perform a bi-directional traversal of the relational Merkle tree data store to retrieve the product history for the request.
However, Dequen discloses for d) wherein the inverse hash is exclusively a cryptographic hash of the linked parent node and the inverse hash is used to perform a bi-directional traversal of the relational Merkle tree data store to retrieve the product history for the request, (see Dequen paragraph [0083]: inverse hash function: solving of hash function utilized to generate hashed word; retrieve data; paragraph [0105], lines 1-5: inverse hash function: solving of hash function in order to retrieve data; paragraph [0031]: authentication protocol using hash functions for registration and authentication processes ; (inverse hash, bi-directional transversal pf tree structure))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Cantwell for d) the inverse hash is used to perform a bi-directional traversal of the relational Merkle tree data store to retrieve the product history for the request as taught by Dequen. One of ordinary skill in the art would have been motivated to employ the teachings of Dequen for the benefits achieved from a system that enables the generation and authentication processing utilizing inverse hash parameters within a network environment. (see Dequen paragraphs [0083]; [0105])
Cantwell does not specifically disclose for d) the relational Merkle tree data store comprises the product history of the product.
However, Anton discloses wherein for d) the relational Merkle tree data store comprises the product history of the product. (see Anton paragraph [0011], lines 1-10: auditing of a data resource through an immutable record of transactions within a hash history (i.e. transaction event history); method for maintaining uniqueness of an evolving data resource within a datastore usable to verify an original of data organism, control copies of the data organism, transfer an ownership of a data organism and/or audit the datastore; data organisms include document, a media file such as music or video, and an electronic record; paragraph [0017], lines 1-6: history (i.e. hash history) of the original instance of a data organism is stored as a Merkle tree; paragraph [0092], lines 1-11: ownership transferred between a first user and a second user by changing an ownership designation and depositing a record of transaction (e.g., transaction record) within a block of the history (i.e. hash history) of the data organism (resource))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Cantwell for d) the relational Merkle tree data store comprises the product history of the product.as taught by Anton. One of ordinary skill in the art would have been motivated to employ the teachings of Anton for the benefits achieved from a system that enables maintaining a record of a sequence of transactions associated with ownership information. (see Anton paragraph [0011], lines 1-10; paragraph [0092], lines 1-11)
Regarding Claims 2, 12, Cantwell-Dequen-Anton discloses the system of claim 1 and the method of claim 11, further comprising: a noSQL data store comprising at least one replicated child node, at least one replicated parent node, at least one replicated hash, and at least one replicated inverse hash. (see Cantwell paragraph [0053], lines 3-7: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes (parent, child nodes) with the corresponding Merkle tree nodes of the replica system (i.e. replicated nodes, parent, child nodes); when corresponding nodes do not match, then data not properly replicated; for comparison to work properly, source side and replicated side must be in sync with each other (synchronization))
Regarding Claims 3, 13, Cantwell-Dequen-Anton discloses the system of claim 2 and the method of claim 11, wherein the at least one replicated hash does not match the hash or that the at least one replicated inverse hash does not match the inverse hash. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync; paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures) (selected: replicated hash does not match hash))
Dequen discloses an inverse hash as stated above.
Regarding Claims 7, 17, Cantwell-Dequen-Anton discloses the system of claim 2 and the method of claim 12, wherein the noSQL data store further comprises at least two replicated lateral hashes. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057], lines 1-18: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica system (i.e. replicated nodes, parent, child nodes); when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync; paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claims 8, 18, Cantwell-Dequen-Anton discloses the system of claim 7 and the method of claim 17, wherein the at least two replicated lateral hashes are copied from and synchronized with a portion of the relational Merkle tree data store. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync (synchronized data); paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claim 9, Cantwell-Dequen-Anton discloses the system of claim 2, wherein the at least one replicated hash matches the hash in the relational Merkle tree data store. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated, when corresponding nodes match, data properly replicated; for comparison to work properly, source side and replicated side must be in sync; (comparison: replicated hashes and hash); paragraph [0050], lines 19-23: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claim 10, Cantwell-Dequen-Anton discloses the system of claim 9, wherein the at least one replicated inverse hash matches the inverse hash in the relational Merkle tree data store. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; when corresponding nodes match, data properly replicated; for comparison to work properly, source side and replicated side must be in sync; (comparison: replicated hashes and hash); paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claim 19 Cantwell-Dequen-Anton discloses the method of claim 12, further comprising, in response to determining that the at least one replicated hash does not match the hash or that the at least one replicated inverse hash does not match the inverse hash (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync; (selected: replicated hash does not match hash)): erasing the noSQL data store. (see Cantwell paragraph [0044]: removing data blocks of storage space; removed block identifiers (hash parameters) removed from ordered list; paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claim 20, Cantwell-Dequen-Anton discloses the method of claim 19, further comprising:
a) comparing a portion of the noSQL data store to the relational Merkle tree data store utilizing the relational Merkle tree data store as primary; and b) finding the at least one replicated hash to match the hash in the relational Merkle tree data store and the at least one replicated inverse hash to match the inverse hash in the relational Merkle tree data store. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync (hashes match); (comparison replicated hash and hash); paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
9. Claims 4 - 6, 14 - 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cantwell et al. (US PGPUB No. 20150244795) in view of Dequen et al. (US PGPUB No. 20180115427) and further in view of Anton et al. (US PGPUB No. 20160344737) and Bensberg et al. (US PGPUB No. 20180137164).
Regarding Claims 4, 14, Cantwell-Dequen-Anton discloses the system of claim 2, wherein the first Merkle tree originates from a first root node and a second Merkle tree originates from a second root node, (Cantwell paragraph [0033]: hash trees (first Merkle tree, second Merkle tree) includes leaves, internal nodes, and root node (first, second root node coupled to Merkle tree); leaves store block identifiers, respectively. In an implementation, leaves may be structured as an ordered list that is indexed by its parent nodes; block identifiers B1-B4 are identifiers as described herein (e.g., a hash of the corresponding data block's content), and each uniquely identify a particular data block of the volume; hash tree (first, second Merkle tree) further includes non-leaf internal nodes and non-leaf root node; paragraph [0041]: using trees (first, second Merkle trees), backup server may retrieve the metadata from a metadata server by requesting only child nodes whose parent node has changed)
Cantwell does not specifically disclose the child node of the first Merkle tree and a second child node of the second Merkle tree are each tagged with a single (same) lateral hash labeling a peer relationship between the child node of the first Merkle tree and the second child node of the second Merkle tree.
However, Bensberg discloses wherein the child node of the first Merkle tree and a second child node of the second Merkle tree are each tagged with a single lateral hash labeling a peer relationship between the child node of the first Merkle tree and the second child node of the second Merkle tree. (see Bensberg paragraph [0023]: a hash collision exists where at least two distinct data entries each resolve to the same hash value (or a single hash value) as a result of the same hash function; paragraph [0024]: resolution dictionary, a separate data structure that may associate a unique identifier, such as a special index value, with each hash collision value in the hash collision table; resolution dictionary may also preferably associate the special index value and/or each hash collision value with corresponding data entries that each result in the same hash collision value of a detected hash collision; By ensuring a unique identifier, such as the special index value, for each original data entry that would result in a hash collision, such unique identifiers may, in some embodiments, be used in place of or alongside the hash values that have collisions)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Cantwell for the child node of the first Merkle tree and a second child node of the second Merkle tree are each tagged with a single (same) lateral hash as taught by Bensberg. One of ordinary skill in the art would have been motivated to employ the teachings of Bensberg for the benefits achieved from a system that manages the situation where a hash results is the same for two different input values. (see Bensberg paragraph [0023]; paragraph [0024])
Regarding Claim 5, Cantwell-Dequen-Anton discloses the system of claim 4, wherein the noSQL data store comprises a replicated lateral hash that is generated based on the single lateral hash of the child node and the second child node. (see Cantwell paragraph [0053], lines 3-7: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057], lines 1-18: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync; paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claims 6, 16, Cantwell discloses the system of claim 5, wherein the replicated lateral hash matches the single lateral hash. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; when corresponding nodes match, data properly replicated; for comparison to work properly, source side and replicated side must be in sync; paragraph [0050]: data storage structure 1: metadata includes an ordered list structure of block identifiers; data storage structure 2: ordered list is structured as the leaves of a hash tree (e.g., such as a Merkle tree, etc.) and the metadata is included in the hash tree; (two data storage structures analogous to noSQL and Merkle tree data structures))
Regarding Claim 15, Cantwell-Dequen-Anton discloses the method of claim 14, wherein replicating the child node further comprises: replicating the single lateral hash of the child node and the second child node into a replicated lateral hash in the noSQL data store. (see Cantwell paragraph [0053]: Merkle tree comparison operations used to determine data blocks which have been modified; paragraph [0057]: replica system compares received Merkle tree nodes with the corresponding Merkle tree nodes of the replica (replicated nodes) system; when corresponding nodes do not match, data not properly replicated; for comparison to work properly, source side and replicated side must be in sync)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLTON JOHNSON whose telephone number is (571)270-1032. The examiner can normally be reached Work: 12-9PM (most days).
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, Shewaye Gelagay can be reached at 571-272-4219. 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.
/CJ/
September 21, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights