DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
The reply filed 07/30/2025 is acknowledged. Claims 1 and 4 have been amended. Claims 2-3 have been canceled. Claims 5-7 are new. Claims 1 and 4-7 are pending and presented for examination.
Response to Arguments
Applicant’s amendments, filed 07/30/2025, with respect to claims 1 and 4 have overcome the previous claim objections. Therefore, the previous claim objections to claims 1 and 4, set forth in Non-Final Rejection 04/30/2025, have been withdrawn.
Applicant’s amendments, filed 07/30/2025, with respect to claim 1 has overcome the previous 35 U.S.C. 112(b) rejection of claims 1-4. Claim 3 has been canceled, therefore, the previous 35 U.S.C. 112(b) rejection of claim 3 has been rendered moot. The previous 35 U.S.C. 112(b) rejection of claim 1-4, set forth in Non-Final Rejection 04/30/2025, has been withdrawn. However, the claim amendments present new issues under 35 U.S.C. 112(a) and 112(b). Please see below for more details.
Applicant's arguments filed 07/30/2025 have been fully considered, but they are not persuasive.
Applicant’s remarks state –
“In an exemplary embodiment, unlike Sells or Brock, exemplary embodiments consistent with the claimed invention require an on-chain confirmation of a user-preauthorized smart contract to gate fiat transaction approval ensuring decentralization and user-side control, which is neither taught nor suggested by the cited references. In detail, Applicant respectfully asserts that the cited references fail to disclose, first entering a smart contract (which allows for a later transfer of tokens between claimed "user's wallet" and "EOA", then receiving a request from an "authorizing entity", and executing the smart contract at a later time. Accordingly, neither Sells nor Brock teaches delayed execution of a pre-agreed smart contract to approve fiat at POS. In an exemplary embodiment, Sells generally uses internal ledged logic and lack blockchain confirmation as gating event for fiat approval ("based on the confirmation of the on-chain transaction" of the claimed invention) while Brock's system appears to convert crypto to fiat using payment service-held wallets without using user-authorized smart contracts (see US2019/0034889Al, paras. [0025], [0049], [0058]).
“Furthermore, in an exemplary embodiment, the request from the "point-of-sale device to the card processor based on confirmation of the on-chain transaction" may be approved, and then, the settlement occurs.”
In response to the Applicant’s remarks, Sells et al. WO 2022/027027 (herein referred to as “Sells”) discloses “the exchange may be automatically performed by the platform based at least in a part on a rule stored in a smart contract” in [0013], “the platform 100 may include an orchestration services system 102, including automated services 104 that may utilize smart contracts 108…as part of managing a wallet” in [0054], “The various options for users present many optimization opportunities, which may be undertaken using a set of rules or a model (optionally embodied by a smart contract that facilitates transaction execution upon ingesting applicable data sets) in [0087], “a transfer to a merchant may be made in advance of redemption, vice versa, or simultaneously. An intelligent agent or other aspect of orchestration services may optimize the timing…redemption may be delayed for a period of time…” and “The merchant or receiving party may still receive payment in fiat currency” in [0087]. One of ordinary skill in the art would know that smart contracts are executed upon meeting the predetermined requirements/conditions, therefore, the actions associated with executing a smart contract are “delayed” or occurs “at a later time” because the terms and/or conditions of the smart contract must first be met and/or triggered. Therefore, since Sells discloses using a smart contract to store rules and performing automatic exchanges, i.e. transactions, Sells at least discloses a delayed execution of a smart contract to approve fiat at POS [0064]. Furthermore, Sells discloses “The wallet is typically configured to interact with an underlying blockchain, such as embodying a distributed ledger that represents a set of transactions involving the cryptocurrency, typically validated by a set of consensus algorithms” in [0022]. Brock et al. U.S. 2019/0034889 (herein referred to as “Brock”) discloses “Once a miner has verified the block, the block is written to a public, distributed blockchain 220 where payment service 108 can then verify that the transaction has been confirmed and can credit customer’s cryptocurrency ledger 204 with the transferred amount” in [0052], i.e. confirm and then settle. Therefore, Sells in view of Brock teach at least a delayed execution of a smart contract to approve fiat at POS and requiring an on-chain confirmation for transaction approval. Abbas et al. U.S. 2024/0386427 (herein referred to as “Abbas”) was previously used to teach a user agreeing to the terms of a smart contract [0082]. Therefore, the combination of Sells in view of Abbas, and further in view of Brock teach the delayed execution of a pre-agreed smart contract to approve fiat at POS. Detailed mapping and rationale to combine are provided below. For purposes of brevity, please see below for more details.
Claim Objections
Claim 1 is objected to because of the following informalities:
“a user’s wallet” should be “a user’s wallet of the user” on pg. 2, line 5.
“the user device” should be “a user device of the user” on pg. 2, line 9.
Appropriate correction is required.
Claim 5 is objected to because of the following informalities: “comprises” should be “comprise.” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 and 4-7 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “withdrawing at least a portion of the number of tokens from the EOA to a local wallet associated with the authorizing entity.” The specification does not provide adequate support for such limitation. At most, the specification discloses an AE wallet 112, analogous to the “a local wallet associated with the authorizing entity,” may be able to hold tokens that may be retrieved from EOA 114 in [0031]. However, the specification does not disclose “withdrawing at least a portion of the number of tokens from the EOA” to the AE wallet. Furthermore, the specification discloses that the AE wallet 112 may not be necessary due to presence of EOA 114 in [0030]. Therefore, the claim introduces new matter.
Claims 4-7 depend from rejected claim 1. They do not cure the deficiencies presented above. Therefore, they are also rejected under 35 U.S.C. 112(a).
Claim 6 recites “wherein the user’s wallet is a non-custodial wallet not managed by the authorizing entity.” The specification does not provide adequate support for such limitation. Therefore, the claim introduces new matter.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 and 4-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation “the terms” on pg. 2, line 9. There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites “the transaction request” on pg. 3, line 12. Claim 1 also previously recites “a request from a point-of-sale device” and “a new transaction request to the crypto-currency network.” Therefore, it is unclear to which request “the transaction request” is referring. Appropriate clarification is required.
Claim 1 recites “the request from the point-of-sale device to the card processor” on pg. 3, pg. 15. Claim 1 previously recites “receiving…from one or more processors associated with a card processor, a request from a point-of-sale device.” There is no request from the point-of-sale device to the card processor. Therefore, there is insufficient antecedent basis for this limitation in the claim.
Claims 4-7 depend from rejected claim 1. They do not cure the deficiencies presented above. Therefore, they are also rejected under 35 U.S.C. 112(b).
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 and 4-7 are rejected under 35 U.S.C. 103 as being unpatentable over Sells et al. WO 2022/027027 (herein referred to as “Sells”) in view of Abbas et al. U.S. 2024/0386427 (herein referred to as “Abbas”), and further in view of Brock et al. U.S. 2019/0034889 (herein referred to as “Brock”).
Re Claim 1, Sells discloses a method for conducting a debit card-based transaction using by a user having a crypto-currency account, comprising:
entering a smart contract, on a crypto-currency network, between a user and an authorizing entity [0092] – “The third-party financier can facilitate the transaction (for a user),” [0087] – “The various options for users present many optimization opportunities, which may be undertaken using a set of rules or a model (optionally embodied by a smart contract that facilities execution upon ingesting applicable data sets),” i.e. entering a smart contract, the smart contract configured to transfer a maximum number of tokens from a user’s wallet to an authorizing entity wallet (EOA) associated with the authorizing entity at a later time when the smart contract is executed [0098] – “the wallet holder may transfer an amount of cryptocurrency, i.e. tokens, to an account of the third-party financier (i.e. EOA),” [0013] – “the exchange may be automatically performed by the platform based at least in a part on a rule stored in a smart contract…The rule may relate to…a transaction size (minimum, maximum, or range), i.e. maximum number of tokens”, wherein entering the smart contract comprises […] allowing the transfer of the maximum number of tokens from the user’s wallet to the authorizing entity wallet associated with the authorizing entity at the later time when the smart contract is executed;
One of ordinary skill in the art would know that smart contracts are executed upon meeting the predetermined requirements/conditions, therefore, the actions associated with executing a smart contract are “delayed” or occurs “at a later time” because the terms and/or conditions of the smart contract must first be met and/or triggered. Since Sells discloses using a smart contract to store rules and performing automatic exchanges, i.e. transactions, Sells at least discloses allowing the transfer at the later time when the smart contract is executed [0013, 54, 87].
receiving, at one or more processors associated with the authorizing entity, from one or processors associated with a card processor, a request from a point-of-sale device to approve an amount in fiat currency [0098] – “The user may initiate a fiat currency payment transaction funded by a cryptocurrency on the user’s application. This transaction may be initiated by the user’s client device, debit card or wearable debit card. The request may be received at the user’s bank,” [0092] – “the bank may contact the third-party financier,” [0100] – “The user may complete a transaction at a point-of-sale 1206”;
forwarding a new transaction request to the crypto-currency network, from the one or more processors associated with the authorizing entity based on the received request [0098] – “The bank may relay the request (i.e. based on the received request) to the third-party financier and the user’s wallet holder (i.e. crypto-currency network) and information stored in one or more databases associated with the authorizing entity, the information stored in the one or more databases associated with the authorizing entity including information about the entered smart contract [0094] – “The third-party financier 710 may store…information which can facilitate transactions” to execute the smart contract on the crypto-currency network, [0087] – “a smart contract that facilitates transaction execution”;
executing the smart contract on the crypto-currency network in response to receiving the new transaction requestion [0087] – “smart contract that facilitates transaction execution upon ingesting applicable data sets,” comprising
initiating a fund transfer and withdrawing, on the crypto-currency network, a quantity of the tokens from the user's wallet to the EOA, the number of tokens corresponding to the amount of the fiat currency [0098] – “In response, the wallet holder may transfer an amount of cryptocurrency (i.e. quantity of tokens) to an account of the third-party financier (i.e. EOA).” [0011] – “the cryptocurrency amount corresponds to the request for payment based on the cryptocurrency valuation, exchanging the cryptocurrency amount for a fiat currency amount of corresponding value” and […];
approving, utilizing the one or more processors associated with the authorizing entity, the request from the point-of-sale device to the card processor based on confirmation of the on-chain transaction [0098] – “Upon receipt of the cryptocurrency, the third-party financier may transfer a sum of fiat currency to an account associated with the bank. Upon receipt of the funds, the bank may authorize the payment”;
storing information related to the approved request in the one or more databases
associated with the authorizing entity [0094] – “database structure 700 is shown for storing information by various entities to facilitate the transaction in conjunction with the platform…transaction data, an amount for each transaction…(i.e. related to the approved request)”; and
settling a payment between the authorizing entity and a merchant associated with the
point-of-sale device based on the previously approved request [0098] – “The merchant may receive the currency selected for the purchase of a good or service or other transaction type as an outcome of this process 1018”, comprising:
withdrawing at least a portion of the number of tokens from the EOA to a local wallet associated with the authorizing entity [0098] – “The third-party financier 1020 may have a settlement account (i.e. local wallet) at the bank 1000 that is linked to registered users 1004,” [0093] - “an entity separate from the third-party financier may hold the user’s cryptocurrency wallet and the third-party financier may receive/send cryptocurrency from/to the wallet holder (i.e. withdraw tokens)”;
converting the at least a portion of the number of tokens into an amount of settlement fiat currency [0058] – “convert cryptocurrency to fiat currency”; and
transferring the settlement fiat currency from a fiat currency account associated with the authorizing entity to a merchant fiat account associated with the merchant based on an amount corresponding to the previously approved request [0087] – “The corresponding payment (USD, i.e. fiat currency) transferred by conventional payment processing channels, such as by either a bank or third-party financier (i.e. authorizing entity) to the merchant.”
However, Sells does not expressly disclose
generating the smart contract, on the crypto-currency network; and
accepting the terms of the smart contract, utilizing the user device, allowing the transfer of the maximum number of tokens from the user’s wallet to the authorizing entity wallet associated with the authorizing entity at the later time when the smart contract is executed.
Abbas discloses method and system for triggering execution of a smart contract. Specifically, Abbas discloses
generating the smart contract, on the crypto-currency network [0073] – “When a smart contract is created, it is compiled into bytecode and stored on the blockchain network 200”; and
accepting the terms of the smart contract, utilizing the user device [0082] – “The indication of acceptance may include an acknowledgment to one or more terms of the smart contract,” thereby suggesting that the client device is used to acquiesce to the agreement of the smart contract.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Sell’s method for cryptocurrency payments with the teachings of generating the smart contract and accepting the terms of the smart contract in Abbas to arrive at the claimed invention. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself. Therefore, the combination of prior art elements according to known methods would yield predictable results and renders the claim obvious.
However, Sells in view of Abbas do not explicitly teach
updating a ledger on the crypto-currency network corresponding to the transferred number of tokens responsive to withdrawing the quantity of tokens from the user’s wallet to the EOA,
confirming, by the one or more processors associated with the authorizing entity, an onchain transaction corresponding to the transaction request on a blockchain based on the updated ledger on the crypto-currency network.
Brock discloses a cryptocurrency payment network. Specifically, Brock discloses
updating a ledger on the crypto-currency network corresponding to the transferred number of tokens responsive to withdrawing the quantity of tokens from the user’s wallet to the EOA [0078] – “Payment service can then debit cryptocurrency ledger 204…and credit payment service 108’s cryptocurrency ledger 219 with the same value”,
confirming, by the one or more processors associated with the authorizing entity, an onchain transaction corresponding to the transaction request on a blockchain based on the updated ledger on the crypto-currency network [0052] - “Once a miner has verified the block, the block is written to a public, distributed blockchain 220 where payment service 108 can then verify that the transaction has been confirmed and can credit customer’s cryptocurrency ledger 204 with the transferred amount,” [0040] – “merchants 102 sending transaction data directly to the payment service 108 as part of the request to authorize the payment instrument,” therefore, the payment service 108 constitutes an authorizing entity.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Sell in view of Abbas’ method for cryptocurrency payments with the teachings of updating a ledger and confirming an on-chain transaction based on the updated ledger in Brock to arrive at the claimed invention. One would be motivated to make this combination to quickly verify that the transfer is legitimate and complete the transaction, thereby improving processing speed Brock, [0050], [0114].
Re Claim 4, Sells in view of Abbas and Brock teach the method of claim 1, and Sells in view of Abbas and Brock further teach wherein generating the smart contract comprises:
accessing terms of an agreement of the smart contract, utilizing a user device Abbas [0089] – “a graphical user interface may be displayed that includes terms and conditions of an agreement,” [0082] – “The indication of acceptance may include acknowledgment to one or more terms of the smart contract”;
inputting acquiescence to the agreement utilizing the user device Abbas, [0089] – the message is displayed on the client device 110, [0082] – “The indication of acceptance may include an acknowledgment to one or more terms of the smart contract,” thereby suggesting that the client device is used to acquiesce to the agreement of the smart contract; and
recording the smart contract on a ledger on the crypto-currency network Abbas, [0073] – “When a smart contract is created, it is compiled into bytecode and stored on the blockchain network 200.”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Sell’s method for cryptocurrency payments with the teachings of acquiescing to the terms of the agreement of the smart contract in Abbas to arrive at the claimed invention. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself. Therefore, the combination of prior art elements according to known methods would yield predictable results and renders the claim obvious.
Re Claim 5, Sells in view of Abbas and Brock teach the method of claim 1, and Sells in view of Abbas and Brock further teach wherein the tokens comprises Ethereum tokens Sells, [0087].
Re Claim 6, Sells in view of Abbas and Brock teach the method of claim 1, and Sells in view of Abbas and Brock further teach wherein the user’s wallet is a non-custodial wallet not managed by the authorizing entity Sells, Fig. 7 – the BTC wallet 708 is separate from TPF 710, therefore, not managed by the authorizing entity.
Sells does not expressly disclose that the crypto or BTC wallet is a non-custodial wallet. However, Sells does disclose “offline computer or device can be used as a cryptocurrency wallet,” i.e. non-custodial wallet. One of ordinary skill in the art would be motivated to modify the crypto or BTC wallet to be a non-custodial wallet because it would secure against online theft by hackers Sells, [0026].
Re Claim 7, Sells in view of Abbas and Brock teach the method of claim 1, and Sells in view of Abbas and Brock further teach wherein approving the request from the point-of-sale device comprises verifying confirmation of the token transfer on a publicly distributed blockchain Brock, [0052] - “Once a miner has verified the block, the block is written to a public, distributed blockchain 220 where payment service 108 can then verify that the transaction has been confirmed and can credit customer’s cryptocurrency ledger 204 with the transferred amount.”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Sell in view of Abbas’ method for cryptocurrency payments with the teachings of verifying confirmation of the token transfer on a publicly distributed blockchain in Brock to arrive at the claimed invention. One would be motivated to make this combination to quickly verify that the transfer is legitimate and complete the transaction, thereby improving processing speed Brock, [0050], [0114].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINE DANG whose telephone number is (571)270-5880. The examiner can normally be reached M-F 9-5pm MT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698