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 .
This Office Action is in response to the Applicant’s Amendment filed December 19, 2025. Claims 1-6 and 13-18 are pending and under examination in this case. Claims 7-12 were previously canceled subject to a Requirement for Restriction. Claims 1-3 and 13-15 are currently amended.
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. Applicant's submission filed on December 19, 2025, has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-3 and 13-15, as currently amended, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-6 and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Brock (US 2019/0034889) in view of Isaacson et al (US 2016/0379298), and further in view of Sells et al (US 2023/0043702).
Regarding claims 1 and 13 –
Brock discloses a method for cryptocurrency checkout, (par 21) comprising:
receiving, by a merchant backend, an identification of a good or service to purchase from a computer program for a customer; (par 73-84 discussing steps performed by the payment service “Payment service 108 receives the transaction details and encrypted cryptocurrency payment information, and calculates (312) a value in cryptocurrency using an exchange rate between the cryptocurrency and the fiat currency (US Dollars in this example) sufficient to cover the value owed to merchant” at par 77; “Payment service can then debit cryptocurrency ledger 204 for the value calculated at step 312 and credit payment service 108's cryptocurrency ledger 219 with the same value” at par 78; “ transaction can be completed immediately without waiting on confirmation of the transaction from blockchain” at par 79’’; also at 21 “the payment service described herein can facilitate real-time (or substantially real-time) transactions, allowing a customer to pay in any currency of their choice, while the merchant can receive payment in a currency of their choice” and par 27 “including servers and server software, merchant devices and software, and client devices and software”, also par 22, 28, 30, This facilitating of transactions is a checkout flow, while the payment service receiving “transaction details and encrypted cryptocurrency payment information, and calculates . . .” is indicative of payment service taking control of the transaction.)
executing, by the merchant backend, a checkout flow for a transaction for the good or service with the customer; (par 83-84, also par 21, 22, 27, 28, 30),
receiving, by the merchant backend, a selection of a cryptocurrency payment option from the customer, wherein the customer does not have a cryptocurrency account; (Brock par 50 “customer profile 132 for customer 104 can include ledgers for more or less accounts”, also par 58 “when customer profile 132 includes multiple payment accounts (e.g., cryptocurrency and fiat currency), application 210 can set one of those accounts to be the default account for debits or credits when using an internal payment card” , 59, 60, 70, 95 “After receipt of transaction information, customer device 103 presents (412) payment options, and receives a selection (414) of a cryptocurrency payment option and sends an instruction to payment merchant 102 using the selected payment option to payment service 108. In some embodiments customer device 103 may need to send authentication information or a PIN to conduct the transaction. In some embodiments, authentication is not sent to the payment service and is instead left to application 210 to authenticate a user to instruct that a payment be made”, also par 56 where “Customer 104's fiat currency ledger 206 . . . can be credited when conducting a transaction with another user (customer or merchant) of the payment service wherein the account receives incoming currency” – indicating the various transactions may be carried out with customer fiat currency account, whether or not the customer has a cryptocurrency account.)
transferring, by the merchant backend, control of the checkout flow to a financial institution backend for a financial institution; par 73-84 discussing steps performed by the payment service “Payment service 108 receives the transaction details and encrypted cryptocurrency payment information, and calculates (312) a value in cryptocurrency using an exchange rate between the cryptocurrency and the fiat currency (US Dollars in this example) sufficient to cover the value owed to merchant” at par 77; “Payment service can then debit cryptocurrency ledger 204 for the value calculated at step 312 and credit payment service 108's cryptocurrency ledger 219 with the same value” at par 78; “ transaction can be completed immediately without waiting on confirmation of the transaction from blockchain” at par 79’’; also at 21 “the payment service described herein can facilitate real-time (or substantially real-time) transactions, allowing a customer to pay in any currency of their choice, while the merchant can receive payment in a currency of their choice” and par 27 “including servers and server software, merchant devices and software, and client devices and software”, also par 22, 28, 30, This facilitating of transactions is a checkout flow, while the payment service receiving “transaction details and encrypted cryptocurrency payment information, and calculates . . .” is indicative of payment service taking control of the transaction)
receiving, by the financial institution backend, control of the checkout flow for a transaction between the merchant backend and a computer program for a customer, wherein the merchant backend accepts payment in cryptocurrency; (par 73-84 discussing steps performed by the payment service “Payment service 108 receives the transaction details and encrypted cryptocurrency payment information, and calculates (312) a value in cryptocurrency using an exchange rate between the cryptocurrency and the fiat currency (US Dollars in this example) sufficient to cover the value owed to merchant” at par 77; “Payment service can then debit cryptocurrency ledger 204 for the value calculated at step 312 and credit payment service 108's cryptocurrency ledger 219 with the same value” at par 78; “ transaction can be completed immediately without waiting on confirmation of the transaction from blockchain” at par 79’’; also at 21 “the payment service described herein can facilitate real-time (or substantially real-time) transactions, allowing a customer to pay in any currency of their choice, while the merchant can receive payment in a currency of their choice” and par 27 “including servers and server software, merchant devices and software, and client devices and software”, also par 22, 28, 30, This facilitating of transactions is a checkout flow, while the payment service receiving “transaction details and encrypted cryptocurrency payment information, and calculates . . .” is indicative of payment service taking control of the transaction)
executing, by the financial institution backend, the checkout flow by:
receiving login credentials with the financial institution for the customer from the computer program; (par 37, par 61 “Once accessed or registered into the applications 240 and 210, the web browser or application remembers the credentials for subsequent customer visits (for example, through web browser authentication, web cookies, web history, etc.) allowing the customer to access the application without logging-in into an account. The description herein is with reference to the mobile payment application 210 as an installed application; however it will be understood that the mobile payment application as an authenticated or unauthenticated application on a web browser is within the meaning of the term”, also par 70 “application 210 can instruct customer device 103 hardware to communicate (308) information declaring that customer 104 would like to pay utilizing cryptocurrency, customer 104 alias, and encrypted customer profile information. The encrypted customer profile information can include at least some data useable by payment service 108 to identify customer profile 132. In some embodiments, this data can include a user name and password. In some embodiments, this data can include an account number and a PIN (or other verification of identity). In some embodiments, verification of identity can be performed by customer device 103 through biometric authentication or other means, and confirmation of identity through a password or PIN does not need to be passed to the server. In some embodiments, payment service can identify customer profile 132 through use of a registered alias, perhaps in combination with other information”)
confirming payment to the merchant backend; (par 86-88) and
settling, by the financial institution backend, the transaction by providing a settlement amount in cryptocurrency to the merchant backend. (par 86-88)
Brock does not specifically disclose retrieving a plurality of customer non-cryptocurrency accounts with the financial institution for the customer.
However, Brock does disclose retrieving a plurality of customer accounts with the financial institution for the customer; (par 37 “payment processing service 126 may communicate with one or more computing devices of a payment card network 140 (or “card payment network”), e.g., MasterCard®, VISA®, over network(s) 110 to conduct financial transactions electronically. Payment processing service 126 can also communicate with one or more computing devices of one or more banks, processing/acquiring services, or the like over the network 110. For example, payment processing service 126 may communicate with an acquiring bank, and/or an issuing bank, and/or a bank maintaining customer accounts for electronic payments. Payment processing service 126 may also communicate with, or access customer and merchant accounts maintained by payment service”; par 47 customer profiles including customer accounts))
Sells discloses wherein those customer accounts may be, inter alia, non-cryptocurrency accounts. (par 481 “custodian account associated with the user 3110 may allow the user to select to pay in Bitcoin or some other cryptocurrency type or to pay in fiat currency”).
It would be obvious to combine Brock with Sells, since both involve selecting an account and by adding other accounts, as Sells, creating greater convenience for the user.
Brock does not specifically disclose receiving a selection of one or more of the plurality of customer non- cryptocurrency accounts to fund the cryptocurrency for the transaction.
However, Brock discloses receiving a selection of one or more of the plurality of customer accounts to fund the cryptocurrency for the transaction; (par 50 “customer profile 132 for customer 104 can include ledgers for more or less accounts”, also par 58, 59, 60, 70, 95 “After receipt of transaction information, customer device 103 presents (412) payment options, and receives a selection (414) of a cryptocurrency payment option and sends an instruction to payment merchant 102 using the selected payment option to payment service 108. In some embodiments customer device 103 may need to send authentication information or a PIN to conduct the transaction. In some embodiments, authentication is not sent to the payment service and is instead left to application 210 to authenticate a user to instruct that a payment be made”)
Sells discloses wherein those customer accounts may be, inter alia, non-cryptocurrency accounts. (par 481 “custodian account associated with the user 3110 may allow the user to select to pay in Bitcoin or some other cryptocurrency type or to pay in fiat currency”).
It would be obvious to combine Brock with Sells, since both involve selecting an account and by adding other accounts, as in Sells, creating greater convenience for the user.
Brock does not specifically disclose deducting a payment amount for the transaction from the one or more selected customer non-cryptocurrency accounts.
However, Brock does disclose deducting a payment amount for the transaction from the one or more selected customer accounts; (par 86-88).
Sells discloses wherein those customer accounts may be, inter alia, non-cryptocurrency accounts. (par 481 “custodian account associated with the user 3110 may allow the user to select to pay in Bitcoin or some other cryptocurrency type or to pay in fiat currency”).
It would be obvious to combine Brock with Sells, since both involve selecting an account and by adding other accounts, as in Sells, creating greater convenience for the user.
Brock does not specifically discloser returning, by the financial institution backend, control of the checkout flow to the merchant backend, wherein the merchant backend executes the checkout flow to complete the transaction with the customer.
However, Isaacson, in analogous art, discloses returning, by the financial institution backend, control of the checkout flow to the merchant backend, wherein the merchant backend executes the checkout flow to complete the transaction with the customer. (par 304 “payment account information is passed from the browser or other agent to the merchant site through the API for payment processing. The payment account data can be transmitted to the merchant in a secure, one-time use fashion and configured such that the payment can be processed but the merchant cannot store the user's payment account data”, also par 20, 299, 265).
However, Isaacson, in analogous discloses returning, by the financial institution backend, control of the checkout flow to the merchant backend, wherein the merchant backend executes the checkout flow to complete the transaction with the customer. (par 304 “payment account information is passed from the browser or other agent to the merchant site through the API for payment processing. The payment account data can be transmitted to the merchant in a secure, one-time use fashion and configured such that the payment can be processed but the merchant cannot store the user's payment account data”, also par 20, 299, 265).
It would be obvious to one of ordinary skill in the art to combine Brock with Isaacson for greater flexibility in payment processing.
Regarding claims 2 and 14 –
Brock discloses that the plurality of customer accounts comprise a demand deposit account, a credit account, a line of credit account, and/or a reward/loyalty point account. (par 32, 49).
Sells discloses wherein those customer accounts may be, inter alia, non-cryptocurrency accounts. (par 481 “custodian account associated with the user 3110 may allow the user to select to pay in Bitcoin or some other cryptocurrency type or to pay in fiat currency”).
It would be obvious to combine Brock with Sells, since both involve selecting an account and by adding other accounts, as in Sells, creating greater convenience for the user.
Regarding claims 3 and 15 –
Brock discloses that the financial institution backend deducts a fee from the one or more selected customer accounts in addition to the payment amount. (par 77, 81, 99)
Sells discloses wherein those customer accounts may be, inter alia, non-cryptocurrency accounts. (par 481 “custodian account associated with the user 3110 may allow the user to select to pay in Bitcoin or some other cryptocurrency type or to pay in fiat currency”).
It would be obvious to combine Brock with Sells, since both involve selecting an account and by adding other accounts, as in Sells, creating greater convenience for the user.
Regarding claims 4 and 16 –
Brock discloses purchasing, by the financial institution backend, cryptocurrency of a type accepted by the merchant backend. (par 51, 126)
Regarding claims 5 and 17 –
Brock discloses that the step of settling the transaction by providing a settlement amount in cryptocurrency to the merchant backend comprises transferring, by the financial institution backend, the settlement amount in cryptocurrency from a financial institution cryptocurrency wallet to a merchant cryptocurrency wallet. (par 86-88)
Regarding claims 6 and 18 –
Isaacson discloses that the checkout flow comprises an option to checkout with the financial institution backend. (par 304 “payment account information is passed from the browser or other agent to the merchant site through the API for payment processing. The payment account data can be transmitted to the merchant in a secure, one-time use fashion and configured such that the payment can be processed but the merchant cannot store the user's payment account data”, also par 20, 299, 265).
It would be obvious to one of ordinary skill in the art to combine Brock with Isaacson for greater flexibility in payment processing.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRISTINA OWEN SHERR whose telephone number is (571)272-6711. The examiner can normally be reached 8:30 - 5:30.
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, John W Hayes can be reached at 571-272-6708. 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.
/Cristina Owen Sherr/Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697