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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Response to Arguments
Applicant's arguments, see pages 7-9, filed 12/22/2025 have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specification
The disclosure is objected to because it contains an embedded hyperlink and/or other form of browser-executable code. Applicant is required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http:// or other browser-executable code. See MPEP § 608.01.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-8, 11-15, 21-22, 26-28, 30, and 32 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claims 1, 26, 30, and 32:
Independent Claims 1, 26, 30, and 32 recite the limitation “a Merkle proof entity configured … not to: … ii) submit blockchain transactions to the blockchain for storing”. Applicant has not pointed out where the new (or amended) claim is supported, nor does there appear to be a written description of this claim limitation in the application as filed. As in MPEP 2173.05(i), Any negative limitation or exclusionary proviso must have basis in the original disclosure. The mere absence of a positive recitation is not basis for an exclusion. While silence will not generally suffice to support a negative claim limitation, there may be circumstances in which it can be established that a skilled artisan would understand a negative limitation to necessarily be present in a disclosure." Novartis Pharms. Corp. v. Accord Healthcare, Inc., 38 F.4th 1013, 2022 USPQ2d 569 (Fed. Cir. 2022) (quoting Ariad Pharm. Inc. v. Eli Lilly & Co., 589 F.3d 1336, 1351, 94 USPQ2d 1161, 1172). Any claim containing a negative limitation which does not have basis in the original disclosure should be rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. See MPEP § 2163 - § 2163.07(b) for a discussion of the written description requirement of 35 U.S.C. 112(a) and pre-AIA 35 U.S.C. 112, first paragraph. In this case, the originally filed disclosure does not appear to be commensurate with the claimed language of a Merkle proof entity configured to store a set of transactions identifiers of respective blockchain transactions, but not to “submit blockchain transactions to the blockchain for storing”. When considering the entirety of the originally filed disclosure, the originally filed disclosure is silent with respect to any discussion of the claimed invention submitting blockchain transactions to the blockchain for storing in the positive or negative, and therefore the claims reciting a negative limitation of not doing so is not commensurate with the originally filed disclosure.
Dependent claims fall together accordingly.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-8, 11-15, 21-22, 26-28, 30 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by RAMABAJA; Lum (US Patent Publication No. US 2023/0108083 A1) hereinafter Rambaja.
Regarding Claims 1 and 30:
Claim 1. Ramabaja discloses a computer-implemented method of providing proof that a blockchain transaction exists on a blockchain (Ramabaja [0050] “In one aspect, the present disclosure provides a transaction verification system that, when in operation, verifies and provides tamper-proof recordation of data entities of one or more transactions in a blockchain”), wherein the method is performed by a Merkle proof entity configured to store a set of transaction identifiers of respective blockchain transactions (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A) but not to: i) publish new blockchain blocks to the blockchain (Ramabaja [0053] “In contradiction to the conventional systems, the transaction verification system of the present disclosure enable more efficient handling of storage hardware (i.e. an improved and efficient memory space management) of each computing node of the plurality of computing nodes while allowing an active participation of any computing node in sending and receiving transactions and their verification, without the need (or without any obligation) to store a local copy of the whole blockchain”; Ramabaja’s disclosure does not publish new blocks to the blockchain), and ii) submit blockchain transactions to the blockchain for storing (Ramabaja [0053] Ramabaja’s disclosure is not a full node that submits blockchain transactions), and wherein the method comprises: obtaining a target transaction identifier of a target blockchain transaction (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A), wherein the target transaction identifier forms part of the stored set of transaction identifiers (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A); obtaining a target Merkle proof for the target blockchain transaction (Ramabaja [0059-0060] and Figs. 3A-3B), wherein a corresponding target Merkle root is contained within a blockheader of the blockchain (Ramabaja [0059] “In accordance with an embodiment, each of the “M” distributed bloom filters is populated with Merkle roots of the “N” block headers.”); and outputting the target Merkle proof for use by a requesting party as proof that the target blockchain transaction exists on the blockchain (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”).
Claim 30 recites substantially the same content and is therefore rejected under the same rationales. Ramabaja 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” (Ramabaja [0001], [0035], claim 15).
Regarding Claim 2:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), wherein the Merkle proof entity does not store the full blockchain (Ramabaja [0053] “In contradiction to the conventional systems, the transaction verification system of the present disclosure enable more efficient handling of storage hardware (i.e. an improved and efficient memory space management) of each computing node of the plurality of computing nodes while allowing an active participation of any computing node in sending and receiving transactions and their verification, without the need (or without any obligation) to store a local copy of the whole blockchain”).
Regarding Claim 3:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), 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 (Ramabaja [0096-0097] and Fig. 4 obtaining the Merkle proof of the chunk is done by calculating the index for the specific transaction ‘E’ which leads to the answer C.sub.4; [0098] further example given of a multi-proof and how to determine the indices of a transaction whose presence is to be verified).
Regarding Claim 4:
Ramabaja further discloses the method of claim 3 (Ramabaja [0050]), comprising outputting the index to the requesting party (Ramabaja [0096-0097] and Fig. 4 obtaining the Merkle proof of the chunk is done by calculating the index for the specific transaction ‘E’ which leads to the answer C.sub.4; [0098] further example given of a multi-proof and how to determine the indices of a transaction whose presence is to be verified).
Regarding Claim 5:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), wherein said obtaining of the target transaction identifier comprises obtaining the target transaction identifier from the requesting party (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root”).
Regarding Claim 6:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), wherein said obtaining of the target transaction identifier comprises obtaining the target blockchain transaction (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network) and constructing the target transaction identifier based on the target blockchain transaction (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root”).
Regarding Claim 7:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), 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 (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059-0060] and Figs. 3A-3B).
Regarding Claim 8:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), 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 (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”), and wherein said obtaining of the target Merkle proof comprises extracting the target Merkle proof from a storage location (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”).
Regarding Claim 11:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), wherein the Merkle proof entity stores one or more Merkle roots (Ramabaja Fig. 3A-3B Merkle roots clearly disclosed; [0053] “The transaction verification system makes economical use of memory as only a bloom block (having only a distributed bloom filter of limited size and a few hashes, such as the plurality of root hashes of bloom trees)”; [0056] Merkle roots, [0059], [0061]), wherein each Merkle root is based on a respective subset of the stored set of transaction identifiers (Ramabaja Fig. 3A-3B Merkle roots clearly disclosed; [0053] “The transaction verification system makes economical use of memory as only a bloom block (having only a distributed bloom filter of limited size and a few hashes, such as the plurality of root hashes of bloom trees)”; [0056] Merkle roots, [0059], [0061]).
Regarding Claim 12:
Ramabaja further discloses the method of claim 11 (Ramabaja [0050]), comprising outputting, to the requesting party, the Merkle root based on the target transaction identifier (Ramabaja Fig. 3A-3B Merkle roots clearly disclosed; [0053] “The transaction verification system makes economical use of memory as only a bloom block (having only a distributed bloom filter of limited size and a few hashes, such as the plurality of root hashes of bloom trees)”; [0056] Merkle roots, [0059], [0061]).
Regarding Claim 13:
Ramabaja further discloses the method of claim 11 (Ramabaja [0050]), wherein the Merkle proof entity stores, for each of the one or more Merkle roots, a Merkle tree (Ramabaja Fig. 3A-3B Merkle roots clearly disclosed; [0053] “The transaction verification system makes economical use of memory as only a bloom block (having only a distributed bloom filter of limited size and a few hashes, such as the plurality of root hashes of bloom trees)”; [0056] Merkle roots, [0059], [0061]).
Regarding Claim 14:
Ramabaja further discloses the method of claim 13 (Ramabaja [0050]), wherein said obtaining of the target Merkle proof comprises extracting the target Merkle proof from a stored Merkle tree comprising the target transaction identifier (Ramabaja Fig. 3A-3B Merkle roots clearly disclosed; [0053] “The transaction verification system makes economical use of memory as only a bloom block (having only a distributed bloom filter of limited size and a few hashes, such as the plurality of root hashes of bloom trees)”; [0056] Merkle roots, [0059], [0061]).
Regarding Claim 15:
Ramabaja further discloses the method of claim 1 (Ramabaja [0050]), wherein the stored set of transaction identifiers comprises a plurality of subsets of transaction identifiers (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network where N is a specified range of the full node network; [0059] and Fig. 3A), wherein each subset of transaction identifiers comprises all transaction identifiers from a respective block of the blockchain (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network where N is a specified range of the full node network).
Regarding Claim 21:
Ramabaja further discloses the method of claim 15 (Ramabaja [0050]), wherein the Merkle proof entity stores, for each subset of transaction identifiers, a first blockchain transaction from the respective block (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network where N is a specified range of the full node network; [0059] and Fig. 3A).
Regarding Claim 22:
Ramabaja further discloses the method of claim 21 (Ramabaja [0050]), comprising: obtaining a first Merkle proof for the first blockchain transaction (Ramabaja [0059-0060] and Figs. 3A-3B), wherein the first Merkle proof is based on one or more of the stored set of transaction identifiers (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059-0060] and Figs. 3A-3B); 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 (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”; [0071]).
Regarding Claims 26 and 32:
Claim 26. Ramabaja discloses a computer-implemented method of obtaining proof that a blockchain transaction exists on a blockchain (Ramabaja [0050] “In one aspect, the present disclosure provides a transaction verification system that, when in operation, verifies and provides tamper-proof recordation of data entities of one or more transactions in a blockchain”), wherein a Merkle proof entity stores a set of transaction identifiers of respective blockchain transactions (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A), wherein the Merkle proof entity is configured to store a set of transaction identifiers of respective blockchain transactions (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A) but not to: i) publish new blockchain blocks to the blockchain (Ramabaja [0053] “In contradiction to the conventional systems, the transaction verification system of the present disclosure enable more efficient handling of storage hardware (i.e. an improved and efficient memory space management) of each computing node of the plurality of computing nodes while allowing an active participation of any computing node in sending and receiving transactions and their verification, without the need (or without any obligation) to store a local copy of the whole blockchain”; Ramabaja’s disclosure does not publish new blocks to the blockchain), and ii) submit blockchain transactions to the blockchain for storing (Ramabaja [0053] Ramabaja’s disclosure is not a full node that submits blockchain transactions), wherein the method is performed by a requesting party and comprises: sending, to the Merkle proof entity, a target blockchain transaction and/or a target transaction identifier of the target transaction (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059] and Fig. 3A); and obtaining, from the Merkle proof entity, a target Merkle proof for the target blockchain transaction (Ramabaja [0059-0060] and Figs. 3A-3B), wherein the Merkle proof is based on one or more of the stored set of transaction identifiers (Ramabaja [0054-0056] “N” block headers that contains transactions are requested from a full node network; [0059-0060] and Figs. 3A-3B).
Claim 32 recites substantially the same content and is therefore rejected under the same rationales. Ramabaja 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 (Ramabaja [0001], [0035], claim 15).
Regarding Claim 27:
Ramabaja further discloses the method of claim 26 (Ramabaja [0050]), comprising sending the target Merkle proof to a second requesting party as proof that the target blockchain transaction exists on the blockchain (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”).
Regarding Claim 28:
Ramabaja further discloses the method of claim 26 (Ramabaja [0050]), wherein the target blockchain transaction is a most recent one of a chain of blockchain transactions (Ramabaja [0055] “Initially, in order to initiate the pre-processing operation to obtain a corresponding bloom block for each computing node, block headers for recently added blocks are potentially requested from certain known full nodes that store such block headers”), wherein the requesting party has access to each transaction in the chain of blockchain transactions (Ramabaja [0055] “In accordance with an embodiment, the transaction verification system operates to cause each computing node of the plurality of computing nodes to execute the pre-processing operation to communicate a request of block headers up to a first defined constant value to other computing nodes of the plurality of computing nodes. In an example, a computing node requests “N” block headers within a specified range from a full node network, where “N” represents a system-wide constant (i.e. the first defined constant value)”), wherein the target Merkle proof is proof that each transaction in the chain of blockchain transactions exists on the blockchain (Ramabaja [0059] “To verify that a single transaction is present in the Merkle tree, a series of hashes are provided, which when are hashed with the transaction hash (e.g. a hash of transaction ID), a root hash of the Merkle tree is recreated. Moreover, this series of hashes is also known as a Merkle proof. Generally, a recipient (computing node) of the Merkle proof already has a copy of the root.”; Fig. 3A and [0094] “In an example, for Merkle tree 300A, a series of hashes: H.sub.4, H.sub.1,2 and H.sub.5,6,7,8 provides Merkle proof for verifying transaction T.sub.3.”).
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.
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