US20230267449A1 - Systems and methods for contactless card activation - Google Patents

Abstract

A mobile device includes a wireless chip, a display, a processor, and a memory storing instructions that, when executed by the processor, cause the processor to perform operations. The operations include: based on a first short-range wireless communication, receiving a customer-specific uniform resource locator (URL) from the contactless card via a wireless chip; automatically navigating to a website associated with the customer-specific URL; receiving authentication information and automatically populating one or more fields on a graphical user interface (GUI); displaying, by the display, an indication of activation of the contactless card; receiving and accepting a prompt to register the mobile device with the activated contactless card; and based on at least a second short range wireless communication between the registered mobile device and the contactless card, providing a second GUI including an online login portal for accessing an account that is associated with the contactless card.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 16/986,111, entitled “Systems and Methods for Contactless Card Activation,” filed Aug. 5, 2020, which claims the benefit of and priority to U.S. Provisional Patent Application No. 62/902,247, entitled “Systems and Methods for Contactless Card Activation, Usage, and Account Access,” filed Sep. 18, 2019, both of which are incorporated herein by reference in their entireties. This application is also a continuation of U.S. patent application Ser. No. 16/986,111, entitled “Systems and Methods for Contactless Card Activation,” filed Aug. 5, 2020, which is a continuation of U.S. patent application Ser. No. 16/703,539, entitled “Systems and Methods for Activating a Transaction Card,” filed Dec. 4, 2019, which claims the benefit of and priority to U.S. Provisional Patent Application No. 62/902,247, entitled “Systems and Methods for Contactless Card Activation, Usage, and Account Access,” filed Sep. 18, 2019, all of which are incorporated herein by reference in their entireties.
TECHNICAL FIELD
• Embodiments of the present disclosure relate to systems and methods for providing and using a contactless transaction card.
BACKGROUND
• Financial institutions such as banks and other card issuers typically offer customers a variety of transaction cards (e.g., credit card, debit card, rewards card, etc.). A corresponding account for the transaction card is also created and provided by the institution. As a security measure, new transaction cards are typically issued to customers in an inactive state (i.e., unable to perform transactions). In operation, the transaction card may be provided to the customer and the customer is then expected to activate the card via, for example, calling an activation telephone line. Once activated, the transaction card may be used in a variety of transactions (e.g., to pay for goods or services). But, accessing the corresponding account of the transaction card may be difficult. In this regard, setting up and accessing online accounts associated with the card is usually a long and cumbersome process. Further, even activating the card may be cumbersome due to users' unwillingness to make the telephone call. Improvements are desired.
SUMMARY
• One embodiment relates to a mobile device. The mobile device includes a network interface configured to allow the mobile device to communicate over a network, a wireless chip structured to allow short-range wireless communications (e.g., a near-field communication), a display, a processor in communication with the network interface, the wireless chip, and the display, and a memory storing instructions. The instructions, when executed by the processor, are configured to cause the processor to perform operations including, based on a short-range wireless communication between the mobile device and a contactless card, receive a customer-specific uniform resource locator (URL) from the contactless card via the wireless chip, the customer-specific URL identifying a client associated with the contactless card, in response to receiving the customer-specific URL, automatically open a web browser and navigate to a website associated with the customer-specific URL, prompt, via a GUI on the display, a user for authentication information to verify that the user is the client associated with the contactless card, receive the authentication information and automatically populate one or more fields on the GUI of the display with the received authentication information, transmit the received authentication information to a separate computing system, and based on a verification of the authentication information, display, by the display, a confirmation page indicating activation of the contactless card.
• Another embodiments relates to a system comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising generate a customer-specific uniform resource locator (URL) for a contactless card for an customer, the customer-specific URL including a publicly accessible URL with an appended data field specific to the customer, issue the contactless card with the customer-specific URL embedded thereon to the customer, store, in a database, information regarding the customer and information regarding the contactless card, the information regarding the contactless card comprising the appended data field specific to the customer, based on a short range contactless communication between a mobile device of the customer and the contactless card, receive the appended data field specific to the customer, in response to receiving the appended data field specific to the customer, access, from the database, the information regarding the customer based on cross-referencing the appended data field specific to the customer to information stored in the database, based on matching the appended data field with information stored in the database, provide a graphical user interface (GUI) to the mobile device, the GUI including a prompt for authentication information, receive authentication information from the mobile device, verify the authentication information based on cross-referencing the received authentication information with the information regarding the customer retrieved from the database using the appended data field specific to the customer, and in response to verifying the authentication information from the customer device, activate the contactless card for a subsequent use.
• Another embodiments relates to a non-transitory computer-readable medium storing instructions that, when executed by one or more processors cause operations including generate a customer-specific uniform resource locator (URL) for a contactless card for an customer, the customer-specific URL including a publicly accessible URL with an appended data field specific to the customer, issue the contactless card with the customer-specific URL embedded thereon to the customer, store, in a database, information regarding the customer and information regarding the contactless card, the information regarding the contactless card comprising the appended data field specific to the customer, based on a short range contactless communication between a mobile device of the customer and the contactless card, receive the appended data field specific to the customer, in response to receiving the appended data field specific to the customer, access, from the database, the information regarding the customer based on cross-referencing the appended data field specific to the customer to information stored in the database, based on matching the appended data field with information stored in the database, provide a graphical user interface (GUI) to the mobile device, the GUI including a prompt for authentication information, receive authentication information from the mobile device, verify the authentication information based on cross-referencing the received authentication information with the information regarding the customer retrieved from the database using the appended data field specific to the customer, and in response to verifying the authentication information from the customer device, activate the contactless card for a subsequent use.
• This summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices or processes described herein will become apparent in the detailed description set forth herein, taken in conjunction with the accompanying figures, wherein like reference numerals refer to like elements.
BRIEF DESCRIPTION OF THE FIGURES
• FIG.1 is a block diagram of a contactless card system, according to an example embodiment.
• FIG.2 is a flow diagram of a method of issuing and activating a new contactless card, according to an example embodiment.
• FIG.3 illustrates a “tap” between a contactless card and a customer device, according to an example embodiment.
• FIG.4 illustrates a method of a contactless communication between a customer device and a contactless card for at least one of activating the contactless card, enabling a password-less login into an account associated with the contactless card, or directing a customer to specific URL, according to example embodiments.
• FIG.5 depicts a contactless card and a customer device being tapped together for a password-less account login, according to an example embodiment.
• FIG.6 depicts a customer device having a graphical user interface displaying an authentication page, according to an example embodiment.
• FIG.7A depicts a customer device displaying an online account dashboard, according to an example embodiment.
• FIG.7B depicts a customer device displaying a confirmation page on a graphical user interface, according to an example embodiment.
• FIG.8 depicts a flow diagram of a method of a password-less login to an account, according to an example embodiment.
• FIG.9 depicts a flow diagram of a method of communicating with a transaction card in order to identify a customer, according to an example embodiment.
• FIG.10 depicts a flow diagram of a method of communication between a customer device and a transaction card, according to an example embodiment.
• FIG.11 depicts a customer device displaying a prompt for additional authentication information on a graphical user interface, according to an example embodiment.
• FIG.12 depicts a customer device displaying a prompt for additional authentication information on a graphical user interface, according to an example embodiment.
DETAILED DESCRIPTION
• Systems, apparatuses, and methods for providing and operating a contactless card system are disclosed according to various embodiments herein. A “contactless card” (also referred to as a “smart card”) is a physical transaction card (e.g., formed of plastic, metal, a combination thereof, etc.) comprising an integrated circuit with a wireless transmission antenna that allows the card to wirelessly transmit information to a contactless receiver, such as certain point of sale (POS) terminals. The contactless card may be a credit card, a debit card, or the like. The wireless transmission may be a radio field transmission and, particularly, is a near-field communication (NFC). When used in a payment transaction, the information transmitted may relate to an account associated with the contactless card (e.g., a payment account number such as a credit card account number). The circuit may store and process information relating to the transaction. In operation, the contactless card may be “tapped” (i.e., brought into a contact or near contact situation) with the contactless reader (e.g., the POS) to enable the exchange of information from the card to the contactless reader. The contactless card may also include other features such as a magnetic stripe. Additionally, the chip of the contactless card may be structured to additionally enables the card to be dipped (i.e., inserted) into a reader.
• According to the present disclosure, the contactless card may have a website uniform resource locator (URL) embedded in a chip or circuit of the card. In particular, the website URL may be embedded in a record or tag on a contactless enabled chip of the card. The contactless chip is NFC enabled. When a user/customer taps the contactless card against a contactless reader (particularly, a wireless interface reader on a mobile device), the contactless circuit is activated by the mobile device to enable transmission of the tag via NFC to the mobile device where the tag/record is read. Reading of the tag causes a web browser application on the mobile device to activate and take the user to the particular website URL. At which point, the user may attempt to activate the card if the card is not yet activated. In one embodiment, the website URL is unique to the card and customer (i.e., a customer-specific URL). In this regard, each card will have a different URL that is specific to the customer. Such an arrangement will ensure that only the intended recipient of the card will be able to activate the card and/or access information regarding the account associated with the card. In other alternate embodiments, the website URL may be generic and not specific to the customer/user. In this situation, additional account information must be manually entered by the user before activation of the card or information regarding the account is provided. Beneficially, a card issuer computing system may manage transactions and activation of the contactless card with improved forms of verifying that the customer is indeed in possession of the contactless card. Thus, the systems and methods described herein provided a mitigation of potential fraud while also reducing the struggle or friction of a customer receiving and managing a contactless card (i.e., activating their card or accessing access information regarding the account associated with the card).
• As used herein, the term “tap” or “tapped” as used to describe the interaction between a contactless card and a contactless reader refers to the two devices coming into a contact or near contact situation with each other such that a wireless transmission of information is possible (e.g., from the card to the customer device). Based on the wireless transmission protocol used, the distance required for the wireless transmission may vary (e.g., Bluetooth versus NFC). For example and with reference to NFC, the devices are brought to a distance of approximately 10 cm or less of each other. However, a Bluetooth transmission protocol may allow a bigger distance between the devices. Accordingly, the “tap” as described herein means a NFC communication unless otherwise specified. As also used herein, the term “authentication” generally refers to the identification of a transaction by the contactless card based on identifying the user of the card to ensure that only allowed users of the card are permitted to use the card. “Authorization” refers to approving the transaction based on the authentication. As also used herein, the term “activation” as used in reference to a state of the contactless card refers to the state of the account associated with the contactless card. When deactivative or in an inactive state, the account associated with the card is not allowed to complete a transaction. When activated, the account associated with the card may be used in various transactions, such as a payment transaction. Thus, even when deactivated, transactions involving the contactless card may be attempted (e.g., a card swipe or dip). However, these transactions are denied because the account associated with the card is not activated.
• Referring now toFIG.1, acontactless card system100 is shown according to an example embodiment. Thesystem100 includes acustomer device102 associated with a customer/user, acontactless card104, anetwork106, and a providerinstitution computing system108. Thenetwork106 may be any type of type of network. For example, thenetwork106 may be a wireless network interface (e.g., Internet, WI-FI®, etc.), a wired network interface (e.g., Ethernet), or any combination thereof. While thenetwork106 generally refers to the definition provided above, in some embodiments, thenetwork106 also includes financial networks associated with various payment brands (e.g., card networks such as Visa®, American Express®, Discover®, MasterCard®, etc.). When thenetwork106 is used to refer to these types of networks, the term “card network” or “payment network” is used herein. Otherwise, the aforementioned definition for thenetwork106 is intended. Thenetwork106 is structured to permit the exchange of data, values, instructions, messages, and the like between and among various components ofFIG.1.
• Thecustomer device102 is owned by or otherwise associated with a customer/user. The user may be an individual, business representative, large and small business owner, and so on. The user or customer may be an existing or a new customer to the provider institution associated with the providerinstitution computing system108. Thecustomer device102 is structured to enable the user to access the network106 (e.g., to send and receive information/data over the network). Thecustomer device102 is also structured as a contactless reader structured to enable the reception of information wirelessly from thecontactless card104. Examples of thecustomer device102 include a mobile device, such as a mobile phone such as a smartphone, a tablet, a wearable computing device (e.g., eyewear), a laptop etc. In the example shown, thecustomer device102 is structured as a mobile device. In other embodiments, thecustomer device102 may be a different computing device, such as a desktop computer or an ATM. In the example shown, thecustomer device102 includes aprocessor110,memory128, a wireless chip orinterface112, and anetwork interface126. Thus, thecustomer device102 includes two interfaces:interface112 that is structured to enable communications with thecontactless card104, andnetwork interface126 that enables communications over thenetwork106.
• Thecustomer device102 may include program logic (e.g., instructions) stored by thememory128 and executable by theprocessor110 to implement at least some of the functions described herein. Theprocessor110 may be implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. The one or more memory devices128 (e.g., RAM, NVRAM, ROM, Flash Memory, hard disk storage, etc.) may store data and/or computer code for facilitating the various processes described herein. Moreover, the one ormore memory devices128 may be or include tangible, non-transient volatile memory or non-volatile memory. Accordingly, the one ormore memory devices128 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein.
• In some embodiments, theprocessor110 may be configured to download and execute a software application of thecustomer device102. For example, a developer may make or create the software application to be downloaded (e.g., via the developer's website, via an app store, or in another manner). Responsive to a customer selection of an appropriate link, the software application can be transmitted to thecustomer device102 and cause itself to be installed on thecustomer device102. Installation of the software application creates a customer application that is executable by theprocessor110. Examples of downloadable applications include a mobile banking application, a mobile wallet application, and so on. Theprocessor110 is also structured to execute thick client applications as well (e.g., via a web browser). In either situation, the execution of the application (either thick, thin, or smart client application) may enable the user to access one or more accounts of the customer (e.g., provided and maintained by the card issuer). Or, more generally, execution of the application allows functions associated with that application. In operation, theprocessor110 is structured to automatically launch an application (e.g., a web browser) in response to receiving embedded data (e.g., a URL embedded in a record or tag accessible via the interface112) as a result of a contact or near-contact engagement with the contactless card104 (e.g., an NFC communication).
• Thenetwork interface126 may include one ormore antennas132 and associated communications hardware and logic. Thenetwork interface126 is structured to allow theprocessor110 to access and connect to thenetwork106 to, in turn, exchange information with for example the providerinstitution computing system108. That is, thenetwork interface126 is coupled to theprocessor110 andmemory128 and configured to enable a coupling to thenetwork106. Thenetwork interface126 allows for thecustomer device102 to transmit and receive internet data and telecommunication data. Accordingly, thenetwork interface126 includes any one or more of a cellular transceiver (e.g., CDMA, GSM™, LTE™, etc.), a wireless network transceiver (e.g., 802.11X, ZigBee™, WI-FI®, Internet, etc.), and a combination thereof (e.g., both a cellular transceiver).
• Thecustomer device102 further includeswireless chip112. Thewireless chip112 includes a radio frequency (RF)antenna130. The wireless chip112 (also referred to as a wireless interface112) is structured to enable other non-network communications. In particular, thewireless interface112 is structured to enable relatively short distance wireless communications with other devices. In the example shown, thewireless chip112 is a NFC interface (e.g., NFC transceiver) coupled to theprocessor110 and configured to transmit and receive data. Thewireless chip112 includes hardware and associated logic structured to enable thecustomer device102 to wirelessly and securely exchange data over short distances. In some arrangements, thewireless chip112 is configured to use radio frequency identification (RFID) to exchange digital information.
• In certain arrangements, thenetwork interface126 and/orwireless interface112 may include cryptography capabilities to establish a secure or relatively secure communication session with the at least the providerinstitution computing system108 or thecontactless card104. In this regard, data may be encrypted to prevent or substantially prevent the threat of hacking.
• It should be understood that thecustomer device102 may include other structures with associated functionality as well. For example, thecustomer device102 may include a global positioning system (GPS) structured to at least one of determine or receive data indicative of the location of thecustomer device102. This “location data” may provide an indication of a location of thecustomer device102. In certain embodiments, location data may be used as part of an authentication process for activation of the contactless card and/or password-less login.
• Still referring toFIG.1, the contactless card104 (or, smart card) is a transaction card associated with the user or customer. Thecontactless card104 is associated with an account of the user. In one embodiment, the transaction card is a payment card associated with a charge account (e.g., a line of credit, a checking account, a prepaid account, and the like). In another embodiment, thecontactless card104 is a non-payment card that is associated with an account of the user (e.g., a loyalty card). In the example shown, the contactless card is a credit card. But, as alluded to above, thecontactless card104 may be any type of transaction card such as a rewards card, a loyalty card, etc. such that the disclosure provided herein is also applicable with these card configurations.
• In the example shown, thecard104 includes amagnetic stripe136, and achip115. Because thechip115 is structured to allow contactless communications, the chip orinterface115 may also be referred to herein as a “contactless enabled chip.” In some embodiments, the contactless enabledchip115 may be a dual interface chip that has the same or similar structure as a dual interface EMV chip. The “dual interface” characteristic means that the contactless enabledchip115 is enabled to transmit information in a contactless manner and in a contact manner. For example, the chip may transmit information on the card (e.g., such as the record containing the URL) via near-field communication (NFC) (i.e., a contactless manner) and also have the physical contacts that allow for the card to be dipped into a reader (i.e., a contact manner). Thus, there is one chip—chip115—that is structured for contactless and contact transactions. As mentioned above, thechip115 may be an EMV chip. In other embodiments, thechip115 may only be capable of performing contact or contactless transactions. As described herein, thechip115 of thecontactless card104 is structured to enable contactless transactions. Themagnetic stripe136 is structured to transmit payment data when swiped through a magnetic stripe reader. In some embodiments, the magnetic stripe may be omitted from thecard104. Thecontactless card104 may also include visible information on the face and/or back of the card and digital information stored within the various structures of thecontactless card104. For example, thecontactless card104 can include a customer's name, a transaction card account number, an expiration date, and the like that is printed or embossed on the physical card. Thecontactless card104 may also include more detailed identifying customer information (e.g., a customer identification number from the issuer) and account information (e.g., account numbers, information regarding the card issuer, expiration date, and so on) in themagnetic stripe136, or an onboard the contactless enabledchip115.
• The contactless enabled chip115 (or, contactless interface or transceiver) is a defining feature of the “contactless” aspect of thecontactless card104. The contactless enabledchip115 is a small circuitry system configured to wirelessly exchange data with a contactless reader. For example, the contactless enabledchip115 can exchange data via RFID. In the example shown, the contactless enabledchip115 is structured to enable a NFC communication. Thus, in the example shown, the contactless enabledchip115 includes a NFC transceiver. In other alternate embodiments, the contactless enabledchip115 may enable a different short-distance communication form, such as a Bluetooth transmission. Accordingly, in these embodiments, the contactless enabledchip115 may include the relevant associated structures (e.g., a Bluetooth antenna).
• The contactless enabledchip115 is configured to selectively store and transmit various types ofinformation114. As shown, theinformation114 includes apayment application191 and arecord193. Thepayment application191 stores data and programs structured to enable a payment via thecard104. Examples ofsuch payment application191 data and programs may include, but are not limited to, terminal risk management data, card risk management data, issuer application data, secret data such as keys, or customer exclusive data.
• The record or tag193 (the terms “record” and “tag” are used interchangeably herein) is structured as a file that is stored in the contactless enabledchip115. In particular, the record ortag193 is structured as a text file that stores information that may include a general website URL, a customer specific website URL, a password, and/or instructions to perform an operation. As described herein, the record ortag193 is accessed via thecontactless interface112 on thecustomer device102. Therecord193 is separate from thepayment application191. In this regard, POS terminals are not configured to access/use therecord193. The contactless enabledchip115 may also have transaction card information embedded within thetag193, such as account numbers, proxy account numbers, payment tokens, issuing entities, expiration date, and so on.
• In this regard, the contactless enabledchip115 may have or store information that includes identifying customer information. In some arrangements, one or more pieces of information may be transmitted as a token, such as the information stored in therecord193. For example, the account number associated with the card may be tokenized to obscure the actual account number. The token, when received by the cardissuer computing system108 via a payment network, can be cross referenced against a token vault to identify the actual payment information (e.g., the actual account number associated with the customer). Other pieces of information may also be tokenized in order to obscure sensitive or relatively sensitive data.
• The contactless enabledchip115 may also be structured to store and transmit specific instructions. The specific instructions may be stored in therecord193. The specific instructions may direct a device (e.g., customer device102) to do or perform one or more functions. For example, the instructions may cause thedevice102 to access a web browser application and be directed to a particular website. In some embodiments, the specific instructions include an instruction to direct a device to a specific website associated with a URL embedded on or stored by the contactless enabledchip115. In some embodiments, the contactless enabledchip115 includes instructions to populate fields with specific information stored by thecontactless card104. According to the present disclosure, a passive NFC tag is stored by the contactless enabledchip115. The passive NFC tag refers to the information stored in therecord193 being communicated via NFC transmission. It is considered “passive” because a contactless reader is needed to power thechip115 to cause the wireless transmission of thetag193 to thecustomer device102. The passive NFC tag includes an instruction that is transmitted to the customer device in response to thewireless interface112 activating the contactless enabledchip115. The passive NFC tag may include information about a specific customer's online login information, instructions to pre-populate fields within a website with transaction card identification, etc. Thus, the contactless enabledchip115 using the passive NFC tag is structured to at least partly control certain functions of thecustomer device102.
• The contactless enabledchip115 may store information regarding a general website, a customer specific website (e.g., via an embedded URL), or online login information for the account associated with thecard104. Thechip115 is structured to transmit the information in response to a request or general communication with the contactlessenabled interface112 of thedevice102.
• Regarding the general website feature, for example, the contactless enabledchip115 may have a general website embedded thereon. This structure may be in the form of a link to a website that is publicly available and not specific to a person or group. The general website URL may be embedded in the tag193 (which is, particularly, a passive NFC tag) of the contactless enabledchip115 such that when thewireless interface112 interacts with the contactless enabledchip115, the general URL gets transmitted to thecustomer device102 for accessing. In addition to the general website URL, an instruction to activate a browser application of thecustomer device102 may also be included with thetag193. This instruction (e.g., an API, etc.) causes activation of a website browser. The precise website browser that is activated may be based on a default setting in thecustomer device102. In another embodiment, the instruction may be specific to particular website browsers (e.g., Google Chrome only). In any event, in addition to activating the web browser, the instruction directs the browser to go to the general website URL. The general website may be an online login portal where the user may be required to enter their credentials in order to access their online accounts or, specifically, the account associated with thecard104. When thecard104 is not yet active, the general website URL is a general activation page where the user may enter identifying and verification information in order to activate thecontactless card104 for use.
• In contrast to the general website example, the contactless enabledchip115 may alternatively have a customer specific URL embedded thereon. The customer specific URL may be embedded in the tag193 (which is, particularly, a passive NFC tag). In this regard, when thewireless interface112 interacts with the contactless enabledchip115, the customer specific URL gets transmitted to for access by thecustomer device102. As compared the general website URL, the customer specific URL is unique to the customer and thecontactless card104. Thus, in this embodiment, each card that is issued for each customer incudes a different, unique website URL that is specific to the particular customer and card. Further, the customer specific URL may be limited in usage. In particular and in one embodiment, the customer specific URL is valid for only a one-time use. In other embodiments, the validity may last for a different predefined number of uses (e.g., two-uses, three-uses, etc.). In this example, the one-time customer specific URL may be available for activating the customer account associated with thecontactless card104 initially after receipt of thecontactless card104 by the user. By limiting the validity of the customer-specific URL, the customer-specific URL may be deactivated after the webpage is accessed. Beneficially, this feature prevents (i) continued access to a website that may allow account access which may thwart potential fraudsters, and (ii) enables that specific URL to be reused or recycled for later subsequent cards thereby decreasing the processing requirements of generating different customer specific URLs for thousands or millions of customers.
• As indicated above, the customer specific URL stored in thetag193 may direct a web browser to a unique online web portal associated with the specific user, so that the user may access an account associated with thecontactless card104 and specific to the customer. In this example, the providerinstitution computing system108 may recognize thecustomer device102 and thecontactless card104 and allow for immediate access to the customer's online account. Alternatively or additionally, based on the customer specific URL, the card may then be automatically activated without requiring any additional information regarding the customer or card. In this regard, the specific website unique to the customer and/or thecontactless card104 may direct a web browser to an activation website unique to thecontactless card104. As such, less identification information may be needed in order to activate thecontactless card104. Further, the customer specific URL may direct a web browser of thecustomer device102 to register thecustomer device102 with thecontactless card104. In this example, the providerinstitution computing system108 may store information regarding thecustomer device102 in a customer profile within thecustomer database120 associated with the customer andcontactless card104. In this way and after activation, the providerinstitution computing system108 may allow for future immediate access to online accounts associated with thecontactless card104 via the customer device (i.e., password-less login). This results in reduced friction for customers accessing online accounts and activating their card while also bolstering security through the use of both thecustomer device102 and thecontactless card104.
• As indicated and alluded to above, the customer specific URL may be dynamic in nature. In this regard and in the situation where the customer does not have a computer application associated with the card issuer/provider institution installed on their mobile device, the URL takes the customer to a website or page to activate their card. The customer then enters additional information (e.g., their PIN) to complete the authentication. This may be used in co-branding situations: the provider institution has a co-branding arrangement with a merchant. The customer may think they just have the merchant's contactless card and is not aware that they have any sort of relationship with the provider institution. Thus, the customer is verified/authenticated based on the additional information entered in combination with the card and phone data being recognized by providerinstitution computing system108. In another scenario, the URL takes the customer to a page to login to mobile banking (i.e., the provider institution application). Here, there is no need to provide further authentication because the customer has already unlocked their phone that is recognized (Factor #1), and the customer is in possession of their card (Factor #2). There is a two-factor authentication/verification of the customer so that the card can be activated.
• The contactless enabledchip115 may also have a password embedded thereon. The password may be embedded in thetag193 of the contactless enabledchip115 such that when thewireless interface112 interacts with the contactless enabledchip115, the password gets accessed by thecustomer device102. Thecustomer device102 may then prompt the user to enter the password (e.g., a PIN, a biometric such as fingerprint, voice print, face print, etc.). If the customer enters the right password, then access to the account associated with the card may be permitted. In some embodiments, the password may be provided via email, mail, etc. to the customer. In one example, the password is received by thecustomer device102 and populated into a field on either a web browser or a mobile application associated with the provider institution. A check may then be implemented by the providerinstitution computing system108 to ensure the provided password matches the password received from the contactless enabled chip. In this way, the password may provide a layer of authentication because it requires the customer to have possession of thecustomer device102 that may be associated with the account associated with thecard104. Thus, thecustomer device102 may be registered with the account before the user receives thecard104 such that thedevice102 may receive the passcode or password instantly or nearly instantly from the providerinstitution computing system108 upon new account sign-up or registration. That way, if the card that is received by the customer does not include a matching passcode or password, registration and activation (or, account access) is denied.
• In some embodiments, the chip may include a cryptographic token, cryptographic key, digital certificate, or encryption algorithm that is profiled to the user. In this situation, the chip may not include a username and/or password of the user. Rather, the stored information (e.g., token, etc.) is the authentication mechanism for the user. This stored information will authenticate and identify the user during each tap (e.g., account access situation). The cryptographic token, cryptographic key, digital certificate, or encryption algorithm may change in response to being accessed or transmitted to acustomer device102 during a tap. The cryptographic token, cryptographic key, digital certificate, or encryption algorithm may serve as identification information. Beneficially, this format provides a layer of security by obfuscating the information from people who may unintentionally or intentionally intercept the token or key. The cryptographic token, etc. may be used to identify and authenticate the user such that the user, via the customer device, is granted access to some or all of their account information. For example, in some embodiments, the cryptographic key (e.g., token, etc.) may be embedded in thetag193 of the contactless enabledchip115 such that when thewireless interface112 interacts with the contactless enabledchip115, the cryptographic key (e.g., token, etc.) gets accessed by thecustomer device102. That is, thecustomer device102 receives the cryptographic key (e.g., token, etc.). In some embodiments, thecustomer device102 may perform an algorithm (e.g., a decryption algorithm) on the cryptographic key (e.g., or token, etc.) in order to identify the user. In some embodiments, thecustomer device102 may transmit, via the network, the cryptographic key (e.g., or token) to the providerinstitution computing system108 in response to accessing the cryptographic key (e.g., or token, etc.). That is, thecustomer device102 may use to cryptographic key (e.g., or token, etc.) in an attempt to access and request data (e.g., data regarding the user's account) from the providerinstitution computing system108. The providerinstitution computing system108, in response to receiving the cryptographic key (e.g., or token, etc.), may use the cryptographic key (e.g., or token, etc.) to identify the user associated with the cryptographic key (e.g., or token). In some embodiments, the providerinstitution computing system108 performs a decryption algorithm with the cryptographic key (e.g., or token) and uses the decrypted key in order to determine (e.g., find or identify) a customer in thecustomer database120 that is associated with the cryptographic key (e.g., or token, etc.). In this way, the cryptographic key (e.g., or token, etc.) can be used to identify the user. Further, the providerinstitution computing system108 may authenticate the user and allow access to account information associated with the user. For example, the user may be authenticated if the providerinstitution computing system108 determines that information received from thecustomer device102 that identifies the customer device102 (e.g., a media access control identification number of the customer device102) is registered and associated with the identified user within thecustomer database120. If the providerinstitution computing system108 cannot authenticate the user based on the information received from thecustomer device102, the providerinstitution computing system108 may send instructions to thecustomer device102 that cause thecustomer device102 to display a prompt for additional authentication information. In some embodiments, the additional authentication information may be a personal identification number (PIN), a voiceprint, a fingerprint, a face print or other biometric data of the user. Thecustomer device102 may receive the additional authentication information from the user, and in response, transmit the additional authentication information to the providerinstitution computing system108. The providerinstitution computing system108 may use the identification information (e.g., token, etc.) and additional authentication information (e.g., the PIN) to authenticate the user and allow thecustomer device102 to access and display some or all of the user's account information. In some embodiments, the providerinstitution computing system108 authenticates the user via cross referencing the additional authentication information with stored information regarding the user within thecustomer database120. The providerinstitution computing system108 may, in response to authenticating the user, allow thecustomer device102 to access and display all or part of the user's account.
• The providerinstitution computing system108 may be owned by or otherwise associated with a provider institution. The provider institution may be a financial institution, such as commercial or private banks, credit unions, investment brokerages, and so on. The provider institution can also include any commercial entity capable of maintaining charge accounts, including retailers, vendors, service providers, and the like. In the example shown, the provider institution is an issuer of thecontactless card104. Accordingly, the provider institution and associated provider institution computing system may also be referred to herein as the card issuer and cardissuer computing system108 herein. The cardissuer computing system108 is configured to manage charge accounts and authorize transactions involving debits from charge accounts associated with existing customers.
• The cardissuer computing system108 includes anissuer network logic116, a transactioncard processing circuit118, and acustomer database120. Theissuer network logic116 is structured to enable the cardissuer computing system108 to connect to and to exchange information over thenetwork106 with, for example, thecustomer device102. Theissuer network logic116 may include a network interface structured to send and receive data over thenetwork106.
• Thecustomer database120 is structured as a repository for information. In this regard, thecustomer database120 is configured to store, hold, and maintain information for a plurality of customers of the provider institution. For example, thedatabase120 may store information for customers with issued cards (e.g., card104), including for example, personal customer information (e.g., names, addresses, phone numbers, and so on) and financial information (e.g., associated financial institutions, account numbers, available credit, credit history, and so on). The information contained in thecustomer database120 may be used by the cardissuer computing system108 to perform a variety of checks surrounding a given contactless card, including for example, confirming identifying customer information, determining a customer's transaction history, determining a customer's available credit, and so on.
• The transactioncard processing circuit118 is structured to process or facilitate processing of transactions by thecard104. The transactioncard processing circuit118 is structured to receive a transaction card authentication request from a website orcustomer device102 over the network106 (or, via other communication means). The authentication request may include a token and a cryptogram. The token may be used to obscure sensitive data regarding at least one of thecard104, the account associated with the card, thecustomer device102, or the customer. The cryptogram may be generated by thecustomer device102 after the tap with thecard104. The cryptogram may serve as an additional layer of security for at least one of a password-less login to an account associated with the card or an activation of thecard104.
• The transactioncard processing circuit118 may be embodied as a processing circuit having one or more processors coupled to one or more memory devices. Thus, the transactioncard processing circuit118 may have the structure described herein. As alluded to above, the transactioncard processing circuit118 is structured to process transaction card applications, issue and activate transaction cards, approve transactions, approve entry into web-based accounts, and/or general respond to information and requests received by the cardissuer computing system108. In some embodiments, the transactioncard processing circuit118 may include or utilize multiple processors throughout the cardissuer computing system108.
• Referring now toFIG.2, amethod200 of issuing and activating a new or replacement contactless card is shown according to an example embodiment. Becausemethod200 may be implemented using the components ofFIG.1, reference may be made to one or more components to aid explanation ofmethod200.
• Atprocess201, a new contactless card application is received. In particular, atprocess201, the cardissuer computing system108 receives a new contactless card application from a customer. For example, the customer may create the application for a contactless credit card at any of a number of brick and mortar locations. Or, as another example, the customer may create the application electronically, such as via a website displayed on thecustomer device102. The new contactless card application can be received by the transactioncard processing circuit118 from thenetwork106 via acustomer device102 or website. Upon receipt of the application, the transactioncard processing circuit118 may cause an underwriting of the new contactless card using typical and conventional processes. In this regard, identifying information regarding the customer provided in the application may be stored in thecustomer database120, which can be used for underwriting as well as subsequent authentication or authorization of transaction requests.
• Atprocess202, upon completing the underwriting process and approving the new contactless card application for the applicant, the contactless card is issued. In particular, the transactioncard processing circuit118 causes issuance of thecontactless card104 corresponding to the contactless card application of the customer. Issuance includes causing or facilitating a sending of thecontactless card104 to the customer (e.g., by mail). In this regard, the transactioncard processing circuit118 sends instructions to have the card issued. Thecontactless card104 may first be printed or otherwise generated by a manufacturer. The issuer may then directly or via a third party cause theinformation114 to be loaded onto the card. An issuance request sent by the transactioncard processing circuit118 may include instructions to embedcertain information114 into the card. In one example, the issuance request includes instructions to embed a uniform recourse locator (URL) into a tag and, particularly a passive NFC tag, on the contactless enabled chip of the contactless card. As another example, the information may include a general URL, a customer specific URL, or specific identifying information based on the application (e.g., information regarding the applicants customer device, password, etc.). The customer may receive thecontactless card104 in a variety of ways. For example, the customer may pick up thecontactless card104 at a brick and mortar store or receive the contactless card in the mail.
• Atprocess203, the new contactless card and associated account are activated. The activation is done via a tap-to-activate method. The tap-to-activate process includes a wireless transmission from thecontactless card104 to thecustomer device102. In particular, the wireless transmission is an NFC communication between thecontactless card104 andcustomer device102. In other embodiments, a different wireless transmission protocol may be used, such as Bluetooth. It is to be understood that while the physical embodiment of thecontactless card104 and thecustomer device102 may be physically tapped, the communication ofinformation114 occurs wirelessly or without the presence of a physical electrical connection.
• Thecustomer device102 may transmit information regarding the customer and the card to cardissuer computing system108 to activate thecontactless card104. In some embodiments, thecustomer device102 may communicate continuously with the cardissuer computing system108 to verify and activate the contactless card. The contactless communication between thecontactless card104 andcustomer device102 causes thecustomer device102 to transmit data pre-loaded onto the card and information from the customer device102 (e.g., phone number, carrier, or other identifying data) to the cardissuer computing system108. The cardissuer computing system108 may then automatically or nearly automatically activate thecontactless card104 for transactions (e.g., payments) based on information received during the application process. That is, the card issuer computing system may cross-reference stored data in the customer database120 (e.g., from the application) with the information received as a result of the contactless communication and automatically activate the transaction card based on a successful cross-reference or matching. In other embodiments, more information is needed before activation occurs.
• As described in detail below, the cardissuer computing system108 may save information regarding thecustomer device102 that was received during the activation of thecontactless card104 to ease and enhance security of future contactless communications. For example, information regarding thecustomer device102 may include the phone number, carrier information, serial number, mobile identification number (MIN), mobile subscription number (MSIN), etc. The cardissuer computing system108 may then reference the stored information regarding thecustomer device102 during future password-less login attempts to the online account associated with the contactless card in order to provide enhanced security (e.g., by only allowing expedited password-less login on a known customer device) while reducing friction for the customer (e.g., by allowing the customer to tap their contactless card to their customer device in order to securely and quickly login to their account).
• In summary ofmethod200, thecontactless card104 is tapped to thecustomer device102. An example “tap”300 is shown inFIG.3. As shown, thecustomer device102 is displaying a blankgraphical user interface302. That is, thecustomer device102 is not displaying a mobile customer application or a web browser. Rather and in this example, thecustomer device102 may be displaying a home screen. As depicted, thecontactless card104 is moved into close proximity of thewireless chip112 of thecustomer device102 and a contactless communication occurs. In the example shown, a NFC transmission of information from thecard104 to thedevice102 occurs. In this regard, thewireless chip112 receives the information114 (in particular, only certain aspects thereof) as a result of the communication and forwards, passes, or otherwise transmits the transmittedinformation114 to theprocessor110 of thecustomer device102. In one example, thecustomer device102 accesses atag193 from thecontactless card104 as a result of the tap. A web browser application running on thecustomer device102 is then redirected to an activation page. In one embodiment, thetag193 includes a customer specific URL that directs the web browser to a customer specific activation page to activate theircontactless card104. In another embodiment, thetag193 includes a general URL that directs the web browser to a general activation page where the customer can enter in verification information in order to activate thecontactless card104. In another embodiment, the cardissuer computing system108 already has information about thecustomer device102 stored in a customer profile within thecustomer database120 and when thecontactless card104 is tapped tocustomer device102, thecustomer device102 goes to a URL accessed within thetag193 and the cardissuer computing system108 automatically activates thecontactless card104 based on the knowncustomer device102.
• Referring now toFIG.4, amethod400 of a contactless communication between a customer device and a contactless card for at least one activating the contactless card, enabling a password-less login into an account associated with the contactless card, or directing a customer to specific URL is shown, according to an example embodiment. Each of these example implementations are explained herein with respect to themethod400.
• Atprocess401, information is received from a contactless card. In particular, a contactless card is placed near to, adjacent to, close to, or in contact or near-contact with a contactless reader to enable information to be transmitted wirelessly to the contactless reader. In particular, thecontactless card104 is placed adjacent to (e.g., within a distance that enables NFC communications to happen, such as 10 cm or less) thecustomer device102 such that communication of the information is shared (e.g., thecontactless card104 is tapped to the customer device102). As described herein, theinformation114 may include a general URL address, a customer specific URL address, an authentication token, etc.
• Atprocess402, a response to the information received occurs. In particular, thecustomer device102 responds to theinformation114 received from thecontactless card104. The response may be dependent on the information, the state of thecustomer device102, and/or a combination thereof. For example, in one embodiment, theinformation114 includes a customer-specific URL address and instructions that cause thecustomer device102 to open a web browser, populate the customer-specific URL into the web browser, and display an activation or authentication web page related to the customer-specific URL. In this instance, thecard104 may be in the process of activation. According to an alternative embodiment, theinformation114 includes instructions for theprocessor110 to launch a mobile application on thecustomer device102 and display an activation page therein. In this alternative embodiment, thecard104 may be in the process of activation as well.
• One response includes instructions to thedevice102 to automatically open an application and go to a web page (e.g., URL) associated with a URL embedded on thecontactless card104. In some embodiments, the application may be a web browser. In some embodiments, the application may include a customer application downloaded on thecustomer device102 provided by the card issuer. In some embodiments, the tap includes instructions to thecustomer device102 that causes theprocessor110 to automatically respond by opening the application and traveling to the URL (e.g., URL stored on the contactless card) provided to thecustomer device102 via the contactless communication. Thecustomer device102 may have computer implementable instructions that cause theprocessor110 to respond in a set manner that utilizes theinformation114 transferred by the contactless communication.
• In one example of a response, theinformation114 includes atag193 that may have a general URL stored therein and thecustomer device102 is in turn directed to display the webpage associated with the general URL on a display screen of thedevice102. In this embodiment, the URL is associated with a general website for activating the contactless card. In operation, thecustomer device102 may receive thetag193 via a NFC tap between thecontactless card104 and thewireless interface112. Thecustomer device102 determines the presence of the general URL in thetag193 and automatically navigates to the web page associated with the general URL. In this example, thecustomer device102 may have instructions stored thereon that cause the navigation. In another example, thetag193 includes instructions to thecustomer device102 that cause thecustomer device102 to navigate to the web page. In some embodiments, instructions stored in thetag193 also cause the account number on thecontactless card104 to automatically populate within a field of the web page associated with the general URL. In other embodiments, thetag193 includes the account number as data and thecustomer device102 includes instructions to automatically populate the account number into an appropriate field within the web page associated with the general URL. The web page associated with the general URL may then prompt the user to enter in additional information (e.g., a PIN) to verify the identity of the user. In certain embodiments and rather than transmitting and showing the account number, a tokenized version of the account number may be provided to the general website. This token may be cross-referenced with associated information, and the user may be required to enter information that is then matched to the information associated with the token. This may enable activation of the card or, after activation, account access. In this regard, thecustomer device102 may tokenize at least some of the information received from the card (e.g., the primary account number and expiration date of the card104). Tokenization may be done via one or more scripts, processes, and the like stored in an application of the provider institution. The token may then be transmitted to the cardissuer computing system108 for authentication.
• Based on the information transmitted in either the general or specific URL example (below), thecustomer device102 may pre-populate the information regarding the card (e.g., the card number, expiration date) within fields on the website that may otherwise need to be manually entered in order to identify the customer to activate the card. Thus, the information may save time in pre-populating one or more fields of a website.
• In a second example of a response, theinformation114 includes atag193 that has a customer specific URL stored therein. In other words, the URL is unique or customer specific. In operation, thecustomer device102 is directed to display the webpage associated with the customer specific URL on the display screen. The customer-specific website may not require entry of information regarding the contactless card. In this regard, the card may be automatically activated once the website is populated. As an example, information regarding the customer device may be matched with stored information to ensure that the customer device is associated with the intended customer of the card. This piece of information may be transmitted from the customer device to the provider institution computing system. Accordingly, information from each of the card and device is transmitted to the provider institution computing system, which can then verify the information and automatically activate the card without an explicit user input. Due to the potential limited use of the customer-specific URL (described above), the customer specific URL may then be deactivated while the card is activated such that the customer is free to use the contactless card. In another embodiment, another piece or pieces of information may be used to authenticate the customer and/or customer device in order to activate the card. Nonetheless, relatively little information may be required to activate the card relative to use of the general website. Examples of the another piece of pieces of information for activation may include any one or more of: confirmation of a code sent to the customer device, entry of a PIN, a confirmation of the name shown on the specific website, a previously-established password or passcode, and the like. Thus, use of the customer specific URL may streamline activation even more quickly than use of the general website URL.
• After the contactless card has been activated, the customer specific URL may direct thecustomer device102 to a unique online login portal. In other words, the website associated with the customer specific URL that was used to activate the card may give way to a unique online login portal. In this way, the customer specific URL enhances security by ensuring that only the specific customer device102 (e.g., stored in the customer database120) authenticated for the customer can enter into the online account associated with the card. The customer specific URL directs thecustomer device102 to a unique login portal and information regarding thecustomer device102 can be utilized by the cardissuer computing system108 to verify that thecustomer device102 is “registered” to the customer associated with the transaction card to allow access to the customer's online account. In this usage, “registered” may mean that thecustomer device102 and related information about thecustomer device102 is stored in thecustomer database120 such that the cardissuer computing system108 can identify the customer device associated with a particular customer. Thecustomer device102 may be “registered” during the application process for the account or transaction card. In some embodiments, as explained below, thecustomer device102 may be “registered” or identifiable based on information received regarding thecustomer device102 during activation of the transaction card or authentication of thecustomer device102 during a password-less login attempt.
• In another example, thetag193 may be used to reset a user's password (or, more generally, their credential) for their online account. This process is implemented after activation of the card. In one implementation, the user may already be at a web page login for the account or a mobile application login attempting to access the online accounts associated with thecontactless card104. The user may have forgotten his/her password and select an icon of “forgot password” on the screen. The user may then tap thecontactless card104 to thecustomer device102. Thecustomer device102 receives thetag193 as a result of the NFC tap and may transmit the tag193 (e.g., and associated data) to the cardissuer computing system108. The cardissuer computing system108 may then verify that the information contained in thetag193 is associated with the user's account and transmit instructions to thecustomer device102 to display a password reset page. The customer may simply enter into the customer device102 a new password and have this new password effective immediately. In this example, the cardissuer computing system108 verifies that the user is in possession of thecontactless card104 and the customer device102 (i.e., a match of these two components) to securely allow the user to reset his/her password. In other embodiments, the cardissuer computing system108 may require additional authentication information if thecustomer device102 is not recognized. Thus, in this example, security of the online account is achieved while also reducing the time commitment (e.g., friction) of the customer.
• As mentioned above, the response may depend on the state or configuration of thecustomer device102. For example, thecustomer device102 may be displaying a home screen when the tap occurs. As another example, thecustomer device102 is displaying a customer application, such as a mobile application, associated with the card issuer when the contactless card is tapped to thecustomer device102. In still another example, thecustomer device102 is displaying a browser (e.g., Safari® or Chrome®) when the contactless card is tapped to thecustomer device102. In one embodiment, the tag may include or be accompanied by instructions used to at least one of activate a web browser (e.g., from a home screen), direct the application to either a card activation screen or a log-in screen (e.g., for password-less login), or direct the browser that may be displayed on thedevice102 to the embedded URL. In this configuration, the tag includes instructions that are applicable with each of these configurations of thedevice102. In another embodiments, the instructions may require thedevice102 to be in a particular state, such as unlocked and on a home screen or unlocked with a browser open.
• Atprocess403, authentication information is received. In particular, thecustomer device102 receives authentication information regarding the customer associated with the card. In one embodiment, the customer may enter the authentication information. For example, the customer provide authentication information on an authentication page accessible by the general or specific URL described above. For example, the authentication page displayed in a mobile application on thecustomer device102 may ask for a PIN related to the account. Authentication information may also include, for example, biometric data, identifying information, a portion of the customer's social security number, phone number, etc., and/or a combination thereof. In certain embodiments and as described above, the customer device may also be authenticated or verified during this process.
• Thecustomer device102 may automatically forward information or otherwise communicate with the cardissuer computing system108 in response to the tap. For example, thecustomer device102 may have instructions (or receive instructions embedded on the contactless card104) to send information (e.g., identifying information) from the contactless card104 (e.g., received as a result of the tap) and information about the customer device102 (e.g., identifying information such as phone number, MIS, or location) to the cardissuer computing system108. Thus and with respect to the authentication information, the cardissuer computing system108 may then cross-reference or otherwise verify the information in order to automatically authenticate the customer and/or activate the card. For example, the cardissuer computing system108 may verify the information received based on the location of thecustomer device102, a phone number of thecustomer device102, type ofcustomer device102, and information received during the application process or information stored in thecustomer database120. For example, the location of the device may be used in authenticating the customer: if the customer is in a predefined location or on a non-open network, then they may pass the first layer of authentication. In some embodiments, thecontactless card104 may be automatically activated based on the received information (i.e., without additional authentication information). The cardissuer computing system108 may then send a confirmation notification in response to successfully verifying and activating thecontactless card104. In some embodiments, more information is needed and the cardissuer computing system108 transmits or otherwise causes a prompt to the customer to enter in more identifying information in order to complete activation of the transaction card or authentication of the customer.
• Atprocess404, a response is provided based on the authentication. Assuming the card issuer has authenticated the card and/or user, atprocess404, the mobile device provides a response to the customer regarding the authentication. Regarding card activation, thecustomer device102 may receive a confirmation of the authentication and resulting activation of thecontactless card104 from the cardissuer computing system108. Regarding password-less login, the cardissuer computing system108 transmits instructions and re-directs the web browser or mobile application to a dashboard of the online account in response to a successful authentication of the customer during the password-less login. The cardissuer computing system108 may transmit instructions and re-direct the web browser or mobile application displayed on thecustomer device102 to display a confirmation notification. In some embodiments, the processor of thecustomer device102 automatically re-directs the web-browser or mobile application to a different page that displays a received notification or confirmation.
• Referring now toFIG.5, an example500 of acontactless card104 and acustomer device102 being tapped together for a password-less login is shown and explained.FIG.5 builds on themethod400. In particular, in this embodiment, the customer has established an account at the card issuer institution (i.e., provider institution associated with the card issuer computing system108). Accordingly, the customer may have established credentials for accessing an account associated with the card104 (e.g., a username and password, answers to security questions, etc.).FIG.5 depicts an improvement where the user does not have to enter their credentials manually, nor does the user have to store their password electronically within thecustomer device102 or on the cloud. This improvement results in low friction for the user and potentially less risk of the user's account information being hacked or stolen.
• In the example shown, a graphical user interface of alogin page502 may be displayed in a customer application that has been installed on thecustomer device102. In some embodiments, the graphical user interface depicts alogin page502 displayed in a web-browser. The graphical user interface of thelogin page502 may be displayed in response to the communication between thecontactless card104 and customer device102 (e.g., the NFC tap described herein). In some embodiments, such as the in the example depicted inFIG.5, the graphical user interface of thelogin page502 may be first opened on thecustomer device102 by the customer, the customer may then tap thecontactless card104 to thecustomer device102 such that communication of theinformation114 occurs there-between. The customer application running on thecustomer device102 may simulate a contactless payment and obtain card data (e.g., PAN, expiration data, etc.) regarding the contactless card. The customer application may convert the card data to a token (alternatively, the received contactless card data may already be tokenized). In either configuration, tokenization protects the sensitive information (e.g., the PAN). Further, the token, which in this instance refers to tokenized card data such as the PAN, in combination with the customer device data (e.g., phone number, serial number, etc.) serves as the credentials for the account. Thecustomer device102 transmits the token and customer device data to the cardissuer computing system108. The cardissuer computing system108 receives this information, which may be processed as business as usual using the transactioncard processing circuit118. The token may be associated with the customer (e.g., via a customer identifier associated with the token) so that thecircuit118 may identify and confirm that the user is indeed associated with this card to authorize and enable account access. Thus, in this situation, the customer does not have to provide any type of information and account access is automatic. In some embodiments, the customer first enters theirusername504, then taps thecontactless card104 to thecustomer device102 to auto-populate thepassword506 field. In some embodiments, thelogin page502 may not display theusername504 andpassword506 fields, rather thelogin page502 may simply prompt the customer to tap thecontactless card104 against thecustomer device102 to login. In each of these configurations, a relatively easy method of logging onto the user's online account associated with the card is provided to enable viewing and managing the account.
• In one example of password-less login that requires additional authentication information, thecustomer device102 may display a prompt to the user for a second form of authentication in order to complete the login. If the cardissuer computing system108 does not recognize the user associated with the contactless card104 (e.g., an password) as the user associated with thecustomer device102, then the cardissuer computing system108 may prompt the user for a second form of authentication in order to enhance security. Examples of second forms of authentication may include instructions for the customer to enter biometric data into thecustomer device102, enter in a personal identification number (PIN) of the customer, or enter in other authentication information such as the last four numbers of the customer's social security number, phone number, etc.
• Referring now toFIG.6, an exemplary image of requiring additional authentication information is shown. Here, a customer device displaying anauthentication page650 on a graphical user interface is shown, in accordance with an example embodiment. Theauthentication page650 may be displayed via a web browser on thecustomer device102. In this example, theauthentication page650 includes averification field652. The verification field is a field that a customer may enter in their authentication information. InFIG.6, theverification field652 and related prompt request is for the customer to enter a portion of their social security number (e.g., the last four digits of the social security number). In other embodiments, other forms of authentication information may be used/required. The customer may enter their last four digits of their social security number into theverification field652 via a keyboard on or displayed on thecustomer device102. This additional authentication information may be sent to thecircuit118, which matches this information with stored information regarding the customer to authenticate the customer.
• Thecustomer device102 may forward the authentication information to the cardissuer computing system108 in order to authenticate the customer. For example, thecustomer device102 may transmit via thenetwork106 information entered into the authentication page (e.g., PIN, address, security questions filled out in the application, online login credentials if the customer is an existing customer, etc.). The cardissuer computing system108 may then authenticate the customer to either activate thecontactless card104 for use in transactions such as payments, and/or allow access to the online accounts associated with the transaction card. Thus, this secondary authentication information process may be used with card activation and/or account access. In some embodiments, the customer device may send an indication to cardissuer computing system108 that the customer has already logged into the phone (i.e., customer device102) via a passcode or biometric scan, with such information also serving as the authentication data/information (i.e., the secondary authentication information). This dual factor authentication provides minimal friction to the customer. That is, the computing system provides enhanced security by requiring two forms of authentication (e.g., the tap of the card and entry of information) while minimizing the inconvenience to the customer.
• In some embodiments, the cardissuer computing system108 may save the information received regarding thecustomer device102 into thecustomer database120 automatically (e.g., “register” thecustomer device102 to the authenticated customer) in response to the successful authentication of the customer. In some embodiments, the cardissuer computing system108 may transmit instructions, or otherwise cause thecustomer device102 to prompt the customer with selectable “Yes” or “No” icons regarding whether the customer would like the cardissuer computing system108 to save information regarding thecustomer device102 in thecustomer database120. If the information regarding thecustomer device102 is saved in thecustomer database120, then future authentications of password-less logins via a tap between thecustomer device102 andcontactless card104 may be expedited in the future. If the information regarding thecustomer device102 is not saved in the customer database120 (e.g., the customer responded “No”), then future authentications for the password-less login may requireprocess403 to ensure security.
• Referring now toFIG.7A, thecustomer device102 displaying anonline account dashboard700 on agraphical user interface702 according to an example embodiment is shown. In some embodiments, thegraphical user interface702 may be displayed on a web-browser or within the customer application on thecustomer device102. The dashboard may be shown automatically without requiring credentials based on the password-less login described above. Theonline account dashboard700 may have been automatically displayed in response to the customer entering in the verification information. Thecustomer device102 may contain instructions stored thereon to automatically re-direct and try to gain access to theonline account dashboard700 in response to the password-less login and account activation. In some embodiments, thecustomer device102 receives instructions to re-direct the graphical user interface to the online account dashboard from the cardissuer computing system108. Theonline account dashboard700 may allow the customer full access to the customer's online accounts to manage same. The online account may include the account associated with thecontactless card104 along with other checking, savings, or credit accounts that the customer has with the provider institution.
• FIG.7A may be subsequent toFIG.7B.FIG.7B shows a customer device displaying aconfirmation page750 on agraphical user interface752 upon activation of the card, according to an example embodiment. Theconfirmation page750 includes aconfirmation notification754 that is intended to notify the customer that the contactless card has been successfully activated and is available for immediate use. As discussed above, thegraphical user interface752 may be displayed in a web browser or within a customer application. In some embodiments, theconfirmation page750 may be displayed in response to instructions to re-direct the graphical user interface of thecustomer device102. In some embodiments, thecustomer device102 may automatically re-direct the graphical user interface to display any notification, error, denial, or confirmation received from the cardissuer computing system108.
• Referring now toFIG.8, a flow diagram800 of a method of a passwordless login to an account is shown, according to an example embodiment. Themethod800 depicts a flow from thecontactless card104, thecustomer device102, and the cardissuer computing system108.
• Inprocess802, information regarding accessing an account associated with the contactless card is embedded in the card. In particular, this information may be embedded in therecord193. This “account access” information may include information regarding the user's customer device, a username, a PIN, a password, and so on. According to one embodiment, this information is preloaded into thechip115 when the user receives thecard104. In another embodiment, this information may be written to the chip115 (e.g., added to the tag193) during a transaction with the card104 (e.g., during a tap with the customer device102). As described herein, this information may also include the customer-specific URL or general website URL that is embedded in therecord193 of the contactless enabled chip/interface.
• At process804, the contactless card transmits the information to thecustomer device102 via a NFC transmission. In other words, thecustomer device102 causes the tag to be transmitted to thecustomer device102.
• Atprocess806, thecustomer device102 receives the transmitted information within the tag. That is, thecustomer device102 receives the tag and embedded information as a result of the NFC communication. Atprocess808, thecustomer device102 reacts or otherwise responds to the NFC communication by launching a web browser or a mobile application to access an online account associated with thecontactless card104. Atprocess810, thecustomer device102 sends identity information such as a MIN, MSIN, or phone number regarding thecustomer device102 and the embedded information received from thecontactless card104 to the cardissuer computing system108 via thenetwork106.
• Atprocess812, the cardissuer computing system108 receives the identity information regarding thecustomer device102 and the embedded information. Atprocess814, the cardissuer computing system108 authenticates the customer. In an example, the cardissuer computing system108 may verify that a customer profile within acustomer database120 includes the identity information of thecustomer device102 and that the customer profile also includes the embedded information that is specific to thatcontactless card104. In this way, the cardissuer computing system108 may automatically authenticate the user and provide access, atprocess816, to the account associated with the contactless card because of the known and verified information. Thus, the cardissuer computing system108 can automatically authenticate the user and provide access to the online account since there are already two security measures overcome. For example, the first security measure is that the user is in possession of the “registered”customer device102 and thecontactless card104. The second security measure is that the user was able to access or unlock thecustomer device102. In this way, security of the accounts associated with thecontactless card104 is provided and friction for the user in accessing the accounts is reduced. Alternatively, the tap may be done when the device is in the locked state. The tap may cause the phone (i.e., device) to wake-up and the user's biometric may unlock the phone. Then, the process may continue as described above.
• Alternatively, if thecustomer device102 is not yet “registered” or the identity information of thecustomer device102 cannot be verified based on the customer profile, then atprocess818 thecustomer device102 receives a prompt for authentication information. Thecustomer device102 may then redirect the display of the web browser or the mobile application to display a request to the user for authentication information. Examples of such a display is shown and described in reference toFIG.6. At aprocess820, thecustomer device102 receives the authentication information as an input on the device. Atprocess822, thecustomer device102 then forwards the received authentication information to the cardissuer computing system108. The cardissuer computing system108, atprocess814, may then automatically authenticate the user based on the received authentication information. In one example, the cardissuer computing system108 authenticates the user by cross referencing the authentication information with information stored in the customer profile within thecustomer database120. After the user is authenticated, the cardissuer computing system108 provides access to the online account associated with thecontactless card104 only to thecustomer device102. In one example, the cardissuer computing system108 sends instructions to thecustomer device102 that causes thecustomer device102 to display the online account information on a display.
• At aprocess824, thecustomer device102 receives confirmation of the authentication and displays via a graphical user interface on either the web browser or mobile application the online account information. In some embodiments, the user may make a payment, transfer funds, redeem rewards, close the account and so on from the page displaying the online account information. In some embodiments, as explained above, the user will have an option during the authentication process to “register” thecustomer device102 for faster access to the online accounts in the future.
• Referring now toFIG.9, a flow diagram900 of a method of a communicating with a transaction card having key stored thereon to identify a customer is shown, according to an example embodiment. In some embodiments, thetransaction card104 may include payment information and information that is indicative of an identity of a user associated with the card. That is, in some embodiments, thetransaction card104 may include atag193 that is configured to store payment account information and information that is indicative of the identity of the user associated with the transaction card. The information that is indicative of the identity of the user associated with the user of the transaction card may include a cryptographic key, a cryptographic token, or a digital certificate stored within thetag193. The information that is indicative of the identity of the user associated with the user may not be used to validate or authorize a transaction. Alternatively, the payment account information may be used to identify the user instead of, or in addition to, the information that is indicative of the identity of the user associated with the transaction card. The cryptographic key may be used to allow the user to access a portion of their online account information, change a password of the online account, or to otherwise identify or authenticate the user.
• At aprocess902, thetransaction card104 is embedded with information. In some embodiments, the information includes payment account information and information that is indicative of an identity of a user associated with the transaction card. In some embodiments, the information embedded on thetransaction card104 includes only the information that is indicative of an identity of a user associated with the transaction card. The information that is indicative of an identity of a user associated with the transaction card includes a cryptographic key, a cryptographic token, or a digital certificate. The information that is indicative of an identity of a user associated with the transaction card may also be stored within a database of a cardissuer computing system108 at the time of issuance of thetransaction card104. For example, the database may include a list of corresponding keys that may be used by the cardissuer computing system108 to identify a particular transaction card and/or identify of a user associated with thetransaction card104.
• In some embodiments, atprocess902, thetransaction card104 is also embedded with an encryption algorithm that is configured to encrypt the cryptographic key or cryptographic token stored ontransaction card104. In some embodiments, the encryption algorithm includes a cryptographic algorithm. In one example of an encryption algorithm, thetransaction card104 may be configured to receive a request from a device (e.g., acustomer device102 having a near-field communications NFC reader) that includes a request for the cryptographic key or token and a seed (e.g., a bit sequence, random number, or word). The request may then cause thetransaction card104 to perform an encryption of the cryptographic key using the seed, the cryptographic key or token (e.g., stored within the transaction card), and/or other information as inputs into the encryption algorithm and cause thetransaction card104 to transmit the output of the encryption algorithm to the device (e.g., the customer device102).
• In some embodiments, the request of the command also causes a count register of thetag193 to increment (e.g., count up). The encryption algorithm (e.g., cryptographic algorithm) may have multiple inputs including a value of the count register, the cryptographic key, and the seed and a single output that may be transmitted to the customer device. In some embodiments, the seed is a random number or data bit(s) (e.g., 1, 2, 3, 4, 5, or more bits) that is randomly generated by thecustomer device102 when thecustomer device102 makes the request.
• Thetransaction card104 may be configured to embed the information that is indicative of an identity of a user associated with the transaction card within a uniform resource locator (URL) string configured to cause acustomer device102 to navigate to a particular web address and pass the embedded information that is indicative of the identity of the user to a cardissuer computing system108. This may be advantageous because it allows a user to use their transaction card with one or manydifferent customer devices102 and/or terminals to access their account in response to a two, three, or four factor authentication. More details regarding the encryption algorithm and other algorithms stored on thetransaction card104 are discussed in more detail herein.
• At process904, the contactless card transmits the information to thecustomer device102 via a NFC transmission. In other words, thecustomer device102 causes at least a portion of the tag (e.g., information that is indicative of an identity of a user associated with the transaction card) to be sent to thecustomer device102. In some embodiments, the contactless card does not transmit any payment account information to thecustomer device102 at process904. In other embodiments, thecontactless card104 may transmit both payment account information and information that is indicative of an identity of a user associated with the transaction card at process904. In some embodiments, thecontactless card104 may transmit only payment card information at process904. In an example, the exact information that is sent at process904 is dependent upon a command (e.g., a wirelessly transmitted NDEF message that requests particular information) made by thecustomer device102 to thetransaction card104. That is, in some thetransaction card104 may have an integrated circuit that is responsive to particular commands made by thecustomer device102. In some embodiments, the information that is indicative of an identity of a user associated with the transaction card is first encrypted as explained throughoutFIG.9, and below in reference toFIG.10.
• Atprocess906, thecustomer device102 receives the information from thetransaction card104. In some embodiments, thecustomer device102 receives the encrypted information that is indicative of an identity of a user associated with the transaction card. In some embodiments, thecustomer device102 receives the payment account information and packages and encrypts the payment account information via an encryption algorithm stored within the mobile application on thecustomer device102. In some embodiments, thecustomer device102 receives a URL from the transaction card that has the information that is indicative of an identity of a user associated with the transaction card stored within a query string. Thecustomer device102 may be configured to automatically launch a browser (or to otherwise automatically navigate a browser) of thecustomer device102 to the URL. In this way, thecustomer device102 navigates to the URL received from the transaction card, thecustomer device102 may act as a conduit in transmitting the data stored within the query string (e.g., the information that is indicative of an identity of a user associated with the transaction card) directly to the cardissuer computing system108.
• Atprocess908, thecustomer device102 transmits the information that is indicative of an identity of a user associated with the transaction card to the cardissuer computing system108. As indicated above, thecustomer device102 acts as a conduit and automatically forwards the information that is indicative of an identity of a user associated with the transaction card. For example, thecustomer device102 may include instructions stored thereon that are configured to cause thecustomer device102 to automatically forward the information that is indicative of an identity of a user associated with the transaction card in response to requesting and receiving the information from the transaction card104 (e.g., via processes902-906).
• In some embodiments, thecustomer device102 receives instructions from the transaction card104 (e.g., stored within the tag193) that are configured to cause thecustomer device102 to automatically forward the information that is indicative of an identity of a user associated with the transaction card to the cardissuer computing system108. For example, thecustomer device102 may receive instructions to automatically transmit the received information from thetransaction card104 in response to the contactless communication to the cardissuer computing system108 via the network. In this way, the cardissuer computing system108 may always or substantially always (e.g., always unless an error happens) receive notifications of a contactless communication (e.g., a contactless communication requesting identity information) between acustomer device102 and atransaction card104 immediately after the contactless communication occurs. Thus, the cardissuer computing system108 is able to monitor and check for potential fraud or theft. For example, the cardissuer computing system108 may detect or monitor for contactless communications between a customer device that is not known (e.g., a customer device that does not belong to or have been used by the user) and thetransaction card104 in order to flag a potential fraudulent activity (e.g., a non-recognized customer device). Further, in the case that thecustomer device102 does not respond or cannot respond to the instructions to transmit identity information to the cardissuer computing system108, a time stamp placed on the identity information (e.g., via the encryption algorithm on the transaction card) may be used to determine that the contactless communication occurred after a pre-determined amount of time (e.g., 5 minutes) and, in response, automatically block access to an account.
• In some embodiments, the information that is indicative of an identity of a user associated with the transaction card includes a cryptographic key or token that is stored within a space in a memory of thetransaction card104. In some embodiments, thetransaction card104 may use the cryptographic key and seed information (e.g., and/or other information such as a count number) as inputs into an encryption algorithm (e.g., a cryptographic algorithm) and outputs a bit sequence that may represent the encrypted cryptographic key. In some embodiments, thecustomer device102 may forward the received encrypted cryptographic key and seed information (and/or other information such as the count number of how many times the cryptographic key has been requested) to the cardissuer computing system108. For example, in some embodiments, thecustomer device102 may be running a web page associated with the card issuer on a web browser or a mobile application associated with the card issuer that includes executable instructions that cause thecustomer device102 to automatically encrypt, package, and forward the information received from thetransaction card104 to the cardissuer computing system108 via the network. For example,FIG.10 includes examples of how thecustomer device102 may be running a program that causes the customer device to package or encrypt the information received from the transaction card104 (e.g., the encrypted information and/or other information) and transmit the package and/or information received from thetransaction card104 to the cardissuer computing system108.
• In some embodiments, the information that is indicative of an identity of a user associated with the transaction card is received from the transaction card104 (e.g., the tag) and is embedded within a query string of a URL. Thecustomer device102 may have instructions stored thereon that automatically enter the URL into a browser or similar application and cause the information that is indicative of an identity of a user associated with the transaction card to be sent to the cardissuer computing system108. For example, thecustomer device102 may automatically recognize receipt of a URL and execute instructions stored thereon that cause thecustomer device102 to navigate to the URL (e.g., open a browser or enter the URL into the browser.) The URL may include a domain associated with the cardissuer computing system108, and the information that is indicative of an identity of a user associated with the transaction card may be embedded within the URL (e.g., within a query string of the URL). Thus, when thecustomer device102 navigates to the URL, thecustomer device102 navigates or interfaces with the cardissuer computing system108 via requesting internet access into the domain of the cardissuer computing system108 and the information indicative of the identity of the user associated with the transaction card (e.g., encrypted identity information) may be automatically entered or passed to the cardissuer computing system108. Thus, this technology may allow for a streamlined access via a customer to their online account via many different customer device102 (e.g., via a tap and contactless communication), while also protecting the account from unauthorized users via the key, algorithm, and/or multi-layered authentication steps (e.g., such as requesting additional authentication information).
• Atprocess918, the cardissuer computing system108 receives the information that is indicative of an identity of a user associated with the transaction card via a network connection to thecustomer device102. Atprocess920, the cardissuer computing system108 may decrypt the received information that is indicative of an identity of a user associated with the transaction card. For example, the cardissuer computing system108 may receive, as the information, an encrypted cryptographic key, seed information that was used to generate the cryptographic key, and/or a count number. The cardissuer computing system108 may then use the encrypted cryptographic key, the seed information that was used to generate the encrypted cryptographic key, and/or the count number as inputs into a decryption algorithm in order to generate an output that is used by the cardissuer computing system108 to cross-reference the output within a database on the cardissuer computing system108 that includes multiple cryptographic keys, each corresponding to a different customer. In this way, the decryption algorithm (and associated encryption algorithm on thetransaction card104 and/or the customer device102) ensures that a hacker or other electronic thief may not intercept the information in a form that has any value. Additionally or alternatively, many of the other steps described throughout this description may be used to further reduce the potential of fraudulent access or use of the accounts of customers (e.g., separation of payment information and identity information on thetag193, time stamps, instructions to automatically transmit information, count numbers, etc.).
• In some embodiments, the decryption algorithm may be used to detect fraud. That is, for example, the cardissuer computing system108 may cross reference the received information within a database that includes information previously received. The cardissuer computing system108 may include a security process that automatically recognizes that the cryptographic key, the seed information that was used to generate the cryptographic key, and/or the count number was previously received and determine that the information was intercepted or hacked by a fraudulent actor. That is, the cardissuer computing system108 may store the information received frommultiple customer devices102 over time within a database and cross-reference or otherwise check to make sure that each time new information that is indicative of an identity of a customer is received, that the new information has not previously been received. For example, if new information is received that includes an encrypted cryptographic key and a seed (e.g., that should have been randomly generated) that are identical to a previously received encrypted cryptographic key and previously received seed, then the card issuer computing system may make the determination that there is likely a fraudulent actor or computing system that has intercepted the previously received cryptographic key and seed and is now trying to use them in a fraudulent manner. Thus, in such example, the cardissuer computing system108 may automatically disable the account associated with thetransaction card104, reject or deny access to the account, and/or flag the internet protocol (IP) address from which the new information (e.g., the suspected fraudulent information) was received from. In some embodiments, where the cardissuer computing system108 has determined a likelihood of a fraudulent attempt to access an account associated with thetransaction card104, the cardissuer computing system108 may automatically generate and send an email or other electronic notification to an employee of the card issuer and/or to the user of the transaction account in order to notify them of the potential fraudulent activity.
• Atprocess922, the cardissuer computing system108 identifies an identity of the customer associated with the transaction card based on the received information (e.g., and/or the output of the decryption algorithm). The cardissuer computing system108 may identify the customer associated with the transaction card via cross-referencing the received or decrypted information indicative of the identity of the user with multiple references, keys, or tokens within a database, where each of the multiple references, keys, or tokens correspond to a customer and to a customer profile. In some embodiments, as explained above, the cardissuer computing system108 may also use information indicative of an identity of the customer device102 (e.g., received during the communications at process918) and cross-reference, verify, or check that the information identifying thecustomer device102 belongs or is known to have been used by the customer in the past.
• Atprocess924, the cardissuer computing system108 authenticates the customer. If the customer can be authenticated based on the received information ofprocess918, the cardissuer computing system108 may automatically go toprocess926. For example, if the customer profile of the customer does not require that additional authentication information is needed when logging in and the identity of thecustomer device102 is recognized by the cardissuer computing system108 as belonging to the customer, then the customer may be authenticated and the cardissuer computing system108 may proceed to process926. If the customer cannot be authenticated based on the received information ofprocess918, the cardissuer computing system108 may automatically generate an electronic notification and push or transmit the electronic notification to thecustomer device102 to prompt the user for additional authentication information atprocess910. For example, if the customer profile associated with the customer of thetransaction card104 requires, as a preference or rule of the customer, that additional authentication information is needed then the system may proceed to process910. In another example, the default of the cardissuer computing system108 may always be to generate an electronic notification and push or transmit the electronic notification to thecustomer device102 to prompt the user for additional authentication information and proceed to process910 unless the customer profile indicates that it is not needed (e.g., such as when the identity of customer device is known to be the customers).
• Atprocess910, thecustomer device102 prompts the user for additional authentication information. That is, the cardissuer computing system108 has determined that additional authentication information is needed in order to allow the mobile device (e.g., the device that requested access) to have access to any or all of the account information associated with the transaction card. The additional authentication information may be unique to the customer. That is, the type of additional authentication information needed atprocess910 may have been prescribed by the user (e.g., the owner of the account and transaction card) to be a particular piece of additional authentication information. In some embodiments, the type of additional authentication information may have a default preference where the user is prompted to provide a particular piece of additional authentication information. In some embodiments, the user may be able to select, on the mobile device atprocess910, the type of additional authentication information that the user would like to enter. In some embodiments, the additional authentication information includes biometric information (e.g., a thumb print on a thumb reader of the mobile device or facial recognition via a camera on the mobile device), a personal identification number (PIN), the last four of the social security number of the user associated with the account, security questions, code words or sentences, or a combination thereof. For example,FIG.11 depicts one example of a graphical user interface on a customer device that prompts the user for additional authentication information (e.g., a PIN number). In another example,FIG.12 depicts one example of a graphical user interface on a customer device that prompts the user for additional authentication information (e.g., biometric data). Further discussion of each of these examples and figures are provided below.
• Atprocess912, thecustomer device102 receives the authentication information. That is, atprocess912, the user interfaces with thecustomer device102 and enters their additional authentication information. In some embodiments, thecustomer device102 encrypts the additional authentication information in response to receiving the additional authentication information. For example, code on a mobile application or embedded within the website may take the additional authentication information and run it through an encryption algorithm that scrambles or obfuscates the additional authentication information automatically in response to receiving the additional authentication information or in response to receiving an input from the user (e.g., the selection of an “Enter” or other confirmation icon displayed along with the prompt for additional authentication information) that is intended to cause thecustomer device102 to transmit the additional authentication information. In some embodiments, the encryption algorithm has an associated decryption algorithm that is known or stored via the cardissuer computing system108. In this way, the encryption algorithm can obfuscate the additional authentication information during the transmission of the additional authentication information and the cardissuer computing system108 can decrypt the transmitted data in order to recover, use, or determine the additional authentication information.
• At process914, thecustomer device102 transmits the additional authentication information to the cardissuer computing system108, which may then use the additional authentication information to authenticate the user atprocess924. For example, thecustomer device102 may automatically transmit the additional authentication information in response to receiving from the user the additional authentication information. In some embodiments, thecustomer device102 may transmit the additional authentication information (e.g., or the encrypted additional authentication information) in response to receiving an input from the user (e.g., the selection of an “Enter” or other confirmation icon displayed along with the prompt for additional authentication information) that is intended to cause thecustomer device102 to transmit the additional authentication information.
• The additional authentication information may then be decrypted and used to authenticate the customer atprocess924. In this way, the card issuer computing system provides an additional layer of security to ensure that only the users (e.g., via the customer device) that are authorized to access particular information of the account. If the additional authentication information is sufficient, the cardissuer computing system108 has authenticated the customer and proceeds to process926. If the additional authentication information, is not sufficient the cardissuer computing system108 may cause the customer device102 (e.g., via sending a signal to the customer device102) to re-prompt the user and re-enterprocess910.
• In some embodiments, the cardissuer computing system108 may count the number times that process910 has been repeated without success and automatically, in response to the count exceeding a pre-determined number, either disable the account, send an electronic notification (e.g., email, text, or instant message) to an employee of the card issuer, send an electronic notification (e.g., email, text, or instant message) to the user, and refuse to allow thecustomer device102 to have access to the account until thecustomer device102 has been verified. For example, the cardissuer computing system108 may refuse to allow thecustomer device102 to have access to the account (e.g., not authenticate the customer) based on information received that identifies the customer device102 (e.g., internet protocol IP address, MAC identifier, or other electronic identifier). In some embodiments, thecustomer device102 may refuse to allow thecustomer device102 to have access to the account for a pre-determined amount of time (e.g., 3 hours, 1 day, etc.). Or, other measures may be implemented until thecustomer device102 can be verified by either an employee of the card issuer or the user associated with the transaction card. For example, the electronic notification sent to the user may prompt the user to call an employee (e.g., a customer service line) of the card issuer in order to verify thecustomer device102 or may include a selectable icon therein that the user may select in order to indicate to the cardissuer computing system108 that thecustomer device102 is indeed a verifiedcustomer device102 that the user has access to or that thecustomer device102 is fraudulent and the user had not tried to access the account. In response to receiving and indication that thecustomer device102 is fraudulent, the cardissuer computing system108 may, in response, deactivate the transaction card and add any electronic identification information of the customer device102 (e.g., IP address or identifying protocol information) to a list within the database that can be used to cross-reference future requests and automatically reject the request based on a determination that the request is coming from afraudulent customer device102.
• The additional authentication information may be determined to be sufficient if the card issuer computing system receives data that corresponds to one or more pieces of data that are stored within a customer profile within a database on the cardissuer computing system108. For example, as discussed above, the customer profile of a user associated with the transaction card may be stored within a database of the cardissuer computing system108. The customer profile may be identified and retrieved or accessed based on the identity of a user associated with thetransaction card104 identified at least atprocess922. The customer profile may include one or multiple pieces of information that can be cross-referenced to the additional authentication information in order to authenticate thecustomer device102. The cardissuer computing system108 may take the received additional authentication information and cross-reference the received additional authentication information within a particular field within the customer profile and if they match, then proceed to process926, and if they don't match, determine that the additional authentication information is not sufficient. In some embodiments, the particular field within the customer profile that is cross-referenced with the additional authentication information is determined by the cardissuer computing system108 based on the particular type of additional authentication information (e.g., PIN, biometric, or other identifying information) that was prompted for atprocess910.
• Atprocess926, the cardissuer computing system108 allows the customer access to at least a portion of the online account associated within the transaction card. In some embodiments, the cardissuer computing system108 may also allow the user to change some fields of information associated with the online account. For example, the cardissuer computing system108 may allow the customer to update a password associated with the online account via thecustomer device102 at process926 (e.g., in response to the user andcustomer device102 being authorized at least partially from the contactless communication). In another example, the cardissuer computing system108 may allow the customer to transfer money into or out of the online account via thecustomer device102 atprocess926. In other words, atprocess926, the cardissuer computing system108 has authenticated the customer device102 (e.g., at least partially in response to the contactless communication) and allows thecustomer device102 to access, change, and/or display at least a portion of the account associated with the identified customer (e.g., and owner/user of the transaction card).Process926 may have a set duration. That is, the cardissuer computing system108 may only allow customer access via thecustomer device102 for a pre-determined amount of time (e.g., 30 minutes, 1 hour, etc.). In some embodiments, the cardissuer computing system108 may disable customer access (e.g., end process926) after a pre-determined amount of time (e.g., 10 minutes) of inactivity (e.g., a time period where the cardissuer computing system108 is not receiving any customer inputs via the customer device102).
• At process916, thecustomer device102 displays at least a portion of the online account information via graphical user interface. In some embodiments, thecustomer device102 receives a signal in response to the cardissuer computing system108 proceeding to process926 (e.g., in response to thecustomer device102 and being authenticated at least partially as a result of the contactless communication) that causes thecustomer device102 to display a home page of the online customer account. The user may interact with one or multiple selectable icons presented via the graphical user interface on the customer device102 (e.g., presented in response to receiving signals from the card issuer computing system108) in order to update account information, update a travel itinerary, move funds from one account to another, pay a loan payment, access the account number and routing number, access a peer-to-peer payment system, etc. In some embodiments, the cardissuer computing system108 may only provide access to particular information. For example, in an embodiment where a user of thecustomer device102 is using the transaction card in order to authenticate he/she to reset or change online account credentials (e.g., a username or password) the cardissuer computing system108 may send a signal to thecustomer device102 that causes thecustomer device102 to display selectable icons or fields (e.g., to enter in a new password) that allow the customer to reset or change the online credential. That is, in some embodiments, the type of information and amount of information that is displayed at process916 may depend on what the initial request to the cardissuer computing system108 was for, rules stored in the customer profile about what may be displayed or accessed, or policies of the card issuer.
• Referring now toFIG.10, a flow diagram of amethod1000 of a communication between a customer device and a transaction card is shown, according to an example embodiment. That is,FIG.10 is one example of how a customer device may communicate with a transaction card via contactless communication, in some embodiments, the process may be different, have additional steps, or the particular processes may be performed by the transaction card and/or the customer device.
• Atprocess1002, thecustomer device102 transmits a command requesting identity information to atransaction card104 via a contactless communication. Thecustomer device102 generates a command that is configured to cause thetransaction card104 to respond by transmitting identification information to thecustomer device102. Thecustomer device102 may transmit the card via activating an NFC tag reader on thecustomer device102 and positioning thecustomer device102 adjacent to a passive NFC tag located on thetransaction card104. Electromagnetic induction generated by the NFC tag reader may create a current in the passive NFC tag to power circuitry of the NFC tag. After the circuitry of the NFC tag is powered up, the NFC may sync with the NFC card reader and data may be exchanged therebetween. Thecustomer device102 transmits the command via the wireless (e.g., contactless) communication between the NFC reader and the NFC tag. In some embodiments, the command includes a request for a particular type of information such as information indicative of the user associated with the card, payment account information, account information, or a uniform resource locator. In some embodiments, the passive NFC tag includes information indicative of account (e.g., payment account) information and information indicative of an identity of the user. In some embodiments, the information indicative of account (e.g., payment account) information is in the form of a first cryptographic key and information indicative of an identity of the user is in the form of a second cryptographic key. In some embodiments, the passive NFC tag includes information indicative of an identity of the user in the form of a cryptographic key, a cryptographic algorithm, or a digital certificate. In some embodiments, a first command from a NFC reader may cause the transaction card to begin a transaction process via causing thetransaction card104 to send the information indicative of the payment account and a second command from a NFC reader may cause the transaction card to send the information indicative of the identity of a user associated with the transaction card. In this way, in some embodiments, the customer device102 (and/or the card issuer computing system108) does not have to begin a complicated transaction sequence and/or involve a third party computing system (e.g., Discover®, Visa®, Mastercard®, American Express®, etc.) in order to obtain the identity information. Rather, the command from thecustomer device102 sent to thetransaction card104 may simply request for identity information and be independent of the interactions that may occur when thetransaction card104 is used for payments. However, in some embodiments, the information indicative of account information may be used for both transactions and to identify the user associated with thetransaction card104.
• For example, in some embodiments, the command may include a random bit string (e.g., a random number) and a request. In some embodiments, the request identifies a particular block of memory within the NFC tag that thecustomer device102 would like to receive. In some embodiments, the request identifies the information type requested (e.g., information indicative of the identity of the user associated with the transaction card, payment information, etc.) and the passive NFC tag determines what information (and whether to encrypt the information) to transmit to thecustomer device102 based on the command. In some embodiments, thecustomer device102 generates the random number via a random number generator and includes the random number in the command. In some embodiments, the command may be in a NFC data exchange format (NDEF).
• Atprocess1004, thetransaction card104 receives the command. Thetransaction card104 receives the command via the contactless communication. For example, in some embodiments, an integrated circuit located on thetransaction card104 may receive the command via an antenna. In some embodiments, the antenna is the same antenna in which thecustomer device102 is supplying power via electromagnetic inductions to the integrated circuit located on the transaction card.
• The integrated circuit may receive the command and determine how to respond. For example, the integrated circuit may determine the type of information that is being requested based on the request and may determine a particular algorithm to use based on the type of information that is being requested. Further, the integrated circuit may also determine the format that the data, cryptographic key, or digital certificate is to be sent back to thecustomer device102. That is, in some embodiments, the integrated circuit may determine, based on the request, that the data to be sent back to the customer device is to be embedded within a uniform resource locator (URL). In some embodiments, the URL that is to have data or information embedded therein is stored on the NFC tag. In some embodiments, the integrated circuit may default to sending information (or determine to send information based on the request) back to thecustomer device102 in NDEF format (e.g., as a NDEF message or NDEF record).
• Atprocess1006, the transaction card encrypts the identity information. For example, the integrated circuit on the transaction card may implement an encryption algorithm that uses a key or data string on thetransaction card104, the random bit string (e.g., random number), and/or a count of how many times the encryption algorithm has been performed by thetransaction card104 and outputs a single bit sequence. The bit sequence is indicative of the encrypted identification information (e.g., encrypted cryptographic key) of a user associated with the card. In some embodiments, the encryption algorithm may have more or fewer inputs. The count of how many times the encryption algorithm has been performed by thetransaction card104 may be held in a register (e.g., a memory register) of the integrated circuit and be incremented via the execution of the encryption algorithm. In some embodiments, the encryption algorithm time stamps the bit sequence that is generated with the time that the encryption algorithm is being ran. The encryption algorithm may be programmed onto thetransaction card104 at the time of manufacture and a cardissuer computing system108 may have a corresponding decryption algorithm stored within a database. In some embodiments, the encryption algorithm is configured to perform either a symmetric encryption or an asymmetric encryption.
• Atprocess1008, the transaction card transmits the encrypted identity information. For example, the transaction card104 (e.g., via the integrated circuit and the antenna of the passive NFC tag) transmits the requested information to thecustomer device102. In some embodiments, thetransaction card104 may send an error message or other default message if the command was not received, was partially received, was unreadable, or undeterminable by the transaction card. In some embodiments, thetransaction card104 transmits the bit sequence that is indicative of the encrypted identification information of a user associated with the card, count number of how many times the encryption algorithm has been ran, and/or any other information that was generated and/or used by thetransaction card104 in generating the encrypted identification information.
• In some embodiments, thetransaction card104 may first package the requested information. For example, in some embodiments, thetransaction card104 may, by default or based on the request (e.g., a particular request or command that asks for a URL and identity information), package or embed the information into a URL that is stored on thetransaction card104. In some embodiments, the transaction card104 (e.g., the integrated circuit having executable instructions) may cause the information (e.g., bit sequence, count, random number) to be embedded within a query string of a URL that is stored with thetransaction card104. The URL may then be configured to cause the information to be sent via the internet to a cardissuer computing system108 or other computing system automatically in response to acustomer device102 executing or navigating to the URL. For example, the URL stored on thetransaction card104 may contain a domain name associated with the cardissuer computing system108 and when the URL is executed or entered into a browser, the URL may cause the browser to navigate the domain of the cardissuer computing system108 and pass the identity information associated with the transaction card via the query string. In this way, the identity information from thetransaction card104 may be automatically passed to the cardissuer computing system108 without particular interventions on the data from thecustomer device102. Thus, thetransaction card104 may pass the identity information via anycustomer device102 that has web or network access and thecustomer device102 and thecustomer device102 may not be required to have specialized code or applications designed to process and/or transmit the encrypted data (e.g., the encrypted cryptographic key) to the cardissuer computing system108. In this way, all customer devices that have a contactless chip may be used by a user to securely access their account via a contactless tap.
• Atprocess1010, the customer devices receives the encrypted identity information. Atprocess1012, the customer device responds to the encrypted identity information. In some embodiments, thecustomer device102 may receive the encrypted identity information from thetransaction card104 and perform an algorithm on the received information intended to further obfuscate or encrypt the identity information before transmitting. For example, in some embodiments, thecustomer device102 may receive the encrypted identity information and package the encrypted identity information along with information that identifies the customer device102 (e.g., a name of the customer device, MAC ID number, or other number and protocol). Further, in some embodiments, thecustomer device102 may package the encrypted identity information, the random number (e.g., the seed) that was sent within the command, and time stamp the package.
• Further, the package also may allow that the cardissuer computing system108 to redundantly check the authorizations of thecustomer device102 to have access to at least a portion of the online customer account. For example, the cardissuer computing system108 may determine an identity of the user associated with the account based on a decryption of the identity information, cross reference the identity information of the phone (e.g., packaged within the package or otherwise received by the card issuer computing system108) with information within the user's customer profile to check that thecustomer device102 is or has been associated with the customer, and/or compare the information received (e.g., time stamps, the random number, or encrypted information) to a database of previously received information to check whether the information received is merely a duplicate of previously received information. In this way, via creating the package, thecustomer device102 may allow for enhanced, redundant security within the computing system.
• Atprocess1014, thecustomer device102 transmits the encrypted identity information to a card issuer computing system. For example, in some embodiments, thecustomer device102 transmits the package (e.g., package including the information received from the transaction card, information regarding the identity of thecustomer device102, time stamps, information from the transaction card that has been encrypted via an encryption algorithm executed on thecustomer device102, or other data, etc.) to the cardissuer computing system108. The cardissuer computing system108 may then use the package to authenticate a user of thecustomer device102.
• In another example, thecustomer device102 may automatically transmit the information received from thetransaction card104 directly to the cardissuer computing system108. That is, as discussed above and herein, thecustomer device102 may receive a URL from thetransaction card104 that contains the identity information of a user associated with the card embedded thereon. Thecustomer device102 may automatically recognize that thecustomer device102 has received a URL and automatically open and/or navigate to the URL, which may cause the information indicative of the identity of the user (e.g., the cryptographic key, and random number) to be passed directly to the cardissuer computing system108. In some embodiments, thecustomer device102 may be running a mobile application or already be navigated to a URL that is associated with the cardissuer computing system108 which contain code that when executed by thecustomer device102, cause thecustomer device102 to send the command inprocess1002 and automatically pass any received information directly to the cardissuer computing system108 via the network. In this way, thecustomer device102 may act as a conduit between thetransaction card104 and the cardissuer computing system108. Thecustomer device102 may be utilized as a conduit in some embodiments without increasing security risks because the encrypted identity information (e.g., the cryptographic key and cryptographic algorithm) allows the information to be passed over the network with lesser security concerns. Alternatively or additionally, in some embodiments, thecustomer device102 may still execute an extra step of packaging and/or encrypting information for an added layer of security. However, because the information indicative of the identity of the user associated with the card may be different than the payment account information on the transaction card, any potential information that is intercepted by a fraudulent actor may not be useful (e.g., because the intercepted information cannot be used for transactions). Additionally, because thetransaction card104 may automatically perform an encryption algorithm (e.g., a cryptographic algorithm) in response to receiving the command inprocess1004, any potential information that is intercepted by a fraudulent actor may not be used to identify the user associated with the transaction card or allow the fraudulent actor to access an online account of the user.
• Referring now toFIG.11, an exemplary image of a customer device prompting a user for additional authentication information via agraphical user interface1100 is shown, according to an example embodiment. For example,FIG.11 depicts an example of acustomer device102 atprocess910 described in reference toFIG.9. Thegraphical user interface1100 may be presented on a display of thecustomer device102 in response to receiving instructions to display or redirect a mobile page1150 (e.g., a browser page or a mobile page being displayed within an application associated with the card issuer downloaded onto the customer device) that prompts the user for additional authentication information. The prompt for additional authentication information may includetext1152 that is intended to instruct the user and a field that allows the user to enter information1153 (e.g., via a keyboard, touch screen, or other input/output device).
• For example, in some embodiments, thetext1152 instructs the user to enter in a personal identification number (PIN). In some embodiments, thetext1152 instructs the user to enter in the last four digits of the social security number or other personally identifying information. The user may then select the field that allows the user to enterinformation1153 into thecustomer device102. In some embodiments, thecustomer device102 automatically accepts and begins to process the input (e.g., the PIN) as soon as a particular number of input digits are received or entered (e.g., in response to 4 numbers being entered). In some embodiments, thecustomer device102 accepts and begins the process the input (e.g., the PIN) in response to a selection of aselectable icon1154 by the user via thegraphical user interface1100. For example, theselectable icon1154 may be intended to indicate to thecustomer device102 when the user is done entering in the information he/she was prompted for. Theselectable icon1154 may also include text (e.g., “Enter,” “Okay,” “Go,” etc.) that indicates to the user that the button is to be pressed or selected after the input into thefield1153 is complete.
• Referring now toFIG.12, an exemplary image of a mobile device prompting a user for additional authentication information via agraphical user interface1200 is shown, according to an example embodiment. For example,FIG.12 depicts an example of acustomer device102 atprocess910 described in reference toFIG.9. Thegraphical user interface1200 may be presented on a display of thecustomer device102 in response to receiving instructions to display or redirect a mobile page1250 (e.g., a browser page or a mobile page being displayed within an application associated with the card issuer downloaded onto the customer device). Thegraphical user interface1200 includes a prompt for additional authentication information, which includestext1252 that instructs the user to enter the user's biometric information into thecustomer device102 via an input/output device such as afingerprint reader1253 or acamera1254, and a cancelbutton1251. In some embodiments, the input/output device may include more or fewer varieties, types, or forms.
• For example, in some embodiments, thetext1252 instructs the user to scan his/her fingerprint on thefingerprint reader1253. In some embodiments, thetext1252 instructs the user to look into thecamera1254 for facial recognition. The user may respond to thetext1252 by placing his/or finger onto thefingerprint reader1253 or looking into thecamera1254. In some embodiments, thecustomer device102 automatically responds to the input from the user and determines the identity of the user or packages the data to be sent to the cardissuer computing system108 for authentication of the identity of the user andcustomer device102. For example, in some embodiments, thecustomer device102 may receive a fingerprint as an input and automatically verify that the user of the phone is the owner of the phone (e.g., or has approved access to the phone) and thecustomer device102 may transmit a signal to the cardissuer computing system108 that indicates that the user has been verified to be the one using thecustomer device102. The cardissuer computing system108 may authenticate a customer based on the known identity of the customer device, signal that has verified the user of the customer device102 (e.g., via the biometric fingerprint or facial recognition verification), and the encrypted cryptographic key. In this way, the authentication process for the cardissuer computing system108 includes multiple redundancies that increases the probability that only customers with the authority to access particular accounts may access the accounts.
• In some embodiments, thegraphical user interface1200 may include aselectable icon1235 that allows for a user to select theselectable icon1235 in order to change the particular form or type of additional authentication information that is being prompted for (e.g., “Other Options”). For example, a user of thecustomer device102 may select theselectable icon1235 and thecustomer device102 may navigate to or present a list of options of types or forms of additional authentication information that the user may enter in order to be authenticated by the cardissuer computing system108. The list of options may include options for the user to enter in a PIN (e.g., and thereby be redirected to a graphical user interface similar to thegraphical user interface1100 ofFIG.11), answer security questions, enter in the last four digits of a social security number of a user associated with the account, enter biometric information (e.g., fingerprint or facial recognition), etc. In this way, thegraphical user interface1200 allows for a customer to provide additional authentication information even when a PIN number may have been forgotten, thefingerprint reader1253 may be broken or not working, thecamera1254 doesn't work, or other technical issues prevent the user from entering in the prompted for additional authentication information.
• The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.
• It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
• As used herein, the term “circuit” or “computing system” may include hardware structured to execute the associated functions described herein. In some embodiments, each respective “circuit” or “computing system” may include machine-readable media for configuring the hardware to execute the associated functions described herein. The “circuit” or “computing system” may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” or “computing system” may include any type of component for accomplishing or facilitating achievement of the associated operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).
• The “circuit” or “computing system” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. The one or more processors may be constructed in a manner sufficient to perform at least the associated operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” or “computing system” as described herein may include components that are distributed across one or more locations.
• An exemplary system for implementing the overall system or portions of the embodiments might include a computer(s), including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND,3D NAND, NOR,3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.
• It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
• The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.

Claims (20)

What is claimed is:

1. A mobile device comprising:

a wireless chip structured to allow short-range wireless communications;

a display;

a processor; and

a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising:

based on a first short-range wireless communication between the mobile device and a contactless card, receiving a customer-specific uniform resource locator (URL) from the contactless card via the wireless chip;

in response to receiving the customer-specific URL, automatically navigating to a website associated with the customer-specific URL;

receiving authentication information and automatically populating one or more fields on a graphical user interface (GUI) of the display with the received authentication information;

transmitting the received authentication information to a separate computing system;

based on a verification of the authentication information, displaying, by the display, an indication of activation of the contactless card;

receiving and accepting a prompt to register the mobile device with the activated contactless card; and

based on at least a second short range wireless communication between the registered mobile device and the contactless card, providing a second GUI via the display, the second GUI including an online login portal for accessing an account that is associated with the contactless card.

2. The mobile device ofclaim 1, the memory storing instructions that, when executed by the processor, further cause the processor to perform operations comprising:

encrypting the received authentication information before transmitting the received authentication information to the separate computing system.

3. The mobile device ofclaim 1, wherein the authentication information is one of a personal identification number (PIN) or biometric information.

4. The mobile device ofclaim 1, wherein the customer-specific URL includes a unique value specific to a client that is appended to a general URL.

5. The mobile device ofclaim 4, wherein navigating to the website associated with the customer-specific URL causes transmission of the unique value specific to the client to the separate computing system.

6. The mobile device ofclaim 1, wherein at least one of the first or second short-range wireless communications is near-field communication (NFC).

7. The mobile device ofclaim 6, wherein the mobile device provides power to the contactless card to enable the NFC transmission of the customer-specific URL from the contactless card to the mobile device.

8. A system comprising:

a processor; and

a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising:

generating a customer-specific uniform resource locator (URL) for a contactless card that is embedded on the contactless card;

storing, in a database, information regarding the customer, the information including data specific to the customer;

based on a first short range contactless communication between a mobile device of the customer and the contactless card, receiving the data specific to the customer;

accessing, from the database, the information regarding the customer based on cross-referencing the data specific to the customer with information stored in the database;

providing a graphical user interface (GUI) to the mobile device, the GUI including a prompt for authentication information;

receiving authentication information from the mobile device;

verifying the authentication information;

in response to verifying the authentication information, activating the contactless card for a subsequent use;

in response to activating the contactless card, receiving an indication from the mobile device to register the mobile device with the activated contactless card by storing identifying information regarding the mobile device in the database; and

based on at least a second short range contactless communication between the registered mobile device and the contactless card, providing a second GUI to the registered mobile device, the second GUI including an online login portal for accessing an account that is associated with the contactless card.

9. The system ofclaim 8, the memory storing instructions that, when executed by the processor, further cause the processor to perform operations comprising:

in response to activating the contactless card, providing a confirmation of activation of the contactless card for display on the mobile device.

10. The system ofclaim 8, the memory storing instructions that, when executed by the processor, further cause the processor to perform operations comprising:

in response to activating the contactless card, deactivating the customer-specific URL.

11. The system ofclaim 8, wherein the identifying information regarding the mobile device is used to automatically grant access to the account associated with the contactless card.

12. The system ofclaim 8, wherein the data specific to the customer excludes payment account information.

13. The system ofclaim 8, wherein the authentication information is one of a personal identification number (PIN) or biometric information.

14. The system ofclaim 8, wherein at least one of the first or second short range wireless communications is a near-field communication tap.

15. The system ofclaim 14, wherein the data specific to the customer is one of a unique numeric or a unique alphanumeric value.

16. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors cause operations comprising:

generating a customer-specific uniform resource locator (URL) for a contactless card;

storing, in a database, information regarding the customer, the information including data specific to the customer;

based on a short range contactless communication between a mobile device of the customer and the contactless card, receiving the data specific to the customer;

accessing, from the database, the information regarding the customer based on cross-referencing the data specific to the customer with information stored in the database;

providing a graphical user interface (GUI) to the mobile device, the GUI including a prompt for authentication information;

receiving authentication information from the mobile device;

verifying the authentication information;

in response to verifying the authentication information, activating the contactless card for a subsequent transaction;

in response to activating the contactless card, receiving an indication from the mobile device to register the mobile device with the activated contactless card by storing identifying information regarding the mobile device in the database; and

based on at least a second short range contactless communication between the registered mobile device and the contactless card, providing a second GUI to the registered mobile device, the second GUI including an online login portal for accessing an account that is associated with the contactless card.

17. The non-transitory computer-readable medium ofclaim 16, wherein the data specific to the customer includes information indicative of an identity of the customer.

18. The non-transitory computer-readable medium ofclaim 16, wherein the data specific to the customer is one of a numeric or an alphanumeric unique value.

19. The non-transitory computer-readable medium ofclaim 16, further comprising instructions, that when executed by the one or more processors cause operations comprising:

providing a notification to the mobile device that the contactless card has been activated.

20. The non-transitory computer-readable medium ofclaim 16, wherein verifying the authentication information is based on the received authentication information matching information associated with the customer stored in the database.

Images