DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. Applicant filed the amendment on 08/15/2025. Claims 1-20 are pending. Claims 1, 3-5, 7-11, 14-15, and 18-20 are amended. Claims 1-20 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
3. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims 1 and 11 do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
4. Applicant is of the opinion that amended claim 1 is integrated into a practical application, as it reflects improvements to the technological field of mobile payment applications and platforms, such as providing the ability to use different tokens improves the security of mobile payment applications.
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. 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)).
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 the abstract idea.
The claims are not patent eligible.
Rejections under 35 U.S.C. § 112(b)
5. Rejections of claims 1-20 due to amended claims are withdrawn.
Rejections under 35 U.S.C. §§ 102-103
6. Applicant is of the opinion that the prior art references Howard in view of Mitra et al. do not teach amendments made to claims 1-20.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Claim Interpretation
Intended Use
7. Intended use language is generally not given patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.”
8. Claim 16 recites “wherein interfacing … the reader device to enable contacts of the chip to engage …”.
The underlined limitations represent intended use and are not given patentable weight.
Claim Rejections - 35 USC §101
9. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
10. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
11. In the instant case, claims 1 and 11 are directed to a “payment reader and method for replenishing tokens in a payment device”.
12. Claim 11 recites “implementing a payment transaction”. Specifically, claim recites “interfacing … during a payment transaction; obtaining a first token stored …; authenticating … using the first token; providing … the first token …; receiving … a script and a second token … wherein the script includes at least one instruction … to store the second token …; processing the script and the second token; communicating … the script and the second token received …; and executing … the script communicated … to store the second token … for a subsequent payment transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
13. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 11 such as “a payment device”, “a reader device”, “a memory of the payment device”, “a server”, and “a processing unit of the payment device” do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “obtaining a first token stored in a memory of the payment device”, “providing, by the reader device, the first token from the payment device to a server”, and “receiving, by the reader device, a script and a second token for the payment device from the server, wherein the script includes at least one instruction for a processing unit of the payment device to store the second token in the memory of the payment device”, is simply transmitting data; “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
14. When analyzed under step 2B (MPEP 2106.04 II), 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 claim merely describe the concept of implementing a payment transaction using computer technology (e.g., the processor). 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)).
15. Hence, claim 11 is not patent eligible.
16. Claim 1 also recites “implementing a payment transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
17. As in the case of claim 11, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a payment reader”, “a payment device”, “reader circuitry”, “communication circuitry”, “a server”, and “a processing unit of the payment device” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. 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., automate) the acts of implementing a payment transaction.
18. When analyzed under step 2B (MPEP 2106.04 II), 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 claim merely describe the concept of implementing a payment transaction using computer technology (e.g., the processor). 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)).
19. Hence, claim 1 is not patent eligible.
20. Dependent claim 2 further describes the abstract idea of implementing a payment transaction. The additional elements such as “the reader circuitry” and “a contactless interface having at least one antenna” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 3 further describes the abstract idea of implementing a payment transaction, as recites “wherein … interfaces with … by inductive coupling to enable wireless communication between …”. The additional elements such as “the contactless interface of the reader circuitry”, “the payment device” and “the reader circuitry” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 4 further describes the abstract idea of implementing a payment transaction, as recites “wherein … obtains the first token stored … during a first inductive coupling … provides the script and the second token … during a second inductive coupling …”. The additional elements such as “the reader circuitry”, “the payment device”, and “the contactless interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 5 further describes the abstract idea of implementing a payment transaction. The additional elements such as “the reader circuitry”, and “a contact interface having power and communication circuitry” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 6 further describes the abstract idea of implementing a payment transaction, as recites “comprising a slot to receive … wherein … interfaces … when … is inserted in the slot”. The additional elements such as “the payment device”, “the contact interface of the reader circuitry”, and “contacts on a chip of the payment device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 7 further describes the abstract idea of implementing a payment transaction, as recites “wherein … provides power …”. The additional elements such as “the power and communication circuitry of the contact interface” and “the payment device”, and “at least one contact on the chip of the payment device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 8 further describes the abstract idea of implementing a payment transaction, as recites “comprising … that executes third computer readable instructions for performing … functions during processing of payment transactions”. The additional elements such as “a cryptographic processing unit” and “cryptographic” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 9 further describes the abstract idea of implementing a payment transaction, as recites “wherein … executes the third computer-readable instructions for … the first token received … prior to the first token being provided … the script and the second token received … prior to the script and the second token being provided …”. The additional elements such as “the cryptographic processing unit”, “encrypting the first token”, “the payment device”, “the server”, and “decrypting the script and the second token” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 10 further describes the abstract idea of implementing a payment transaction, as recites “wherein the first token is a permanent token that does not have a predetermined expiration time and the script provided … reprograms … causing …to replace the permanent token with the second token”. The additional element such as “the payment device reprograms the payment device causing the payment device to replace” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 12 further describes the abstract idea of implementing a payment transaction. The additional elements such as “the payment device”, “a near field communication (NFC) device”, “the reader device”, and “a contactless interface having at least one antenna” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 13 further describes the abstract idea of implementing a payment transaction, as recites “wherein interfacing … includes inductively coupling … with … to enable wireless communication between …”. The additional elements such as “the payment device”, “the reader device”, “the NFC device”, and “the contactless interface of the reader device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 14 further describes the abstract idea of implementing a payment transaction, as recites “wherein obtaining the token includes obtaining the first token stored … during a first inductive coupling … and communicating the script and the second token includes providing the script and the second token to … during a second inductive coupling …”. The additional elements such as “the NFC device” and “the reader device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 15 further describes the abstract idea of implementing a payment transaction. The additional elements such as “the payment device”, “a payment card comprising a chip”, “the reader device”, and “a contact interface having a power and communication circuitry” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 16 further describes the abstract idea of implementing a payment transaction, as recites “wherein interfacing … includes inserting … into a corresponding slot … to enable … to engage …”. The additional elements such as “the payment device”, “the reader device”, “a payment card”, “the payment card”, “the reader device”, “contacts of the chip”, and “contacts of the contact interface” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 17 further describes the abstract idea of implementing a payment transaction, as recites “comprises providing power …”. The additional elements such as “the payment device with the power and communication circuitry” and “at least one contact on the chip of the payment device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 18 further describes the abstract idea of implementing a payment transaction, as recites “comprising performing … functions during processing of payment transactions …”. The additional elements such as “cryptographic” and “a cryptographic processing unit of the reader device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 19 further describes the abstract idea of implementing a payment transaction, as recites “wherein performing … functions includes: … the firs token received … prior to the first token being provided … and … the script and the second token received…prior to the script and the second token being communicated …”. The additional elements such as “cryptographic”, “encrypting, using the cryptographic functions”, “the payment device”, “the server”, and “decrypting the script and the second token” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 20 further describes the abstract idea of implementing a payment transaction, as recites “wherein the token is a permanent token that does not have a predetermined expiration time and wherein executing the script includes … causing … to replace the permanent token with the second token”. The additional element such as “reprogramming the payment device causing the payment device to replace” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
21. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
22. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 112
23. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
24. Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Lack of Algorithm
25. Claim 1 recites “authenticating the payment device utilizing the first token”.
Claim 11 recites “authenticating the payment device using the first token”.
According to the Specification (PGPub, para 3) “The EMV card can store a unique key that is used each time the EMV card is used for a payment transaction. The unique key can be used to authenticate the EMV card and/or for encrypting the payment information provided to the payment reader”. However, the Specification is silent how the “authenticating” is performed.
26. The underlined limitations should have the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed, (MPEP 2161.01(I)).
27. Claims 2-10 and 12-20 are rejected under the same rationale as claims 1 and 11 because claims 2-10 and 12-20 inherit the deficiencies of claims 1 and 11 respectively due to their dependency.
Claim Rejections - 35 USC § 103
28. 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 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.
29. 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.
30. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
31. Claims 1-5, 8, 11-15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US20230153792A1 to Kurani et al. in view of US20150339663A1 to Lopreiato et al.
32. As per claim 1:
Kurani et al. discloses the following limitations:
reader circuitry executing first computer-readable instructions for ([0022] “…The systems and methods described herein allow for integration between a mobile wallet server and a merchant for processing a payment.”
interfacing with a payment device during a payment transaction (Fig.1, items 110, 116, 140; [0033] “…Upon initiation of a transaction, the client application 116 may request data from the mobile wallet computer system 120 to generate a unique code/token…” [0034] “The mobile wallet client application 116 is used in connection with merchant computer system 140 located at a brick and mortar store location…”)
obtaining a first token stored in the payment device ([0033] “… The unique code/token may then be transmitted by the mobile device 110 to the merchant computer system 140 as part of a transaction to facilitate authentication of the transaction…”)
authenticating the payment device utilizing the first token (Fig.2, items 110, 120, 140, 145, 202; [0061] “The use of the payment token and trace ID as described herein allows for two levels of authentication. The payment token is generated by the mobile wallet computer system at step 202. The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120 where it is matched with the original payment token generated at step 202.”)
communication circuitry communicatively coupled with a server, and executing second computer-readable instruction for,
providing the first token from the payment device to the server (Fig.2, items 110, 120; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”
receiving a script and a second token for the payment device from the server (Fig.3, items 308, 310; [0068] “Process 300 further includes generating a customer token and device token (step 308), and sending the customer token and device token to the mobile device of the user (step 310). The customer token and device token may be tokens that identify the user and the associated mobile device to the mobile wallet bank computer system in the future…”, [0069] “Process 300 further includes receiving a default payment method from the user (step 312) and completing the registration (step 314).”, wherein the script includes at least one instruction for a processing unit of the payment device to store the second token in the payment device ([0016] “FIG. 6 illustrates a Track 2 format for a generated QR code that may be created in the token generation process, according to an example embodiment.”, [0068] “…The tokens are encrypted by the mobile wallet bank computer system and provided to the mobile device. The mobile device stores the tokens for future use…”, [0069] “…Step 314 may include a user accepting terms and conditions associated with use of the mobile wallet account…”) wherein
Kurani et al does not disclose, however, Lopreiato et al., as shown, teaches the following limitations:
the reader circuitry executes the first computer-readable instructions for processing the script and the second token received from the server and providing the script and the second token to the payment device, the processing unit of the payment device executing the script and storing the second token in the payment device for a subsequent payment transaction (Fig.7, items 706,708, 710; [0062] “…At block 706, the token service provider computer 104 may select or generate a new token number…”, [0063] “…At block 708, the token service provider computer 104 may establish or update a database entry for the token number selected or generated at 706, such that the new token number is mapped to the same PAN to which the replaced token number was previously mapped…”, [0064] “…At block 710, the token service provider computer 104 (or in some cases the payment account issuer) may provision the new token to the user's payment-enabled mobile device. In the course of the provisioning of the new token to the mobile device, other data may also be provisioned to the mobile device, including, for example, a token expiration date for the new token, an updated cryptographic key or keys, etc.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for establishing or updating a database entry by the token service provider computer for the token number selected or generated, such that the new token number, and provisioning the new token to the user's payment-enabled mobile device and an updated cryptographic key or keys, etc. (‘663, [0063]-[0064]).
33. As per claim 2:
Kurani et al. discloses the following limitations:
wherein the reader circuitry comprises a contactless interface having at least one antenna ([0038] “…As will be appreciated, any suitable method may be used to transmit the code. In various embodiments, the code may be transmitted using optical image methods (e.g., QR code), NFC, wireless, Bluetooth, low energy Bluetooth, RFID, hypersonic, Wi-Fi, cellular 3G, 4G, GSM, LiFi, etc…”)
34. As per claim 3:
Kurani et al. discloses the following limitations:
wherein the contactless interface of the reader circuitry interfaces with the payment device by inductive coupling to enable wireless communication between the reader circuitry and the payment device (Fig.1, items 110, 140; [0028] “The payment processing system 100 may include, among other systems, a mobile device 110, a mobile wallet bank computer system 120, a source account bank computer system 130, a merchant computer system 140, an acquirer/processor computer system 145 and a payment system 150. The various systems may communicate through a network 160, which may include one or more of the Internet, cellular network, Wi-Fi, Wi-Max, a proprietary banking network, or any other type of wired or wireless network…”)
35. As per claim 4:
Kurani et al. discloses the following limitations:
wherein the reader circuitry obtains the first token stored in the payment device during a first inductive coupling of the contactless interface with the payment device… ([0033] “… The unique code/token may then be transmitted by the mobile device 110 to the merchant computer system 140 as part of a transaction to facilitate authentication of the transaction…”)
Kurani et al does not disclose, however, Lopreiato et al., as shown, teaches the following limitations:
[wherein] … and the reader circuitry provides the script and the second token to the payment device during a second inductive coupling of the contactless interface with the payment device (Fig.7, items 708, 710; [0063] “…At block 708, the token service provider computer 104 may establish or update a database entry for the token number selected or generated at 706, such that the new token number is mapped to the same PAN to which the replaced token number was previously mapped…”, [0064] “…At block 710, the token service provider computer 104 (or in some cases the payment account issuer) may provision the new token to the user's payment-enabled mobile device. In the course of the provisioning of the new token to the mobile device, other data may also be provisioned to the mobile device, including, for example, a token expiration date for the new token, an updated cryptographic key or keys, etc.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for establishing or updating a database entry by the token service provider computer for the token number selected or generated, such that the new token number, and provisioning the new token to the user's payment-enabled mobile device and an updated cryptographic key or keys, etc. (‘663, [0063]-[0064]).
36. As per claim 5:
Kurani et al. discloses the following limitations:
wherein the reader circuitry comprises a contact interface having a power and communication circuitry (Fig.1, items 140, 142; [0043] “… the merchant computer system 140 may include a mobile computing device (e.g., smart phone, tablet PC, etc.) …”, [0044] “The merchant computer system 140 includes network interface logic 142, a code scanner 144, location indicator logic 146, fund requesting logic 148, and fund receiving logic 149. In one embodiment, the network interface logic 142 is configured to allow the merchant computer system 140 to communicate with the network 140. The network interface logic 142 sends and receives data from the mobile device 110 and the mobile wallet bank computer system 120.”)
37. As per claim 8:
Kurani et al. discloses the following limitations:
further comprising a cryptographic processing unit that executes third computer-readable instructions for performing cryptographic functions during the processing of payment transactions (Fig.1, item 144; [0045] “The code scanner 144 may be configured to scan codes, such as but not limited to, optically scanned or non-optically scanned codes. In the embodiment of the present disclosure, the code scanner 204 scans one or more types of codes. After receiving the code, the scanner 144 determines the information that was incorporated into the code by the mobile device 110 or the mobile wallet bank computer system 120 that generated the code…”)
38. As per claim 11:
Kurani et al. discloses the following limitations:
interfacing a payment device to a reader device during a payment transaction (Fig.1, items 110, 116, 140; [0033] “…Upon initiation of a transaction, the client application 116 may request data from the mobile wallet computer system 120 to generate a unique code/token…” [0034] “The mobile wallet client application 116 is used in connection with merchant computer system 140 located at a brick and mortar store location…”)
obtaining a first token stored in a memory of the payment device ([0033] “… The unique code/token may then be transmitted by the mobile device 110 to the merchant computer system 140 as part of a transaction to facilitate authentication of the transaction…”, [0068] “… A device and customer token are stored on each device…”)
authenticating the payment device using the first token (Fig.2, items 110, 120, 140, 145, 202; [0061] “The use of the payment token and trace ID as described herein allows for two levels of authentication. The payment token is generated by the mobile wallet computer system at step 202. The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120 where it is matched with the original payment token generated at step 202.”)
providing, by the reader device, the first token from the payment device to a server (Fig.2, items 110, 120; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”
receiving, by the reader device, a script and a second token for the payment device from the server (Fig.3, items 308, 310; [0068] “Process 300 further includes generating a customer token and device token (step 308), and sending the customer token and device token to the mobile device of the user (step 310). The customer token and device token may be tokens that identify the user and the associated mobile device to the mobile wallet bank computer system in the future…”, [0069] “Process 300 further includes receiving a default payment method from the user (step 312) and completing the registration (step 314).”, wherein the script includes at least one instruction for a processing unit of the payment device to store the second token in the memory of the payment device ([0016] “FIG. 6 illustrates a Track 2 format for a generated QR code that may be created in the token generation process, according to an example embodiment.”, [0068] “…The tokens are encrypted by the mobile wallet bank computer system and provided to the mobile device. The mobile device stores the tokens for future use…”, [0069] “…Step 314 may include a user accepting terms and conditions associated with use of the mobile wallet account…”)
Kurani et al does not disclose, however, Lopreiato et al., as shown, teaches the following limitations:
processing the script and the second token ([0064] “… In the course of the provisioning of the new token to the mobile device, other data may also be provisioned to the mobile device, including, for example, a token expiration date for the new token, an updated cryptographic key or keys, etc.”)
communicating, by the reader device, the script and the second token received from the server to the payment device (Fig.7, item 710, [0064] “…At block 710, the token service provider computer 104 (or in some cases the payment account issuer) may provision the new token to the user's payment-enabled mobile device.
executing, by the processing unit of the payment device, the script communicated by the reader device to store the second token in the memory of the payment device for a subsequent payment transaction (Fig.7, items 708, 710; [0063] “…At block 708, the token service provider computer 104 may establish or update a database entry for the token number selected or generated at 706, such that the new token number is mapped to the same PAN to which the replaced token number was previously mapped…”, [0064] “…At block 710, the token service provider computer 104 (or in some cases the payment account issuer) may provision the new token to the user's payment-enabled mobile device. In the course of the provisioning of the new token to the mobile device, other data may also be provisioned to the mobile device, including, for example, a token expiration date for the new token, an updated cryptographic key or keys, etc.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for establishing or updating a database entry by the token service provider computer for the token number selected or generated, such that the new token number, and provisioning the new token to the user's payment-enabled mobile device and an updated cryptographic key or keys, etc. (‘663, [0063]-[0064]).
39. As per claim 12:
Kurani et al. discloses the following limitations:
wherein the payment device is a near field communication (NFC) device and the reader device comprises a contactless interface having at least one antenna ([0038] “…As will be appreciated, any suitable method may be used to transmit the code. In various embodiments, the code may be transmitted using optical image methods (e.g., QR code), NFC, wireless, Bluetooth, low energy Bluetooth, RFID, hypersonic, Wi-Fi, cellular 3G, 4G, GSM, LiFi, etc…”)
40. As per claim 13:
Kurani et al. discloses the following limitations:
wherein interfacing the payment device to the reader device includes inductively coupling the NFC device with the contactless interface of the reader device to enable wireless communication between the reader device and the NFC device (Fig.1, items 110, 140; [0028] “The payment processing system 100 may include, among other systems, a mobile device 110, a mobile wallet bank computer system 120, a source account bank computer system 130, a merchant computer system 140, an acquirer/processor computer system 145 and a payment system 150. The various systems may communicate through a network 160, which may include one or more of the Internet, cellular network, Wi-Fi, Wi-Max, a proprietary banking network, or any other type of wired or wireless network…”)
41. As per claim 14:
Kurani et al. discloses the following limitations:
wherein obtaining the first token includes obtaining the first token stored in the NFC device during a first inductive coupling of the reader device and the NFC device during a first inductive coupling of the reader device… ([0033] “… The unique code/token may then be transmitted by the mobile device 110 to the merchant computer system 140 as part of a transaction to facilitate authentication of the transaction…”)
Kurani et al does not disclose, however, Lopreiato et al., as shown, teaches the following limitations:
[wherein] … and communicating the script and the second token includes providing the script and the second token to the NFC device during a second inductive coupling of the reader device and the NFC device (Fig.7, items 708, 710; [0063] “…At block 708, the token service provider computer 104 may establish or update a database entry for the token number selected or generated at 706, such that the new token number is mapped to the same PAN to which the replaced token number was previously mapped…”, [0064] “…At block 710, the token service provider computer 104 (or in some cases the payment account issuer) may provision the new token to the user's payment-enabled mobile device. In the course of the provisioning of the new token to the mobile device, other data may also be provisioned to the mobile device, including, for example, a token expiration date for the new token, an updated cryptographic key or keys, etc.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for establishing or updating a database entry by the token service provider computer for the token number selected or generated, such that the new token number, and provisioning the new token to the user's payment-enabled mobile device and an updated cryptographic key or keys, etc. (‘663, [0063]-[0064]).
42. As per claim 15:
Kurani et al. discloses the following limitations:
wherein the payment device is a payment card comprising a chip and the reader device comprises a contact interface having a power and communication circuitry (Fig.1, items 140, 142; [0043] “… the merchant computer system 140 may include a mobile computing device (e.g., smart phone, tablet PC, etc.) …”, [0044] “The merchant computer system 140 includes network interface logic 142, a code scanner 144, location indicator logic 146, fund requesting logic 148, and fund receiving logic 149. In one embodiment, the network interface logic 142 is configured to allow the merchant computer system 140 to communicate with the network 140. The network interface logic 142 sends and receives data from the mobile device 110 and the mobile wallet bank computer system 120.”)
43. As per claim 18:
Kurani et al. discloses the following limitations:
further comprising performing cryptographic functions during processing of payment transactions with a cryptographic processing unit of the reader device (Fig.1, item 144; [0045] “The code scanner 144 may be configured to scan codes, such as but not limited to, optically scanned or non-optically scanned codes. In the embodiment of the present disclosure, the code scanner 204 scans one or more types of codes. After receiving the code, the scanner 144 determines the information that was incorporated into the code by the mobile device 110 or the mobile wallet bank computer system 120 that generated the code…”)
44. Claim 6-7 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US20230153792A1 to Kurani et al. in view of US20150339663A1 to Lopreiato et al. and US20160267486A1 to Mitra et al.
45. As per claim 6:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Mitra et al., as shown, teaches the following limitations:
further comprising a slot to receive the payment device (Fig.2, item 234), wherein the contact interface of the reader circuitry interfaces with contacts on a chip of the payment device when the payment device is inserted in the slot (Fig.2, items 210, 234, 246, fig.5B; [0052] “… For use the universal smartcard 234 is inserted in the smartjacket 210 and connected via a wired contact connection 246…”, [0070] “…The aesthetics of the jacket can complement the card. In various embodiments, the smartjacket includes one or more of the following components: … b.) a slot to firmly hold the smartcard and ISO connector plate, which among other uses, is used to physically connect the Smartcard and can be used to correctly orient the smartcard to the smartjacket when inserted…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a smartcard that transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFi, and the jacket acts as a holder as well as an external battery source and in some embodiments has a set of input commands used for various functions of Mitra et al. (‘486, [0016]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for including into the payment device a smartjacket that designed to hold the smartcard as an external body and a slot to firmly hold the smartcard to physically connect the Smartcard and can be used to correctly orient the smartcard to the smartjacket when inserted (‘486, [0070]).
46. As per claim 7:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Mitra et al., as shown, teaches the following limitations:
wherein the power and communication circuitry of the contact interface provides power to the payment device via at least one contact on the chip of the payment device (Fig.2, items 230, 234, 246, fig.5B; [0051] “…The power-management application 230 is used to extend the battery life on the universal smartcard 234, by powering off the secure element 236 of the universal smartcard 234 when not in use.”, [0070] “…The aesthetics of the jacket can complement the card. In various embodiments, the smartjacket includes one or more of the following components: …c.) A battery for the charging of the smartcard and powering features such as the Microprocessor or any wireless communication systems; d.) a Bluetooth smart chip for low energy data transfer between the Smartcard and other trusted mobile devices…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a smartcard that transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFi, and the jacket acts as a holder as well as an external battery source and in some embodiments has a set of input commands used for various functions of Mitra et al. (‘486, [0016]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004])) for including into the payment device a smartjacket that designed to hold the smartcard as an external body and a slot to firmly hold the smartcard to physically connect the Smartcard and the power-management application is used to extend the battery life on the universal smartcard when inserted (‘486, [0051], [0070]).
47. As per claim 16:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Mitra et al., as shown, teaches the following limitations:
wherein interfacing the payment device to the reader device includes inserting the payment card into a corresponding slot of the reader device to enable contacts of the chip to engage with corresponding contacts of the contact interface (Fig.2, items 210, 234, 246, fig.5B; [0052] “… For use the universal smartcard 234 is inserted in the smartjacket 210 and connected via a wired contact connection 246…”, [0070] “…The aesthetics of the jacket can complement the card. In various embodiments, the smartjacket includes one or more of the following components: … b.) a slot to firmly hold the smartcard and ISO connector plate, which among other uses, is used to physically connect the Smartcard and can be used to correctly orient the smartcard to the smartjacket when inserted…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a smartcard that transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFi, and the jacket acts as a holder as well as an external battery source and in some embodiments has a set of input commands used for various functions of Mitra et al. (‘486, [0016]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for including into the payment device a smartjacket that designed to hold the smartcard as an external body and a slot to firmly hold the smartcard to physically connect the Smartcard and can be used to correctly orient the smartcard to the smartjacket when inserted (‘486, [0070]).
48. As per claim 17:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Mitra et al., as shown, teaches the following limitations:
further comprises providing power to the payment device with the power and communication circuitry via at least one contact on the chip of the payment device (Fig.2, items 230, 234, 246, fig.5B; [0051] “…The power-management application 230 is used to extend the battery life on the universal smartcard 234, by powering off the secure element 236 of the universal smartcard 234 when not in use.”, [0070] “…The aesthetics of the jacket can complement the card. In various embodiments, the smartjacket includes one or more of the following components: …c.) A battery for the charging of the smartcard and powering features such as the Microprocessor or any wireless communication systems; d.) a Bluetooth smart chip for low energy data transfer between the Smartcard and other trusted mobile devices…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a smartcard that transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFi, and the jacket acts as a holder as well as an external battery source and in some embodiments has a set of input commands used for various functions of Mitra et al. (‘486, [0016]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004])) for including into the payment device a smartjacket that designed to hold the smartcard as an external body and a slot to firmly hold the smartcard to physically connect the Smartcard and the power-management application is used to extend the battery life on the universal smartcard when inserted (‘486, [0051], [0070]).
49. Claim 9-10 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20230153792A1 to Kurani et al. in view of US20150339663A1 to Lopreiato et al. and US20150312038A1 to Palanisamy.
50. As per claim 9:
Kurani et al. discloses the following limitations:
encrypting the first token received from the payment device prior to the first token being provided to the server (Fig.2, items 110, 120; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”, [0068] “… The tokens are encrypted by the mobile wallet bank computer system and provided to the mobile device. The mobile device stores the tokens for future use…”)
[decrypting] the script and the second token received from the server prior to the script and the second token being provided to the payment device (Fig.3, items 308, 310; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”, [0068] “Process 300 further includes generating a customer token and device token (step 308), and sending the customer token and device token to the mobile device of the user (step 310). The customer token and device token may be tokens that identify the user and the associated mobile device to the mobile wallet bank computer system in the future…”, [0069] “Process 300 further includes receiving a default payment method from the user (step 312) and completing the registration (step 314).”
Neither Kurani et al., nor Lopreiato et al. disclose, however, Palanisamy, as shown, teaches the following limitations:
decrypting the script and the second token … (Fig.7, item 708; [0078] “…Once the decrypted session key is obtained, at block 708, the decrypted session key can be used to decrypt the token or sensitive information retrieved from memory…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a method for enhancing the security of storing sensitive information or a token on a communication device may include sending a request for the sensitive information or token of Palanisamy (‘038, [0005]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for decrypting the encrypted token or sensitive information retrieved from memory by using the decrypted session key and the decrypted token or sensitive information can stored (‘038, [0078]).
51. As per claim 10:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Palanisamy, as shown, teaches the following limitations:
wherein the first token is a permanent token that does not have a predetermined expiration time and the script provided to the payment device reprograms the payment device causing the payment device to replace the permanent token with the second token ([0030] “‘Token attributes’ may include any feature or information about a token. For example, token attributes may include any information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction processing system. For example, token attributes may determine how a token may be used in place of a real account identifier (e.g., PAN) for a transaction. For example, the token attributes may include a type of token, frequency of use, token expiration date and/or expiration time, a number of associated tokens, a transaction life-cycle expiration date, and any additional information that may be relevant to any entity within a transaction processing system”, [0086] “Token requestor 804 may be configured to request a new token or request life-cycle management actions for an existing token (e.g., change an existing token, deactivate a token, etc.). In some embodiments, token requestor 804 may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token. Network token system 802 may use the token requestor ID to identify and validate token requestor 804 as well as validate a token based transaction when processing a transaction conducted with a token.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a method for enhancing the security of storing sensitive information or a token on a communication device may include sending a request for the sensitive information or token of Palanisamy (‘038, [0005]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for changing an existing token to a new token based on a transaction processing information that can determine how the existing token is used (‘038, [0086]).
52. As per claim 19:
Kurani et al. discloses the following limitations:
encrypting, using the cryptographic functions, the first token received from the payment device prior to the first token being provided to the server (Fig.2, items 110, 120; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”, [0068] “… The tokens are encrypted by the mobile wallet bank computer system and provided to the mobile device. The mobile device stores the tokens for future use…”)
[decrypting] the script and the second token received from the serve prior to the script and the second token being communicated to the payment device (Fig.3, items 308, 310; [0061] “…The payment token is then transmitted to the mobile device 110, then to the merchant computer system 140, then to the acquirer processor computer system 145, and eventually back to the mobile wallet computer system 120…”, [0068] “Process 300 further includes generating a customer token and device token (step 308), and sending the customer token and device token to the mobile device of the user (step 310). The customer token and device token may be tokens that identify the user and the associated mobile device to the mobile wallet bank computer system in the future…”, [0069] “Process 300 further includes receiving a default payment method from the user (step 312) and completing the registration (step 314).”
Neither Kurani et al., nor Lopreiato et al. disclose, however, Palanisamy, as shown, teaches the following limitations:
decrypting the script and the second token … (Fig.7, item 708; [0078] “…Once the decrypted session key is obtained, at block 708, the decrypted session key can be used to decrypt the token or sensitive information retrieved from memory…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a method for enhancing the security of storing sensitive information or a token on a communication device may include sending a request for the sensitive information or token of Palanisamy (‘038, [0005]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for decrypting the encrypted token or sensitive information retrieved from memory by using the decrypted session key and the decrypted token or sensitive information can stored (‘038, [0078]).
53. As per claim 20:
Neither Kurani et al., nor Lopreiato et al. disclose, however, Palanisamy, as shown, teaches the following limitations:
wherein the first token is a permanent token that does not have a predetermined expiration time and wherein executing the script includes reprogramming the payment device causing the payment device to replace the permanent token with the second token ([0030] “‘Token attributes’ may include any feature or information about a token. For example, token attributes may include any information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction processing system. For example, token attributes may determine how a token may be used in place of a real account identifier (e.g., PAN) for a transaction. For example, the token attributes may include a type of token, frequency of use, token expiration date and/or expiration time, a number of associated tokens, a transaction life-cycle expiration date, and any additional information that may be relevant to any entity within a transaction processing system”, [0086] “Token requestor 804 may be configured to request a new token or request life-cycle management actions for an existing token (e.g., change an existing token, deactivate a token, etc.). In some embodiments, token requestor 804 may provide an account identifier (e.g., a PAN) and an expiration date with a request for a new token. Network token system 802 may use the token requestor ID to identify and validate token requestor 804 as well as validate a token based transaction when processing a transaction conducted with a token.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for maintaining a token database in a computer system, where the token database maps tokens to primary account numbers (PANs) for payment card accounts, and the token being mapped by the respective entry to a respective PAN and the respective PAN identifies a payment card account that belongs to a cardholder who uses a mobile device of Lopreiato et al. (‘663, abstract) and a method for enhancing the security of storing sensitive information or a token on a communication device may include sending a request for the sensitive information or token of Palanisamy (‘038, [0005]) with teaching of Kurani et al. for receiving an indication from a user that the user wishes to perform a mobile wallet transaction to transfer funds to a recipient using a mobile device (‘792, [0004]) for changing an existing token to a new token based on a transaction processing information that can determine how the existing token is used (‘038, [0086]).
Conclusion
54. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20190095607A1 – Howard – Discloses a system for generating subtokens and/or sets of protocols to be provided to connected devices for use in subsequent transactions, wherein a mobile device identifies one or more connected devices via a discovery process.
US20180107994A1 – Anderson et al. – Discloses a method for application of account and transaction controls on a payment token includes: storing, in a first device of a system, a control profile including a token number and transaction controls; storing, in a second device of the system, a token profile including the token number and a corresponding account number.
US20180211247A1 – England et al. – Discloses a method establishing dedicated connection for token replacement including receive user authentication credentials; validate the user authentication credentials; in response to validation, enable access to one or more features or functions of a mobile application.
US20190197518A1 – Puehse et al. – Discloses a system including: a stored value token having an associated token value; a token validation server; and a computing device in communication with the token validation server; wherein the computing device is configured to: read token data comprising a token identifier and a token status from the stored value token; validate the stored value token.
US20210012315A1 – Priebatsch – Discloses a method of facilitating payment by a user registered with the server include, at the server, generating and storing, for the user, a code readable by a merchant device, transmitting the code to a mobile device of the user, facilitating provision of information characterizing a payment instrument from the user.
US20180268405A1 – Lopez – Discloses methods, systems, and devices for replacing a token on a user device, such as a transaction card, wherein the transaction card includes tokens representing an actual account identifier which is not visible on the transaction card.
55. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
56. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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 D 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692