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