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, see page 8, filed 07/07/2026, with respect to the objection to the specification, have been fully considered. The objection to the specification has been withdrawn in response to the removal of the executable code.
Applicant’s arguments, see page 8, filed 07/07/2026, with respect to the rejection of claims 1-8, 11-15, 21-22, 26-28, 30 and 32 under 35 U.S.C. § 112(a) have been fully considered. The previous rejection of claims 1-8, 11-15, 21-22, 26-28, 30 and 32 under 35 U.S.C. § 112(a) have been withdrawn in view of Applicant’s amendments removing the limitations that lack support in the originally filed disclosure.
Applicant’s arguments, see pages 8-11 with respect to the rejection of claim(s) 1-8, 11-15, 21-22, 26-28, 30 and 32 under 35 U.S.C. § 102(a)(1) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-8, 11-15, 21-22, 26-28, 30 and 32 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by ALIN TOMESCU ET.AL.: “Catena: Preventing Lies with Bitcoin”, IACR, INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH, vol. 20161115:150307, 13 November 2016 pages 1-17, XP061022070 hereinafter Alin.
Regarding Claims 1 and 30:
Claim 1. Alin discloses a computer-implemented method of providing proof that a blockchain transaction exists on a blockchain (Alin Fig. 1 and 3, Section III A System Model), wherein the method is performed by a Merkle proof entity configured to store a set of transaction identifiers of respective blockchain transactions but not to publish new blockchain blocks to the blockchain (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model log server stores transactions, the broadest reasonable interpretation of a Merkle proof entity includes multiple computing devices in light of pgs. 30-31 and 35 of the originally filed specification “the term ‘Merkle proof entity’ is used merely as a convenient label for an entity configured to perform the actions described herein. Similarly, the term ‘Merkle proof server’ does not necessarily mean that the described actions are performed by a server (i.e. one or more server units), although that is one possible implementation”); and wherein the method comprises: obtaining a target transaction identifier of a target blockchain transaction (Alin Figs. 1-4, Section III A. System Model, Section IV “Catena operates very simply, as illustrated in Figure 1.The Catena log server creates a log by issuing an initial transaction called the genesis transaction. The server issues the first statement in the log by creating a new transaction which spends the genesis transaction and commits that first statement via an OP_RETURN transaction output (see Section II-B6). Finally, the server can append a new statement to the log by creating a new transaction which spends the previously created transaction and commits the statement as before. Catena clients first obtain the log’s genesis transaction, … Then, clients obtain and verify all Bitcoin block headers from the header relay network (discussed in Section IV-C). Finally, clients can ask the Catena log server for the statements and verify them against the genesis transaction and the Bitcoin block headers. Importantly, because Catena transactions are chained and Bitcoin prevents double spends, clients are assured that no inconsistent statements have been issued by the server. Catena’s overhead is small. For each statement, the server will send over a 235-byte Catena transaction and a 350-byte Merkle path proving that the statement is part of the log. That amounts to around 600 bytes per statement plus the overhead of downloading all block headers (currently 35 MB), making Catena very cheap in terms of bandwidth” Section IV D. Auditing a Catena Log “to audit a log, clients download the Catena transaction chain and verify that the transactions are signed and chained correctly using the statement key. Clients first download and verify block headers from the header relay network and then download and verify Catena transactions and their Merkle proofs from the log server. The log server can serve the transactions and Merkle proofs more efficiently [storing transactions and serving transactions anticipates the claimed obtaining a target transaction identifier] than using Bloom filtering on the Bitcoin P2P nodes (see section II-B7) which creates significant disk activity for Bitcoin full nodes. Finally, auditing is cheap for Catena clients as they only download small transactions and Merkle proofs (600 bytes) and not full Bitcoin blocks (1 MB)”), wherein the target transaction identifier forms part of the stored set of transaction identifiers (Alin Figs. 1-4, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log); obtaining a target Merkle proof for the target blockchain transaction, the target Merkle proof based on one or more of the stored set of transaction identifiers (Alin Figs. 1-4, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log “to audit a log, clients download the Catena transaction chain and verify that the transactions are signed and chained correctly using the statement key. Clients first download and verify block headers from the header relay network and then download and verify Catena transactions and their Merkle proofs from the log server. The log server can serve the transactions and Merkle proofs more efficiently than using Bloom filtering on the Bitcoin P2P nodes (see section II-B7) which creates significant disk activity for Bitcoin full nodes. Finally, auditing is cheap for Catena clients as they only download small transactions and Merkle proofs (600 bytes) and not full Bitcoin blocks (1 MB)”), wherein a corresponding target Merkle root is contained within a blockheader of the blockchain (Alin Figs. 1-4, Section IV, Section IV. D Auditing a Catena Log); and outputting the target Merkle proof for use by a requesting party as proof that the target blockchain transaction exists on the blockchain (Alin Figs. 1-4, Section IV, Section IV. D Auditing a Catena Log).
Claim 30 recites substantially the same content and is therefore rejected under the same rationales. Alin discloses “a computer program product embodied on non-transitory computer-readable storage media and configured so as, when run on one or more processors, the one or more processors perform a method” (Alin Fig. 1 and 3, Section III A System Model).
Regarding Claim 2:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein the Merkle proof entity does not store the full blockchain (Alin Figs. 1-4, Section III D. 3) Efficiently Verifiable “Catena clients should be able to audit logs efficiently without downloading the entire Bitcoin blockchain”).
Regarding Claim 3:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein obtaining the target Merkle proof comprises calculating an index of the target transaction identifier within a leaf layer of a corresponding target Merkle tree (Alin Figs. 1-4 index of block shown including Merkle trees, Section II B. 7) Catena takes advantage of a thin node implementation).
Regarding Claim 4:
Alin further discloses the method of claim 3 (Alin Fig. 1 and 3, Section III A System Model), comprising outputting the index to the requesting party (Alin Figs. 1-4, Section IV, Section IV A. Genesis Transaction, Section IV B. Catena Transactions, Section IV D. Auditing a Catena Log).
Regarding Claim 5:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein said obtaining of the target transaction identifier comprises obtaining the target transaction identifier from the requesting party (Alin Figs. 1-4 index of block shown including Merkle trees, Section II B. 7) Catena takes advantage of a thin node implementation).
Regarding Claim 6:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein said obtaining of the target transaction identifier comprises obtaining the target blockchain transaction (Alin Figs. 1-4, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log) and constructing the target transaction identifier based on the target blockchain transaction (Alin Figs. 1-4, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log).
Regarding Claim 7:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein said obtaining of the target Merkle proof comprises calculating the target Merkle proof using one or more of the stored set of transaction identifiers (Alin Figs. 1-4, Section III D. “the barrier for Catena clients is very low. A client only downloads small 80-byte block headers for each Bitcoin block and 600-byte Merkle membership proofs for each issued statement.”).
Regarding Claim 8:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein the Merkle proof entity stores a respective Merkle proof for one or more of the stored set of transaction identifiers including the target transaction identifier (Alin Figs. 1-4, Section III D. Catena client may store block headers and Merkle membership proof), and wherein said obtaining of the target Merkle proof comprises extracting the target Merkle proof from a storage location (Alin Figs. 1-4, Section III D. Catena client may store block headers and Merkle membership proof).
Regarding Claim 11:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein the Merkle proof entity stores one or more Merkle roots (Alin Figs. 1-4, Section IV A. Merkle root stored in block header), wherein each Merkle root is based on a respective subset of the stored set of transaction identifiers (Alin Figs. 1-4, Section IV A. Merkle root stored in block header).
Regarding Claim 12:
Alin further discloses the method of claim 11 (Alin Fig. 1 and 3, Section III A System Model), comprising outputting, to the requesting party, the Merkle root based on the target transaction identifier (Alin Figs. 1-4, Section IV, Section IV. D Auditing a Catena Log).
Regarding Claim 13:
Alin further discloses the method of claim 11 (Alin Fig. 1 and 3, Section III A System Model), wherein the Merkle proof entity stores, for each of the one or more Merkle roots, a Merkle tree (Alin Figs. 1-4, Section IV A. Merkle root stored in block header and each block has a Merkle tree of transactions).
Regarding Claim 14:
Alin further discloses the method of claim 13 (Alin Fig. 1 and 3, Section III A System Model), wherein said obtaining of the target Merkle proof comprises extracting the target Merkle proof from a stored Merkle tree comprising the target transaction identifier (Alin Figs. 1-4, Section IV A. Merkle root stored in block header and each block has a Merkle tree of transactions).
Regarding Claim 15:
Alin further discloses the method of claim 1 (Alin Fig. 1 and 3, Section III A System Model), wherein the stored set of transaction identifiers comprises a plurality of subsets of transaction identifiers (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model), wherein each subset of transaction identifiers comprises all transaction identifiers from a respective block of the blockchain (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model).
Regarding Claim 21:
Alin further discloses the method of claim 15 (Alin Fig. 1 and 3, Section III A System Model), wherein the Merkle proof entity stores, for each subset of transaction identifiers, a first blockchain transaction from the respective block (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model, Section IV A. Genesis transaction).
Regarding Claim 22:
Alin further discloses the method of claim 21 (Alin Fig. 1 and 3, Section III A System Model), comprising: obtaining a first Merkle proof for the first blockchain transaction (Alin Figs. 1-4, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log), wherein the first Merkle proof is based on one or more of the stored set of transaction identifiers (Alin Figs. 1-4, Section III D. “the barrier for Catena clients is very low. A client only downloads small 80-byte block headers for each Bitcoin block and 600-byte Merkle membership proofs for each issued statement.”); and outputting the first blockchain transaction and the first Merkle proof for use by the requesting party for verifying that a length of the target Merkle proof matches a length of the corresponding target Merkle tree (Alin Figs. 1-4, Section IV, Section IV A. Genesis Transaction, Section IV. D Auditing a Catena Log).
Regarding Claims 26 and 32:
Claim 26. Alin discloses a computer-implemented method of obtaining proof that a blockchain transaction exists on a blockchain (Fig. 1 and 3, Section III A System Model), wherein a Merkle proof entity stores a set of transaction identifiers of respective blockchain transactions (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model), wherein the Merkle proof entity is configured to store a set of transaction identifiers of respective blockchain transactions but not to publish new blockchain blocks to the blockchain (Alin Figs. 1-4, Section II A. (2) Blockchain-based Transparency, Section III A. System Model), wherein the method is performed by a requesting party and comprises (Alin Figs. 1-4 Catena client queries): sending, to the Merkle proof entity, a target transaction identifier of the target transaction (Alin Figs. 1-4, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log); and obtaining, from the Merkle proof entity, a target Merkle proof for the target blockchain transaction (Alin Figs. 1-4, Section IV, Section IV. D Auditing a Catena Log), wherein the Merkle proof is based on one or more of the stored set of transaction identifiers (Alin Figs. 1-4, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log).
Claim 32 recites substantially the same content and is therefore rejected under the same rationales. Alin also discloses a computer program product embodied on non-transitory computer-readable storage media and configured so as, when run on one or more processors, to perform a method (Fig. 1 and 3, Section III A System Model).
Regarding Claim 27:
Alin further discloses the method of claim 26 (Fig. 1 and 3, Section III A System Model), comprising sending the target Merkle proof to a second requesting party as proof that the target blockchain transaction exists on the blockchain (Alin Figs. 1-4, Section IV, Section IV. D Auditing a Catena Log).
Regarding Claim 28:
Alin further discloses the method of claim 26 (Fig. 1 and 3, Section III A System Model), wherein the target blockchain transaction is a most recent one of a chain of blockchain transactions (Alin Figs. 1-5, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log, Section V B. Catena may query for “fresh” or recent transactions), wherein the requesting party has access to each transaction in the chain of blockchain transactions (Alin Figs. 1-5, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log, Section VI B. log clients have access to newly issued statements), wherein the target Merkle proof is proof that each transaction in the chain of blockchain transactions exists on the blockchain (Alin Figs. 1-5, Section III A. System Model, Section IV, Section IV A. Genesis Transaction, Section IV D. Auditing a Catena Log, Section VI B. log clients have access to newly issued statements and can publish equivocation attempts by the log server).
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
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 MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
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, Jorge Ortiz-Criado can be reached on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights