Patent Application 18499046 - SYSTEMS AND METHODS FOR TOKENIZING ASSETS VIA

Title: SYSTEMS AND METHODS FOR TOKENIZING ASSETS VIA BLOCKCHAIN-TO-BLOCKCHAIN BRIDGE USING UNDERLYING ASSETS HELD AT A TRIPARTY AGENT OR CUSTODIAN
Application Information

Invention Title: SYSTEMS AND METHODS FOR TOKENIZING ASSETS VIA BLOCKCHAIN-TO-BLOCKCHAIN BRIDGE USING UNDERLYING ASSETS HELD AT A TRIPARTY AGENT OR CUSTODIAN
Application Number: 18499046
Submission Date: 2025-05-13T00:00:00.000Z
Effective Filing Date: 2023-10-31T00:00:00.000Z
Filing Date: 2023-10-31T00:00:00.000Z
National Class: 713
National Sub-Class: 168000
Examiner Employee Number: 80349
Art Unit: 2498
Tech Center: 2400
Rejection Summary

102 Rejections: 0
103 Rejections: 1
Cited Patents

The following patents were cited in the rejection:
US 0230240🔗
US 0172026🔗
Office Action Text



    DETAILED ACTION
1. 	This office action is in response to application 18/499,046 filed on 10/31/2023. Claims 1-18 are submitted for examination. Claims 1, 7 and 13 are independent. 
Notice of Pre-AIA  or AIA  Status
2.	The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
					Priority

	3.	This application filed on 10/31/2023 claims foreign priority to 202211062711, filed 11/02/2022. However, the certified copy of the foreign priority hasn’t yet been received. 
				Information Disclosure Statement
4.	The information disclosure statements (IDS) submitted on 02/16/2024 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Drawings
5.	The drawings filed on October 31, 2023 are accepted. 
Specification
6.	The specification filed on October 31, 2023 is also accepted.

Claim Rejections - 35 USC § 101
7.	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.


8.	Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. 
	Independent claims 1, 7 and 13
Independent claims 1, 7 and 13 are directed to a method/system/non-transitory computer readable medium which are all statutory category under 35 U.S.C. 101.
First prong of Step 2A; 
The claims are directed to the abstract idea of tokenizing and transferring assets between distributed ledgers using a blockchain bridge. The method/system/medium involves the steps such as minting tokens, locking assets, verifying token states and executing a public burn. These are routine financial operations and mechanisms of asset transfer, which fall under the category of “fundamental economic practices” or “methods of organizing human activity” recognized by the court as abstract ideas.
Second Prong of Step 2A, the claims do not recite any additional elements that integrate the abstract idea into a practical application. The steps are performed using conventional components, including client programs and distributed ledger systems and do not provide any improvement to the functioning of computers or blockchain networks themselves. As to independent claim 7, the functions of the system components are limited to performing conventional blockchain operations using standard computing technology. There is no indication that the claimed invention improves the functionality of the computer or blockchain systems involved.
Step 2B: Inventive Concept?
The claims do not recite an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter. The method/system and medium recited in independent claims 1, 7 and 13 employ generic computer functions and known blockchain features such as the use private keys, minting operations and verifications mechanisms. These do not amount to significantly more than the underlying abstract idea. As to independent claim 7, client computer, tokenization agent, custody agent and distributed ledgers operates in a routine and conventional manners. The claim limitations represent generic implementation of financial tokenization logic without any technical innovation or unconventional use of technology. 
Accordingly independent claims 1, 7 and 13 are rejected under 35 U.S.C. 101 as being directed to a judicial exception without reciting significantly more. 
Dependent claims 2-6, 8-12 and 14-18
Dependent claims 2-6, 8-12 and 14-18 include further limitations such as signature verification using private keys and operations on a second distributed ledger. However, these elements are conventional and well-understood in the fields of distributed ledger technology and do not add an inventive concept that would render the claims patent-eligible under the 35 U.S.C. 101. Furthermore, the added elements such as cryptographic signing of instructions using private keys, redemption requests and client-side token operations. These additions represent standard security and transaction features well-known in the blockchain and distributed ledger domain and do not significantly more than the underlying abstract idea. 
Accordingly, the dependent claims 2-6, 8-12 and 14-18 are rejected under 35 U.S.C. 101 as being directed to a judicial exception without reciting significantly more. 

Claim Rejections - 35 USC § 103
9.	In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.  
10.	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.

