Prosecution Insights
Last updated: October 23, 2026
Application No. 18/824,309

SYSTEMS AND METHODS FOR CARD TOKENIZATION VIA API

Final Rejection §101§102
Filed
Sep 04, 2024
Priority
Mar 04, 2020 — divisional of 12/118,536
Examiner
SHARVIN, DAVID P
Art Unit
3692
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
JPMorgan Chase Bank, N.A.
OA Round
2 (Final)
39%
Grant Probability
At Risk
3-4
OA Rounds
1y 11m
Est. Remaining
63%
With Interview

Examiner Intelligence

Grants only 39% of cases
39%
Career Allowance Rate
116 granted / 300 resolved
-13.3% vs TC avg
Strong +24% interview lift
Without
With
+24.4%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
18 currently pending
Career history
331
Total Applications
across all art units

Statute-Specific Performance

§101
40.6%
+0.6% vs TC avg
§103
28.9%
-11.1% vs TC avg
§102
10.7%
-29.3% vs TC avg
§112
14.6%
-25.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 300 resolved cases

Office Action

§101 §102
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Applicant states that the claims were amended but the claims appear to be the same as previously presented on 4/23/2026, only without the strikeout portions. Appropriate claim identifiers should be included in future responses. If the incorrect claims were submitted or entered by the Applicant, then any amended claims can be examiner in the next round of prosecution. Response to Arguments Applicant's arguments filed 28 July 2026 with respect to the 101 rejection have been fully considered but they are not persuasive. Applicant argues on pages9-10 that the claims are not directed to a judicial exception, specifically that the identified abstract idea is not explicitly recited in the enumerated examples in the MPEP. The Examiner disagrees because the claims are directed to a fundamental economic practice of issuing a financial instrument such as issuing currency or issuing a payment account number or credit card number or bank account number which is used in commerce. Issuing a token for a payment account is similar to these fundamental economic practices. Applicant argues on pages 10-11 that the claim are integrated into a practical application due to the digital enable service that controls the digital wallet. The Examiner disagrees because the abstract idea is being implemented by a computer (a digital enable service) and these additional elements amount to merely using a computer as a tool to perform an abstract idea or apply it type language, MPEP 210.05(f). Applicant's arguments filed 28 July 2026 with respect to the 102 rejection have been fully considered but they are not persuasive. Applicant argues the claims are not anticipated by the cited reference Safak on pages 12-13. The Examiner disagrees because [0120] states the digital issuance system (which includes the token service provider, which can also be the MDES) allows the life cycle management of the credentials such as adding/deleting/suspending/unsuspending the credential and is done using APIs. In [0221] “Alternatively, the token state is changed from “active” to “suspended” in the wallet front end (MPA SDK), if an MPA is used, as well as in the wallet backend and the token mapping is suspended at the TSP for that specific PSN value only, whereas the SUKs/SKs remain as is in the device” which when read with [0120] and [0184] “The arrow between the TSP 1241 and wallet client 1221 represents digitization (SUK or SK replenishment, etc.)” shows that the issuer host communicates with the TSP in the Digital issuance system to perform lifecycle management of the credentials. The plain reading of the reference shows that information flow claimed is disclosed in the cited reference Safak. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 6-8, 10-13, and 18-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In the instant case, claim 6 is directed to a “method”. Claim 6 is directed to the concept of “issuing a financial instrument” which is grouped under “organizing human activity… fundamental economic practice (issuing a financial instrument is a fundamental practice similar to issuing currency or issuing a payment account number or credit card number or bank account number which is used in commerce)” in prong one of step 2A (See MPEP 2106.04(a)(2)). Claim 6 recites initiating a lifecycle action for the payment token, communicating the token lifecycle action for a card association, communicating the token lifecycle action and executing the token lifecycle action. Accordingly, the claim recites an abstract idea (See MPEP 2106.04(a)(2)). This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04(d)), the additional elements of the claim such as financial institution backend, digital enablement service, an API, and the digital wallet represent the use of a computer as a tool to perform an abstract idea and/or does no more than ‘Apply it’ (MPEP 2106.05(f)&(h)). Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. implement) the acts of issuing a financial instrument. When analyzed under step 2B (See MPEP 2106.05), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of issuing a financial instrument using computer technology (e.g. a financial backend). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Dependent claims 7-8, 10-13, 18-20 and 22-30 do not remedy the deficiencies of the independent claims and are rejected accordingly. The dependent claims further refine the abstract idea of the independent claims and do not integrate the abstract idea into a practical application In this case, all claims have been reviewed and are found to be substantially similar and linked to the same abstract idea (see Content Extraction and Transmission LLC v. Wells Fargo (Fed. Cir. 2014)). Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claim(s) 6-8, 10-13, and 18-30 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Safak US 2019/0156335. As per claims 6 and 21: Safak discloses a method comprising: initiating, by a financial institution backend for a financial institution, and in response to a token lifecycle event for a payment token that is provisioned to a digital wallet executed by an electronic device, a token lifecycle action for the payment token (¶¶ [0120]-[0122] ‘suspension or deletion’, [0176 “lifecycle management”, Fig 12 ‘1297’ [0184]); communicating, by the financial institution backend, the token lifecycle action to a digital enablement service for a card association using an application programming interface (API) (¶¶ [0116], [0120] API are used to communicate between digital issuance system and authorized entity, Fig 12 ‘TSP’ or ‘MDES’, see also [0221] the digital issuance system that controls the lifecycle management operations an suspend the token through the wallet backend and the token mapping is suspended at the TSP, and [0184] ‘SUK’ from the TSP, which is a part of the digital issuance system); communicating, by the digital enablement service, the token lifecycle action to the digital wallet (¶¶ [0116], [0120], Fig 12 ‘TSP’ or ‘MDES’, Fig 14 is also representative of adding or updating an account for tokenization, which can also read on a lifecycle action under BRI; see also [0221], [0184]); and executing, by the digital wallet, the token lifecycle action (¶¶ [0229]-[0231], [0120]-[0122], [0221] active to suspended). As per claims 7 and 22: Safak further discloses the method of claim 6, wherein the token lifecycle event is a token suspension event, a token update event, a token termination event, and a token reissue event (¶ [0120] ‘Life cycle management can include, but is not limited to, adding/deleting/suspending/un-suspending a digital consumer credential’). As per claims 8 and 23: Safak further discloses the method of claim 6, wherein a token vault service for the financial institution executes the token lifecycle action, wherein the token vault service updates or deletes the payment token in response to the token lifecycle action (¶¶ [0120]-[0122], Fig 12 ‘TSP’, ¶ [0234] the TSP includes token vault and is considered a token vault service). As per claims 10 and 24: Safak further discloses the method of claim 6, wherein the token lifecycle event is requested by a holder of the payment token and is received by a services system (¶ [0120] “The digital issuance system allows the life cycle management of the digital consumer credentials by the consumer and/or by authorized parties (typically the bank)”). As per claims 11 and 25: Safak further discloses the method of claim 10, wherein the services system comprises an automated response system (¶¶ [0121]-[0122] ‘CSR’ Fig 12 ‘1209, ‘1211’). As per claims 12 and 26: Safak further discloses the method of claim 10, wherein the services system comprises a service representative (¶¶ [0121]-[0122] ‘CSR’, Fig 12 ‘1209, ‘1211’). As per claims 13 and 27: Safak further discloses the method of claim 10, wherein the token lifecycle event is received electronically (¶ [0143], [0247] Fig 12, token server is an electronic device that only receives electronic requests and operates digitally). As per claims 18 and 28: Safak further discloses the method of claim 6 further comprising: receiving, by the financial institution backend and from the digital enablement service for a card association via the API, a provisioning request to tokenize an account to the digital wallet, the provisioning request comprising an identification of the account, the digital enablement service interfacing with both a third-party wallet provider backend for the digital wallet and the financial institution backend (Fig 14A, ¶¶ [0199]-[0200]); approving, by the financial institution backend, the provisioning request (¶¶ [0203]-[0204], Fig 14A); communicating, by the financial institution backend and to the digital enablement service, the approval (¶¶ [0203]-[0204], Fig 14A); generating, by the digital enablement service, the payment token for the account in response to receiving the approval (¶ [0213] “MDES generates the token”, Fig 14B); communicating, by the digital enablement service, the payment token to the third-party wallet provider backend, wherein the third-party wallet provider backend provides the payment token to the digital wallet (¶ [0213]-[0214], Fig 14B); sending, by the digital enablement service, a token activation notice to the financial institution backend (Fig 14B, ¶ [0204] MDES notifies the wallet server which notifies the issuer); and updating, by the financial institution backend, a cardholder card status for the account with a token provisioned status (¶¶ [0203]-[0204]). As per claims 19 and 29: Safak further discloses the method of claim 18, further comprising: presenting, by the financial institution backend and via the digital enablement service to the digital wallet, terms and conditions (Fig 14A, ¶¶ [0197]-[0198] ‘terms and conditions’); and generating, by the digital enablement service, the token activation notice in response to acceptance of the terms and conditions (Fig 14A, ¶¶ [0197]-[0198] ‘terms and conditions’). As per claims 20 and 30: Safak further discloses the method of claim 18, wherein the token lifecycle event is requested by a holder of the account and is received by a services system (¶ [0120] “The digital issuance system allows the life cycle management of the digital consumer credentials by the consumer and/or by authorized parties (typically the bank)”). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Asefi US 2024/0086931 “Token Management System” Kim US 2017/0337542 Aabye US 2015/0120472 Desai US 2015/0302398 Royyuru US 2021/0279699 THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID P SHARVIN whose telephone number is (571)272-9863. The examiner can normally be reached M-F 9 am - 5 pm EST. 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, Ryan Donlon can be reached at 571-270-3602. 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. /DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Read full office action

Prosecution Timeline

Sep 04, 2024
Application Filed
May 05, 2026
Non-Final Rejection mailed — §101, §102
Jul 30, 2026
Response Filed
Oct 06, 2026
Final Rejection mailed — §101, §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12770127
METHODS FOR PROVIDING SYSTEMATIC INTELLIGENCE FOR SELECTING MODE OF PAYMENT AND DEVICES THEREOF
1y 11m to grant Granted Oct 20, 2026
Patent 12762532
TRANSACTION COORDINATION ACROSS SERVICES
2y 5m to grant Granted Oct 13, 2026
Patent 12749067
SERVER AND CONTROL METHOD THEREOF
3y 10m to grant Granted Sep 29, 2026
Patent 12731114
COMPUTER IMPLEMENTED METHOD AND SYSTEM
3y 1m to grant Granted Sep 08, 2026
Patent 12718298
DETERMINATION OF IMPLIED ORDERS IN A TRADE MATCHING SYSTEM
1y 8m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
39%
Grant Probability
63%
With Interview (+24.4%)
4y 0m (~1y 11m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 300 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month