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 .
Priority
The present application claims priority from Provisional Application 63567179, filed 03/19/2024.
Allowable Subject Matter
Claim 25-27 allowed.
Claim Rejections - 35 USC § 103
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.
Claim(s) Claims 1-2, 4-5, 7-8, 15-19 and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0233065 Al to NCHAlN HOLDINGS LIMITED (hereinafter 'nChain') in view of CN 112422341 B to TENCENT TECH SHENZHEN CO LTD (hereinafter 'Tencent') (“nChain” and “Tencent” cited in the 10/22/2025 IDS ).
As to claim 1, nChain teaches a system, comprising: a set of networked computing devices configured in a multiple-neighborhood topology, each respective computing device of the set of networked computing devices being configured as part of the multiple-neighborhood topology in which each respective computing device is assigned to a group of neighborhoods and follows a topology protocol to yield a respective assigned group of neighborhoods for the respective computing device, wherein each respective neighborhood of the group of neighborhoods comprises a different subset of the set of networked computing devices in which the different subset of the set of networked computing devices only communicates with other computing devices in its respective assigned group of neighborhoods ("As can be seen in FIG. 1 b , a particular node can be a member of one or more shard groups. This is seen by the shaded lines shown in this figure, where a node within the shaded area is a member of both, shard 2 as
well as shard 3. For communication, in the current Bitcoin network and Bitcoin SV (BSV) client, a list of available peers, i.e. nodes in the network, holds information regarding nodes it can connect to, distribute to, and receive from," para [0057]);
a respective ledger operating on each respective computing device for recording transactions, wherein a combination of each respective ledger on each respective computing device comprises a distributed ledger ("a blockchain network, for example the Bitcoin blockchain network, is a secure distributed computing system. Full nodes of the system persist and manage a copy of the entire blockchain, sending and receiving transactions, validating them, and adding blocks to the blockchain based on a shared decentralized consensus protocol," para [0006]);
a respective consensus algorithm running on each respective computing device such that when a respective transaction of a group of transactions is to be made via application of the respective consensus algorithm, a set of rules according to a transaction protocol applies in order for the respective transaction to be recorded on the distributed ledger, wherein the transaction protocol comprises a combination each operation of each respective consensus algorithm on each respective computing device and further comprises: receiving, at a first computing device in a first neighborhood, the respective transaction to be recorded on the distributed ledger across the set of networked computing devices ("Full nodes of the system persist and manage a copy of the entire blockchain, sending and receiving transactions, validating them, and adding blocks to the
blockchain based on a shared decentralized consensus protocol," para [0006]);
communicating the respective transaction to each neighbor of the first computing device, wherein each neighbor of the first computing device comprises the respective assigned group of neighborhoods for the first computing device ("for handling transaction propagation across the network, each node shown in the sharded network in FIG. 1 b arranged or configured such that it may communicate with at least a single node from each shard to propagate their transactions destined for a different shard. In some implementations, the information held by each node may be in the form of a data structure to indicate nodes it can connect to, distribute to, receive from, and the shard that it belongs to in the sharded network seen in FIG. 1 b," para [0057]);
continuing to communicate the respective transaction from neighborhood to neighborhood in the set of networked computing devices according to the multiple-neighborhood topology until all computing devices of the set of networked computing devices have received the respective transaction ("In a sharded blockchain according to the first embodiment, additional information is held, including of which shard each node is a member. In some implementations, for handling transaction propagation across the network, each node shown in the sharded network in FIG. lb arranged or configured such that it may communicate with at least a single node from each shard to propagate their transactions destined for a different shard,"
para [0057]).
nChain fails to explicitly teach such a system further comprising: and upon approval of the respective transaction by a respective vote from at least a majority of computing devices of the set of networked computing devices, recording the respective transaction on the distributed ledger; and a respective judicial module operating a respective judicial protocol on each respective computing device, wherein fault detection occurs via application of the respective judicial protocol in which a majority of computing devices in a respective neighborhood can take an action against a faulty computing device of the respective neighborhood by determining that the faulty computing device violates one or more rule of the set of rules.
However, Tencent teaches such a system further comprising: and upon approval of the respective transaction by a respective vote from at least a majority of computing devices of the set of networked computing devices, recording the respective transaction on the distributed ledger ("After generating the current block, the master node generates a block proposal message based on the current block and broadcasts the block proposal message to each slave node in the block chain network; the block proposal message is used for instructing a slave node in the block chain network to perform consensus on a current block in the block proposal message, and to uplink the current block after the current block consensus passes, and the like," translation at pg 8); and
a respective judicial module operating a respective judicial protocol on each respective computing device, wherein fault detection occurs via application of the respective judicial protocol in which a majority of computing devices in a respective neighborhood can take an action against a faulty computing device of the respective neighborhood by determining that the faulty computing device violates one or more rule of the set of rules ("a set of governance contracts is deployed on a blockchain network, and a fault table is maintained through the governance contracts, where the fault table is used to record fault information of each faulty billing node (referred to as a faulty node) in the blockchain network, and the fault information may include an identification (identity, ID) of the billing node corresponding to the faulty
node," translation at pg 9; "The method for detecting the fault of the block chain network is realized based on an intelligent contract and a related governing contract, the fault of a bookkeeping node in the block chain network is automatically monitored by adopting a fault detection intelligent contract mode, when the fault triggers the agreed governing contract, a corresponding contract rule is automatically executed, and a target fault node is eliminated from the block chain network," pg 13).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention , to combine the blockchain network system of nChain with the support for judicial modules and fault detection of Tencent, because such systems and
methods allow for monitoring and recording instances of faulty nodes in a blockchain network (Tencent: translation at pg 8-9, 13). Furthermore, both nChain and Tencent are directed to systems and methods for blockchain networks.
As to claim 2, the system of claim 1 is discussed above. Further, Tencent teaches such a system wherein the action against the faulty computing device comprises removing the faulty computing device from participating in a consensus operation of the respective neighborhood of computing devices until a fault event is remedied ("a target fault node is eliminated from the block chain network," pg 13.
As to claim 4, the system of claim 1 is discussed above. Further, Tencent teaches such a system wherein the respective judicial module operates on each respective computing device such that there is no centralized judicial process ("The consensus mechanism of the block chain enables the block chain to still cooperate and complete the operation efficiently in a large scale without depending on centralized organization," translation at pg 8).
As to claim 5, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein continuing to communicate the respective transaction from neighborhood to neighborhood in the set of networked computing devices according to the multiple-neighborhood topology until all devices of the set of networked computing devices have received the respective transaction further comprises each respective computing device that receives the respective transaction from a sending computing device will communicate the respective transaction to each other computing device in its respective assigned group of neighborhoods except to the sending computing device ("based on a determination that the transaction is valid, adding the transaction to a mempool associated with the requesting node; and propagating the transaction to other member nodes of the at least one shard that the requesting node is a member of," para [0030]).
As to claim 7, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein the group of neighborhoods comprises two or more neighborhoods ("the blockchain network is partitioned into a plurality of shards," para [0030]).
As to claim 8, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein the transaction protocol drops duplicate transactions as they are identified ("During transaction validation, one of the checks required is to check that there has not been a double spend. A double spend is when a transaction output has been referenced in a transaction input either already in the Bitcoin mempool, or confirmed on the blockchain," para [0012]).
As to claim 15, the system of claim 1 is discussed above. Further, Tencent teaches such a system wherein the respective transaction is received at the first computing device from an electronic wallet associated with a user device ("the wallet is used for providing a function of carrying out transaction of virtual resources," translation at pg 7).
As to claim 16, the system of claim 15 is discussed above. Further, Tencent teaches such a system wherein the respective transaction is associated with a transaction (translation at pg 7).
As to claim 17, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein each respective computing device is equal to each other respective computing device and wherein all transactions require a consensus to be recorded on a ledger or wherein transactions recorded on the distributed ledger are immutable and the distributed ledger only persists in a forward direction ("Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block so that blocks become chained together to create a permanent, unalterable record of all transactions which have been written to the blockchain since its inception," para [0003]; "Full nodes of the system persist and manage a copy of the entire blockchain, sending and receiving transactions, validating them, and adding blocks to the blockchain based on a shared decentralized consensus protocol," para [0006]).
As to claim 18, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein each respective computing device of the set of networked computing devices receives a broadcast associated with each respective transaction according to the multiple-neighborhood topology ("According to the second embodiment, each node in the sharded network can broadcast every transaction to each other," para [0061]).
As to claim 19, the system of claim 1 is discussed above. Further, Tencent teaches such a system wherein each respective computing device is distributed across a public network, equal and independent ("The blockchain network may include a public blockchain network (referred to as a public chain for short), a private blockchain network (referred to as a private chain for short), or a federation blockchain network (referred to as a federation chain for short) ... Any node in the public chain is open to anyone, and each person can participate in the blockchain to perform calculation, and anyone can download and obtain the data (all accounts) of the complete blockchain," translation at pg 7).
As to claim 21, the system of claim 1 is discussed above. Further, nChain teaches such a system wherein the transaction protocol comprises procedures and rules each respective computing device must follow to actively participate in processing, voting and maintaining the respective ledger as part of the distributed ledger ("Receiving, storing and/or validating UTXO's in such a sharded network is performed using the described and claimed methods, rules or protocols for communication, data storage, data sharing as well as validation techniques for nodes within each shard, as well as based on the rules and protocols associated for communication with nodes belonging to different shards," para [0016]).
As to claim 22, the system of claim 1 is discussed above. Further, Tencent teaches such a system wherein a respective judicial protocol comprises each respective computing device actively monitoring and correction controls overseeing all interactions of other computing devices within its respective neighborhoods and providing guardrails against malicious attack vectors, non-compliant messaging, or underperforming neighbor computing devices which may compromise an overall stability of the set of networked computing devices ("In the consensus process, there may be a malicious behavior of the current master node (the accounting node of the current block) or a communication failure of the current master node (i.e., the current master node fails), which may result in the current consensus process not being completed normally ... The intelligent contract for fault detection in the embodiment of the disclosure can realize automatic governance of the block chain network, and does not need to judge whether the block chain network has a fault by means of an external monitoring system, so the intelligent contract for fault detection can also be called a governance contract, wherein the governance contract is a component of the whole intelligent contract for the block chain network, and is a set of contract rules for automatically triggering execution and detecting whether the block chain network has a fault," translation at pg 8-9).
Claim(s) 3, 6, 9 and 23-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over nChain in view of Tencent and further in view of US 2020/0259633 Al to COPA FIN LIMITED (hereinafter 'Copa') (“Copa” cited in the 10/22/2025 IDS ).
As to claim 3, nChain and Tencent teach the system of claim 1, but fail to explicitly teach such a system wherein the respective consensus algorithm operates in an asynchronous manner.
However, Copa teaches such a system wherein the respective consensus algorithm operates in an asynchronous manner ("The synchronization trigger event may be associated with a regular time interval or a varying time interval which is asynchronous with respect to the creation of blocks on a member node (e.g. it may be a random time interval)," para [0122]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain and Tencent with the support for asynchronous consensus of Copa, because such systems and methods allow for performing blockchain operations in a synchronous or asynchronous manner as needed (Copa: para [0122]). Furthermore, nChain, Tencent and Copa are directed to systems and methods for blockchain networks.
As to claim 6, nChain and Tencent teach the system of claim 1, but fail to explicitly teach such a system wherein communicating the respective transaction to each neighbor of the first computing device is performed using a communication protocol that does not require an acknowledgment return signal to the first computing device.
However, Copa teaches such a system wherein communicating the respective transaction to each neighbor of the first computing device is performed using a communication protocol that does not require an acknowledgment return signal to the first computing device ("Multicasting of the outbound synchronization data is performed using a connectionless protocol, such as the User Datagram Protocol (UDP). Multicasting therefore differs from peer-to-peer transmissions in which a member node transmitting outbound synchronization data must have a direct connection with each other peer (such as another member node of the DLN) in order to transmit the outbound synchronization data to that peer. The method of these examples thus provides much lower network overhead and utilization compared to existing DLN networks, in which significant overhead and utilization is required in the setting up and maintenance of peer-to-peer connections across the network. For example, UDP involves a so-called "fire and forget" method that occurs once," para [0127]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain and Tencent with the support for a communication protocol that does not require a return acknowledgment signal of Copa, because such systems and methods allow for multicasting data without needing to wait for a response (Copa: para [0127]). Furthermore, nChain, Tencent and Copa are directed to systems and methods for blockchain networks.
As to claim 9, nChain and Tencent teach the system of claim 1, but fail to explicitly teach such a system wherein the transaction protocol puts all transactions approved by the set of networked computing devices into a single line of transactions via a deterministic order.
However, Copa teaches such a system wherein the transaction protocol puts all transactions approved by the set of networked computing devices into a single line of transactions via a deterministic order ("each member node of the DLN may include a blockmatrix builder that includes a block ordering algorithm that orders the blockvectors in a predetermined order. The block ordering algorithm may be common to each DLN such that, when corresponding blocks, from adjacent blockvectors in the blockmatrix, are chained
together, the same resulting hashblock is created. Hence, each member node is able to verify the integrity of a blockmatrix that it has stored against a blockmatrix that may be received from a remote member node of the DLN. The blockchains may be ordered for example according to a member node identifier (described further below with reference to FIG. 8), which may be considered to correspond to a second dimension," para [0092]).
It would have been obvious to one of ordinary skill in the art , before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain and Tencent with the support for recording transactions in a deterministic order of Copa, because such systems and methods allow for using predetermined orders depending on a variety of factors other than chronological order (Copa: para [0092]). Furthermore, nChain, Tencent and Copa are directed to
systems and methods for blockchain networks.
As to claim 23, nChain and Tencent teach the system of claim 1, but fail to explicitly teach such a system wherein communicating the respective transaction to each neighbor of the first computing device is performed using a message delivery protocol that does not provide an acknowledgment return signal.
However, Copa teaches such a system wherein communicating the respective transaction to each neighbor of the first computing device is performed using a message delivery protocol that does not provide an acknowledgment return signal (para [0127]).
It would have been obvious to one of ordinary skill in the art , before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain and Tencent with the support for a communication protocol that does not require a return
acknowledgment signal of Copa, because such systems and methods allow for multicasting data without needing to wait for a response (Copa: para [0127]). Furthermore, nChain, Tencent and Copa are directed to systems and methods for blockchain networks.
As to claim 24, the system of claim 23 is discussed above. Further, Copa teaches such a system wherein the message delivery protocol comprises a user datagram protocol (UDP) (para [0127]).
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over nChain in view of Tencent and further in view of US 2022/0182243 Al to TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) (hereinafter 'Ericsson'). (“Ericsson” cited in the 10/22/2025 IDS ).
As to claim 20, nChain and Copa teach the system of claim 1, but fail to explicitly teach such a system wherein the topology protocol followed by each respective computing device comprises (1) at least procedures and rules each respective computing device follows to actively participate in operating its respective consensus algorithm and (2) an ability to self-organize in network alignment to sustain an adequate overlay coverage across the set of networked computing devices according to the multipleneighborhood topology.
However, Ericsson teaches such a system wherein the topology protocol followed by each respective computing device comprises (1) at least procedures and rules each respective computing device follows to actively participate in operating its respective consensus algorithm and (2) an ability to self-organize in network alignment to sustain an adequate overlay coverage across the set of networked computing devices according to the multiple-neighborhood topology ("Since DHT overlay network is a balanced architecture, multiple options can be provided to consider which nodes (and replicas) and which paths to use to store objects (copies) to ensure application layer security. The DHT overlay network is selforganizing and autonomous, so there is no need for extra user operations, which reduces the cost of execution, maintenance, and management," para [0074]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain and Tencent with the support for a self-organizing network of Ericsson, because such systems and methods allow for the generation of an autonomous and self-organizing overlay network (Ericsson:
para [0074]). Furthermore, nChain, Tencent and Ericsson are directed to systems and methods for blockchain networks.
Claim(s) 10-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over nChain in view of Tencent and Copa and further in view of US 2019/0034465 Al to HITACHI, LTD. (hereinafter 'Hitachi'). (“Hitachi” cited in the 10/22/2025 IDS ).
As to claim 10, nChain, Tencent and Copa teach the system of claim 9, but fail to explicitly teach such a system wherein the transaction protocol orders all ordering attributes are assigned in a place in the single line in a non-chronological order or wherein transaction protocol orders all ordering attributes are assigned in a place in the single line according to respective ordering attributes associated with each respective transaction.
However, Hitachi teaches such a system wherein the transaction protocol orders all ordering attributes are assigned in a place in the single line in a non-chronological order or wherein transaction protocol orders all ordering attributes are assigned in a place in the single line according to respective ordering attributes associated with each respective transaction ("the block list may store block data in a serialized order. To create the block list, the auditing computing device may add the information from each block in each blockchain to the block list and may establish the location in the block list of the sequential data based on the order of the blocks in the blockchains as well as the source IDs and the local date and time associated with each piece of the sequential data," para [0025]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain, Tencent and Copa with the support for using ordering attributes in ordering transactions of Hitachi, because such systems and methods allow for storing blocks in order based on specific attributes (Hitachi: para [0025]). Furthermore, nChain, Tencent, Copa and Hitachi are directed to systems and
methods for blockchain networks.
As to claim 11, nChain, Tencent and Copa teach the system of claim 9, but fail to explicitly teach such a system wherein the transaction protocol implements a delay period for ordering each respective transaction into the single line and packages a group of transactions into a preframe.
However, Hitachi teaches such a system wherein the transaction protocol implements a delay period for ordering each respective transaction into the single line and packages a group of transactions into a preframe ("the sequential data receiver 218 may configure the processor 202 to receive the sequential data 122 from the source computing devices 108 and/or the other consensus nodes, and store the received sequential data 122 in a sequential data storage 224. For instance, the sequential data storage 224 may be a storage buffer or the like, such as configured as a first-in-first-out (FIFO) queue in which the sequential data 122 is stored until it can be recorded on a blockchain 112," para [0044]).
It would have been obvious to one of ordinary skill in the art , before the effective filing date of the claimed invention, to combine the blockchain network systems of nChain, Tencent and Copa with the support for delayed transaction recordings of Hitachi, because such systems and methods allow for packaging a group of transactions in a queue to be recorded (Hitachi: para [0044]). Furthermore, nChain, Tencent, Copa and Hitachi are directed to systems and methods for blockchain networks.
As to claim 12, the system of claim 11 is discussed above. Further, Copa teaches such a system wherein the transaction protocol on a respective computing device sends the preframe out to the respective neighborhood of computing devices for a vote to confirm that each computing device of the set of networked computing devices have a same ordered line of transactions as does the single line in the preframe to yield a first consensus ("each member node of the DLN may include a blockmatrix builder that includes a block ordering algorithm that orders the blockvectors in a predetermined order. The block ordering algorithm may be common to each DLN such that, when corresponding blocks, from adjacent blockvectors in the blockmatrix, are chained together, the same resulting hashblock is created. Hence, each member node is able to verify the integrity of a blockmatrix that it has stored against a blockmatrix that
may be received from a remote member node of the DLN," para [0092]).
As to claim 13, the system of claim 12 is discussed above. Further, Hitachi teaches such a system wherein the transaction protocol, based on the first consensus for the preframe, packages the preframe with other preframes that have also received consensus from the set of networked computing devices, to yield a group of preframes comprising a frame that is recorded on the distributed ledger ("the leader consensus node may execute the leader node program 216, which may include a sequential data receiver 218, a block generator 220, and a sequential data transferor 222, each of which may be executable instructions executable by the processor 202 for performing the functions described herein," para [0043]; para [0044]).
As to claim 14, the system of claim 13 is discussed above. Further, Hitachi teaches such a system wherein the frame is assigned by the transaction protocol a unique transaction identifier for a set of transactions associated with the frame ("The resulting block header hash 308 is a 32-byte hash value that uniquely represents the header of the corresponding block. The block header hash 308 can be independently derived by any consensus node or user by simply hashing the block header 310 of the particular block," para[0054]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULKADER M ALRIYASHI whose telephone number is (313)446-6551. The examiner can normally be reached Monday - Friday, 8AM - 5PM Alt, Friday, EST.
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, JOON HWANG can be reached at (571)272-4036. 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.
/Abdulkader M Alriyashi/Primary Examiner, Art Unit 2447 9/30/2026
