Detailed Action
Claims 1, 4, and 6-7 are pending and are examined.
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 .
Status of Claims
Claims 1, 4, and 6 are currently amended.
Claims 2-3, and 5 are cancelled.
Response to Remarks
35 U.S.C. § 101
Remark 1: Applicant argues that claim 1 is not merely directed to cryptocurrency payment processing, but to a specific technical architecture for controlling smart-contract execution on a cryptocurrency network. The claim allegedly generates and records smart contracts on a distributed ledger, enforces token-transfer limits at execution time, and computes POS approval using wallet balance minus cumulative unsettled card balance. Applicant further argues that on-chain execution occurs only after authorization through distinct transaction request, thereby presenting settlement unless ledger-recorded constraints are satisfied. Applicant asserts that this improves cryptocurrency-network functionality under Enfish because it safely bridges real-time authorization with deferred on-chain smart-contract execution.
Response to Remark 1: Applicants arguments are unpersuasive because the amended claim remains directed to the abstract idea of authorizing and settling a financial transaction based on account balances and rules, even though the claim recites that the transaction is implemented using smart contracts and a cryptocurrency network. The recited ‘spending power’ calculation, balance updating, and approval decision, and token redistribution are financial-accouting functions that fall within certain methods of organizing human activity, including commercial interactions and payment settlement. The claim does not recite a technological improvement to the operation of a blockchain or distributed ledger itself, but instead uses conventional blockchain components as tools to perform the financial settlement process. Merely reciting that smart contracts are generated, recorded, and executed on-chain does not transform the abstract financial process into a patent-eligible technical improvement. Unlike Enfish, the claim is not directed to an improved data structure or improvement in computer functionality, but to applying financial authorization rules in a distributed ledger environment.
Remark 2: Applicant argues claims cannot be treated as a mental process because that require maintaining unsettled balances, calculating spending power from system-maintained values, etc. Applicant asserts that a human mind cannot mentally record or execute a smart contract or control blockchain execution after deployment. Applicant also argues that the claimed sequence of ledger recording, POS authorization, etc integrates the idea unto a practical application.
Response to Remark 2: Applicants argument that the claim cannot performed mentally is not persuasive because the Offices position is not limited to a pure-mental process characterization. Even if certain recited steps require a computer or blockchain environment, the claim as a whole remains directed to the abstract financial concept of approving and settling transactions using account balances and predefined rules. The use of processors, ledgers, smart contracts, and on-chain requests merely implements the commercial transaction flow in a technological environment. The claimed sequencing does not recite a specific improvement to the functioning of the computer, blockchain protocol, or network architecture itself. Rather, the claim uses generic computer and blockchain functionality to carry out the underlying economic practice.
Remark 3: Applicant argues that the claims recite specific execution-control architecture that decouples real-time authorization from later blockchain settlement and therefore provides a technical solution in the distributed ledger environment. Applicant further contends under Berkheimer that the Office failed to show the ordered combination was well-understood, routine, or conventional.
Response to Remark 3: Applicants Berkheimer argument is also unpersuasive because the additional elements, individually and as an ordered combination, do not amount to significantly more than the abstract idea. The claim recites generic processors, user wallets, merchant wallets, service-provider accounts, cryptocurrency ledgers, and smart contracts performing their expected functions of storing balances, receiving requests, executing transfer instructions, and recording transactions. The alleged non-conventional arrangement is still described at the high level of functional result, without reciting a particular technical mechanism for improving smart-contract execution, ledger security, consensus operation, network throughout, or computer performance. The claim does not require any unconventional blockchain protocol, specialized cryptographic process, or improved data structure; it merely applies routine blockchain transaction execution to financial authorization and settlement workflow. The fact that multiple balances are maintained and multiple transfers may occur does not provide an inventive concept, because those steps are part of the financial settlement logic itself.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Applicant respectfully notes that Kim has an effective filing date of July 22, 2023 and qualifies, if at all, as prior art only under 35 U.S.C. §102(a)(2). The Kim application and the present application were commonly owned prior to the effective filing date of the present application (August 11, 2025). All assignments evidencing such common ownership are recorded with the United States Patent and Trademark Office. Accordingly, pursuant to 35 U.S.C. § 102(b)(2)(C), Kim is excluded from the prior-art universe and cannot be relied upon in a rejection under § 103. Applicant has concurrently submitted a declaration under 37 C.F.R. § 1.130 establishing the foregoing facts. Accordingly, Applicant respectfully asserts that because Kim is excluded as prior art under § 102(b)(2)(C), the combination relied upon by the Examiner no longer exists. The remaining reference(s), standing alone, do not teach or suggest the claimed features, as indicated by the Office Action.” (id).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Ricotta and Kim) still teach the currently amended independent claims, as shown at least in paragraphs 21-22, 25-27, and 32-36 of Ricotta, and paragraphs 26-27 of Duris, and as further outlined in paragraphs 16-18 of this action. Indeed, Ricotta teaches debiting value from the user/customer side, crediting the payment service, and crediting the merchant, while Duris teaches a generated smart contract that transfers cryptocurrency from a service-side/liquidity-provider wallet to a merchant wallet and supports service-side settlement. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4, and 6-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 4, and 6-7 :
Step 1
Claims 1, 4, and 6-7 are directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of managing obligations between parties through conditional approval and redistribution of value. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. The claim limitations reciting the abstract idea are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, managing personal behavior or relationships or interactions between people, as they recite following rules or instructions. Indeed, the claims recite a condition-based transaction signing process that mitigates risk by ensuring a signature is only applied if an entity a transaction data meets a predefined policy. This mechanism supports commercial or legal interactions, such as authorizing sales or financial transactions, by preventing unauthorized or fraudulent signatures. More specifically, the following underlined claim elements recite the abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A method for settling cryptocurrency transactions, comprising:
entering a smart contract, on a crypto currency network, between a user, a merchant, and a service provider account (SPA), the SPA associated with a service provider,
wherein the entering the smart contract comprises:
generating the smart contract, on the crypto-currency network, allowing the transfer of a maximum number of tokens from the user's wallet, allowing the transfer of a first number of tokens to a service provider wallet associated with the service provider, and allowing transfer of a second number of tokens to a merchant wallet associated with the merchant;
recording the smart contract on a ledger on the crypto-currency network;
receiving, at one or more processors associated with the service provider, from one or processors associated with a merchant, POS transaction request from the merchant to approve an amount for a transaction;
determining, by the one or more processors associated with the service provider, whether to approve the amount for the transaction based on spending power associated with the user, the spending power calculated as a wallet balance associated with a user minus a card balance associated with the user;
approving, utilizing the one or more processors associated with the service provider, the POS transaction request from the merchant based on the determined approval;
updating, utilizing the one or more processors, the card balance associated with the user and a merchant account balance, based on approving the amount for the transaction;
forwarding a new on-chain transaction request to the crypto-currency network, from the one or more processors associated with the Service Provider, to execute the smart contract; and
initiating a token transfer, on the cryptocurrency network, by executing the smart contract, wherein execution of the smart contract enforces ledger-recorded token transfer limits and prevents settlement of the point-of-sale transaction unless the ledger-recorded constraints are satisfied, and wherein the initiating the token transfer by executing the smart contract comprises transferring an amount of tokens from a wallet associated with the user based on the card balance, transferring a second amount of tokens to a merchant wallet associated with the merchant based on the merchant account balance, and transferring a third amount of tokens to a service provider account.
Step 2A Prong Two
Prong Two asks does the claim recite additional elements that integrate the judicial exception into a practical application (MPEP § 2106.04(II)(A)(2)). Here, the additional elements of processor, execution of a smart contract, and crypto-currency network, individually and in combination, are recited at a high level of generality as generic and conventional elements merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)) and generally linking the use of the abstract idea to a particular technological environment (MPEP § 2106.05(h)). The description of the additional elements evidences that they are generic and conventional elements used as tools to perform the abstract idea. The processor may be a generic and conventional processor (See Spec. 0033). The execution of a smart contract may be a generic and conventional execution of a smart contract (See Spec. 0088-0091). The crypto-currency network may be a generic and conventional crypto-currency network (See Spec. 0024).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the abstract idea itself (MPEP § 2106.05). Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the abstract idea itself. Individually, the additional elements do not amount to significantly more than the abstract idea. As discussed previously, the description of the additional elements evidences that they are generic and conventional elements used as tools to perform the abstract idea (See Spec. 0024, 0033, and 0088-0091). As such, the additional elements merely serve as a tool to perform the abstract idea and generally link the use of the abstract idea to a particular technological environment. The ordered combination recites no more than the individual elements do. Thus, the additional elements are not significantly more than the abstract idea. Accordingly, the claims are directed to the abstract idea identified above without significantly more. The claims are not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 4, and 6-7 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising updating the ledger on the crypto-currency network.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein generating the smart contract comprises:
accessing terms of the agreement of the smart contract, utilizing a user device;
and inputting acquiescence to the agreement utilizing the user device.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the card balance comprises a cumulative total of unsettled transactions associated with the user.
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.
Claims 1, 4, and 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Ricotta et al. (US20190139033A1) (hereinafter “Ricotta”) in view of Duris et al. (US20230376940A1) (hereinafter “Duris”).
As per Claim 1, Ricotta teaches:
A method for settling cryptocurrency transactions, comprising: entering a smart contract, on a crypto currency network, between a user, a merchant, and a service provider account (SPA), the SPA associated with a service provider; (“A system and method convert monetary value stored as digital currencies and cryptocurrency to cash and other forms of value in real-time within a transactional mobile commerce system using distributed ledger technology and smart contract services.” (Para. 0003)
wherein entering the smart contract comprises: generating the smart contract, on the crypto-currency network, allowing the transfer of a maximum number of tokens from the user’s wallet, allowing the transfer of a first number of tokens to an service provider wallet associated with the service provider, and allowing transfer of a second number of token to a merchant wallet associated with the merchant. (“FIG. 2 shows Settlement Services, which may settle transactions across multiple Currency Wallets 120. For example, the process to load a debit card with funds may take longer than the time available to complete a transaction, in which case, the settlement services may handle completion of the transaction and update appropriate balances after completion of such transaction. In one embodiment, Distributed Reserve Services may provide a pool of funds that allow settlement services to complete a transaction in the absence of sufficient funds in Reserve Account 206.” (Para. 0022); “FIG. 4 shows example transaction steps and communications for real-time conversion and transfer of funds from digital currency account 112 to fiat currency account 110, for the currency wallet 120 of FIG. 1, to provide the spending power 150 for the owner 101 of the currency wallet 120. For example, this conversion facilitates the loading of a stored-value payment instrument (e.g., the debit card account 152 and/or the e-wallet 154) that allows the owner 101 of the currency wallet 120 to easily use their digital currency account 112 in conventional retail or ecommerce transactions.” (Para. 0025); “FIG. 5 shows loading of the debit card account 152 from the fiat currency account 110 funds in the crypto wallet 102 of the owner 101. When the owner of the crypto wallet 102 desires to use their digital currency account 110 at a retail location, they may do so in one of two ways. Where the retail location (e.g., POS terminal, online store etc.) supports use of the digital currency account 112, the owner 101 may transfer funds from the digital currency account 112 of the cyber wallet 102 to complete the transaction. Alternatively, where the retail location does not allow use of digital currency, the owner 101 may move funds from the crypto wallet 102 to a stored value instrument such as the debit card account 152 using a web interface or mobile application. For example, the owner 121 may instruct the monetary conversion system 100 to convert funds from the digital currency account 112(1) (e.g., Bitcoin) into the fiat currency account 110 (e.g., US dollars), and then to move the funds from the fiat currency account 110 to the debit card account 152 and/or the e-wallet 154. All funds in the debit card account can then be used anywhere a credit card or debit card can be used, such as in any ATM around the world. Conversely, funds may also be moved from the debit card account 152 and/or the e-wallet 154 to the crypto wallet 102 and stored in the fiat currency account 110 and/or converted into digital currency and stored in one or more of the digital current accounts 112.” (Para. 0027); “The value of Reserve Account 206 may be a calculated amount, a user-directed amount, or may be determined by other methods. The Spending Limit 202 may be calculated as the value of Transaction Account 204 minus the value of Reserve Account 206. Spending limit 202 is the amount a user has available to use for commerce activities.” (Para. 0021)
receiving, at one or more processors associated with the service provider, from one or processors associated with a merchant, a POS transaction request from the merchant to approve an amount for a transaction; (“FIG. 6 shows real-time loading of debt card account during the flow of an Authorization Transaction from a card network, in an embodiment.” (Para. 0015); “FIG. 6 shows transaction steps for purchasing goods or services in a retail or ecommerce environment through a card network and illustrating real-time (on-the-fly) conversion of funds from a digital currency account 112 within the crypto wallet 102 to load the debit card account 152 with sufficient funds to complete the transaction by the monetary conversion system 100. For example, the owner 101 may authorize automatic use of funds from the digital currency account 112 to top up the debit card account 152 as needed. As shown in FIG. 6, the consumer 602 (e.g., the owner 101) uses 604 a debit card at a POS 606, which sends an authorization transaction 608 to a merchant enquire 610 of the card network. The merchant acquirer 610, in turn, sends an authorization transaction 612 to an account evaluation service 614 which issues a balance inquiry transaction to an external transaction processor 618. In response, the transaction processor 618 returns a balance 620 to the account evaluation service 614.” (Para. 0029-0030)
determining, by the one or more processors associated with the service provider, whether to approve the amount for the transaction based on spending power associated with the user, the spending power calculated as a wallet balance associated with a user minus a card balance associated with the user; (“FIG. 2 shows a system of layered accounts for all users, in an embodiment. FIG. 3 shows a system of layered authentication and distributed identities between components of value representation and stored value, in an embodiment.” (Para. 0011-0012); “FIG. 2 shows a plurality of currency accounts 220(1)-220(N), each associated with a crypto wallet 102. The monetary conversion system 100 uses a multi-layered distributed ledger to create and manage each currency wallet 120. Each currency wallet may include a spending limit 202, a transactional account 204 and a reserve account 206, that collectively support the real-time conversion and transaction of digital currencies 112 to and from fiat currency account 110. For example, where the owner 101 visits a store and makes a purchase, the monetary conversion system 100 may convert funds from one or more digital currencies 112 into the fiat currency account 110 for use at the store. Each currency wallet 120 operates with an independent ledger and maintains a balance as determined interaction with the Intelligent Balance Service 714 (FIG. 7). Given a set of inputs, constraints, and currency values, the Intelligent Balance Service 714 provides a spendable balance which may be represented in fiat currency. In one embodiment, a Reserve Account 206 is used when a person wishes to purchase crypto currency to convert to fiat currency. The value of Reserve Account 206 may be a calculated amount, a user-directed amount, or may be determined by other methods. The Spending Limit 202 may be calculated as the value of Transaction Account 204 minus the value of Reserve Account 206. Spending limit 202 is the amount a user has available to use for commerce activities. FIG. 2 shows Settlement Services, which may settle transactions across multiple Currency Wallets 120. For example, the process to load a debit card with funds may take longer than the time available to complete a transaction, in which case, the settlement services may handle completion of the transaction and update appropriate balances after completion of such transaction. In one embodiment, Distributed Reserve Services may provide a pool of funds that allow settlement services to complete a transaction in the absence of sufficient funds in Reserve Account 206.” (Para. 0021-0022)
approving, utilizing the one or more processors associated with the service provider, the POS transaction request from the merchant based on the determined approval; (“FIG. 7 shows how the Intelligent Balance Service would interact with Service Providers to create a dynamic balance based on value of the different values based on a user's Cybercurrency Wallets, in an embodiment.” (Para. 0016); “Each currency wallet 120 operates with an independent ledger and maintains a balance as determined interaction with the Intelligent Balance Service 714 (FIG. 7). Given a set of inputs, constraints, and currency values, the Intelligent Balance Service 714 provides a spendable balance which may be represented in fiat currency. In one embodiment, a Reserve Account 206 is used when a person wishes to purchase crypto currency to convert to fiat currency. The value of Reserve Account 206 may be a calculated amount, a user-directed amount, or may be determined by other methods. The Spending Limit 202 may be calculated as the value of Transaction Account 204 minus the value of Reserve Account 206. Spending limit 202 is the amount a user has available to use for commerce activities.” (Para. 0021); “FIG. 7 shows example transaction steps for a debit card purchase where the debit card account has insufficient funds and illustrates how an intelligent balance service 714 may interact with a service provider 710 to create Spending Limit 202 based on a current value of digital currency accounts 112 within the crypto wallet 102 of the owner 101. In certain embodiments, the service provider 710 (e.g., an issuing bank) may determine spending limit for a stored value instrument (e.g., the debit card 702) based on a current value of the corresponding crypt wallet 102. The service provider 710 and/or the intelligent balance service 714 may utilize one or more complex algorithms that use volatility and liquidity of digital currencies corresponding to the digital currency accounts 112 in the crypto wallet 102. In the example of FIG. 7, the owner 101 presents a debit card 702 at a POS (e.g., at a POS terminal or at an online retail location) using either a physical card or a mobile wallet service. The POS sends an authorization request 704 to the merchant acquirer 610, which in turn, sends an authorization request 708 to the service provider 710. The service provider 710 then sends an authorization transaction to the intelligent balance server 714 which must be approved by the intelligent balance service 714 before the purchase may be completed.” (Para. 0033-0034))
updating, utilizing the one or more processors, the card balance associated with the user and a merchant account balance, based on approving the amount for the transaction; (“FIG. 6 shows real-time loading of debt card account during the flow of an Authorization Transaction from a card network, in an embodiment.” (Para. 0015); “FIG. 6 shows transaction steps for purchasing goods or services in a retail or ecommerce environment through a card network and illustrating real-time (on-the-fly) conversion of funds from a digital currency account 112 within the crypto wallet 102 to load the debit card account 152 with sufficient funds to complete the transaction by the monetary conversion system 100. For example, the owner 101 may authorize automatic use of funds from the digital currency account 112 to top up the debit card account 152 as needed. As shown in FIG. 6, the consumer 602 (e.g., the owner 101) uses 604 a debit card at a POS 606, which sends an authorization transaction 608 to a merchant enquire 610 of the card network. The merchant acquirer 610, in turn, sends an authorization transaction 612 to an account evaluation service 614 which issues a balance inquiry transaction to an external transaction processor 618. In response, the transaction processor 618 returns a balance 620 to the account evaluation service 614.” (Para. 0029-0030)
. . .; and initiating a token transfer, on the cryptocurrency network, by executing the smart contract. (“FIG. 4 shows example transaction steps and communications for real-time conversion and transfer of funds from digital currency account 112 to fiat currency account 110, for the currency wallet 120 of FIG. 1, to provide the spending power 150 for the owner 101 of the currency wallet 120. For example, this conversion facilitates the loading of a stored-value payment instrument (e.g., the debit card account 152 and/or the e-wallet 154) that allows the owner 101 of the currency wallet 120 to easily use their digital currency account 112 in conventional retail or ecommerce transactions.” (Para. 0025); “FIG. 5 shows loading of the debit card account 152 from the fiat currency account 110 funds in the crypto wallet 102 of the owner 101. When the owner of the crypto wallet 102 desires to use their digital currency account 110 at a retail location, they may do so in one of two ways. Where the retail location (e.g., POS terminal, online store etc.) supports use of the digital currency account 112, the owner 101 may transfer funds from the digital currency account 112 of the cyber wallet 102 to complete the transaction. Alternatively, where the retail location does not allow use of digital currency, the owner 101 may move funds from the crypto wallet 102 to a stored value instrument such as the debit card account 152 using a web interface or mobile application. For example, the owner 121 may instruct the monetary conversion system 100 to convert funds from the digital currency account 112(1) (e.g., Bitcoin) into the fiat currency account 110 (e.g., US dollars), and then to move the funds from the fiat currency account 110 to the debit card account 152 and/or the e-wallet 154. All funds in the debit card account can then be used anywhere a credit card or debit card can be used, such as in any ATM around the world. Conversely, funds may also be moved from the debit card account 152 and/or the e-wallet 154 to the crypto wallet 102 and stored in the fiat currency account 110 and/or converted into digital currency and stored in one or more of the digital current accounts 112.” (Para. 0027); “In a second scenario, shown within dashed outline 670, when the account evaluation service 614 determines that there are insufficient funds in the debit card account 152 to complete the transaction, the account evaluation service 614 checks 630 the balance of the digital currency account 112 and converts funds of the digital currency account 112 to funds in the fiat currency account 110. The account evaluation service 614 then instructs the transaction processor 618 to load 634 the debit card account 152 with funds from the fiat currency account 110 and in response receives a load approve 636 from the transaction processor 618. The account evaluation service 614 then sends an approve authorization 638 to the merchant acquirer 610. In response, the merchant acquirer 610 sends an approve authorization 640 to the POS 606, and the purchase is completed 642. Advantageously, funds from the digital currency account 112 of the crypto wallet 102 are converted and transferred when needed to make the purchase and at the time of the purchase.” (Para. 0032)).
And wherein initiating the token transfer executing the smart contract comprises transferring an amount of tokens from a wallet associated with the user based on the card balance and transferring a second amount of tokens to a merchant wallet associated with the merchant based on the merchant account balance. (“A system and method convert monetary value stored as digital currencies and cryptocurrency to cash and other forms of value in real-time within a transactional mobile commerce system using distributed ledger technology and smart contract services.” (Para. 0003); “In particular, the monetary conversion system 100 may convert at least part of the funds of the digital currency account 112 in real-time (e.g., on the fly) to the fiat currency account 110 to enable purchase of virtual or physical goods and services at point-of-sale terminals. For example, the monetary conversion system 100 may allow the owner 101 to obtain fiat currency cash at an automatic teller machine (ATM) from funds stored within the crypto wallet 102 and converted to funds accessible via one or both of the debit card account 152 and/or the e-wallet 154.” (Para. 0020); “FIG. 2 shows a plurality of currency accounts 220(1)-220(N), each associated with a crypto wallet 102. The monetary conversion system 100 uses a multi-layered distributed ledger to create and manage each currency wallet 120. Each currency wallet may include a spending limit 202, a transactional account 204 and a reserve account 206, that collectively support the real-time conversion and transaction of digital currencies 112 to and from fiat currency account 110. For example, where the owner 101 visits a store and makes a purchase, the monetary conversion system 100 may convert funds from one or more digital currencies 112 into the fiat currency account 110 for use at the store. Each currency wallet 120 operates with an independent ledger and maintains a balance as determined interaction with the Intelligent Balance Service 714 (FIG. 7). Given a set of inputs, constraints, and currency values, the Intelligent Balance Service 714 provides a spendable balance which may be represented in fiat currency. In one embodiment, a Reserve Account 206 is used when a person wishes to purchase crypto currency to convert to fiat currency. The value of Reserve Account 206 may be a calculated amount, a user-directed amount, or may be determined by other methods. The Spending Limit 202 may be calculated as the value of Transaction Account 204 minus the value of Reserve Account 206. Spending limit 202 is the amount a user has available to use for commerce activities.” (Para. 0021); “In the example of FIG. 4, the owner 101 of the currency wallet 120 wishes to make a purchase using digital currency funds (e.g., one of Bitcoin, Ethereum, and BIQ of digital currencies 112(1)-112(3), respectively). The owner 101 provides an account ID 402, identifying the currency wallet 120 corresponding to the crypto wallet 102 for example, and requests conversion of digital currency account 112 to fiat currency account 110. Accordingly, a conversion request 404 is sent to a digital currency arbitrage service 406 of the monetary conversion system 100. The digital currency arbitrage service 406, based upon the conversion request 404, interacts with at least one digital currency exchange 408 to determine an exchange rate 410 for the digital currency. For example, where the owner 101 wishes to convert bitcoin, the digital currency exchange 408 may deal in bitcoin and provide the exchange rate 412 based upon current market exchange values for Bitcoin. The digital currency arbitrage service 406 then requests 414 funds from the reserve account 206 to purchase the digital currency, and receives funds to purchase 416 from the reserve account 206. The digital currency arbitrage service 406 then purchases 418 the digital currency from the digital currency exchange 408 and the digital currency ledger 409 is updated 420 and confirmed 422. When the digital currency exchange 408 confirms that the purchase is successful 424, the digital currency arbitrage service 406 places 424 the purchased digital currency into the digital currency account 112 and receives confirmation 426. The digital currency arbitrage service 406 then initiate an exchange of digital currency 428 with the digital currency exchange 408 and received a confirmation of exchange complete 430. The digital currency arbitrage service 406 then updates 432 the fiat currency account 110 with the converted amount and received a fiat account change 434 confirmation. The digital currency arbitrage service 406 may then indicates that the fiat amount is available 436. Accordingly, funds from the digital currency account 112 are converted into fiat currency account 110 and may be loaded into the debit card account 152 and/or the e-wallet 154. FIG. 5 shows loading of the debit card account 152 from the fiat currency account 110 funds in the crypto wallet 102 of the owner 101. When the owner of the crypto wallet 102 desires to use their digital currency account 110 at a retail location, they may do so in one of two ways. Where the retail location (e.g., POS terminal, online store etc.) supports use of the digital currency account 112, the owner 101 may transfer funds from the digital currency account 112 of the cyber wallet 102 to complete the transaction. Alternatively, where the retail location does not allow use of digital currency, the owner 101 may move funds from the crypto wallet 102 to a stored value instrument such as the debit card account 152 using a web interface or mobile application. For example, the owner 121 may instruct the monetary conversion system 100 to convert funds from the digital currency account 112(1) (e.g., Bitcoin) into the fiat currency account 110 (e.g., US dollars), and then to move the funds from the fiat currency account 110 to the debit card account 152 and/or the e-wallet 154. All funds in the debit card account can then be used anywhere a credit card or debit card can be used, such as in any ATM around the world. Conversely, funds may also be moved from the debit card account 152 and/or the e-wallet 154 to the crypto wallet 102 and stored in the fiat currency account 110 and/or converted into digital currency and stored in one or more of the digital current accounts 112.” (Para. 0026-0027).
wherein initiating the token transfer executing the smart contract further comprises transferring a third amount of tokens to a service provider account.; (“In the example of FIG. 4, the owner 101 of the currency wallet 120 wishes to make a purchase using digital currency funds (e.g., one of Bitcoin, Ethereum, and BIQ of digital currencies 112(1)-112(3), respectively). The owner 101 provides an account ID 402, identifying the currency wallet 120 corresponding to the crypto wallet 102 for example, and requests conversion of digital currency account 112 to fiat currency account 110. Accordingly, a conversion request 404 is sent to a digital currency arbitrage service 406 of the monetary conversion system 100. The digital currency arbitrage service 406, based upon the conversion request 404, interacts with at least one digital currency exchange 408 to determine an exchange rate 410 for the digital currency. For example, where the owner 101 wishes to convert bitcoin, the digital currency exchange 408 may deal in bitcoin and provide the exchange rate 412 based upon current market exchange values for Bitcoin. The digital currency arbitrage service 406 then requests 414 funds from the reserve account 206 to purchase the digital currency, and receives funds to purchase 416 from the reserve account 206. The digital currency arbitrage service 406 then purchases 418 the digital currency from the digital currency exchange 408 and the digital currency ledger 409 is updated 420 and confirmed 422. When the digital currency exchange 408 confirms that the purchase is successful 424, the digital currency arbitrage service 406 places 424 the purchased digital currency into the digital currency account 112 and receives confirmation 426. The digital currency arbitrage service 406 then initiate an exchange of digital currency 428 with the digital currency exchange 408 and received a confirmation of exchange complete 430. The digital currency arbitrage service 406 then updates 432 the fiat currency account 110 with the converted amount and received a fiat account change 434 confirmation. The digital currency arbitrage service 406 may then indicates that the fiat amount is available 436. Accordingly, funds from the digital currency account 112 are converted into fiat currency account 110 and may be loaded into the debit card account 152 and/or the e-wallet 154.” (Para. 0026); “The intelligent balance service 714 may first send a balance inquiry 716 to the debit card account 152 and receive a balance 718 is response. When the indicated balance 718 is sufficient for the transaction, the intelligent balance service 714 sends a return authorization amount 740 to the service provider 710, which sends an approve authorization 742 to the merchant acquirer 610, which in turn sends an approve authorization 744 to the POS. When the indicated balance 718 is insufficient for the transaction, the intelligent balance service 714 requests 720 (e.g., from the monetary conversion system 100) a determined value of the crypto wallet 102, and receives in response, and receives, in response, a value of accounts 722 (e.g., a current value of each digital currency account 112 in the crypto wallet 102). The intelligent balance service 714 may then select an account 724 (e.g., an appropriate one of the digital currency accounts 12(1)-(3)), apply a cap limit 730 (e.g., set the approval amount to a limit when the funds exceed the limit), exchange cryptocurrency 726 (e.g., funds from the selected digital currency account 112), apply fees 728 (e.g., per transaction fees, currency conversion fees, gas fees or other fees) and then move 732 the funds to the debit card account 152, receiving a funds available indication 734 when the funds are available in the debit card account 152. The intelligent balance service 714 sends a return authorization amount 740 to the service provider 710, which sends an approve authorization 742 to the merchant acquirer 610, which in turn sends an approve authorization 744 to the POS.” (Para. 0035); “Accordingly, the monetary conversion system 100 transfers funds from the crypto wallet 102 to automatically load the debit card account 152 with the appropriate funds in the fiat currency as part of the final authorization and approval process for the POS transaction.” (Para. 0036))
Ricotta does not disclose:
“forwarding a new on-chain transaction request to the crypto-currency network, from the one or more processors associated with the Service Provider, to execute the smart contract” (claim 1).
However, as per Claim 1, Duris in the analogous art of secured cryptocurrency transactions between parties, teaches: “forwarding a new transaction request to the crypto-currency network, from the one or more processors associated with the Service Provider, to execute the smart contract”. (See “Once a liquidity provider 112 receives a transaction request message, the liquidity provider 112 can determine if it wants to authorize the requested blockchain transaction. For instance, the liquidity provider 112 can confirm the desired transaction amount and its availability of the requested cryptocurrency and authorize the transaction if suitable. In some cases, the liquidity provider 112 can validate the identities of one or more of the entities involved in the requested transaction, such as discussed in more detail below. If authorized, the liquidity provider 112 can generate a smart contract to be added to the blockchain.” (Para. 0027); “The smart contract can be configured to, upon execution, add a new blockchain transaction to the blockchain for transfer of the requested transaction amount from a blockchain wallet associated with the liquidity provider 112 to a desired blockchain wallet of the merchant system 108.” (Para. 0027); “The liquidity provider 112 can electronically transmit the smart contract to a blockchain node 106 in the blockchain network 104, which can confirm the smart contract and include the smart contract in a new block that is generated, validated, and added to the blockchain.” (Para. 0028).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Ricotta with the technique of Duris to include a forwarded new transaction request from a service provider processor to a blockchain network for execution of a smart contract. Therefore, the incentives of ensuring secure, automated settlement of approved transactions using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 4, Ricotta teaches:
The method of claim 1, further comprising updating a ledger on the crypto-currency network. (“FIG. 2 shows Settlement Services, which may settle transactions across multiple Currency Wallets 120. For example, the process to load a debit card with funds may take longer than the time available to complete a transaction, in which case, the settlement services may handle completion of the transaction and update appropriate balances after completion of such transaction. In one embodiment, Distributed Reserve Services may provide a pool of funds that allow settlement services to complete a transaction in the absence of sufficient funds in Reserve Account 206.” (Para. 0022); “In the example of FIG. 4, the owner 101 of the currency wallet 120 wishes to make a purchase using digital currency funds (e.g., one of Bitcoin, Ethereum, and BIQ of digital currencies 112(1)-112(3), respectively). The owner 101 provides an account ID 402, identifying the currency wallet 120 corresponding to the crypto wallet 102 for example, and requests conversion of digital currency account 112 to fiat currency account 110. Accordingly, a conversion request 404 is sent to a digital currency arbitrage service 406 of the monetary conversion system 100. The digital currency arbitrage service 406, based upon the conversion request 404, interacts with at least one digital currency exchange 408 to determine an exchange rate 410 for the digital currency. For example, where the owner 101 wishes to convert bitcoin, the digital currency exchange 408 may deal in bitcoin and provide the exchange rate 412 based upon current market exchange values for Bitcoin. The digital currency arbitrage service 406 then requests 414 funds from the reserve account 206 to purchase the digital currency, and receives funds to purchase 416 from the reserve account 206. The digital currency arbitrage service 406 then purchases 418 the digital currency from the digital currency exchange 408 and the digital currency ledger 409 is updated 420 and confirmed 422. When the digital currency exchange 408 confirms that the purchase is successful 424, the digital currency arbitrage service 406 places 424 the purchased digital currency into the digital currency account 112 and receives confirmation 426. The digital currency arbitrage service 406 then initiate an exchange of digital currency 428 with the digital currency exchange 408 and received a confirmation of exchange complete 430. The digital currency arbitrage service 406 then updates 432 the fiat currency account 110 with the converted amount and received a fiat account change 434 confirmation. The digital currency arbitrage service 406 may then indicates that the fiat amount is available 436. Accordingly, funds from the digital currency account 112 are converted into fiat currency account 110 and may be loaded into the debit card account 152 and/or the e-wallet 154.” (Para. 0026)
As per Claim 6, Ricotta teaches:
The method of claim 5, wherein generating the smart contract comprises: accessing terms of the agreement of the smart contract, utilizing a user device; inputting acquiescence to the agreement utilizing the user device; and recording the smart contract on a ledger on the crypto-currency network.; (“FIG. 3 is a schematic diagram showing layered encryption and distributed ID management that may be implemented by the monetary conversion system 100 of FIG. 1. FIGS. 1 through 3 are best viewed together with the following description: Through layered encryption and distributed ID management, value representation (e.g., debit card account 152 and/or e-wallet 154) and stored value (e.g., values in transaction accounts 204 and reserve accounts 206) are balanced and maintained. Account identification and authorization is managed through device and account authorization contained in the currency wallet 120 and that are embedded in the multi-layered distributed ledger implemented by the security and access services 104. Each e-wallet 154 and currency wallet 120 has a unique anonymous public and private key. The public key provides the basis for the underlying ID for currency accounts 110, 112, 220. The methods depicted in FIG. 3 provide extended account management features capable of securing, storing, and protecting identifiable attributes such as name, address, phone, email, and other attributes for each of the currency wallets 120 (e.g., the account of the owner 101) to be fully compliant with local regulatory requirements.” (Para. 0024); “FIG. 6 shows transaction steps for purchasing goods or services in a retail or ecommerce environment through a card network and illustrating real-time (on-the-fly) conversion of funds from a digital currency account 112 within the crypto wallet 102 to load the debit card account 152 with sufficient funds to complete the transaction by the monetary conversion system 100. For example, the owner 101 may authorize automatic use of funds from the digital currency account 112 to top up the debit card account 152 as needed. As shown in FIG. 6, the consumer 602 (e.g., the owner 101) uses 604 a debit card at a POS 606, which sends an authorization transaction 608 to a merchant enquire 610 of the card network. The merchant acquirer 610, in turn, sends an authorization transaction 612 to an account evaluation service 614 which issues a balance inquiry transaction to an external transaction processor 618. In response, the transaction processor 618 returns a balance 620 to the account evaluation service 614.” (Para. 0029-0030); “In a first scenario, shown within dashed outline 660, when the account evaluation service 614 determines that there are sufficient funds in the debit card account 152 to complete the transaction, the account evaluation service 614 sends an approve authorization 622 to the merchant acquirer 610. The merchant acquirer 610 then sends an approve authorization 624 to the POS 606, and the purchase is completed 626.” (Para. 0031))
As per Claim 7, Ricotta teaches:
The method of claim 1, wherein the card balance comprises a cumulative total of unsettled transactions associated with the user. (“FIG. 4 shows example transaction steps and communications for real-time conversion and transfer of funds from digital currency account 112 to fiat currency account 110, for the currency wallet 120 of FIG. 1, to provide the spending power 150 for the owner 101 of the currency wallet 120. For example, this conversion facilitates the loading of a stored-value payment instrument (e.g., the debit card account 152 and/or the e-wallet 154) that allows the owner 101 of the currency wallet 120 to easily use their digital currency account 112 in conventional retail or ecommerce transactions.” (Para. 0025); “As disclosed herein, a monetary conversion system 100 may exchange funds on the fly (e.g., in real-time) between the digital currency accounts 112 and the fiat currency accounts 110 to provide the owner 101 of the crypto wallet 102 with spending power 150 based upon funds stored in the crypto wallet 102. Accordingly, the monetary conversion system 100 may use a currency wallet 120 to associate and connect the crypto wallet 102 with one or more financial instruments, such as the debit card account 152 and/or the e-wallet 154. The monetary conversion system 100 uses security and access services 104 associated with the crypto wallet 102, and implements a layered distributed ledger (described in detail below) for the currency wallet 120, to exchange currencies within currency accounts 110, 112 contained within the crypto wallet 102 to provide the spending power 150 to the owner 101 of the crypto wallet 102. A value of the crypto wallet 102 may be computed by the monetary conversion system 100 based on current market values of each of the currencies held within the crypto wallet 102.” (Para. 0018-0019); “FIG. 7 shows how the Intelligent Balance Service would interact with Service Providers to create a dynamic balance based on value of the different values based on a user's Cybercurrency Wallets, in an embodiment.” (Para. 0016); “FIG. 7 shows example transaction steps for a debit card purchase where the debit card account has insufficient funds and illustrates how an intelligent balance service 714 may interact with a service provider 710 to create Spending Limit 202 based on a current value of digital currency accounts 112 within the crypto wallet 102 of the owner 101. In certain embodiments, the service provider 710 (e.g., an issuing bank) may determine spending limit for a stored value instrument (e.g., the debit card 702) based on a current value of the corresponding crypt wallet 102. The service provider 710 and/or the intelligent balance service 714 may utilize one or more complex algorithms that use volatility and liquidity of digital currencies corresponding to the digital currency accounts 112 in the crypto wallet 102.” (Para. 0033))
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20230394471A1 (Saad), discussing “The present disclosure includes methods and systems for providing a framework for facilitating time-sensitive cryptocurrency transactions for users. As discussed herein, due to the distributed and decentralized nature of blockchains, certain verification processes (e.g., a proof-of-work process, a proof-of-stake process, etc.) are in place to ensure that the amount of cryptocurrency being spent in association with the transaction is in possession of a sender of the transaction at the time of the transaction, and that the amount has not been spent by the sender prior to the transaction, thereby maintaining the integrity of the cryptocurrency system. Such a verification process, depending on the implementations by the cryptocurrency system, may take a long time to complete (e.g., several hours, several days, etc.). The processing requirement may prevent certain users from performing certain time-sensitive transactions using cryptocurrency. These time-sensitive transactions usually do not present a challenge for users who conduct the transactions using fiat currency, as systems are in place to process transactions in fiat currency efficiently, in real time (e.g., in a matter of seconds). Consider an example in which a purchase of an item (as used herein, items can include products, services, access, and content) is associated with a time constraint (e.g., an incentive for purchasing the item expiring in 10 minutes, making a bid in an auction, etc.). Such a purchase can typically be made without any challenges in fiat currencies, as transaction processing systems can process a purchase transaction in a fiat currency within a short period of time (e.g., less than a second, a few seconds, etc.). However, with the increased prevalent use of cryptocurrency, a user may wish to use funds in a cryptocurrency (e.g., Bitcoins, Ether, etc.) to fund at least a portion of the purchase. Unfortunately, the user may not be able to perform the purchase transaction in this scenario when the time requirement for processing a cryptocurrency transaction in the cryptocurrency exceeds the time constraint (e.g., takes longer than 10 minutes to process the cryptocurrency transaction).” (Para. 0009-0010).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights