Detailed Action
Acknowledgements
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 in reply to the preliminary amendment filed on September 12, 2025.
Claim 19 is cancelled.
Claim 21 is added.
Claims 1-18 and 20-21 are pending.
Claims 1-18 and 20-21 are examined.
This Office Action is given Paper No. 20260721 for references purposes only.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The Information Disclosure Statement filed on September 12, 2025 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
Claim Objections
Claim 14 is objected to because it recites “a digital signature of an author and/or approver of said data.” Examiner assumes that Applicant intended “the digital signature of the author and/or the approver of said data.” Appropriate correction is required.
Claim 15 is objected to because it recites “a history of the allocated resources.” Examiner assumes that Applicant intended “a history of allocated resources.” Appropriate correction is required.
Claim Rejections - 35 USC § 112b
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 8 recites “data, processed data and/or the digital signature with a blockchain transaction.” This phrase is vague and indefinite because it’s unclear whether this refers to the previously recited “the data, the processed data and/or the digital signature with the blockchain transaction”, or to “second data, second processed data and/or the digital signature with a second blockchain transaction.” For purposes of applying the prior art only, Examiner will interpret as “the data, the processed data and/or the digital signature with the blockchain transaction.”
Claim Rejections - 35 USC § 101
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.
Claims 1-18 and 20-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A Prong 1: The claims recite an abstract idea of validating data in a transaction, which is a mental process (i.e. concepts performed in the human mind including observations, evaluations, judgments, and opinions).
Claim 1, representative of claims 6 and 20, includes the following limitations:
Associating data with a transaction, wherein said data is represented in a tree structure;
Processing a path of the tree structure that includes the data;
Processing a digital signature of an author or approver of the data;
Validating at least one of: the data, the signature, and the blockchain transaction as part of the tree structure.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
Blockchain.
These additional elements are not indicative of integration into a practical application because:
They generally link the use of the judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h).
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional element of a “blockchain” generally links the use of the judicial exception to a particular technological environment or field of use, and does not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional element of a “blockchain” is re-evaluated to determine whether it constitutes significantly more. Examiner finds that the additional element of a “blockchain” is merely an attempt to limit the use of the abstract idea to a particular technological environment. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05(h).
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the claim does not amount to significantly more than the exception.
The dependent claims fail to cure this deficiency and are rejected accordingly.
Claim 2 recites the signature is associated with the blockchain transaction, which is merely describing data and further defining the abstract idea.
Claim 3 recites the data and the signature are combined, which is merely describing data and further defining the abstract idea.
Claim 4 recites determining the signature is part of the tree structure, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 5 recites storing at least one of the data, the signature, the tree structure, and the blockchain transaction in an allocated resource, which is well-understood, routine, and conventional. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 and MPEP 2106.05(d).
Claim 11 recites the data is represented by a node or a leaf, which is merely describing data and further defining the abstract idea.
Claim 12 recites a hash of a root node is stored in the blockchain transaction, which is well-understood, routine, and conventional. See Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 and MPEP 2106.05(d).
Claim 13 recites the tree structure represents a web address and the data is content on a web page, which is merely describing data and further defining the abstract idea.
Claim 14 recites the content is signed by a digital signature, which is merely describing data and further defining the abstract idea.
Claim 15 recites the blockchain transaction includes at least one of a history of the tree structure and a history of the allocated resource, which is merely describing data and further defining the abstract idea.
Claim 16 recites the blockchain transaction is used to identify the allocated resource, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 17 recites the different types of information that can comprise the blockchain transaction, which is merely describing data and further defining the abstract idea.
Claim 18 recites, for at least a portion of the blockchain transaction, at least one of: validating the transaction, performing a simplified payment verification, confirming the transaction is contained within the blockchain block, determining a Merkle proof, and a proof that the transaction is part of the tree structure, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 21 recites a hash of the blockchain transaction is used to determine a key, which is insignificant extra-solution activity (e.g. mere data gathering). See Ultramercial, Inc. v. Hulu, 772 F.3d 709, 715.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-18 and 20-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Davies et al. (US 2023/0015569) in view of Day et al. (US 2017/0295180).
Claims 1, 20
Davies discloses:
associating data (data block D1, see [0117]) with a blockchain transaction (Tx) (blockchain transaction, see [0132]), wherein said data is represented in a tree structure (see figure 5),
processing a path (Merkle path, see [0120]) of the tree structure that includes the data;
processing a digital signature (check signature matches the expected signature, see [0041]);
validating that at least one of: the data (data set is confirmed, see [0129-0130]), the digital signature and the blockchain transaction (Tx) is a part of the tree structure.
Davies does not disclose:
of an author and/or approver of said data.
Day teaches:
of an author and/or approver (requestor, see [0043]) of said data.
Davies discloses associating data with a blockchain transaction, processing a path, processing a digital signature, and validating. Davies does not disclose an approver, but Day does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the data structure for efficiently verifying data of Davies with the approver of Day because 1) a need exists for an improved hash tree data structure that can be used to efficiently verify a received data block (see Davies [0002]); and 2) a need exists for controlling access of persons, things, and other entities (see Day [0001]). An approver can be used for verifying a received data block.
Claim 2
Furthermore, Davies discloses:
the digital signature (signature, see [0041]) is associated with the blockchain transaction (transaction, see [0041]).
Claim 3
Furthermore, Davies discloses:
the data and the digital signature are combined (input of the transaction also comprises the signature, see [0038]).
Claim 4
Furthermore, Davies discloses:
validating comprises determining that the digital signature (check signature matches the expected signature, see [0041]) is a part of the tree structure.
Claims 5, 10
Furthermore, Davies discloses:
processing and/or storing at least one of: the data, the digital signature, the tree structure and the blockchain transaction (Tx) in an allocated resource (storage node, see [0057-0058]).
Claim 6
Davies discloses:
processing data (data block D1, see [0117]) to produce processed data and associating said data and/or said processed data with a digital signature (signature, see [0041]);
representing said data and/or the processed data in a tree structure (see figure 5);
associating at least one of the data (data set, see [0129-0130]), the processed data and/or the digital signature with a blockchain transaction (Tx) (blockchain transaction, see [0132]), which is represented in the tree structure (see figure 5); and
recording (recording, see claim 12) of at least one of the data, processed data, the digital signature, the blockchain transaction (Tx) and the tree structure on a blockchain.
Davies does not disclose:
of an author and/or approver.
Day teaches:
of an author and/or approver (requestor, see [0043]).
Davies discloses processing data, representing data in a tree structure, associating the data with a blockchain transaction, and recording the data. Davies does not disclose an approver, but Day does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the data structure for efficiently verifying data of Davies with the approver of Day because 1) a need exists for an improved hash tree data structure that can be used to efficiently verify a received data block (see Davies [0002]); and 2) a need exists for controlling access of persons, things, and other entities (see Day [0001]). An approver can be used for verifying a received data block.
Claim 7
Furthermore, Davies discloses:
processing an update to the data to produce updated processed data (nodes of original tree are updated, see [0265]), and representing the updated processed data in a second tree structure (see figure 9).
Claim 8
Furthermore, Davies discloses:
the processed data is stored in a node (storage node, see [0057-0058]) of the tree structure or the second tree structure, and
wherein each node of the tree structure or the second tree structure comprises at least one of data (original data set, see figure 9), processed data (new data set, see figure 9) and/or the digital signature with a blockchain transaction (Tx), which is represented in the tree structure (see figure 9).
Claim 9
Furthermore, Davies discloses:
processing at least one of the data, the processed data, the digital signature, the blockchain transaction (Tx) and the tree structure to produce a hash (calculate unique hash values, see [0266]) thereof, and storing said hash on the blockchain (blockchain, see [0267]).
Claim 11
Furthermore, Davies discloses:
the data is represented by a node (node, see [0265], figure 9) or a leaf in the tree structure, and hashed to create a hash tree (hash tree, see [0267]).
Claim 12
Furthermore, Davies discloses:
a hash of a root node (hash value of root node, see [0270]) of the tree structure is stored in the blockchain transaction (Tx) on the blockchain (blockchain, see [0267]).
Claim 13
Furthermore, Davies discloses:
wherein the tree structure comprises at least one of: a top-level domain (see figure 11); a second-level domain; a subdomain; and a subdirectory.
Furthermore, Day teaches:
the tree structure (hash tree data structure, see [0085]) represents a web address and the data is content on a web page (web site, see [0086, 0098]) of the web address and accessible via a path of the web address, said path providing a link to content.
Claim 14
Furthermore, Day teaches:
the content of each web page is signed by a digital signature (signature, see [0101-0104]) of an author and/or approver of said data.
Claim 15
Furthermore, Davies discloses:
the blockchain transaction includes at least one of:
a history of the or each tree structure from which the blockchain transaction originated (each block comprises a block pointer pointing back to the previously created block, see [0055]); and
a history of the allocated resources in which the blockchain transaction was stored,
wherein said history enables validation of at least one of: the data, processed data, the digital signature, the blockchain transaction (Tx) and the tree structure on a blockchain.
Claim 16
Furthermore, Davies discloses:
the blockchain transaction (Tx) is used to identify and/or allocate the allocated resource (storage node, see [0057-0058]).
Claim 17
Furthermore, Davies discloses:
the blockchain transaction comprises at least one of:
a Merkle Tree (Merkle tree, see [0133], figure 5) of the block in which said transaction (Tx) is recorded;
the Merkle root the block in which said transaction (Tx) is recorded;
a Merkle path, which enables the determination of the value for the Merkle root for the block in which said transaction (Tx) is recorded, from a hash of said blockchain transaction (Tx);
a Merkle proof;
a block identifier (block ID) associated with the blockchain block
a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions within the blockchain block;
a function of the block identifier (block ID) and the transaction identifier (TxID); and
a concatenation of the block identifier (blockID) and the transaction identifier (TxID).
Claim 18
Furthermore, Davies discloses:
for at least a portion of the blockchain transaction (Tx), at least one of:
validating and/or verifying said blockchain transaction (Tx);
performing at least part of a Simplified Payment Verification (SPV) process for said blockchain transaction;
confirming whether the blockchain transaction (Tx) is contained within the blockchain block;
determining a Merkle proof (Merkle proof, see [0133]) for said blockchain transaction (Tx); and
a proof that the associated blockchain transaction is part of the tree structure, by at least one of using a hash of the root of the tree structure and a path that enables the determination of the hash of the root for the tree structure in which said associated blockchain transaction is recorded, from a hash of said blockchain transaction.
Claim 21
Furthermore, Davies discloses:
a hash (hash, see [0067, 0069]) of the blockchain transaction is used to determine a key (key, see [0067, 0069]), wherein the key determines the allocated resource.
Claim Interpretation
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure (see attached form PTO-892).
Ghosh et al. (US 2025/0191067) discloses a tokenized structured exchange tracking.
Conclusion
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from Examiner should be directed to Chrystina Zelaskiewicz whose telephone number is 571-270-3940. Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Neha Patel can be reached at 571-270-1492.
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://portal.uspto.gov/external/portal/pair <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).
/CHRYSTINA E ZELASKIEWICZ/Primary Examiner, Art Unit 3699
Prosecution Insights