DETAILED ACTION
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 October 14, 2025 has been entered.
Status of the Claims
1. This action is in reply to the Request for Continued Examination dated October 14, 2025.
2. Claims 1-20 are pending and have been examined.
3. Claims 1, 4, 11, and 14 have been amended.
4. Applicant filed a specification amendment as to paragraph 45 of their specification on October 14, 2025. This specification amendment has been accepted.
Notice of Pre-AIA or AIA Status
5. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
6. Claim 1 is objected to because of the following informalities:
- Claim 1 recites in part in the last limitation “generate, a third new block on the blockchain…”. Examiner assumes that Applicant is referring to the first blockchain previously recited, however the antecedent basis is imperfect and requires correction.
Appropriate correction is required.
Claim Interpretation - Broadest Reasonable Interpretation
7. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e. the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined.
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. see MPEP §2013(I)(C).
Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following language is interpreted as not further limiting the scope of the claimed invention.
In the instant case, the following italicized limitations are expressing the intended result or use of a process step positively recited and are not being given additional weight:
As in Claim 1:
generate, based on a user input to create a payment token, a payment token, wherein the payment token comprises a virtual card number and configured to receive funds via an associated alias;
generate, based on generation of the payment token, a first new block corresponding to the payment token in a first blockchain associated with an account associated with the payment token of the plurality of blockchains, wherein the first blockchain stores an immutable record of activities with the payment token
configure, based on user input received from a user device, the payment token, wherein a payment token configuration defines use cases for the payment token and the use cases comprise use as a primary account and as a backup to a second account to be used when the primary account is unavailable;
generate, a third new block on the blockchain and based on success or failure of the payment transaction, wherein the third new block comprises a record of payment token activity comprising one of a first record of successful completion of the electronic payment transaction or a second record of a failed payment transaction.
As in Claim 11:
generating, triggered by the payment token account platform and by a distributed ledger computing system based on generation of the payment token, a first new block corresponding to the payment token in a blockchain of a distributed ledger computing system, wherein the blockchain is associated with an account associated with the payment token, and wherein the blockchain stores an immutable record of activities with the payment token;
configuring, based on user input received from a user device, the payment token, wherein a payment token configuration defines use cases for the payment token and the use cases comprise use as a primary account and as a backup to a second account to be used when the primary account is unavailable;
generating, a third new block on the blockchain and based on success or failure of the payment transaction, wherein the third new block comprises a record of payment token activity comprising one of a first record of successful completion of the electronic payment transaction or a second record of a failed payment transaction.
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.
8. Claims 1-20 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.
Regarding Claim 1, the claim recites the following limitations that are not supported by the specification as currently claimed:
a distributed ledger computing system facilitating operations of a plurality of blockchains;
generate, based on the generation of the payment token, a first new block corresponding to the payment token in a first blockchain associated with an account associated with the payment token of the plurality of blockchains, wherein the first blockchain stores an immutable record of activities with the payment token;
generate, based on the payment token configuration, a second new block in the first blockchain corresponding to the payment token configuration;
initiate payment, via the payment token based on a condition causing access to the primary account to fail, to a deposit account associated with the electronic payment transaction, based on a payment token configuration;
Regarding Claim 11, the claim recites the following limitations that are not supported by the specification as currently claimed:
initiating payment, via the payment token based on a condition causing access to the primary account to be unavailable, to a deposit account associated with the electronic payment transaction, based on the payment token configuration;
Regarding Claim 1, the claim recites a plurality of blockchains. This is broader than the specification discloses. The specification refers to a blockchain (e.g., an initial block of a blockchain or a sub-chain of a blockchain). (See at least Applicant Spec para 51 as seen below) The recitations are thus broader than the specification discloses.
The recitation of a first blockchain is also broader than the specification discloses. The specification indicates that the payment token account may be associated with a first block in a block chain and that each payment token associated with the account may be associated with a different additional block added to the blockchain. (See Applicant Spec para 41, below)
Applicant’s Specification discloses the following:
“Various aspects of the disclosure relate to creation, management, and use of electronic payment tokens to facilitate coordination of payments for products and/or services. A payment token account system may facilitate creation of a payment token account and an associated payment token to electronically receive deposit from one or more sources and to complete an electronic payment transaction. Each payment token may be separately enabled and disabled and may be associated as a backup to another payment account to ensure a payment transaction may be completed when a payment network associated with the payment account is down or otherwise unavailable. Illustrative payment token functionality supported by a payment token account computing system may include generating, based on a user request, a payment token, configuring, based on user input received from a user device, the payment token, wherein a payment token configuration defines use cases for the payment token, receiving, via a network and from a deposit computing system, an electronic funds deposit request, accepting, based on the configuration, the electronic funds deposit, receiving, via a network and from the payment computing system, a payment request associated with the electronic payment transaction, initiating payment, via the payment token, to a deposit account associated with the electronic payment transaction, based on the payment token configuration, and sending, via the network and to the payment computing system, confirmation of completion of the electronic payment transaction. In some cases, the payment token account computing system may issue an error or disable a payment token in response to invalid activity requests based on the configuration, insufficient funds, use before deposits have been made, and/or the like.” (See Applicant Spec para 19 – emphasis added)
“As discussed above, a user may create an electronic token account that may be associated with a token (e.g., a virtual card number) with the token requestor. In some cases, the token requestor may be a retailer, a restaurant, a vendor, and/or the like. The token account may be configured to receive funds via an associated alias (e.g., a phone number, a credit card, funds deposit via an automated teller machine (ATM), and the like). The associated customer, or other parties, may deposit funds into the token account via the associated alias. A user interface may be available to the user to facilitate configuration of the token account, such as associating a primary account (e.g., a credit card account, a debit account, or the like) and/or giving an ability to enable the token account (e.g., “turn on), disable the token account (e.g., “turn off”), configure the token account for backup use only (e.g., use of the token account when the associated primary account is unavailable), or backup only the use of token account. Once configured, the token account may only allow funds to be debited when the token account is enabled. In some cases, such as when the token account is configured as a backup to the primary account, the token account may be debited when a payment network is unavailable (e.g., when an issuing bank network associated with the primary account, such as a credit card, is not reachable). Additionally, a reporting engine may notify the use when a status of the token account has changed and/or an action has occurred, such as enabling the account, disabling the account, depositing funds into the account, withdrawing funds from the account, and/or the like. In some cases, the token account may be incorporated with a distributed ledger (e.g., a blockchain computing system) to provide additional security and immutability, such as to provide traceability of use of the payment token account (e.g., depositing of funds, payments made, configuration changes, and the like).” (See Applicant Spec para 20 – emphasis added)
“FIG. 2 shows an illustrative process 200 for creation and management of payment token accounts, with one or more aspects described herein. For example, the payment token account computing system 104 may be triggered to create a payment token account for a particular user based on a triggering input, such as one received via a user interface screen presented at a user device, at 210. The user input causes the payment token account computing system 104 to generate a payment token account and one or more payment tokens associated with that account. In some cases, the payment token account computing system 104 may associate the payment token account and/or one or more of the payment tokens to a distributed ledger computing system, such as by generating one or more blocks in a blockchain. In some cases, transactions associated with a payment token may be added as a block to the main blockchain or may be added as part of a sub-chain off the main blockchain.” (See Applicant Spec para 41 – emphasis added)
“At 220, the payment token account computing system 104 may associate a created payment token to one or more payment accounts. For example, the payment token may be associated with a newly created payment account (e.g., one-time account, a multi-use account) that may be used to facilitate funds transfer transactions associated with payments from the payment token account to a deposit account associated with the vendor. In some cases, the payment token may be associated with an existing or newly created electronic wallet. In some cases, the payment token account may be associated with an existing payment method (e.g., a debit card, a credit card) to be used as a failsafe backup to complete payments when a financial transaction network (e.g., a banking computing system, a credit card processing system and/or the like) is unavailable or otherwise inactive. As such, the payment token may be used to complete a transaction when a portion of credit card processing network is unavailable so that the payment transaction would otherwise fail.” (See Applicant Spec para 43 – emphasis added)
“At 230, the payment token account computing system 104 may cause a user interface to be presented at a user screen of a user device to allow the user to configure the payment token account and/or one or more payment tokens associated with the account. For example, the user interface may solicit user input to configure each payment token associated with the payment token account. For example, the user may enable use of the payment token, disable use of the payment token and/or limit use of the payment token to provide the failsafe payment functionality for the associated payment account. In some cases, the payment token account computing system 104 may configure the payment toke[n] as a single use token or a multi-use token, where the single use token may be used for a single or otherwise specified transaction (e.g., a purchase) and the multi-use token may be reused in multiple payment transaction.” (See Applicant Spec para 44 – emphasis added)
“FIG. 3 shows an illustrative computing system 300 incorporating a payment token account computing system in accordance with one or more aspects described herein. The illustrative computing system may include one or more user devices 310 (e.g., user devices 110), an authentication system 350, a payment token system 320, an account computing system 330, a vendor computing system 340, and/or optionally, a distributed ledger computing system 360. The payment token system 320 may include one or more token accounts 322 (each including one or more payment tokens), a configuration data repository 325, a user interface engine 324, a reporting engine 326, and/or a token management engine 328.” (See Applicant Spec para 47 – emphasis added)
“As mentioned, each token account 322 may include one or more payment tokens. Each token account may be associated with a user, or a group of users. In some cases, the payment token accounts 322 may be created as a one-time use token account, such as to facilitate payment of a common purchase (e.g., an activity) to be paid for by funds pooled from multiple individuals and/or accounts. In some cases, an individual token account associated to a single user may be configured to solicit and receive funds from multiple sources. Configurations associated with each of the token accounts 322 may stored in the configuration data repository 325 and may include an enablement flag (enabled/disabled), a use flag (single use, multi-use), an expiration date defining a time period during which the payment token is enabled, disabled and/or valid, a creation date, owner information, depositor information, allowed user information, allowed use information (e.g., purchases only, account backup only, and the like), a list of allowable users, a list of allowable depositors, and the like.” (See Applicant Spec para 49)
“The account computing system 330 may include one or more different computing systems of the application computing systems 108 of one or more financial institutions. For example, the user accounts 334a-n may be a banking account (e.g., a checking account, a savings account), a brokerage account, a credit card account computing system, a debit card account, and/or other account associated with online activities that require payment. The account computing system’s functionalities may be leveraged to facilitate deposits to and/or seek payments from the token accounts 322. The vendor computing system 340 may include a transaction computing system 342 used to initiate an electronic transaction seeking payment for a product or service and from one or more token accounts 322. The distributed ledger computing system 360 optionally may be used to provide traceability, immutability, and protection from improper use through the processes discussed above, such as by associating a blockchain (e.g., an initial block of a blockchain or a sub-chain of a blockchain) with a payment token account and/or a payment token, with subsequently added blocks being associated with configuration activities, deposit activities, payment activities, reporting activities (e.g., report generation, view requests, and the like), improper activity identifications, and the like.” (See Applicant Spec para 51 – emphasis added)
Further, in reference to Claims 1 and 11, the references to “a condition causing access to the primary account to fail…” and “a condition causing access to the primary account to be unavailable…” are broader than the specification discloses. The recitation of “a condition” could include any potential reason. Further, the reference to unavailable, seems to be as to the payment network being down or unavailable or could be when the account itself is unavailable and the payment transaction would otherwise fail. (See Applicant Spec paras 19-20, 43 above) Applicant is encouraged to ensure that the recitations are aligned with the specification.
Dependent claims 2-10 and 12-20 are further rejected as based upon a rejected base claim. Appropriate correction is required.
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.
9. Claims 1-20 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 “configure, based on user input received from a user device, the payment token, wherein a payment token configuration defines use cases for the payment token and the use cases comprise use as a primary account and as a backup to a second account to be used when the primary account is unavailable” .
As amended, based on this limitation, the user has configured the payment token to be used as a primary account and as the backup to a second account if the primary account is unavailable.
By this recitation, the payment token is used as the primary account. If the primary account is unavailable, that would mean that the payment token being used as the primary account is unavailable. If the payment token being used as the primary account is unavailable, how could it be used as the backup to a second account? The recitation is written in a tautological manner that does not make sense.
Based on the disclosure of the specification, it appears that the payment token account may be configured as a backup to the primary account when the primary account is unavailable or otherwise inactive. (See Applicant Spec paras 6, 19-20)
However, when the “initiate payment…” limitation is recited, the primary account has failed. The configuration as claimed, does not provide for a failsafe for the primary account, rather only provides a failsafe for the secondary account. As recited, as there is a failure of the primary account, there is no available payment token to be used for payment. Presumably, as the system recited is executing instructions presented as method steps, the process would stop, and would not even get to payment confirmation as claimed. That being the case, there is no ability to have a successful completion of the electronic payment transaction as claimed in the penultimate limitation and further no disabling of the payment token as the process has already stopped.
As such, there are some issues with the process that is being disclosed as amended. Applicant is requested to amend and clarify the process that they intend to claim within the bounds of the specification.
Claim 11 recites a substantially similar issue that is similarly rejected.
Substantially similar Claims 8 and 18 recite “wherein the payment account is a credit card, where configuration specifies that the payment token is used for payments when a credit card network is unavailable.” There is insufficient antecedent basis for this limitation in the claim. There is no previous recitation of a payment account in the claims from which Claims 8 and 18 depend. Further, the limitations are disjointed, discussing the payment account, which was not previously disclosed and connecting it to configuration, which is be applied to the payment token configuration. It is unclear as presented. It appears that perhaps Applicant intends for the primary account to be identified as a credit card, but this is speculation on the part of Examiner and not clearly identified material, especially in view of the issues (above) surrounding how the payment token configuration is presented.
Dependent claims 2-10 and 12-20 are further rejected as based as dependent on a rejected base claim.
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.
10. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 1 recites a system. Claim 11 recites a method.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 recites the abstract idea of initiating and confirming a payment transaction. The idea is described by the following limitations:
generate, based on a user request to create a payment token, a payment token, wherein the payment token comprises a virtual card number and configured to receive funds via an associated alias;
generate, based on generation of the payment token, corresponding to the payment token associated with an account associated with the payment token,
configure, based on a user input, the payment token, wherein a payment token configuration defines use cases for the payment token and the use cases comprise use as a primary account and as a backup to a second account to be used when the primary account is unavailable;
generate, based on the payment token configuration, corresponding to the payment token configuration;
receive a funds deposit request;
accept, based on the configuration, the funds deposit to the account associated with the payment token;
receive a payment request associated with the payment transaction;
initiate payment, via the payment token based on a condition causing access to the primary account to fail, to a deposit account associated with the payment transaction, based on a payment token configuration; and
send, based on successful completion of the payment transaction, confirmation of completion of the payment transaction; and
disable, based on the configuration retrieved from a configuration record and based on a determination that the payment transaction failed due to the configuration identifying an invalid activity request, the payment token; and
generate, based on success or failure of the payment transaction, wherein a record of payment token activity comprising one of a first record of successful completion of the payment transaction or a second record of a failed payment transaction.
Claim 11 recites the abstract idea of initiating and confirming a payment transaction. The idea is described by the following limitations:
generating, based on a user request received initiating a payment transaction, a payment token;
generating, based on generation of the payment token, associated with an account associated with the payment token;
configuring, based on user input, the payment token, wherein a payment token configuration defines use cases for the payment token and the use cases comprise use as a primary account and as a backup to a second account to be used when the primary account is unavailable;
receiving a funds deposit request;
accepting based on the configuration, the funds deposit to the account associated with the payment token;
receiving a payment request associated with a payment transaction received from a vendor;
initiating payment, via the payment token based on a condition causing access to the primary account to be unavailable, to a deposit account associated with the payment transaction, based on the payment token configuration; and
sending confirmation of completion of the payment transaction based on successful completion of the payment transaction; and
disabling, based on the configuration retrieved from a configuration record and based on a determination that the payment transaction failed due to the configuration identifying an invalid activity request, the payment token; and
generating, based on success or failure of the payment transaction, wherein a record of payment token activity comprising one of a first record of successful completion of the payment transaction or a second record of a failed payment transaction.
The abstract ideas describe fundamental economic principles or practices; commercial interactions; marketing or sales activities or behaviors; business relations and/or managing personal behavior or relationships or interactions between people. The series of steps recited are thus grouped as certain methods of organizing human activity which is an abstract idea.
As to certain methods of organizing activity, the steps involve managing personal behavior or relationships or interactions between people, fundamental economic principles or practices, commercial interactions and/or business relations (as seen above).
In the case of the instant independent claims, the limitations are receiving and sending data that a user is inputting and defining, using generic computer technology to generate, configure, receive, accept and send data to initiate and confirm completion of a payment transaction. (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
Claims 1 and 11 do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 1 recites a payment computing system, a distributed ledger computing system facilitating operations of a plurality of blockchains, a payment token account platform comprising at least one processor and non-transitory memory storing computer-readable instructions, a first new block, a first blockchain, wherein the first blockchain stores an immutable record of activities with the payment token, a user device, a second new block in the first blockchain, a network, a deposit computing system, a configuration data store, and a third new block on the blockchain.
Claim 11 recites a payment token account platform, a payment computing system, a distributed ledger computing system, a first new block, a blockchain of a distributed ledger computing system and wherein the blockchain stores an immutable record of activities with the payment token, a user device, a network, a deposit computing system, an identified network error, a vendor transaction computing system, a configuration data store, and a third new block on the blockchain.
The claims recite a payment computing system, a payment token account platform comprising at least one processor and non-transitory memory storing computer-readable instructions, a user device, a network, a deposit computing system, a first new block, a first blockchain, wherein the first blockchain stores an immutable record of activities, a second new block in the first blockchain, a network, a deposit computing system, a configuration data store, a third new block on the blockchain, a payment token account platform, a distributed ledger computing system, a configuration data store, a third new block on the blockchain and a vendor transaction computing system which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1 and 11 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network (Symantec, TLI, OIP Techs – MPEP 2106.05(d)(II); storing and retrieving information in memory (Versata, OIP Techs – MPEP 2106.05(d)(II) and electronically scanning or extracting data (Content Extraction – MPEP 2106.05(d)(II) – all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“Computer machines” can include one or more: general-purpose or special-purpose network-accessible administrative computers, clusters, computing devices, computing platforms, desktop computers, distributed systems, enterprise computers, laptop or notebook computers, primary node computers, nodes, personal computers, portable electronic devices, servers, node computers, smart devices, tablets, and/or workstations, which have one or more microprocessors or executors for executing or accessing the computer-executable software and data. References to computer machines and names of devices within this definition are used interchangeably in this specification and are not considered limiting or exclusive to only a specific type of device. Instead, references in this disclosure to computer machines and the like are to be interpreted broadly as understood by skilled artisans. Further, as used in this specification, computer machines also include all hardware and components typically contained therein such as, for example, processors, executors, cores, volatile and non-volatile memories, communication interfaces, etc.” (See Applicant Spec para 16)
“FIG. 1A shows an illustrative computing environment 100 for creation, use, and management of payment token accounts, in accordance with one or more arrangements. The computing environment 100 may comprise one or more devices (e.g., computer systems, communication devices, and the like). The computing environment 100 may comprise, for example, a payment token account computing system 104, one or more application computing system 108, and/or one or more database(s) 116. The one or more of the devices and/or systems, may be linked over a private network 125 associated with an enterprise organization (e.g., a financial institution, a business organization, an educational institution, a governmental organization and the like). The computing environment 100 may additionally comprise a client computing system 120, a distributed ledger computing system 124, and one or more user devices 110 connected, via a public network 130, to the devices in the private network 125. The devices in the computing environment 100 may transmit/exchange/share information via hardware and/or software interfaces using one or more communication protocols. The communication protocols may be any wired communication protocol(s), wireless communication protocol(s), one or more protocols corresponding to one or more layers in the Open Systems Interconnection (OSI) model (e.g., local area network (LAN) protocol, an Institution of Electrical and Electronics Engineers (IEEE) 802.11 WIFI protocol, a 3rd Generation Partnership Project (3GPP) cellular protocol, a hypertext transfer protocol (HTTP), etc.). While FIG. 1A shows the payment token account computing system 104 as being a separate computing system, aspects of the payment token account computing system 104 may be incorporated within one or more different computing systems, such as one or more of the application computing systems 108.” (See Applicant Spec para 21)
“The payment token account computing system 104 may comprise one or more computing devices and/or other computer components (e.g., processors, memories, communication interfaces) configured to perform one or more functions as described herein, such as and creation of a payment token account, management and/or configuration of the payment token account, and use of the payment token account. Further details associated with the architecture of the payment token account computing system 104 are described with reference to FIG. 1B.” (See Applicant Spec para 22)
“The application computing systems 108 and/or the client computing system 120 may comprise one or more computing devices and/or other computer components (e.g., processors, memories, communication interfaces). In addition, application computing systems 108 and/or the client computing system 120 may be configured to host, execute, and/or otherwise provide one or more enterprise applications. In some cases, the application computing systems may host one or more API calls, such as data retrieval and/or initiating processing of specified functionality. In some cases, the client computing system 120 may be configured to communicate with one or more of the application computing systems 108 such as via direct communications and/or API function calls and the services. In an arrangement where the private network 125 is associated with a financial institution (e.g., a bank), the application computing systems 108 may be configured, for example, to host, execute, and/or otherwise provide one or more transaction processing programs, such as an online banking application, fund transfer applications, and/or other programs associated with the financial institution. The client computing system 122 and/or the application systems 108 may comprise various servers and/or databases that store and/or otherwise maintain account information, such as financial account information including account balances, transaction history, account owner information, and/or other information. In addition, application computing systems 108 and/or the client computing system 120 may process and/or otherwise execute transactions on specific accounts based on commands and/or other information received from other computer systems comprising the computing environment 100. In some cases, one or more of the application computing systems 108 and/or the client computing system 120 may be configured, for example, to host, execute, and/or otherwise provide one or more transaction processing programs, such as electronic fund transfer applications, online load processing applications, and/or other programs associated with the financial institution.” (See Applicant Spec para 23)
“The client computing system 120 may comprise one or more computing devices and/or other computer components (e.g., processors, memories, communication interfaces). The client computing system 120 may be configured, for example, to host, execute, and/or otherwise provide one or more transaction processing programs, such as goods ordering applications, electronic fund transfer applications, online loan processing applications, and/or other programs associated with providing a product or service to a user. With reference to the example where the client computing system 120 is for processing an electronic exchange of goods and/or services. The client computing system 120 may be associated with a specific goods purchasing activity, such as purchasing a vehicle, transferring title of real estate, providing payment for a service rendered and may communicate with one or more other platforms within the client computing system 120. In some cases, the client computing system 120 may integrate API calls to request data, initiate functionality, or otherwise communicate with one or more application computing systems 108, such as via the services. For example, the services may be configured to facilitate data communications (e.g., data gathering functions, data writing functions, and the like) between the client computing system 120 and the one or more application computing systems 108.” (See Applicant Spec para 25)
“The user device(s) 110 may be computing devices (e.g., desktop computers, laptop computers) or mobile computing device (e.g., smartphones, tablets) connected to the network 125 and/or the network 130. The user device(s) 110 may be configured to enable the user to access the various functionalities provided by the devices, applications, and/or systems in the network 125, such as via the external network 130.” (See Applicant Spec para 26)
“The database(s) 116 may comprise one or more computer-readable memories storing information that may be used by payment token account computing system 104.
“FIG. 1B shows an illustrative payment token account computing system 104 in accordance with one or more examples described herein. The payment token account computing system 104 may be a stand-alone device and/or may at least be partial integrated with the development computing system 104 may comprise one or more of host processor(s) 155, medium access control (MAC) processor(s) 160, physical layer (PHY) processor(s) 165, transmit/receive (TX/RX) module(s) 170, memory 150, and/or the like. One or more data buses may interconnect host processor(s) 155, MAC processor(s) 160, PHY processor(s) 165, and/or Tx/Rx module(s) 170, and/or memory 150. The payment token account computing system 104 may be implemented using one or more integrated circuits (ICs), software, or a combination thereof, configured to operate as discussed below. The host processor(s) 155, the MAC processor(s) 160, and the PHY processor(s) 165 may be implemented, at least partially, on a single IC or multiple ICs. The memory 150 may be any memory such as random-access memory (RAM), a read-only memory (ROM), a flash memory, or any other electronically readable memory, or the like.” (See Applicant Spec para 37)
“While FIG. 1A illustrates the payment token account computing system 104 and the application computing systems 108, as being separate elements connected in the private network 125, in one or more other arrangements, functions of one or more of the above may be integrated in a single device/network of devices. For example, elements in payment token account computing system 104 (e.g., host processor(s) 155, memory(s) 150, MAC processor(s) 160, PHY processor(s) 165, TX/RX module(s) 170, and/or one or more program/modules stored in memory(s) 150) may share hardware and software elements with and corresponding to, for example, the application computing systems 108.” (See Applicant Spec para 40)
“One or more aspects of the disclosure may be embodied in computer-usable data or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices to perform the operations described herein. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types when executed by one or more processors in a computer or other data processing device. The computer-executable instructions may be stored as computer-readable instructions on a computer-readable medium such as a hard disk, optical disk, removable storage media, solid-state memory, RAM, and the like. The functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the disclosure, and such data structures are contemplated to be within the scope of computer executable instructions and computer-usable data described herein.” (See Applicant Spec para 52)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 1 and 11 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-10 and 12-20 further define the abstract ideas presented in respective Independent Claims 1 and 11 and are further grouped as certain methods of organizing human activities are abstract for the same reasons and basis as presented above.
No further additional hardware components other than those found in the respective independent claims is recited, thus it is concluded that the claim is further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Prior Art of Record Not Currently Applied
Selfridge et al. (US 2017/0091759) (“Selfridge”) - Selfridge discloses a token based financial transaction system whereby individual tokens associated with one or more financial accounts provided to one or more third parties. (See Selfridge Abstract) Embodiments generate a payment token associated with an account of a customer, wherein the payment token is associated with an amount of funds; enable the customer to issue the generated payment token to a third party; receive a transaction request to process a transaction using the token; determine that the transaction request is associated with a transaction having a transaction amount less than or equal to the amount of funds associated with the payment token; and approve and settle the transaction. (See Selfridge Abstract)
Salama et al. (US PG Pub. 2019/0156338) (“Salama”) - Salama discloses methods and systems for providing tokenized transaction accounts. (See Salama Abstract) In an embodiment, a computer-implemented method is provided that may include generating, by one or more processors, a first tokenized transaction account from a first transaction account associated with a first user and may also include providing the first tokenized transaction account to a client device associated with the first user for storage in the client device and use in transactions. (See Salama Abstract) The method may also include updating the first tokenized transaction account to the client device for storage and use in a subsequent transaction. (See Salama Abstract)
Angelos et al. (US PG Pub. 2022/0005023) (“Angelos”) – Angelos discloses his invention as to a method that utilizes a mapping between a blockchain address and a payment credential. (See Angelos Abstract) In some embodiments, the mapping may have been previously generated based on blockchain data (e.g., one or more blockchain tokens) associated with a blockchain address and a previously provided set of conditions. (See Angelos Abstract) An authorization request message is later received that includes the payment credential. (See Angelos Abstract) The blockchain address may be retrieved from the mapping and it may be determined whether the set of conditions have been met. (See Angelos Abstract) One or more operations may be executed based on determining the set of conditions that have been met. (See Angelos Abstract)
Response to Arguments
Applicant's arguments filed October 14, 2025 have been fully considered as further detailed below.
As to the Drawing Objections:
Applicant has submitted a specification amendment as to paragraph 25 dated October 14, 2025. This specification amendment has been accepted. The drawing objection has been accordingly withdrawn as the underlying issue has been resolved. (See Applicant Arguments dated October 14, 2025, page 9)
As to the 112 Rejections:
Applicant’s amendments resolved some of the issues, however some issues remained to be resolved and other issues were created by the amendments made, as fully disclosed in the rejection in chief. (Id. at page 9) The amendments to resolve the 112(d) issues obviated the rejection, which has been withdrawn. (Id.)
As to the 101 Rejections:
Applicant disagrees that the claims are abstract without significantly more as amended. (Id. at pages 9-10) Applicant asserts that the claims, as amended, are not directed to a mental process. (Id. at page 10) Examiner has made no assertion that the claims are directed to a mental process, thus the arguments to the contrary is inapplicable. (Id. at pages 10 and 12)
Applicant then asserts that the claims are directed to a technical process comprising use of electronic payment tokens to facilitate automatic completion of an electronic payment transaction to one of a plurality of accounts and creating an immutable blockchain record of activities associated with the payment account and use of the payment token. (Id. at pages 10-11) Applicant then asserts that even if the amended claim 1 is treated as recited a judicial exception such as a method of organizing human activity or a mental process, it recites features that, when considered as a whole, integrate any such exception into a practical application. (Id. at page 11) Applicant then alleges that their specification, at paragraphs 1 and 6 provides a technical solution to a technical problem.
Examiner is of another opinion. The claims recite a primary account and a second account where the payment token is configured by user input from a user device to be used as a primary account and as a backup to a second account when the primary account is unavailable. As the issues raised under 112 (above) as to the claims disclose, the claim recites that the payment token is the primary account and is a backup to second account when the primary account is unavailable.
The creation and use of a payment token account (e.g., a virtual card number) by a user is not a technical advance from the state of the art at the time of the invention. Having a backup payment source when a primary payment source is unable to be used is also a conventional feature, for instance in the case of overdraft protection.
Applicant then again argues an assertion of mental processes, which again was not presented by Examiner as noted above. The last argument presented by Applicant is that the claims as a whole are eligible. (Id. at page 13) Examiner further disagrees. The further additional elements are recited at a high level and the blockchain is recited as a mechanism to store data. The 101 Rejection is maintained.
As to the 103 Rejections:
There is currently no prior art rejection being applied.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
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, Abhishek Vyas can be reached at 571-270-1836. 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.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 October 31, 2025
Prosecution Insights