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 .
Status of Claims
This is the final office action in response to the applicant’s arguments/remarks filed on April 9, 2026.
Claims 1, 3, 5-7, 9, 12, 15-16, 18, and 25-26 have been amended; claims 4, 8, 10, and 21-24 have been canceled.
Claims 1-3, 5-7, 9, 11-20, and 25-26 are pending and have been examined.
Responses to Arguments/Remarks
Claim Objections:
The amended claims have overcome the claim objections, and the claim objections are now withdrawn.
35 U.S.C. § 112:
The amended claims have overcome the 112 rejections and the 112 rejections are now withdrawn. However, the amended claims cause more 112 issues, and the applicant has been advised to refer to the 112 rejection section for details.
35 U.S.C. § 101:
The amended claim 26 has overcome the 101 rejection that is directed to non-statutory subject matter, and the 101 rejection of claim 26 that is directed to non-statutory subject matter is now withdrawn.
The applicant contends that the amended claims integrate the judicial exception into a practical application. The examiner agrees, and the 101 rejection of claims 1-7, 9, 11-20, and 25 is now withdrawn.
35 U.S.C. § 103:
First, the applicant contends that lyu does not teach or suggest “the batch hash value.” The examiner respectfully disagrees. lyu discloses “the batch hash value” (see paragraphs 2-4, page 8 and paragraph 4, page 7). Lyu discloses performing reconciliation based on the hash values of account data during a time period. One of ordinary skill in the art knows that account data, during the time period, may comprise/be related to a plurality of transactions. All the transaction information of the account data during the time period is a reconciliation batch transaction record.
Second, Zou, by the broadest reasonable interpretation, discloses the shard hash values (see paragraphs 3-5, page 8; page 9; and pages 12-13). Zou discloses that transaction data of a reconciliation could comprise a plurality of blocks and each block comprises a plurality of transactions. Each data block can be represented by the corresponding data block hash.
Additionally, Chen, discloses the shard hash values as well (see pages 9-10). Furthermore, Chen, by the broadest reasonable interpretation, discloses wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record, and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard (see pages 9-10). All transactions in a transaction reconciliation are grouped as a reconciliation batch transaction record. Each transaction hash is generated; at least two intermediate hashes are obtained by sequentially joining transaction hashes; and the root hash, as a batch hash value, is obtained by sequentially joining the at least two intermediate hashes.
Regarding utilizing a smart contract to perform transaction reconciliation, the examiner would like to point out that the smart contract is program code/application that can be executed to perform the defined functionalities. Lyu discloses including program code/application in a blockchain system to perform the transaction reconciliation (see the penultimate paragraph, page 5, “[f]or example, to solve the reconciliation problem, a code containing a reconciliation flow may be written in the blockchain system 100, and then a node of any reconciliation party may invoke the code containing the reconciliation flow after receiving the reconciliation transaction through broadcasting the reconciliation transaction, which is more efficient and timely compared with manual reconciliation”), and lyu further discloses that the program code/application of the transaction reconciliation can be implemented as a smart contract (see paragraphs 5-9, page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100”). Zou and Chen disclose performing steps of a transaction reconciliation process by program code/application. Furthermore, Zou further discloses deploying and executing a reconciliation contract that comprises reconciliation logic (see page 12). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement and utilize a smart contract to perform all steps of the transaction reconciliation process, so that the transactions reconciliation process can be effectively performed by the smart contract.
The applicant’s amendments have overcome the 35 U.S.C. § 103 rejection. However, there are new grounds of rejection necessitated by the applicant’s amendments as detailed in the 35 U.S.C. § 103 rejection section.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
a feed system of a transaction reconciliation platform in claims 9 and 26.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. The specification discloses that a transaction reconciliation platform includes two parts of a blockchain node and a feed system (see paragraph [0042] of the publication), and the specification discloses the functionalities performed by the feed system (see paragraphs [0062]-[0071] of the publication). But the specification does not clearly disclose what the feed system is, software, firmware, or hardware.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 9, 11-17, and 26 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 9 recites “a feed system of a transaction reconciliation platform triggering …; the feed system notifying …; the feed system triggering … and generating a reconciliation result,” and claim 26 recites “a feed system of a transaction reconciliation platform triggering …; the feed system notifying …; the feed system triggering … and generating a reconciliation result.” The specification does not provide an adequate structure to perform the claimed function listed above. The specification does not demonstrate that the applicant has made an invention that achieves the claimed function because the invention is not described in sufficient details such that one of ordinary skill in the art can reasonably conclude that the inventor has possession of the claimed invention.
Dependent claims 11-17 are rejected because they depend on the rejected independent claim 9.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5-7, 9, 11-17, and 26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant) regards as the invention.
Claim 1 recites “a smart contract deployed on a transaction reconciliation platform acquiring a batch hash value fed onto the blockchain by an institution to be reconciled and a batch hash value fed onto the blockchain by a transaction reconciliation platform respectively.” It is unclear whether the transaction reconciliation platform where a smart contract is deployed is the same transaction reconciliation platform that feeds a batch hash value. If they are the same transaction reconciliation platform, the second underlined “a transaction reconciliation platform” should be changed to “the transaction reconciliation platform.” If they are different transaction reconciliation platforms, the examiner suggests changing them to “a first transaction reconciliation platform” and “a second transaction reconciliation platform,” for more clarity. For examination purpose, they are interpreted as any transaction reconciliation platforms.
Claim 9 recites “a feed system of a transaction reconciliation platform triggering …; the feed system notifying …; the feed system triggering … and generating a reconciliation result,” and claim 26 recites “a feed system of a transaction reconciliation platform triggering …; the feed system notifying …; the feed system triggering … and generating a reconciliation result.” The specification discloses that a transaction reconciliation platform includes two parts of a blockchain node and a feed system (see paragraph [0042] of the publication), and the specification discloses the functionalities performed by the feed system (see paragraphs [0062]-[0071] of the publication). But the specification does not clearly disclose what the feed system is, software, firmware, or hardware. Therefore, it is unclear whether the feed system is software, firmware, or hardware.
The limitation, which recites a feed system in claims 9 and 25, invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not provide sufficient details such that one of ordinary skill in the art would understand which structures perform the claimed functions. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
The applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If the applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, the applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification,
perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§
608.01(o) and 2181.
Dependent claims 2-3, 5-7, and 11-17 are rejected because they depend on the rejected independent claims 1 and 9, respectively.
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.
Claims 1, 5, 9, 15-16, 18, 20, and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Lyu et al. (CN 111861482 A) in view of Zou et al (CN 112767113 A), and further in view of Chen et al. (CN 112785408 A).
Claim 1:
Lyu discloses the following:
a reconciliation method based on a blockchain, comprising: a smart contract deployed on a transaction reconciliation platform acquiring a batch hash value fed onto the blockchain by (a first reconciliation participant) to be reconciled and a batch hash value fed onto the blockchain by (a second reconciliation participant) respectively, wherein the batch hash values are generated according to a reconciliation batch transaction record. (See the penultimate paragraph, page 5; paragraphs 5-9, page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100. Without exposing account data in plaintext form, the basic function of the reconciliation contract may include comparing hash values of account data of both reconciliation parties to obtain a reconciliation result”; paragraph 4, page 7; and paragraphs 2-4, page 8, “FIG. 2 is an interaction diagram of a blockchain reconciliation flow in accordance with some embodiments of the present description. The reconciliation process involves a first reconciliation party, a second reconciliation party and any blockchain node (consensus node) that received the reconciliation transaction. Referring to the related description in the foregoing embodiments, the first and second reconciliers may use the same hash function and generate hash values of the respective account data in the format and order of the attributes of the agreed account data. Further, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers. It can be understood that to ensure that reconciliation is successful (consistency of submitted account data by both reconciling parties), the first account data and the second account data should have the same account identification…. After any consensus node receives the reconciliation transaction from the first reconciliation party, the account identification in the reconciliation transaction and the hash value of the second account data can be associated and written into the blockchain data.”)
the smart contract performing first comparison on the batch hash value fed onto the blockchain by the first participant and the batch hash value fed onto the blockchain by the second participant. (See paragraphs 5-9, page 6; paragraph 6, page 8, “[i]f the consensus node inquires the hash value of the second account data in the blockchain data, that is, the consensus node obtains the hash value of the account data submitted by both reconciliation parties, the hash value of the first account data and the hash value of the second account data can be compared. Accordingly, the consensus node may determine an account checking result based on the comparison result, and the account checking result may indicate whether the account data submitted by the account checking parties are consistent.”)
notifying the first participant and the second participant the reconciliation result. (See paragraph 1, page 9, “[i]n some embodiments, the consensus node may return the obtained checking result to the client of the account checking party.”)
feeding hash values from the first participant and the second participant onto the blockchain. (See paragraph 3, page 8, “[f]urther, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers.”)
the program code/applications of the transaction reconciliation can be implemented as a smart contract. (See the penultimate paragraph, page 5, “[f]or example, to solve the reconciliation problem, a code containing a reconciliation flow may be written in the blockchain system 100, and then a node of any reconciliation party may invoke the code containing the reconciliation flow after receiving the reconciliation transaction through broadcasting the reconciliation transaction, which is more efficient and timely compared with manual reconciliation”; paragraphs 5-9, page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100.”)
Lyu does not explicitly disclose the following:
reconciliation participants being an institution and a transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed shard hash values corresponding to the reconciliation batch transaction record onto the blockchain under a condition that a result of the first comparison shows that the batch hash value fed onto the blockchain by the institution and the batch hash value fed onto the blockchain by the transaction reconciliation platform are inconsistence, wherein the shard hash values are obtained by sharding the reconciliation batch transaction record, and generating, for each shard, a shard hash value of the shard according to transaction records comprised in the shard;
acquiring an inconsistent shard by performing second comparison on the shard hash values fed onto the blockchain by the institution and the shard hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed a record hash value corresponding to each transaction record comprised in the inconsistent shard onto the blockchain;
acquiring an inconsistent transaction record by performing third comparison on the record hash values fed onto the blockchain by the institution and the record hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform of the inconsistent transaction record; and
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard.
However, Zou, an analogous art of performing reconciliation, discloses the following:
two participants being an institution and a transaction reconciliation platform; notifying the institution and the transaction reconciliation platform to feed shard hash values corresponding to the reconciliation batch transaction record under a condition that a result of the first comparison shows that the batch hash value fed by the institution and the batch hash value fed by the transaction reconciliation platform are inconsistence, wherein the shard hash values are obtained by sharding the reconciliation batch transaction record, and generating, for each shard, a shard hash value of the shard according to transaction records comprised in the shard. (See paragraphs 3-5, page 8, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30, and when the account checking is failed, the server side account checking data processing device 20 and the client side account checking data processing device 30 continue to execute account checking operation”; page 9, “[a] server job data obtaining unit 202, configured to obtain server job data according to the job batch number, where the server job data includes: and multiple strokes of detail data. A compression operation unit 203, configured to compress i pieces of detail data in the server job data, and generate a hash of the i pieces of detail data, where 1 ≦ i ≦ n, and i and n are positive integers greater than or equal to 1”; and pages 12-13, “Fig. 8 is a flowchart of continuing reconciliation on the bank side and the enterprise side after reconciliation failure of the bank MPC node 13 and the enterprise MPC node 14, and as shown in fig. 8, the flowchart includes … compresses each i detailed data of the current batch to generate a transaction HASH, constructs a reconciliation HASH linked list, links the HASH of the previous transaction besides the transaction detailed list and links the HASH of the previous transaction until the last transaction data of the batch…. The transactions field contains partial reconciliation details data for the batch. The pre-hash field points to the previous block of data with the same structure, in the figure to the hash-1 block of data. By analogy, the HASH can be continuously resolved to trace back to the first data block HASH1 in the linked list. The contents of all transactions in the data blocks HASH1 through HASHN constitute all reconciliation data for the enterprise batch. Therefore, the enterprise can obtain all data required by account checking of a certain batch finally by serially calling the getlocktxbyhash (function applied to the blockchain) method provided by the blockchain SDK (software development kit) in sequence until the hash value in the return value TxByHashResp is null.”)
notifying the institution and the transaction reconciliation platform of information associated with the inconsistent transaction data. (See paragraph 5, page 3, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30.”)
deploying and executing a reconciliation contract that comprises reconciliation logic. (See page 12)
Lyu discloses feeding the hash values onto a blockchain and comparing the hash values for transaction reconciliation. Lyu further discloses that the program code/applications of the transaction reconciliation can be implemented as a smart contract. Additionally, the smart contract is program code/application that can be executed to perform the defined functionalities. Furthermore, Zou discloses deploying and executing a reconciliation contract that comprises reconciliation logic. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Zou in the Lyu system. Moreover, in order to improve the reconciliation process of the Lyu system, one of ordinary skill in the art would have been motivated to notify the participants, via a smart contract, of providing the hash values of each subset of transactions for further comparison when an inconsistent result is identified, so that the transaction information associated with the inconsistent result can be effectively determined based on hash values of each subset of transactions via a smart contract.
The combination of Lyu and Zou discloses the claimed invention but does not explicitly disclose the following:
acquiring an inconsistent shard by performing second comparison on the shard hash values fed onto the blockchain by the institution and the shard hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed a record hash value corresponding to each transaction record comprised in the inconsistent shard onto the blockchain; and
acquiring an inconsistent transaction record by performing third comparison on the record hash values fed onto the blockchain by the institution and the record hash values fed onto the blockchain by the transaction reconciliation platform; and
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard.
Chen, an analogous art of performing reconciliation, discloses the following:
acquiring an inconsistent shard by performing second comparison on the shard files associated with shard hash values fed onto a storage by an upstream system and the shard files associated with shard hash values fed onto a storage by a downstream system. (See pages 9-10, “s101: acquiring transaction data to be checked; s102: calculating a hash value corresponding to each transaction datum in the transaction data and generating leaf nodes of a Merkel tree based on the hash value; in this step, calculating a hash value corresponding to each transaction data in the transaction data includes: and carrying out Hash calculation according to the reconciliation main key of each transaction data to obtain a Hash value corresponding to each transaction data…. S104: the reconciliation is performed based on a plurality of reconciliation files generated by each of the upstream system and the downstream system. In the step, checking account checking files corresponding to respective root nodes of an upstream system and a downstream system … and if the check results of the two account checking files are inconsistent, checking the account checking files generated by the upstream system and the downstream system in pairs, and determining inconsistent leaf nodes and transaction data corresponding to the inconsistent leaf nodes.”)
notifying two systems to locate a record file associated with a record hash value corresponding to each transaction record comprised in the inconsistent shard; acquiring an inconsistent transaction record by performing third comparison on the record files associated with record hash values fed onto the storage by the upstream system and the record files associated with record hash values fed onto the storage by the downstream system. (See page 10, “[i]n general, if there is record inconsistency, after sequentially scanning 23 files, finding inconsistent Merkle trees leaf nodes is needed. In the process of tree comparison, only the tree access paths caused by inconsistent leaf nodes need to be compared, and other tree nodes do not need to be compared. According to the compared result, the upstream application informs the downstream application to generate an original data file [4.2] according to the inconsistent Merkle trees leaf nodes to check specific data and find out inconsistent records.”)
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard. (See pages 9-10. All transactions in a transaction reconciliation are grouped as a reconciliation batch transaction record. Each transaction hash is generated; at least two intermediate hashes are obtained by sequentially joining transaction hashes; and the root hash, as a batch hash value, is obtained by sequentially joining the at least two intermediate hashes.)
Lyu discloses that the program code/applications of the transaction reconciliation can be implemented as a smart contract. Additionally, the smart contract is program code/application that can be executed to perform the defined functionalities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Chen in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyn system, one of ordinary skill in the art would have been motivated to notify the participants, via a smart contract, of providing hash values of each transaction record for further comparison when an inconsistent subset is identified, to acquire an inconsistent shard and an inconsistent transaction via the smart contract, and to sequentially splice the lower-level hash values for an upper-level hash value, so that the transaction record associated with the inconsistent subset can be effectively determined based on the provided hash values of each shard and transaction record via a smart contract.
Claim 5:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses wherein each transaction record comprised in the reconciliation batch transaction record has a transaction initiation time point, and the reconciliation batch transaction record is sorted and sharded based on the transaction initiation time point. (See paragraph 4, page 7; paragraphs 3-4, page 9.)
Claims 9, 25, and 26:
Lyu discloses the following:
a. a reconciliation method based on a blockchain, comprising: a feed system of a transaction reconciliation platform triggering, in response to receiving hash values of data to be reconciled fed onto the blockchain by reconciliation participants, a smart contract to perform comparison on the hash values, wherein the smart contract is deployed on the blockchain in advance, and the hash values are obtained by performing hash operation on the date to be reconciled. (See paragraphs 5-9, page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100. Without exposing account data in plaintext form, the basic function of the reconciliation contract may include comparing hash values of account data of both reconciliation parties to obtain a reconciliation result”; paragraph 4, page 7; page 8, “FIG. 2 is an interaction diagram of a blockchain reconciliation flow in accordance with some embodiments of the present description. The reconciliation process involves a first reconciliation party, a second reconciliation party and any blockchain node (consensus node) that received the reconciliation transaction. Referring to the related description in the foregoing embodiments, the first and second reconciliers may use the same hash function and generate hash values of the respective account data in the format and order of the attributes of the agreed account data. Further, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers. It can be understood that to ensure that reconciliation is successful (consistency of submitted account data by both reconciling parties), the first account data and the second account data should have the same account identification…. After any consensus node receives the reconciliation transaction from the first reconciliation party, the account identification in the reconciliation transaction and the hash value of the second account data can be associated and written into the blockchain data.”)
b. generating a reconciliation result. (See paragraphs 5-6, page 8, “[a]ccordingly, the consensus node may determine an account checking result based on the comparison result, and the account checking result may indicate whether the account data submitted by the account checking parties are consistent”; paragraph 1, page 9, “[i]n some embodiments, the consensus node may return the obtained checking result to the client of the account checking party.”)
c. an electronic reconciliation device based on a blockchain, comprising: one or more processors; and a memory configured to store one or more programs; wherein when the one or more programs are executed by the one or more processors, the one or more processors implement following actions. (See paragraph 1, page 5, “[o]ne of the embodiments of the present specification provides a blockchain reconciliation apparatus, which includes a processor and a storage device, where the storage device is configured to store instructions, and when the processor executes the instructions, the blockchain reconciliation method according to any embodiment of the present specification is implemented.”)
d. the program code/applications of the transaction reconciliation can be implemented as a smart contract. (See the penultimate paragraph, page 5, “[f]or example, to solve the reconciliation problem, a code containing a reconciliation flow may be written in the blockchain system 100, and then a node of any reconciliation party may invoke the code containing the reconciliation flow after receiving the reconciliation transaction through broadcasting the reconciliation transaction, which is more efficient and timely compared with manual reconciliation”; paragraphs 5-9, page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100.”)
Lyn does not explicitly disclose the following:
shard hash values of date to be reconciled when batch hash values are inconsistence and wherein the shard hash values are obtained by performing hash operation on each shard after sharding the data to be reconciled, each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard;
the feed system notifying the reconciliation participants to feed record hash values of transaction records comprised in an inconsistent shard under a condition that a result of the comparison of the shard hash values shows inconsistence; and
the feed system triggering, in response to receiving the record hash values fed onto the blockchain by the reconciliation participants, the smart contract to perform comparison on the record hash values, so as to find an inconsistent transaction record.
However, Zou, an analogous art of performing reconciliation, discloses the following:
d. shard hash values of date to be reconciled and wherein a smart contract is deployed on the blockchain in advance and the shard hash values are obtained by performing hash operation on each shard after sharding the data to be reconciled. (See paragraph 5, page 8, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30, and when the account checking is failed, the server side account checking data processing device 20 and the client side account checking data processing device 30 continue to execute account checking operation”; page 9, “[a] server job data obtaining unit 202, configured to obtain server job data according to the job batch number, where the server job data includes: and multiple strokes of detail data. A compression operation unit 203, configured to compress i pieces of detail data in the server job data, and generate a hash of the i pieces of detail data, where 1 ≦ i ≦ n, and i and n are positive integers greater than or equal to 1”; and pages 12-13, “[b]lock chain network: and the coalition chain is formed by the bank and the enterprise and is used for executing the reconciliation contract, broadcasting and scheduling the reconciliation task and storing and tracing the reconciliation result…. And after the contract definition is finished, submitting the contract to the nodes of participators in the alliance chain for auditing, deploying the contract after the node auditing is passed, and starting the block chain network…. Fig. 8 is a flowchart of continuing reconciliation on the bank side and the enterprise side after reconciliation failure of the bank MPC node 13 and the enterprise MPC node 14, and as shown in fig. 8, the flowchart includes … compresses each i detailed data of the current batch to generate a transaction HASH, constructs a reconciliation HASH linked list, links the HASH of the previous transaction besides the transaction detailed list and links the HASH of the previous transaction until the last transaction data of the batch…. The transactions field contains partial reconciliation details data for the batch. The pre-hash field points to the previous block of data with the same structure, in the figure to the hash-1 block of data. By analogy, the HASH can be continuously resolved to trace back to the first data block HASH1 in the linked list. The contents of all transactions in the data blocks HASH1 through HASHN constitute all reconciliation data for the enterprise batch. Therefore, the enterprise can obtain all data required by account checking of a certain batch finally by serially calling the getlocktxbyhash (function applied to the blockchain) method provided by the blockchain SDK (software development kit) in sequence until the hash value in the return value TxByHashResp is null.”)
e. the feed system notifying the reconciliation participants of information associated with the inconsistent transaction data. (See paragraph 5, page 8, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30.”)
Lyu discloses feeding the hash values onto a blockchain and comparing the hash values for reconciliation. Lyu further discloses that the program code/applications of the transaction reconciliation can be implemented as a smart contract. Additionally, the smart contract is program code/application that can be executed to perform the defined functionalities. Furthermore, Zou discloses deploying and executing a reconciliation contract that comprises reconciliation logic. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Zou in the Lyu system. Moreover, in order to improve the reconciliation process of the Lyu system, one of ordinary skill in the art would have been motivated to provide hash values of each subset of transactions for performing comparison via a smart contract, so that the transaction information can be effectively determined based on hash values of each subset of transactions.
The combination of Lyu and Zou discloses the claimed invention but does not explicitly disclose the following:
triggering, when batch hash values are inconsistence, a smart contract to perform comparison on the shard hash values;
the feed system notifying the reconciliation participants to feed record hash values comprised in an inconsistent shard under a condition that a result of the comparison of the shard hash values shows inconsistence;
the feed system triggering, in response to receiving the record hash values fed onto the blockchain by the reconciliation participants, the smart contract to perform comparison on the record hash values, so as to find an inconsistent transaction record.
Chen, an analogous art of performing reconciliation, discloses a feed system triggering, when batch hash values are inconsistence, program/code to perform comparison on the shard hash values; the feed system notifying the reconciliation participants to locate record files associated with record hash values of transaction records comprised in an inconsistent shard under a condition that a result of the comparison of the shard filed associated with shard hash values shows inconsistence; the feed system trigging, in response to locating the record files associated with record hash values fed onto a storage by the reconciliation participants, performing comparison on the record files associated with record hash values, so as to find an inconsistent transaction record. (See pages 9-10, “s101: acquiring transaction data to be checked; s102: calculating a hash value corresponding to each transaction datum in the transaction data and generating leaf nodes of a Merkel tree based on the hash value; in this step, calculating a hash value corresponding to each transaction data in the transaction data includes: and carrying out Hash calculation according to the reconciliation main key of each transaction data to obtain a Hash value corresponding to each transaction data…. S104: the reconciliation is performed based on a plurality of reconciliation files generated by each of the upstream system and the downstream system. In the step, checking account checking files corresponding to respective root nodes of an upstream system and a downstream system … and if the check results of the two account checking files are inconsistent, checking the account checking files generated by the upstream system and the downstream system in pairs, and determining inconsistent leaf nodes and transaction data corresponding to the inconsistent leaf nodes…. In general, if there is record inconsistency, after sequentially scanning 23 files, finding inconsistent Merkle trees leaf nodes is needed. In the process of tree comparison, only the tree access paths caused by inconsistent leaf nodes need to be compared, and other tree nodes do not need to be compared. According to the compared result, the upstream application informs the downstream application to generate an original data file [4.2] according to the inconsistent Merkle trees leaf nodes to check specific data and find out inconsistent records.” All transactions in a transaction reconciliation are grouped as a reconciliation batch transaction record. Each transaction hash is generated; at least two intermediate hashes are obtained by sequentially joining transaction hashes; and the root hash, as a batch hash value, is obtained by sequentially joining the at least two intermediate hashes.)
Lyu discloses that the program code/applications of the transaction reconciliation can be implemented as a smart contract. Additionally, the smart contract is program code/application that can be executed to perform the defined functionalities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Chen in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to notify the participants of providing hash values of each transaction record for further comparison via a smart contract when an inconsistent subset is identified and to sequentially splice the lower-level hash values for an upper-level hash value, so that the transaction record associated with the inconsistent subset can be effectively determined based on the record files associated with hash values of each transaction record via a smart contract.
Examiner’s Note: Regarding claim 25, the cited feed system is not positively recited as a component comprised in the claimed electronic reconciliation device. Therefore, the feed system is out of scope of the claimed electronic reconciliation device and does not have patentable weight. In accordance with compact prosecution, the examiner provided the references to disclose the steps performed by the feed system of claim 25.
Claim 15:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses wherein each transaction record comprised in the data to be reconciled has time information, and the data to be reconciled is sharded based on the time information. (See paragraph 4, page 7; paragraphs 3-4, page 9.)
Claim 16:
Lyu in view of Zou and Chen discloses the limitation shown above.
Chen further discloses wherein each transaction record comprised in the data to be reconciled has an ordered message identification number; and a shard hash value of each shard is obtained by sorting the transaction records of comprised in the each shard incrementally according to message identification number of the transaction records comprised in the each shard, and performing hash operation on the transaction records comprised in the each shard after sharding the data to be reconciled. (See pages 9-10.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Chen in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to sequentially combine the lower-level hash values for an upper-level hash value, so that the reconciliation can be effectively performed based on these hash values.
Claim 18:
Lyu discloses the following:
a reconciliation method based on a blockchain, comprising: feeding, by (a first reconciliation participant) to be reconciled and (a second reconciliation participant), batch hash values corresponding to a reconciliation batch record onto the blockchain respectively, wherein the batch hash values are generated according to the reconciliation batch transaction record. (See paragraph 4, page 7; paragraphs 2-4, page 8, “FIG. 2 is an interaction diagram of a blockchain reconciliation flow in accordance with some embodiments of the present description. The reconciliation process involves a first reconciliation party, a second reconciliation party and any blockchain node (consensus node) that received the reconciliation transaction. Referring to the related description in the foregoing embodiments, the first and second reconciliers may use the same hash function and generate hash values of the respective account data in the format and order of the attributes of the agreed account data. Further, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers. It can be understood that to ensure that reconciliation is successful (consistency of submitted account data by both reconciling parties), the first account data and the second account data should have the same account identification…. After any consensus node receives the reconciliation transaction from the first reconciliation party, the account identification in the reconciliation transaction and the hash value of the second account data can be associated and written into the blockchain data.”)
triggering a smart contract to respectively acquire the batch hash values fed onto the blockchain by the first reconciliation participant and the second reconciliation participant in response to reconciliation processing instruction, and performing first comparison on the batch hash value fed onto the blockchain by the first reconciliation participant and the batch hash value fed onto the blockchain by the second reconciliation participant. (See page 6, “[i]t is understood that reconciliation may also be achieved through intelligent contract techniques. First, an intelligent contract (hereinafter referred to as a tie-out contract) containing a tie-out procedure may be deployed in the blockchain system 100. Without exposing account data in plaintext form, the basic function of the reconciliation contract may include comparing hash values of account data of both reconciliation parties to obtain a reconciliation result”; paragraph 6, page 8, “[i]f the consensus node inquires the hash value of the second account data in the blockchain data, that is, the consensus node obtains the hash value of the account data submitted by both reconciliation parties, the hash value of the first account data and the hash value of the second account data can be compared. Accordingly, the consensus node may determine an account checking result based on the comparison result, and the account checking result may indicate whether the account data submitted by the account checking parties are consistent.”)
notifying the first reconciliation participant and the second reconciliation participant the reconciliation result. (See paragraph 1, page 9, “[i]n some embodiments, the consensus node may return the obtained checking result to the client of the account checking party.”)
feeding hash values from the first reconciliation participant and the second reconciliation participant onto the blockchain. (See paragraph 3, page 8, “[f]urther, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers.”)
Lyu does not explicitly disclose the following:
reconciliation participants being an institution and a transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed shard hash values corresponding to the reconciliation batch transaction record onto the blockchain under a condition that a result of the first comparison shows that the batch hash value fed onto the blockchain by the institution and the batch hash value fed onto the blockchain by the transaction reconciliation platform are inconsistence;
feeding the shard hash values by the institution and the transaction reconciliation platform onto the blockchain, wherein the shard hash values are obtained by sharding the reconciliation batch transaction record, and generating, for each shard, a shard hash value of the shard according to transaction records comprised in the shard;
acquiring, in response to receiving the shard hash values, an inconsistent shard by the smart contract performing second comparison on the shard hash values fed onto the blockchain by the institution and the shard hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed a record hash value corresponding to each transaction record comprised in the inconsistent shard;
feeding, by the institution and the transaction reconciliation platform, the record hash values onto the blockchain;
acquiring, in response to receiving the record hash values, an inconsistent transaction record by the smart contract performing third comparison on the record hash values fed onto the blockchain by the institution and the record hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform of the inconsistent transaction record; and
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard.
However, Zou, an analogous art of performing reconciliation, discloses the following:
reconciliation participants being an institution and a transaction reconciliation platform; notifying the institution and the transaction reconciliation platform to feed shard hash values corresponding to the reconciliation batch transaction record under a condition that a result of the first comparison shows that the batch hash value fed by the institution and the batch hash value fed by the transaction reconciliation platform are inconsistence; feeding the shard hash values by the institution and the transaction reconciliation platform, wherein the shard hash values are obtained by sharding the reconciliation batch transaction record, and generating, for each shard, a shard hash value of the shard according to transaction records comprised in the shard. (See paragraphs 3-5, page 8, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30, and when the account checking is failed, the server side account checking data processing device 20 and the client side account checking data processing device 30 continue to execute account checking operation”; page 9, “[a] server job data obtaining unit 202, configured to obtain server job data according to the job batch number, where the server job data includes: and multiple strokes of detail data. A compression operation unit 203, configured to compress i pieces of detail data in the server job data, and generate a hash of the i pieces of detail data, where 1 ≦ i ≦ n, and i and n are positive integers greater than or equal to 1”; and pages 12-13, “Fig. 8 is a flowchart of continuing reconciliation on the bank side and the enterprise side after reconciliation failure of the bank MPC node 13 and the enterprise MPC node 14, and as shown in fig. 8, the flowchart includes … compresses each i detailed data of the current batch to generate a transaction HASH, constructs a reconciliation HASH linked list, links the HASH of the previous transaction besides the transaction detailed list and links the HASH of the previous transaction until the last transaction data of the batch…. The transactions field contains partial reconciliation details data for the batch. The pre-hash field points to the previous block of data with the same structure, in the figure to the hash-1 block of data. By analogy, the HASH can be continuously resolved to trace back to the first data block HASH1 in the linked list. The contents of all transactions in the data blocks HASH1 through HASHN constitute all reconciliation data for the enterprise batch. Therefore, the enterprise can obtain all data required by account checking of a certain batch finally by serially calling the getlocktxbyhash (function applied to the blockchain) method provided by the blockchain SDK (software development kit) in sequence until the hash value in the return value TxByHashResp is null.”)
notifying the institution and the transaction reconciliation platform of information associated with the inconsistent transaction data. (See paragraph 5, page 8, “when the two data are consistent, the account checking data can be judged to be consistent, the account checking is successful, otherwise, the account checking is failed, then the account checking result data are respectively sent to the server side account checking data processing device 20 and the client side account checking data processing device 30.”)
Lyu discloses feeding the hash values onto a blockchain and comparing the hash values for reconciliation via a smart contract. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Zou in the Lyu system. Moreover, in order to improve the reconciliation process of the Lyu system, one of ordinary skill in the art would have been motivated to notify the participants of providing the hash values of each subset of transactions for further comparison when an inconsistent result is identified, so that the transaction information associated with the inconsistent result can be effectively determined based on hash values of each subset of transactions.
The combination of Lyu and Zou discloses the claimed invention but does not explicitly disclose the following:
acquiring, in response to receiving the shard hash values, an inconsistent shard by the smart contract performing second comparison on the shard hash values fed onto the blockchain by the institution and the shard hash values fed onto the blockchain by the transaction reconciliation platform;
notifying the institution and the transaction reconciliation platform to feed a record hash value corresponding to each transaction record comprised in the inconsistent shard;
feeding, by the institution and the transaction reconciliation platform, the record hash values onto the blockchain;
acquiring, in response to receiving the record hash values, an inconsistent transaction record by the smart contract performing third comparison on the record hash values fed onto the blockchain by the institution and the record hash values fed onto the blockchain by the transaction reconciliation platform; and
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard.
Chen, an analogous art of performing reconciliation, discloses the following:
acquiring an inconsistent shard by performing second comparison on the shard files associated with shard hash values fed onto a storage by an upstream system and the shard files associated with shard hash values fed onto a storage by a downstream system. (See pages 9-10, “s101: acquiring transaction data to be checked; s102: calculating a hash value corresponding to each transaction datum in the transaction data and generating leaf nodes of a Merkel tree based on the hash value; in this step, calculating a hash value corresponding to each transaction data in the transaction data includes: and carrying out Hash calculation according to the reconciliation main key of each transaction data to obtain a Hash value corresponding to each transaction data…. S104: the reconciliation is performed based on a plurality of reconciliation files generated by each of the upstream system and the downstream system. In the step, checking account checking files corresponding to respective root nodes of an upstream system and a downstream system … and if the check results of the two account checking files are inconsistent, checking the account checking files generated by the upstream system and the downstream system in pairs, and determining inconsistent leaf nodes and transaction data corresponding to the inconsistent leaf nodes.”)
notifying two systems to locate a record file associated with a record hash value corresponding to each transaction record comprised in the inconsistent shard; locating, by the two systems, the record files associated with the record hash values; acquiring, in response to locating the record files associated with the record hash values, an inconsistent transaction record by performing third comparison on the record files associated with the hash values fed onto a storage by the upstream system and the record files associated with record hash values fed onto the storage by the downstream system. (See page 10, “[i]n general, if there is record inconsistency, after sequentially scanning 23 files, finding inconsistent Merkle trees leaf nodes is needed. In the process of tree comparison, only the tree access paths caused by inconsistent leaf nodes need to be compared, and other tree nodes do not need to be compared. According to the compared result, the upstream application informs the downstream application to generate an original data file [4.2] according to the inconsistent Merkle trees leaf nodes to check specific data and find out inconsistent records.”)
wherein each batch hash value is obtained by sequentially splicing shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and a shard hash value of each shard is obtained by sequentially splicing record hash values obtained by performing hash operation on each transaction record comprised in the shard. (See pages 9-10. All transactions in a transaction reconciliation are grouped as a reconciliation batch transaction record. Each transaction hash is generated; at least two intermediate hashes are obtained by sequentially joining transaction hashes; and the root hash, as a batch hash value, is obtained by sequentially joining the at least two intermediate hashes.)
Lyu discloses that the program code/applications of the transaction reconciliation can be implemented as a smart contract (see the penultimate paragraph, page 5; paragraphs 5-9, page 6). Additionally, the smart contract is program code/application that can be executed to perform the defined functionalities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Chen in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyn system, one of ordinary skill in the art would have been motivated to notify the participants, via a smart contract, of providing hash values of each transaction record for further comparison when an inconsistent subset is identified, to acquire an inconsistent shard and an inconsistent transact via the smart contract, and to sequentially splice the lower-level hash values for an upper-level hash value, so that the transaction record associated with the inconsistent subset can be effectively determined based on the provided hash values of each shard and transaction record via a smart contract.
Claim 20:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu further discloses wherein after the first reconciliation participant and the second reconciliation participant feed onto the blockchain each time, data fed onto the blockchain by the first reconciliation participant is synchronized to a blockchain node of the second reconciliation participant based on a data synchronization function of the blockchain; and the smart contract obtains the data fed onto the blockchain by the first reconciliation participant and the second reconciliation participant from the blockchain node of the transaction reconciliation platform. (See pages 8-10.)
Zou discloses wherein a first reconciliation participant is an institution and a second reconciliation participant is a transaction reconciliation platform. (See paragraph 3, page 8.)
Claims 2-3, 11-14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lyu et al. (CN 111861482 A) in view of Zou et al (CN 112767113 A), and further in view of Chen et al. (CN 112785408 A) and Sun et al. (CN 110706105 A).
Claims 2 and 11:
Lyu in view of Zou and Chen discloses the limitation shown above.
Zou discloses wherein the reconciliation participants comprise a reconciliation institution and a transaction reconciliation platform. (See paragraph 3, page 8.)
None of Lyn, Zou, and Chen explicitly discloses sending the inconsistent transaction record to an automatic error handling system by means of the transaction reconciliation platform, such that the automatic error handling system performs error handling by calling an error handling interface provided by the institution, and feeds back an error handling result to the transaction reconciliation platform.
However, Sun, an analogous art of performing reconciliation, discloses sending the inconsistent transaction record to an automatic error handling system by means of a first entity, such that the automatic error handling system performs error handling by calling an error handling interface provided by a second entity, and feeds back an error handling result to the first entity. (See pages 8-9, “[i]n one aspect, there is provided an error marking apparatus, comprising … the adding module is further configured to add an error reason identifier to the transaction information with inconsistent data according to a second transaction data linked list corresponding to the second transaction information and a first transaction data linked list corresponding to the first transaction information when the first transaction information with the same transaction identifier as the second transaction information exists in the first bill file … when the inquiry result is in payment, determining that a second error reason of the second transaction information is the order drop of the transaction system; when the inquiry result is that payment is in progress and the transaction amount is inconsistent, determining that a second error reason of the second transaction information is that the order of the transaction system is lost and the account is wrong”; pages 13-14, “[t]he second error cause may be multiple, and the step of determining, by the computer device, the second error cause of the second transaction information according to the query result returned by the second transaction system may be.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to obtain information associated with errors in a transaction by sending a query request, so that the system can process the transaction based on the received result.
Claim 3:
Lyu in view of Zou, and Chen discloses the limitation shown above.
None of Lyn, Zou, and Chen explicitly discloses determining a classification to which the inconsistent transaction record belongs; notifying the institution and the transaction reconciliation platform of the classification to which the inconsistent transaction record belongs; and sending the classification to which the inconsistent transaction record belongs to the automatic error handling system by means of the transaction reconciliation platform.
However, Sun, an analogous art of performing reconciliation, discloses determining a classification according to a preset business rule to which the inconsistent transaction record belongs; notifying the participants of the classification to which the inconsistent transaction record belongs; and sending the classification to which the inconsistent transaction record belongs to the automatic error handling system by means of an entity. (See pages 12-14, “[i]n step 302, the computer device adds the system identifiers of the affiliated transaction systems to the first transaction information and the second transaction information, respectively, stores the transaction data of the first transaction information in a first transaction data linked list associated with the transaction identifier of the first transaction information, and stores the transaction data of the second transaction information in a second transaction data linked list associated with the transaction identifier of the second transaction information…. In an alternative implementation, the step of adding, by the computer device, an error cause identifier to the second transaction information according to the system identifier may be: and the computer equipment sends a query request to a second transaction system corresponding to the system identification according to the system identification of the second transaction information. The computer device may determine a second error cause for the second transaction information based on the query results returned by the second transaction system.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to determine a classification associated with a transaction and obtain information associated with errors in the transaction by sending a query request with the classification, so that the system can process the transaction based on the received result.
Claim 12:
Lyu in view of Zou, Chen, and Sun discloses the limitation shown above.
Sun further discloses wherein before sending the inconsistent transaction record to the automatic error handling system, the method further comprises: marking a classification on the inconsistent transaction record according to a present business rule; sending the classification of the inconsistent transaction record to the automatic error handling system. (See pages 12-14, “[i]n step 302, the computer device adds the system identifiers of the affiliated transaction systems to the first transaction information and the second transaction information, respectively, stores the transaction data of the first transaction information in a first transaction data linked list associated with the transaction identifier of the first transaction information, and stores the transaction data of the second transaction information in a second transaction data linked list associated with the transaction identifier of the second transaction information…. In an alternative implementation, the step of adding, by the computer device, an error cause identifier to the second transaction information according to the system identifier may be: and the computer equipment sends a query request to a second transaction system corresponding to the system identification according to the system identification of the second transaction information. The computer device may determine a second error cause for the second transaction information based on the query results returned by the second transaction system.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to determine a classification associated with a transaction and obtain information associated with errors in the transaction by sending a query request with the classification, so that the system can process the transaction based on the received result.
Claim 13:
Lyu in view of Zou, Chen, and Sun discloses the limitation shown above.
Lyn discloses wherein the preset business rule is implemented as an automatic error smart contract. (See page 9, “[i]n connection with the relevant content of the foregoing embodiments, a blockchain may be deployed with at least two tie-out contracts having different tie-out constraints. Accordingly, the tie-up transaction may further include an address of the target tie-up contract, and the consensus node may invoke the target tie-up contract according to the address of the target tie-up contract in the tie-up transaction. And the calling of the target account-checking contract comprises judging whether the account-checking transaction meets the account-checking constraint condition of the target account-checking contract.”)
Sun discloses calling a procedure, and marking the error classification on the inconsistent transaction record in combination with a specific transaction scene and a failure reason. (See pages 12-14.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to utilize a smart contract to determine the errors and reasons associated with a marked transaction, so that the system can process the transaction based on the information determined via the smart contract.
Claim 14:
Lyu in view of Zou, Chen, and Sun discloses the limitation shown above.
Zou discloses wherein the reconciliation participants comprise a reconciliation institution and a transaction reconciliation platform. (See paragraph 3, page 8.)
Sun further discloses wherein an entity performs error handling according to an error handling flow corresponding to the error classification of the inconsistent transaction record. (See pages 12-14.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to perform error handling according to an error handling flow, so that the transaction can be effectively processed.
Claim 19:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu further discloses feeding checking result onto the blockchain by a participant node. (See page 7, “[i]n some embodiments, the user terminal 120 may also be directly integrated on a blockchain node. In other words, the user terminal 120 can join the blockchain network 110 as a node. In some embodiments, the customer end 120 of the account checking party may join the blockchain network 110 as a normal node not participating in consensus, or join the blockchain network 110 as a consensus node”; claim 8, “associating the account identification with the account checking result and writing the account checking result into block chain data.”)
None of Lyn, Zou, and Chen explicitly discloses sending the inconsistent transaction record to an automatic error handling system by the transaction reconciliation platform, such that the automatic error handling system calls an error handling interface provided by the institution to perform error handling, and feeds back an error handling result to the transaction reconciliation platform.
However, Sun, an analogous art of performing reconciliation, discloses sending the inconsistent transaction record to an automatic error handling system by a first entity, such that the automatic error handling system calls an error handing interface provided by a second entity to perform error handling, and feeds back an error handling result to the first entity. (See pages 8-9, “[i]n one aspect, there is provided an error marking apparatus, comprising … the adding module is further configured to add an error reason identifier to the transaction information with inconsistent data according to a second transaction data linked list corresponding to the second transaction information and a first transaction data linked list corresponding to the first transaction information when the first transaction information with the same transaction identifier as the second transaction information exists in the first bill file … when the inquiry result is in payment, determining that a second error reason of the second transaction information is the order drop of the transaction system; when the inquiry result is that payment is in progress and the transaction amount is inconsistent, determining that a second error reason of the second transaction information is that the order of the transaction system is lost and the account is wrong”; pages 13-14, “[t]he second error cause may be multiple, and the step of determining, by the computer device, the second error cause of the second transaction information according to the query result returned by the second transaction system may be.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to obtain information associated with errors in a transaction by sending a query request, so that the system can process the transaction based on the received result.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Lyu et al. (CN 111861482 A) in view of Zou et al (CN 112767113 A), and further in view of Chen et al. (CN 112785408 A) and Galisteo (US 8639596 B2).
Claim 6:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses feeding hash values onto a blockchain. (See paragraph 3, page 8, “[f]urther, as shown in fig. 2, the first and second reconciliers may submit the hash value of the account data to be reconciled, i.e. the hash value of the first account data and the hash value of the second account data, respectively, and the hash () in fig. 2 represents a hash function agreed by the reconciliers.”)
Zou discloses wherein shard hash are fed onto a blockchain node in a form of a list; and performing comparison based on the shard hash values fed onto the blockchain by the institution with the shard hash values of the transaction reconciliation platform. (See paragraph 5, page 8; pages 12-13, “Fig. 8 is a flowchart of continuing reconciliation on the bank side and the enterprise side after reconciliation failure of the bank MPC node 13 and the enterprise MPC node 14, and as shown in fig. 8, the flowchart includes … compresses each i detailed data of the current batch to generate a transaction HASH, constructs a reconciliation HASH linked list, links the HASH of the previous transaction besides the transaction detailed list and links the HASH of the previous transaction until the last transaction data of the batch…. The transactions field contains partial reconciliation details data for the batch. The pre-hash field points to the previous block of data with the same structure, in the figure to the hash-1 block of data. By analogy, the HASH can be continuously resolved to trace back to the first data block HASH1 in the linked list. The contents of all transactions in the data blocks HASH1 through HASHN constitute all reconciliation data for the enterprise batch. Therefore, the enterprise can obtain all data required by account checking of a certain batch finally by serially calling the getlocktxbyhash (function applied to the blockchain) method provided by the blockchain SDK (software development kit) in sequence until the hash value in the return value TxByHashResp is null.”)
Chen discloses performing comparison of the shard hash values of the blockchain node of a first participant with the shard hash values of a second participant comprises: performing an operation on a shard file associated with shard hash value list fed onto a storage by the first participant and a shard file associated with a shard hash value list fed onto the storage by the second participant for comparison. (See pages 9-10, “s101: acquiring transaction data to be checked; s102: calculating a hash value corresponding to each transaction datum in the transaction data and generating leaf nodes of a Merkel tree based on the hash value; in this step, calculating a hash value corresponding to each transaction data in the transaction data includes: and carrying out Hash calculation according to the reconciliation main key of each transaction data to obtain a Hash value corresponding to each transaction data…. S104: the reconciliation is performed based on a plurality of reconciliation files generated by each of the upstream system and the downstream system. In the step, checking account checking files corresponding to respective root nodes of an upstream system and a downstream system … and if the check results of the two account checking files are inconsistent, checking the account checking files generated by the upstream system and the downstream system in pairs, and determining inconsistent leaf nodes and transaction data corresponding to the inconsistent leaf nodes.”)
None of Lyn, Zou, and Chen explicitly discloses performing Cartesian product operation.
However, Galisteo, an analogous art of performing reconciliation, discloses performing Cartesian product operation on transactions for reconciliation. (See claim 1, “listing pairs of financial transactions which are candidates for reconciliation with reference to the weighted features, wherein listing pairs comprises constructing a Cartesian product of the at least first and second datasets being reconciled.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Galisteo in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to utilize Cartesian product to generate all combinations of shard hash values for comparison, so as to ensure the quality of the reconciliation process.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lyu et al. (CN 111861482 A) in view of Zou et al (CN 112767113 A), and further in view of Chen et al. (CN 112785408 A) and Alexa et al. (US 20220147988 A1).
Claim 7:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses wherein before the acquiring a batch hash value fed onto the blockchain by a first reconciliation participant to be reconciled and a batch hash value fed onto the blockchain by a second reconciliation participant respectively, the method further comprises: feeding the batch hash value corresponding to the reconciliation batch transaction record onto the blockchain by means of the first reconciliation participant and the second reconciliation participant respectively; wherein feed the batch hash value and the shard hash values onto the blockchain comprises: calling a smart contract of a blockchain node. (See pages 8-9.)
Zou discloses wherein the reconciliation participants comprise a reconciliation an institution and a transaction reconciliation platform. (See paragraph 3, page 8.)
None of Lyn, Zou, and Chen explicitly discloses storing the batch hash value and the shard hash values in an attribute of the smart contract.
However, Alexa, an analogous art of utilizing a smart contract for processing transactions, discloses storing hash values of transactions in an attribute of the smart contract. (See paragraph [0205], “[t]he smart contract, such as the smart contract 1528 of FIG. 15, monitors the network address of the product and when a new transaction has occurred, the smart contract collects a hash value representative of the transaction and stores it in the contract. The smart contract continues to grow and expand as more transactions for the product occur.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Galisteo in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to store hash values in a smart contract, so that the smart contract can effectively access the hash values.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Lyu et al. (CN 111861482 A) in view of Zou et al (CN 112767113 A), and further in view of Chen et al. (CN 112785408 A), Sun et al. (CN 110706105 A), and Shang et al. (US 10147129 B1).
Claim 17:
Lyu in view of Zou and Chen discloses the limitation shown above.
Zou discloses sharding the data with a certain number of pieces of transaction data. (See page 9, “[a] server job data obtaining unit 202, configured to obtain server job data according to the job batch number, where the server job data includes: and multiple strokes of detail data. A compression operation unit 203, configured to compress i pieces of detail data in the server job data, and generate a hash of the i pieces of detail data, where 1 ≦ i ≦ n, and i and n are positive integers greater than or equal to 1.”)
None of Lyu, Zou, and Chen explicitly discloses wherein when an amount of the data to be reconciled is greater than a first threshold, a sharding time interval is decreased to increase the number of shards; and when the amount of the data to be reconciled is less than a second threshold, the sharding time interval is increased to decrease the number of shards, wherein the first threshold is greater than the second threshold.
However, Sun, an analogous art of performing reconciliation, discloses wherein when an amount of the data to be reconciled is greater than a threshold, a sharding time interval is decreased to increase the number of shards; and when the amount of the data to be reconciled is less than a threshold, the sharding time interval is increased to decrease the number of shards. (See the last paragraph, page 11 – the first paragraph, page 12, “[w]hen the number of the transaction information pieces contained in the third bill file is larger than a preset number threshold value, or the number of the transaction information pieces contained in the fourth bill file is larger than a preset number threshold value, splitting the third bill file to obtain a plurality of first bill files, and splitting the fourth bill file to obtain a plurality of second bill files.”)
Shang discloses a first threshold and a second threshold for controlling a size of each group, wherein the first threshold is greater than the second threshold. (See col. 22, lines 5-30, “[t]hus, in such embodiments, the item placement service may partition the graph into groups of nodes of a similar size that is between a lower size threshold and an upper size threshold. In some embodiments, the cluster size thresholds targeted may be modified over time by the placement service based on various considerations using machine learning techniques.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Sun and Shang in the Lyu system as modified. Moreover, in order to improve the reconciliation process of the Lyu system as modified, one of ordinary skill in the art would have been motivated to use thresholds to control the size of a shard, so that the system can effectively perform the reconciliation process.
Examiner’s Note: Claim 17 recites “wherein the first threshold is greater than the second threshold.” This describes the characteristics of the thresholds. Therefore, these claims recite nonfunctional descriptive material. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability.
Conclusion
The prior art, made of record and not relied upon, is considered pertinent to the applicant’s disclosure.
Xue (CN 109859043 B) discloses a transaction settlement method comprising: notifying the clearing participation server corresponding to the target batch transaction; determining the target settlement file corresponding to the target batch transaction; calculating the target hash value corresponding to the target clearing file based on the preset hash algorithm; sending the target hash value to the clearing participation server, so the clearing participation server can extract the local clearing file corresponding to the target batch transaction from the local database, based on the preset hash algorithm, to calculate the local hash value corresponding to the local settlement file; and then performing transaction settlement based on the target hash value and the local hash value.
Liu (US 20210133702 A1) discloses that a first account reconciliation device and a second account reconciliation device may store transaction records for which account reconciliation is to be performed to a blockchain in the blockchain node. Blocks on the blockchain are stored in a first block file.
Hanrahan et al. (US 20180046992 A1) discloses account reconciliation using a distributed ledger.
The 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). The applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUNLING DING, whose telephone number is (571)270-3605. The examiner can normally be reached 9:30 - 7:30 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, an 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, Neha Patel, can be reached at 571-270-1492. 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.
/CHUNLING DING/Primary Examiner, Art Unit 3699
Prosecution Insights