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
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on January 8th, 2025 and June 30th, 2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities: The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 5-7, 9, 11-12, 15-17 and 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tian (US Publication No. 2021/0081403 – “Tian”).
Regarding claim 11, Tian teaches A distributed data management system comprising: a plurality of data management apparatuses comprising: a first data management apparatus corresponding to a first blockchain node in a blockchain network; (Tian paragraphs [0067-0068], FIG. 3 is a diagram illustrating an example of a log-structured storage system 300 in accordance with embodiments of this specification. The log-structured storage system 300 can store data of a distributed ledger system (e.g., a blockchain network) and/or a blockchain-based centralized ledger system (e.g., a universal auditable ledger service system) that stores data on one or more blockchains (collectively, referred to as a blockchain-based ledger system). In some embodiments, the log-structured storage system 300 can be implemented by each consensus node of a blockchain network or a central node of the blockchain-based centralized ledger system. Data management storage system may utilize blockchain nodes in a blockchain network) a second data management apparatus corresponding to a second blockchain node in the blockchain network; a first storage mounted to the first data management apparatus; (Tian paragraph [0116], In some embodiments, the file systems can further include long-term file systems such as a self-built distributed system (e.g., distributive storage system 340 built by a client node of the blockchain-based ledger system). For example, the first-level pool 402 can further include NVME devices of a distributed storage system generated by a client node of the blockchain network (e.g., as part of the distributive storage system 340) that store hot log files 410. The blockchain network can use a plurality of nodes mounted on storage) a second storage mounted to the second data management apparatus, wherein the first storage and the second storage are configured to form a storage resource pool of the blockchain network; (Tian paragraph [0116], In some embodiments, the file systems can further include long-term file systems such as a self-built distributed system (e.g., distributive storage system 340 built by a client node of the blockchain-based ledger system). For example, the first-level pool 402 can further include NVME devices of a distributed storage system generated by a client node of the blockchain network (e.g., as part of the distributive storage system 340) that store hot log files 410. The second-level pool 404 can further include SSD devices of the distributed storage system that store warm log files 412. The third-level pool 406 can further include HDD devices of the distributed storage system that store cold log files 414. The fourth-level pool 408 can further include SMR devices of the distributed storage system that store archived files 416. In some embodiments, all file systems can be provided with a unified interface with the overall log-structured storage system 300. A storage resource pool corresponding to blockchain network nodes is configured) and a target data management apparatus configured to: receive a data operation request for performing an input/output (I/O) operation on target data; (Tian paragraph [0035], In some embodiments, transaction data can include data related to inputs and outputs of a series of operations. In some embodiments, the transaction data can include data related to exchanges of things of value (e.g., assets, products, services, currency). Target data (i.e., transaction data) can be used for input/output operations) obtain, from the blockchain network based on the data operation request, a first storage address of a plurality of data shards of the target data; (Tian paragraphs [0076-0077], In some embodiments, the front-end I/O subsystem 310 stores index information in the memory 315 that indicates a mapping correspondence between the data (e.g., transaction data, block data, and state data) and the data log files that store the data so as to address or retrieve the data. In some embodiments, the index data in the memory can be organized using a log-structured merge (LSM) method. In some embodiments, the index of newly written data can be stored in the memory 315 and flushed into the index log file 380 when the memory usage exceeds a predetermined threshold value. As such, the indexes of old data can be stored in the index log file 380 in a disk storage or hard drive storage and free up space for caching an index of new hotspot data in the memory 315. The blockchain network can provide address information for particular pieces (i.e., shards) of data targeted by operations) and perform the I/O operation on the target data in the storage resource pool based on the data operation request and based on the first storage address (Tian paragraph [0034], In some embodiments, the state data can be further categorized into a current state and a history state. In some embodiments, the current state is the state data corresponding to the latest block and is the data source when the latest transaction on the blockchain network is executed. In some embodiments, the history state is a content-addressed data set that stores all state data from the genesis block to the latest block. In some embodiments, the history state data is stored in a historic state tree. The historic state tree can store state information as key-value pairs (KVPs) expressed as <hash (node value), node value>, which is content-addressable. The value or node value can be account states of accounts associated with the blockchain node and the key can be the hash values of the corresponding account states. In some embodiments, current state data is stored in a current state tree. In some embodiments, the current state tree can be location-addressed based on one or more location related identifiers (IDs). For example, the current state tree can store state information as KVPs expressed as <node ID, node value>, where the node values can be addressed based on their corresponding node IDs. The data transactions can be performed on blockchain nodes (corresponding to the storage pools) based on requests and address information).
Claim 1 is the corresponding method claim to system claim 11. It is rejected with the same references and rationale.
Regarding claim 12, Tian teaches The distributed data management system according to claim 11, wherein the data operation request is a write request, and wherein the target data management apparatus is further configured to: obtain an allocation policy based on the data operation request and based on a smart contract of the blockchain network; (Tian Fig. 5-6, paragraphs [0014-0015], FIG. 5 is a flowchart illustrating an example of a process for performing a write operation of a log-structured storage system, in accordance with embodiments of this specification. FIG. 6 is a flowchart illustrating an example of a process for generating index in connection with a write operation of a log-structured storage system, in accordance with embodiments of this specification. The write request may use an allocation policy for the blockchain network, which may include a smart contract, see Tian paragraph [0033], In some embodiments, state data can be assembled to a globally shared state (also referred to as a world state). The world state can include a mapping between an account address and an account state. The world state can be stored in data structures such as a Merkle Patricia tree (MPT). In some embodiments, for example, in a smart contract scenario, the state data can be designed based on the content of a Merkle Tree. It is an incremental content-addressed data set. The storage space occupied by the state data is often large) allocate, according to the allocation policy, a storage resource to the data shards from the storage resource pool in order to obtain the first storage address; (Tian paragraph [0044], In some embodiments, the log-structured storage system can provide a tier pool manager that manages multiple levels of pools of storage devices. In some embodiments, each pool supports multiple disks or storage devices in a cluster. The tier pool manager can manage the space, pressure, and health of the pools. In some embodiments, the log-structured storage system can provide a migration task manager that manages two-way migration tasks for data between different levels of storage devices, manages the life cycle of migration tasks, result callbacks, statistics, etc. In some embodiment, the log-structured storage system can provide a migration scheduler that supports pluggable policies, manages data migration strategies, and provides data create/query/update/delete interfaces. The operations (i.e., write operations) can be allocated to particularly data based on an allocation corresponding to address information, such as described in Tian paragraph [0170], For example, a stream configured for block data can write block data into a data log file allocated to store block data, while a stream configured for transaction data can read certain request transaction data from a data log file that includes the transaction data) write the data shards into the storage resource pool based on a second storage address of at least one data shard of the data shards; and store the first storage address in a distributed ledger of the blockchain network (Tian paragraph [0045], The disclosed log-structured storage system adopts the idea of a merge-tree (LSM-Tree) architecture. In some embodiments, the log-structured storage system can include multiple log-structured storage instances (or streams), where each log-structured storage instance is responsible for storing and managing data for a distributed ledger system (e.g., a blockchain system) or a blockchain-based centralized ledger system. In some embodiments, the log-structured storage system can convert random write operations into sequential append operations so as to mitigate write amplification issues resulting from frequent “dirty” page flush due to large number of random write operations. In some embodiments, the log-structured storage system can delay write flush operations in high-performance scenarios and reduce the number of sync operations to improve the efficiency and performance of the overall system. The blockchain network may utilize a distributed ledger for performing write operations to a determined storage system based on address information).
Claim 2 is the corresponding method claim to system claim 12. It is rejected with the same references and rationale.
Regarding claim 15, Tian teaches The distributed data management system according to claim 12, wherein the target data management apparatus is further configured to: determine at least one of a first hash value of the target data, a plurality of second hash values of each of the data shards, or a data attribute of the target data, wherein each of the second hash values corresponds to one of the data shards; (Tian paragraph [0031], In some embodiments, each type of the blockchain data can be received in the form of a key-value pair (KVPs) expressed as <hash (value), value>. The value can actual data of one or more of a block, a transaction, or a state of a blockchain network. The key can be the hash of the value. A plurality of hash values may be determined for data corresponding to the blockchain network) and store at least one of the first hash value, the second hash values, or the data attribute in the distributed ledger (Tian paragraph [0030], In general, data generated and/or stored in a distributed ledger system (e.g., a blockchain network) can be referred to as blockchain data. The blockchain data can include or be categorized into transaction data, block data, state data, and index data. In some embodiments, data generated and/or stored in a blockchain-based centralized ledger system (e.g., a universal auditable ledger service system) can include or be categorized into transaction data, block data, and index data. The ledger of the blockchain can store various data categorized into data type (i.e., data attributes), also see paragraph [0031] as described above for hash data stored).
Claim 5 is the corresponding method claim to system claim 15. It is rejected with the same references and rationale.
Regarding claim 16, Tian teaches The distributed data management system according to claim 11, wherein the data operation request is a read request, and wherein the target data management apparatus is further configured to: obtain, based on the read request, the first storage address from a distributed ledger of the blockchain network; (Tian paragraph [0045], The disclosed log-structured storage system adopts the idea of a merge-tree (LSM-Tree) architecture. In some embodiments, the log-structured storage system can include multiple log-structured storage instances (or streams), where each log-structured storage instance is responsible for storing and managing data for a distributed ledger system (e.g., a blockchain system) or a blockchain-based centralized ledger system. In some embodiments, the log-structured storage system can convert random write operations into sequential append operations so as to mitigate write amplification issues resulting from frequent “dirty” page flush due to large number of random write operations. In some embodiments, the log-structured storage system can delay write flush operations in high-performance scenarios and reduce the number of sync operations to improve the efficiency and performance of the overall system. The blockchain network may utilize a distributed ledger for performing write operations to a determined storage system based on address information, which can also correspond to read operations, see Tian Fig. 7-8, paragraphs [0016-0017], FIG. 7 is a flowchart illustrating an example of a process for performing a read operation of a log-structured storage system, in accordance with embodiments of this specification. FIG. 8 is a flowchart illustrating an example of a process for improving a read operation of a log-structured storage system, in accordance with embodiments of this specification) obtain the data shards from the storage resource pool based on the first storage address; and aggregate the data shards in order to obtain the target data (Tian paragraph [0165], In some embodiments, multiple streams can be combined into a bundle to provide flexible implementations suitable for a specific application of a distributed ledger system and/or a blockchain-based centralized ledger system. The described techniques can support services in a distributed ledger system (e.g., blockchain networks), a blockchain-based centralized ledger system, or both. In some embodiments, the two types of systems can have different streams that are customized or otherwise configured according to the needs of the two types of the log-structured storage systems 300. The individual data shards (i.e., data streams) may be aggregated (i.e., combined) by address to form a ledger for operations).
Claim 6 is the corresponding method claim to system claim 16. It is rejected with the same references and rationale.
Regarding claim 17, Tian teaches The distributed data management system according to claim 16, wherein the target data management apparatus is further configured to: obtain an aggregation policy based on the data operation request and based on a smart contract of the blockchain network; and aggregate the data shards according to the aggregation policy in order to obtain the target data (Tian paragraph [0165], In some embodiments, multiple streams can be combined into a bundle to provide flexible implementations suitable for a specific application of a distributed ledger system and/or a blockchain-based centralized ledger system. The described techniques can support services in a distributed ledger system (e.g., blockchain networks), a blockchain-based centralized ledger system, or both. In some embodiments, the two types of systems can have different streams that are customized or otherwise configured according to the needs of the two types of the log-structured storage systems 300. The individual data shards (i.e., data streams) may be aggregated (i.e., combined) by address to form a ledger for operations).
Claim 7 is the corresponding method claim to system claim 17. It is rejected with the same references and rationale.
Regarding claim 19, Tian teaches The distributed data management system according to claim 11, wherein the target data management apparatus is further configured to: obtain, from a blockchain node corresponding to the target data management apparatus, first meta information of a first data shard of the data shards in a third storage mounted to the target data management apparatus; (Tian paragraph [0071], In some embodiments, data that are processed by the front-end I/O subsystem 310 can be stored in the following two types of log files: (1) data log files (e.g., data log files 390, 362, 364, 366, 372, 374, and 376) that store substantive data such as blockchain data (e.g., transaction data, block data, state data) and self-descriptive metadata; and (2) index log files (e.g., index log files 380) that store index information that indicate physical locations of the data (e.g., identifiers and offsets of the data log files). In some embodiments, the data log file does not store index information, whereas the index information is maintained by a separate index log file. The blockchain data may contain metadata (i.e., meta information) in a plurality of different storages for the subsystem, such as described in Tian paragraph [0072]) obtain second meta information of the first data shard from the third storage; determine, when the first meta information does not match the second meta information, that a fault occurs; and store fault information of the fault in a distributed ledger of the blockchain network (Tian paragraph [0072], In some embodiments, the front-end I/O subsystem 310 can be configured to perform write operations to write blockchain data into data log files 390. In some embodiments, the blockchain data can include block data, transaction data, or state data generated by a blockchain network or a distributed ledger system. In some embodiments, the blockchain data can include block data and transaction data generated by a blockchain-based centralized ledger system. In some embodiments, data written to the data log files 390 can include metadata describing the data blocks, such as transaction hash values and sequence values, block hash values and block numbers, snapshot version numbers, cyclic redundancy check (CRC) code, encryption information, and so on. In some embodiments, the data log files 390 can be an append-only file. The metadata for a plurality of data entries can be stored in a ledger and compared to determine various faults through methods such as CRC, and other faults such as described in Tian paragraph [0062]).
Claim 9 is the corresponding method claim to system claim 19. It is rejected with the same references and rationale.
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.
Claim(s) 3-4, 8, 13-14 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tian (US Publication No. 2021/0081403 – “Tian”) as applied to claims 2, 6, 12 and 16 above, and further in view of Mu et al. (US Publication No. 2025/0045746 – “Mu”).
Regarding claim 13, Tian teaches The distributed data management system according to claim 12, wherein the target data management apparatus is further configured to: obtain a sharding policy based on the data operation request and based on the smart contract of the blockchain network; (Tian paragraph [0033], In some embodiments, state data can be assembled to a globally shared state (also referred to as a world state). The world state can include a mapping between an account address and an account state. The world state can be stored in data structures such as a Merkle Patricia tree (MPT). In some embodiments, for example, in a smart contract scenario, the state data can be designed based on the content of a Merkle Tree. It is an incremental content-addressed data set. The storage space occupied by the state data is often large. A smart contract for the blockchain network may be used to provide data allocation/assignment) write copies of each data shard into the storage resource pool based on a third storage address of the copies of each of the data shards; and store the third storage address in the distributed ledger (Tian paragraph [0045], The disclosed log-structured storage system adopts the idea of a merge-tree (LSM-Tree) architecture. In some embodiments, the log-structured storage system can include multiple log-structured storage instances (or streams), where each log-structured storage instance is responsible for storing and managing data for a distributed ledger system (e.g., a blockchain system) or a blockchain-based centralized ledger system. In some embodiments, the log-structured storage system can convert random write operations into sequential append operations so as to mitigate write amplification issues resulting from frequent “dirty” page flush due to large number of random write operations. In some embodiments, the log-structured storage system can delay write flush operations in high-performance scenarios and reduce the number of sync operations to improve the efficiency and performance of the overall system. The blockchain network may utilize a distributed ledger for performing write operations to a determined storage system based on address information).
Tian does not teach obtain, according to the sharding policy, a sharding algorithm, a first quantity of shards, and a second quantity of copies of each data shard of the data shards; perform sharding on the target data based on the sharding algorithm and the first quantity of shards in order to obtain the data shards.
However, Mu teaches obtain, according to the sharding policy, a sharding algorithm, a first quantity of shards, and a second quantity of copies of each data shard of the data shards; perform sharding on the target data based on the sharding algorithm and the first quantity of shards in order to obtain the data shards; (Mu paragraph [0123], In order to improve the blockchain reconciliation performance and reconciliation fault tolerance capability, the present disclosure uses a flexibly configurable data sharding algorithm to shard data to be reconciled based on an idea of “binary search”. The essence of reconciliation is to search massive data for inconsistent error transaction records, such that improving a search speed is a key to improvement in reconciliation performance and efficiency. Hash values generated by same data must be the same. According to the principle, constructing as much data as possible into one shard can greatly improve the reconciliation efficiency. In view of this, the present disclosure designs a reconciliation data sharding algorithm, that is, specific data sharding algorithm parameters are flexibly adjusted according to a plurality of factors such as business operation conditions, reconciliation error rates, the number of participating institutions, and a digital currency system unitization technical architecture, and the data to be reconciled is divided into several parts. A data sharding algorithm may be used on target data to determine a first and second quantity, with various parts being reconciled of shards based on given parameters).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Tian with those of Mu. Mu teaches using a sharding algorithm policy for determining a quantity of data for data shards, which can allow improved blockchain reconciliation and performance when performing operations (i.e., see Mu paragraph [0123], In order to improve the blockchain reconciliation performance and reconciliation fault tolerance capability, the present disclosure uses a flexibly configurable data sharding algorithm to shard data to be reconciled based on an idea of “binary search”. The essence of reconciliation is to search massive data for inconsistent error transaction records, such that improving a search speed is a key to improvement in reconciliation performance and efficiency. Hash values generated by same data must be the same).
Claim 3 is the corresponding method claim to system claim 13. It is rejected with the same references and rationale.
Regarding claim 14, Tian in view of Mu teaches The distributed data management system according to claim 13, wherein each of the data shards comprises a plurality of copies, and wherein the target data management apparatus is further configured to write the copies of each data shard (Tian paragraphs [0037-0038], When more and more transactions are entered into the blockchain, blockchain data (e.g., state data and block data) can grow larger in size. In a DLS, every node of the DLS stores an entire copy of the blockchain, which can take a large amount of storage spaces, even if some of the old block data or state data are not frequently visited. In some embodiments, blockchain data are stored by the log-structured system in data files, and the data files are continuously appended and divided based on time. In some embodiments, data may not be rearranged according to key sorting (e.g., data is not sorted by key values or other metric so that hot and cold data are not mixed in multiple data log files), thus greatly reducing the technical challenges of tiering implementation. Copies of the data from the blockchain can be stored) into different types of storage media in the storage resource pool (Tian paragraph [0042], In some embodiments, different types of log files can have different storage strategies. For example, data log files that are not accessed for a relatively long time can be stored in inexpensive and relatively low-speed storage devices such as NAS/OSS, and can be processed using compression and erasure coding for storage. As another example, index log files can be stored on high-speed storage devices such as cloud disks. Different types of storage media can be used depending on various factors).
Claim 4 is the corresponding method claim to system claim 14. It is rejected with the same references and rationale.
Regarding claim 18, Tian in view of Mu teaches The distributed data management system according to claim 16, wherein the target data management apparatus is further configured to: obtain local hash values of the data shards using a hash algorithm; (Mu paragraph [0056], According to another example of the present disclosure, the shard hash values are fed onto a blockchain node in a form of a list. Moreover, when the shard hash value of the blockchain node of the institution is compared with the shard hash value of the transaction reconciliation platform, comparison may be performed by performing Cartesian product operation on a shard hash value list of the blockchain node of the institution and a shard hash value list of the transaction reconciliation platform. The inconsistent shard may be obtained by comparing the shard hash values, and then different transaction records may be obtained by further comparing the record hash value corresponding to each transaction record included in the inconsistent shard. The institution and the transaction reconciliation platform may be notified of the inconsistent transaction record. Hash values of data shards local to the blockchain network may be obtained) obtain on-chain hash values of the data shards from the blockchain network; (Mu paragraph [0006], In view of this, examples of the present disclosure provide a reconciliation method, apparatus and system based on a blockchain. A storage space of the blockchain can be saved, and an influence caused by insufficient blockchain performance can be greatly reduced and mitigated. A blockchain-based smart contract program can complete automatic comparison and automatic error handling, which greatly improves efficiency, and a reconciliation result cannot be tampered with. Moreover, since only hash data is stored on a chain, hash has a function of not being able to reverse original data, and an on-chain data privacy problem is solved through the feature of hash. On-Chain hash values of the blockchain network may be determined) start, when the local hash values match the on-chain hash values, the aggregation of the data shards in order to obtain aggregated data; determine a first hash value of the aggregated data; obtain a second hash value of the target data from the blockchain network; (Mu paragraph [0055], According to transaction initiation time points of the transaction records, the transaction records with different transaction initiation time points may be sharded. When record hash values corresponding to the transaction records are spliced, the transaction records may be sorted according to the transaction initiation time points of the transaction records, and then the record hash values are spliced in sequence. Similarly, when the shard hash values are spliced, shards are sorted according to the transaction initiation time points of the transaction records corresponding to each shard, and then the shard hash values are spliced in sequence. A plurality of hash values from the blockchain network may be determined for each data shard, and can be spliced together to form aggregate data) and determine the aggregated data as the target data when the first hash value matches the second hash value (Tian paragraph [0165], In some embodiments, multiple streams can be combined into a bundle to provide flexible implementations suitable for a specific application of a distributed ledger system and/or a blockchain-based centralized ledger system. The described techniques can support services in a distributed ledger system (e.g., blockchain networks), a blockchain-based centralized ledger system, or both. In some embodiments, the two types of systems can have different streams that are customized or otherwise configured according to the needs of the two types of the log-structured storage systems 300. The individual data shards (i.e., data streams) may be aggregated (i.e., combined) by address to form a ledger for operations), which can be done when hash values match, see Tian paragraph [0061], In further detail, the consensus node generates a block header, hashes all of the transactions in the block, and combines the hash value in pairs to generate further hash values until a single hash value is provided for all transactions in the block (the Merkle root hash). This hash is added to the block header. The consensus node also determines the hash value of the most recent block in the blockchain (i.e., the last block added to the blockchain). The consensus node also adds a nonce value, and a timestamp to the block header).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Tian with those of Mu. Mu teaches using a sharding algorithm policy for determining a quantity of data for data shards, which can allow improved blockchain reconciliation and performance when performing operations (i.e., see Mu paragraph [0123], In order to improve the blockchain reconciliation performance and reconciliation fault tolerance capability, the present disclosure uses a flexibly configurable data sharding algorithm to shard data to be reconciled based on an idea of “binary search”. The essence of reconciliation is to search massive data for inconsistent error transaction records, such that improving a search speed is a key to improvement in reconciliation performance and efficiency. Hash values generated by same data must be the same).
Claim 8 is the corresponding method claim to system claim 18. It is rejected with the same references and rationale.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tian (US Publication No. 2021/0081403 – “Tian”) as applied to claims 1 and 11 above, and further in view of Tong (US Publication No. 2019/0280855 – “Tong”).
Regarding claim 20, Tian in view of Tong teaches The distributed data management system according to claim 11, wherein the target data management apparatus is further configured to: (see claim 11 above) read fault information from the blockchain network; obtain, when the fault information represents that a first data shard of the data shards in a third storage mounted to the target data management apparatus is tampered with, deleted, or lost, the first data shard from a fourth storage mounted to another data management apparatus; (Tong paragraph [0036], To ensure data security, usually, there can be a plurality of blockchain network storage nodes in the blockchain technology. As such, the blockchain can be stored in the plurality of blockchain network storage nodes. When one blockchain network storage node is faulty (for example, a breakdown or a data loss occurs), any other blockchain network storage node that is not faulty can replace the node to work, and the faulty blockchain network storage node can be restored based on data stored in the blockchain network storage node that is not faulty (that is, data stored in the blockchain. Fault information can be obtained from a storage node in the blockchain network indicating various potential faults such as data loss as described above) locally store the first data shard; and store an updated storage address of the first data shard in a distributed ledger of the blockchain network (Tong paragraph [0036], For example, the mapping relationship between an identifier and a blockchain can be stored locally in the storage device, so that it can be more convenient for reading and writing. Likewise, a mapping relationship between the identifier and the key pair can be stored in a place based on an actual situation. In addition, it is worthwhile to further note that the blockchain network storage node and the storage device here can be the same device, or can be different devices. Implementations are not limited in the present application. Locally stored data in a blockchain node can be stored and updated based on fault detection (i.e., blockchain node replacement), see Tong paragraph [0036], As such, the blockchain can be stored in the plurality of blockchain network storage nodes. When one blockchain network storage node is faulty (for example, a breakdown or a data loss occurs), any other blockchain network storage node that is not faulty can replace the node to work, and the faulty blockchain network storage node can be restored based on data stored in the blockchain network storage node that is not faulty (that is, data stored in the blockchain)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teachings of Tian with those of Tong. Tong teaches detecting faults in blockchain network data, which can be used to detect faulty information (i.e., tampered or lost data), which enables the device to perform operations to restore data reliability (I.e., see Tong paragraph [0036], To ensure data security, usually, there can be a plurality of blockchain network storage nodes in the blockchain technology. As such, the blockchain can be stored in the plurality of blockchain network storage nodes. When one blockchain network storage node is faulty (for example, a breakdown or a data loss occurs), any other blockchain network storage node that is not faulty can replace the node to work, and the faulty blockchain network storage node can be restored based on data stored in the blockchain network storage node that is not faulty (that is, data stored in the blockchain).
Claim 10 is the corresponding method claim to system claim 20. It is rejected with the same references and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shannon et al. (US Publication No. 2023/0048589) teaches a blockchain network ledger system that is tamper-resistant through the use of distributed ledgers with a plurality of blockchain notes utilizing redundancy to determine data consistency for data update operations/transactions (i.e., see Shannon paragraph [0016], setting up a blockchain network comprised of a distributed, and therefore highly tamper-resistant, ledger distributed among a network of nodes; issuing each user an attestable pre-fabricated and digitally signed virtualized environment on approved hardware that comes with all of the functionality required for the user's role on the project implemented as one of a set of virtual machine templates fashioned from a digitally signed and approved pre-fabricated image, the users' virtualized environments issue commands to the blockchain network based on user actions, the network of nodes communicate amongst themselves via blockchain consensus protocols to manage the state of the ledger and any updates that result from those issued commands; and, verifying that assigned developer time is valid, and if so, record each development action on the ledger to enable extensive tracking and auditing of the end-to-end software development process).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONAH C KRIEGER whose telephone number is (571)272-3627. The examiner can normally be reached Monday - Friday 8 AM - 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rocio Del Mar Perez-Velez can be reached at (571)-270-5935. 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.
/J.C.K./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights