DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed 4/3/2026.
Claim 1 is currently amended. Claims 21 and 22 are new.
Claims 1, 5-6, 13, 15, 17, 18, and 20-22 are currently pending.
Claims 1, 5-6, 13, 15, 17, 18, and 20-22 have been examined.
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 Amendment
In the April 3, 2026 Claim Amendments and with respect to claim 1, Applicants removed language from the claim without showing appropriate markup.
37 C.F.R. §1.121 as discussed in MPEP §714 II. C. sets forth the manner of making claim amendments. In particular, MPEP §714 II. C. states that amended claims must show removed language using strikethrough.
Because the words “to form a sharded network” were removed from the third to last limitation of claim 1, and the words “at least one” were removed from the last two limitations of claim 1 in the 12/2/2025 claim set without showing markup, the April 3, 2026 Claim Amendments are a Non-Compliant Amendment. See MPEP §714 II. F.
Because this application is not in condition for allowance, because the error noted above is considered an error that would not otherwise prevent the subsequent examination of this application, and to show a good faith effort by the Examiner to advance prosecution, the Claim Amendments are being examined.
However, Applicants are given actual notice that should any future amendment be non-compliant because the amendment does not (for any reason) comply with 37 C.F.R. §1.121 (as discussed in MPEP §714), the amendment will be considered a non-compliant amendment and the Examiner will issue a “Notice of Non-Compliant Amendment (37 CFR 1.121)” See USPTO Form PTOL-324.
Notwithstanding the issues above, the Claim Amendments are being examined and an office action on the merits is set forth below.
Claim Objections
Claim 1 is objected to because it uses “UXTO” throughout the claim whereas it should be “UTXO”.
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.
Claim 22 is 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.
Claim 22 recites:
The computer-implemented method of claim 1, wherein the identified shard of the first plurality of shards is a shard of the first plurality of shards associated with the previous transaction referred to in the output of the U[TX]O.
There is no support for the language “previous transaction referred to in the output”. It is not typical in blockchain technology for a transaction output to contain a reference to a previous transaction and the application does not provide any description of such an output. In typical blockchain technology, only inputs contain transaction references.
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.
Claim 22 is additionally rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 22 recites:
The computer-implemented method of claim 1, wherein the identified shard of the first plurality of shards is a shard of the first plurality of shards associated with the previous transaction referred to in the output of the U[TX]O.
“Output of the UTXO” is an unclear phrase. A UTXO is an unspent output, and it’s not clear what an output of an output is. The specification does not have any reference to an output of a UTXO to explain what this refers to. For purposes of examination, the claim is interpreted as though it read “input of the transaction containing the UTXO” instead of “output of the UTXO”, as this appears to be the most likely intended form of the claim.
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 (i.e., changing from AIA to pre-AIA ) 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 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, 5-6, 13, 15, 17, 18, 20, 22 are rejected under 35 U.S.C. 103 as being unpatentable over Kokoris-Kogias, “OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding” (2017), in view of Pedro Franco, “Understanding Bitcoin” (2015), in view of Reddit.com “Are there any plans of SHARDING”.
Regarding claim 1
Kokoris-Kogias teaches:
A computer-implemented method for validating a blockchain transaction associated with a blockchain network, wherein the blockchain network is partitioned into a plurality of shards, each shard comprising at least one member node, and wherein each node in the blockchain network is a member of least one shard among the plurality of shards, the method comprising steps of: {Page 2 paragraph 4 “To evaluate OmniLedger, we implemented a prototype in Go on commodity servers” (computer-implemented) and abstract “distributed ledger that […] ensures security and correctness by using a […] protocol for choosing large, statistically representative shards that process transactions” (partitioned into a plurality of shards) and page 3 III(A) “validators [nodes] are evenly distributed across m shards”}
responsive to receiving a given transaction at a node, determining that at least one UTXO associated with the node is referenced by at least one input of the blockchain transaction, wherein the node is associated with a set of UTXOs that relate to one or more transactions allocated to each shard of which the node is a member; {Page 6, Steps 1-2 “A client creates a cross-shard transaction (crossTX for short) whose inputs spend UTXOs of some input shards […] The client gossips the cross-TX and it eventually reaches all ISs [received at a node]. All input shards associated with a given cross-TX proceed as follows.”}
Kokoris-Kogias does not explicitly teach determining. However, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention that the claimed step of determining is implicit in the process of Kokoris-Kogias. The input shards are proceeding to process the cross-TX. The term input shard is being used by Kokoris-Kogias to refer to the set of nodes that make up the shard associated with a UTXO referenced by an input in the cross-TX. Since the method of Kokoris-Kogias calls for the input shards to process the cross-TX, Kokoris-Kogias at least implicitly teaches determining that a node belongs to the input shard.
Additionally, Kokoris-Kogias appendix C teaches a method of determining which shard a UTXO is associated with: “the common practice is to assign UTXOs to shards, based on the first bits of their hash.” On page 4, “Afterwards, all registered validators [nodes] […] determine their assignment to one of the SLedger’s shards”. Since Kokoris-Kogias teaches a specific method of determining what shard a UTXO is associated with, and a method of determining what shard a node is a member of, it implicitly teaches a method of determining that a node is associated with a UTXO.
based on a determination that the transaction is valid, adding the transaction to a mempool associated with the node; {Page 6 step 2 “If the transaction is valid, the leader marks within the state that the input is spent, logs [adds] the transaction in the shard’s ledger [mempool]”}
propagating the transaction to other member nodes of the at least one shard of which the node is a member; {Fig. 2; Page 6 step 1 “the client gossips [propagates] the cross-TX and it eventually reaches all ISs [member nodes of the at least one shard]”}
based on a determination that the at least one input of the given transaction is associated with at least one shard of which the node is a member, performing a validation check on at least one input […]; {Page 6, Step 2 “All input shards associated with a given cross-TX proceed as follows. First, to decide whether the inputs can be spent, each [input shard] leader validates the transaction within his shard.”}
“Based on a determination that the at least one input of the given transaction is associated with a shard that the node is a member of” is interpreted as requiring that the determining step occurs first.
wherein the first allocation scheme comprises, for each U[TX]O to be allocated to a shard of the first plurality of shards:
determining an input of the U[TX]O and an output of a previous transaction to which the input of the U[TX]O refers;
identifying a shard of the first plurality of shards; and
allocating the U[TX]O and the previous transaction to the identified shard; {page 6 “1) Initialize. A client creates a cross-shard transaction (cross TX for short) whose inputs spend UTXOs of some input shards (ISs) and whose outputs create new UTXOs in some output shards (OSs). The client gossips the cross-TX and it eventually reaches all ISs. 2) Lock. All input shards associated with a given cross-TX proceed as follows. First, to decide whether the inputs can be spent, each IS leader validates the transaction within his shard.”}
wherein the second allocation scheme comprises, for each U[TX]O allocated to the identified shard:
determining a shard number associated with a shard of a second plurality of shards to which the UTXO is to be allocated, the shard number being determined based on a transaction identifier of the U[TX]O and a total number of shards, n, and wherein the second plurality of shards shard from the identified shard; and
allocating that U[TX]O to the shard of the second plurality of shards corresponding to the determined shard number. {Appendix C “the common practice is to assign UTXOs to shards, based on the first bits of their hash [transaction identifier]. For example, one shard manages all UTXOs whose first bit is 0, and the second shard all UTXOs whose first bit is 1.”}
The specification does not provide a definition of “allocate”. However, the specification states “A user who is a member of fewer than all shards requires less storage space to store all of the transactions allocated to the shards of which the user is a member.” Based on the way the word “allocate” is used in the specification, data is considered to be allocated to a shard if it is stored or processed by the nodes which are members of that shard.
The method taught by Kokoris-Kogias (OmniLedger) satisfies both claimed allocation schemes because OmniLedger allocates each transaction to potentially multiple shards. In OmniLedger, outputs are assigned to shards based on their hash (see Appendix C “the common practice is to assign UTXOs to shards, based on the first bits of their hash”). Inputs are assigned to shards based on the output that they reference, and transactions are processed and stored by all shards to which any of their inputs or outputs are assigned (see page 6 “A client creates a cross-shard transaction […] whose inputs spend UTXOs of some input shards (ISs) and whose outputs create new UTXOs in some output shards (OSs). The client gossips the cross-TX and it eventually reaches all ISs.”). The shards which process and store any given transaction are therefore determined by both the hash values of the transaction data (second allocation scheme) and by the shards to which the referenced UTXOs belong (first allocation scheme).
Kokoris-Kogias does not teach, however Franco teaches:
based on a determination that the at least one input of the given transaction is associated with at least one shard of which the node is a member, performing a validation check on at least one input using validity data of the at least one UTXO; {Page 80, 6.1 paragraph 1 “Every transaction output creates a Mathematical puzzle that must be solved in order to spend the output. The puzzle to unlock the funds and the solution to the puzzle are represented by two scripts [validity data]”}
Kokoris-Kogias teaches validating inputs using the UTXO model, which Franco shows includes using scripts associated with the input. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the two scripts of Franco with the validation of OmniLedger because Kokoris-Kogias says OmniLedger uses the UTXO model introduced by Bitcoin and Franco is describing that model. (Kokoris-Kogias Section II(B) “OmniLedger adopts the unspent transaction output (UTXO) model […] The UTXO model was introduced by Bitcoin”)
Kokoris-Kogias in view of Franco does not teach, however Reddit.com “Are there any plans of SHARDING” teaches:
applying a first sharding method to partition the blockchain network into a first plurality of shards according to a first allocation scheme, {page 1 “I recently saw that another major coin is trying to solve on chain capacity with sharding and i find the concept very interesting, and was wondering if there are any plans or if there was ever any discussion about implementing sharding for the bitcoin blockchain? It could improve the on-chain capacity a lot, and would not compromise the security of the blockchain with the actual size of the network and it also would help keeping the 1 mb blocksize”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the sharding method of Kokoris-Kogias in view of Franco to a blockchain as taught by Reddit.com because it would increase scalability of the blockchain network.
subsequently applying at least one additional sharding method to further partition the blockchain network, according to a second allocation scheme,
This step is merely taking a blockchain network which has been subdivided into shards and further subdividing into more shards. Since merely applying the sharding method of OmniLedger a second time would satisfy this limitation, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to do so in order to further increase scalability. See MPEP 2144.04 “duplication of parts”.
Regarding claim 2
Kokoris-Kogias teaches:
The method of claim 1, further comprising a step of communicating, to a member node of the shard, a request from a node seeking shard membership information. (Kokoris-Kogias: See page 12 “Recall, that during an epoch transition, a new validator [node] first crawls [requests] the identity blockchain [shard membership information]”.)
Regarding claims 5 and 6
Claim 5 is for a system to perform the method of claim 1. Claim 6 is for a computer-readable storage medium with instructions to perform the method of claim 1. These claims are substantially similar to claim 1 and are treated the same with respect to prior art rejections.
Regarding claim 13
Kokoris-Kogias does not teach the following, however Franco further teaches:
The method of claim 1, wherein the validity data comprises an unlocking script and a locking script. (See claim 1 rejection, performing step, above. See also Franco page 80, 6.1 paragraph 1 “Every transaction output creates a Mathematical puzzle that must be solved in order to spend the output. The puzzle to unlock the funds [locking script] and the solution to the puzzle [unlocking script] are represented by two scripts.”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the validation of Kokoris-Kogias with the locking and unlocking scripts of Franco because Kokoris-Kogias says it adopts the UTXO model that was introduced by bitcoin, and Franco describes the two scripts are used in the UTXO model of the bitcoin protocol. The locking and unlocking scripts of Franco would perform the same function in the distributed ledger protocol of Kokoris-Kogias as they do in Bitcoin.
Regarding claim 15
Kokoris-Kogias does not teach the following, however Franco further teaches:
The method of claim 1, wherein performing the validity check comprises determining that the blockchain transaction will not result in a double spend. (See claim 1 rejection, performing step, above. See also Franco page 78, last paragraph “To verify that a transaction is valid, a node follows these steps: It checks that the previous outputs referenced by the transaction exist, and that they haven’t been spent.”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the validation of Kokoris-Kogias with the double spending validation check of Franco because Kokoris-Kogias says it adopts the UTXO model that was introduced by bitcoin, and Franco teaches validation in the UTXO model of bitcoin involves verifying that UTXOs are in fact unspent. The double spend verification of Franco would perform the same function in the distributed ledger protocol of Kokoris-Kogias as it does in bitcoin.
Regarding claim 17
Claim 17 (system) is substantially similar to claim 15, and is treated the same with respect to prior art rejections.
Regarding claim 18
Kokoris-Kogias does not teach the following, however Franco further teaches:
The system of claim 5, wherein performing the validity check comprises executing a script of a stack-based scripting language to determine whether the script evaluates to TRUE. (See claim 13 rejection above. See also Franco page 81, paragraphs 1 and 2 “If the script fails midway or if the end result does not evaluate to true, the input of the transaction is invalid and the whole transaction is rendered invalid and dropped. The scripting language is stack-based.”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the validation of Kokoris-Kogias with the stack-based script validation check of Franco for the reasons given above regarding claim 13.
Regarding claim 20
Claim 20 (computer-readable storage medium) is substantially similar to claim 13, and is treated the same with respect to prior art rejections.
Regarding claim 22
The computer-implemented method of claim 1, wherein the identified shard of the first plurality of shards is a shard of the first plurality of shards associated with the previous transaction referred to in the output of the U[TX]O.
Claim 22 does not contain any new limitation and is merely redundant with respect to claim 1 and is rejected for the same reasons.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Kokoris-Kogias., “OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding” (2017), in view of Pedro Franco, “Understanding Bitcoin” (2015), in view of Reddit.com “Are there any plans of SHARDING” as applied to claim 1 above, and further in view of Applicant Admitted Prior Art.
Regarding claim 21
Kokoris-Kogias teaches:
The computer-implemented method of claim 1 further comprising:
communicating the shard membership information from the another node to the node, wherein the communication is performed using a modified addr message that includes an indication of the node’s IP address and one or more shards with which the node is associated. {Pages 3-4 “They [another node] create their identities [shard membership information, indication of the node’s IP address and one or more shards with which the node is associated] through a Sybil-attack-resistant mechanism in epoch e−1 and broadcast [communicate] them”}
See Luu “A Secure Sharding Protocol For Open Blockchains” (6/6/2022 IDS) regarding the meaning of the term “identity”:
Each processor locally generates an identity consisting of a public key, an IP address and a proof-of-work (PoW) solution [1]. The processor must solve a PoW puzzle which has publicly verifiable solutions to generate the final component of the identity. (Luu section 3.1).
The public key and PoW solution are shard membership information which indicates a shard with which the node is associated.
Kokoris-Kogias in view of Franco in view of Reddit.com does not teach, however Applicant Admitted Prior Art teaches:
communicating a request from a node seeking shard membership information to another node; and
Page 12 paragraph 1 of Applicant’s specification reads “An implementation of addr messages that currently exist as part of the Bitcoin protocol is used to list or identify one or more IP addresses and ports. For example, a getaddr request [request from a node] may be used to obtain an addr message containing a bunch of known-active peers (for bootstrapping, for example). […] In some examples, all nodes broadcast an addr containing their own IP address periodically, i.e. every 24 hours.” This statement is considered admitted prior art and it would be obvious for the validators of OmniLedger to do the same for the same reason.
Response to Arguments
35 USC § 103
Applicant has amended claim 1 and argues the new limitations are not taught by the cited references. Applicant states the cited references do not teach or suggest how to implement the specific two-level hierarchical sharding mechanism recited in claim 1. However, the claimed “two-level hierarchical” structure is achieved merely by applying the method of Kokoris-Kogias twice, i.e. to divide a blockchain into shards once and then to subdivide it further.
Applicant argues Appendix C of Kokoris-Kogias teaches assigning UTXOs to shards randomly, rather than based on a transaction identifier (second allocation scheme) as alleged in the rejection. However, what Kokoris-Kogias teaches is assigning UTXOs to shards based on a hash of their data. Since a transaction identifier is nothing more than a unique value and can include a hash of the transaction data, assigning UTXOs to shards based on a hash of the UTXO reads on assigning the UTXO based on a transaction identifier. Kokoris-Kogias is merely stating that, assuming the hash function is a cryptographic hash function, assigning UTXOs to shards based on the hash will result in effectively random assignments.
Applicant argues the claimed first sharding method using a first allocation scheme (input-based sharding) is not taught by Kokoris-Kogias. It is true that Kokoris-Kogias does not describe this allocation scheme using similar language. However, the term “allocate” is not defined in the application. Additionally, the term is used alternately to refer to allocation of a transaction or allocation of a UTXO, adding to the difficulty in interpreting the term. Based on the way the term is used in the application, it is given the following interpretation: a transaction (or transaction output) is considered to be “allocated” to a shard if that shard’s nodes process or store the transaction.
In the sharding method of Kokoris-Kogias, a transaction is processed and stored by every shard to which at least one of the transaction’s outputs was assigned based on the hash assignment method of Appendix C, as well as by every shard which stores the outputs referenced by that transaction. In the method of Kokoris-Kogias, each transaction is potentially stored and processed by more than one shard, where the shards are determined by hashes of transaction data as well as the shards of referenced transactions. The method of Kokoris-Kogias therefore simultaneously satisfies both claimed allocation scheme requirements.
Applicant argues the cited Reddit post is not enabling because it merely speculates that a blockchain could be sharded and that it would result in performance improvement. However, the rejection is not relying on the Reddit post to provide such details. The implementation details and performance analysis are provided by Kokoris-Kogias. The Reddit post is only relied on to establish that it was known that it was desirable to apply a sharding technique to an existing unsharded blockchain.
Conclusion
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 SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm ET.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights