Constraining transactional capabilities for contactless cards

Abstract

To provide systems, methods, articles of manufacture, and computer-readable media for constraining transactional capabilities for contactless cards.SOLUTION: In a system 100, a communications interface for contactless cards receives, from a server, an indication that the server has preauthorized a transaction, and receives, from a point of sale (POS) device, an indication to pay for the transaction. The contactless card determines, based on rules stored in a memory, that a location of the mobile device is within one or more locations the contactless card is permitted for use. The contactless card generates transaction data including indications of an account number and an expiration date of the contactless card, and the indication of the preauthorization, and transmits the transaction data to the POS device as payment for the transaction. The server authorizes payment for the transaction using at least a part of the transaction data based at least in part on identifying the indication of the preauthorization in the transaction data.SELECTED DRAWING: Figure 1A

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Patent Application No. 16 / 503,142, entitled "LIMITING CONTACTLESS CARD TRANSACTION FUNCTIONALITY," filed July 3, 2019. The contents of the aforementioned patent application are incorporated herein by reference in their entirety. [Technical Field]

[0002] TECHNICAL FIELD Embodiments herein relate generally to contactless cards, and more particularly to limiting transaction functionality of contactless cards. [Background technology]

[0003] Cardholders (e.g., credit card holders, bank card holders, etc.) often obtain additional physical cards and / or virtual card numbers for trusted individuals, such as family members and employees. However, in such cases, security risks may arise. Conventional solutions do not provide the necessary security mechanisms to ensure that the physical cards and / or virtual card numbers are used in accordance with any defined restrictions. Summary of the Invention

[0004] Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for restricting transaction functionality of a contactless card. In one example, a communication interface may receive, from a mobile device running an account application, an indication that a server has pre-approved a transaction based on authentication of location data describing the location of the mobile device and encrypted data. The encrypted data is generated by the contactless card using a cryptographic algorithm and a private key stored in the contactless card's memory, and one or more credentials related to an account associated with the contactless card are received by the account application. The communication interface may receive, from a point-of-sale (POS) device, an indication to settle the transaction using the contactless card. The contactless card may determine, based on one or more rules stored in the memory, that the location of the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized. The contactless card may generate transaction data including (i) an indication of the account number and expiration date of the contactless card, and (ii) an indication of pre-approval of the transaction by the server. The contactless card may transmit transaction data to the POS device as settlement of the transaction, and the server authorizes settlement of the transaction using at least a portion of the transaction data based at least in part on identifying in the transaction data an indication of pre-approval of the transaction by the server. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1A illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 1B] FIG. 1B illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 1C] FIG. 1C illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 1D] FIG. 1D illustrates an embodiment of a system for restricting contactless card transaction functionality. [Figure 2A]FIG. 2A illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 2B] FIG. 2B illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 3A] FIG. 3A illustrates an embodiment of a system for restricting transaction functionality of a contactless card. [Figure 3B] FIG. 3B illustrates an embodiment of a system for restricting contactless card transaction functionality. [Figure 3C] FIG. 3C illustrates an embodiment of a system for restricting contactless card transaction functionality. [Figure 3D] FIG. 3D illustrates an embodiment of a system for restricting contactless card transaction functionality. [Figure 4] FIG. 4 illustrates a first logic flow embodiment. [Figure 5] FIG. 5 illustrates a second logic flow embodiment. [Figure 6] FIG. 6 illustrates a third logic flow embodiment. [Figure 7] FIG. 7 illustrates a fourth logic flow embodiment. [Figure 8] FIG. 8 illustrates a fifth logic flow embodiment. [Figure 9] FIG. 9 illustrates an embodiment of a computing architecture. [Figure 10A] FIG. 10A shows an example of a contactless card. [Figure 10B] FIG. 10B shows an example of a contactless card. DETAILED DESCRIPTION OF THE INVENTION

[0006] Embodiments disclosed herein provide secure techniques for restricting the transaction capabilities of contactless cards. Generally, contactless cards are programmable to include restrictions on the use of the contactless card. The restrictions may include geographic (or location) restrictions, amount restrictions, and / or time restrictions. When a cardholder attempts to use the contactless card, logic in the contactless card may determine whether use is permitted against the restrictions. For example, the contactless card may periodically communicate with a mobile device running an account management application. The contactless card may periodically receive location data from the account management application. The location data indicates the location of the mobile device (and / or contactless card). When a cardholder attempts to use the contactless card, logic in the contactless card may determine whether the received location data is in one or more geographic locations where use of the contactless card is permitted. For example, the contactless card may be limited to use within a five-mile radius of the cardholder's home. If the received location data indicates that the mobile device and / or contactless card is 10 miles from home, the contactless card may refuse to process the attempted transaction. Similarly, if the location data indicates that the mobile device and / or contactless card is 1 mile from home, the contactless card may allow the attempted transaction.

[0007] In some embodiments, the location data may be used as part of a transaction pre-authorization process. For example, when purchasing an expensive item, such as a watch, a user may tap a contactless card to a mobile device running an account application to pre-authorize the high-value transaction. The account application may receive encrypted data generated by the contactless card. The account application may transmit the encrypted data describing the current location of the mobile device and the location data to a server. The server may decrypt the encrypted data and thereby validate the encrypted data. The server may further determine that the location data indicates that the mobile device and / or the contactless card are within one or more locations where contactless card use is permitted. Similarly, the server may authenticate the purchase amount and / or time period requested for pre-authorization. The server may determine to pre-authorize the transaction using the contactless card and send an indication of pre-authorization to the account application running on the mobile device. The indication of pre-authorization may be sent from the mobile device to the contactless card. If the contactless card determines that the card is being used to settle a transaction, it may write a pre-authorization indication into one or more fields of a payment payload sent to a point-of-sale (POS) device. The POS device may send the payment payload containing the pre-authorization indication to a server. The server may approve settlement of the transaction based at least in part on identifying the pre-authorization indication in the payment payload. The server may further authenticate data received from the mobile device (e.g., requested purchase amount, time, location, etc.) in response to tapping the contactless card during the attempted purchase. The server may then send an approval indication to the POS device.

[0008] Advantageously, the embodiments disclosed herein improve the security of all devices and associated data. For example, pre-authorization techniques may mitigate fraud and / or security risks of contactless cards. As another example, authentication performed by a server provides a safeguard to ensure that authorized users can access physical cards. Furthermore, by enforcing rules related to the use of physical cards and / or virtual account numbers, the security of associated accounts is maintained.

[0009] With general reference to the notation and nomenclature used herein, one or more portions of the detailed descriptions which follow may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is herein, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0010] Further, these operations are often referred to in terms, such as adding or comparing, commonly associated with human mental activities. However, no such capability of a human operator is necessary, or even desirable in most cases, for any of the operations described herein that form part of one or more of the embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein and written in accordance with the teachings herein, and / or specially constructed apparatus or digital computers for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for these various machines will be apparent from the description given.

[0011] Referring to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It will be apparent, however, that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate description thereof. It is intended to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0012] FIG. 1A illustrates a schematic diagram of an exemplary system 100 consistent with disclosed embodiments. As illustrated, the system 100 includes one or more contactless cards 101, one or more mobile devices 110, a server 120, and one or more POS devices 140. The contactless cards 101 represent any type of payment card, such as a credit card, a debit card, an ATM card, or a gift card. The contactless cards 101 may include one or more communication interfaces 105-2, such as a radio frequency identification (RFID) chip, configured to communicate with a communication interface 105-1 of the mobile device 110 via NFC, the EMV standard, or other short-range protocols for wireless communication. While NFC is used as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and / or Wi-Fi. The mobile devices 110 represent any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, a mobile device, or the like. Server 120 represents any type of computing device, such as a server, a workstation, a computer cluster, a cloud computing platform, a virtualized computing system, etc. POS device 140 represents any type of device for processing payments, such as a card reader device, a smartphone, a tablet computer, a desktop computer, a POS terminal, a server, a workstation, a laptop computer, etc.

[0013] As shown, the memory 111 of the mobile device 110 includes an instance of an account application 113. The account application 113 allows a user to perform various account-related operations, such as viewing account balances, purchasing items, processing payments, defining limits for the contactless card 101, communicating location data to the contactless card 101, and communicating with the server 120 for pre-authorization. Initially, a user may authenticate using authentication credentials to access certain features of the account application 113. For example, the authentication credentials may include a username and password, biometric credentials (e.g., fingerprint, Face ID, etc.), etc. In some embodiments, a user may perform additional authentication (e.g., multi-factor authentication) in addition to the authentication credentials. For example, a user may provide the account application 113 with a one-time passcode received via text message, biometric credentials associated with the account, and / or a temporary code generated by an authentication application (not shown). In some embodiments, the contactless card 101 may generate and transmit encrypted data 108 to be used as an additional authentication factor. In some embodiments, the account application 113 may send an indication to the contactless card 101 identifying that the user has been authenticated using the authentication credentials.

[0014] When a user authenticates to their account in the account application 113, the account application 113 may receive location data from the location module 114. The location data may generally describe the location of the mobile device 110. The location module 114 may be any device that determines location, such as a Global Positioning System (GPS) module, a Global Navigation Satellite System (GNSS) module, a Galileo module, etc. In some embodiments, the network interface 112 may provide location data describing the location of the mobile device (e.g., based on cellular network signals, tower locations, etc.). The account application 113 may periodically provide the generated location data to the contactless card 101 via the communication interfaces 105-1, 105-2. As described in more detail below, the contactless card 101 may use the location data to restrict transaction capabilities of the contactless card 101. For example, the rules 107-1 of the contactless card 101 may specify one or more locations where the contactless card 101 may be used to settle a transaction. If the received location data is not within one or more location ranges (and / or within one or more location threshold distances) specified in Rule 107-1, the contactless card 101 may refrain from generating and / or transmitting data to the POS device 140 for settlement of the transaction.

[0015] In one embodiment, a user may wish to obtain pre-approval for a purchase using contactless card 101. For example, a user may wish to purchase expensive jewelry at a jewelry store using contactless card 101. To receive pre-approval, the user may typically unlock mobile device 110 and authenticate with account application 113. In some embodiments, the pre-approval page may not be a page of account application 113, but may be part of another application. In response, account application 113 may output a notification to mobile device 110 specifying that contactless card 101 be tapped to mobile device 110, thereby bringing contactless card 101 sufficiently close to communication interface 105-1 of mobile device 110 to enable data transfer (e.g., NFC data transfer, Bluetooth data transfer, etc.) between communication interface 105-2 of contactless card 101 and communication interface 105-1 of mobile device 110. An authorization applet 104 executing on a processor (not shown) of the contactless card 101 may then generate and transmit encrypted data 108 to the mobile device 110 via the communication interface 107. The authorization applet 104 of the contactless card 101 may use a cryptographic algorithm to generate a cryptographic payload of the encrypted data 108 based at least in part on a private key stored in the memory 102 of the contactless card 101. In such an embodiment, the private key and other data (e.g., a customer identifier, an account identifier, etc.) may be provided as input to the cryptographic algorithm, which outputs the encrypted data 108. In general, the authorization applet 104 can generate the encrypted data 108 using any type of cryptographic algorithm and / or system, and the use of a particular cryptographic algorithm as an example herein should not be considered limiting of the present disclosure. In some embodiments, the authorization applet 104 may perform encryption using key diversification techniques to generate the encrypted data 108.Examples of key diversification techniques are described in U.S. patent application Ser. No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated by reference herein in its entirety. In one embodiment, the authorization applet 104 generates the encrypted data 108 based at least in part on an indication received from the account application 113 specifying that the user has authenticated to their account using the account credentials.

[0016] In some such embodiments, authorization applet 104 determines whether the most recently received location data is within one or more locations specified in rule 107-1 as locations where contactless card 101 is authorized for use. If the location data is within one or more locations specified in rule 107-1, authorization applet 104 may generate encrypted data 108. If the location data is not within one or more locations specified in rule 107-1, to maintain security, authorization applet 104 may refrain from generating encrypted data 108. Additionally, authorization applet 104 may apply other rules in rule 107-1 when determining whether to generate encrypted data 108. For example, rule 107-1 may specify the times when contactless card 101 may be used (e.g., between 8:00 AM and 5:00 PM on weekdays, within one year of issuance, etc.). As another example, rule 107-1 may specify a monetary limit for any transaction (or transactions) using contactless card 101. If the current time is not within the time period specified in rule 107-1, authorization applet 104 may refrain from generating encrypted data 108. Similarly, if the user provides an amount for pre-authorization to account application 113 (which may be sent to contactless card 101) that exceeds the amount limit specified in rule 107-1, authorization applet 104 may refrain from generating encrypted data 108.

[0017] Once generated, the authorization applet 104 may transmit the encrypted data 108 to the account application 113 of the mobile device 110, for example, via NFC. For example, the authorization applet 104 may transmit the encrypted data 108 in an NDEF tag that instructs the operating system (OS, not shown) of the mobile device 110 to launch the account application 113 to receive the encrypted data 108. More generally, when communicating with the mobile device 110, the data generated by the contactless card 101 may be specified (e.g., via an intent attribute) to launch the account application 113. The OS may detect the NFC signal from the contactless card 101, read the data sent by the contactless card 101, and launch the account application 113.

[0018] The account application 113 may send the encrypted data 108 and the location data 115 generated by the location module 114 to the authorization application 123 of the server 120. The account application 113 may also send other data, such as the amount requested for pre-authorization, to the server 120. The authorization application 123 may attempt to authenticate the received encrypted data 108. For example, the authorization application 123 may attempt to decrypt the encrypted data 108 using a copy of a private key stored in the memory 122 of the server 120. This private key may be the same as the private key stored in the memory 102 of the contactless card 101, with each contactless card 101 being made to include a unique private key (and the server 120 stores a corresponding copy of each unique private key). Thus, the authorization application 123 may successfully decrypt the encrypted data 108, thereby authenticating the encrypted data 108. Although the private key is described as being stored in memory 122, it may be stored elsewhere, such as in a secure element and / or a hardware security module (HSM). In such embodiments, the secure element and / or HSM may use the private key and a cryptographic function to decrypt the encrypted data 108.

[0019] For example, as described above, the encrypted data 108 may be generated using a customer identifier associated with the contactless card 101. In such an example, the authorization application 123 may decrypt the encrypted data 108 using the private key of the server 120. If the decryption results in a customer identifier associated with the account in the account data 124, the authorization application 123 authenticates the encrypted data 108. If the authorization application 123 cannot decrypt the encrypted data to produce the expected result (e.g., a customer identifier for the account associated with the contactless card 101), the authorization application 123 does not authenticate the encrypted data 108. Failure to authenticate may cause the authorization application 123 to not pre-approve the requested transaction.

[0020] More generally, as part of the pre-authorization process, the authorization application 123 may determine whether the location data 115 is within one or more locations specified in rule 107-2 of the account data 124 of the account as locations where the contactless card 101 is authorized for use. If the location information is within one or more locations specified in rule 107-2, the authorization application 123 pre-authorizes the transaction. If the location information is not within one or more locations specified in rule 107-1, to maintain security, the authorization application 123 may refrain from pre-authorizing the transaction. Similarly, if the time restriction for using the contactless card 101 in rule 107-2 is not met by the time associated with the pre-authorization request, the authorization application 123 may refrain from pre-authorizing the transaction. Additionally, if the transaction amount restriction is not met by the amount associated with the pre-authorization request, the authorization application 123 may refrain from pre-authorizing the transaction.

[0021] In some embodiments, the authorization application 123 may return a binary indication of pre-approval (e.g., pre-approved and / or not pre-approved) as the pre-approval result. In other embodiments, the authorization application 123 may select a pre-approval level from one or more pre-approval levels as the pre-approval result. For example, the highest level of pre-approval may be selected when the authorization application 123 successfully decrypts the encrypted data 108 and determines that the pre-approval request complies with the restrictions of Rule 107-2. As another example, a second level of pre-approval, which is lower than the highest level of pre-approval, may be selected when the authorization application 123 successfully decrypts the encrypted data 108 and determines that the pre-approval request does not comply with at least one of the restrictions of Rule 107-2. As another example, a third level of pre-approval, which is lower than the highest level of pre-approval, may be selected when the authorization application 123 does not successfully decrypt the encrypted data 108 and determines that the pre-approval request complies with the restrictions of Rule 107-2. As another example, a lowest level of pre-approval, lower than the highest, second, and third levels of pre-approval, may be selected if the authorization application 123 does not successfully decrypt the encrypted data 108 and determines that the pre-approval request does not comply with at least one of the restrictions in Rule 107-2. Regardless of the type of pre-approval result, in some embodiments, the authorization application 123 may perform additional fraud vector analysis and pre-approve and / or deny pre-approval of the transaction based on the additional analysis.

[0022] 1B , once the authorization application 123 authenticates the encrypted data 108 and determines a pre-authorization result, the authorization application 123 sends an indication of pre-authorization 132 to the mobile device 110. The pre-authorization result 132 may include an associated timestamp, the received location data 115, the pre-authorization amount, and other attributes as metadata. The authorization application 123 may further store the pre-authorization result 132 in the account data 124 of the account associated with the contactless card. Upon receipt, the account application 113 may output an indication to the mobile device 110 specifying that the contactless card 101 be tapped. Upon tapping, the account application 113 may send the indication of pre-authorization 132 to the authorization applet 104 of the contactless card 101. In some embodiments, the account application 113 sends the indication of pre-authorization 132 received from the server 120 to the authorization applet 104 of the contactless card 101. In other embodiments, the account application 113 may send a different indication of pre-approval 132 to the authorization applet 104 of the contactless card 101. The authorization applet 104 may then store the received indication of pre-approval 132 in the memory 102 of the contactless card.

[0023] When a user attempts a purchase, the user may bring the contactless card 101 within communication range of the communication interface 105-3 of the POS device 140. For example, the user may tap the contactless card 101 to the POS device 140 for wireless communication and / or insert the contactless card into the communication interface 105-3 of the card reader of the POS device 140. Transaction logic 144 in memory 142 of the POS device 140 may then transmit transaction data 145 to the contactless card 101. The transaction data 145 may include the transaction amount, a merchant identifier, location data of the POS device 140, a timestamp, etc. For example, the transaction data 145 may identify that the user is purchasing a $1,000 ring and may include the jeweler's merchant identifier, location data of the POS device 140 and / or the jeweler. The payment applet 106 may receive the transaction data 145 and request authorization from the authorization applet 104 to provide the card data 103 as payment for the transaction.

[0024] To determine whether to approve a transaction, the authorization applet 104 may determine whether rule 107-1 is satisfied by the transaction data 145 and / or location information data received from the mobile device 110 at periodic intervals. For example, if the $1,000 amount of the transaction exceeds the maximum spend amount in rule 107-1, the authorization applet 104 may deny the authorization requested by the payment applet 106. As another example, if the location information received from the mobile device 110 (or the location information in the transaction data 145) is outside the locations specified in rule 107-1, the authorization applet 104 may deny the authorization requested by the payment applet 106. Additionally, the authorization applet 104 may determine whether pre-approval 132 has been received for the transaction. If pre-approval 132 has been received, the authorization applet 104 may deny the authorization requested by the payment applet 106. In some embodiments, authorization applet 104 determines whether the difference between the timestamp of transaction data 145 and the timestamp of pre-authorization 132 exceeds a time threshold specified in rule 107-1. If the difference exceeds the time threshold, authorization applet 104 may deny the authorization requested by settlement applet 106.

[0025] However, if the authorization applet 104 determines that all rules 107-1 have been satisfied and / or determines that pre-authorization 132 has been received from the server 120, the authorization applet 104 may provide the authorization requested by the payment applet 106. FIG. 1C illustrates an embodiment in which the authorization applet 104 provides the authorization requested by the payment applet 106 to the payment applet 106. In response, the payment applet 106 may generate transaction data 109 that includes card data 103 and an indication of pre-authorization 132. The card data 103 may include a card number (or account number), an expiration date, and / or a card verification value (CVV). In some embodiments, the data 109 of the transaction is an EMV payload. In such embodiments, the card data 103 is inserted into one or more corresponding fields of the EMV payload, and the indication of pre-authorization 132 is stored in one or more other fields of the EMV payload. For example, the card number may be stored in tag (or field) 5A of the EMV payload, and the expiration date may be stored in tag 59 of the EMV payload. In some embodiments, the CVV is not included in the EMV payload. In other embodiments, the CVV is included in one or more other tags of the EMV payload. The pre-authorization indication may be stored in other tags of the EMV payload, such as any data field and / or padding data field of the EMV payload.

[0026] 1D illustrates an embodiment in which transaction logic 144 of POS device 140 transmits transaction data 150 to server 120 over network 130 to request approval of the requested transaction. As illustrated, transaction data 150 may include card data 103, pre-authorization 132, location data 132 describing the location of the POS device, and transaction data 145. In at least one embodiment, transaction data 150 comprises an EMV payload generated by payment applet 106. The EMV payload includes indications of card data 103 and pre-authorization 132 in one or more fields of the EMV payload. In some embodiments, mobile device 110 may transmit at least a portion of transaction data 150 (e.g., requested purchase amount, location of mobile device 110, etc.) to server 120 as part of a request for transaction approval.

[0027] Once received, the authorization application 123 may process the transaction data 150 to determine whether to approve and / or deny the transaction. Generally, the authorization application 123 may attempt to identify an indication of pre-authorization 132 within the transaction data 150. If the authorization application 123 identifies an indication of pre-authorization 132, the authorization application 123 may compare the received indication of pre-authorization 132 (or any attributes thereof) with an indication of pre-authorization 132 (or any attributes thereof) stored in the account data 124 of the account associated with the contactless card 101. If the authorization application 123 determines that a matching indication of pre-authorization 132 exists in the account data 124 of the account associated with the contactless card 101, the authorization application 123 may approve the transaction because the pre-authorization 132 at least partially reflects a pre-authentication of the encrypted data 108. The authorization application 123 may deny the transaction if it determines that there is no matching pre-authorization 132 indication in the account data 124 for the account associated with the contactless card 101. In some embodiments, the authorization application 123 may determine whether the location of the POS device 140 is within a threshold distance of the location data 115 stored as an attribute of the pre-authorization 132 in the account data 124. If the location of the POS device 140 is not within the threshold distance of the location data 115, the authorization application 123 may deny the transaction and / or require further processing of the transaction before approving it.

[0028] In other embodiments, the authorization application 123 may perform additional processing before approving and / or denying a transaction. For example, the authorization application 123 may determine whether the transaction amount exceeds the account limit and / or Rule 107-2. Similarly, the authorization application 123 may determine whether the time of the transaction is within any time restrictions for using the contactless card 101 in Rule 107-2. Similarly, the authorization application 123 may determine whether the location data of the POS device 140 is within a location specified in Rule 107-2. In some embodiments, the authorization application 123 may not receive location data from the POS device 140. In such embodiments, the authorization application 123 may determine the location of the POS device 140 based on a merchant identifier specified in a merchant entry in the account data 124 and a location associated with the merchant identifier. The authorization application 123 may then determine whether the location is within a location specified in Rule 107-2. Additionally, the authorization application 123 may perform additional fraud analysis to determine whether to approve the transaction. The authorization application 123 may then send an indication of the approval and / or denial of the transaction to the POS device 140. The POS device 140 may then send an indication of the approval and / or denial of the transaction to the contactless card 101. Additionally, the authorization application 123 may send an indication of additional details related to the approval and / or denial of the transaction to the POS device 140 (e.g., results of processing performed by the authorization application 123 for the transaction such as location analysis, analysis based on rule 107-2, etc.). The POS device 140 may then send the received indication to the contactless card 101.

[0029] 2A is a schematic diagram illustrating an example embodiment of using an account application 113 on a mobile device 110 to define rules for using a contactless card 101. As shown, the account application 113 outputs a form including fields 201-204, where field 201 corresponds to an amount field, field 202 corresponds to a location field, field 203 corresponds to a time field, and field 204 corresponds to a merchant category field. As shown, a user has provided example values of $300 in amount field 201, 10 miles from the office in location field 202, 10 days in time field 203, and a hardware store in merchant field 204. Thus, by providing values in fields 201-204, the user is specifying that the contactless card 101 can be used to spend up to $300 at a hardware store within 10 miles of the office for 10 days.

[0030] 2B is a schematic diagram 210 illustrating an embodiment in which a user submits values for fields 201-203. As shown, account application 113 may output an indication to tap contactless card 101 to mobile device 110. In doing so, authorization applet 104 may generate encrypted data 108. Account application 113 may send encrypted data 108 and the values (or an indication thereof) from fields 201-204 to server 120, which may authenticate encrypted data 108 and store the received values (or an indication thereof) in rule 107-2 for the corresponding account in the account data. Server 120 may then send an indication of authentication of encrypted data 108 to account application 113, which may output another indication to tap contactless card 101 to mobile device 110. Upon tapping, the account application 113 may send the values from fields 201-204 (or an indication thereof) to the contactless card 101, which may store the received values in rule 107-1.

[0031] 3A is a schematic diagram 300 illustrating an example of tapping a contactless card 101 to pre-authorize a transaction. As shown, the account application 113 may output an indication to tap the contactless card 101 to the mobile device 110 to pre-authorize the transaction after receiving a fingerprint to authenticate the user's account. The user may initiate a request to pre-authorize a transaction in the account application 113 to maintain account security.

[0032] When the contactless card 101 is tapped against the mobile device 110, the contactless card 101 may generate encrypted data 108 using the private key, the encryption algorithm, and the customer identifier. As described above, in some embodiments, the contactless card 101 may determine whether data received from the mobile device 110 violates one or more rules 107-1. For example, as shown, a user has specified that a transaction of $100 be pre-approved. If the value of $100 exceeds the rules of rule 107-1, the contactless card 101 may refrain from generating encrypted data 108, thereby terminating the pre-approval process. As another example, if the location data received from the mobile device 110 is not within one or more permitted locations specified in rule 107-1, the contactless card 101 may refrain from generating encrypted data 108, thereby terminating the pre-approval process.

[0033] Once generated, contactless card 101 may send encrypted data 108 to account application 113 on mobile device 110. Account application 113 may send encrypted data 108, location data, and other data (e.g., requested amount, requested merchant, etc.) to server 120. Authorization application 123 may then attempt to decrypt encrypted data 108. If encrypted data 108 is successfully decrypted to obtain a customer ID, authorization application 123 may then determine whether the location data and other received data violate any rules in rule 107-2. For example, if a request for $100 exceeds the amount specified in rule 107-2, authorization application 123 may withhold pre-approval for the transaction.

[0034] 3A , the authorization application 123 pre-approves the transaction based on decrypting the encrypted data 108 and / or determining that the request does not violate Rule 107-2. In response, the authorization application 123 stores an indication of pre-approval in the account data 124 and sends the indication of pre-approval to the account application 113 of the mobile device 110. The stored indication of pre-approval may include one or more attributes received from the mobile device, such as location data, a timestamp, a transaction amount, etc. The account application 113 may then output another indication to the mobile device 110 to tap the contactless card 101, which may store the indication of pre-approval in the memory 102 of the contactless card 101.

[0035] FIG. 3B is a schematic diagram 310 illustrating an embodiment in which a user who has received pre-approval for the transaction in FIG. 3A attempts to make a purchase at a POS device 140 using a contactless card 101. As shown, the user may tap and / or insert the contactless card 101 into the POS device 140. In doing so, the payment applet 106 receives transaction data from the POS device 140. The transaction data may represent the amount of the transaction, the time of the transaction, a merchant identifier associated with the POS device 140, and / or the location of the transaction. The payment applet 106 can then request authorization from the authorization applet 104 to proceed with the transaction. The authorization applet 104 may decide to approve the transaction based on the stored indication of pre-approval based on the results of FIG. 3A. The authorization applet 104 may further determine whether the transaction data received from the POS device 140 satisfies rule 107-2 (e.g., whether the merchant identifier corresponds to an authorized merchant class, whether the location data corresponds to an authorized location, whether the amount is an authorized amount, etc.).

[0036] The authorization applet 104 may then provide an indication of approval and / or an indication of pre-approval to the payment applet 106. The payment applet 106 may then generate an EMV payload including the card data 103 and the indication of pre-approval. The payment applet 106 may then send the EMV payload to the POS device 140. The POS device 140 may then send the EMV payload to the server 120. The POS device 140 may also send other data to the server 120, such as transaction data, location data, and merchant ID. The server 120 may then approve and / or deny the transaction based at least in part on the indication of pre-approval in the EMV payload. For example, if the server 120 identifies an indication of pre-approval, the server 120 may approve the transaction. However, if an indication of pre-approval is expected but not detected in the EMV payload, the server 120 may deny the transaction. Server 120 may further approve and / or deny the transaction based on whether the transaction satisfies and / or violates rule 107-2.

[0037] 3C is a schematic diagram 320 illustrating an embodiment in which the POS device 140 outputs an indication that the server 120 has denied the transaction. For example, the server 120 may determine that the location of the POS device 140 and / or the corresponding merchant is outside the geographic area specified in rule 107-2 in which the contactless card 101 may be used. As another example, the authorization application 123 may determine that the location of the POS device 140 and / or the corresponding merchant is not within a threshold distance of the location data stored in the account data 124 as an attribute of the pre-authorization 132. For example, if the location data of the POS device 140 and / or the merchant is 5 miles away from the location data of the pre-authorization 132, the server 120 may deny the transaction because the user is no longer within the threshold distance (e.g., 100 feet) of the location for which pre-authorization was requested. The server 120 can send an indication of denial to the POS device 140, which may output the same for display to the user.

[0038] 3D is a schematic diagram 330 illustrating an embodiment in which the POS device 140 outputs an indication that the server 120 has approved the transaction based on a pre-approval flag in the EMV payload. As previously described, the server 120 may approve the transaction based, at least in part, on whether an expected pre-approval indication is present in the EMV payload and matches a corresponding indication stored in the account data 124 when the transaction was pre-approved. However, as noted above, the server 120 may authorize the transaction based on additional factors, such as Rule 107-2 and / or other anti-fraud analyses. Once approved, the server 120 can send an indication of approval to the POS device 140, which may output the same for display to the user.

[0039] 4 illustrates one embodiment of logic flow 400. Logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 400 may include some or all of the operations for pre-approving a transaction. The embodiments are not limited in this context.

[0040] As shown, logic flow 400 begins at block 405, where authorization applet 104 generates encrypted data 108 using a secret key, input data (e.g., a customer identifier), and an encryption algorithm. Authorization applet 104 may send the encrypted data 108 to an account application 113 running on mobile device 110. In one embodiment, authorization applet 104 generates the encrypted data 108 in response to a user requesting pre-authorization after the user provides authentication credentials for their account in the account application 113. At block 410, account application 113 sends the encrypted data 108 and location data received from location module 114 to server 120 over network 130. As described above, the location data received from location module 114 describes the location of mobile device 110. In some embodiments, account application 113 may send additional data to server 120, such as the pre-authorization requested amount, the pre-authorization merchant, the pre-authorization period, and / or the pre-authorization merchant category.

[0041] At block 420, the authorization application 123 may pre-approve the transaction based at least in part on the received location data and / or the decryption of the encrypted data 108. For example, the authorization application 123 may determine whether the received location data is within one or more permitted locations for using the contactless card 101 specified in Rule 107-2. The authorization application 123 may further attempt to decrypt the encrypted data 108 using a private key associated with the contactless card 101. In one embodiment, the authorization application 123 may pre-approve the transaction based on decrypting the encrypted data 108 and determining that the location data is within one or more locations for using the contactless card 101 specified in Rule 107-2. In another embodiment, the authorization application 123 may pre-approve the transaction based on decrypting the encrypted data 108 or determining that the location data is within one or more locations for using the contactless card 101 specified in Rule 107-2. In some embodiments, authorization application 123 may additionally determine whether the pre-approval request satisfies rule 107-2, e.g., whether the requested amount, merchant, time period, and / or merchant category satisfy one or more corresponding rules in rule 107-2. As mentioned above, in some embodiments, authorization application 123 may select a pre-approval level from multiple pre-approval levels. In other embodiments, authorization application 132 may return a binary pre-approval result (e.g., pre-approved and / or not pre-approved). Authorization application 123 may then store an indication of pre-approval in account data 124 for the account. As mentioned above, the stored indication of pre-approval may include attributes such as the level of pre-approval, the time of pre-approval, location data received from the mobile device, etc.

[0042] At block 430, the account application 113 of the mobile device 110 may receive an indication of pre-approval from the server 120. The account application 113 may then send the indication of pre-approval to the contactless card 101, which stores the indication of pre-approval in memory 102. At block 440, the authorization applet 104 may receive a request to approve the transaction from the payment applet 106. Generally, the payment applet 106 may receive transaction data indicating attributes such as the transaction amount, merchant ID, location data, timestamp, etc.

[0043] At block 450, the authorization applet 104 approves the request from the payment applet based at least in part on pre-approval by the server 120 and / or the location of the mobile device 110 (and / or POS device 140). The authorization applet 104 may approve and / or deny the request based at least in part on the presence of an indication of pre-approval stored in memory 102. For example, the authorization applet 104 may determine whether the location associated with the indication of pre-approval is within a threshold distance of the most recent location data received from the mobile device 110 and / or the location data received from the POS device 140. Additionally and / or alternatively, the authorization applet 104 may determine whether the amount and / or time of the transaction received from the POS device 140 violates the amount and / or time rules in rule 107-2. Additionally and / or alternatively, authorization applet 104 may determine whether a merchant ID received from POS device 140 violates the merchant and / or merchant category rules in rule 107-2.

[0044] At block 460, the payment applet 106 generates an EMV payload including transaction data and an indication of pre-authorization. The transaction data may include the card number, expiration date, and CVV value of the contactless card 101. The payment applet 106 may send the EMV payload to the POS device 140. At block 470, the POS device sends the EMV payload and the transaction data to the server 120 to request authorization to pay for the transaction using the contactless card 101. The transaction data may include the transaction amount, a merchant identifier, and / or location data of the POS device 140. In some embodiments, the account application 113 may also send data (e.g., requested amount, location information, time information) to the server 120 for authorization. At block 480, the authorization application 123 of the server 120 approves payment for the transaction using the contactless card 101 based at least in part on the indication of pre-authorization in the EMV payload. For example, the authorization application 123 may determine that the location data in the pre-approval indication stored in the account data 124 is within a threshold distance of the location of the POS device 140. Additionally and / or alternatively, the authorization application 123 may determine that attributes of the transaction do not violate rule 107-2 for using the contactless card 101. In block 490, the authorization application 123 sends an indication of approval of the transaction to the POS device 140, which may output the indication of approval and proceed further with the transaction.

[0045] 5 illustrates one embodiment of a logic flow 500. The logic flow 500 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 500 may include some or all of the operations performed by the authorization application 123 to pre-approve a transaction. The embodiments are not limited in this context.

[0046] As shown, logic flow 500 begins at block 510, where authorization application 123 determines whether location data received from mobile device 110 is within one or more locations specified in rule 107-2 as being permitted for use of contactless card 101. In some embodiments, authorization application 123 determines whether the location data is within a threshold distance of one or more locations specified in rule 107-2. At block 520, authorization application 123 attempts to decrypt encrypted data 108 generated by contactless card 101, for example, using a copy of a private key associated with contactless card 101. At block 530, authorization application 123 determines whether multi-factor authentication has been completed for the account. For example, authorization application 123 may decide to pre-authorize a transaction based at least in part on whether multi-factor authentication was used to authenticate a user in the account in account application 113.

[0047] At block 540, the authorization application 123 may select one or more pre-authorization levels for the transaction based at least in part on the results of the attempt to decrypt the encrypted data 108 and / or whether the location data received from the mobile device 110 is within one or more locations specified in Rule 107-2. Additionally and / or alternatively, the authorization application 123 may select the pre-authorization level based on whether multi-factor authentication is completed and / or whether Rule 107-2 is violated by the requested pre-authorization. At block 550, the authorization application 123 may store an indication of the selected pre-authorization level. In some embodiments, the pre-authorization level is a binary pre-authorization (e.g., pre-authorized and / or not pre-authorized). In one embodiment, the pre-authorization indication includes a unique identifier for the pre-authorization. The pre-authorization indication may further include the location data received from the mobile device, the requested pre-authorization amount, and / or a timestamp.

[0048] At block 560, the authorization application 123 may send an indication of pre-approval to the mobile device 110. The sent indication may be the same as or different from the indication stored in the account data 124. For example, the authorization application 123 may send a unique identifier of the pre-approval. At block 570, the account application 113 sends the indication of pre-approval received from the authorization application 123 to the contactless card 101. The contactless card 101 may then store the received indication of pre-approval for inclusion in an EMV payload generated by the contactless card 101 to pay for the transaction via the POS device 140. In doing so, the authorization application 123 may identify the indication of pre-approval in the EMV payload and compare the received indication (or attributes thereof) with the indication of pre-approval (or attributes thereof) stored in the account data 124 (or attributes thereof).

[0049] 6 illustrates one embodiment of a logic flow 600. The logic flow 600 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations performed by the authorization application 123 to restrict contactless card transaction capabilities. The embodiments are not limited in this context. For example, the authorization applet 104 may perform some or all of the operations of the logic flow 600 when determining whether to generate encrypted data 108 and / or whether to approve a request from the payment applet 106 to pay for a transaction using a contactless card.

[0050] As shown, logic flow 600 begins at block 610, where the authorization application 123 may determine whether location data received from the mobile device 110 is within (and / or within a threshold distance of) one or more permitted locations for using the contactless card 101. As previously described, the permitted locations for using the contactless card 101 may be stored in rule 107-2. At block 620, the authorization application 123 may determine whether location data provided by the POS device 140 is within one or more permitted locations for using the contactless card 101. Additionally and / or alternatively, the authorization application 123 may determine whether the location data provided by the POS device 140 is within a predetermined distance of the location data received from the mobile device 110 as part of the pre-authentication request.

[0051] In block 630, the authorization application 123 may determine whether the requested transaction amount is below the maximum amount specified in rules 107-1 and / or 107-2 for using a contactless card. In block 640, the authorization application 123 may determine whether the time of the transaction is within one or more time periods during which the contactless card 101 is authorized for use (e.g., based on rules 107-1 and / or 107-2). In block 650, the authorization application 123 may determine whether the merchant associated with the transaction is an authorized use of the contactless card 101. As previously mentioned, rule 107-2 may specify authorized merchant identifiers and / or merchant categories. If the merchant identifier associated with the transaction is not an authorized merchant identifier and / or is not within an authorized merchant category, the server 120 and / or the contactless card 101 may restrict the use of the contactless card 101. In block 660, the authorization application 123 may determine whether a pre-approval indication is stored in the EMV payload received from the POS device 140. In some embodiments, the authorization application 123 may compare the pre-approval indication (or attributes thereof) to one or more stored pre-approval indications for the account in the account data. Additionally, the authorization application 123 may determine whether any rules associated with the pre-approval indication have been violated. For example, the pre-approval may be limited in time, distance (e.g., relative to location data received from the mobile device 110 when the pre-approval was processed), etc.

[0052] At block 670, the authorization application 123 may approve the transaction based at least in part on determining that all rules 107-2 are satisfied and / or identifying an indication of pre-approval in the EMV payload. At block 680, the authorization application 123 may deny the transaction based at least in part on determining that at least one rule 107-2 is not satisfied and / or failing to identify an indication of pre-approval in the EMV payload. Similarly, the authorization application 123 may deny the transaction if the location data associated with the indication of pre-approval is not within a threshold distance of the POS device 140 providing the EMV payload.

[0053] 7 illustrates one embodiment of a logic flow 700. The logic flow 700 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 700 may include some or all of the operations for limiting contactless card transaction capabilities. The embodiments are not limited in this context.

[0054] As shown, logic flow 700 begins at block 705, where the location module 114 of the unlocked mobile device 110 provides location data to the account application 113. The account application 113 may then transmit the location data to the contactless card 101. At block 710, the payment applet of the contactless card 101 may receive transaction data (e.g., transaction amount, merchant ID, location data, etc.) from the POS device 140. At block 720, the payment applet 106 requests approval of the transaction from the authorization applet 104. At block 730, the authorization applet 104 determines that rule 107-1 is satisfied by the transaction data, including the transaction amount, the location of the POS device 140, and / or the merchant ID. At block 740, the authorization applet 104 determines that a valid indication of pre-authorization is stored in memory 102. For example, authorization applet 104 may determine that the time associated with the pre-approval is within the time threshold specified in rule 107-1. As another example, authorization applet 104 may determine that the location data associated with the pre-approval indication is within a threshold distance of the location data of POS device 140.

[0055] At block 750, the authorization applet 104 provides authorization to the payment applet 106 based at least in part on the decisions made in blocks 730 and 740. At block 760, the payment applet 106 generates an EMV payload including the account number, expiration date, CVV, and a pre-authorization indication. The payment applet 106 may then send the EMV payload to the POS device 140. At block 770, the POS device 140 sends the EMV payload, the transaction data, and the location data of the POS device 140 to the authorization application 123 of the server 120.

[0056] At block 780, the authorization application 123 approves the transaction based at least in part on detecting the pre-approval indication in the EMV payload and / or the location data received from the POS device 140. For example, the authorization application 123 may determine whether the location data provided by the POS device 140 is within one or more permitted locations for using the contactless card 101. Additionally and / or alternatively, the authorization application 123 may determine whether the location data provided by the POS device 140 is within a predetermined distance of the location data of the pre-approval indication stored in the account data 124. The authorization application 123 may then send an indication of approval. At block 790, the POS device 140 may process the transaction in response to receiving the indication of approval from the authorization application 123.

[0057] 8 illustrates one embodiment of a logic flow 800. The logic flow 800 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 800 may include some or all of the operations performed to determine that multi-factor authentication has been performed for an account. The embodiments are not limited in this context.

[0058] As shown, the logic flow 800 begins at block 810, where the account application 113 optionally receives valid login credentials for the account (e.g., username and password). At block 820, the account application 113 optionally receives biometric credentials for the account (e.g., iris scan, fingerprint, Face ID, etc.). At block 830, the account application 113 optionally receives a one-time passcode sent by the server 120 via text message to the phone number of the mobile device 110. At block 840, the account application 113 optionally receives encrypted data 108 generated by the contactless card 101 and sends the encrypted data 108 to the server 120. The server 120 may decrypt the encrypted data 108 to authenticate the encrypted data 108 and send an indication of the authentication to the account application 113. At block 850, the account application 113 optionally receives a passcode generated by another application and provided by the user as input to the account application 113. At block 860, the account application 113 may determine that multi-factor authentication has occurred for the account based on at least two of the authentication factors at blocks 810-850. For example, if login credentials are received at block 810 and biometric credentials are received at block 820, the account application 113 may determine that multi-factor authentication of the account is complete. The account application 113 may send an indication of multi-factor authentication of the account to the server 120.

[0059] FIG. 9 illustrates one embodiment of an exemplary computing architecture 900, including a computing system 902, that may be suitable for implementing various embodiments as described above. In various embodiments, the computing architecture 900 may include or be implemented as part of an electronic device. In some embodiments, the computing architecture 900 may represent, for example, a system that implements one or more components of the system 100. In some embodiments, the computing system 902 may represent, for example, the contactless card 101, the mobile device 110, the server 120, and / or the POS device 140 of the system 100. The embodiments are not limited in this context. More generally, the computing architecture 900 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-8.

[0060] As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, either hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 900. For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may be located within a process and / or thread of execution, and components may be localized on one computer or distributed across two or more computers. Furthermore, components may be communicatively coupled to each other by various types of communication media to operate in cooperation. Cooperation may include one-way or two-way information exchange. For example, components may convey information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines, and in such assignments, each message is a signal. However, further embodiments may use data messages instead. Such data messages may be transmitted over a variety of connections, example connections including parallel interfaces, serial interfaces, and bus interfaces.

[0061] The computing system 902 may include various typical computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by the computing system 902.

[0062] As shown in Figure 9, computing system 902 includes a processor 904, a system memory 906, and a system bus 908. Processor 904 can be any of a variety of commercially available computer processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors, and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures can also be used as processor 904.

[0063] The system bus 908 provides an interface to the processor 904 for system components, including but not limited to the system memory 906. The system bus 908 may be any of several types of bus structures, interconnectable to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may connect to the system bus 908 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0064] The system memory 906 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-silicon-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and other types of storage media suitable for storing information. In the embodiment shown in FIG. 9, the system memory 906 may include non-volatile memory 910 and / or volatile memory 912. The basic input / output system (BIOS) can be stored in non-volatile memory 910 .

[0065] Computing system 902 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 914, a magnetic floppy disk drive (FDD) 916 for reading from or writing to a removable magnetic disk 918, and an optical disk drive 920 for reading from or writing to a removable optical disk 922 (e.g., a CD-ROM or DVD). HDD 914, FDD 916, and optical disk drive 920 can be connected to system bus 908 by an HDD interface 924, an FDD interface 926, and an optical drive interface 928, respectively. HDD interface 924 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Computing system 902 is generally configured to implement all of the logic, systems, methods, devices, and functions described herein with reference to FIGS. 1-8.

[0066] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. A number of program modules can be stored on the drives and memory units 910, 912, including, for example, an operating system 930, one or more application programs 932, other program modules 934, and program data 936. In one embodiment, the one or more application programs 932, other program modules 934, and program data 936 can include, for example, various applications and / or components of system 100, such as card data 103, authorization applet 104, payment applet 106, rules 107, encryption data 108, account application 113, authorization application 123, account data 124, and / or transaction logic 144.

[0067] A user can enter commands and information into the computing system 902 through one or more wired and / or wireless input devices, such as a keyboard 938 and a pointing device such as a mouse 940. Other input devices include a microphone, infrared (IR) remote, radio frequency (RF) remote, game pad, stylus pen, card reader, dongle, fingerprint reader, gloves, graphics tablet, joystick, keyboard, retina reader, touch screen (capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 904 through an input device interface 942 coupled to the system bus 908, but may also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0068] A monitor 944 or other type of display device is also connected to the system bus 908 via an interface, such as a video adapter 946. The monitor 944 may be internal or external to the computing system 902. In addition to the monitor 944, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0069] Computing system 902 may operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as remote computer 948. The remote computer 948 may be a personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node and typically includes many or all of the elements described relative to computing system 902, although for simplicity, only memory / storage device 950 is shown. The logical connections shown include wired / wireless connections to larger networks, such as a local area network (LAN) 952 and / or a wide area network (WAN) 954. Such LAN and WAN networking environments are commonplace in offices and enterprises, facilitating enterprise-wide computer networking, such as an intranet. All of these may connect to a global communications network, such as the Internet. In an embodiment, network 130 of FIG. 1 is one or more of LAN 952 and WAN 954.

[0070] When used in a LAN networking environment, the computing system 902 is connected to the LAN 952 via a wired and / or wireless communication network interface or adapter 956. The adapter 956 can facilitate wired and / or wireless communication to the LAN 952 and may also include a wireless access point disposed on the adapter 956 to communicate with the wireless capabilities of the adapter 956. The network interface 112 of the mobile device 110 is an example of an adapter 956.

[0071] When used in a WAN networking environment, the computing system 902 may include a modem 958 or may be connected to a communication server on the WAN 954, or may have other means for establishing communications over the WAN 954, such as via the Internet. The modem 958, which may be an internal or external wired and / or wireless device, connects to the system bus 908 via the input device interface 942. In a networked environment, program modules described relative to the computing system 902, or portions thereof, may be stored in the remote memory / storage device 950. The network connections shown are exemplary and it is understood that other means of establishing a communications link between the computers may be used.

[0072] The computing system 902 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.16 wireless modulation techniques). This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth wireless technologies. Thus, communication can be structured like a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies referred to as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3-related media and functions).

[0073] FIG. 10A illustrates a contactless card 101, which may include a payment card such as a credit card, debit card, and / or gift card. As illustrated, the contactless card 101 may be issued by a service provider 1002, which may display the card's name on the front or back of the card 101. In some examples, the contactless card 101 may be unrelated to a payment card and may include, but is not limited to, an ID card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 101 may include a substrate 1010, which may include a single layer or one or more laminates composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, contactless card 101 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard, or the contactless card may conform to the ISO / IEC 14443 standard. However, it will be understood that contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented in a payment card.

[0074] The contactless card 101 may include identification information 1015 displayed on the front and / or back of the card and a contact pad 1020. The contact pad 1020 may be configured to establish contact with another communication device, such as the mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may include processing circuitry, an antenna, and other components not shown in FIG. 10A . These components may be located behind the contact pad 1020 or elsewhere on the substrate 1010. The contactless card 101 may include a magnetic strip or tape (not shown in FIG. 10A ) that may be located on the back of the card.

[0075] 10B, the contact pad 1020 of the contactless card 101 may include processing circuitry 1025 for storing and processing information, including a microprocessor 1030 and memory 102. It will be understood that the processing circuitry 1025 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as needed to perform the functions described herein.

[0076] The memory 102 may be read-only memory, write-once / read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be programmable as read-only at the factory or may be programmable only once. If programmable only once, it can be written once and then read many times. Write-once / read-multiple memory is programmable at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but can be read many times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. Read / write memory can also be read many times after leaving the factory.

[0077] The memory 102 may be configured to store card data 103, one or more applets (including an authorization applet 104, a payment applet 106, and other applets), a private key 1008, encrypted data 108, rules 107-1, and one or more customer (or user) identifiers (IDs) 1007. The one or more applets 103 may include one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 103 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device with limited memory. The customer ID 1007 may include a unique alphanumeric identifier assigned to a user of the contactless card 101, which may distinguish the user of the contactless card from other users of contactless cards. In some examples, customer ID 1007 may identify both the customer and the account assigned to that customer, and may further identify the contactless card associated with the customer's account. In some embodiments, authorization applet 104 (or another applet) may use customer ID 1007 as input to a cryptographic algorithm using private key 1008 to generate encrypted data 108.

[0078] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto, and it will be understood that these elements may be implemented outside of the pads 1020, completely separate from the pads 1020, or as additional elements in addition to the processor 1030 and memory 102 elements disposed within the contact pads 1020.

[0079] In some examples, the contactless card 101 may include one or more antennas 1055. The one or more antennas 1055 may be disposed within the contactless card 101 and around the processing circuit 1025 of the contact pads 1020. For example, the one or more antennas 1055 may be integral with the processing circuit 1025, or the one or more antennas 1055 may be used with an external booster coil. As another example, the one or more antennas 1055 may be external to the contact pads 1020 and the processing circuit 1025.

[0080] In one embodiment, the coil of the contactless card 101 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 101 by cutting power or amplitude modulation. The contactless card 101 may infer data transmitted from the terminal using gaps in the contactless card's power connection, which are maintained functionally through one or more capacitors. The contactless card 101 may communicate back by switching or load modulating the load on the contactless card's coil. The load modulation may be detected by interference on the terminal's coil. More generally, using the antenna 1055, processing circuitry 1025, and / or memory 102, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0081] As described above, contactless card 101 is built on a software platform capable of running on a smart card or other device with limited memory, such as a JavaCard, on which one or more applications or applets can be securely executed. An applet can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet can be configured to respond to one or more requests, such as a near-field data exchange request, from a reader, such as a mobile NFC reader (e.g., communication interface 105-1 of device 110), and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag.

[0082] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include a processor, a microprocessor, a circuit, a circuit element (such as a transistor, resistor, capacitor, inductor, etc.), an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a logic gate, a register, a semiconductor device, a chip, a microchip, a chipset, etc. Examples of software may include a software component, a program, an application, a computer program, an application program, a system program, a machine program, an operating system software, a middleware, a firmware, a software module, a routine, a subroutine, a function, a method, a procedure, a software interface, an application program interface (API), an instruction set, a computing code, a computer code, a code segment, a computer code segment, a word, a value, a symbol, or a combination thereof. The decision to implement an embodiment using hardware and / or software elements depends on various factors, such as desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0083] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor. The representative instructions, when read by a machine, cause the machine to assemble logic that performs the techniques described herein. Such expressions, known as "IP cores," may be stored on tangible machine-readable media and provided to various customers or manufacturing facilities for inclusion in manufacturing machines that create logic or processors. Some embodiments may be implemented using, for example, a machine-readable medium or article that stores instructions or sets of instructions that, when executed by the machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such machines may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, including, for example, memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, hard disk, floppy disk, compact disk read-only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tape, cassette, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0084] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but by the claims appended hereto. Future applications claiming priority to this application may claim the disclosed subject matter differently and generally can include any set of one or more limitations as variously disclosed or otherwise set forth herein.

Claims

1. A contactless card, a processor circuit; a communication interface; a memory storing instructions that, when executed by the processor circuit, cause the processor circuit to: receive, via the communications interface, from a mobile device running an account application, an indication that a server has pre-approved the transaction based on location data indicating the location of the mobile device and authentication of encrypted data, where the encrypted data was generated by the contactless card using a cryptographic algorithm and a private key stored in a memory of the contactless card, and the indication further identifies that one or more credentials for an account associated with the contactless card have been received by the account application; receiving an indication from a point of sale (POS) device via the communications interface to pay for a transaction using the contactless card; determining, based on one or more rules stored in the memory, that the location of the mobile device is within a threshold distance of one or more locations where use of the contactless card is permitted; generating transaction data including (i) an indication of the contactless card's account number and expiration date, and (ii) an indication of pre-approval of the transaction by the server; transmitting the transaction data to the POS device as payment for the transaction; receiving from the POS device an indication that the server approves payment of the transaction using at least a portion of the transaction data and based at least in part on identifying in the transaction data an indication of pre-approval of the transaction by the server; Contactless card.

2. The memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: writing an indication of pre-approval of the transaction by the server into a first field of an EMV payload; writing the indication of location data, the indication of account number, the indication of expiration date, and an indication of card verification value (CVV) into one or more other fields of the EMV payload; 2. The contactless card of claim 1.

3. the memory stores an authorization applet and a settlement applet; the authorization applet determines that the location of the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized; the authorization applet receives from the mobile device an indication of pre-approval of the transaction by the server; the authorization applet generates the encrypted data based on a customer ID associated with the contactless card; the payment applet generates the EMV payload and, in response to receiving approval from the authorization applet, transmits the EMV payload to the POS device; The authorization applet provides approval to the payment applet based on an indication of pre-approval of the transaction by the server received from the mobile device and a determination that the location of the mobile device is within a threshold distance of one or more locations where use of the contactless card is permitted.

3. The contactless card according to claim 2.

4. The memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: and receiving, via the communication interface, an indication from an account application executing on the mobile device that multi-factor authentication of an account has been completed using the mobile device, wherein the multi-factor authentication is based on at least two of: (i) a login and password for the account; (ii) a one-time password sent to a phone number associated with the account; (iii) biometric information associated with the account; (iv) a temporary code generated by an authentication application; and (v) data generated by a contactless card.

4. The contactless card according to claim 3.

5. The POS device transmits the EMV payload and location data indicating a location of the POS device to the server, and the memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: before transmitting an indication of approval for the transaction to the POS device; receiving an indication identifying that the server has determined that the location of the mobile device is within a threshold distance of location data indicating the location of the POS device; receiving an indication that the server authenticated the transaction as pre-approved based on an indication of pre-approval of the transaction by the server in a first field of the EMV payload; 4. The contactless card according to claim 3.

6. The memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: receiving, by the authorization applet, updated location data from the mobile device via the communications interface, indicating an updated location of the mobile device, where the updated location is different from the location; determining, by the authorization applet, based on one or more rules stored in the memory, that the location of the mobile device is not within a threshold distance of one or more locations where use of the contactless card is permitted; receiving, by the payment applet, from a second POS device, an indication to pay for a second transaction using the contactless card; the payment applet requests approval of payment of the second transaction from the authorization applet; denying payment authorization for the second transaction based on a determination by the authorization applet that the location of the mobile device is not within a threshold distance of one or more locations where use of the contactless card is authorized; and transmitting, by the payment applet, an indication to the second POS device denying payment of the second transaction using the contactless card based on the denial by the authorization applet.

4. The contactless card according to claim 3.

7. the indications of pre-approval of the transaction by the server in the transaction data include different indications of pre-approval of the transaction by the server; the communication interface of the contactless card is configured to support at least one of near field communication (NFC), Bluetooth, and Wi-Fi; and the memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: receiving a current time associated with the transaction; determining, based on one or more rules stored in the memory, that the current time is within a time period during which use of the contactless card is permitted; receiving an indication of the amount of the transaction from the POS device; determining, based on one or more rules stored in the memory, that the transaction amount is less than a maximum spend amount associated with the contactless card; 2. The contactless card of claim 1.

8. 1. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to: a server authenticating encrypted data generated by the contactless card using a cryptographic algorithm and a private key, wherein the encrypted data is received by the server from a mobile device running an account application, and one or more credentials related to an account associated with the contactless card are received by the account application; the server determines, based on one or more rules associated with the account, that the location data received from the mobile device is within a threshold distance of one or more locations where use of the contactless card is permitted; the server pre-authorizing the transaction using the contactless card based on authentication of the encrypted data and a determination that the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized; the server sending an indication of pre-approval for the transaction to an account application running on the mobile device; the server receives transaction data from a point of sale (POS) device, the transaction data including (i) an indication of the contactless card's account number and expiration date, and (ii) an indication of pre-approval of the transaction by the server; The server approves the transaction based at least in part on identifying in the transaction data an indication of pre-approval of the transaction by the server. A non-transitory computer-readable storage medium.

9. The transaction data includes an EMV payload, and the non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to: the server identifying an indication of pre-approval of the transaction by the server in a first field of the EMV payload; Identifying an indication of the account number, an indication of the expiration date, and an indication of a card verification value (CVV) in one or more other fields of the EMV payload. The non-transitory computer-readable storage medium of claim 8.

10. and storing instructions that, when executed by the processor, cause the processor to: the server stores an indication of the pre-approval; The server compares the stored indication of pre-approval of the transaction by the server with the indication of pre-approval of the transaction by the server in a first field of the EMV payload.

10. The non-transitory computer-readable storage medium of claim 9.

11. The pre-approval includes one or more levels of pre-approval, the levels of pre-approval being based on (i) the server using a copy of the private key and the cryptographic algorithm to decrypt the encrypted data, and (ii) determining that location data received from the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized. The non-transitory computer-readable storage medium of claim 10.

12. the POS device transmits the EMV payload and location data indicating the location of the POS device to the server; The non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to do the following before sending an indication of approval for the transaction to the POS device: The server determines that the location of the mobile device is within the threshold distance from the location of the POS device. The non-transitory computer-readable storage medium of claim 11.

13. and storing instructions that, when executed by the processor, cause the processor to: The server receives a current time associated with the transaction; The server determines, based on one or more rules associated with the account, that the current time is within an authorized time for use of the contactless card. The non-transitory computer-readable storage medium of claim 11.

14. the communication interface of the contactless card is configured to support at least one of Near Field Communication (NFC), Bluetooth, and Wi-Fi; The non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to: the server receiving an indication of the transaction amount from the POS device; The server determines, based on one or more rules associated with the account, that the transaction amount is less than a maximum spend amount associated with the contactless card. The non-transitory computer-readable storage medium of claim 8.

15. 1. A method comprising: a server authenticating encrypted data generated by the contactless card using a cryptographic algorithm and a private key, wherein the encrypted data is received by the server from a mobile device running an account application, and one or more credentials associated with an account associated with the contactless card are received by the account application; the server determining, based on one or more rules associated with the account, that the location data received from the mobile device is within a threshold distance of one or more locations where use of the contactless card is permitted; pre-authorizing, by the server, a transaction using the contactless card based on authenticating the encrypted data and determining that the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized; the server sending an indication of pre-approval for the transaction to an account application executing on the mobile device; receiving, by the server, transaction data from a point of sale (POS) device, the transaction data including (i) an indication of the contactless card's account number and expiration date, and (ii) an indication of pre-approval of the transaction by the server; and approving the transaction by the server based at least in part on identifying in the transaction data an indication of pre-approval of the transaction by the server. A method comprising:

16. The transaction data includes an EMV payload, and further the server identifying an indication of pre-approval of the transaction by the server in a first field of the EMV payload; Identifying an indication of the account number, an indication of the expiration date, and an indication of a card verification value (CVV) in one or more other fields of the EMV payload.

16. The method of claim 15, comprising:

17. moreover, the server storing an indication of the pre-approval; the server comparing the stored indication of pre-approval of the transaction by the server with the indication of pre-approval of the transaction by the server in the first field of the EMV payload.

17. The method of claim 16, comprising:

18. The pre-approval includes one or more levels of pre-approval, the levels of pre-approval being based on (i) the server using a copy of the private key and the cryptographic algorithm to decrypt the encrypted data, and (ii) determining that location data received from the mobile device is within a threshold distance of one or more locations where use of the contactless card is authorized.

18. The method of claim 17.

19. the POS device transmits the EMV payload and location data indicating the location of the POS device to the server; and, prior to transmitting an indication of approval of the transaction to the POS device, the server determining that the location of the mobile device is within the threshold distance from the location of the POS device; 18. The method of claim 17, comprising:

20. the communication interface of the contactless card is configured to support at least one of Near Field Communication (NFC), Bluetooth, and Wi-Fi; Furthermore, before approving said transaction: the server receiving a current time associated with the transaction; the server determining, based on one or more rules associated with the account, that the current time is within an authorized time for use of the contactless card; the server receiving an indication of the transaction amount from the POS device; the server determining, based on one or more rules associated with the account, that the transaction amount is less than a maximum spend amount associated with the contactless card.

16. The method of claim 15, comprising:

Images