DETAILED ACTION
This office action is in response to claims filed 4 April 2024.
Claims 1-16 are pending.
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 .
Claim Objections
Claim 6 is objected to because of the following informalities: In line 7, “iii)” should read “iv)”. Appropriate correction is required.
Double Patenting
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1, 15, and 16 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/703,701. This is a provisional nonstatutory double patenting rejection.
Regarding claim 1 of the instant application, the following table highlights the similarities between that claim and claim 1 of the copending Application.
Instant Application
Copending Application
1. (Currently Amended) A computer-implemented method of downloading at least part of a blockchain block that comprises a plurality of blockchain transactions and a root of a Merkle tree for the block, the method comprising:
allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree; and
using one, some or all of the plurality of processing resources to download their respective subset of blockchain transactions.
1. A system configured to validate blockchain transactions in at least a portion of a blockchain block that has been assembled and is to be written to a blockchain, the blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the blockchain block, the system comprising:
at least one controller component that is a network device on a network wherein the at least one controller component is operative to:
i) receive the blockchain block from a sending resource across an electronic channel or network; and
ii) segment the blockchain block into a plurality of segments based on the Merkle tree for the blockchain block, each segment in the plurality of segments comprising a subset of the plurality of blockchain transactions that is represented by a segment hash that is an inner node of the Merkle tree for the blockchain block; and
a plurality of validating resources, each in networked communication with the at least one controller component and configured to validate one or more blockchain transactions to validate that they conform to transaction-level criteria of a blockchain protocol and comprising:
at least one processor associated with at least one portion of memory storing executable instructions that, as a result of execution by the at least one processor, causes or enables each respective validating resource to:
i) receive or download, from the at least one controller component via the network, a respective subset of the plurality of blockchain transactions
ii) perform pre-mining validation of the blockchain transactions in the respective subset of the plurality of blockchain transactions to assess whether they comply with the transaction-level criteria of the blockchain protocol; and
iii) if a non-compliant blockchain transaction is identified within the respective subset of the plurality of blockchain transactions, send an interrupt signal or other output to the at least one controller component or other validating resources in the plurality of validating resources to cease validation of their respective subsets of the plurality of blockchain transactions.
Claim Rejections - 35 USC § 112
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.
Claim 6 is 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 6,
In lines 1-2, the claim fails to particularly point out and distinctly claim what is meant by “wherein: validating the respective subset of blockchain transactions comprises”, because there is a lack of antecedent basis for this term. For examination purposes, the examiner will interpret this claim as being dependent upon claim 5, which contains the antecedent basis.
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)(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.
Claims 1-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by SNOW Pub. No.: US 2022/0006641 A1 (hereafter SNOW).
Regarding claim 1, SNOW teaches:
A computer-implemented method of downloading at least part of a blockchain block that comprises a plurality of blockchain transactions and a root of a Merkle tree for the block ([0039] The blockchain network server 28 may thus instruct the miner systems 22 a-g to generate individual, hierarchical nodal Merkle values 75, with lower tiered hash values as leaf/branch inputs and outputs in a Merkle-tree analysis. Each miner systems 22 a-g may thus calculatedly contribute to the final Merkle root 77 representing the encryption of the blockchain transactions 32. The miner systems 22 a-g, in other words, crowd-calculate, crowd-encrypt, or crowd-validate the Merkle values 75 and the Merkle root 77 (i.e., system comprises a root of a Merkle tree that is calculated based on a plurality of hashed blockchain transactions)), the method comprising:
allocating respective subsets of the blockchain transactions to a plurality of processing resources, wherein each respective subset provides a respective portion of the Merkle tree and is represented by a respective inner node of the Merkle tree ([0003] A blockchain environment may utilize accumulator devices that collect nodal Merkle values calculated by individual miners and other nodal machines. Any nodal machine (such as a miner system) need only retrieve Merkle child values as inputs. The nodal machine may then determine a hierarchical Merkle value based only on the Merkle child values provided as the inputs. [0041] Whatever the accumulator device 79 (again illustrated as the blockchain network server 28), the accumulator device 79 may collect/accumulate the Merkle values 75 and build the Merkle tree (e.g., using the hash values 64 reported by each miner system 22), perhaps according to its encryption/validation share 73 of the blockchain transactions 32. Moreover, Merkle leaf values, branch values, and/or the Merkle root 77 (i.e., leaf and branch values represent “inner nodes”) may be distributed to other miner systems 22 or other blockchain nodes. [0041] The database 81 may thus map the miner systems 22 to their corresponding nodal Merkle values 75 (and final Merkle root 77) (i.e., each nodal machine, representing “processing resources” is mapped, or assigned, or “allocated” a Merkle value, representing a “portion” of a Merkle tree corresponding to blockchain transactions representing a portion or “subset” of the total number of transactions in the blockchain)); and
using one, some or all of the plurality of processing resources to download their respective subset of blockchain transactions ([0003] The nodal machine need only download the piece, segment, or portion of interest. [0085] Any of the randomized Merkle values may thus be quickly and simply conveyed via the communications network 26, without downloading and sending the individual blockchain transactions 32, the block 40 of data, and/or larger portions of the blockchain 56).
Regarding claim 2, SNOW further teaches:
one, some or all of the plurality of processing resources sending their respective subset of blockchain transactions to a central storage location ([0035] FIG. 4 illustrates an accumulation of encryption outputs. The blockchain network server 28 (i.e., “central storage location”) may receive multiple micro-hashing outputs 62 reported by any of the multiple miner systems (e.g., 22 a-d) that are credentialed members of the blockchain environment 20).
Regarding claim 3, SNOW further teaches:
the respective inner node of the Merkle tree has a respective position in the Merkle tree, and wherein the method comprises: arranging the respective subsets of blockchain transactions based on the respective position of the respective inner node of the Merkle tree ([0041] Whatever the accumulator device 79 (again illustrated as the blockchain network server 28), the accumulator device 79 may collect/accumulate the Merkle values 75 and build the Merkle tree (e.g., using the hash values 64 reported by each miner system 22), perhaps according to its encryption/validation share 73 of the blockchain transactions 32. Moreover, Merkle leaf values, branch values, and/or the Merkle root 77 (i.e., blockchain transactions correspond to leaf or branch values of a Merkle tree, representing “inner nodes” having “positions” on the tree)).
Regarding claim 4, SNOW further teaches:
one, some or all of the processing resource generating a respective candidate inner node of the Merkle tree based on the respective downloaded subset of blockchain transactions ([0040] Different miner systems 22 may be assigned to determine a corresponding cryptographic hash of any leaf or branch (using child nodes as inputs). Any miner system 22 need only be fed or given the lower-tiered, child inputs. The miner system 22 need not store and encrypt every Merkle nodal value. Exemplary embodiments may distribute the blockchain storage and may distribute the validation of processes. Exemplary embodiments thus permit unbounded numbers of the blockchain transactions 32 on the blockchain 56. Validation of the any data (such as the blockchain transactions 32) may occur locally in the blockchain 56. Once the data is validated, streams of the hash values 64 may be passed to any accumulator device 79 (i.e., prior to validation, each leaf or branch represents a “candidate inner node of a Merkle tree”, which is downloaded to each miner system for validation)); and further comprising at least one of the following:
verifying that the respective candidate inner node matches the respective inner node of the Merkle tree ([0039] The blockchain network server 28 may thus instruct the miner systems 22 a-g to generate individual, hierarchical nodal Merkle values 75, with lower tiered hash values as leaf/branch inputs and outputs in a Merkle-tree analysis. Each miner systems 22 a-g may thus calculatedly contribute to the final Merkle root 77 representing the encryption of the blockchain transactions 32. [0056] The proof-of-work algorithm 52, for example, may have to compare the hash value(s) 64 to a target hash value 82. The target hash value 82 may be any minimum or maximum hash value that must be satisfied. If the hash value 64 is less than or perhaps equal to the target hash value 82, then the proof-of-work algorithm 52 has perhaps solved the mathematical problem or puzzle 54 (i.e., system validates, or “verifies” Merkle values and roots of a Merkle tree by comparing candidate Merkle leaf and branch “inner” nodes represented by hash values to target hash values to identify matches)); and/or;
verifying that the respective candidate inner node is a node of the Merkle tree by performing a Merkle proof based on the root of the Merkle tree ([0039] The miner systems 22 a-g, in other words, crowd-calculate, crowd-encrypt, or crowd-validate the Merkle values 75 and the Merkle root 77 (i.e., validating Merkle values represent “verification” of the Merkle values as nodes of a Merkle tree including leaf or branch “inner” nodes, and validating the Merkle root represents performing a “Merkle proof”)); and/or
sending the respective candidate inner node of the Merkle tree to one or more other processing resources ([0028] The winning or successful miner system (say 22 a) may timestamp the block 40 of data and broadcast the block 40 of data, the timestamp, the proof-of-work result 42, and/or the mathematical problem or puzzle 54 to other miners 22 b-d in the blockchain environment 20. The miner system 22 a, for example, may broadcast a hash value representing the block 40 of data, and the other miners begin working on a next block in the blockchain 56 (i.e., hash values broadcast to other processing resource represents Merkle values, or “inner nodes”)).
Regarding claim 5, SNOW further teaches:
using one, some or all of the plurality of processing resources to validate their respective subset of blockchain transactions ([0039] The blockchain network server 28 may thus instruct the miner systems 22 a-g to generate individual, hierarchical nodal Merkle values 75, with lower tiered hash values as leaf/branch inputs and outputs in a Merkle-tree analysis. Each miner systems 22 a-g may thus calculatedly contribute to the final Merkle root 77 representing the encryption of the blockchain transactions 32. The miner systems 22 a-g, in other words, crowd-calculate, crowd-encrypt, or crowd-validate the Merkle values 75 and the Merkle root 77 (i.e., multiple miner systems, representing plural processing resources, validate respective blockchain transactions 32)).
Regarding claim 6, SNOW further teaches:
validating the respective subset of blockchain transactions comprises:
i) validating and/or verifying at least one blockchain transaction ([0035] Each miner system 22 a-d, in other words, may contribute an encryption or validation share 73 of the total encryption/validation processing that is required to mine the blockchain transactions 32 written to, recorded to, and/or associated with the block 40 of data. The multiple miner systems 22 a-d may thus pool their computing resources to verify blockchain transactions 32); and/or
ii) performing a Simplified Payment Verification process; and/or iii) confirming whether a given blockchain transaction is contained within the blockchain block; and/or iii) generating a hash of at least one of the blockchain transactions, using the hash to construct a Merkle path and/or checking whether the hash matches a transaction identifier in a header of the blockchain block (the limitations of this claim were satisfied by rejecting i) above).
Regarding claim 7, SNOW further teaches:
at least one of the respective subsets of blockchain transactions comprises a respective identifier that is associated with, identifies and/or represents the respective subset ([0041] The database 81 may thus have entries that relate each blockchain transaction 32 to its corresponding subset 60, group 68, validation rule 69, share 73, and the Merkle value(s) 75 calculated by the corresponding miner system 22 (such an Internet protocol address or other alphanumeric miner identifier 83) using the blockchain transaction 32. In plain words, the database 81 stores each blockchain transaction 32, its encrypting miner system 22, and its corresponding Merkle value 75. The database 81 may thus map the miner systems 22 to their corresponding nodal Merkle values 75 (and final Merkle root 77). The accumulator device 79 may thus easily perform database lookups to identify and retrieve any of the nodal Merkle values 75 associated with encrypting the blockchain transactions 32 and/or the block 40 of data (i.e., transactions representing “subsets” are identifiable within the database, and thus have identifiers/identities, or, alternatively, are “associated with” an IP address or alphanumeric identifier of a miner allocated to process the subset of transactions)).
Regarding claim 8, SNOW further teaches:
the respective identifier facilitates calculation of a respective position of the at least one respective subset within the Merkle tree ([0041] In plain words, the database 81 stores each blockchain transaction 32, its encrypting miner system 22, and its corresponding Merkle value 75. The database 81 may thus map the miner systems 22 to their corresponding nodal Merkle values 75 (and final Merkle root 77). The accumulator device 79 may thus easily perform database lookups to identify and retrieve any of the nodal Merkle values 75 associated with encrypting the blockchain transactions 32 and/or the block 40 of data (i.e., at least the encrypting miner system 22 represents an identifier that reflects a position of the subset of transactions encrypted by that particular miner system in the Merkle tree, according to Fig. 7)).
Regarding claim 9, SNOW further teaches:
the respective identifier is based on the respective inner node of the Merkle tree ([0041] In plain words, the database 81 stores each blockchain transaction 32, its encrypting miner system 22, and its corresponding Merkle value 75. The database 81 may thus map the miner systems 22 to their corresponding nodal Merkle values 75 (and final Merkle root 77). The accumulator device 79 may thus easily perform database lookups to identify and retrieve any of the nodal Merkle values 75 associated with encrypting the blockchain transactions 32 and/or the block 40 of data (i.e., each database identity is associated with a respective Merkle value that corresponds to leaf and branch (inner) nodes of a Merkle tree)).
Regarding claim 10, SNOW further teaches:
the respective identifier comprises part of the respective inner node of the Merkle tree ([0041] In plain words, the database 81 stores each blockchain transaction 32, its encrypting miner system 22, and its corresponding Merkle value 75. The database 81 may thus map the miner systems 22 to their corresponding nodal Merkle values 75 (and final Merkle root 77). The accumulator device 79 may thus easily perform database lookups to identify and retrieve any of the nodal Merkle values 75 associated with encrypting the blockchain transactions 32 and/or the block 40 of data (i.e., each database identity includes a respective Merkle value that corresponds to leaf and branch (inner) nodes of a Merkle tree)).
Regarding claim 11, SNOW further teaches:
the step of allocating the respective subset of blockchain transactions to the plurality of respective processing resources comprises matching the respective subsets to respective processing resources based on respective identifiers associated with the respective subsets of transactions ([0036] The blockchain network server 28 may send T1 and T2 to the miner system 22 a, or the blockchain network server 28 may instruct the miner system 22 a to retrieve T1 and T2 from any networked device, resource, or location. So, even though block 40 of data may contain the eight (8) blockchain transactions 32 (e.g., T1-T8), the miner system 22 a need only utilize its processor and memory resources to encrypt or hash T1 and T2 of the blockchain transactions 32. [0041] The database 81 may thus have entries that relate each blockchain transaction 32 to its corresponding subset 60, group 68, validation rule 69, share 73, and the Merkle value(s) 75 calculated by the corresponding miner system 22 (such an Internet protocol address or other alphanumeric miner identifier 83) using the blockchain transaction 32 (i.e., T1 and T2 are allocated, or “matched” to a miner based at least partially on and identification of T1 and T2. Alternatively, the subsets of transactions are at least associated with IP addresses or alphanumeric miner identifiers allocated to process the subsets)).
Regarding claim 12, SNOW further teaches:
the Merkle tree comprises a binary tree or a mesh structure of hashes of the plurality of blockchain transactions (FIG. 7 illustrates a Merkle tree as a binary tree where each node has at most two children).
Regarding claim 13, SNOW further teaches:
identifying and/or determining the subsets of blockchain transactions within the plurality of blockchain transactions ([0035] The blockchain network server 28 may form (i.e., “identify/determine”) multiple portions or subsets 60 of the blockchain transactions 32 by segregating separate groups 68, with each individual blockchain transaction 32 assigned to or associated with a different group 68. Each group 68 may contain at least one single blockchain transaction 32, but each group may be associated with two (2) or more blockchain transactions 32).
Regarding claim 14, SNOW further teaches:
at least one of the plurality of processing resources is, or comprises, a virtual machine ([0133] The miner system 22 may outsource or subcontract mining operations to a virtual machine (or “VM”)), a server ([0040] The accumulator device 79, however, may be any client, server, or device having access permission to the blockchain…the accumulator device 79 may be any miner system 22 that locally functions as the accumulator), a GPU-based computing resource ([0066] Exemplary embodiments thus force miners to choose the CPU 36, as a faster GPU/ASIC provides no performance/speed gain (i.e., while not providing any performance/speed gain, GPUs/ASICs may still operate as miner systems )), or a multiprocessor system ([0132] The miner system 22 has the hardware processor capability and performance (e.g., clock speed, processor core(s)/thread(s) count, cycles, the on-board cache memory 100, thermal profile, electrical power consumption, and/or chipset) to mine in both blockchain environments 20 a and 20 b (i.e., miner system comprises a multi-core, or “multiprocessor” system)).
Regarding claims 15 and 16, they comprise limitations similar to claim 1, and are therefore rejected for similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SCHMID Pub. No.: US 2022/0067147 A1 discloses nodes which group transactions into blocks, and where transactions are linked under a Merkle tree.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/Primary Examiner, Art Unit 2195
Prosecution Insights