11.	The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.

	Examiner’s note: text in bold corresponds to the claimed limitations; text in italics underlined or not underlined correspond to the cited prior art reference (i.e., verbatim, and/or examiner’s clarification. Meaning, text after a limitation in brackets [ ] corresponds to examiner’s mapping (including further explanation and/or comments) and/or prior art reference citations. Furthermore text in brackets [ ] points out explanation how the claim limitation is taught or explicitly taught by the reference being cited for that particular limitation or part of the limitation]
12.	Claims 1-18 are rejected under AIA  35 U.S.C. 103 as being unpatentable over Peter Joseph Vessenes (herein after referred as Vessenes) (US Publication No. 2019/0172026) (Jun 6, 2019) in view of Lukasz Jakub Sliwka (hereinafter referred as Sliwka) (US Publication No. 2022/0230240 A1) (July 21, 2022) 
	The following is referring to independent claims 1, 7 and 13

As per independent claim 1, Vessenes discloses a method for tokenizing assets via a blockchain-to-blockchain bridge using underlying assets held at a triparty agent or custodian, comprising: receiving, at a tokenization agent computer program, a first instruction from a client computer program to mint first tokens for a client asset; [Paragraph 0046, when a user wishes to initiate a transaction, the Deluge wallet 102 creates BTC and Ethereum (or ERC20 compliant) address pairs that correspond to a same public key, and stores it. If a user wishes to import tokens (eg. convert and/or synchronize BTC and DBTC), the user may perform a BTC transfer 110 from the Bitcoin wallet 104 to the BTC repository 102 a, and initiate an import transaction. In embodiments, the import transaction may be initiated upon the BTC transfer 110. In embodiments, the Deluge wallet will newly mint DBTC and initiate a DBTC transfer 112 to the DBTC repository 102 based upon the BTC within the BTC repository 102 a. Prior to newly minting the DBTC, an associated number of BTC will be transferred 114 into a locked BTC 116 state within a multisig address. Once the newly minted DBTC is in the DBTC repository 102, the user may perform a DBTC transfer 118 to transfer the ERC20 compliant tokens to the user's Ethereum wallet 106 to allow transactions to take place on the Ethereum blockchain. In embodiments, the amount of DBTC minted may be equivalent to the original amount of BTC transferred by the user. In other embodiments, transaction fees, for example fees incurred during the validation process as described above, may result in a reduced amount of DBTC minted]; encumbering, by the tokenization agent computer program, the client asset on a custody ledger [See paragraph 0046]; 
creating, by the tokenization agent computer program, a balance of the first tokens for the client asset on a first distributed ledger [Paragraph 0046]; 
receiving, by the tokenization agent computer program, a second instruction to lock and mint the first tokens to a second distributed ledger as second tokens [Paragraph 0046]; 
receiving, by the tokenization agent computer program, verification from a custodian or triparty agent that the first tokens are locked on a lock ledger for the custodian or triparty agent [See paragraph 0047 and 0124, prior to the DBTC transfer 118, a number of verifications may occur. For example, the user's BTC transfer 110 to the Deluge wallet 102 and the user's ownership of the transferred BTC are to be verified, as well as the locked BTC 116 associated within the multisig address. In addition, an Ethereum address generated during minting must be verified as produced by the public key that matches a pay to public key hash (P2PKH) address that initiated the multisig transfer. Paragraph 0124, At 520, the Deluge wallet 504 initiates a verify transaction (verifyTx) with a smart contract 506, which ultimately triggers DBTC minting at 522 if verification is successful. The network uses BTC Relay smart contract to verify on the Ethereum blockchain that the given transaction in fact took place on the bitcoin blockchain. Prior to minting DBTC for use on the Ethereum blockchain, a smart contract verifies both the user's transfer of BTC to the Deluge Wallet and that user's ownership of the same BTC once it has been locked into the multisig 508 address. In embodiments, to verify that the user transferred the BTC, a P2PKH bitcoin address may be used. The smart contract checks that at least one of the transaction inputs to P2SH is originated from the user's transaction output, thus providing the check to the condition that the user owns the bitcoin that was locked. A BTC Relay is used to verify both that the user's BTC contributions are confirmed to the created BTC address and that the user's Bitcoins are locked to the P2SH. If verification is successful, a token smart contract 506 mints the DBTCs to user's Ethereum address in the Deluge wallet 504.]]; 
instructing, by the tokenization agent computer program, a blockchain bridge computer program to mint second tokens to a client address on the second distributed ledger [Paragraph 0046];
receiving, by the tokenization agent computer program, a third instruction to return the second tokens to the first distributed ledger [Paragraph 0053, if the user wishes to use the cross-blockchain secure transactions network to transition from DBTC used on the Ethereum blockchain to BTC tokens on the Bitcoin block chain, the user may perform a transfer 120 from the Ethereum wallet 106 to the DBTC repository 102 b. For example, the user may wish to synchronize tokens between and/or return tokens from the Ethereum ERC20 ecosystem and the Bitcoin blockchain, and convert DBTC back into an equivalent amount of BTC by initiating a cross-blockchain secure transaction export transaction];
executing, by the tokenization agent computer program, a public burn [Paragraph 0054-0055, the export transaction may create a BTC and Ethereum address pair that corresponds to the same public key, and send DBTC to the repository 102 b. A smart contract 108 may be initiated via the Deluge wallet 102 to signal a burn (destruction) of the DBTC tokens and to record the burn event on an Ethereum log. In embodiments, this may signal the burn event 122 to a plurality of validators 124 and Paragraph 0055; the validators 124 may listen for burn events and trigger the export process upon observing the DBTC burn. When the validators 124 observe the DBTC burn event, for example on the Ethereum log, and upon execution of the burn, each validator creates a bitcoin transaction with the appropriate amount of BTC owed to the user consisting of the unspent output from bitcoin transactions (UTXO) that sent BTC 116 to the multisig address. The validators 124 then send their signature 126 to a smart contract.]; and 
instructing, by the tokenization agent computer program, the custodian or triparty agent to unlock the first tokens and move the first tokens to the first distributed ledger [Paragraph 0056-0057, Paragraph 0056, n embodiments, throughout this process, a majority of validators are required to sign the transaction before any BTC can be released to the user's Deluge wallet 102, in order to prevent mishandling of funds, as described in the Validators and Consensus section below. Paragraph 0057, Finally, the Deluge wallet 102 awaits the log events on the blockchain to collect the signatures, construct the Bitcoin transaction, and submits it to the bitcoin blockchain. The user then receives the corresponding BTC amount 128 into the Deluge wallet 102 (less any transaction and mining fees incurred during the validation process described above), and the export process is complete. The user may then transfer BTC 130 to the user's Bitcoin wallet 104. In this way, in embodiments, behavior of BTC and DBTC may be synchronized between the bitcoin and Ethereum blockchains, such that BTC that is transferred to the Ethereum blockchain and results in minting of DBTC in the import process may not be used until such time as a corresponding amount of DBTC is burned in the export process, at which time the BTC may then be released to the party who burned the DBTC].  

	Vessenes substantially discloses all the limitation recited in the claim but doesn’t explicitly disclose the following underlined claim limitation:
