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 .
Response to Amendment
Applicant's response filed 24 July 2024 has been considered and entered. Accordingly, claims 1-12 are pending in this application. Claims 1-12 are currently amended.
Claim Objections
3. Claims 2-3 are objected to because of the following informalities:
In claim 2, line 1, “The method according to claim 1 further comprising” should read “The method according to claim 1, further comprising”. There should be a comma after claim 1.
Appropriate correction is required.
In claim 3, line 1, “The method according to claim 1 further comprising:” should read “The method according to claim 1, further comprising:”. There should be a comma after claim 1 and a colon after comprising.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
4. 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 11-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The specification covers both statutory and non-statutory (i.e. signal) embodiments.
5. Claim 11 discloses “A computer-program product, comprising a computer readable hardware storage device having computer readable program code stored therein, the program code executable by a processor of a computer system to implement a method according to claim 1”. The claimed computer readable hardware storage device is not defined in the disclosure. Furthermore, according to the specification [Para. 18], “a computer-program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions), having computer-readable instructions stored therein, that when executed by a processing unit, cause the processing unit to perform the method steps” and [Para. 51], “a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.”. However, computer-readable storage medium or computer-readable medium is not the medium being claimed is also described in an open-ended manner not excluding signals. As such, the specification does not clearly limit the claimed “computer readable hardware storage device” to statutory subject matter. The BRI of machine-readable media can encompass non-statutory transitory forms of signal transmission, such as a propagating electrical or electromagnetic signal per se. See In re Nuijten, 500 F.3d 1346, 84 USPQ2d 1495 (Fed. Cir. 2007). When the BRI encompasses transitory forms of signal transmission, a rejection under 35 U.S.C. 101 as failing to claim statutory subject matter would be appropriate. Thus, a claim to a computer readable medium that can be a compact disc or a carrier wave covers a non-statutory embodiment and therefore should be rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. See, e.g., Mentor Graphics v. EVE-USA, Inc., 851 F.3d at 1294-95, 112 USPQ2d at 1134 (claims to a "machine-readable medium" were non-statutory, because their scope encompassed both statutory random-access memory and non-statutory carrier waves). Thus, the broadest reasonable interpretation of the claim covers a carrier wave, which does not fall within one of the four categories of invention. As such, a computer readable hardware storage device may be a transitory medium.
As per the Kappos memo, the only proper recourse for open ended and non-correlated definitions is to amend the medium to be non-transitory. So, it is suggested an amendment to the claim 11 to recite, “A computer-program product, comprising a non- transitory computer readable hardware storage device having computer readable program code stored therein, the program code executable by a processor of a computer system to implement a method according to claim 1”.
6. Claims 12 disclose “A computer readable medium on which program code sections of a computer program are saved, the program code sections being loadable into and/or executable in a system to make the system execute the method according to claim 1 when the program code sections are executed in the system”. But in the specification [Para. 18], “a computer-program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions), having computer-readable instructions stored therein, that when executed by a processing unit, cause the processing unit to perform the method steps” and [Para. 51], “a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device”. However, computer-readable storage medium in [Para. 18] is not the medium being claimed and further computer-readable medium in [Para. 51] is described in an open-ended manner not excluding signals. As such, the specification does not clearly limit the claimed “A computer readable medium” to statutory subject matter. Thus, the broadest reasonable interpretation of the claim covers a carrier wave, which does not fall within one of the four categories of invention. As such, a computer readable medium may be a transitory medium.
Subject Matter Eligibility of Computer Readable Media
The United States Patent and Trademark Office (USPTO) is obliged to give claims their broadest reasonable interpretation consistent with the specification during proceedings before the USPTO. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 U.S.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007).
The USPTO recognizes that applicants may have claims directed to computer readablemedia that cover signals per se, which the USPTO must reject under 35 U.S.C. § 101as covering both non-statutory subject matter and statutory subject matter. In an effortto assist the patent community in overcoming a rejection or potential rejection under
35 U.S.C. § 101 in this situation, the USPTO suggests the following approach. A claimdrawn to such a computer readable medium that covers both transitory and non-transitory embodiments may be amended to narrow the claim to cover only statutoryembodiments to avoid a rejection under 35 U.S.C. § 101 by adding the limitation "non-transitory" to the claim.
The computer-executable instructions per se embodies functional descriptive material, is a sequence or instructions merely capable of being executed by a computer machine to realize its functionality, it is not a process, nor a device, cannot be embodied in a machine without a non-transitory computer-readable medium; and then a computer readable medium thereof could be broadly interpreted to include medium such as carrier wave distributed over a network. It is suggested an amendment to the claims to recite, "A non-transitory computer readable medium on which program code sections of a computer program are saved, the program code sections being loadable into and/or executable in a system to make the system execute the method according to claim 1 when the program code sections are executed in the system" to overcome the rejection.
Claim Rejections - 35 USC § 103
7. 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.
8. Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over WRIGHT et al. (US 2023/0054245 A1) hereinafter WRIGHT, in view of Li (US 2019/0342422 A1) hereinafter Li.
As to claim 1, WRIGHT discloses a method for writing and retrieval of data in a blockchain with a plurality of nodes to manage multiple assets (Para. 36; 43), the method comprising:
designating one of the plurality of nodes at current instant of committing of a block to the blockchain, wherein the designated node is a current leader node (Para. 36, “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160.”. Para. 281, When a client uses a Cassandra cluster to read or write data, the client may choose to communicate with any node in the cluster, as they are treated indiscriminately. The node chosen by the client becomes a coordinator node, i.e., a current leader node, for performing the particular read or write request being made by the client.);
broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant (Para. 349, “1. A user/client makes a read/write request to a database node. The user/client simultaneously creates and broadcasts a read/write request transaction and sends directly to the blockchain core layer. The user/client also sends the TxID of this transaction to the coordinator database node”. Para. 350, “2. The coordinator behaves as usual by identifying the relevant nodes to which the read/write request pertains. Depending on the request type, the coordinator does the following:”. Para. 351, a. Read request: there is no state mutation required for any node, so the coordinator operator simply forwards the request to the relevant nodes, i.e., broadcasting a message by the current leader node, via Gossip or direct communication (if directly connected). Thus, broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant.);
receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message (Para. 354, “3. Upon receiving the request and data from the peers, a replica node confirms, from the core, that the request they have received matches the request details in the request transaction, and return an acknowledgement to the coordinator”. Thus, receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message.);
storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein (Para. 244, “if the update is destined for the receiving database node 1202DB, then the receiving database node applies the requested update locally at the copy of the relevant target entry stored locally on the receiving node 1202DB”. Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online. Again this check may be performed directly over a connection within the layered network 1200 between the database node 1202DB in question and one or more of the core nodes 1201, or indirectly via more than one hop.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including deletions) that a node misses while offline is stored and recoverable from the blockchain.”. Thus, storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein.);
receiving transaction data from each of the nodes that have been determined to be back online (Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online.”. Thus, receiving transaction data from each of the nodes that have been determined to be back online.); and
recording the transaction data to a current block being committed to the blockchain, if there has been no transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between an instant when the corresponding node was last identified to be offline and the current instant (Para. 303, “In the event that a node is unreachable during the deletion (i.e. tombstone and compaction) of a row of data, when that node re-joins the cluster it will treat the record as new and attempt to forward it to other replica nodes. Because the other replica nodes, which were online during the record's deletion, have already deleted the record it is known as a zombie record.”. Para. 310, “When the unreachable node (identified by Node ID) comes back online the coordinator is responsible for replaying the hint to that node and effectively forwarding the write request to it after the fact. This means that a burden, both in disk space and processing, is necessarily placed on the coordinator for updating unreachable nodes when they re-join the network.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including deletions) that a node misses while offline is stored and recoverable from the blockchain.”. Thus, recording the transaction data to a current block being committed to the blockchain, if there has been no transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between an instant when the corresponding node was last identified to be offline and the current instant.).
WRIGHT does not explicitly disclose identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby; determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant; determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby.
However, in the same filed of endeavor, Li discloses identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby (Para. 61, “After sending the heartbeat detection message to the server, if detecting that no response message returned by the server based on the heartbeat detection message is received after a specified time elapses, the registration center can determine that the server is possibly offline currently because of a running fault, a program restart, etc., and does not push the address of the server to the client.”. Thus, identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby.);
determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant (Para. 74, “after obtaining the addresses of the servers in the second blockchain node, the registration center can regularly send a heartbeat detection message to the servers corresponding to these addresses. When receiving a response message returned by a server based on the heartbeat detection message after a specified time elapses (or within a specified time), the registration center can determine that the server is still in an online state, and continues to manage an address of the server. When not receiving the response message returned by the server based on the heartbeat detection message after the specified time elapses, the registration center can determine that the server is possibly offline because of a running fault, network instability, etc., and does not continue to manage the address of the server until the server is back online.”. Thus, determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant.);
determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby (Para. 74, “after obtaining the addresses of the servers in the second blockchain node, the registration center can regularly send a heartbeat detection message to the servers corresponding to these addresses. When receiving a response message returned by a server based on the heartbeat detection message after a specified time elapses (or within a specified time), the registration center can determine that the server is still in an online state, and continues to manage an address of the server. When not receiving the response message returned by the server based on the heartbeat detection message after the specified time elapses, the registration center can determine that the server is possibly offline because of a running fault, network instability, etc., and does not continue to manage the address of the server until the server is back online.”. Thus, determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of WRIGHT by sending a heartbeat detection message to the servers in order to determine whether the server such as the node of WRIGHT is still in an online or offline state for performing service processing as disclosed by Li (Para. 74). After re-obtaining the address of the server from the registration center when the server is back online, the servers in the first blockchain node and the client can send the service request to the server corresponding to the address by using the obtained address. One of the ordinary skills in the art would have motivated to make this modification in order to ensure the server can perform service processing without any interruption or processing delay by determining the available status of the server such as the node of WRIGHT as suggested by Li (Para. 59-61).
As to claim 2, the claim is rejected for the same reasons as claim 1 above. In addition, WRIGHT discloses further comprising: re-executing one or more transactions in the received transaction data to generate new transaction data related to the one or more assets, if there has been transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between the instant when the corresponding node was last identified to be offline and the current instant; recording the new transaction data to the current block being committed to the blockchain (Para. 252, “when a node is disconnected it may miss an update in the form of a deletion. If all the other nodes have completely expunged the deleted entry by the time the disconnected node reconnects, then that node may re-propagate the deleted data as if it were a new entry to be added to the database.”. Para. 303, “In the event that a node is unreachable during the deletion (i.e. tombstone and compaction) of a row of data, when that node re-joins the cluster it will treat the record as new and attempt to forward it to other replica nodes. Because the other replica nodes, which were online during the record's deletion, have already deleted the record it is known as a zombie record.”. Para. 310, “When the unreachable node (identified by Node ID) comes back online the coordinator is responsible for replaying the hint to that node and effectively forwarding the write request to it after the fact. This means that a burden, both in disk space and processing, is necessarily placed on the coordinator for updating unreachable nodes when they re-join the network.”. Thus, recording the new transaction data to the current block being committed to the blockchain.).
As to claim 3, the claim is rejected for the same reasons as claim 1 above. In addition, WRIGHT discloses further comprising assigning a unique asset identification to each of the one or more assets (Para. 65, “The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the miners 104M.”. Para. 358, “The details of an example read/write transaction are shown in FIG. 19 below. The <request data> packet may include a unique request ID, the ID of the coordinator node for that request and the key for the row of data that is being requested.”. Thus, assigning a unique asset identification to each of the one or more assets.).
As to claim 4, the claim is rejected for the same reasons as claim 3 above. In addition, WRIGHT discloses wherein the transaction data has metadata associated therewith, wherein the metadata comprises: the unique asset ID for respective one of the one or more assets for which there is at least one corresponding transaction in the associated transaction data, one or more pointers, with each of the one or more pointers referring to a previous block which contains last transaction related to the respective one of the one or more assets, and a first timestamp corresponding to instant when the associated transaction data was stored (Fig. 2, Para. 41, “The current state of all accounts is stored by the miners separate to the blockchain and is updated constantly. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.”. Para. 45, “A block pointer 155 is also assigned to the new block 151n pointing back to the previously created block 151n-1 in the chain. The proof-of-work helps reduce the risk of double spending since it takes a large amount of effort to create a new block 151, and as any block containing a double spend is likely to be rejected by other nodes 104, mining nodes 104M are incentivised not to allow double spends to be included in their blocks. Once created, the block 151 cannot be modified since it is recognized and maintained at each of the storing nodes 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each storage node 104S in a P2P network 106, this therefore provides an immutable public ledger of the transactions.”. Para. 197, “the attestation node 702A may also include at least one timestamp in the payload of each transaction Tx0 , Tx1 , Tx2 ... in the series. The timestamp indicates a time at which the respective data item(s) were received at the attesting node 702A.”. Thus, the transaction data has metadata associated therewith, wherein the metadata comprises: the unique asset ID for respective one of the one or more assets for which there is at least one corresponding transaction in the associated transaction data, one or more pointers, with each of the one or more pointers referring to a previous block which contains last transaction related to the respective one of the one or more assets, and a first timestamp corresponding to instant when the associated transaction data was stored.).
As to claim 5, the claim is rejected for the same reasons as claim 4 above. In addition, WRIGHT discloses wherein the metadata further comprises a second timestamp corresponding to instant when the associated transaction data was recorded in a block committed to the blockchain (Para. 256, “the attestation service 702A could be integrated into one or more of the database nodes 1202DB. In this case one of the database nodes 1202DB takes responsibility for determining the order (and optionally adding the timestamps), and recording this on the blockchain 150. The database node 1202DB responsible for the order may propagate the specified order to other database nodes 1202DB around the connections between nodes in the intermediate layer(s). The other database nodes 1202DB may check this against the order recorded in the blockchain, or alternatively may read the order directly from the blockchain 150 (or in a miner's mempool 154).”. Thus, the metadata further comprises a second timestamp corresponding to instant when the associated transaction data was recorded in a block committed to the blockchain.).
As to claim 6, the claim is rejected for the same reasons as claim 4 above. In addition, WRIGHT discloses wherein the retrieval of data from the blockchain is independent for each of the one or more assets and is based on the first timestamps of the transaction data related thereto (Para. 197, “the attestation node 702A may also include at least one timestamp in the payload of each transaction Tx0 , Tx1 , Tx2 ... in the series. The timestamp indicates a time at which the respective data item(s) were received at the attesting node 702A. In the case of a single data item D per transaction, this may simply be the time of receipt of that data item. In the case of multiple data items D per transaction Tx, each transaction payload could include a single timestamp indicating a time of arrival for the set (e.g. the time interval in which they were received), or an individual timestamp per data item Din the set.”. Thus, the retrieval of data from the blockchain is independent for each of the one or more assets and is based on the first timestamps of the transaction data related thereto).
As to claim 7, the claim is rejected for the same reasons as claim 1 above. In addition, WRIGHT discloses wherein each of the plurality of nodes configured to manage one or more of the multiple assets (Para. 36, “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will typically use one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset belonging to a user 103 to whom the output is cryptographically locked (requiring a signature of that user in order to be unlocked and thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.”. Thus, each of the plurality of nodes configured to manage one or more of the multiple assets.).
As to claim 8, the claim is rejected for the same reasons as claim 1 above. In addition, WRIGHT discloses wherein the current leader node is designated randomly or pseudo-randomly from nodes that are online at current instant, from the plurality of nodes (Para. 281, When a client uses a Cassandra cluster to read or write data, the client may choose to communicate with any node in the cluster, as they are treated indiscriminately. The node chosen by the client becomes a coordinator node, i.e., the current leader node, for performing the particular read or write request being made by the client. Thus, the current leader node is designated randomly or pseudo-randomly from nodes that are online at current instant, from the plurality of nodes.).
As to claim 9, the claim is rejected for the same reasons as claim 1 above. In addition, WRIGHT discloses wherein the nodes that have determined the current status thereof being offline and are part of a same network partition, store corresponding transaction data related to one or more assets managed thereby, locally in a side chain (Para. 244, “Each update request contains data content, i.e. the actual update to be made. This could be expressed in absolute terms, i.e. replacement data to replace some or all of the existing content of the target entry. Alternatively the content of the update could be expressed in the request as a delta (difference), i.e. a modification to apply to the respective target entry. The data content may comprise a full version of the ultimate user data that the user wishes to store, or it may instead take the form of a fingerprint or compressed version of the user data rather than the full version itself explicitly. Either way, if the update is destined for the receiving database node 1202DB, then the receiving database node applies the requested update locally at the copy of the relevant target entry stored locally on the receiving node 1202DB”. Para. 344, “In a multi-node cluster, different database nodes may store replicas of the same data. If a node receives a delete request for data it stores locally, the node tombstones the specified database entry and also tries to forward the tombstone to other nodes containing replicas of the same record. But if one replica node is unreachable at that time, it will not receive the tombstone immediately, so it still contains the version of the record from before the delete operation. If the "tombstoned" record has already been deleted from the rest of the cluster before that node recovers, then the entry in question on the now-recovered node may be treated as new data when it comes back online, and thus may be propagated it to the rest of the cluster as a new addition. This is referred to as a zombie record.”. Thus, the nodes that have determined the current status thereof being offline and are part of a same network partition, store corresponding transaction data related to one or more assets managed thereby, locally in a side chain.).
As to claim 10, WRIGHT discloses a system for writing and retrieval of data in a blockchain with a plurality of nodes configured to manage multiple assets and to commit blocks therein, the system comprising: one or more processing units; and a memory communicatively coupled to the one or more processing units, the memory comprising a module stored in the form of machine-readable instructions executable by the one or more processing units (Para. 35; 50), wherein the module is configured to perform the method (Para. 36; 43), the method comprising:
designating one of the plurality of nodes at current instant of committing of a block to the blockchain, wherein the designated node is a current leader node (Para. 36, “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160.”. Para. 281, When a client uses a Cassandra cluster to read or write data, the client may choose to communicate with any node in the cluster, as they are treated indiscriminately. The node chosen by the client becomes a coordinator node, i.e., a current leader node, for performing the particular read or write request being made by the client.);
broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant (Para. 349, “1. A user/client makes a read/write request to a database node. The user/client simultaneously creates and broadcasts a read/write request transaction and sends directly to the blockchain core layer. The user/client also sends the TxID of this transaction to the coordinator database node”. Para. 350, “2. The coordinator behaves as usual by identifying the relevant nodes to which the read/write request pertains. Depending on the request type, the coordinator does the following:”. Para. 351, a. Read request: there is no state mutation required for any node, so the coordinator operator simply forwards the request to the relevant nodes, i.e., broadcasting a message by the current leader node, via Gossip or direct communication (if directly connected). Thus, broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant.);
receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message (Para. 354, “3. Upon receiving the request and data from the peers, a replica node confirms, from the core, that the request they have received matches the request details in the request transaction, and return an acknowledgement to the coordinator”. Thus, receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message.);
storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein (Para. 244, “if the update is destined for the receiving database node 1202DB, then the receiving database node applies the requested update locally at the copy of the relevant target entry stored locally on the receiving node 1202DB”. Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online. Again this check may be performed directly over a connection within the layered network 1200 between the database node 1202DB in question and one or more of the core nodes 1201, or indirectly via more than one hop.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including deletions) that a node misses while offline is stored and recoverable from the blockchain.”. Thus, storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein.);
receiving transaction data from each of the nodes that have been determined to be back online (Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online.”. Thus, receiving transaction data from each of the nodes that have been determined to be back online.); and
recording the transaction data to a current block being committed to the blockchain, if there has been no transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between an instant when the corresponding node was last identified to be offline and the current instant (Para. 303, “In the event that a node is unreachable during the deletion (i.e. tombstone and compaction) of a row of data, when that node re-joins the cluster it will treat the record as new and attempt to forward it to other replica nodes. Because the other replica nodes, which were online during the record's deletion, have already deleted the record it is known as a zombie record.”. Para. 310, “When the unreachable node (identified by Node ID) comes back online the coordinator is responsible for replaying the hint to that node and effectively forwarding the write request to it after the fact. This means that a burden, both in disk space and processing, is necessarily placed on the coordinator for updating unreachable nodes when they re-join the network.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including deletions) that a node misses while offline is stored and recoverable from the blockchain.”. Thus, recording the transaction data to a current block being committed to the blockchain, if there has been no transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between an instant when the corresponding node was last identified to be offline and the current instant.).
WRIGHT does not explicitly disclose identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby; determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant; determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby.
However, in the same filed of endeavor, Li discloses identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby (Para. 61, “After sending the heartbeat detection message to the server, if detecting that no response message returned by the server based on the heartbeat detection message is received after a specified time elapses, the registration center can determine that the server is possibly offline currently because of a running fault, a program restart, etc., and does not push the address of the server to the client.”. Thus, identifying, by the current leader node, nodes from the other of the plurality of nodes that are offline at the current instant based on the responses thereby.);
determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant (Para. 74, “after obtaining the addresses of the servers in the second blockchain node, the registration center can regularly send a heartbeat detection message to the servers corresponding to these addresses. When receiving a response message returned by a server based on the heartbeat detection message after a specified time elapses (or within a specified time), the registration center can determine that the server is still in an online state, and continues to manage an address of the server. When not receiving the response message returned by the server based on the heartbeat detection message after the specified time elapses, the registration center can determine that the server is possibly offline because of a running fault, network instability, etc., and does not continue to manage the address of the server until the server is back online.”. Thus, determining by each of the other of the plurality of nodes a current status thereof being one of online and offline, based on receipt and non-receipt, respectively, of the message thereby at the current instant.);
determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby (Para. 74, “after obtaining the addresses of the servers in the second blockchain node, the registration center can regularly send a heartbeat detection message to the servers corresponding to these addresses. When receiving a response message returned by a server based on the heartbeat detection message after a specified time elapses (or within a specified time), the registration center can determine that the server is still in an online state, and continues to manage an address of the server. When not receiving the response message returned by the server based on the heartbeat detection message after the specified time elapses, the registration center can determine that the server is possibly offline because of a running fault, network instability, etc., and does not continue to manage the address of the server until the server is back online.”. Thus, determining, by the current leader node, if any of the nodes that were identified to be offline at a previous instant when a block was committed to the blockchain is back online at the current instant based on the responses to currently broadcasted message thereby.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of WRIGHT by sending a heartbeat detection message to the servers in order to determine whether the server such as the node of WRIGHT is still in an online or offline state for performing service processing as disclosed by Li (Para. 74). After re-obtaining the address of the server from the registration center when the server is back online, the servers in the first blockchain node and the client can send the service request to the server corresponding to the address by using the obtained address. One of the ordinary skills in the art would have motivated to make this modification in order to ensure the server can perform service processing without any interruption or processing delay by determining the available status of the server such as the node of WRIGHT as suggested by Li (Para. 59-61).
As to claim 11, WRIGHT discloses a computer-program product, comprising a computer readable hardware storage device having computer readable program code stored therein, the program code executable by a processor of a computer system (Para. 35; 50) to implement a method for writing and retrieval of data in a blockchain with a plurality of nodes to manage multiple assets (Para. 36; 43), the method comprising:
designating one of the plurality of nodes at current instant of committing of a block to the blockchain, wherein the designated node is a current leader node (Para. 36, “The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160.”. Para. 281, When a client uses a Cassandra cluster to read or write data, the client may choose to communicate with any node in the cluster, as they are treated indiscriminately. The node chosen by the client becomes a coordinator node, i.e., a current leader node, for performing the particular read or write request being made by the client.);
broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant (Para. 349, “1. A user/client makes a read/write request to a database node. The user/client simultaneously creates and broadcasts a read/write request transaction and sends directly to the blockchain core layer. The user/client also sends the TxID of this transaction to the coordinator database node”. Para. 350, “2. The coordinator behaves as usual by identifying the relevant nodes to which the read/write request pertains. Depending on the request type, the coordinator does the following:”. Para. 351, a. Read request: there is no state mutation required for any node, so the coordinator operator simply forwards the request to the relevant nodes, i.e., broadcasting a message by the current leader node, via Gossip or direct communication (if directly connected). Thus, broadcasting a message by the current leader node to each of the other of the plurality of nodes at the current instant.);
receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message (Para. 354, “3. Upon receiving the request and data from the peers, a replica node confirms, from the core, that the request they have received matches the request details in the request transaction, and return an acknowledgement to the coordinator”. Thus, receiving responses by the current leader node from one or more of the other of the plurality of nodes in response to the message.);
storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein (Para. 244, “if the update is destined for the receiving database node 1202DB, then the receiving database node applies the requested update locally at the copy of the relevant target entry stored locally on the receiving node 1202DB”. Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online. Again this check may be performed directly over a connection within the layered network 1200 between the database node 1202DB in question and one or more of the core nodes 1201, or indirectly via more than one hop.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including deletions) that a node misses while offline is stored and recoverable from the blockchain.”. Thus, storing, by each of the nodes that have determined the current status thereof being offline, corresponding transaction data related to one or more assets managed thereby, locally therein.);
receiving transaction data from each of the nodes that have been determined to be back online (Para. 251, “if a database node 1202DB temporarily becomes disconnected from the layered network 1200, then it can use the record stored on the blockchain 150 to check for any relevant updates and make that/those updates when it comes back online.”. Thus, receiving transaction data from each of the nodes that have been determined to be back online.); and
recording the transaction data to a current block being committed to the blockchain, if there has been no transaction data for the one or more assets recorded in any of the blocks committed to the blockchain between an instant when the corresponding node was last identified to be offline and the current instant (Para. 303, “In the event that a node is unreachable during the deletion (i.e. tombstone and compaction) of a row of data, when that node re-joins the cluster it will treat the record as new and attempt to forward it to other replica nodes. Because the other replica nodes, which were online during the record's deletion, have already deleted the record it is known as a zombie record.”. Para. 310, “When the unreachable node (identified by Node ID) comes back online the coordinator is responsible for replaying the hint to that node and effectively forwarding the write request to it after the fact. This means that a burden, both in disk space and processing, is necessarily placed on the coordinator for updating unreachable nodes when they re-join the network.”. Para. 362, “One advantage is that this reduces the burden on the coordinator to ensure that replica nodes reach the same eventual consistency by repeating the correct order of operations. This is offloaded to the Bitcoin network. Another advantage is that it mitigates the possibility of zombie records, as order of operations (including dele