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 December 5, 2025 has been entered.
Status of the Claims
1. This action is in reply to the Request for Continued Examination dated December 5, 2025.
2. Claims 1, 4-8, 10-13, 15-16, 18 and 20 are pending and have been examined.
3. Claims 1, 4, 8, 10, 16, and 18 have been amended.
4. Claims 2-3, 9, 14, 17 and 19 have been cancelled.
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 Interpretation – Broadest Reasonable Interpretation
6. 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.
The preamble of the instant claim 1 recites "[a] computer-implemented method for use in provisioning and/or using tokens for unsupported accounts, the method comprising:”
The preamble of the instant claim 8 recites "[a] non-transitory computer-readable storage medium comprising executable instructions for use in provisioning and/or using tokens for unsupported accounts, which when executed by at least one processor, cause the at least one processor to:”
The preamble of the instant claim 16 recites "[a] system for use in provisioning and/or using tokens for unsupported accounts, the system comprising a computing device configured to:”
In general, a preamble limits the invention if it recites essential structure or steps, or if it is "necessary to give life, meaning, and vitality" to the claims. Pitney Bowes, Inc. v. Hewlett-Packard Co. 51 USPQ2d 1161 (Fed. Cir. 1999), Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002). Conversely, where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or an intended use for the invention, the preamble is not a claim limitation given patentable weight. Rowe v. Dror, 42 USPQ2d 1550 (Fed. Cir. 1997); Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002); Bell Communications Research, Inc. v. Vitalink Communications Corp., 34 USPQ2d 1816 (Fed. Cir. 1995) If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets the claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) See MPEP 2111.02
In the instant case, “for use in provisioning and/or using tokens for unsupported accounts” as recited in the preambles of Claims 1, 8 and 16 only states a purpose and/or the intended use of the invention and accordingly is not being assigned any patentable weight.
Similarly in the instant case, the following italicized limitations are expressing the intended result of a process step positively recited and are not given weight:
As in Claim 1:
returning, by the token host computing device, the token to the wallet application, whereby the token is stored in the mobile device for use in initiating transactions to the account.
As in Claim 8:
return the token to the wallet application, whereby the token is stored in the mobile device for use in initiating transactions to the account.
As in Claim 16:
return the token to the wallet application, whereby the token is stored in the mobile device for use in initiating transactions to the account.
As in Claim 4:
requesting, by the token host computing device, from the issuer processor, which issued the account, permission to provision the token to the mobile device; and
receiving by the token host computing device, permission to provision the token to the mobile device from the issuer processor; and
wherein generating the token for the account includes generating the token for the account further based on permission from the issuer processor.
As in Claim 5:
wherein the provisioning request includes an identifier of the issuer processor;
wherein requesting permission to provision the token is based on the identifier of the issuer processor.
As in Claim 6:
wherein generating a pseudo PAN for the account is based on a BIN range assigned to the identified issuer processor, the second BIN being within the BIN range.
As in Claims 7, 15, and 20:
transmitting the account number to an issuer processor, which issued the account, whereby the issuer processor uses the account number to process the transaction.
As in Claim 10:
request, from the issuer processor, which issued the account, permission to provision the token to the mobile device; and
receive permission to provision the token to the mobile device from the issuer processor.
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.
7. Claims 1, 4-8, 10-13, 15-16, 18 and 20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
The substantially similar independent claims 1, 8 and 16 recite method, computer readable storage medium and system claims reciting receiving, a provisioning request to provision for an account, the request including an account number for the account and an identifier, the account number including a first bank identification number (BIN), which is unsupported; verifying the request based on an issuer, which issued the account, being supported for provisioning and a country code included the request being consistent with a location; based on the request being verified, generating, a pseudo primary account number (PAN) for the account, the pseudo PAN having a second BIN, which is supported and different than the first BIN; generating a token based on the pseudo PAN for the account, the token including the second BIN; storing the token and the pseudo PAN in association with the account number for the account, which is specific to the pseudo PAN; and returning the token, whereby the token is stored for use in initiating transactions to the account.
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 method claim. Claim 9 recites a computer-readable storage medium claim. Claim 16 is a system claim.
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 provisioning and/or using tokens for unsupported accounts for use in initiating transactions. This idea is described by the following limitations:
receiving from a wallet, a provisioning request to provision a token for an account, the request including an account number for the account and an identifier, the account number including a first bank identification number (BIN) which is unsupported;
verifying the request based on an issuer, which issued the account, being supported for provisioning and a country code included the request being consistent with a location;
based on the request being verified, generating, a pseudo primary account number (PAN) for the account, the pseudo PAN having a second BIN, which is supported and different than the first BIN;
generating a token based on the pseudo PAN for the account, the token including the second BIN;
storing the token and the pseudo PAN in association with the account number for the account, which is specific to the pseudo PAN; and
returning the token to the wallet, whereby the token is stored for use in initiating transactions to the account.
Claim 8 recites the abstract idea of provisioning and/or using tokens for unsupported accounts for use in initiating transactions. This idea is described by the following limitations:
receive from a wallet, a provisioning request to provision a token for an account, the request including an account number for the account and an identifier, the account number including a first bank identification number (BIN), which is unsupported;
verify the request based on an issuer, which issued the account, being supported for provisioning and a country code included the request being consistent with a location;
based on the request being verified, generate a pseudo primary account number (PAN) for the account, the pseudo PAN having a second BIN, which is supported and different than the first BIN;
generate a token based on the pseudo PAN for the account, the token including the second BIN;
store the token in association with the account number for the account, which is specific to the pseudo PAN; and
return the token to the wallet, whereby the token is stored for use in initiating transactions to the account.
Claim 16 recites the abstract idea of provisioning and/or using tokens for unsupported accounts for use in initiating transactions. This idea is described by the following limitations:
receive from a wallet, a provisioning request to provision a token for an account, the request including an account number for the account and an identifier, the account number including a first bank identification number (BIN), which is unsupported;
verify the request based on an issuer which issued the account, being supported for provisioning and a country code included the request being consistent with a location;
based on the request being verified, generate a pseudo primary account number (PAN) for the account, the pseudo PAN having a second BIN, which is supported and different than the first BIN;
generate a token based on the pseudo PAN for the account, the token including the second BIN;
store the token and the pseudo PAN in association with the account number for the account, which is specific to the pseudo PAN; and
return the token to the wallet, whereby the token is stored for use in initiating transactions to the account.
The abstract idea describes certain methods of organizing human activity as the steps involve commercial interactions and/or managing personal behavior or relationships or interactions between people as seen in the steps disclosed above.
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)
The claims 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 token host computing device, a wallet application, a mobile device, an issuer processor and a memory of the token host computing device.
Claim 8 recites a non-transitory computer-readable storage medium comprising executable instructions, at least one processor, a wallet application, a mobile device, an issuer processor and a memory.
Claim 16 recites a computing device, a wallet application, a mobile device, an issuer processor, and a memory of the computing device.
In particular, the claims only recite a token host computing device, a wallet application, a mobile device, a memory of the token host computing device, an issuer processor, a non-transitory computer-readable storage medium comprising executable instructions, at least one processor, a computing device and a memory of the computing device 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, 8 and 16 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; storing and retrieving information in memory and electronically scanning or extracting data– 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:
“Additionally, the system 100 includes a mobile device 110, which is associated with a user (not shown). The mobile device 110 may include, for example, a smartphone, a tablet, a smartwatch/wearable, or other suitable mobile device, which may be carried with the user. As shown, the mobile device 110 is associated with a digital activity service, which in this embodiment, includes a digital wallet. Specifically, the mobile device 110 includes a wallet application 112, which configures the mobile device 110 to perform as a payment device (e.g., to present payment credentials to the first party 102, etc.). The wallet application 112 may include, without limitation PayPass™ from Mastercard™, ApplePay™ from Apple, PayWave™ from Visa, GooglePay by Google, etc. In addition, the mobile device 110 also includes an issuer application 114, which is provided from and/or associated with the issuer processor 106. The issuer application 114 configures the mobile device 110 to show balances, transaction details, etc., associated with the account of the user associated with the mobile device 110.” (See Applicant Spec para 22)
“FIG. 2 illustrates an example computing device 200 that may be used in the system 100. The computing device 200 may include, for example, one or more servers, workstations, computers, laptops, tablets, smartphones, virtual devices, etc. In addition, the computing device 200 may include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, so long as the computing devices are specifically configured to operate as described herein. In the example embodiment of FIG. 1, at the least, the first party 102, the VAN 104, the issuer processor 106, the token host 116, the access server 118 and the authorization platform 120 may each include and/or may be implemented in one or more computing devices consistent with computing device 200. In addition, the mobile device 110 may be a computing device at least partially consistent with the computing device 200 (or a part thereof, such as, for example, memory 204, etc.). However, the system 100 should not be considered to be limited to the computing device 200, as described below, as different computing devices and/or arrangements of computing devices may be used. In addition, different components and/or arrangements of components may be used in other computing devices.” (See Applicant Spec para 39)
“As shown, in FIG. 4, the example computing device 200 includes a processor 202 and a memory 204 coupled to (and in communication with) the processor 202. The processor 202 may include one or more processing units (e.g., in a multi-core configuration, etc.) For example, the processor 202 may include without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein.” (See Applicant Spec para 40)
“The memory 204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. In connection therewith, the memory 204 may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), erasable programmable read only memory (EPROM), solid-state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other types of volatile or non-volatile physical or tangible computer-readable media for storing such data, instructions, etc. In particular herein, the memory 204 is configured to store data including, without limitation, tokens, account number, wallet identifiers, pseudo-PANs, records, ledgers, and/or other types of data (and/or data structures) suitable for use as described herein.” (See Applicant Spec para 41)
“Furthermore, in various embodiments, computer-executable instructions may be stored in the memory 204 for execution by the processor 202 the cause the processor 202 to perform one or more of the operations described herein (e.g., one or more of the operations of method 300 or 400, etc.) In connection with the various different parts of the system 100, such that the memory 204 is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor 202 as performing one or more of the various operations herein, whereby such performance may transform a computing device 200 into a special-purpose computing device. It should be appreciated that the memory 204 may include a variety of different memories, each implemented in connection with the one or more of the functions or processes described herein.” (See Applicant Spec para 42)
“it should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on computer readable media, and executable by one or more processors. The computer readable media is a non-transitory computer readable media. By way of example, and not limitation, such computer readable media can include RAM, ROM, EEPROM, CD-ROM or any other optical disk storage, magnetic disk storage or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.” (See Applicant Spec para 62)
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 claim(s) 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, 8 and 16 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 4-7, 10-13, 15, 18 and 20 further define the abstract idea that is presented in the respective independent Claims 1, 8, and 16 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
No further additional hardware components other than those found in the independent claims are recited, thus it is presumed that the claims are further utilizing the same generic systemization as presented in the independent claims. The claims do not recite additional elements that integrate the judicial exception 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.
Therefore, the dependent claims are also directed to an abstract idea.
Thus, Claims 1, 4-8, 10-13, 15-16, 18 and 20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Related Prior Art Not Currently Relied Upon
Deliwala et al. (US 2018/0101857) (“Deliwala”) – discloses a system, method, and computer readable medium is disclosed for managing and using loyalty rewards accounts in a digital wallet. (See Deliwala para 5) The system may generate a mapping comprising an account mapped to a wallet token number and an indicator with the mapping stored in a database on a network of servers. (See Deliwala para 5) The indicator may indicate an account type, and the wallet token number may be transmitted to a user device and may also receive a transaction request including a received wallet token number and a received indicator. (See Deliwala para 5) The system may also receive a transaction request including a received wallet token number and a received indicator. (See Deliwala para 5) In various embodiments, the mapping may include an alias associated with the account and the wallet token number. (See Deliwala para 6) The alias may also have the structure of an account number and the mapping may also comprise a funding source associated with the alias. (See Deliwala para 6)
The disclosure provides a system, method, and computer program product for managing and using loyalty pay accounts in conjunction with a digital wallet via a separate account issuer application. (See Deliwala para 17) The account issuer application may map and route account data securely to the digital wallet on various digital devices and in that regard, the account issuer may enable a user to add a loyalty payment account to the digital wallet as a payment medium and this loyalty account may be added to the digital wallet as a token, identified as a loyalty/rewards tokens, that may optionally be linked to a funding source. (See Deliwala para 17)
Jamkhedkar et al. (US PG Pub. 2019/0087816) (“Jamkhedkar”) - discloses his invention as to a system configured to perform operations that include receiving a purchase request to use a consumer digital wallet of a user to pay for an item sold by a merchant, the consumer digital wallet being included as a payment method in a merchant digital wallet account provided by the merchant to the user. (See Jamkhedkar Abstract) The operations further include generating a single-use payment token based on a non-transactable token. (See Jamkhedkar Abstract)
According to certain embodiments, the user may desire to add the consumer digital wallet account as a payment method to store within the merchant digital wallet account. (See Jamkhedkar para 13) For example, the user may initiate a request, via the user device, to add the consumer digital wallet account as a payment method to the merchant digital account. (See Jamkhedkar para 13) The request may include an account identifier associated with the consumer digital wallet account and additionally, the user device may transmit device information associated with the user device to the merchant server. (See Jamkhedkar para 14) The merchant server may receive the requet and the device information and forward the account identifier and device information to a payment provider system of the payment provider (which maintains the consumer digital wallet account for the user). (See Jamkhedkar para 15) In response to determining, based on the risk assessment, that the request is approved, the payment provider system generates an electronic nontransactable token (NTT) corresponding to the consumer digital wallet account. (See Jamkhedkar para 15) Further, the NTT is unusable for payment (e.g., the NTT is unusable and/or unrecognizable by a payment network used to process payment transactions). (See Jamkhedkar para 15) The NTT may be stored, in association with the account identifier, in a secure database separate from the merchant server. (See Jamkhedkar para 16) Subsequent to the generation and storage of the NTT, the user may initiate a purchase request to purchase an item from the merchant. (See Jamkhedkar para 17) Since the NTT is unusable for payment, the payment provider system may generate a single-use payment token based on the NTT. (See Jamkhedkar para 18) The single-use payment token may be another electronic token that is different from the NTT. (See Jamkhedkar para 18) Additionally, an association between the single-use payment token and the NTT may be stored in the secure database. (See Jamkhedkar para 18) Thus, the secure database may store associations between the NTT, the account identifier, and the single-use payment token. (See Jamkhedkar para 18) However, in contrast to the NTT, the single-use payment token is usable for a single payment transaction (e.g, the purchase request). (See Jamkhedkar para 18) Therefore, after the purchase request is processed using the single-use payment token, the single-use payment token is no longer usable for subsequent purchase transactions. (See Jamkhedkar para 18)
Kumnick et al. (US PG Pub. 2015/0199689) (“Kumnick”) - discloses a method for utilizing a non-transactable account identifier with a payment token is disclosed. (See Kumnick Abstract) The non-transactable account identifier can have the same format as a primary account number (PAN) and the payment token, but is not used to conduct a payment transaction. (See Kumnick Abstract) The transactable payment token can be used by the access device to process a payment for the transaction instead of the primary account identifier, while the non-transactable payment account identifier can be used as a reference for the primary account identifier to perform an operation that is not a payment transaction. (See Kumnick para 9)
Dill et al. (US PG Pub. 2015/0032626) (“Dill”) – discloses systems and methods for interoperable network token processing are provided. (See Dill Abstract) A network token system provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions. (See Dill Abstract) A token registry vault can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems to request generation, use and management of tokens. (See Dill Abstract)
Response to Arguments
Applicant's arguments filed December 5, 2025 have been fully considered as further detailed below.
Regarding the Claim Interpretation Section:
Examiner has reviewed the claim interpretation section in view of the amendments made to the claims and Applicant’s arguments and has updated the section accordingly. (See Applicant’s Arguments dated 11/13/2025, page 8)
Regarding the 101 Rejections:
Examiner has updated the rejection to account for the amendments made to the claims. Applicant traverses the previous 101 rejection arguing that the pending claims recite a technical solution to a technical problem which leverages the specific standard associated with tokens and pseudo PANs to provision accounts, which are unsupported to wallet applications. (Id. at pages 8-9)
In support of this assertion, Applicant references paragraph 12 of their specification. Examiner notes that paragraph 12 of the specification merely establishes recognizing a need for a technical solution, however does not actually present one. Applicant then recites limitations of Claim 1 and then concludes that the account, while unsupported, is associated with extended functionality through the tokenization, which provides for efficient and convenient access to the service(s), referring to paragraph 13 of their specification. (Id. at pages 9-10)
Applicant asserts that the technical improvement is provided through a pseudo PAN, which includes a supported BIN, and then also the token, which includes that same BIN, alleging that the functionality of the mobile device is enhanced and extended, in response to a technical problem and thus eligible. (Id. at page 10)
Applicant argues that the BIN range assigned to the accounts indicates services, capabilities, etc. associated with an account and that the claims “reinvent the account”. (Id. at pages 10-11) The account is not being reinvented – it is operating under rules that create a pseudo PAN and a pseudo BIN other than the original PAN and associated BIN. This is not reinvention, this is masking the original PAN/BIN into another format that lets it be used by the wallet. This is not enhancing the mobile device’s functionality, it is a workaround business solution to a business problem.
The claims are directed to commercial interactions, which includes marketing or sales activities or behaviors and business relations. The claims clearly disclose that the process is for provisioning and/or using tokens for unsupported accounts. The generation of a pseudo primary account number is used to generate a token based on the pseudo PAN which is returned to the wallet application for use in initiating transactions to the account. As to managing personal behavior or interactions between people, this category includes following rules or instructions, which is clearly being undertaken in the claims. Applicant’s assertions to the contrary are not persuasive. (Id. at pages 10-11)
Applicant then argues that the claims include an improvement to the functioning of technology. (Id.) While Applicant asserts that the pending claims enable the wallet application to be provisioned with unsupported accounts and alleges that this is something that was not previously possible, the specification does not bear out this assertion, rather, the specification only notes that “broadly” some exemplary accounts are unsupported for digital activity customers, however does not assert that this is some previously impossible activity. (Id. at page 11) Applicant’s arguments to the contrary are not persuasive.
Applicant also asserts that the above operations are not well-known, routine or conventional. (Id. at page 11) Applicant again attempts to argue that the claims operate differently than conventional wallets, however Examiner is of another opinion – this is not an improvement in technology, rather it is following rules using a computer that it has been programmed or instructed to follow. (Id. at pages 11-12) Further, Examiner notes that there is disclosure from Applicant’s own disclosure as well as the MPEP – which fulfills any Berkheimer considerations that Applicant is attempting to raise. (Id. at page 11) The 101 Rejection is maintained.
Regarding the 103 Rejections:
Based on the amendments and arguments made, there is no prior art rejection being applied at this time. (See Applicant Arguments dated 11/13/2025, pages 12-14)
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 January 5, 2026