“executing, by the tokenization agent computer program, a public burn of the second tokens on the second distributed ledger”;
However, Sliwka at least paragraph 0127 teaches the above underlined claim limitation:
executing, by the tokenization agent computer program, a public burn of the second tokens on the second distributed ledger” [Paragraph 0127, the ledger update system 304 is further configured to “burn” tokens. Burning tokens may refer to the mechanism by which a token is deemed no longer redeemable. A token may be burned when the token expires or when the token is redeemed. In embodiments, the ledger update system 304 may update the ownership of the token to indicate that the token is not currently owned (e.g., owner=NULL) and/or may update the token state to indicate that the token is no longer valid. In some of these embodiments, the ledger update system 304 may generate a block indicating that the token is not currently owned or that the state of the token is not valid. The ledger update system 304 may then write generated block(s) to the distributed ledger 310. For example, the ledger update system 304 may amend the block(s) to the distributed ledger 310 and/or may broadcast the block(s) to the computing nodes 160 that store the distributed ledger 310. In some embodiments, the distributed ledger 310 is sharded. In these embodiments, the ledger update system 304 may designate a side chain 314 (e.g., an item classification) to which the token corresponds. In these embodiments, the generated blocks are amended to the designated side chain 314 to indicate the burned token. See also paragraph 0230; 0317 and claim 3];


Vessenes and Sliwka are analogous arts and are in the same field of endeavor as they both are directed to distributed ledgers such as blockchain ecosystem. 
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention, to implement in the system of Vessenes a mechanism to combine feature such as “executing, by the tokenization agent computer program, a public burn of the second tokens on the second distributed ledger” as taught by Sliwka because this would enhance the level of security by implementing a secure, token mirroring system across two distributed ledgders with lock-and burn redemption workflow, thereby arriving at claimed invention. [See Sliwak at least paragraph 0127 and paragraph 0230] 

As per independent claim 7, independent claim 7 recites similar limitation and has the same scope as that of the above independent claim 1 and is likewise rejected for the same reason as  independent claim 1.

