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 .
Information Disclosure Statement
The Information Disclosure Statements filed on 08 December 2025 and 12 March 2026 comply with all applicable rules and regulations. Therefore, the information referred to therein has been considered.
The listing of references in the specification is not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
In this case, page 38 states “Additional details of the functionality of event streams may be found in GB2002285.1 filed in the name of nChain Holdings Limited, GB2020279.2 filed in the name of nChain Holdings Limited” and page 52 states “in accordance with the process set out in GB2109064.2 filed on 24 June 2021 in the name of nChain Licensing AG”. These three foreign documents have not been “submitted on a separate paper”. Therefore, they have not been considered.
Response to Arguments
Applicant's arguments filed 28 January 2026 have been fully considered but they are not persuasive.
In response to applicant’s arguments regarding the 35 U.S.C. 101 rejection that “This is not an abstract outcome and instead represents a real practical application of the present invention”, stated on page 8, the examiner respectfully disagrees.
Particularly, applicant states “The analysis of hardware processing instruction data to make a determination as to whether instruction data has been duplicated across multiple requests is not abstract and instead relates to an improvement in the operation of the hardware processing resource”.
See MPEP 2106.04(d)(1)—"first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. Second, if the specification sets forth an improvement in technology, the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. That is, the claim includes the components or steps of the invention that provide the improvement described in the specification.”
The specification does not appear to disclose either implicitly or explicitly the stated improvement. The examiner suggests providing particular sections of the specification that disclose the improvement.
Therefore, the claimed invention does not appear to improve a technology or technological field.
Furthermore, the claims do not indicate that the instruction data is “hardware processing instruction data” or some other type of instructions for the processor. For example, claim 1 states “the instruction data relating to a transaction being processed by the hardware processing resource”. This limitation merely indicates that the data is somehow related to a transaction being processed. This could be any of a multitude of basic data such as a transaction ID or a timestamp.
Therefore, the stated “improvement” is not reflected in the claims since the claims do not include the components or steps that provide the improvement described in the specification.
Therefore, the 35 U.S.C. 101 rejection of the claims stands.
Side note: applicant points to “paragraph [0014]” of the specification on page 8. However, the specification has not been filed with numbered paragraphs.
In response to applicant’s arguments that “This is in contrast to the present claim in which both of the first request and the subsequent received request are rejected”, stated on page 9, the examiner respectfully disagrees.
Lv discloses the server 403 receives a transaction request from the client 401 (506), wherein the transaction request can include a hash of a requested transaction for storage in a blockchain maintained by the server 403 (Fig. 5, el. 506; Col. 10, lines 53-58). Subsequently, if the server 403 determines that the hash of the requested transaction is already included in the blockchain 216, the server 403 will send a transaction rejection to the client 301 (510), wherein the existence of a duplicate transaction hash can indicate that the client 301 is malicious and is replaying stolen information to gain server access (Fig. 5, el. 510; Col. 11, lines 13-18).
Lv also discloses that a replay attack involves an attacker intercepting one or more messages sent between the two computing devices and re-sending the messages (Col. 1, lines 27-31).
Liu discloses that each node in the blockchain network 20 can use the block list to verify whether the obtained transaction data is transaction data in a historical block that has been uploaded to the blockchain; if yes, determine the obtained transaction data as duplicate transaction data, and forbid generation of a block according to the duplicate transaction data (Para. 62). Liu further discloses the block list is list of historical blocks that have been uploaded to a blockchain.
Note that if both the first request and the further request include data that is duplicate of data in the log, then both requests will be rejected as duplicates according to the claim language of claims 1 and 13. In other words, the further request would be rejected for the same reason as the first request.
If the intent of the indicated limitation is to indicate that the instruction data of the first request and instruction data of the further request are identical, but are not identical to any instruction data in the log, then the independent claims should be amended to reflect that.
The examiner suggests clarifying the “the further request comprising identical instruction data to the request…” limitation to indicate whether the instruction data is also identical to instruction data in the log and, if not, to indicate how it is determined that the instruction data of the requests is identical.
Therefore, the aforementioned limitation is taught by the combination of the cited prior art.
Specification
The incorporation of essential material in the specification by reference to an unpublished U.S. application, foreign application or patent, or to a publication is improper. Applicant is required to amend the disclosure to include the material incorporated by reference, if the material is relied upon to overcome any objection, rejection, or other requirement imposed by the Office. The amendment must be accompanied by a statement executed by the applicant, or a practitioner representing the applicant, stating that the material being inserted is the material previously incorporated by reference and that the amendment contains no new matter. 37 CFR 1.57(g).
See page 52—“The instance of the payment processing resource 106 is used to manage the activity surrounding an asset which is managed by an account which is established on the payment processing resource 106 in accordance with the process set out in GB2109064.2 filed 24 June 2021in the name of nChain Licensing AG .”
The disclosure is objected to because of the following informalities: page 52—" set out in GB2109064.2 filed 24 June 2021in the name of nChain Licensing AG .” should be amended to include a space between “24 June 2021” and “in” and to remove the extra space between “AG” and the period.
Appropriate correction is required.
Claim Objections
Claims 1, 13, and 15 are objected to because of the following informalities:
Regarding claim 1, lines 20 and 21—“an entry” appears to be referring to “an entry” of line 5. Lines 20 and 21 should be amended to state --the entry--, in order to refer to the previous limitations.
Claim 13 includes similar language and is similarly analyzed.
Regarding claim 15, line 6—“an entity” appears to be referring to “an entity” of line 4. Line 6 should be amended to state --the entity-- in order to refer to the previous limitations.
Appropriate correction is required.
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.
Claims 1-11 and 13-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 13 recite receiving a request to append an entry to the at least one event stream, retrieving the identifier for the at least one event stream from the request, based on the identifier, accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream, retrieving the instruction data from the request, generating a unique identifier for the instruction data, based on the generated unique identifier, determining whether data identical to the instruction data is present in the log of previous entries associated with the identified at least one event stream, and based on an outcome of the determining step, either appending the entry to the at least one event stream, or rejecting the entry to the at least one event stream as a duplicated entry, and wherein upon receipt of a further request…rejecting both requests.
The limitations of generating a unique identifier for the instruction data, determining whether data identical to the instruction data is present in the log of previous entries, based on an outcome of the determining step, either appending an entry to the at least one event stream, or rejecting the entry to the event stream as a duplicated entry, and …rejecting both requests, as drafted, are processes that, under its broadest reasonable interpretation, cover performance of the limitations in the mind or by a human using a pen and paper but for the recitation of generic computer components.
That is, other than reciting “the method implemented on a hardware processing resource,” for claims 1 and 13 and, additionally “A system” for claim 13, nothing in the claim elements precludes the steps from practically being performed in the mind or by a human using a pen and paper. For example, the “the method implemented on a hardware processing resource,” for claims 1 and 13 and “A system” for claim 13 language, “generating,” “determining,” “appending,” and “rejecting” in the context of these claims encompasses the user manually generating the unique identifier, determining whether the data is identical, appending the entry, and rejecting the entry or entries. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind or by a human using a pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, claim 1 includes the additional element of “a hardware processing resource” and claim 13 includes the additional elements of “A system” and “a hardware processing resource”. Both claims 1 and 13 include the steps of receiving a request to append an entry to the at least one event stream, retrieving the identifier for the at least one event stream from the request, accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream, retrieving the instruction data from the request, and receipt of a further request.
The “hardware processing resource” of claims 1 and 13 implementing the steps is recited with a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The same applies to the “system” of claim 13—it is recited with a high-level of generality and is a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The steps of “receiving,” “retrieving,” “accessing,” “obtaining,” “retrieving,” and “receipt” are also recited at a high level of generality and amount to mere data gathering, which is a form of insignificant extra-solution activity. According, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements do not impose any meaningful limits on practicing the abstract idea by including mere instructions to apply an exception using a generic computer and insignificant extra-solution activity. The claims are not patent eligible.
Dependent claims 2-11 and 14-20 do not include any limitations that are sufficient to amount to significantly more than the judicial exception. Therefore, claims 2-11 and 14-20 are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6-8, 13, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al. (US 2021/0357369 A1) in view of Lv (US 10,785,035 B1) and further in view of Liu (US 2022/0271960 A1).
Regarding claim 1, Kwon teaches a computer-implemented method of appending entries to at least one event stream…, e.g., in order to interconnect data between a plurality of blockchain networks 10 and 20 (that is, to ensure that the same data is commonly recorded), an interconnecting transaction of recording the same data for each of the blockchain networks 10 and 20 is performed (Fig. 2, el. 10, 20; Para. 34); the first blockchain network 10 is any blockchain network formed by a plurality of blockchain nodes, wherein the first blockchain network 10 may be a network that verifies its consistency through distributed consensus of blockchain nodes with respect to transaction requests, and records transaction data in newly generated blocks according to the verified results (Para. 31); the second blockchain network 20 is also any blockchain network formed by a plurality of blockchain nodes, wherein the second blockchain network 20 may also be a network that verifies its consistency through distributed consensus of blockchain nodes with respect to transaction requests, and records transaction data in newly generated blocks according to the verified results (Para. 32),
…,
the method implemented on a hardware processing resource, e.g., the first interconnecting device 100 and the second interconnecting device 200 may be configured as separate devices, or the first interconnecting device 100 and the second interconnecting device 200 may be configured as one device (Fig. 2, el. 100, 200; Para. 39); processor 510 (Fig. 12, el. 510),
the method comprising:
receiving a request to append an entry to the at least one event stream, e.g., in step S100, the first interconnecting device 100 receives an interconnecting transaction request from the user terminal 300, wherein the interconnecting transaction request is a request to perform an interconnecting transaction for interconnecting data between a plurality of blockchain networks 10 and 20, and may be a request to commonly record specific data in a plurality of blockchain networks 10 and 20 (Fig. 4, el. S100; Para. 50),
the entry comprising instruction data and an identifier for the at least one event stream, and the instruction data relating to a transaction being processed by the hardware processing resource, e.g., in step S200, the first interconnecting device 100 extracts reference information of the interconnecting transaction from the interconnecting transaction request or from data provided therewith, wherein the extracted reference information may include metadata of an interconnecting transaction, and may include a chain ID, channel ID, a chain code ID or smart contract ID of the interconnecting transaction (Para. 51);
the interconnecting transaction request is a request to perform an interconnecting transaction for interconnecting data between a plurality of blockchain networks 10 and 20—instruction data relating to a transaction being processed by the hardware processing resource--, and may be a request to commonly record specific data in a plurality of blockchain networks 10 and 20 (Para. 50);
Examiner note: in a case where the instruction data is a duplicate, the transaction (from the previous request) will already be processing by the hardware processing resource;
retrieving the identifier for the at least one event stream from the request, e.g., in step S200, the first interconnecting device 100 extracts reference information of the interconnecting transaction from the interconnecting transaction request or from data provided therewith, wherein the extracted reference information may include metadata of an interconnecting transaction, and may include a chain ID, channel ID, a chain code ID or smart contract ID of the interconnecting transaction (Fig. 4, el. S200; Para. 51);
based on the identifier, accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream, e.g., in step S300, the first interconnecting device 100 queries information of ongoing or scheduled transactions through a plurality of blockchain networks 10 and 20, and as an embodiment, the first interconnecting device 100 may query the information of the ongoing or scheduled transactions through a separately implemented distributed database 400, wherein the distributed database 400 may search or extract the information of the transactions registered in its transaction queue and provide it to the first interconnecting device 100 as information of the ongoing or scheduled transactions (Fig. 2, el. 200; Fig. 4, el. S300; Para. 52);
retrieving the instruction data from the request, e.g., in step S432, the first interconnecting device 100 independently performs the first interconnecting transaction through the first blockchain network 10 (Fig. 6, el. S432; Para. 73); in response to the request, the second interconnecting device 200, similar to the first interconnecting device 100, checks the ready state of the second blockchain network 20 and, when ready to perform a new transaction, generates and proceeds with the second interconnecting transaction (Para. 74); In step S453a, the first interconnecting device 100 divides the first interconnecting transaction into a plurality of steps through the first blockchain network 10 and performs the first step among them (Fig. 8, el. S453a; Para. 83); in step S453b, the first interconnecting device 100 requests the second interconnecting device 200 connected to the second blockchain network 20 to perform the first step of the interconnecting transaction, and the second interconnecting device 200 divides the second interconnecting transaction into a plurality of steps in response to the request, and performs the first step among them (Fig. 8, el. S453b; Para. 84);
…determining whether data…is present in the log of previous entries associated with the identified event stream, e.g., in step S300, the first interconnecting device 100 queries information of ongoing or scheduled transactions through a plurality of blockchain networks 10 and 20, and as an embodiment, the first interconnecting device 100 may query the information of the ongoing or scheduled transactions through a separately implemented distributed database 400, wherein the distributed database 400 may search or extract the information of the transactions registered in its transaction queue and provide it to the first interconnecting device 100 as information of the ongoing or scheduled transactions (Fig. 2, el. 200; Fig. 4, el. S300; Para. 52); in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Fig. 5, el. S410; Para. 62); and
based on the outcome of the determining step, either appending the entry to the at least one event stream…, e.g., in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Fig. 5, el. S410; Para. 62); in step S430, the first interconnecting device 100 applies an asynchronous scheme to perform an interconnecting transaction (Fig. 5, el. S430; Para. 68); in step S450, the first interconnecting device 100 applies a synchronous scheme to perform an interconnecting transaction (Fig. 5, el. S450; Para. 70); and
….
Kwon does not clearly teach a computer-implemented method of appending entries to at least one event stream such that duplicate entries are inhibited, wherein the at least one event stream pertains to an asset account associated with a user registered on an asset transfer platform;
generating a unique identifier for the instruction data;
based on the generated unique identifier, determining whether data identical to the instruction data is present in the log of previous entries associated with the identified at least one event stream;
based on the outcome of the determining step, either appending the entry to the at least one event stream, the entry comprising the unique identifier for the instruction data; or rejecting the entry to the at least one event stream as a duplicated entry; and
wherein upon receipt of a further request received at substantially the same time as the request to append an entry to the at least one event stream, the further request comprising identical instruction data to the request to append an entry to the at least one event stream, the method comprises rejecting both requests.
Lv teaches a computer-implemented method of appending entries to at least one event stream such that duplicate entries are inhibited, wherein the at least one event stream pertains to an asset account associated with a user registered on an asset transfer platform, e.g., the transaction management system 208 can be a digital wallet application running on a user device, wherein the digital wallet application can manage financial transactions of a user account and communicates with the node 214 to register new transactions on the blockchain 216, and example financial transactions include sending and receiving digital currency, executing smart contracts, opening a new user account, and so on (Fig. 2, el. 208, 214, 216; Col. 6, line 66-Col. 7, line 7);
if the server 403 determines that the hash of the requested transaction is already included in the blockchain 216, the server 403 will send a transaction rejection to the client 301 (510), wherein the existence of a duplicate transaction hash can indicate that the client 301 is malicious and is replaying stolen information to gain server access (Fig. 5, el. 510; Col. 11, lines 13-18);
the method implemented on a hardware processing resource, e.g., server 403 (Fig. 4, el. 403), wherein the server can be one or more consensus nodes of a blockchain network (Col. 8, lines 63-67); the processes and logic flows described in this specification can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. (Col. 13, lines 27-31),
the method comprising:
receiving a request to append an entry to the at least one event stream, the entry comprising instruction data…, and the instruction data relating to a transaction being processed by the hardware processing resource, e.g., in response to issuing the challenge, the server 403 receives a transaction request from the client 401 (506), wherein the transaction request can include a hash value calculated from the issued challenge, a password associated with the client, and a hash of a requested transaction for storage in a blockchain maintained by the server 403 (Fig. 5, el. 506; Col. 10, lines 53-58), wherein the transaction request can include a transfer of digital asset controlled by the client 401, and the client 401 can request the server 403 to record the transaction on a blockchain, e.g., the blockchain 216 (Col. 10, lines 41-44);
Examiner note: in a case where the instruction data is a duplicate, the transaction (from the previous request) will already be processing by the hardware processing resource;
…;
…accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream, e.g., the server 403 then determines whether the requested transaction is included in the blockchain 216 (508), wherein for example, the server 403 can query a cache resource storing the hash values of all transactions previously stored in the blockchain, wherein the server 403 can use a bloom filter to determine whether the blockchain 216 already includes the hash of the requested transaction (Fig. 5, el. 508; Col. 10, line 64-Col. 11, line 4);
retrieving the instruction data from the request, e.g., the server 403 proceeds with the transaction (416) (Fig. 4, el. 416; Col. 10, lines 4-10); the server 403 will proceed with the transaction (512) (Fig. 5, el. 512; Col. 11, lines 5-7);
generating, by the client, a unique identifier for the instruction data, e.g., the client 401 then computes a transaction hash h(m) of the transaction message m (406) (Fig. 4, el. 406; Col. 9, lines 14-16);
based on the generated unique identifier, determining whether data identical to the instruction data is present in the log of previous entries associated with the identified at least one event stream, e.g., the server 403 then determines whether the requested transaction is included in the blockchain 216 (508), wherein for example, the server 403 can query a cache resource storing the hash values of all transactions previously stored in the blockchain, wherein the server 403 can use a bloom filter to determine whether the blockchain 216 already includes the hash of the requested transaction (Fig. 5, el. 508; Col. 10, line 64-Col. 11, line 4); and
based on the outcome of the determining step, either appending the entry to the at least one event stream, the entry comprising the unique identifier for the instruction data, e.g., if the server 403 determines that the hash of the requested transaction is not included in the blockchain 216, the server 403 will proceed with the transaction (512) (Fig. 5, el. 512; Col. 11, lines 5-7); every transaction on the blockchain is indexed by a unique hash value, a match between the transaction hash h(m) and a transaction hash on the blockchain would indicate that the transaction information is a duplicate and may be from a replay attack (Col. 9, lines 32-36); or
rejecting the entry to the at least one event stream as a duplicated entry, e.g., if the server 403 determines that the hash of the requested transaction is already included in the blockchain 216, the server 403 will send a transaction rejection to the client 301 (510), wherein the existence of a duplicate transaction hash can indicate that the client 301 is malicious and is replaying stolen information to gain server access (Fig. 5, el. 510; Col. 11, lines 13-18); and
wherein upon receipt of a further request received at substantially the same time as the request to append an entry to the at least one event stream, the further request comprising identical instruction data to the request to append an entry to the at least one event stream, the method comprises rejecting both requests, e.g., in response to issuing the challenge, the server 403 receives a transaction request from the client 401 (506), wherein the transaction request can include a hash value calculated from the issued challenge, a password associated with the client, and a hash of a requested transaction for storage in a blockchain maintained by the server 403 (Fig. 5, el. 506; Col. 10, lines 53-58); if the server 403 determines that the hash of the requested transaction is already included in the blockchain 216, the server 403 will send a transaction rejection to the client 301 (510), wherein the existence of a duplicate transaction hash can indicate that the client 301 is malicious and is replaying stolen information to gain server access (Fig. 5, el. 510; Col. 11, lines 13-18);
a replay attack involves an attacker intercepting one or more messages sent between the two computing devices and re-sending the messages (Col. 1, lines 27-31);
the attacker 308 can resend the intercepted data verbatim in a new communication session with the interface 210 or the transaction management system 208 (Col. 7, lines 33-36).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon to include a computer-implemented method of appending entries to at least one event stream such that duplicate entries are inhibited, wherein the at least one event stream pertains to an asset account associated with a user registered on an asset transfer platform; generating a unique identifier for the instruction data;
based on the generated unique identifier, determining whether data identical to the instruction data is present in the log of previous entries associated with the identified at least one event stream; based on the outcome of the determining step, either appending the entry to the at least one event stream, the entry comprising the unique identifier for the instruction data; or rejecting the entry to the at least one event stream as a duplicated entry; and wherein upon receipt of a further request received at substantially the same time as the request to append an entry to the at least one event stream, the further request comprising identical instruction data to the request to append an entry to the at least one event stream, the method comprises rejecting both requests, using the known method of searching past transactions in the blockchain for a hash match of the proposed transaction, as taught by Lv, in combination with the blockchain system of Kwon, for the purpose of combatting replay attacks in the network (Lv-Col. 8, lines 58-59).
Kwon in view of Lv does not clearly teach the method implemented on a hardware processing resource, the method comprising: generating a unique identifier for the instruction data.
Liu teaches the method implemented on a hardware processing resource, e.g., first node 10 (Fig. 1, el. 10),
the method comprising:
…accessing the at least one event stream and obtaining a log of previous entries associated with the identified at least one event stream, e.g., the first node 10 obtains historical block information in a block list 100, wherein the historical block information includes historical hash values, and the historical hash values are hash values of transaction data in historical blocks that have been uploaded to the blockchain (Fig. 2, el. 10, 100; Para. 72);
retrieving the instruction data from the request, e.g., the first node 10 obtains a target transaction data (Para. 71); when a fifth node 30 receives an upload operation for transaction data A, the fifth node 30 may transmit a data uploading request (for uploading the data to a blockchain) to the blockchain network 20, where the data uploading request carries the transaction data A (Fig. 1, el. 30; Para. 55);
generating a unique identifier for the instruction data, e.g., the first node 10 sequentially generates to-be-checked hash values corresponding to transaction data in the to-be-uploaded transaction sequence 10c according to a hash algorithm (Fig. 2, el. 10c; Para. 71);
based on the generated unique identifier, determining whether data identical to the instruction data is present in the log of previous entries associated with the identified at least one event stream, e.g., the first node 10 matches each to-be-checked hash value in the to-be-checked hash value sequence 10d against the historical hash values in the block list 100, for example, matches the to-be-checked hash value 2 against the historical hash values in the block list 100 (Fig. 2, el. 10d; Para. 73); and
based on the outcome of the determining step, either appending the entry to the at least one event stream, the entry comprising the unique identifier for the instruction data, e.g., the to-be-uploaded transaction sequence 10b includes the transaction data 2, the transaction data 3, and the transaction data 4, wherein all transaction data in the to-be-uploaded transaction sequence 10b are transaction data that have not been uploaded to the blockchain (Fig. 2, el. 10b; Para. 78); the first node 10 generates a target block according to the to-be-uploaded transaction sequence 10b, and broadcasts the target block to a consensus network in the blockchain network, and after the consensus network reaches a consensus on the target block, the block generation node (e.g., the first node 10) in the blockchain network may add the target block to the ledger (Para. 79); determining target block information of the target block, when uploading of the target block is complete, the target block information includes a hash value of transaction data in the target block (Para. 104); or
rejecting the entry to the at least one event stream as a duplicated entry, e.g., the first node 10 may determine the transaction data 5 as duplicate transaction data, delete the duplicate transaction data from the transaction pool 40, and delete the duplicate transaction data from the to-be-uploaded transaction sequence 10c to obtain a to-be-uploaded transaction sequence 10b (Para. 78); and
wherein upon receipt of a further request received at substantially the same time as the request to append an entry to the at least one event stream, the further request comprising identical instruction data to the request to append an entry to the at least one event stream, the method comprises rejecting both requests, e.g., each node in the blockchain network 20 can use the block list to verify whether the obtained transaction data is transaction data in a historical block that has been uploaded to the blockchain; if yes, determine the obtained transaction data as duplicate transaction data, and forbid generation of a block according to the duplicate transaction data (Para. 62);
the first node 10 may determine the transaction data 5 as duplicate transaction data, delete the duplicate transaction data from the transaction pool 40, and delete the duplicate transaction data from the to-be-uploaded transaction sequence 10c to obtain a to-be-uploaded transaction sequence 10b (Para. 78).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv to include the method implemented on a hardware processing resource, the method comprising: generating a unique identifier for the instruction data, using the known method of generating, by a blockchain node, a hash of the transaction, as taught by Liu, in combination with the blockchain system of Kwon in view of Lv, for the purpose of avoiding repeated transmission or storage of transaction data, thereby avoiding a waste of storage resources (Liu-Abstract).
Regarding claim 6, Kwon in view of Lv in view of Liu teaches the method of claim 1.
Kwon further teaches wherein the request is to append the entry to a plurality of event streams, e.g., in step S100, the first interconnecting device 100 receives an interconnecting transaction request from the user terminal 300, wherein the interconnecting transaction request is a request to perform an interconnecting transaction for interconnecting data between a plurality of blockchain networks 10 and 20, and may be a request to commonly record specific data in a plurality of blockchain networks 10 and 20 (Kwon-Fig. 4, el. S100; Para. 50) and
the method further comprises:
retrieving the identifier for each of the plurality of event streams from the request, e.g., in step S200, the first interconnecting device 100 extracts reference information of the interconnecting transaction from the interconnecting transaction request or from data provided therewith, wherein the extracted reference information may include metadata of an interconnecting transaction, and may include a chain ID, channel ID, a chain code ID or smart contract ID of the interconnecting transaction (Kwon-Fig. 4, el. S200; Para. 51); e.g., in step S100, the first interconnecting device 100 receives an interconnecting transaction request from the user terminal 300, wherein the interconnecting transaction request is a request to perform an interconnecting transaction for interconnecting data between a plurality of blockchain networks 10 and 20, and may be a request to commonly record specific data in a plurality of blockchain networks 10 and 20 (Kwon-Fig. 4, el. S100; Para. 50);
identifying each of the plurality of event streams and corresponding logs of previous entries, e.g., in step S300, the first interconnecting device 100 queries information of ongoing or scheduled transactions through a plurality of blockchain networks 10 and 20, and as an embodiment, the first interconnecting device 100 may query the information of the ongoing or scheduled transactions through a separately implemented distributed database 400, wherein the distributed database 400 may search or extract the information of the transactions registered in its transaction queue and provide it to the first interconnecting device 100 as information of the ongoing or scheduled transactions (Fig. 2, el. 200; Fig. 4, el. S300; Para. 52); and
using…a search key, determining whether data…has been previously added to any of the logs, e.g., in step S300, the first interconnecting device 100 queries information of ongoing or scheduled transactions through a plurality of blockchain networks 10 and 20, and as an embodiment, the first interconnecting device 100 may query the information of the ongoing or scheduled transactions through a separately implemented distributed database 400, wherein the distributed database 400 may search or extract the information of the transactions registered in its transaction queue and provide it to the first interconnecting device 100 as information of the ongoing or scheduled transactions (Kwon-Fig. 2, el. 200; Fig. 4, el. S300; Para. 52); in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Kwon-Fig. 5, el. S410; Para. 62); and
based on the outcome of the determining step, either appending the entry to each of the event streams…, e.g., in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Kwon-Fig. 5, el. S410; Para. 62); in step S430, the first interconnecting device 100 applies an asynchronous scheme to perform an interconnecting transaction (Kwon-Fig. 5, el. S430; Para. 68); in step S450, the first interconnecting device 100 applies a synchronous scheme to perform an interconnecting transaction (Kwon-Fig. 5, el. S450; Para. 70).
Kwon does not clearly teach using the unique identifier as a search key, determining whether data identical to the instruction data has been previously added to any of the logs; and
based on the outcome of the determining step, either appending the entry to each of the event streams using the unique identifier; or
reject the entry to the plurality of the event streams.
Lv further teaches using the unique identifier as a search key, determining whether data identical to the instruction data has been previously added to the log, e.g., the server 403 then determines whether the requested transaction is included in the blockchain 216 (508), wherein for example, the server 403 can query a cache resource storing the hash values of all transactions previously stored in the blockchain, wherein the server 403 can use a bloom filter to determine whether the blockchain 216 already includes the hash of the requested transaction (Fig. 5, el. 508; Col. 10, line 64-Col. 11, line 4); and
based on the outcome of the determining step, either appending the entry to…the event stream using the unique identifier, e.g., if the server 403 determines that the hash of the requested transaction is not included in the blockchain 216, the server 403 will proceed with the transaction (512) (Fig. 5, el. 512; Col. 11, lines 5-7); every transaction on the blockchain is indexed by a unique hash value, a match between the transaction hash h(m) and a transaction hash on the blockchain would indicate that the transaction information is a duplicate and may be from a replay attack (Col. 9, lines 32-36); or
reject the entry to…the event stream, .g., if the server 403 determines that the hash of the requested transaction is already included in the blockchain 216, the server 403 will send a transaction rejection to the client 301 (510), wherein the existence of a duplicate transaction hash can indicate that the client 301 is malicious and is replaying stolen information to gain server access (Fig. 5, el. 510; Col. 11, lines 13-18).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon to include using the unique identifier as a search key, determining whether data identical to the instruction data has been previously added to any of the logs; and based on the outcome of the determining step, either appending the entry to each of the event streams using the unique identifier; or reject the entry to the plurality of the event streams, using the known method of searching past transactions in the blockchain for a hash match of the proposed transaction, as taught by Lv, in combination with the system including a plurality of blockchain networks of Kwon, using the same motivation as in claim 1.
Regarding claim 7, Kwon in view of Lv in view of Liu teaches the method of claim 1, wherein the method further comprises: determining, from the instruction data, a condition on the at least one event stream which must be satisfied for the entry to be added to the at least one event stream, and determining whether the condition has been satisfied prior to adding the entry to the at least one event stream, e.g., in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Kwon-Fig. 5, el. S410; Para. 62); in step S430, the first interconnecting device 100 applies an asynchronous scheme to perform an interconnecting transaction (Kwon-Fig. 5, el. S430; Para. 68); in step S450, the first interconnecting device 100 applies a synchronous scheme to perform an interconnecting transaction (Kwon-Fig. 5, el. S450; Para. 70).
Regarding claim 8, Kwon in view of Lv in view of Liu teaches the method of claim 7, wherein the condition is that an index of the at least one event stream must be less than or equal to an integer defined in the instruction data, e.g., in step S410, the first interconnecting device 100 determines whether the reference information and the queried information match each other, wherein at this time, the reference information includes the chain ID or chain code ID of the interconnecting transaction, and the queried information may include the chain ID or chain code ID of the ongoing or scheduled transaction of the plurality of blockchain networks 10, 20 (Kwon-Fig. 5, el. S410; Para. 62).
Regarding claim 13, the claim is analyzed with respect to claim 1. Kwon in view of Lv in view of Liu further teaches a system configured to implement the method, e.g., system environment 1000 (Kwon-Fig. 2, el. 1000).
Regarding claim 16, the claim is analyzed with respect to claim 6.
Regarding claim 17, the claim is analyzed with respect to claim 7.
Regarding claim 18, the claim is analyzed with respect to claim 8.
Claims 2, 4, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu and further in view of Xia (US 2019/0278766 A1).
Regarding claim 2, Kwon in view of Lv in view of Liu teaches the method of claim 1.
Kwon in view of Lv in view of Liu does not clearly teach wherein the unique identifier for the instruction data comprises a cryptographic signature used to cryptographically sign the instruction data.
Xia teaches wherein the unique identifier for the instruction data comprises a cryptographic signature used to cryptographically sign the instruction data, e.g., Participant A generates a hash of the message, and then, using its private key, encrypts the hash to provide a digital signature as the encrypted hash, and Participant A appends the digital signature to the message, and sends the message with digital signature to Participant B, and Participant B decrypts the digital signature using the public key of Participant A, and extracts the hash, and Participant B hashes the message and compares the hashes (Para. 57); wherein an example of a path 300 for a transaction sent (or delivered) directly between two nodes in a blockchain, wherein the path 300 can be used for a transaction that is sent by Node_A 302 to Node_B 304 for execution by Node_B 304 (Para. 59).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu to include wherein the unique identifier for the instruction data comprises a cryptographic signature used to cryptographically sign the instruction data, using the known method of signing a transaction by a blockchain node, as taught by Xia, in combination with the blockchain system of Kwon in view of Lv in view of Liu, for the purpose of enabling a blockchain node to confirm that the transaction was not tampered with (Xia-Para. 57).
Regarding claim 4, Kwon in view of Lv in view of Liu in view of Xia teaches the method of claim 2, wherein the cryptographic signature is generated based on public and/or private keys owned by an entity associated with the instruction data, e.g., Participant A generates a hash of the message, and then, using its private key, encrypts the hash to provide a digital signature as the encrypted hash, and Participant A appends the digital signature to the message, and sends the message with digital signature to Participant B, and Participant B decrypts the digital signature using the public key of Participant A, and extracts the hash, and Participant B hashes the message and compares the hashes (Xia-Para. 57).
Regarding claim 14, the claim is analyzed with respect to claim 2.
Regarding claim 15, the claim is analyzed with respect to claim 4.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu in view of Xia and further in view of Cook et al. (US 2023/0031316 A1).
Regarding claim 3, Kwon in view of Lv in view of Liu in view of Xia teaches the method of claim 2.
Kwon in view of Lv in view of Liu in view of Xia does not clearly teach wherein the cryptographic signature is generated using elliptical digital signature algorithm techniques.
Cook teaches wherein the cryptographic signature is generated using elliptical digital signature algorithm techniques, e.g., cryptographic conventions such as Elliptic Curve Digital Signature Algorithm (ECDSA) with SHA-256 for signing and encrypting data with industry standard ciphers (Para. 26).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu in view of Xia to include wherein the cryptographic signature is generated using elliptical digital signature algorithm techniques, using the known method of utilizing cryptographic conventions such as Elliptic Curve Digital Signature Algorithm (ECDSA) with SHA-256 for signing and encrypting data with industry standard ciphers, as taught by Cook, in combination with the blockchain system of Kwon in view of Lv in view of Liu in view of Xia, for the purpose of improving the security of the signature by utilizing the elliptic curve which is an extremely hard to solve.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu in view of Xia and further in view of Rector (US 2023/0224166 A1).
Regarding claim 5, Kwon in view of Lv in view of Liu in view of Xia teaches the method of claim 2.
Kwon in view of Lv in view of Liu in view of Xia does not clearly teach wherein the cryptographic signature is retrieved from a permit data structure associated with an entity associated with the instruction data.
Rector teaches wherein the cryptographic signature is retrieved from a permit data structure associated with an entity associated with the instruction data, e.g., signatures are generated (312) when a buyer first purchases an image (314) and are stored for reference in a data schema table 316, and if a buyer later wants to re-download the image, there may or may not be a signed copy of the image already available, and if the signed copy of the image is not available, it's simple to re-generate the image (318) by retrieving the signature (320) from the database 316 and adding it as metadata to the base image again (Fig. 3, el. 316; Para. 51); when an order is submitted in the system, signature generator 226 posts a message to purchase queue 228 that contains the image ID, artist name, recipient name, and number of credits to use, and signature generator 226 reads off the purchase queue 228, wherein for each purchase, signature generator 226 retrieves the appropriate number of credits from credit manager 236, including their identifiers, and the info for the purchased image—identifier and hash, and signature generator 226 generates an inscription string containing the artist, the purchaser, the credits, and the image hash, and digitally signs the string with a private key, wherein this signature is then stored in signature table 230, and an event notification 234 may be generated indicating that the signature is ready (Para. 45).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu in view of Xia to include wherein the cryptographic signature is retrieved from a permit data structure associated with an entity associated with the instruction data, using the known method of retrieving a digital signature from a signature table, wherein the signature is generated and stored in the signature table when an order is submitted, as taught by Rector, in combination with the blockchain system of Kwon in view of Lv in view of Liu in view of Xia, for the purpose of an additional level of security and convenience by storing a signature related to a purchase transaction for later use.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu and further in view of Chalkias et al. (US 2019/0103973 A1).
Regarding claim 9, Kwon in view of Lv in view of Liu teaches the method of claim 7.
Kwon in view of Lv in view of Liu does not clearly teach wherein the condition is that the entry is added to the at least one event stream within a pre-determined time-period.
Chalkias teaches wherein the condition is that the entry is added to the at least one event stream within a pre-determined time-period, e.g., the components of a transaction may include the inputs, the outputs, the commands (e.g., for a smart contract), the attachments (e.g., written contract), an identification of a notary, an identification of an oracle (e.g., a service that provides real-time currency exchange rates), a validation time window (e.g., a notary will only notarize a transaction if received during this window) and so on (Para. 8); when parties agree on the terms of a transaction, a party submits the transaction to a notary, which is a trusted node or cluster of nodes, for notarization, wherein the notary maintains an UTXO database of unspent transaction outputs or alternatively spent transaction outputs, and when a transaction is received, the notary checks the inputs to the transaction against the UTXO database to ensure that the outputs referenced by the inputs have not been spent, and if the inputs have not been spent, the notary updates the UTXO database to indicate that the referenced outputs have been spent, notarizes the transaction, and sends the notarization to the party that submitted the transaction for notarization (Para. 7).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu to include wherein the condition is that the entry is added to the at least one event stream within a pre-determined time-period, using the known method of including a validation time window as a component of a transaction, as taught by Chalkias, in combination with the blockchain system of Kwon in view of Lv in view of Liu, for the purpose of enhancing the security of the transaction and the system by aiding in the prevention of a transaction being intercepted by a malicious user and submitted by the malicious user as his/her own.
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu and further in view of Qi et al. (US 2021/0232596 A1).
Regarding claim 10, Kwon in view of Lv in view of Liu teaches the method of claim 1.
Kwon in view of Lv in view of Liu does not clearly teach wherein the entries contained in the log are maintained in the log for a pre-defined minimum period of time.
Qi teaches wherein the entries contained in the log are maintained in the log for a pre-defined minimum period of time, e.g., deleting entries in log data that are older than/exceed the predetermined time period (e.g., delete stale entries older than 28 days) (Para. 42).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu to include wherein the entries contained in the log are maintained in the log for a pre-defined minimum period of time, using the known method of deleting entries in log data that are older than/exceed the predetermined time period, as taught by Qi, in combination with the blockchain system of Kwon in view of Lv in view of Liu, for the purpose of making space for new entries in the list while also preventing the list from getting too big.
Regarding claim 19, the claim is analyzed with respect to claim 10.
Claims 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon in view of Lv in view of Liu and further in view of Lipfert et al. (US 2012/0084392 A1).
Regarding claim 11, Kwon in view of Lv in view of Liu teaches the method of claim 1.
Kwon in view of Lv in view of Liu does not clearly teach wherein the processing resource is configured to maintain the log at a maximum size by removing entries which have been present in the log for longer than a pre-defined maximum period of time.
Lipfert teaches wherein the processing resource is configured to maintain the log at a maximum size by removing entries which have been present in the log for longer than a pre-defined maximum period of time, e.g., following expiry of a fixed period of time, old entries in the PaRL list are deleted, and the PaRL list is also limited by a maximum size of entries, and when this value is exceeded, the oldest entries are deleted in order to make space for new entries in the PaRL list (Para. 100).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kwon in view of Lv in view of Liu to include wherein the processing resource is configured to maintain the log at a maximum size by removing entries which have been present in the log for longer than a pre-defined maximum period of time, using the known method of limiting a list by a maximum size of entries and deleting old entries in the list after expiration of a fixed period of time, as taught by Lipfert, in combination with the blockchain system of Kwon in view of Lv in view of Liu, for the purpose of making space for new entries in the list while also preventing the list from getting too big (Lipfert-Para. 100).
Regarding claim 20, the claim is analyzed with respect to claim 11.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jois (US 2023/0031316 A1)—Jois discloses one issue that has persisted in on-line transactions is the problem of a “duplication of transaction.” Where there is any significant time delay, as in blockchains or other transactions where there must be an approval with a measurable time delay. In the finite interval between issuing a transaction and resolution, the original issuance may be directed or misdirected towards to a different or multiple recipient (Para. 160).
Jing (US 2022/0100777 A1)—Jing discloses generating a standard transaction request according to a standard key of a service application party, to-be-processed request data, a target blockchain architecture to be accessed and a target blockchain identifier; and calling a transaction conversion service and converting the standard transaction request into a target transaction request under the target blockchain architecture according to the standard key, the target blockchain architecture and the target blockchain identifier; where the target transaction request is used for processing the to-be-processed request data (Abstract).
Singh (US 11,645,650 B1)—Singh discloses receiving a transaction request from a first computing device, the transaction request corresponding to a pending transaction between the first computing device and a second computing device and comprising a first set of transaction attributes; appending block instances to blockchains of the first and second computing devices, retrieving or receiving, from the second computing device, a second set of transaction attributes; when the first set of transaction attributes match, identifying a second blockchain associated with the pending transaction; automatically executing a protocol to compare the first set of transaction attributes with data stored onto a ledger of the identified second blockchain; and, in response to determining that the first set of transaction attributes complies with data of the ledger of the identified second blockchain, appending block instance to the blockchain comprising data corresponding to the transaction request to blockchains of the first and second computing devices (Abstract).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
17 March 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498