DETAILED ACTION
Status of Claims
Claims 1, 11, and 16 have been amended.
Claims 1-23 are currently pending and have been considered by the examiner.
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 .
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 11 December 2025 has been entered.
Response to Arguments
101 Rejection:
Applicant’s arguments have been considered and have been deemed unpersuasive by the examiner based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant’s arguments have been considered and are moot in view of new grounds for rejection.
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 1-23 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, claims 1-10 are directed towards a method, claims 16-23 are directed to a system/apparatus, and claims 11-15 are directed towards a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method for a high-security display of distinct subsets of a digital payment card dataset, the method comprising:
at a payment card issuer:
importing token data comprising:
a token generated from a primary account number (PAN), the token having the same number of digits as the PAN;
an expiration date associated with the token; and
a token security code associated with the token;
maintaining the PAN and the token data in the same file in an issuer system of record; and
generating a digital payment card for a user, the digital payment card comprising the token in place of a payment card PAN, the token expiration date in place of a payment card expiration date, and the token security code in place of a payment card verification value (CVV); and
at a high security display:
in response to receiving a first signal from a user, upgrading a verification status from a default security level to a first security level;
when the verification status is at the first security level, displaying a first subset of the digital payment card dataset to the user, the first subset comprising a first portion of the token data;
in response to a second signal, upgrading the verification status from the first security level to a second security level; and
when the verification status is at the second security level, augmenting the display with a selectable option to toggle to a second subset of the dataset, the second subset comprising a second portion of the token data.
Regarding Step 2A Prong One, the claims recite the abstract idea of mitigating settlement risk. Specifically, the claims recite the limitations underlined above which recite the process of establishing security procedures for a digital payment card which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of mitigating risk in an economic transaction. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “digital payment card” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “digital payment card” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “digital payment card” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “digital payment card” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite risk mitigation. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-10, 12-15, and 17-23 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claims 2, 4-5, 8, 10, 12, 14-15, 17, 19, and 23 merely recite additional limitations which are also directed towards the abstract idea of mitigating settlement risk in an economic transaction.
Claims 3, 6-7, 13, 18, and 20-21 merely further describe the data used to perform the recited abstract idea.
Claims 9 and 22 recite the additional element of a digital wallet but does not place the recited abstract idea into practical application nor amount to significantly more.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Church et al. (US 20200097971 A1) in view of Zhang (US 20190347667 A1).
Regarding Claims 1, 11, and 16, Church discloses:
A method for a high-security display of distinct subsets of a digital payment card dataset, the method comprising: at a payment card issuer: importing token data comprising:
a token generated from a primary account number (PAN), the token having the same number of digits as the PAN (See Church: Para. [0031] – “In some embodiments, the dataset may include a sequence of numbers associated with a payment instrument. The sequence of numbers may include a 16-digit account number associated with the payment instrument.);
an expiration date associated with the token (See Church: Para. [0031] – “In some embodiments, the dataset may include a sequence of numbers associated with a payment instrument. The sequence of numbers may include a 16-digit account number associated with the payment instrument. The sequence of numbers may also include an expiration date associated with the payment instrument); and
a token security code associated with the token (See Church: Para. [0031] – “In some embodiments, the dataset may include … a card verification value (“CVV”) associated with the payment instrument. A CVV is typically formulated at least in part based on the expiration date. The term CVV as used herein may be synonymous with CVV2, card security code (“CSC”), card verification data (“CVD”), card verification number (“CVN”), or card verification code (“CVC”).);
generating a digital payment card for a user, the digital payment card comprising the token in place of a payment card PAN, the token expiration date in place of a payment card expiration date, and the token security code in place of a payment card verification value (CVV) (See Church: Para. [0072] – “Initiation of the two tracks may include creation of two accounts. The two accounts may be one account internally. The two accounts may share an account number. The account number may be a 16-digit card number. The two accounts may differ in their respective expiration dates and CVVs. In some embodiments, the two accounts may share one, some or all of an account number, CVV, and expiration date.”); and
at a high security display:
in response to receiving a first signal from a user, upgrading a verification status from a default security level to a first security level (See Church: Para. [0022] – “In response to a first signal, the verification module may upgrade the verification status from a default level to a first level”);
when the verification status is at the first security level, displaying a first subset of the digital payment card dataset to the user (See Church: Para. [0022] – “When the verification status is at the first level, the screen may display a first, partial, subset of the dataset.”);
in response to a second signal, upgrading the verification status from the first security level to a second security level (See Church: Para. [0023] – “In response to a second signal, the verification module may upgrade the verification status from the first level to a second level”); and
when the verification status is at the second security level, augmenting the display with a selectable option to toggle to a second subset of the dataset (See Church: Para. [0023] – “When the verification status is at the second level, the screen may be augmented with the ability (e.g. in the form of a selectable option) to toggle to display a second, sensitive, subset of the dataset.”).
Church fails to explicitly disclose:
maintaining the PAN and the token data in the same file in an issuer system of record
the first subset comprising a first portion of the token data
the second subset comprising a second portion of the token data.
However, in a similar field of endeavor, Zhang discloses:
maintaining the PAN and the token data in the same file in a system of record (See Zhang: Para. [0180] – “Referring to FIG. 9, the first data structure 12 (and all other data structures included therewith) is shown. The first data structure 12 may store the data associated with token. The token data may include a PAN number 146 (or other account identifier), a token ID 206, and a timestamp 208. The token ID 206 may be a unique identifier that allows the tokenized transaction to be identified solely based on that token ID 206. The token ID 206 may take any form, as previously discussed in connection with the first data ID. The timestamp 208 may associate the tokenized transaction with a specific time, such as the time the tokenized transaction was initiated and/or the token generated and assigned. However, the timestamp 208 may be assigned based on other events occurring during processing of the tokenized transaction, such as when the tokenized transaction was received by a certain party (e.g., merchant system, transaction service provider, issuer, and the like) when the tokenized transaction was transmitted from one party to another party, and the like.”)
a first subset comprising a first portion of the token data and a second subset comprising a second portion of the token data (See Zhang: Para. [0067] – “receiving, with at least one processor, first token data associated with a first token, wherein the first token data comprises a first timestamp associated with generation of the first token and a first token ID; determining, with at least one processor and based on the first timestamp, that the first timestamp falls within the overlap time interval; upon determining that the first timestamp falls within the overlap time interval storing, with at least one processor, the first token data to the first data structure and the second data structure; receiving, with at least one processor, second token data associated with a second token, wherein the second token comprises a second timestamp associated with generation of the second token and a second token ID”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the structural architecture used for data storage disclosed by Zhang in order to structure the data handled by the system of Church yielding the predictable result of an increase in the data processing efficiency by eliminating the chance that data might be duplicated. (See Zhang: Para. [0137])
Regarding Claims 2, 12, and 17, Church discloses:
further comprising executing a transaction in response to receiving an input of the token, the token expiration date, and the token security code from the user (See Church: Para. [0039] – “The digital wallet may be used to execute transactions, such as purchases, both in brick-and-mortar stores and online”).
Regarding Claims 3, 13, and 18, Church discloses:
wherein the token is a first token, the method further comprising, importing a second token generated from the PAN, the second token replacing the first token on the digital payment card (See Church: Para. [0075] – “The digital payment instrument track may proceed further with step 313. Step 313 may include updating a digital wallet with the digital payment instrument. The update may add the digital payment instrument to the digital wallet. The update may replace an existing payment instrument (e.g. an expired or cancelled version of the digital payment instrument) with the digital payment instrument. The update may be executed absent any user activity. Alternatively, the update may be executed partially or completely manually. The update may involve re-provisioning the wallet. Re-provisioning the wallet may involve updating and/or creating tokens.”).
Regarding Claims 4, 14, and 19, Church discloses:
further comprising importing the second token after a predetermined number of uses of the digital payment card (See Church: Para. [0037] – “In certain embodiments, the temporary payment instrument may be deactivated when a tangible payment instrument associated with the temporary payment instrument is activated. The tangible payment instrument may, in some embodiments, be periodically or substantially continuously monitored for activation. For example, the tangible payment instrument may be monitored once a day. The monitoring may coincide with batch processing activity. In another example, the tangible payment instrument may be monitored every time an attempt is made to access information regarding the temporary payment instrument. In yet another example, an alert may be issued when the tangible payment instrument is activated.”).
Regarding Claims 5, 15, and 20, Church discloses:
further comprising importing the second token after a predetermined time period following issuance of the digital payment card (See Church: Para. [0036] – “In some embodiments, the temporary payment instrument may be associated with an expiration date that is 30 days after the creation of the temporary payment instrument. In other embodiments, the temporary payment instrument may be associated with an expiration date that is any suitable amount of time from the creation of the temporary payment instrument. For example, the expiration date may be 7, 10, 14, 21, 45, 60, 90 or any other suitable number of days after the creation of the temporary payment instrument. The expiration date may be at the end of a month or billing cycle. The temporary payment instrument may expire less than four years, or any other suitable amount of time, after its creation. Four years may be the typical life-span of a tangible payment instrument.”).
Regarding Claim 6, Church discloses
wherein a plurality of tokens is associated with the PAN in a system of record maintained by the payment card issuer (See Church: Para. [0051] – “The memory 115 may be comprised of any suitable permanent storage technology—e.g., a hard drive. The memory 115 stores software including the operating system 117 any application(s) 119 along with any data 111 needed for the operation of the system 100. Memory 115 may also store videos, text, and/or audio assistance files. The videos, text, and/or audio assistance files may also be stored in cache memory, or any other suitable memory. Alternatively, some or all of computer executable instructions may be embodied in hardware or firmware (not shown). The computer 101 may execute the instructions embodied by the software to perform various functions.”).
Regarding Claim 7, Church discloses:
wherein the PAN and the tokens are maintained by the payment card issuer in the same file (See Church: Para. [0051] – “The memory 115 may be comprised of any suitable permanent storage technology—e.g., a hard drive. The memory 115 stores software including the operating system 117 any application(s) 119 along with any data 111 needed for the operation of the system 100. Memory 115 may also store videos, text, and/or audio assistance files. The videos, text, and/or audio assistance files may also be stored in cache memory, or any other suitable memory. Alternatively, some or all of computer executable instructions may be embodied in hardware or firmware (not shown). The computer 101 may execute the instructions embodied by the software to perform various functions.”).
Regarding Claims 8 and 21, Church discloses:
further comprising obtaining a new token security code for each transaction executed using the digital payment card (See Church: Para. [0035] – “In certain embodiments of the TUI, the payment instrument may be a debit card. In some embodiments, the payment instrument may be a temporary payment instrument. The temporary payment instrument may be a digital version of a tangible payment instrument. The temporary payment instrument may be a digital payment instrument that is independent of a physical embodiment. The temporary payment instrument and the tangible payment instrument may share an account number, and differ with respect to an expiration date and a CVV. In some embodiments, the CVV and/or the expiration date may be the same for the temporary and the tangible payment instruments. In still other embodiments, the account number may be different for the temporary and the tangible payment instruments”).
Regarding Claims 9 and 22, Church discloses:
further comprising provisioning a digital wallet with the digital payment card in response to user input of the token, the token expiration date, and the token security code (See Church: Para. [0039] – “In some embodiments, the TUI may include a digital wallet. A digital wallet may be a program or app. The digital wallet may store payment instrument information. The digital wallet may use tokenization methods to represent payment instruments. Tokenization methods may provide payment instrument operability with limited or no transfer of sensitive information. The digital wallet may be used to execute transactions, such as purchases, both in brick-and-mortar stores and online.”).
Regarding Claims 10 and 23, Church discloses:
further comprising automatically reprovisioning the digital wallet in response to replacing the first token with the second token (See Church: Para. [0040] – “In certain embodiments of the TUI, the digital wallet may be updated to include the temporary payment instrument. Updating the digital wallet may require manually selecting an update option. Updating the digital wallet may be accomplished automatically, absent the need for user activity.”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 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, Neha Patel can be reached at 571-270-1492. 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699