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 comp