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 .
Request for Consideration
The Applicant’s Request for consideration dated 01/26/2026 is acknowledged.
Status of Claims
Claims 1, 8 and 15 are amended.
Claims 1-20 are pending.
Response to Arguments
Claim Rejections- 35 USC 112 (a) &(b)
The amendments/limitations are provided to address issues from the 35 USC 112 (a)&(b) are acknowledged. Thus these rejections are withdrawn.
Claim Rejections- 35 USC 103 (a)
The 35 USC 103 rejection is maintained for the following reasons:
Amended Claim 1 (and similarly claims 8 and 15) recites, “…providing a datastore of rebalance job data comprising status of respective rebalance jobs executing across the multiple cryptocurrency networks; performing a portion of a set of checks based on the first rebalance job…in response to determining that the first rebalance job is a concurrent rebalance job in response to a status of the at least one on-going rebalance job determined from the rebalance job data;…”
In regards to “providing a data store of rebalance job data…” it is maintained that Tierney at least discloses a datastore (Fig. 6)(item# 610)(item#640)[¶0065],[¶0066] and [¶0076].
In regards to “….comprising status of respective rebalance jobs executing across the multiple cryptocurrency networks;”
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies, that being the status of the rebalance job, which according to the specification is either PENDING, IN-PROGRESS or COMPLETED (see Applicant’s Specification [¶0039]), are not recited in the rejected claim(s). It should be noted that although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Thus, under the broadest reasonable interpretation, Tierney describes the status of respective rebalance job(s) where in the rebalancer, if the token amount for a given network is not the same as the target ratio value for that network, is outside of the range defined by the float variable for that network, it is determined to be in an ‘out of balance’ status. For network(s) that are out of balance, the flow diagram proceeds to block 216 to bring the out-of-balance network(s) back into a ‘balanced’ status, otherwise returns to block 204. (see Tierney [¶0048]-[0051]). Tierney also discloses that the rebalancer 102 issues a rebalance transaction for the network (e.g., may be multiple networks) that is out of balance.
It is also the case that Tierney also discloses performing a set of checks based upon rebalance (Fig. 2)(item# 200)(Fig. 4) (400)[0058].
It is thus respectfully submitted that for the reasons stated above, that the 35 USC 103 rejections is maintained below.
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.
Claim(s) 1, 3-8, 10-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tierney et al (2023/0073883) in view of Liu et al (US 2021/0049594).
Regarding Claims 1, 8, and 15, Tierney discloses a computer-implemented method, apparatus, methods, processing systems, and computer-readable mediums for multi-blockchain token rebalancing, [see also ¶0018];
a non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations (non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of a processing system, cause the processing system to perform the aforementioned methods, [see ¶0007); a system (item# 100), comprising:
a computing device; and a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device, cause the computing device to perform operations (non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of a processing system, cause the processing system to perform the aforementioned methods [see ¶ 0007];
The rebalancer (item# 102) comprises a CPU, memory, storage, etc., [see ¶0026, ¶0028); the method, the non-transitory computer- readable storage medium, and the system comprising operations for concurrent rebalancing of tokens of a cryptocurrency across multiple cryptocurrency networks [see, ¶0018], comprising:
determining a first set of actual ratios for a set of chain networks, each actual ratio in the first set of actual ratios representing a relative number of tokens of a cryptocurrency within a respective chain network of the set of chain networks,[see ¶0018-generating a first ratio for each of a plurality of blockchains constitutes determining a first set of actual ratios for a set of chain networks and the ratio determined based on the amount of token on each blockchain shows that the ratio represents the relative number of tokens within a respective chain network];
comparing actual ratios in the first set of actual ratios to respective target ratios in a set of target ratios to provide a first set of differences (a target ratio defining a first quantitative relationship between an amount of a token present is determined for each of a plurality of blockchains...The first ratio is compared to the target ratio to generate a ratio difference, ¶0018, [target ratios determined for each of a plurality of blockchains constitute a set of target ratios and comparing the first ratio to the target ratio to generate a ratio difference for each blockchain constitutes providing a first set of differences]);
determining that a first rebalance job is to be executed for a first chain work in the set of chain networks in response to the first set of differences, and in response, defining a first rebalance job for the first chain network (Based on the ratio difference, a rebalancing transaction is executed on the first blockchain to bring the amount of the first token closer to the target ratio for the first blockchain, ¶0018, ¶0049), the first rebalance job comprising a first transaction to be executed on the first chain network and a second transaction to be executed on a second chain network in the set of chain networks (the rebalance transaction will issue a transaction on a first network to bring the token amount on that network back to the target ratio value for that network...The rebalance transaction will also issue a counter-transaction on a second network to ensure the total amount of the token across all networks complies with the asset reserves backing the token, ¶0049, [the rebalance transaction issued on a first network and the counter-transaction on a second network constitutes a first transaction and a second transaction to be executed on a first and second chain network, respectively]);
providing a datastore of rebalance job data comprising status of respective rebalance jobs executing across the multiple cryptocurrency networks; [Tierney describes the status of respective rebalance job(s) where in the rebalancer, if the token amount for a given network is not the same as the target ratio value for that network, is outside of the range defined by the float variable for that network, it is determined to be in an ‘out of balance’ status. For network(s) that are out of balance, the flow diagram proceeds to block 216 to bring the out-of-balance network(s) back into a ‘balanced’ status, otherwise returns to block 204. (see Tierney [¶0048]-[¶0051]). Tierney also discloses that the rebalancer 102 issues a rebalance transaction for the network (e.g., may be multiple networks) that is out of balance.]
performing at least a portion of a set of checks based on the first rebalance job (executing the rebalancing transaction is based on the ratio difference exceeding a float variable, para 0064, [checking whether the ratio difference exceeds a float variable constitutes performing at least a portion of a set of checks]); and executing the first rebalance job in response to the first rebalance job meeting the at least a portion of the set of checks in response to a status of the at least one on-going rebalance job determined from the rebalance job data (Executing the rebalancing transaction is based on the ratio difference exceeding a float variable, ¶0064-the ratio difference exceeding a float variable constitutes a rebalance job meeting the at least a portion of the set of checks, where the float variable is a check. Tierney also discloses performing a set of checks based upon rebalance (Fig. 2)(item# 200)(Fig. 4) (400)[¶0058]).
Tierney fails to explicitly disclose performing a check based on the first job and at least one on-going rebalance job in response to determining that the first job is a concurrent rebalance job.
Liu teaches performing a check based on the first job and at least one on-going rebalance job in response to determining that the first job is a concurrent rebalance job (the remitter account further includes a reserve fund list to support concurrent transactions generated based on the balance of the remitter account [see abstract].
The reserve fund list includes multiple reserved amounts obtained by dividing the account balance, so that at least one of the multiple reserved amounts can be allocated to a remittance transaction that the reserved amount is sufficient to pay. As the reserve fund list can include multiple available reserved amounts, the remitter can initiate, based on the multiple available reserved amounts, multiple remittance transactions that the reserved amounts are sufficient to pay, [see ¶0022] to ensure that the reserved amount allocated to the first transaction has not been used in other remittance transactions, the reserved amount can be marked in the reserve fund list to reduce “double-spending” transactions generated based on the same reserved amount, [¶0028], [checking that there is an amount available for a transaction in the reserve fund list and that the reserved amount is not being used in a different remittance transaction constitutes performing a check based on a first job and at least one on-going rebalance job in response to determining that the first job is a concurrent rebalance job, where a reserved amount already being committed to a different remittance transaction is the on- going rebalance job and shows a concurrent rebalance job, where the transactions are rebalance jobs since a remittance rebalances the account]).
It would have been obvious before the effective filing date for one of ordinary skill in the art to modify Tierney with the remittance of Liu for the purpose of providing a remittance method where multiple reserved amounts are generated based on an account balance, and the multiple reserved amounts are allocated to multiple remittance transactions. Whether existing remittance transactions can afford payment is verified based on an account balance of a remitter account. Different from such verification, in the remittance method provided in the present specification, a blockchain node verifies, based on a reserved amount included in each remittance transaction, whether each remittance transaction can afford payment. The verification on remittance transactions is separately performed and does not affect each other. As such, a blockchain constructed based on an account model can send multiple remittance transactions in parallel (see Liu, para 0010).
Regarding Claims 3, 10, and 17, as modified by Liu, the prior art discloses the computer-implemented method of claim 1, the non-transitory computer-readable storage medium of claim 8, and the system of claim 15, respectively, further comprising delaying execution of the first rebalance job until the first rebalance job meets the at least a portion of the set of checks (the ratio of tokens across the various networks may fluctuate about their respective target ratio 108 value by a float variable value for each network, such as float variable1 110 through float variable N 112. For example, a network having an 80% target ratio value may have a large and continuous transactional volume of the token, causing a constant fluctuation of +/-10% about the target ratio value for that network. To avoid constant rebalancing transactions, a configuration parameter of the rebalancer may have may set the float variable value for this network to be +/-10%, para 0047, [in order to avoid constantly rebalancing, setting a float variable for the network constitutes delaying execution of the first rebalance job until the first rebalance job meets at least a portion of the set checks since the rebalance job would not take place as soon as the actual ratio is different than the target ration, and instead would delay until it is +/- 10%, for example, about the target ratio value]).
Regarding Claims 4, 11, and 18, as modified by Liu, the prior art discloses the computer-implemented method of claim 1, the non-transitory computer-readable storage medium of claim 8, and the system of claim 15, respectively, wherein: the first transaction is executed by a first smart contract in the first chain network and is recorded in a first blockchain maintained within the first chain network (Mint and burn functions are typically provided cither as native token functionality in a cryptocurrency network or by a smart contract in a cryptocurrency network, [ ¶0022], [shows mint and burn transactions occur via smart contract]; At arrow 320, the TIF1 120 executes the function to meet the rebalancing transaction request (¢.g., a mint or a burn), and at arrow 324 issues the transaction 128 to the blockchain1 130 to record the rebalancing transaction, ¶0053); and the second transaction is executed by a second smart contract in the second chain network and is recorded in a second blockchain maintained within the second chain network (Mint and burn functions are typically provided either as native token functionality in a cryptocurrency network or by a smart contract in a cryptocurrency network, [¶0022]);
At arrow 328, the TIFN 140 executes the function to meet the rebalancing counter transaction request (e.g., a burn or a mint transaction), and at arrow 332, issues the transaction 148 to the blockchainN 150 (e.g., a blockchain different than the rebalancing transaction) to record the rebalancing counter transaction, ¶0054).
Regarding Claims 5, 12, and 19, Tierney discloses the computer-implemented method of claim 1, the non-transitory computer-readable storage medium of claim 8, and the system of claim 15, respectively, wherein the first transaction changes a first reserve held by a provider of the cryptocurrency within the first chain network by a number of tokens determined based on a difference between a target ratio and an actual ratio, and the second transaction changes a second reserve held by the provider of the cryptocurrency within the second chain network by the number of tokens (Based on the ratio difference, a rebalancing transaction is executed on the first blockchain to bring the amount of the first token closer to the target ratio for the first blockchain, [0018];
If the token amount for a given network is not the same as the target ratio value for that network, or outside of the range defined by the float variable for that network, it is considered to be ‘out of balance,” [0048];
If the token amount for the network (item# 104) is out of balance, the rebalancer issues a rebalancing transaction to network TIF1 (item# 120), to execute the rebalance transaction...For example, if the rebalancing transaction is a mint transaction, the rebalancing counter transaction will be a burn transaction, and vice-versa, in order to maintain the total amount of the token across all selected networks (e.g., to comply with asset reserve requirements), [para 0051], [a second transaction countering the first transaction, for example, if the first transaction is a mint transaction then the second transaction is a burn transaction, in order to maintain the total amount of tokens based on the ratio difference constitutes changing a first reserve held by a provider of the cryptocurrency within the first chain network by a number of tokens determined based on a difference and the second transaction changes a second reserve held by the provider of the cryptocurrency within the second chain network by the number of tokens]). Regarding Claims 6, 13, and 20, modified discloses the computer-implemented method of claim 1, the non-transitory computer-readable storage medium of claim 8, and the system of claim 15, respectively, further comprising: determining a second set of actual ratios for the set of chain networks (A first amount of the token is received for a first blockchain, and a first ratio is generated for the token present on each of the plurality of blockchains, based on the first amount, paras [¶0018, ¶0044-¶0045]; At block 204, the rebalancer 102 receives a signal at a check interval to check a token balance for a network such as network! 104, or more than one network. The check interval may be a periodic interval, such as every two minutes, 30 minutes, hour, day, multiple days, etc., as appropriate, that may be determined a configuration parameter (or setting) of rebalancer 102, [0044, [checking the token balance and performing the steps of figure 2 in periodic intervals, shows that the steps of figure 2 are performed more than once]);
comparing actual ratios in the second set of actual ratios to respective target ratios in the set of target ratios to provide a second set of differences (At block 212, the rebalancer 102 compares the token amount (e.g., number of tokens) received from the network1 104 to the target ratio 108, [¶ 0046];
At block 312, the rebalancer compares the first ratio to the target ratio and generates a ratio difference, [¶0063];
determining that a rebalance job is to be executed for the first chain network in the set of chain networks in response to the second set of differences (At block 216, the rebalancer 102 issues a rebalance transaction for the network (e.g., may be multiple networks) that is out of balance, [¶0049]), and in response, defining a second rebalance job for the first chain network, the second rebalance job comprising a third transaction to be executed on the first chain network and a fourth transaction to be executed on the second chain network (the rebalance transaction will issue a transaction on a first network to bring the token amount on that network back to the target ratio value for that network, or in some networks, within the range defined by the float variable value for that network.
The rebalance transaction will also issue a counter-transaction on a second network to ensure the total amount of the token across all networks complies with the asset reserves backing the token, [¶0049]); and
executing the second rebalance job in response to determining that the second rebalance job is not in balance (At block 214, the rebalancer 102 determines if the token amount on each selected network is...within a range of the target ratio value based on the float variable, [¶0048];
At block 214, the rebalancer 102 determines if the token amount on each selected network is at the target ratio value or in some embodiments within a range of the target ratio value based on the float variable, [¶0049]).
Tierney fails to explicitly disclose determining that the second rebalance job is not a concurrent rebalance job. Advanced teaches determining that the second rebalance job is not a concurrent rebalance job (to ensure that the reserved amount allocated to the first transaction has not been used in other remittance transactions, the reserved amount can be marked in the reserve fund list to reduce “double-spending” transactions generated based on the same reserved amount, [¶0028], [ensuring the reserved amount allocated to the first transaction has not been used in other remittance transactions constitutes determining that the second rebalance job is not a concurrent rebalance job since the reserved amount can only be allocated to a single transaction]). It would have been obvious to one of ordinary skill in the art before the priority date to modify Tierney with the remittance of Liu for the purpose of providing a remittance method where multiple reserved amounts are generated based on an account balance, and the multiple reserved amounts are allocated to multiple remittance transactions. Whether existing remittance transactions can afford payment is verified based on an account balance of a remitter account. Different from such verification, in the remittance method provided in the present specification, a blockchain node verifies, based on a reserved amount included in each remittance transaction, whether each remittance transaction can afford payment. The verification on remittance transactions is separately performed and does not affect each other. As such, a blockchain constructed based on an account model can send multiple remittance transactions in parallel [see Liu, ¶0010].
Regarding claims 7 and 14, modified Circle discloses the computer-implemented method of claim 1, the non-transitory computer-readable storage medium of claim 8, respectively, wherein executing the first rebalance job comprises:
transmitting instructions to the first chain network to execute the first transaction (At arrow 320, the TIF1 120 executes the function to meet the rebalancing transaction request (e.g., a mint or a bur), and at arrow 324 issues the transaction] 128 to the blockchain1 130 to record the rebalancing transaction, [¶0053], [issuing transaction! to the blockchain1 constitutes transmitting instructions to the first chain network to execute the first transaction]); and transmitting instructions to the second chain network to execute the second transaction (At arrow 328, the TIFN 140 executes the function to meet the rebalancing counter transaction request (e.g., a burn or a mint transaction), and at arrow 332, issues the transaction 148 to the blockchainN 150 (e.g., a blockchain different than the rebalancing transaction) to record the rebalancing counter transaction, para 0054).
Claims 2, 9 and 16-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Boneh et al (US 2025/0292233) discloses cross-chain cryptocurrency abstraction using cross-chain transfer protocol
Williams et al (US 2025/0182074) discloses blockchain cross-chain non-fungible token exchange
Marques (US 2025/0086711) discloses system and method for linking cryptocurrency to a physical asset.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL S FELTEN whose telephone number is (571)272-6742. The examiner can normally be reached Flex.
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, Ryan D Donlon can be reached at 5712703602. 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.
DANIEL S. FELTEN
Examiner
Art Unit 3692
/DANIEL S FELTEN/Primary Examiner, Art Unit 3692
Prosecution Insights