As per independent claim 13, independent claim 13 recites similar limitation and has the same scope as that of the above independent claim 1 and is likewise rejected for the same reason as  independent claim 1.

The following is referring to dependent claims 2-6; 8-12 and 17-18

As per dependent claim 2, the combination of Vessenes and Sliwak discloses the method/system/device as applied to claims above. Furthermore Vessenes discloses the method/system/device further comprising: receiving, by the tokenization agent computer program, a request to redeem the first tokens; and executing, by the tokenization agent computer program, a public burn and redeem of the first tokens [Paragraph 0054-0055 and paragraph 0056, the export transaction may create a BTC and Ethereum address pair that corresponds to the same public key, and send DBTC to the repository 102 b. A smart contract 108 may be initiated via the Deluge wallet 102 to signal a burn (destruction) of the DBTC tokens and to record the burn event on an Ethereum log. In embodiments, this may signal the burn event 122 to a plurality of validators 124 and Paragraph 0055; the validators 124 may listen for burn events and trigger the export process upon observing the DBTC burn. When the validators 124 observe the DBTC burn event, for example on the Ethereum log, and upon execution of the burn, each validator creates a bitcoin transaction with the appropriate amount of BTC owed to the user consisting of the unspent output from bitcoin transactions (UTXO) that sent BTC 116 to the multisig address. The validators 124 then send their signature 126 to a smart contract and see also See Sliwak at least paragraph 0127 and paragraph 0230] 

As per dependent claim 8, dependent claim 8 recites similar limitation and has the same scope as that of the above dependent claim 2 and is likewise rejected for the same reason as  dependent claim 2.

As per dependent claim 14, dependent claim 14 recites similar limitation and has the same scope as that of the above dependent claim 2 and is likewise rejected for the same reason as  dependent claim 2.

As per dependent claim 3, the combination of Vessenes and Sliwak discloses the method/system/device as applied to claims above. Furthermore Vessenes discloses the method/system/device, wherein the first instruction, the second instruction, and/or the third instruction are signed with a first private client key [paragraph 0034 and paragraph 0029 and paragraph 0090, During export, the validator's independently construct and sign (with their respective private keys) the raw bitcoin transaction and post the signature to the smart contract or Ethereum logs. When enough M-of-N signatures from the validator's are posted, the smart contract generates an Ethereum event (e.g., log message) notifying the wallet. The user, via the wallet, will retrieve the validator signatures, transaction metadata, and a “Redeemscript” from the smart contract. “Redeemscript” is a list of validator public keys required to verify that the transaction was signed by M-of-N validators.]

As per dependent claim 9, dependent claim 9 recites similar limitation and has the same scope as that of the above dependent claim 3 and is likewise rejected for the same reason as  dependent claim 3.

As per dependent claim 15, dependent claim 15 recites similar limitation and has the same scope as that of the above dependent claim 3 and is likewise rejected for the same reason as  dependent claim 3.

