,
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 the Claims
This is a final rejection prepared in response to applicant’s amendment filed on 05/09/2026.
Claims 2, 8-9 and 11-20 are cancelled.
Claims 1, 4, 6-7 and 10 are amended.
Claims 1, 3-7 and 10 are pending.
Claim Objections
Claims 1, 4 and 7 are objected to because of the following informalities:
Claim 1, recites the limitation "wherein the transaction content…" in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 1, the recited "… on transaction content" in lines 7-8, should be amended to “… the transaction content” as “… on transaction content” was previously recited on line 4.
Claim 1, recites “…recipient’s conformation signature” which is grammatically incorrect and should be amended to “…recipient’s confirmation signature”. Further, there is no antecedent basis in the claim for “…recipient’s confirmation signature”.
Claim 4, recites the limitation " the signature aggregate function" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 7, recites “the asset swapping method of claim 1 terminates the asset swapping method…” is redundant and unnecessarily repetitive.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-7 and 10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1, recites the limitation “the transaction content comprises … a flag indicating whether a recipient's signature is required in the transaction;” and “…if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature”. The specification does not provide support for “a flag indicating whether a recipient’s signature is required in the transaction” nor does it provide support for “…if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature”. The specifications in ¶0035 recite that each transaction requires both the sender’s and the recipient’s signatures, which contradicts the limitations above. Therefore, because the original specifications fail to reasonably convey to a person of ordinary skills in the art that the applicant had possession of the concept of a sensor integrated with the user device to obtain user credentials, the limitation constitutes new matter under 35 U.S.C. 112(a).
Claims 3-7 and 10 are also rejected as they depend on claim 1.
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 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.
Regarding claim 1, the limitation “validating the broadcast transactions by blockchain node or miners” is unclear. The claim recites broadcasting multiple transactions to the blockchain. It is therefore unclear which of these transactions is being validated in the recited step (i.e. the first transaction, the second transaction or both transactions).
Claim 1, recites the limitation “in response to a negative verification result, terminating the asset swapping method”, however the claim does not recite any verification step or way to generate a verification result. Therefore, it is unclear what is being verified, how the verification is performed and what constitutes a negative verification result.
Regarding claim 4, the limitation “the aggregate signature is generated using the signature aggregate function to secure against forgery” is unclear as of which aggregate signature is being referred to. Claim 1 recites “creating aggregate signatures…” in plural form, while claim 4 refers to “the aggregate signature…” in singular form. As a result, the claim lacks clarity as to whether claim 4 is directed to one of the aggregate signatures created in claim 1, to a specific aggregate signature among them, or to a different aggregate signature not previously introduced.
Claim 10, recites the limitation “packing, by the blockchain node or the blockchain miner, an accepted transaction into a block and broadcasting the block to the blockchain network.” It is not clear whether the “packing… an accepted transaction…” refers to one of the transactions previously recited in claim 1 (i.e. the first blockchain transaction, the second blockchain transaction) or it refers to a completely new transaction. Therefore, the claim is indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 3-7 and 10 are also rejected as they depend on claim 1.
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, 3-7 and 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1, 3-7 and 10 are directed to computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method for asset swapping between blockchains comprising:
negotiating, by a first participant and a second participant, to determine content of asset swapping transactions, wherein the transaction content comprises a locking script of a referenced previous transaction, transaction amounts, and a flag indicating whether a recipient's signature is required in the transaction;
producing, by each participant, an individual signature on transaction content
creating, by each participant, an aggregate signature from the individual signatures using a reversible signature aggregation function, wherein the aggregate signature is configured to allow recovery and verification of both a sender's signature and a recipient's confirmation;
exchanging, between the first participant and the second participant, the aggregate signatures, and in response to a negative verification result, terminating the asset swapping method;
constructing, by the second participant, a first blockchain transaction comprising the transaction content and both the sender's signature and recipient's conformation signature;
broadcasting, by the second participant, the first blockchain transaction to a blockchain network;
constructing, by the first participant, a second blockchain transaction comprising the transaction content and both the sender's signature and the recipient's confirmation signature;
broadcasting, by the first participant, the second blockchain transaction to a blockchain network;
validating, by a blockchain node or a blockchain miner, the broadcast transactions, wherein validating comprises: (1) checking a format of the transaction according to a blockchain specification; (ii) verifying a signature from a transaction payer; (iii) if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature; and (iv) in response to a negative verification result for the signature from the transaction payer or the signature from the transaction payee, rejecting the transaction.
Claim 1, recites (i.e., sets forth or describes) a method of negotiating a contract for exchanging assets between different parties. The method is executed by negotiating terms for a transaction, signing the contract/transaction, aggregating signatures by each participant, exchanging the aggregated signatures among the participants, collecting and verifying the signatures and recording the transaction. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas (commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
In regards to “producing, by each participant, an individual signature on transaction content”, “creating, by each participant, an aggregate signature from the individual signatures using a reversible signature aggregation function, wherein the aggregate signature is configured to allow recovery and verification of both a sender's signature and a recipient's confirmation;” and “(ii) verifying a signature from a transaction payer; (iii) if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature; and (iv) in response to a negative verification result for the signature from the transaction payer or the signature from the transaction payee, rejecting the transaction.” the examiner finds these to further recite an abstract idea as the recitations recite mathematical concept.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of blockchains, blockchain network, blockchain miner and blockchain nodes merely serve as tools to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 3-7 and 10 have also been analyzed for subject matter
eligibility. However, claims 3-7 and 10 also fail to recite patent eligible subject matter for the
following reasons:
Claim 3 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the participants sign the transaction contents according to a signature scheme comprising Boneh–Lynn–Shacham (BLS) or Schnorr signature scheme.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The non-underlined additional elements, if any, fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 4 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the aggregate signature is generated using the signature aggregate function to secure against forgery.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The non-underlined additional elements, if any, fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 5 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the reversible signature aggregate function is constructed with a BLS signature scheme given that public keys are authenticated.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The non-underlined additional elements, if any, fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 6 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the reversible signature aggregate function is constructed with a Schnorr signature scheme given that public keys are authenticated, and each ephemeral public key for signing a transaction content is fixed in an asset swapping method of claim 1.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The non-underlined additional elements, if any, fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 7 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the asset swapping method of claim 1 terminates the asset swapping method before any transaction is broadcast if the verification of the aggregate signature is negative.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mathematical concepts” grouping of abstract ideas. The non-underlined additional elements, if any, fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 10 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
packing, by the blockchain node or the blockchain miner, an accepted transaction into a block and broadcasting the block to the blockchain network.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-underlined additional elements of a blockchain node, a blockchain miner and blockchain network fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
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, 3, 6-7 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Brogliato (US 2024/0202703 A1) in view of Fay (US 20160292672 A1), further in view of Molloy (US20250053965 A1), and in further in view of Frosty (Aggregate Signature of Wisdom Chain Document Knowledge Base, 09/29/2020, https://www.reddit.com/user/Frosty_Gene_7770/comments/j1veec/aggregate_signature_of_wisdom_chain_document/?rdt=35061.)
Regarding claim 1, Brogliato discloses:
Negotiating, by a first participant and a second participant, to determine content of asset swapping transactions; (Brogliato ¶0083, Executing the trade S300 can include: determining trade information for each order S320 and facilitating the trade using the trade information S340, or be otherwise performed. Brogliato ¶0084, Determining the trade information S320 functions to determine the information needed to construct the blockchain transaction that executes the trade. The trade information functions to provide all the information needed for a user to send an asset to the opposing party. The trade information is preferably determined from the order information, but can additionally or alternatively be automatically generated by the exchange system, be determined from the partial transaction, be requested from the user (e.g., wherein the UTXOs to use are requested from the user wallet after the match is made), and/or otherwise determined. Brogliato ¶0091, In a second example, S342 includes generating a different unsigned transaction for each blockchain wallet within the match (e.g., by the exchange), wherein each unsigned transaction is sent to the respective blockchain wallet for signature. Brogliato ¶0105, In this example, a first user and a second user both utilize input and output UTXOs to exchange transaction data (i.e., perform an atomic swap). In this variant, the swap can be executed with only one on-chain transaction. The first user and the second user both have wallets and can establish an off-chain communication channel including email, Telegram, Discord, and/or any other suitable channel. The first user and second user can negotiate a transaction proposal, call the generation of one or more unsigned transactions and/or unsigned partial transactions by S342 and S344, respectively, and receive the transactions by S346 through a wallet application feature and/or otherwise called.)
producing, by each participant, an individual signature on transaction content;(Brogliato ¶0092, In a third example, S342 includes generating a different unsigned transaction by each blockchain wallet (e.g., before a match is made), wherein the blockchain wallet can also sign the unsigned transaction (e.g., using a partial signature, using a bitmask, etc.) before sending the unsigned transaction to the exchange for subsequent matching. Each unsigned transaction is preferably a partial transaction, and includes the trade information from the respective wallet (e.g., one or more: inputs, outputs, user- or wallet-selected inputs, user- or wallet-selected outputs, asset amount spent, asset amount received, spending address, receiving address, etc.), but can additionally or alternatively include trade information from the other party (e.g., be a full transaction). Brogliato ¶0094, Each user account in the match preferably generates at least one signature for the transaction to be considered valid (e.g., by the blockchain). The signatures are preferably generated offchain, but can alternatively be generated onchain. The signatures are preferably generated while the user wallets (e.g., private keys) are online (e.g., “hot”), but can be otherwise generated. Brogliato ¶0095, Receiving signed transactions functions to obtain a signature for the transaction from each user account involved in the trade. The signed transaction can be received by a centralized system (e.g., the exchange system), a user account involved in the match, and/or by any other suitable system. The signed transaction can be received offchain, but can alternatively be received onchain. ¶0105, The first user and the second user can sign the transaction(s) and send the signature(s) and/or transaction(s) to an off-chain execution system, but can be otherwise sent.)
in response to a negative verification result, terminating the asset swapping method(Brogliato ¶0096, The method can optionally include verifying if the signature on a partial transaction is valid and/or if the aggregated transaction is valid. The execution system and/or any other suitable system can receive the bitmask from a user and a signed partial transaction. The bitmask-indicated inputs and outputs can be verified as indeed relevant to the user to ensure the user and/or wallet are not signing on assets of others. If the test fails, the signature is invalid. If verified, the hash of the transaction with the bitmask appended to the header can be computed and compared against the signature provided by the user. If matched, the signature on the partial transaction can be deemed valid. Any other suitable verification strategies can be executed as well. The aggregated transaction can also be verified as valid if the execution system and/or any other suitable system can sign the aggregated transaction combining the partial signatures confirming that the signatures are valid for each of the partial transactions merged.)
validating, by a blockchain node or a blockchain miner, the broadcast transactions, wherein validating comprises: (i) checking a format of the transaction according to a blockchain specification; (ii) verifying a signature from a transaction payer; (Brogliato ¶0096, The method can optionally include verifying if the signature on a partial transaction is valid and/or if the aggregated transaction is valid. The execution system and/or any other suitable system can receive the bitmask from a user and a signed partial transaction. The bitmask-indicated inputs and outputs can be verified as indeed relevant to the user to ensure the user and/or wallet are not signing on assets of others. If the test fails, the signature is invalid. If verified, the hash of the transaction with the bitmask appended to the header can be computed and compared against the signature provided by the user. If matched, the signature on the partial transaction can be deemed valid. Any other suitable verification strategies can be executed as well. ¶0101, Once the unitary signed transaction is sent to the blockchain(s), the respective blockchain(s) preferably validate the signed transaction based on the blockchain's protocol (e.g., by the blockchain's nodes, using the blockchain's consensus mechanism, etc.), wherein signed transaction validation sends the assets to the respective addresses (e.g., executes the trade).)
Brogliato does not disclose, however Fay teaches:
constructing, by the second participant, a first blockchain transaction comprising the transaction content and both the sender's signature and recipient's conformation signature; (Fay ¶0052, In FIG. 2C and in step 256, computing device A 120A generates a blockchain transaction using the previously received trade and/or wallet information (e.g., that includes information of trading party B's digital wallet)… For example, a transaction message is generated that specifies the transfer of assets (e.g., 100 shares of AAPL) from one trading party (e.g., A) to the hashed wallet information that is associated with the counter party (e.g., B).)
broadcasting, by the second participant, the first blockchain transaction to a blockchain network; (Fay ¶0052, …and transmits the generated blockchain transaction to blockchain computer system 214 at step 257.
Constructing, by the first participant, the second blockchain transaction to a blockchain network; (Fay ¶0052, Similarly, computing device B 120B (the counter party) generates a blockchain transaction at step 258… The counter-transaction (e.g., generated by computing device B 120AB) may specify the transfer of some other assets (e.g., USD, bitcoin, other asset types, etc. . . . ).
Broadcasting, by the second participant, the second blockchain transaction to a blockchain network; (Fay ¶0052, …and transmits the transaction to blockchain computer system 214 at step 259.
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified Brogliato invention with Fay’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide individual user agreements (transactions) and commit them to the blockchain to complete the transfer.
The combination of Brogliato and Fay does not disclose, however Molloy teaches:
the transaction content comprises a locking script of a referenced previous transaction, transaction amounts, and a flag indicating whether a recipient's signature is required in the transaction; (Molloy ¶0008, In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So, consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction. Molloy ¶0066, Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato and Fay with Molloy’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to include a locking script, transaction amounts and a flag in the transaction which are routine necessary elements for multi-signature blockchain transactions.
The combination of Brogliato, Fay and Molloy do not disclose, however Frosty teaches:
creating, by each participant, an aggregate signature from the individual signatures using a reversible signature aggregation function, wherein the aggregate signature is configured to allow recovery and verification of both a sender's signature and a recipient's confirmation; (Frosty P.1, Aggregate signature is a kind of signature aggregation of key generated by each party using Schnorr Signature (a digital signature scheme, known for its simplicity and efficiency, and its security is based on the intractability of some discrete logarithm problems. Next, we will talk about Schnorr Signature. Frosty P. 3, The essence of aggregate signature is a signature offset. Once combined with the real signature, the private key used in the signature can be calculated. The credibility of aggregate signature can be verified without exposing any information at the same time. Aggregate signature can ensure the atomicity of atomic exchange and the security of both parties.).
exchanging, (Frosty P.2, A provides B with an aggregate signature, which needs to be confirmed by B.)
While the combination of Brogliato, Fay, Molloy and Frosty do not explicitly disclose both participants exchanging the aggregate signature, Frosty teaches that one party provides an aggregate signature to another party. Further, Frosty teaches that each party generates an aggregate signature, therefore, it would have been obvious to one of ordinary skill in the art, to have each party exchange the aggregated signatures to the other party in order to allow each party to verify the other’s party signature before completing the asset exchange.
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato, Fay and Molloy with Frosty’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure the atomicity of atomic exchange and the security of both parties. (Frosty P.2)
Further, the combination of prior art does not teach “if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature; and (iv) in response to a negative verification result for the signature from the transaction payer or the signature from the transaction payee, rejecting the transaction”". However, the claim limitations are conditional limitations which means that the claim limitations are only required when the stated conditions are met.
Regarding claim 3, the combination of Brogliato, Fay, Molloy and Frosty further discloses:
the participants sign the transaction contents according to a signature scheme comprising Boneh–Lynn–Shacham (BLS) or Schnorr signature scheme. (Frosty P.1, Aggregate signature is a kind of signature aggregation of key generated by each party using Schnorr Signature (a digital signature scheme, known for its simplicity and efficiency, and its security is based on the intractability of some discrete logarithm problems. Next, we will talk about Schnorr Signature). It can merge the public key and signature of each participant in a multi signature transaction into one public key and signature It is invisible, and the information before merging cannot be deduced from the public key and signature after merging, and only one verification is needed during verification. At present, Mimblewimble has used Schnorr signature algorithm to implement signature aggregation.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato, Fay, Molloy and Frosty with Frosty’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to reduce the cost of verifying signatures, the bandwidth consumption for network transmission and the occupation of storage space of nodes as well as to improve the privacy of data on the chain (Frosty P.1)
Regarding claim 6, the combination of Brogliato, Fay, Molloy and Frosty further disclose:
the reversible signature aggregate function is constructed with a Schnorr signature scheme given that public keys are authenticated, and each ephemeral public key for signing a transaction content is fixed in a swap process. (Frosty P.1, Aggregate signature is a kind of signature aggregation of key generated by each party using Schnorr Signature (a digital signature scheme, known for its simplicity and efficiency, and its security is based on the intractability of some discrete logarithm problems. Next, we will talk about Schnorr Signature). It can merge the public key and signature of each participant in a multi signature transaction into one public key and signature It is invisible, and the information before merging cannot be deduced from the public key and signature after merging, and only one verification is needed during verification. At present, Mimblewimble has used Schnorr signature algorithm to implement signature aggregation. It is impossible to distinguish whether the transaction is an ordinary transaction or a multi signature transaction, and the public key and signature of the users participating in the transaction will not be exposed.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato, Fay, Molloy and Frosty with Frosty’s additional teaching. One of ordinary skills in the art would have been motivated to enhance the system’s efficiency, security and traceability while preserving the ability to create, exchange and verify aggregate signatures in an atomic swap.
Regarding claim 7, the combination of Brogliato, Fay, Molloy and Frosty further disclose:
the asset swapping method of claim 1 terminates the asset swapping method before any transaction is broadcast if the verification of the aggregate signature is negative. (Brogliato ¶0096, The method can optionally include verifying if the signature on a partial transaction is valid and/or if the aggregated transaction is valid. The execution system and/or any other suitable system can receive the bitmask from a user and a signed partial transaction. The bitmask-indicated inputs and outputs can be verified as indeed relevant to the user to ensure the user and/or wallet are not signing on assets of others. If the test fails, the signature is invalid. If verified, the hash of the transaction with the bitmask appended to the header can be computed and compared against the signature provided by the user. If matched, the signature on the partial transaction can be deemed valid. Any other suitable verification strategies can be executed as well. The aggregated transaction can also be verified as valid if the execution system and/or any other suitable system can sign the aggregated transaction combining the partial signatures confirming that the signatures are valid for each of the partial transactions merged.)
Furthermore, in regards to the method claim, the claimed limitation “the asset swapping method of claim 1 terminates the asset swapping method before any transaction is broadcast if the verification of the aggregate signature is negative” is a conditional that does not move to distinguish over prior art as it is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Regarding claim 10, the combination of Brogliato, Fay, Molloy and Frosty further disclose:
packing, by the blockchain node or the blockchain miner, an accepted transaction into a block and broadcasting the block to the blockchain network. (Brogliato ¶0128, The signed transactions (sTx) can optionally be received from the user accounts, wherein the validity of the signatures are validated, optionally aggregated into a unitary transaction (e.g., a Hathor transaction, wherein the signed transactions form different components of a Hathor transaction's inputs; a Hathor atomic swap; etc.), and sent the signed transactions to the blockchain (e.g., the Hathor blockchain) and/or the respective assets' blockchains (e.g., for the spent assets). Alternatively, the users (e.g., their wallets) can send the signed transaction to the respective blockchains.)
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Brogliato, Fay, Molloy and Frosty as applied to claim 1 above, and further in view of Boneh (Aggregate and Verifiably Encrypted Signatures from Bilinear Maps. May,2023 <https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf >).
Regarding claim 4, the combination of Brogliato, Fay, Molloy and Frosty do not disclose, however Boneh teaches:
the aggregate signature is generated using the signature aggregate function to secure against forgery (Boneh P.1 abstract, Aggregate signatures are useful for reducing the size of certificate chains (by aggregating all signatures in the chain) and for reducing message size in secure routing protocols such as SBGP. We also show that aggregate signatures give rise to verifiably encrypted signatures. Such signatures enable the verifier to test that a given ciphertext C is the encryption of a signature on a given message M. Verifiably encrypted signatures are used in contract-signing protocols. Boneh P.12 Sec 4.3 We motivate our construction for verifiably encrypted signatures by considering aggregate signatures as a launching point. An aggregate signature scheme can give rise to a verifiably encrypted signature scheme if it is difficult to extract individual signatures from an aggregate, but easy to forge existentially under the adjudicator’s key. Consider the following: 1. Alice wishes to create a verifiably encrypted signature, which Bob will verify; Carol is the adjudicator. Alice and Carol’s keys are both generated under the underlying signature scheme’s key-generation algorithm. 2. Alice creates a signature σ on M under her public key. She forges a signature σ 0 on some random message M0 under Carol’s public key. She then combines σ and σ 0 , obtaining an aggregate ω. The verifiably encrypted signature is the pair (ω, M0 ). 3. Bob validates Alice’s verifiably encrypted signature (ω, M0 ) on M by checking that ω is a valid aggregate signature by Alice on M and by Carol on M0 . 4. Carol adjudicates, given a verifiably encrypted signature (ω, M0 ) on M by Alice, by computing a signature σ 0 on M0 under her key, and removing σ 0 from the aggregate; what remains is Alice’s ordinary signature σ. )
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato, Fay, Molloy and Frosty with Boneh’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to allow for individual signature extraction.
Regarding claim 5, the combination of Brogliato, Fay, Molloy, Frosty and Boneh further disclose:
the reversible signature aggregate function is constructed with a BLS signature scheme given that public keys are authenticated. (Boneh P.1 abstract, We construct an efficient aggregate signature from a recent short signature scheme based on bilinear maps due to Boneh, Lynn, and Shacham. Boneh P.2 ¶2, We construct an aggregate signature scheme based on a recent short signature due to Boneh, Lynn, and Shacham (BLS) [6].)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modified the combination of Brogliato, Fay, Molloy, Frosty and Boneh with Boneh’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to enable extraction of individual signatures while maintaining security guarantees, ensuring that extracted signatures could be securely attributed to its respective participant.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,555,110 in view of Brogliato (US 2024/0202703 A1).
Reference Application (12,555,110)
Instant application (18/537,839)
Claim 1
Claim 1
A fault-tolerant asset transfer method, comprising:
A method for asset swapping between blockchains, comprising:
parties negotiate and agree on a transaction content; wherein the transaction content includes a hash type field having an indicator bit set to a predetermined value to signal that a transaction requires payee confirmation;
negotiating, by a first participant and a second participant, to determine content of asset swapping transactions, wherein the transaction content comprises
generating signatures on the transaction content by the parties;
producing, by each participant, an individual signature on transaction content;
exchanging the signatures verifying the signatures;
exchanging, between the first participant and the second participant, the aggregate signatures,
constructing a transaction by either party;
constructing, by the second participant, a first blockchain transaction comprising the transaction content and both the sender's signature and recipient's conformation signature; constructing, by the first participant, a second blockchain transaction comprising the transaction content and both the sender's signature and the recipient's confirmation signature
broadcasting the constructed transaction to a blockchain network;
broadcasting, by the second participant, the first blockchain transaction to a blockchain network; broadcasting, by the first participant, the second blockchain transaction to a blockchain network;
validating the transaction by blockchain nodes or miners, wherein the validating comprises:
checking the indicator bit of the hash type field; and responsive to an indicator bit being set to the predetermined value, preforming a mandatory second verification of the payee's signature after successfully verifying the payer's signature, wherein the transaction is packed into a block only if both verifications are successful.
validating, by a blockchain node or a blockchain miner, the broadcast transactions, wherein validating comprises: (1) checking a format of the transaction according to a blockchain specification; (ii) verifying a signature from a transaction payer; (iii) if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature; and (iv)
The main difference in the claims is that while ‘110 discloses much of the subject matter in the instant claim, ‘110 claim does not particularly disclose “creating, by each participant, an aggregate signature from the individual signatures using a reversible signature aggregation function, wherein the aggregate signature is configured to allow recovery and verification of both a sender’s signature and a recipient’s confirmation;”, “wherein the transaction content comprises a locking script of a referenced previous transaction, transaction amounts”, “in response to a negative verification result, terminating the asset swapping method” and “(iv) in response to a negative verification result for the signature from the transaction payer or the signature from the transaction payee, rejecting the transaction.;”. However, Brogliato teaches “aggregating the signed transactions received from each user.” (¶0099) as well as “verifying if the signature on a partial transaction is valid and/or if the aggregated transaction is valid… If the test fails, the signature is invalid” (¶0096). Hence, it would have been obvious to one of ordinary skill in the art prior to the effective filing of instant claim to combine the teachings of signature aggregation and transaction rejection based on the signature verification teaching by Brogliato to the instant claimed invention for the purpose of generating a single compact signature which provides the benefit of reducing storage and reducing the computational complexity of verifying multiple individual signatures.
Further, in regards to the limitations “wherein the transaction content comprises a locking script of a referenced previous transaction, transaction amounts” and “wherein the constructed transaction is a multi-input transaction comprising a first input from a payer corresponding to a parent payment transaction and a second input from the payee for confirmation, the second input corresponding to a null transaction identity;” only describe characteristics of the transaction content and the constructed transaction which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. Similarly, “wherein the aggregate signature is configured to allow recovery and verification of both a sender’s signature and a recipient’s confirmation;” is considered intended use and therefore does not move to distinguish over prior art.
Furthermore, in regards to the limitations “in response to a negative verification result, terminating the asset swapping method” and “(iii) if the flag indicates that a recipient's signature is required, verifying a signature from a transaction payee as a conformation signature; and (iv) in response to a negative verification result for the signature from the transaction payer or the signature from the transaction payee, rejecting the transaction.;” are conditional limitations which means that the claim limitations are only required when the stated conditions are met.
Response to Arguments
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 (a) in the previous non-final action dated 09/03/2025 are withdrawn in light of the claim amendments.
Claim rejections 35 U.S.C. § 112 (b) regarding claims 7-11 in the previous non-final action dated 09/03/2025 are withdrawn in light of the claim amendments. Rejection regarding claims 1 and 4 are maintained.
Claim Rejections – 35 U.S.C. § 101
On pages 8-16 of the applicant’s arguments, the applicant presents several assertions regarding the claim rejections 101 found in the previous office action.
First, the applicant performs step 2A prong 1 analysis on the claim and asserts that the amended claim “is not directed to a commercial agreement in the abstract” because “it recites a particular cryptographic transaction protocol that operates within, and is enforced by, blockchain consensus machinery.” The applicant further present additional assertions including that “each steps in the claim impose a specific technical operation on computing devices and network node”, “the steps cannot be performed as a mental process, they are implemented by computers executing cryptographic primitives and by distributed nodes applying protocol rules to update on-chain data structures”, “the claims are directed to a specific technical solution” and the claim “integrates any abstract idea into a practical application”. The examiner finds these assertions not persuasive and respectfully disagrees. The applicant is attempting to conflate the Step 2A, 1st prong test, with Step 2A, 2nd prong test. As per MPEP 2106.04(a), in step 2A prong one to determine whether a claim recites an abstract idea, the specific limitations in the claim under examination must be identified and analyzed to determine whether they fall within at least one of the recognize groupings of abstract ideas. If one of the limitations in the examined claim falls within one of the groups, it is reasonable to conclude that the claims recite an abstract idea, and the examination continues to step 2A prong two. As shown in the 101 section above the claim recites a process of negotiating terms for a transaction, signing the contract/transaction, aggregating signatures by each participant, exchanging the aggregated signatures among the participants, collecting and verifying the signatures and recording the transaction. Therefore, the examiner maintains that the claim remains directed to an abstract idea, specifically directed toward certain methods of organizing human activity (i.e., commercial or legal interaction) because it focuses on negotiating and exchanging assets between parties which is a core activity in commerce.
Then, the applicant continues with step 2A prong 2 analysis and asserts that “the claim integrates any putative exception into a concrete, technological application” because it recites “specific cryptographic operations, generation of individual digital signatures, aggregation, exchange, and verification, that cannot be performed in the human mind and must be executed by computing devices” and “also reflects a technical improvement to blockchain transaction security and reliability”. The examiner finds these assertions not persuasive and respectfully disagrees. The claim merely implements commercial or legal interactions as described above. A method for negotiating and exchanging assets between parties does not provide any specific improvement to the functioning of the computer or technology. While the use of aggregated signatures and a flagging mechanism for recipient confirmation may appear technical, they are merely applying the abstract idea in the blockchain environment. Further, applying the abstract idea does not improve upon the blockchain nor does it improve upon the computer technology. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fails to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework. Further, in regard to the assertion that the operations “cannot be performed in the human mind and must be executed by computing devices”, under 101 analysis the focus is not on whether the user can feasibly perform the functions or not, but on whether a claim as a whole is directed towards an abstract idea and whether it recites a technological improvement or solution.
Finally, the applicant performs step 2B and asserts that the amended claim “recites significantly more” and the claim elements “considered as an ordered combination, form a non-routine, non-generic architecture for escrow-free atomic swap”. The examiner also finds these assertions not persuasive and respectfully disagrees. As previously mentioned, the claim invention pertains to a method for negotiating and exchanging assets between parties which is an implementation of commercial or legal interactions. Further, the additional elements of a blockchain, blockchain network, blockchain miner and blockchain nodes, as recited in the claim, are merely additional elements representing conventional computer technologies employed to apply the underlying abstract idea. To meet the requirements for patent eligibility, the claim must do more than simply apply this abstract idea using generic technological tools. Therefore, the recited claim does not include any additional features that rise to the level of an inventive concept under step 2B of the subject matter eligibility framework. Further, in regard to the assertion that “the claim elements “considered as an ordered combination, form a non-routine, non-generic architecture for escrow-free atomic swap”.”, the rejection under 35 U.S.C. 101 was not based on the determination that the recited steps are routine or conventional. Rather, the claims are directed to an abstract idea and do not recite additional elements that integrate the abstract idea into a practical application. Therefore, whether the claimed steps are routine or unconventional does not overcome the rejection. Even assuming, arguendo, that the steps are not routine or conventional, the claim still recites the abstract idea implemented using generic computer components and do not amount to significantly more than the underlining abstract idea.
Claim Rejections – 35 U.S.C. § 103
On pages 16-28 of the applicant’s arguments, the applicant presents several assertions in regard to the claim rejections 103 found in the previous office action.
First, the applicant assets that Brogliato do not teach “the transaction level flagging mechanism for recipient confirmation and corresponding validator logic that conditions acceptance of the presence and validity of a recipient signature”. The applicant further asserts that neither one of the secondary references teaches or suggests the limitation (i.e. Molloy, Davis or Nguyen). The examiner finds this assertion not persuasive and respectfully disagrees. Molloy explicitly teaches locking scripts that define one or more conditions that must be satisfied by an unlocking script as well as multi signature conditions (i.e. 1 of 2 or 1 of n signatures required) (Molloy ¶0022, ¶0107, ¶0129 ¶0132). Therefore, Molloy teaches the concept of requiring one or more specific signatures as a transaction validation condition.
Second, the applicant asserts that the office action does not provide “articulated reason to combine the references with a reasonable expectation of success” and that “to reach the claimed invention, one would have to discard core mechanisms that the references rely on”. The examiner finds this assertion not persuasive and respectfully disagrees. The combination of prior art does not require abandoning the references’ core mechanisms but rather applying known cryptographic authorization, signature aggregation and transaction validation techniques to a known atomic swap process. Further the applicant asserts that such “re-architecture is not suggested by the references”. The examiner finds this assertion not persuasive and respectfully disagrees. The fact that not a single reference explicitly recites the precise combination claimed does not overcome the 103 rejection.
Third, applicant asserts that “modifying Brogliato to require a recipient confirmation signature as a gating condition would contradict Brogliato’s architecture” and instead of optimizing Brogliato’s invention it would frustrate its objectives. The examiner finds these assertions not persuasive and respectfully disagrees. The combination of prior art does not replace Brogliato’s underlining atomic swap process but instead adds signature aggregation and validation conditions which improves the system’s security and performance (Frosty). Further, the applicant asserts that “requiring the recipient to come online and co-sign at execution time adds a synchronous round- trip, negates the offline-settlement feature, increases latency, and erodes the privacy and security benefits Brogliato achieves by minimizing real-time key use”. The examiner also finds this assertion not persuasive and respectfully disagrees. Requiring a recipient’s confirmation signature does not require the users to be continuously online, negates the offline-settlement feature, increases latency, and erodes the privacy and security benefits as asserted by the applicant. This requirement merely adds an additional authorization requirement that is conditional to the existence of the recipient’s confirmation signature in the transaction.
Fourth, the applicant asserts that the combination of references would change the principal of operation of Brogliato. The applicant further asserts that “imposing counterparty co-signature at execution would force both parties online in real time, eliminating Brogliato's offline-
tolerant settlement model, increasing latency, and expanding key-exposure windows, outcomes
directly contrary to Brogliato's stated design goals.” and “substituting a reversible aggregate-signature scheme of the type discussed in Nguyen or Boneh would upend Brogliato's validation path, which relies on straightforward, widely supported primitives.” The examiner finds these assertions not persuasive and respectfully disagrees. As previously mentioned, the proposed combination does not change Brogliato’s underlining method of non-custodial on-chain atomic swap. Adding a recipient’s confirmation signature merely modifies the cryptographic validation process by adding an additional condition for verification. Similarly, replacing the signature in Brogliato with a reversible aggregated signature would only change the way the signatures are generated and validated but would not change the atomic swap process taught by Brogliato.
Finally, the applicant asserts that “the inventor identified a problem that other did not” and compares it with In Re Omeprazole. The examiner finds these assertions not persuasive and respectfully disagrees. Identifying a previously unrecognized problem does not establish non-obviousness. The relevant question is whether the claimed solution would have been obvious to one of ordinary skill in view of the prior art. Here, the claimed solution to the recognized problem employs previously known cryptographic techniques taught in the prior art to strengthen the atomic swap method and prevent erroneous or fraudulent execution.
Non-Statutory Double Patenting
Applicant submits that a terminal disclaimer will be filed once there is no outstanding rejection except for the non-statutory double patenting.
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.
The following prior art made of record and not relied upon is considered pertinent to applicant's
Disclosure:
US 20220138748 A1 to Millar et al. discloses: Method for settling an asset transaction in which a first asset is exchanged for a second asset, which first asset is registered as an association with a specific first blockchain asset (A) on a blockchain-based ledger (L), which second asset is either a second blockchain asset (A) on the ledger (L) in question or an asset registered as an association with a specific second blockchain asset (A) on the said ledger (L). The method comprises the following steps: a) a selling first party (U) providing and signing a first blockchain transaction part concerning the first blockchain asset (A) in question, and a buying second party (U) providing and signing a second blockchain transaction part concerning the second blockchain asset (A) in question; b) a central server (100) electronically receiving the signed first and second blockchain transaction parts; c) the central server (100) combining the first and second blockchain transaction parts in a single combined blockchain transaction; and d) the central server (100) publishing the combined blockchain transaction on the blockchain ledger (L). The invention also relates to a computer server interacting with a client computer, and to two interacting computer software products.
US 20210398116 A1 to Fang discloses: Disclosed are computer-implemented methods, non-transitory computer-readable media, and systems for managing transactions in multiple blockchain networks. One computer-implemented method includes identifying a first transaction in a first blockchain network that is a first Hash Time Locked Contract (HTLC) transaction in the first blockchain network, identifying a second transaction in a second blockchain network that is a second HTLC transaction in the second blockchain network different from the first blockchain network, determining that a first transaction commit time of the first HTLC transaction is earlier than a second transaction commit time of the second HTLC transaction and a first secret hash of the first HTLC transaction has a same value as a second secret hash of the second HTLC transaction, and in response, determining that the first HTLC transaction and the second HTLC transaction are associated with each other and related to a cross-chain transaction.
US 20210224797 A1 to Berengoltz discloses: A system and method for securing crypto-asset transactions. The method includes sharding a wallet private key such that each shard of the wallet private key is distributed to a different secure module; generating signatures by each of the different secure modules based on a respective shard of the sharded wallet private key and obtained trading platform credentials; and verifying the crypto-asset transaction when a predetermined threshold of the generated signatures are determined to match each other.
US 10652019 B1 to Nicolas discloses: Disclosed herein are system, method, and computer program product embodiments for performing transactions or atomic swaps using zero-knowledge proofs (“ZKPs”). A first system may propose a transaction between with a second system. The first system may generate a first ZKP indicating that the first system has possession of an asset desired by the second system and that the first system is committing the asset to the transaction. The second system may also similarly generate a second ZKP. These ZKPs may be encrypted and exchanged. The second system may receive an encrypted version of the first ZKP, perform a decryption using a key specific to the second system, and verify the ZKP. When the parties verify the ZKPs, this confirms that each party has committed the requested asset and that the transaction may proceed. The transaction may be committed to a blockchain.
US 20220300916 A1 to Fytraki discloses: A system is provided for swapping assets owned by different parties in different networks. The system provides techniques that allow a first party holding a first asset in a first network and a second party holding a second asset in a second network to swap their assets. The result of the swap will be that the first party owns the second asset in the second network and that second party owns the first asset in the first network. The system employs locks and transfer condition and if needed, a resolution strategy to ensure that either the swap occurs or that the parties retain their own assets.
US 20170366358 A1 to Lyubashevsky discloses: The method involves storing a user identification (ID) for a user computer and a user signing key which comprises a signature on the user ID under a secret key of a selectively-secure signature scheme. A cryptographic proof comprising a zero-knowledge proof of knowledge of the user signing key and including a message in the proof of knowledge are generated (35, 36), The message and a group signature comprising a proof are sent (37) to a verifier computer. The user ID is encrypted using a predetermined encryption scheme to produce a ciphertext.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights