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 action is response to communication: response to election filed on 02/04/2026..
Claims 1-6 are currently pending in this application. Applicants have elected Group I (claims 1-6) without traverse and have cancelled claims 7 and 8.
The IDS filed 10/03/2024, 06/23/2025, and 107/17/2025 have been accepted.
Election/Restrictions
Applicant’s election without traverse of the restriction requirement in the reply filed on 02/04/2026 is acknowledged.
Double Patenting
6. 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 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 Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
7. Claims 1 and 4 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,034,859. Although the claims at issue are not identical, they are not patentably distinct from each. Claims 1 and 4 of the instant application are obvious over claim 1 of US Patent No. 12,034,859. As per claim 1, as seen below for claim 1 of the instant application, the instant application is directed toward generating a secondary block identifier, while the parent patent is directed toward using the secondary block identifier and refers to the generation of the secondary block identifier using the same steps. The steps of the generation are thus anticipated by the claim limitations found in the parent patent. Further, claims 1 and 4 of the current application are further directed toward utilizing a block for a set of blockchain transactions while the parent teaches a utilizing a block for a singular transaction. This would have been obvious to one of ordinary skill in the art and is merely a design choice to process data that is grouped together or whether to process the data individually. The same steps are implemented for both and would have been merely a design choice and would have been obvious to one of ordinary skill in the art, depending on the use. See the differences in the claims, as highlighted below.
Instant Application
Patent 12,034,859
1. A computer-implemented method of generating a secondary block identifier of a block of a blockchain, wherein the block comprises a set of blockchain transactions, the secondary block identifier enabling a querying user to determine whether the set of blockchain transactions comprises a candidate data field; the method being performed by a generating user and comprising: for each blockchain transaction in the set of blockchain transactions, obtaining a respective secondary transaction identifier; and generating a transaction set hash tree, wherein the transaction set hash tree comprises: i) a leaf layer comprising a plurality of leaf hashes, wherein each leaf hash corresponds to a respective one of the secondary transaction identifiers, ii) one or more internal layers each comprising a plurality of internal hashes, wherein each internal hash in each internal layer is generated by hashing a concatenation of at least two hashes from a lower layer, each internal hash of a lowermost internal layer of the one or more internal layers being generated by hashing a concatenation of at least two different leaf hashes, and iii) a root layer comprising the secondary block identifier, wherein the secondary block identifier is generated by hashing a concatenation of the internal hashes of an uppermost internal layer of the one or more internal layers.
4. A computer-implemented method of enabling a querying user to determine whether a set of blockchain transactions within a block of a blockchain comprises a candidate data field; the method being performed by a committing user and comprising: obtaining a secondary block identifier of the block that comprises the set of blockchain transactions; and committing the secondary block identifier to a blockchain transaction for inclusion within a block of the blockchain, wherein the secondary block identifier has been generated by: for each blockchain transaction in the set of blockchain transactions, obtaining a respective secondary transaction identifier; and generating a transaction set hash tree, wherein the transaction set hash tree comprises: i) a leaf layer comprising a plurality of leaf hashes, wherein each leaf hash corresponds to a respective one of the secondary transaction identifiers, ii) one or more internal layers each comprising a plurality of internal hashes, wherein each internal hash in each internal layer is generated by hashing a concatenation of at least two hashes from a lower layer, each internal hash of a lowermost internal layer of the one or more internal layers being generated by hashing a concatenation of at least two different leaf hashes, and iii) a root layer comprising the secondary block identifier, wherein the secondary block identifier is generated by hashing a concatenation of the internal hashes of an uppermost internal layer of the one or more internal layers.
1. A computer-implemented method of enabling a querying user to determine whether a target blockchain transaction within a block of a blockchain comprises a candidate data field; the method being performed by a committing user and comprising: obtaining a secondary transaction identifier of the target blockchain transaction; and committing the secondary transaction identifier to a blockchain transaction for inclusion within a block of the blockchain, wherein the secondary transaction identifier has been generated by: identifying a set of data fields of the target blockchain transaction, each data field comprising respective data of the target blockchain transaction; and generating a transaction hash tree, wherein the transaction hash tree comprises: i) a leaf layer comprising a plurality of leaf hashes ordered based on the ordered set of data fields, wherein each data field is hashed to generate a respective one of the plurality of leaf hashes, ii) one or more internal layers each comprising a plurality of internal hashes, wherein each internal hash in each internal layer is generated by hashing a concatenation of at least two hashes from a lower layer, each internal hash of a lowermost internal layer of the one or more internal layers being generated by hashing a concatenation of at least two different leaf hashes, and iii) a root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a concatenation of the internal hashes of an uppermost internal layer of the one or more internal layers.
1. A computer-implemented method of enabling a querying user to determine whether a target blockchain transaction within a block of a blockchain comprises a candidate data field; the method being performed by a committing user and comprising: obtaining a secondary transaction identifier of the target blockchain transaction; and committing the secondary transaction identifier to a blockchain transaction for inclusion within a block of the blockchain, wherein the secondary transaction identifier has been generated by: identifying a set of data fields of the target blockchain transaction, each data field comprising respective data of the target blockchain transaction; and generating a transaction hash tree, wherein the transaction hash tree comprises: i) a leaf layer comprising a plurality of leaf hashes ordered based on the ordered set of data fields, wherein each data field is hashed to generate a respective one of the plurality of leaf hashes, ii) one or more internal layers each comprising a plurality of internal hashes, wherein each internal hash in each internal layer is generated by hashing a concatenation of at least two hashes from a lower layer, each internal hash of a lowermost internal layer of the one or more internal layers being generated by hashing a concatenation of at least two different leaf hashes, and iii) a root layer comprising the secondary transaction identifier, wherein the secondary transaction identifier is generated by hashing a concatenation of the internal hashes of an uppermost internal layer of the one or more internal layers.
.
Allowable Subject Matter
Claims 1 and 4 would be allowable if rewritten or amended to overcome the double patenting rejection set for above, or if a terminal disclaimer is properly filed.
Claims 2, 3, 5, and 6 would be allowable if rewritten to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: Below is the closest prior art the examiner has found:
Uhr et al. US Patent Application Publication 2018/0343128 teaches a blockchain node system for submitting data into a blockchain, including generating and utilizing a Merkle tree, with multiple layers of hashed information regarding prior transactions (see claim 1, paragarphs 23, 37, 54, and throughout).
Treat et al. US Patent Application Publication 2019/0253240 teaches utilizing blockchain and transaction details including transaction identifiers and leaf nodes (paragraph 23, 52, Figure 3A, and 68).
Sharma et al. US Patent Application Publication 2020/0252216 teaches utilizing a blockchain wallet and further teaches the use of a tree with values (pragarph 20).
Although the above references teach many aspects of the claimed invention, the claimed invention, as a whole, would not have been obvious over the prior art of record.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON KAI YIN GEE whose telephone number is (571)272-6431. The examiner can normally be reached on Monday-Friday 8:30-5:00 PST Pacific.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739. 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).
/JASON K GEE/Primary Examiner, Art Unit 2495