As per dependent claim 4, the combination of Vessenes and Sliwak discloses the method/system/device as applied to claims above. Furthermore Vessenes discloses the method/system/device, wherein the balance of first tokens is created with a first tokenization agent private key [Paragraph 0029 and 0034 and paragraph 0090: Paragraph 0029; the cross-blockchain secure transaction network including a plurality of validators provides a 2-way pegging between BTC and DBTC. As discussed above, DBTC may be a ERC20 compatible token for the Ethereum network. Characteristics of the token transfer may include: (1) users are always in control—every transaction request is initiated by the user; (2) the user who submits the initial transaction request may be the only user who can receive the output of the transaction—transactions are only valid if the addresses correspond to the same private key claiming the swap; (3) validators never submit transactions, they independently construct the transaction and publish their signature to the Ethereum blockchain (however, user and the user's wallet may be responsible for submitting the claim request); and (4) Bitcoin protocol is used for the escrow of the funds to P2SH address, which requires a majority of the validator keys to unlock. Paragraph 0034, During importing (sending BTC for DBTC), user sends the user's Bitcoins to a P2SH address specified by a smart contract. The Bitcoins are then locked at this address until a future time when a user requests an export (sending DBTC for BTC). During export, the validator's independently construct and sign (with their respective private keys) the raw bitcoin transaction and post the signature to the smart contract or Ethereum logs. When enough M-of-N signatures from the validator's are posted, the smart contract generates an Ethereum event (e.g., log message) notifying the wallet. The user, via the wallet, will retrieve the validator signatures, transaction metadata, and a “Redeemscript” from the smart contract. “Redeemscript” is a list of validator public keys required to verify that the transaction was signed by M-of-N validators]

As per dependent claim 10, dependent claim 10 recites similar limitation and has the same scope as that of the above dependent claim 4 and is likewise rejected for the same reason as  dependent claim 4.

As per dependent claim 16, dependent claim 16 recites similar limitation and has the same scope as that of the above dependent claim 4 and is likewise rejected for the same reason as  dependent claim 4.

As per dependent claim 5, the combination of Vessenes and Sliwak discloses the method/system/device as applied to claims above. Furthermore Vessenes discloses the method/system/device, wherein the instruction to mint second tokens, the instruction to unlock, and/or the public burn and redeem are signed with a second tokenization agent private key [Paragraph 0138, Validator operation and duties. Validators provide the needed M-of-N keys required to unlock the multisig bitcoin transaction for exporting. For the signing process, individual validators are to: (1) maintain a list of UTXOs (unspent transaction outputs) to construct the spending transaction signature; (2) listen for an export transaction that includes a token burn event; and (3) Independently construct and sign a raw transaction and post their signature to the smart contract and see paragraph 0055, the validators 124 may listen for burn events and trigger the export process upon observing the DBTC burn. When the validators 124 observe the DBTC burn event, for example on the Ethereum log, and upon execution of the burn, each validator creates a bitcoin transaction with the appropriate amount of BTC owed to the user consisting of the unspent output from bitcoin transactions (UTXO) that sent BTC 116 to the multisig address. The validators 124 then send their signature 126 to a smart contract.]
As per dependent claim 11, dependent claim 11 recites similar limitation and has the same scope as that of the above dependent claim 5 and is likewise rejected for the same reason as  dependent claim 5.

As per dependent claim 17, dependent claim 17 recites similar limitation and has the same scope as that of the above dependent claim 5 and is likewise rejected for the same reason as  dependent claim 5.

As per dependent claim 6, the combination of Vessenes and Sliwak discloses the method/system/device as applied to claims above. Furthermore Sliwak discloses the method/system/device, wherein the client computer program performs actions with the second tokens on the second distributed ledger with a second client private key [Paragaph 0121, The token generation system 302 may generate the token identifier using any suitable technique. For example, the token generation system 302 may implement random number genesis, case genesis, simple genesis, and/or token bridge genesis to generate a value that identifies the token. In embodiments, the token generation system 302 may digitally sign the value using a private key/public key pair. The token generation system 302 may utilize a private key/public key pair associated with the platform 100 or the merchant to digitally sign the value that identifies the token. The token generation system 302 may implement any suitable digital signature algorithm to digitally sign the value that identifies the token, such as the Digital Signature Algorithm (DSA), developed by the National Institute of Standards and Technology].

As per dependent claim 12, dependent claim 12 recites similar limitation and has the same scope as that of the above dependent claim 6 and is likewise rejected for the same reason as  dependent claim 6.

As per dependent claim 18, dependent claim 18 recites similar limitation and has the same scope as that of the above dependent claim 6 and is likewise rejected for the same reason as  dependent claim 6.

Conclusion
13.	The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. 	US Publication No. 20220253842 A1 to James discloses a method, system and program product for modifying a supply of stable value digital asset tokens tied to a blockchain.
B.	US Patent No. 10929842B1 to Arvanaghi discloses a method, system and program product for depositing and withdrawing a stable value digital asset tied to a blockchain in exchange for fiat.
C.	US Publication No. 2022/0173893A1 to Basu discloses a method for processing NFTs on a blockchain platform. A request for processing an NFT is received on the blockchain platform, by a requestor. The NFT is accessed by chunks C (C1, C2, . . . , Cn) from at least two blobbers B (B1, B2, . . . , Bn). The NFT is reconstructed from the chunks C (C1, C2, . . . , Cn) to process the request. The supported requests include creating, viewing, purchasing, transferring ownership, setting permissions for reveal of data at a future date, adding, updating, deleting, moving, copying, and renaming data assets. The NFT may be transferred from one blockchain platform to a different blockchain platform, and may be initially used as a fundraising vehicle by the creator with no data asset initially and later uploaded to the blobbers.
D.  See the other cited prior arts. 
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMSON B LEMMA whose telephone number is 571-272-3806.  The examiner can normally be reached on M-F 8am-10pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Yin-Chen Shaw can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system.  Status information for published applications may be obtained from either Private PAIR or Public PAIR.  Status information for unpublished applications is available through Private PAIR only.  For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).

/SAMSON B LEMMA/Primary Examiner, Art Unit 2498