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 a first office action on the merits in response to the application filed on June 13, 2024.
Preliminary Amendment – Preliminary amendments to the claims, the abstract, the specification, and the drawing, are acknowledged.
Claims 3, 5, and 25-26 have been amended; claims 8, 10, and 21-24 have been canceled.
Claims 1-7, 9, 11-20, and 25-26 are pending and have been examined.
Claim Objections
Claims 3, 7, 12, and 18 are objected to because of the following informalities:
Claim 3 recites “sending the classification to which the inconsistent transaction record belongs to the automatic error handling system by means of the transaction reconciliation platform.” Claim 3 depends on claim 1, and an automatic error handing system is cited for the first time. Therefore, the phrasing, “the automatic error handling system,” should be changed to “an automatic error handling system.”
Claim 7 recites “wherein feed the batch hash value and the shard hash values onto the blockchain comprises.” The word, “feed,” should be changed to “feeding.”
Claim 12 recites “wherein before the sending the inconsistent transaction record to an automatic error handling system, the method further comprises: marking an error classification on the inconsistent transaction record according to a preset business rule; and the sending the inconsistent transaction record to an automatic error handling system further comprises: sending the error classification of the inconsistent transaction record to the automatic error handling system.” Claim 12 depends on claim 11, and claim 11 recites an automatic error handling system. Therefore, the underlined phrasing, “an automatic error handling system,” should be changed to “the automatic error handling system” for more clarity.
Claim 18 recites “feeding, by the institution and the transaction reconciliation platform, the record hash values onto the blockchain.” The phrasing, “the record hash values,” should be changed to “record hash values.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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 4-6 and 15-16 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 4 recites “wherein the batch hash value is obtained by sequentially splicing the shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and the shard hash value is obtained by sequentially splicing the record hash values obtained by performing hash operation on each transaction record comprised in the shard.” There is insufficient antecedent basis for the underlined limitations in the claim.
Claim 5 recites “wherein the transaction record has a transaction initiation time point.” There is insufficient antecedent basis for the underlined limitation in the claim.
Claim 6 recites “wherein the shard hash are fed onto a blockchain node in a form of a list; and performing comparison of the shard hash values of the blockchain node of the institution with the shard hash values of the transaction reconciliation platform comprises.” There is insufficient antecedent basis for the underlined limitations in the claim. Additionally, the phrasing, “the shard hash,” may need to be changed to “shard hash values.”
Claim 15 recites “wherein the transaction record has time information, and the data to be reconciled is sharded based on the time information.” There is insufficient antecedent basis for the underlined limitation in the claim.
Claim 16 recites “wherein the transaction records have ordered message identification numbers; and the shard hash values are obtained by sorting the transaction records of each shard incrementally according to the message identification numbers, and performing hash operation on the transaction records after sharding the data to be reconciled.” Claim 16 depends on claim 9, and claim 9 recites “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.” The transaction records cited in claim 9 are the transaction records comprised in an inconsistent shard. It is unclear whether the transaction records cited in claim 16 are the same set of transaction records as cited in claim 9.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 26 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter.
Claim 26 recites “[a] computer-readable medium, storing a computer program, wherein the program implements following actions when executed by a processor.” It is directed to transitory forms of signal transmission (often referred to as “signals per se”). Therefore, claim 26 is no patent eligible.
Claims 1-7, 9, 11-20, and 25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In this instance, claims 1-7 are directed to a method, claims 9 and 11-17 are directed to a method, claims 18-20 are directed to a method, and claim 25 is directed to an electronic reconciliation device comprising a memory and one or more processors. Therefore, claims 1-7, 9, 11-20, and 25 fall within the four statutory categories of invention.
Claim 1 as a whole is directed to the reconciliation of transactions. In particular, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. In other words, the claim falls under the “Certain Methods of Organizing Human Activity” and “Mental Processes” groupings of abstract ideas in Step 2A Prong One (MPEP 2106.04(a)(d)) because the claim involves the steps for the reconciliation of transactions, which is a process related to fundamental economic principles or practices. Additionally, the comparisons of hash values for a batch of transactions, shards of transactions, and a transaction can be performed in the human mind. More specifically, the following underlined claim elements recite an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 1 recites “[a] reconciliation method based on a blockchain, comprising: 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, wherein the batch hash values are generated according to a reconciliation batch transaction record; performing first comparison on 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; 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; and notifying the institution and the transaction reconciliation platform of the inconsistent transaction record.”
This judicial exception is not integrated into a practical application because, when analyzed under Step 2A Prong Two (MPEP 2106.04(d)), the non-underlined additional element of a blockchain is recited as a particular technological environment to perform the reconciliation of transactions. Therefore, the additional element of blockchain generally links the use of the judicial exception to a particular technological environment or field of use. As discussed above, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. The claim elements may improve the identified abstract idea itself, but do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); the claim does not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)); and the claim does not apply or use the abstract idea in some other meaningful ways beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claim does not, for example, purport to improve the functioning of a computer. Nor does it effect an improvement in any other technology or technical field. Accordingly, the additional element does not impose any meaningful limits on practicing the abstract idea. Claim 1 as a whole, judging from the claim elements individually and in combination, does not integrate the judicial exception into a practical application. Therefore, claim 1 as a whole fails to recite a practical application of the abstract idea.
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under Step 2B (MPEP 2106.05), using a blockchain as a particular technological environment to perform the reconciliation of transactions amounts to no more than merely indicating a field of use or technological environment in which to apply a judicial exception and/or using computer components to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claim merely recites the reconciliation of transactions. Therefore, the use of the additional element does nothing more than generally linking the use of the judicial exception to a particular technological environment or field of use and/or employing the computer components as tools to automate and/or implement the abstract idea. Therefore, the claim elements, when considered individually and in combination, fail to recite significantly more than the abstract idea.
Accordingly, claim 1 is rejected as being directed toward patent-ineligible subject matter.
Claims 2-7 have also been considered for subject-matter eligibility. However, these claims fail to recite patent-eligible subject matter for the following reasons:
Claim 2 recites sending the inconsistent transaction record to a system by means of the transaction reconciliation platform, such that the system performs error handling by calling an interface provided by the institution, and feeds back an error handling result to the transaction reconciliation platform, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional elements of an automatic error handling system and an error handling interface are recited as tools to perform the abstract idea, and they amount to no more than mere instructions to apply the exception using generic computer components. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Claim 3 recites 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 system by means of the transaction reconciliation platform, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. The additional element of an automatic error handling system is recited as a tool to perform the abstract idea, and it amounts to no more than mere instructions to apply the exception using a generic computer component. This additional element does not integrate the judicial exception into a practical application and fails to recite significantly more than the abstract idea.
Claim 4 recites wherein the batch hash value is obtained by sequentially splicing the shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and the shard hash value is obtained by sequentially splicing the record hash values obtained by performing hash operation on each transaction record comprised in the shard, which further limits the identified abstract idea and falls under the “Mental Processes” and/or “Mathematical Concepts” groupings of abstract ideas. No new additional elements are identified.
Claim 5 recites wherein the 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, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. No new additional elements are identified.
Claim 6 recites wherein the shard hash are fed in a form of a list; and performing comparison of the shard hash values of the institution with the shard hash values of the transaction reconciliation platform comprises: performing operation on a shard hash value list fed by the institution and a shard hash value list fed by the transaction reconciliation platform for comparison, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mathematical Concepts” groupings of abstract ideas. The additional elements of a blockchain node and a blockchain generally link the use of the judicial exception to a particular technological environment or field of use. The additional element of Cartesian product is a known algorithm. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Claim 7 recites wherein before the acquiring of a batch hash value fed by an institution to be reconciled and a batch hash value fed by a transaction reconciliation platform respectively, the method further comprises: feeding the batch hash value corresponding to the reconciliation batch transaction record by means of the institution and the transaction reconciliation platform respectively; wherein feeding the batch hash value and the shard hash values comprises: calling a contract to store the batch hash value and the shard hash values in an attribute of the contract, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional elements of a blockchain node and a blockchain generally link the use of the judicial exception to a particular technological environment or field of use. The additional element of a smart contract is a known type of contract that comprises executable instructions. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Regarding independent claim 9, claim 9 as a whole is directed to the reconciliation of transactions. In particular, the claim recites steps for locating an inconsistent transaction by narrowing down the ranges for comparisons from the shards of transactions to transactions in a determined inconsistent shard. In other words, the claim falls under the “Certain Methods of Organizing Human Activity” and “Mental Processes” groupings of abstract ideas in Step 2A Prong One (MPEP 2106.04(a)(d)) because the claim involves the steps for the reconciliation of transactions, which is a process related to fundamental economic principles or practices. Additionally, the comparisons of hash values for shards of transactions and a transaction can be performed in the human mind. More specifically, the following underlined claim elements recite an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 9 recites “[a] reconciliation method based on a blockchain, comprising: triggering, in response to receiving shard hash values of data to be reconciled fed onto the blockchain by reconciliation participants, a smart contract to perform comparison on the shard hash values, wherein the 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; 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 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, and generating a reconciliation result.”
This judicial exception is not integrated into a practical application because, when analyzed under Step 2A Prong Two (MPEP 2106.04(d)), the non-underlined additional element of a blockchain is recited as a particular technological environment to perform the reconciliation of transactions, and the non-underlined additional element of a smart contract is a known type of contract that comprises executable instructions. Therefore, the additional element of blockchain generally links the use of the judicial exception to a particular technological environment or field of use, and the additional element of a smart contract is merely used as a tool to perform the abstract idea. As discussed above, the claim recites steps for locating an inconsistent transaction by narrowing down the ranges for comparisons from the shards of transactions to transactions in a determined inconsistent shard. The claim elements may improve the identified abstract idea itself, but do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); the claim does not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)); and the claim does not apply or use the abstract idea in some other meaningful ways beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claim does not, for example, purport to improve the functioning of a computer. Nor does it effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea. Claim 9 as a whole, judging from the claim elements individually and in combination, does not integrate the judicial exception into a practical application. Therefore, claim 9 as a whole fails to recite a practical application of the abstract idea.
Claim 9 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under Step 2B (MPEP 2106.05), using a blockchain as a particular technological environment and a smart contract to perform the reconciliation of transactions amounts to no more than merely indicating a field of use or technological environment in which to apply a judicial exception and/or using computing components to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the claim recites steps for locating an inconsistent transaction by narrowing down the ranges for comparisons from the shards of transactions to transactions in a determined inconsistent shard. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claim merely recites the reconciliation of transactions. Therefore, the use of the additional elements does nothing more than generally linking the use of the judicial exception to a particular technological environment or field of use and/or employing the computing components as tools to automate and/or implement the abstract idea. Therefore, the claim elements, when considered individually and in combination, fail to recite significantly more than the abstract idea.
Accordingly, claim 9 is rejected as being directed toward patent-ineligible subject matter.
Claim 25 recites the abstract idea similar to that discussed above in connection with claim 9. As analyzed above, the use of the additional elements of a blockchain, a smart contract, and an electronic reconciliation device comprising one or more processors and a memory does nothing more than generally linking the use of the judicial exception to a particular technological environment or field of use and/or employing the computer components as tools to automate and/or implement the abstract idea. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Claims 11-17 have also been considered for subject-matter eligibility. However, these claims fail to recite patent-eligible subject matter for the following reasons:
Claim 11 recites wherein the method further comprises: sending the inconsistent transaction record to a system, such that the system calls the reconciliation institution to perform error handling and obtains an error handling result fed back by the reconciliation institution, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional element of wherein the reconciliation participants comprise a reconciliation institution and a transaction reconciliation platform merely describes the characteristics of the reconciliation participants. The additional element of an automatic error handling system is recited as a tool to perform the abstract idea, and it amounts to no more than mere instructions to apply the exception using a generic computer component. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Claim 12 recites wherein before the sending of the inconsistent transaction record to an system, the method further comprises: marking an error classification on the inconsistent transaction record according to a preset business rule; and the sending of the inconsistent transaction record to an system further comprises: sending the error classification of the inconsistent transaction record to the system, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. The additional element of an automatic error handling system is recited as a tool to perform the abstract idea, and it amounts to no more than mere instructions to apply the exception using a generic computer component. This additional element does not integrate the judicial exception into a practical application and fails to recite significantly more than the abstract idea.
Claim 13 recites wherein the preset business rule is implemented as a contract; and the marking of an error classification on the inconsistent transaction record according to a preset business rule comprises: calling the contract, and marking the error classification on the inconsistent transaction record in combination with a specific transaction scene and a failure reason, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. The additional element of an automatic error smart contract is merely used as a tool to perform the abstract idea. This additional element does not integrate the judicial exception into a practical application and fails to recite significantly more than the abstract idea.
Claim 14 recites wherein the reconciliation institution performs error handling according to an error handling flow corresponding to the error classification of the inconsistent transaction record, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. No new additional elements are identified.
Claim 15 recites wherein the transaction record has time information, and the data to be reconciled is sharded based on the time information, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. No new additional elements are identified.
Claim 16 recites wherein the transaction records have ordered message identification numbers; and the shard hash values are obtained by sorting the transaction records of each shard incrementally according to the message identification numbers, and performing hash operation on the transaction records after sharding the data to be reconciled, which further limits the identified abstract idea and falls under the “Mental Processes” and/or “Mathematical Concepts” groupings of abstract ideas. No new additional elements are identified.
Claim 17 recites 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, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. No new additional elements are identified.
Regarding independent claim 18, claim 18 as a whole is directed to the reconciliation of transactions. In particular, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. In other words, the claim falls under the “Certain Methods of Organizing Human Activity” and “Mental Processes” groupings of abstract ideas in Step 2A Prong One (MPEP 2106.04(a)(d)) because the claim involves the steps for the reconciliation of transactions, which is a process related to fundamental economic principles or practices. Additionally, the comparisons of hash values for a batch of transactions, shards of transactions, and a transaction can be performed in the human mind. More specifically, the following underlined claim elements recite an abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 18 recites “[a] reconciliation method based on a blockchain, comprising: feeding, by an institution to be reconciled and a transaction reconciliation platform, batch hash values corresponding to reconciliation batch transaction record onto the blockchain respectively, wherein the batch hash values are generated according to the reconciliation batch transaction record; triggering a smart contract to respectively acquire the batch hash values fed onto the blockchain by the institution and the transaction reconciliation platform in response to a reconciliation processing instruction, and performing first comparison on 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; 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; and notifying the institution and the transaction reconciliation platform of the inconsistent transaction record.”
This judicial exception is not integrated into a practical application because, when analyzed under Step 2A Prong Two (MPEP 2106.04(d)), the non-underlined additional element of a blockchain is recited as a particular technological environment to perform the reconciliation of transactions, and the non-underlined additional element of a smart contract is a known type of contract that comprises executable instructions. Therefore, the additional element of blockchain generally links the use of the judicial exception to a particular technological environment or field of use, and the additional element of a smart contract is merely used as a tool to perform the abstract idea. As discussed above, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. The claim elements may improve the identified abstract idea itself, but do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); the claim does not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)); and the claim does not apply or use the abstract idea in some other meaningful ways beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claim does not, for example, purport to improve the functioning of a computer. Nor does it effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea. Claim 18 as a whole, judging from the claim elements individually and in combination, does not integrate the judicial exception into a practical application. Therefore, claim 18 as a whole fails to recite a practical application of the abstract idea.
Claim 18 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under Step 2B (MPEP 2106.05), using a blockchain as a particular technological environment and a smart contract to perform the reconciliation of transactions amounts to no more than merely indicating a field of use or technological environment in which to apply a judicial exception and/or using computing components to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the claim recites steps for locating an inconsistent transaction in a batch of transactions by narrowing down the ranges for comparisons from a batch of transactions to shards of transactions, and from the shards of transactions to transactions in a determined inconsistent shard. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claim merely recites the reconciliation of transactions. Therefore, the use of the additional elements does nothing more than generally linking the use of the judicial exception to a particular technological environment or field of use and/or employing the computing components as tools to automate and/or implement the abstract idea. Therefore, the claim elements, when considered individually and in combination, fail to recite significantly more than the abstract idea.
Accordingly, claim 18 is rejected as being directed toward patent-ineligible subject matter.
Claims 19-20 have also been considered for subject-matter eligibility. However, these claims fail to recite patent-eligible subject matter for the following reasons:
Claim 19 recites sending the inconsistent transaction record to a system by the transaction reconciliation platform, such that the system calls an interface provided by the institution to perform error handling, and feeds back an error handling result to the transaction reconciliation platform; and feeding the error handling result by the transaction reconciliation platform, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional elements of an automatic error handling system and an error handling interface are recited as tools to perform the abstract idea, and they amount to no more than mere instructions to apply the exception using generic computer components. The additional element of a blockchain is merely recited as a storage. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
Claim 20 recites wherein after the institution and the transaction reconciliation platform feed each time, data fed by the institution is synchronized to the transaction reconciliation platform; and obtains the data fed by the institution and the transaction reconciliation platform, which further limits the identified abstract idea and falls under the “Certain Method of Organizing Human Activity” and/or “Mental Processes” groupings of abstract ideas. The additional elements of a blockchain and a blockchain node generally link the use of the judicial exception to a particular technological environment or filed of use. The additional elements of a data synchronization function and a smart contract are recited as tools to perform the abstract idea, and they amount to no more than mere instructions to apply the exception using generic computing components. These additional elements do not integrate the judicial exception into a practical application and fail to recite significantly more than the abstract idea.
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, 4-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: 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 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.”)
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 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.”)
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; and
notifying the institution and the transaction reconciliation platform of the inconsistent transaction record.
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.”)
Lyu discloses feeding the hash values onto a blockchain and comparing the hash values for reconciliation. 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 Lee 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 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.
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.”)
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 Lee system, 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 when an inconsistent subset is identified, so that the transaction record associated with the inconsistent subset can be effectively determined based on the provided hash values of each transaction record.
Claim 4:
Lyu in view of Zou and Chen discloses the limitation shown above.
Chen further discloses wherein the batch hash value is obtained by sequentially splicing the shard hash values corresponding to all shards comprised in the reconciliation batch transaction record; and the shard hash value is obtained by sequentially splicing the record hash values obtained by performing hash operation on each transaction record comprised in the shard. (See pages 9-10, “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. S103: generating a plurality of account checking files according to the leaf nodes of the Merkel tree; in the step, performing hash calculation between every two leaf nodes of the Merkel tree to obtain iterated leaf nodes and a reconciliation file; performing Hash calculation between every two leaf nodes after iteration to obtain the leaf nodes after secondary iteration and a reconciliation file.”)
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 Lee system, one of ordinary skill in the art would have been motivated to sequentially splice 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 5:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses wherein the 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: 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”; 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.”)
Lyn does not explicitly disclose the following:
shard hash values of date to be reconciled and wherein the shard hash values are obtained by performing hash operation on each shard after sharding the data to be reconciled;
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
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. 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 by 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 Lee 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:
performing comparison on the shard hash values;
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;
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 performing comparison on the shard hash values; 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; 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.”)
Lyu discloses providing hash values onto a blockchain and utilizing a smart contract to compare hash values. 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 Lee system, 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, so that the transaction record associated with the inconsistent subset can be further determined based on the record files associated with hash values of each transaction record.
Claim 15:
Lyu in view of Zou and Chen discloses the limitation shown above.
Lyu discloses wherein the transaction record 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 the transaction records have ordered message identification numbers; and the shard hash values are obtained by sorting the transaction records of each shard incrementally according to the message identification numbers, and performing hash operation on the transaction records 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 Lee system, 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 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; and
notifying the institution and the transaction reconciliation platform of the inconsistent transaction record.
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 Lee 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; and
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.
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.”)
Lyu discloses providing hash values and utilizing a smart contract to compare two sets of data. 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 Lee system, one of ordinary skill in the art would have been motivated to notify the participants of providing the hash values of each transaction record for further comparison via a smart contract when an inconsistent subset is identified, so that the transaction record associated with the inconsistent subset can be further determined based on the record files associated with hash values of each transaction record.
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 Lee system, 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 Lee system, 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 the sending the inconsistent transaction record to an 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 Lee system, 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 Lee system, 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 Lee system, 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 Lee system, 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 the shard hash are fed onto a blockchain node in a form of a list; and performing comparison based on the shard hash values of the blockchain node of 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 Lee system, 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 contact 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 Lee system, 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 Lee system, 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.
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