DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jul. 28, 2026, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicants’ submission filed on Jul. 28, 2026, has been entered.
Claim Status
The status of claims is as follows:
Claims 1, 3, 5–11, 13, 15–24 are pending and examined with Claims 1, 11, and 20 in independent form.
Claims 1, 3, 5, 11, 13, 20, and 21 are presently amended.
Claims 2, 4, 12, and 14 are presently cancelled.
Claims 22–24 are presently added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Jun. 30, 2023, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues the amended claims recite a technical solution to security problems caused by the immutability and irreversibility of blockchain transactions. Applicant’s Reply at 11–21. Applicant’s arguments directed to Step 2A, Prong Two (“practical application”) are persuasive for the reasons discussed below. Applicant’s Reply at 15–18; MPEP §§ 2106.04(d)(1), 2106.05(a). Because eligibility is resolved by applying the MPEP’s technological improvement analysis to the Specification and amended claims, Examiner need not rely on Applicant’s analogies to cited PTAB and Fed. Cir. decisions.
Examiner’s Statement of Eligibility Under 35 U.S.C. § 101
Independent Claims 1, 11, and 20 recite the abstract idea of conditionally managing and recovering a disputed transfer of financial value as reflected in the following limitations of representative Claim 1 [“Rep. Claim 1”]: “receiving a request to execute a transaction” that transfers “a quantity of a token … from a transmitter wallet to a receiver wallet”; “incrementing a running total of tokens in the receiver wallet that are in a recoverable state;” “determining, after a threshold amount of time … whether the transaction has been frozen”; and “transferring tokens from the chain of wallets to the transmitter wallet.” These limitations describe commercial and legal interactions involving conditional payment and recovery of disputed assets, as well as bookkeeping associated with those transactions. MPEP § 2106.04(a)(2)(II)(A), (B).
The Specification explains that “transaction security and trust in a blockchain system may be negatively impacted by the immutability of a blockchain system and the irreversibility of transactions executed on blockchain systems.” Spec. ¶ 16. It addresses this problem by using “wrapped tokens” existing in one of three states: “a recoverable state, a non-recoverable state, or a frozen state.” Spec. ¶ 17. “[A] wrapped token may be received at a wallet in a recoverable state and remain in a recoverable state until some threshold amount of time has elapsed. While the wrapped token is in a recoverable state, the wrapped token may be frozen (e.g., based on an indication, performed by a trusted source, that the wrapped token was involved in a fraudulent transaction subject to reversal).” Spec. ¶ 17. “[T]o restore the quantity of the token to the transmitter wallet, a chain of wallets including the receiver wallet is identified.” Spec. ¶ 49. These wallets may be identified “based on timestamps associated with a series of transactions such that a total amount of tokens frozen across the chain of wallets equals the quantity of the token. Tokens are transferred from the chain of wallets to the transmitter wallet.” Spec. ¶ 49.
The amended Independent Claims 1, 11, and 20 reflect that improvement in the following limitations of Rep. Claim 1:
creating a wrapped token by encapsulating a base token with a recoverability status indicator and a frozen status indicator; determining, after a threshold amount of time from a timestamp associated with the received request, whether the transaction has been frozen based on the frozen status indicator of each token; and based on determining that the transaction has been frozen: identifying a chain of wallets, including the receiver wallet, in which tokens associated with the transaction were transferred based on timestamps associated with a series of transactions such that a total amount of tokens frozen across the chain of wallets equals the quantity of the token; and transferring tokens from the chain of wallets to the transmitter wallet.
These limitations reflect the wrapped-token recovery technique described in the Specification. Spec. ¶¶ 17, 21, 49. These limitations recite a particular wrapped-token recovery process for blockchain transactions, rather than merely the result of reversing a transaction or applying a conventional chargeback to a blockchain.
MPEP §§ 2106.04(d)(1) and 2106.05(a) require the Examiner to: (1) determine whether the specification describes a technological improvement with sufficient detail that the improvement would be apparent to a person of ordinary skill; and (2) determine whether the claims include components or steps that provide the improvement. The claims need not recite the resulting technological benefit or incorporate features from the Specification that are not necessary to provide technological improvement. Here, Independent Claims 1, 11, and 20 satisfy this requirement by reciting using the language of Rep. Claim 1, “a recoverability status indicator and a frozen status indicator”; determining “after a threshold amount of time,” whether the transaction has been frozen; “identifying a chain of wallets” based on transaction timestamps; requiring that “a total amount of tokens frozen across the chain of wallets equals the quantity of the token”; and “transferring tokens from the chain of wallets to the transmitter wallet.” Considered as a whole and in combination, these limitations reflect the Specification’s particular solution for providing token recoverability despite blockchain transaction immutability. Spec. ¶¶ 17, 19, 49.
The Specification separately discloses a smart contract, governance voting, functional processing modules, and chronologically organized transaction lists in additional embodiments of the disclosed solution. Spec. ¶¶ 19, 26, 27, 29. For example, the transaction processor “can” invoke “a smart contract or other programmatic construct on blockchain 132,” identifying the smart contract as one possible implementation rather than the sole mechanism for transferring tokens. Spec. ¶ 29. Governance voting is described as “[i]n some aspects” indicating one possible method of authorizing a freeze. Spec. ¶ 27. The “token wrapper/unwrapper 112,” “token freezer 114,” and “transaction processor 116” are disclosed as components of an example transaction processing architecture and correspond to wrapped token creation, wrapped token freezing, and transaction processing functions already recited by Independent Claims. The “list of transactions” “may be organized chronologically” is an alternate way because the clams require a timestamp-based determination. Spec. ¶ 26. These additional features of the Specification are not required to implement the claimed technological solution because they do not provide the improvement.
Accordingly, even assuming the claims recite an abstract idea under Step 2A, Prong One, the claims as a whole and in combination integrate that idea into a practical application at Step 2A, Prong Two. The rejection of Claims 1–21 under § 101, as set forth in the Final Office Action mailed Apr. 28, 2026 [“Final Office Action”], is WITHDRAWN.
Declaration under § 1.130
Applicant argues that Wang, et al., “ERC-20R and ERC-721R: Reversible Transactions on Ethereum” (first publicly available Jul. 31, 2022) [“NPL Wang”] is not prior art to the present application (effective filing date: Jun. 30, 2023), because the Declaration of Inventor Erik Tierney (filed July 2, 2026) establishes that the named inventors invented the subject matter of NPL Wang relied upon in the rejection and explains that Qinchen Wang and Dan Boneh contributed only to portions of NPL Wang not included in the claimed subject matter. Applicant’s Reply at 21.
Examiner respectfully disagrees. Applicant’s Declaration has been considered but is insufficient to establish NPL Wang qualifies for the exception under 35 U.S.C. § 102(b)(1)(A). Applicant has not met its burden of production to establish that the exception applies.
MPEP § 2153.01(a) provides guidance applicable to the present facts:
If, however, the application names fewer joint inventors than a publication (e.g., the application names as joint inventors A and B, and the publication names as authors A, B and C), it would not be readily apparent from the publication that it is an inventor-originated disclosure and the publication would be treated as prior art under AIA 35 U.S.C. 102(a)(1) unless there is evidence of record that an exception under AIA 35 U.S.C. 102(b)(1) applies.
Here, the application names Keri Kaili Wang and Erik Tierney as inventors, while NPL Wang names Kaili Wang, Qinchen Wang, and Dan Boneh as authors. Thus, only Kaili Wang appears in both the application inventor list and NPL Wang’s author list. It is therefore not apparent from the publication that the relied upon disclosure is an inventor-originated disclosure. NPL Wang is treated as prior art under 35 U.S.C. § 102(a)(1) unless Applicant provides evidence establishing that an exception under § 102(b)(1)(A) applies. MPEP § 2153.01(a). Thus, Applicant bears the burden of coming forward with evidence sufficient to establish the exception.
Applicant may establish the § 102(b)(1)(A) exception by submitting an affidavit or declaration under 37 C.F.R. § 1.130(a) that provides: (i) “an unequivocal statement from the inventor or a joint inventor that the inventor or joint inventor (or some combination of named inventors) invented the subject matter of the disclosure”; and (ii) “a reasonable explanation of the presence of additional authors.” An “unequivocal statement” and “reasonable explanation” “may be acceptable in the absence of evidence to the contrary.” “[A] naked assertion of inventorship [ ] that fails to provide any context, explanation, or evidence to support that assertion is insufficient.” MPEP § 2155.01.
Here, regarding the first prong, (i), unlike the sufficient declaration in MPEP § 2155.01, Example 1, here, the Declaration does not unequivocally state that Erik Tierney, Keri Kaili Wang, or a specified combination of named inventors invented the particular subject matter of NPL Wang relied upon in the rejection. The Declaration merely states that Erik Tierney and Keri Kaili Wang are joint inventors of the present application, which does not establish who invented the anticipatory subject matter disclosed by NPL Wang. Tierney Decl. ¶ 1.
Regarding the second prong, (ii), the Declaration does not provide a sufficiently particular and supported explanation for the additional authors. It asserts that Qinchen Wang and Dan Boneh “contributed to other parts of NPL Wang that are not included in the claimed subject matter,” without identifying those parts, describing the authors’ respective contributions, or providing a factual basis for the Declarant’s knowledge. Tierney Decl. ¶ 3. Additionally, NPL Wang repeatedly uses (over seventy-five times) the words “we” and “our” to represent the collective opinion and contribution of all three authors. For example, NPL Wang states that “we propose reversible versions of ERC-20 and ERC-721”; “We also provide a prototype implementation”; “We provide a reference implementation of these new standards”; and “Our freeze algorithm will chase the stolen funds across the transaction graph and freeze funds across suspected addresses.” NPL Wang at 1, 4, 7. NPL Wang therefore collectively attributes to its authors the proposal, implementation, and freeze algorithm used to describe the reversible token operations relied upon in the § 102 rejection. Although literary co-authorship does not establish joint inventorship, this collective attribution is evidence contrary to the Declarant’s unexplained allocation of contributions and therefore requires more than the Declarant’s conclusory assertion.
Accordingly, Applicant has not met its burden of production to establish that the relevant disclosure in NPL Wang was made by an inventor or joint inventor. The Declaration therefore does not establish the § 102(b)(1)(A) exception, and NPL Wang remains available as prior art under § 102(a)(1).
35 U.S.C. §§ 102/103 Argument
Based on Examiner’s finding Applicant has not met its burden of production to establish the § 102(b)(1)(A) exception and NPL remaining available as prior art under § 102(a)(1), Applicant’s arguments regarding the withdrawal of the §§ 102.103 rejections are unpersuasive.
Claim Interpretation
Under the broadest reasonable interpretation, consistent with the specification, the following claim terms are given their ordinary meaning as interpreted by one of ordinary skill in the art. MPEP § 2111.
token(s) is a digital asset used in transaction recorded on the blockchain. Spec. ¶¶ 15, 17.
wrapped token(s) is a token that encapsulates an underlying base token by adding data or functionality to the base token.
wallet is a “digital account” that stores tokens. Spec. ¶¶ 18, 20.
recoverable state is “reversible”. Spec. ¶¶ 17, 21.
non-recoverable state is “irreversible” Spec. ¶¶ 17, 21.
frozen is unavailable for transfer, because the token is associated with a disputed or cancelled transaction. Spec. ¶¶ 21, 24, 27.
encapsulating a base token, with a recoverability status indicator and a frozen status indicator is creating a wrapped token based on a base token by adding recoverability data or functionality, including data indicating whether the token is recoverable and frozen, while retaining the base token as the underlying token, Spec. ¶¶ 17, 21, 55.
Claim Objections
Claim 21 is objected to because of the following informalities. Appropriate correction is required.
Claim 21: Claim 21 is objected to under 37 CFR § 1.75(c) because it depends from Claim 22, which is not previously set forth. MPEP § 608.01(n)(III).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 5–10, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over NPL: Wang, et al., “ERC-20R and ERC-721R: Reversible Transactions on Ethereum” (Oct. 11, 2022) [“NPL Wang”] in view of NPL: Kyber Network, et al., “Wrapped Tokens,” Jan. 24, 2019 [“NPL Wrapped Tokens”]
Regarding Claim 1, NPL Wang discloses:
A computer-implemented method, comprising:
(See at least p. 1, “We also provide a prototype implementation” of our standards” p.4, “Our Solidity implementation is split into two parts: (i) the main ERC-20R and ERC-721R contracts that keep track of all the balances and transactions, and (ii) a governance contract that selects judges and gathers votes.”
creating a wrapped token [ERC-20R] by encapsulating a base token [ERC-20], with a recoverability status indicator and a frozen status indicator, wherein the base token [ERC-20] is exchanged in transactions on the blockchain;
(See at p.1, “In this paper we propose reversible versions of ERC-20 and ERC-721 … This paper explores these challenges and proposes a design for our ERC-20R and ERC-721R standards, the reversible versions of ERC-20 and ERC-721.” See also p. 4, “Our ERC-20R and ERC-721R implementations are extensions of the Open Zeppelin non-reversible contracts … In our ERC-20R contract, an account balance is a pair of numbers we call Rbalance and NRbalance. • The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal.”
Thus, the ERC-20R token adds functionality to the underlying ERC-20 token, wherein the functionality added includes a recoverability data layer (Rbalance/NRbalance) and a freeze data layer without altering capability of the ERC-20 transfer function. p.4 (“our transfer function is backwards compatible with the ERC-20 specification.”). ERC-20R retains ERC-20 transfer functionality while adding Rbalance and NRbalance classifications. Each fungible token in Rbalance is recoverable (reversible) while each token in NRbalance is non-recoverable (irreversible), so an ERC-20R token’s membership in the Rbalance and NRbalance pol is per token recoverability status data satisfying the claimed “recoverability status indicator”). See. p. 4.
NPL Wang further discloses frozen amount and claim data records. See pp. 4–5, “• freeze(): calculates the amounts to freeze on the attacker’s address as well as potential downstream addresses, and freezes those amounts. For ERC-20R it returns a claimID that points to an on-chain list of (account, amount) pairs.”; p. 7, “If there are multiple freeze events on a single account, the frozen amount is cumulative. In particular, if account a has a total of s frozen coins, then the ERC-20R contract will reject any transfer that causes the Rbalance of account a to drop below s.”; p. 10, “all these freeze amounts are recorded in a secondary array called claims that is indexed by a newly generated 256-bit ClaimID.”
Because ERC-20R tokens are fungible, each token included in a recorded frozen quantity necessarily has the frozen status represented by that quantity and its corresponding ClaimID record, and the contract enforces that status by refusing to transfer any coin causing the account’s Rbalance to drop below the cumulative frozen amount (p.7). Thus, the extension of the underlying ERC-20 implementation with Rbalance, NRbalance, frozen amount, and claim data creates a reversible ERC-20R token by adding the recoverability and frozen status information.
receiving a request to execute a transaction on a blockchain, wherein the request comprises a request to transfer a quantity of a token on the blockchain from a transmitter wallet to a receiver wallet identified in the request, wherein the token comprises the wrapped token [ERC-20R];
(See at least p.3, “Suppose Alice holds tokens in an ERC-20R (an R-token) and she wishes to exchange them for ETH or for some other ERC-20 (a non-R-token). Bob is willing to do the ETH-for-token exchange with Alice and they agree on the exchange rate.” p. 4, “When an account owner sends funds from its own account to another account (say, to fulfill an exchange of assets), the account owner specifies how much to take out of the Rbalance and how much to take out of the NRbalance. That is, the standard ERC-20 transfer function now comes in two flavors: transfer() and Rtransfer(). The former transfers from the nonreversible balance, while the latter transfers from the reversible balance. Either way, the transferred funds are added to the Rbalance of the recipient.” The ERC-20R transfer () and Rtransfer() function calls constitute requests to execute blockchain transactions transferring a specific quantity of the ERC-20R tokens from the sending account [transmitter wallet] to the receiving account [receiver wallet], and each call specifies the sender address, recipient address, and amount.)
incrementing a running total of tokens in the receiver wallet that are in a recoverable state by the quantity of the token identified in the request based on the recoverability status indicator of each token;
(See at least p.4, “When an account owner sends funds from its own account to another account (say, to fulfill an exchange of assets), the account owner specifies how much to take out of the Rbalance and how much to take out of the NRbalance. That is, the standard ERC-20 transfer function now comes in two flavors: transfer() and Rtransfer(). The former transfers from the nonreversible balance, while the latter transfers from the reversible balance. Either way, the transferred funds are added to the Rbalance of the recipient. Rbalance is the running total of transferred funds in a recoverable state. Adding the transferred quantity to Rbalance increments that running total by the quantity identified in the request. Because every token is accounted for in Rbalance is subject to reversal, inclusion in Rbalance indicates the recoverability status of each token included in the balance.)
determining, after a threshold amount of time [dispute window] from a timestamp associated with the received request, whether the transaction has been frozen based on the frozen status indicator of each token; and
(See at least p. 1, “a transaction is eligible for reversal for a short period of time after it has been posted on chain. After the dispute period has elapsed, the transaction can no longer be reversed.” See also, Fig. 1. p. 4, “The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. As the dispute window elapses, funds move from the Rbalance to the NRbalance. This is done using the clean function discussed below.” p.4. See also, p. 5, “The clean function removes on-chain information for transactions whose dispute window has elapsed.” p. 10–11, “For every deleted entry, the specified spenditures amount is transferred from the account’s Rbalance to its NRbalance, while making sure that the total Rbalance does not drop below the frozen amount at the account.”
When clean processes a transaction after expiration of that window, it determines whether the corresponding amount may be moved to NRbalance while preserving the account’s recorded frozen amount. Therefore, the operation distinguishes transaction amounts subject to a recorded freeze from amounts eligible for reclassification. The frozen amount and the associated ClaimID records indicate that the tokens included in the transaction amount were frozen during the dispute window. The clean function’s arithmetic check that the Rbalance not drop below the frozen amount is therefore a per-token determination, keyed on the frozen status indicator, that necessarily runs after a threshold amount of time from the timestamp associated with the received request (i.e., after the dispute window elapses))
based on determining that the transaction has been frozen: identifying a chain of wallets [downstream accounts], including the receiver wallet, in which tokens associated with the transaction were transferred based on timestamps associated with a series of transactions such that a total amount of tokens frozen across the chain of wallets equals the quantity of the token; and
(See at least p. 3, “By the time the freeze is executed, the funds may have been dispersed across many downstream accounts, some honest and some dishonest.” p. 7, “Subsequent transfers from a0 that took place after the disputed transaction, but prior to a freeze request, are indicated as directed edges in the graph. All these downstream addresses may hold stolen funds that may need to be frozen.” p. 8, “consider the graph G that is defined by the set of transactions that took place after the disputed transaction and before the freeze transaction.” p. 9, “The loop proceeds in reverse chronological order, namely from the most recent transaction to the oldest transaction.” p. 10, “Each Spenditure entry in Figure 5 contains the triple (to, amount, blockNumber). p.8, Fig. 3 showing directed graph G rooted attacker address a0 with downstream accounts a1–a8.
Each directed path through the transaction graph, beginning with the receiver of the disputed transaction and proceeding through downstream accounts, is the chain of wallets. The accounts on each path are identified from transactions occurring after the disputed transfer and before the freeze request. Each spenditure entry records the recipient, amount, and block number (p.10) and the freeze algorithm traverses those entries by block number in reverse chronological order (p.9) The block number field and the chronological ordering derived from it, are timestamps associated with a series of transactions.
The total amount frozen across the downstream accounts equal to the disputed quantity. p.8, “The process terminates once s coins are frozen, or once there are no more descendants to process.” p.15, “Theorem 1. Suppose that no burn transactions are processed between the disputed transaction t0 and the freeze transaction tf. Moreover, there are no prior freezes in the system. Then, if the disputed transaction t0 sends tokens to address a0, then the freeze algorithm in Figure 4 will freeze a total of exactly s tokens.”
transferring tokens from the chain of wallets to the transmitter wallet [owner].
(See at least p. 5, “reverse(): sends all frozen assets associated with the claimed theft back to the original owner.” p. 10, “If the victim prevails in trial, this array is used to transfer the correct amount from every suspect address to the victim.” p.11, “An ERC-20R reversal takes as input a ClaimID which is an index into the claims array. The entry indicates the obligation of each suspect account in the disputed transfer. The function transfers the specified amount from the Rbalance of suspect accounts [downstream wallets identified by the freeze algorithm] to the original owner, and clears the freezes.”
The suspect accounts are the downstream account wallets identified by the freeze algorithm and the original owner is the transmitter from which the disputed transaction originated. The reverse function transfers the specified frozen quantities from the identified chain of downstream wallets to the transmitter wallet, transferring tokens from the chain of wallets to the transmitter wallet.)
NPL Wang discloses all of the limitations of Claim 1. Alternatively, NPL Wang does not disclose, arguendo, but NPL Wrapped Tokens discloses:
creating a wrapped token [Wrapped BTC] by encapsulating a base token [Bitcoin],
(See at least p. 2, “The first wrapped token we launch will be an ERC20 token backed by Bitcoin (BTC) and will be appropriately named, "Wrapped BTC" (WBTC). Unlike centralized solutions (USD), WBTC will be fully accounted for and proof of reserves posted on the BTC chain.” p.4, “The wrapped framework would make it easy to represent any other cryptocurrency, such as Bitcoin, on Ethereum and thereby enhance it with all the capabilities of the Ethereum blockchain.” p.5, “describing Key Roles of the Custodian and Merchant.
NPL- Wang discloses an ERC-20R token having recoverability and frozen status functionality. NPL Wrapped Token disclose creating a wrapped ERC-20 token backed by an underlying blockchain asset by holding the underlying blockchain asset, minting a corresponding wrapped ERC-20 token, and later burning the wrapped token to release the underlying asset. NPL Wang expressly contemplates the wrapped token in 2018, “In a 2018 tweet, Vitalik Buterin wrote that Someone should come along and issue an ERC20 called “Reversible Ether” that is 1:1 backed by ether but has a DAO that can revert transfers within N days.” p.2.NPL Wang invites application of it reversible design to a wrapped token architecture of the type taught by NPL Wrapped Token.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to implement NPL Wang’s ERC-20R token using the wrapped token architecture taught by NPL Wrapped Token. NPL Wrapped Token teaches that wrapping permits an existing cryptocurrency to be represented on Ethereum blockchain and enhanced with additional Ethereum functionality. Applying that wrapped token architecture to NPL Wang would have permitted an existing base token to obtain recoverability and frozen status functionality without modifying the underlying token or its native blockchain. The combination would predictably create a wrapped token based on an underlying base token with recoverability and frozen status data. A person of ordinary skill would have had a reasonable expectation of success because both references implement transferable blockchain tokens using ERC-20 smart contracts and the combination would use NPL Wrapped Token’s known minting and backing process for token creations together with NPL Wang’s state and recovery functions.
Regarding Claim 3, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 1,
NPL Wang further discloses
further comprising: receiving, from a defined governance source, an indication that the transaction is to be reversed; and based on the received indication,
(See at least p. 2, “A decentralized set of judges decides to accept or reject the request. If accepted, the judges instruct an on-chain governance contract to call the freeze function on the impacted ERC-20R or ERC-721R contract. Subsequently, the assets in question are frozen and can no longer be transferred.” p.2, “Eventually the judges reach a decision, at which point they instruct the governance contract to call either the reverse or rejectReverse functions on the impacted ERC-20R or ERC-721R contract. The reverse function transfers the disputed (frozen) assets to their original owner.” p.5, “The freeze, reverse and rejectReverse functions can only be called by the governance contract.” For ERC-20R, the freeze function records the frozen quantity for each implicated account, makes frozen quantities cumulative, and records the account and amount pairs in a claims array indexed by ClaimID. pp. 5, 7,10. Under BRI, the governance contract’s call to the freeze function is the “defined governance source” indicating that the transaction has been accepted into the freeze and reversal process and is subject to reversal, and the governance contract’s subsequent call to reverse() is the express governance indication “that the transaction is to be reversed”. In response to the freeze call, ERC-20R updates the frozen amount and associated ClaimID records for the quantity implicated in the transaction. The recorded frozen amount indicates that each fungible token included in the quantity is frozen.)
Regarding Claim 5, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 4 and the series of transactions
NPL Wang further discloses
wherein the series of transactions comprises a chain of transactions ordered sequentially in time and performed subsequent to the transaction.
(See at least p. 7, “Subsequent transfers from a0 that took place after the disputed transaction, but prior to a freeze request, are indicated as directed edges in the graph. All these downstream addresses may hold stolen funds that may need to be frozen.” Graph G (Fig. 3) is defined using transactions occurring after the disputed transactions and before the freeze transaction, and processes outgoing transactions “in reverse chronological order,” and records a blockNumber for each transfer. pp. 8–10. Each directed path from the recipient of the disputed transaction through one or more downstream accounts is a chain of transactions. Every transaction on that path occurs after the disputed transaction and is ordered by its transaction sequence and recorded block number.)
Regarding Claim 6, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 1 and incrementing the running total of tokens in the receiver wallet that are in the recoverable state
NPL Wang further discloses
wherein incrementing the running total of tokens in the receiver wallet that are in the recoverable state comprises transferring, from the transmitter wallet to the receiver wallet, the quantity of the token into a portion of the receiver wallet in which tokens in the recoverable state are stored.
(See at least p. 4, “In our ERC-20R contract, an account balance is a pair of numbers we call Rbalance and NRbalance. … The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. … Either way, the transferred funds are added to the Rbalance of the recipient.” Rbalance is a logical portion of the recipient account in which recoverable ERC-20R tokens are maintained. The transferred quantity is added to the recipient’s Rbalance regardless of whether the sender uses transfer() or Rtransfer() (p.4) so adding the transferred quantity to the recipient’s Rbalance transfers that quantity into the claimed recoverable token portion of the receiver’s wallet.)
Regarding Claim 7, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 6 and transferring the quantity of the token
NPL Wang further discloses
wherein transferring the quantity of the token comprises transmitting the quantity of the token from tokens in the non-recoverable state in the transmitter wallet.
(See at least p. 4, “The former transfers from the nonreversible balance, while the latter transfers from the reversible balance. Either way, the transferred funds are added to the Rbalance of the recipient.” See also, p. 4, “The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal.” In the transfer() embodiment, the transferred quantity is withdrawn from the transmitter’s NRbalance. Because NRbalance contains tokens that are no longer subject to freezing or reversal, NPL Wang discloses transmitting the quantity from tokens in the transmitter’s wallet that are in a non-recoverable state.)
Regarding Claim 8, NPL Wang discloses:
The method of Claim 6 and transferring the quantity of the token
NPL Wang further discloses
wherein: transferring the quantity of the token comprises transmitting a first quantity of the token from tokens in the recoverable state in the transmitter wallet before transmitting a second quantity of the token from tokens in the non-recoverable state, a sum of the first quantity of the token and the second quantity of the token equals the quantity of the token; and the first quantity of the token is less than the quantity of the token.
(See at least p.4, “When an account owner sends funds from its own account to another account (say, to fulfill an exchange of assets), the account owner specifies how much to take out of the Rbalance and how much to take out of the NRbalance. That is, the standard ERC-20 transfer function now comes in two flavors: transfer() and Rtransfer(). The former transfers from the non-reversible balance, while the latter transfers from the
reversible balance. Either way, the transferred funds are added to the Rbalance of the recipient.” Thus, a single outgoing transfer can be split into two components: one withdraw from the Rbalance (recoverable) and one withdraw from the NRbalance (non-recoverable), with the account owner specifying the amount taken from each. Because the split is a partition of the total quantity, each quantity is necessarily less that the total, and their sum necessarily equals the total, satisfying the “first quantity + second quantity = total quantity” and “first quantity < total quantity” limitations. To the extent Claim further requires the recoverable withdraw to precede the non-recoverable withdrawal within a single transaction, the ordering of the two withdrawals is matter of routine implementation choice within NPL Wang’s disclosed two-type transfer architecture. And would have been obvious to one of ordinary skill in the art as a predictable design choice.
Regarding Claim 9, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 6 and transferring the quantity of the token
NPL Wang further discloses
wherein a policy associated with the receiver wallet identifies whether the quantity of the token can be withdrawn from a portion of the transmitter wallet in which tokens in the recoverable state are stored.
(See at least p. 4, “The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. As the dispute window elapses, funds move from the Rbalance to the NRbalance. This is done using the clean function discussed below.” pp. 3–4, “Bob will not release his ETH to Alice until he is assured that the R-tokens that Alice sent him cannot be taken back due an upstream reversal request. This means that Bob will only accept R-tokens that were transferred to Alice at least four days ago, if the dispute window is four days.” p. 12–13, “some exchanges and lending protocols may be willing to take the risk and accept funds from Alice’s Rbalance, most likely charging Alice a higher fee in the process.” A recipient, such as Bob or a receiving exchange, determines whether it will accept funds from the sender’s Rbalance. Under BRI, the receiver side acceptance rule is a “policy associated with the receiver wallet” because it is enforced at the receiver wallet ad controls whether the receiver wallet will accept a transfer drawn from the transmitter’s recoverable (Rbalance) portion. Wand discloses twp policy states: (1) refusing to accept funds drawn from the sender’s Rbalance (pp. 3-4) and (2) accepting funds subject to additional conditions (pp. 12-13 “willing to take a risk and accept funds from Alice’s Rbalance”).)
Regarding Claim 10, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 1
NPL Wang further discloses
further comprising determining, based on records stored on the blockchain, a first amount of tokens in a non-recoverable state in the transmitter wallet and a second amount of tokens in a recoverable state in the transmitter wallet, wherein the second amount of tokens in the recoverable state are identified based on transaction records on the blockchain associated with transactions for which the threshold amount of time has not elapsed.
(See at least p. 4, “Recall that an ERC-20 contract manages the balances of many accounts. In our ERC-20R contract, an account balance is a pair of numbers we call Rbalance and NRbalance. The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. As the dispute window elapses, funds move from the Rbalance to the NRbalance. This is done using the clean function discussed below.” p. 5, “Reversible contracts store some transaction data on chain.” Because ERC-20R is implemented as an on-chain Ethereum smart contract (p.4, “Our Solidity implementation is split into two parts: (i) the main ERC-20R and ERC-721R contracts that keep track of all the balances and transactions”), the Rbalance and NRbalance variables of each account, together with the spenditure data structure, are stored on the blockchain. The spenditure structure records each transfer’s destination, amount, and block number, and the clean function removes entries for transactions whose dispute windows that have elapsed and transfers the corresponding amounts from Rbalance to NRbalance (p.10). Thus, the on-chain ERC-20R contract records Rbalance and NRbalance for each account and maintains transaction records containing transfer amounts and block numbers. Rbalance represents the second amount attributable to transactions whose dispute windows have not elapsed, while NRbalance represents the first amount attributable to transactions whose dispute window have elapsed. Reading those contract records to obtain Rbalance and NRbalance is determining both amounts based on records stored on the blockchain.)
Regarding Claim 21, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 22
NPL Wang further discloses
further comprising: [ … ] incrementing of the running total of tokens in the receiver wallet that are in the non-recoverable state; [ … ].
(See at least p. 4, “Recall that an ERC-20 contract manages the balances of many accounts. In our ERC-20R contract, an account balance is a pair of numbers we call Rbalance and NRbalance. The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. As the dispute window elapses, funds move from the Rbalance to the NRbalance. This is done using the clean function discussed below.”
NPL Wang discloses the triggering event—the incrementing of the running total of tokens in the receiver wallet that are in the non-recoverable state (NRbalance) upon expiration of the dispute window. NPL does not disclose the unwrapping, base-token storage, and reminting. Thus, NPL Wang does not disclose but NPL Wrapped Token discloses:
unwrapping the base token from the wrapped token [ … ] ; and storing the unwrapped base token in a base token store, wherein the unwrapped base token is retrieved from the base token store and used to generate a subsequent wrapped token in association with a subsequent transaction.
(See NPL Wrapped Tokens p. 2, " The first wrapped token we launch will be an ERC20 token backed by Bitcoin (BTC) and will be appropriately named, "Wrapped BTC" (WBTC). Unlike centralized solutions (USD), WBTC will be fully accounted for and proof of reserves posted on the BTC chain." p. 5, describes the Custodian as "the institution or party to which wrapped tokens will be minted to and burnt from" and holds the underlying base tokens in reserve. pp. 5–6 further describes the mint/burn cycle in which the custodian holds the base token in reserve, mints a corresponding wrapped token upon deposit, releases the base token upon burn of the wrapped token, and can re-mint a new wrapped token from the released base token in a subsequent transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine NPL Wang's Rbalance-to-NRbalance transition with NPL Wrapped Tokens' unwrapping, custodial storage, and re-minting architecture, such that the transition of tokens in the receiver wallet to the non-recoverable state (NRbalance) triggers unwrapping the base token from the wrapped ERC-20R token, storing the unwrapped base token in the Wrapped Tokens custodian's reserve store, and making the stored base token available for generating a subsequent wrapped token in a subsequent transaction. The combination is a straightforward application of prior-art elements according to known methods to yield the predictable result of a recoverable wrapped token that returns to base-token custody upon completion of the dispute window. A person of ordinary skill would have had a reasonable expectation of success because both references implement transferable blockchain tokens using ERC-20 smart contracts, and Wrapped Tokens' mint/burn/custody framework is designed to be applied to any ERC-20 wrapping scenario, including the ERC-20R reversibility framework of Wang. NPL Wang itself expressly contemplates the wrapped-token paradigm (p. 2, quoting Buterin's proposal for a 'Reversible Ether' ERC-20 '1:1 backed by ether'; p. 5, describing Lossless.io as a 'wrapped version of certain ERC-20 tokens'), supplying an in-reference motivation to combine. MPEP § 2143(G).)
Regarding Claim 22, NPL Wang and NPL Wrapped Token disclose:
The method of Claim 1
NPL Wang further discloses
based on determining that the transaction has not been frozen: decrementing the running total of tokens in the receiver wallet that are in the recoverable state by the quantity of the token, and incrementing a running total of tokens in the receiver wallet that are in a non-recoverable state by the quantity of the token.
(See at least p. 4, “The NRbalance is the current account balance due to incoming transactions whose dispute window has elapsed. Funds in the NRbalance are non-reversible: they are no longer subject to a potential freeze and reversal. • The Rbalance is the account balance due to recent incoming transactions. Funds in the Rbalance are subject to reversal. As the dispute window elapses, funds move from the Rbalance to the NRbalance. This is done using the clean function discussed below.” See also p. 5, "clean(): Reversible contracts store some transaction data on chain. The clean function removes on-chain information for transactions whose dispute window has elapsed." pp. 10–11, "For every deleted entry, the specified spenditures amount is transferred from the account's Rbalance to its NRbalance, while making sure that the total Rbalance does not drop below the frozen amount at the account." The clean function operates on transactions whose dispute window has elapsed and, for every such transaction, transfers the specified transaction amount from the account's Rbalance to its NRbalance — that is, decrements the Rbalance (the receiver wallet's running total of tokens in the recoverable state) by the transaction quantity and increments the NRbalance (the receiver wallet's running total of tokens in the non-recoverable state) by the same transaction quantity. The clean function's arithmetic check that "the total Rbalance does not drop below the frozen amount at the account" (pp. 10–11) expressly conditions the Rbalance-to-NRbalance transfer on the transaction not having been frozen, meeting the "based on determining that the transaction has not been frozen")
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 11, 13, 15–20, 23, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over NPL Wang and NPL Wrapped Token and further in view of Krasnyansky (U.S. Pat. Pub. No. 2021/0383334) [“Krasnyansky”].
Regarding Claim 11, NPL Wang and NPL Wrapped Token disclose
create a wrapped token by encapsulating a base token with a recoverability status indicator and a frozen status indicator, wherein the base token is exchanged in transactions on the blockchain; receive a request to execute a transaction on a blockchain, wherein the request comprises a request to transfer a quantity of a token on the blockchain from a transmitter wallet to a receiver wallet identified in the request, wherein the token comprises the wrapped token; increment a running total of tokens in the receiver wallet that are in a recoverable state by the quantity of the token identified in the request based on the recoverability status indicator of each token; determine, after a threshold amount of time from a timestamp associated with the received request, whether the transaction has been frozen based on the frozen status indicator of each token; and based on a determination that the transaction has been frozen: identify a chain of wallets, including the receiver wallet, in which tokens associated with the transaction were transferred based on timestamps associated with a series of transactions such that a total amount of tokens frozen across the chain of wallets equals the quantity of the token; and transfer tokens from the chain of wallets to the transmitter wallet.
(See rejection Claim 1)
NPL Wang does not disclose but Krasnyansky discloses:
A system, comprising: a memory having executable instructions stored thereon; and a processor configured to execute the executable instructions in order to cause the system to:
(See at least ¶ 90, “each server computing device may include at least a processing unit
and a system memory for executing computer-readable instructions (e.g., a contingency
payment system and contingency payment tracking system application) for implementing
the contingent payment system 124 and tracking system 530.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined A system, comprising: a memory having executable instructions stored thereon; and a processor configured to execute the executable instructions in order to cause the system to as explained in Krasnyansky, to the known invention of NPL Wang, in the same field of invention, with the motivation to permit a “contingent transfer of value”. Krasnyansky, ¶¶ 4, 18.
The remaining limitations of Claims 13, 15, 16, 17, 18, 19, and 23 are not substantively different than those presented in Claims 3, 6, 7, 8, 9, 10, and 22 respectively, and are therefore, rejected, mutatis mutandis, based on NPL Wang, NPL Wrapped Token, and Krasnyansky for the same rationale presented in Claims 3, 6, 7, 8, 9, 10, and 22, respectively, supra.
Regarding Claim 20, NPL Wang discloses
creating a wrapped token by encapsulating a base token with a recoverability status indicator and a frozen status indicator, wherein the base token is exchanged in transactions on the blockchain; receiving a request to execute a transaction on a blockchain, wherein the request comprises a request to transfer a quantity of a token on the blockchain from a transmitter wallet to a receiver wallet identified in the request, wherein the token comprises the wrapped token; incrementing a running total of tokens in the receiver wallet that are in a recoverable state by the quantity of the token identified in the request based on the recoverability status indicator of each token; determining, after a threshold amount of time from a timestamp associated with the received request, whether the transaction has been frozen based on the frozen status indicator of each token; and based on determining that the transaction has been frozen: identifying a chain of wallets, including the receiver wallet, in which tokens associated with the transaction were transferred based on timestamps associated with a series of transactions such that a total amount of tokens frozen across the chain of wallets equals the quantity of the token; and transferring tokens from the chain of wallets to the transmitter wallet.
(See Rejection Claim 1)
NPL Wang does not disclose but Krasnyansky discloses:
A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processor, performs an operation comprising:
(See at least Claim 19)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 11 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 20.
Regarding Claim 24, NPL Wang, NPL Wrapped Token, and Krasnyansky disclose:
The computer-readable medium of Claim 20
The remaining limitations of Claim 24 are not substantively different than those presented in Claim 22 and are therefore, rejected, mutatis mutandis, based on NPL Wang, NPL Wrapped Token, and Krasnyansky for the same rationale presented in Claim 22 supra.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
Prosecution Insights