DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/929,686, which was filed on Oct. 29, 2024, is a Continuation of International Application PCT/CN2023/121990, filed Sept. 27, 2023, which claims foreign priority to Chinese Patent Application CN 202211362635.7, filed Nov. 2, 2022.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
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.
Priority
Acknowledgment is made of applicant's claim for foreign priority, based on Chinese Application CN202211362635.7 filed on Nov. 2, 2022.
On Nov. 22, 2024, the certified priority document was electronically retrieved by USPTO from WIPO.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Status of the Application
This Final Office Action is in response to Applicant’s communication of Dec. 23, 2025.
Claims 1-20 are pending, of which claims 1, 11, and 20 are independent.
All pending claims have been examined on the merits.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on Oct. 29, 2024 has been considered.
Claim Interpretation
The Examiner interprets the claims in light of Figures 1 and 4 of the application, and the descriptions thereof. More specifically, the Examiner interprets that:
The Examiner interprets that “a service network” is equivalent to one copy of a distributed ledger.
The Examiner interprets that “a service node” (and “a service clearing node”) of “a service network” is equivalent to a communication node in a distributed ledger / blockchain that “transmits requests”, as discussed in para. [0040] of the application’s US 2025/0053976.
Examples of “a service node” and “a service network” are: “service node 110n” in “service network A21” of Figure 4, and “service node 120n” in “service network A31” of Figure 4, and “service node 130g” in “service network A41” of the application’s Figure 4, as described in para. [0110] of the application’s US 2025/0053976.
The Examiner interprets that “a multi-blockchain” is equivalent to a multiple copies of a distributed ledger / blockchain.
An example of “a multi-blockchain” collectively refers to: a blockchain corresponding to the “consensus network A11”, and a blockchain corresponding to the “consensus network A22”, and a blockchain corresponding to the “consensus network A32”, and a blockchain corresponding to the “sub-consensus network A42”, all shown in FIG. 1 of the application, and described in para. [0030] of the application’s US 2025/0053976.
The Examiner interprets that the “first network” is one of the copies of the blockchain. See para. [0048] of the application’s US 2025/0053976: “When the consensus network A22 is used as the first network”.
The Examiner interprets that a “service object” corresponds to a specific node in a specific copy of the blockchain. See para. [0054] of the application’s US 2025/0053976: “the first service object (for example, a service object corresponding to a service node in the service network W1)” and “the second service object (for example, a service object corresponding to a service node in the service network W2)”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2022/0374880 A1 to Mallela et al. (“Mallela”. Eff. Filed on May 19, 2021) in view of US 2020/0294048 A1 to Ye (“Ye”. Eff. Filed on Jun. 29, 2018. Published on Sept. 17, 2020).
In regards to claim 1,
1. A data processing method performed by a first consensus node in a first network of a multi-blockchain, comprising:
obtaining, through a service clearing node, a clearing transaction request submitted by a service object comprising a first service object associated with a first service network,
(See Mallela, para. [0002]: “Embodiments are directed to distributed ledger based multi-currency clearing and settlement across multiple and distinct entities.”)
wherein the first service network performs data chaining and data clearing interaction with the first network, and the first network is a consensus network corresponding to a first main chain of the multi-blockchain;
(See Mallela, Abstract: “A distributed ledger system may include a first distributed ledger node associated with a first participant bank that maintains a first participant bank deposit account on a blockchain-based distributed ledger in a distributed ledger network; a second distributed ledger node associated with a second participant bank that maintains a second participant bank deposit account on the blockchain-based distributed ledger; and a third distributed ledger node associated with a liquidity provider that maintains a liquidity provider deposit account on the blockchain-based distributed ledger. A consensus algorithm operates on the distributed ledger nodes and updates the blockchain-based distributed ledger in which multiple copies of the blockchain-based distributed ledger across the distributed ledger nodes, and transactions involving the first participant bank deposit account, the second participant bank deposit account, and/or the liquidity provider deposit account are added to a block to the blockchain-based distributed ledger.”)
(See Mallela, para. [0004]: “Distributed ledger based multi-currency clearing and settlement across multiple and distinct entities are disclosed. In one embodiment, a distributed ledger system may include a first distributed ledger node associated with a first participant bank, wherein the first participant bank maintains a first participant bank deposit account on a blockchain-based distributed ledger in a distributed ledger network; a second distributed ledger node associated with a second participant bank, wherein the second participant bank maintains a second participant bank deposit account on the blockchain-based distributed ledger in the distributed ledger network; and a third distributed ledger node associated with a liquidity provider, wherein the liquidity provider maintains a liquidity provider deposit account on the blockchain-based distributed ledger in the distributed ledger network. A consensus algorithm operates on the distributed ledger nodes and updates the blockchain-based distributed ledger in which multiple copies of the blockchain-based distributed ledger that exist across the distributed ledger nodes, and transactions involving the first participant bank deposit account, the second participant bank deposit account, and/or the liquidity provider deposit account are added to a block to the blockchain-based distributed ledger.”)
(See Mallela, para. [0050]: “In one embodiment, smart contracts may be deployed to distributed ledger 120. The smart contracts may perform various functions, including database functions.”)
The Examiner interprets that the claimed “data clearing” is “a database function” such as those disclosed by Mallela para. [0050].
using a node identifier of the service clearing node carried in the clearing transaction request as a target node identifier;
(See Mallela, para. [0018]: “In one embodiment, wherein the one or more of the plurality of accounting entries that are resynched may be identified as having hashes from the liquidity provider distributed ledger node that do not match hashes generated by the first financial institution distributed ledger node.”)
performing verification on an identity authority of the service clearing node based on the target node identifier and a first authority contract on the first main chain that is configured for node identity verification and node authority verification, to obtain an identity authority verification result corresponding to the service clearing node;
(See Mallela, para. [0015]: “In one embodiment the result of the verification may be replicated to smart contracts executed on the second distributed ledger node and the liquidity provider distributed ledger node.”)
(See Mallela, para. [0071]: “In step 270, a smart contract may verify that the first financial institution's account has sufficient funds for the transaction, whether the crediting account number exists, that the account is not closed or frozen, etc. For example, because the first financial institution is triggering the transactions from the first financial institution's distributed ledger node, the smart contract on the financial institution's distributed ledger node performs this verification. The result of the verification, i.e. whether the validation is successful and if not the failure code, is then replicated to other smart contracts on the other distributed ledger nodes that are parties to the transaction.”)
(See Mallela, claim 12: “The method of claim 8, wherein the result of the verification is replicated to smart contracts executed on the second distributed ledger node and the liquidity provider distributed ledger node.”)
invoking a first authority clearing contract associated with the first authority contract to obtain first service data comprising a service execution result, the first service data being associated with a first-type clearing node corresponding to the first service object that is a service node in the first service network and first ledger data corresponding to the first service data from the first main chain, based on:
the identity authority verification result indicating the service clearing node is the first- type clearing node, and
a node authority of the first-type clearing node being a first-type clearing authority indicating the first-type clearing node has data obtaining authority to obtain the first service data which is visible to the first service object from the first main chain;
(See Mallela, para. [0046]: “In one embodiment, distributed ledger 120 may be a permissioned distributed ledger, accessible only to participating financial institutions 110. In one embodiment, the data in accounts on distributed ledger 120 may be private to financial institutions 110 that maintain the accounts, are involved in the transactions, etc. For example, data may be encrypted with the private key for the host financial institution 110.”)
The Examiner interprets that Mallela’s “permissioned distributed ledger” is an example embodiment of the claimed “the first-type clearing node has data obtaining authority to obtain the first service data”.
obtaining first contract data corresponding to the first ledger data from a contract database corresponding to the first main chain;
…
returning the first clearing response information to the first-type clearing node, to cause the first-type clearing node to recover a sub-ledger corresponding to the first ledger data based on the determined integrity.
(See Mallela, para. [0088]: “For example, bridging accounts are generally used in pairs. Bridging happens when funds are moved from one sub-ledger (e.g., a financial institution's system) to another sub-ledger (e.g., distributed ledger). Thus, bridging accounts that mirrors each other are provided on each side. Both bridging accounts may be fed into the general ledger (GL) by the two different subledgers at the end of day, and the GL validates that the position of both bridging accounts are the same, otherwise it will cause a reconciliation break.”)
(See Mallela, para. [0091]: “In step 525, the liquidity provider may debit the payer participant bank's off-chain account, and credit the payer participant bank's on-chain account. In one embodiment, the liquidity provider may use an internal bridging account to traverse between sub-ledgers of the liquidity provider.”)
The Examiner interprets that the Mallela’s “bridging” is an example embodiment of the claimed “recover a sub-ledger corresponding to the first ledger data”.
However, under a conservative interpretation of Mallela, it could be argued that Mallela does not explicitly teach the following features, which are taught by Ye:
using the first service data, the first ledger data, and the first contract data as first clearing response information corresponding to the clearing transaction request, wherein the first ledger data comprises a block header comprising a block Merkle tree root, and a Merkle verification path for reconstructing a reconstructed Merkle tree root,
(See Ye, para. [0080]: “The Merkle verification path is specifically a path formed by sibling nodes (that is, neighboring nodes) that are obtained by traversing the Merkle tree based on the transaction value of a transaction. When SPV is performed on a transaction, the Merkle verification path of the transaction can be used as a calculation parameter for inversely calculating a hash value corresponding to the root node of the Merkle tree at which the transaction is located.”)
wherein the integrity of the first service data is determined by comparing the reconstructed Merkle tree root with the block Merkle tree root in the block header; and
(See Ye, para. [0084]: “In the present specification, after obtaining the Merkle verification path of the transaction in the Merkle tree including the target block of the transaction, the hash value of the block header of the target block (that is, the hash value of the root node of the Merkle tree of the target block) can be calculated based on the calculation procedure specified by the SPV protocol. Then, it can be determined whether the calculated hash value of the block header of the target block matches the hash value stored in the block header of the target block. If the calculated hash value of the block header of the target block matches the hash value stored in the block header of the target block, it can be determined that the transaction is included in the target block; that is, the product quality inspection report has been successfully stored in the distributed database of the consortium blockchain. Alternatively, if the calculated hash value of the block header of the target block does not match the hash value stored in the block header of the target block, it indicates that the transaction is not included in the target block; that is, the product quality inspection report is not successfully stored in the distributed database stored in the consortium blockchain.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for “Distributed ledger based multi-currency clearing and settlement”, as taught by Mallela above, with “Blockchain-based data verification method and apparatus, and electronic device”, as further taught by Ye above, because as Ye discloses in para. [0020], the described data verification can help to determine whether the content of the target data in the blockchain has been tampered with, and quickly identify abnormal data.
In regards to independent claim 11, it is rejected on the same grounds as independent claim 1.
In regards to dependent claims 12-19, they are rejected on the same grounds as independent claim 2-9.
In regards to independent claim 20, it is rejected on the same grounds as independent claim 1.
In regards to claim 2, both of the Mallela and Ye references fail to teach the following claimed feature in combination with the features of claim 1:
wherein a first chain entrance corresponding to the first network has a chain access count threshold indicating a maximum concurrent request access count obtained through the first chain entrance that corresponds to the first main chain and authorized access data information stored in the first chain entrance, the authorized access data information being information of an authorized object allowed to access the first main chain and that is obtained by the first consensus node from the target main chain,
In regards to claim 3, both of the Mallela and Ye references fail to teach the following claimed feature in combination with the features of claims 1 and 2:
wherein the authorized access data information comprises public key information of the service object, wherein the data clearing transaction request comprises object signature information of the service object obtained based on the service clearing node performing signature addition on a first clearing transaction requested by the service object based on private key information of the service object,
wherein the private key information of the service object and the public key information of the service object form a key pair and are configured by the target consensus node based on the object data information submitted by the service object, and
In regards to claim 4, both of the Mallela and Ye references fail to teach the following claimed feature in combination with the features of claims 1 and 2:
4. (Original): The data processing method according to claim 3, further comprising
determining, based on the signature verification result indicating the signature verification failed, the service object to be an invalid object, and rejecting the data clearing transaction request.
In regards to claim 5, both of the Mallela and Ye references fail to teach the following claimed feature in combination with the features of claim 1:
invoking a first authority verification method of the first authority contract on the service clearing node, to obtain an authority verification result; and using, based on the authority verification result indicating the node authority is the first-type clearing authority, the first-type clearing node as the identity authority verification result.
In regards to claim 6, both of the Mallela and Ye references fail to teach the following claimed feature in combination with the features of claims 1 and 2:
wherein the invoking the first authority clearing contract comprises:
invoking a data clearing method of the first authority contract;
accessing the first authority clearing contract, and writing the target node identifier into the first authority clearing contract;
invoking the first authority clearing contract to obtain the first target block associated with the first-type clearing node from the first main chain;
In regards to claim 7, both of the Mallela and Ye references fail to teach the claimed features in combination with features of claims 1, 2, and 6.
In regards to claim 8, both of the Mallela and Ye references fail to teach the claimed features in combination with features of claims 1, 2, 6, and 7.
In regards to claim 9, both of the Mallela and Ye references fail to teach the claimed features in combination with features of claims 1, 2, 6, and 7.
In regards to claim 10, both of the Mallela and Ye references fail to teach the claimed features in combination with features of claims 1, 2, 6, 7, and 9.
Response to Amendments
Re: Claim Rejections - 35 USC § 101
The 35 USC § 101 rejection has been withdrawn, because the Examiner holds that the following features newly added to the independent claims recite a practical application of an abstract idea (“returning the first clearing response information to the first-type clearing node, to cause the first-type clearing node to recover a sub-ledger corresponding to the first ledger data based on the determined integrity”):
using the first service data, the first ledger data, and the first contract data as first clearing response information corresponding to the clearing transaction request, wherein the first ledger data comprises a block header comprising a block Merkle tree root, and a Merkle verification path for reconstructing a reconstructed Merkle tree root, wherein the integrity of the first service data is determined by comparing the reconstructed Merkle tree root with the block Merkle tree root in the block header; and
returning the first clearing response information to the first-type clearing node, to cause the first-type clearing node to recover a sub-ledger corresponding to the first ledger data based on the determined integrity.
Re: Claim Rejections - 35 USC § 102/103
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
March 27, 2026