Systems and techniques for authenticated website-based checkout using uniform resource locators

Abstract

A system, computer readable medium, and method are disclosed for receiving notification from a website that an authentication request is received at a financial institution's system within a predetermined time period. A prompt is displayed on a mobile device corresponding to a user's verification identifier, the prompt including a request to confirm the pending transaction via near field communication with the contactless card. In response to a near field communication interaction responsive to the prompt, an encrypted authentication payload may be received at an authentication web address as confirmation of the pending transaction. The payload is decrypted and parameters are obtained from the decrypted authentication payload. The user may be authenticated as the owner of the contactless card using one or more of the parameters. In response, the pending transaction is completed by transmitting user identification information to the website.

Description

[Technical field]

[0001] This application claims priority to U.S. patent application Ser. No. 17 / 538,351, entitled "System and Technique for Authenticated Website-Based Checkout Using Uniform Resource Locators," filed on November 30, 2021, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] In a customer-facing transaction, such as at a brick-and-mortar store, the customer presents a chip-enabled credit card to a chip reader or a contactless credit card in a "tap" exchange, either of which provides encrypted information that is accepted as authenticating that the customer is the person associated with the credit card account.

[0003] In contrast, online transactions typically do not provide the user with an opportunity to provide the merchant with encrypted information obtained from a chip-enabled card reader or a "tap" exchange in a contactless reader. During online transactions, merchants may not rigorously screen the information provided by consumers because they presume, or must presume, that the information provided by the consumer, such as an account number or address, can be authenticated by a financial institution.

[0004] Furthermore, if a consumer is the target of identity theft, they may not realize that fraud is occurring until they receive their account statement, and therefore have no protection against fraudulent transactions.

[0005] It is advantageous for consumers and online merchants to have confidence that transactions between them are secure, and for merchants to be able to authenticate the identity of consumers, thus reducing fraud and improving the security of online transactions. Summary of the Invention

[0006] In one aspect, a method is provided that includes receiving, at a financial institution system, a notification from a website that a financial transaction authentication request from a user is received at the financial institution system within a predetermined time period from receipt of the notification. The notification includes a verification identifier of the user entered during a transaction session with the website. A prompt corresponding to the verification identifier of the user may be generated for display on the mobile device. The presented prompt may include a request for confirmation of the pending transaction via near field communication with a contactless card associated with the financial institution. In response to a near field communication interaction responsive to display of the presented prompt, a financial transaction authentication request including an encrypted authentication payload may be received at an authentication web address of the financial institution system as confirmation of the pending transaction. A portion of the encrypted authentication payload is retained on the contactless card. The encrypted authentication payload may be decrypted and a plurality of parameters may be obtained from the decrypted authentication payload. The user may be authenticated as an owner of the contactless card using one or more of the plurality of parameters. Upon authenticating the user as an owner of the contactless card, sending an identification of the user to the website enables completion of the pending transaction.

[0007] In another aspect, a non-transitory computer readable storage medium is provided. The computer readable storage medium includes instructions that, when executed by a computer, cause a computer at a financial institution system to receive a notification from a website that an authentication request from a user is received at the financial institution system within a predetermined period of time after receiving the notification. The notification includes a verification identifier of the user entered during a transaction session with the website. The instructions can cause the computer to display a prompt on the mobile device corresponding to the verification identifier of the user. The presented prompt can include a request for confirmation of the pending transaction via near field communication between the user and a contactless card associated with the financial institution. In response to a near field communication interaction responsive to the display of the presented prompt, a financial transaction authentication request including an encrypted authentication payload can be received at an authentication web address of the financial institution system as confirmation of the pending transaction. A portion of the encrypted authentication payload is retained on the contactless card. The encrypted authentication payload can be decrypted to obtain a plurality of parameters from the decrypted authentication payload. A user can be authenticated as an owner of the contactless card using one or more of the plurality of parameters. Completion of a pending transaction may be enabled by transmitting user identification information to the website in response to the user authenticating that he or she is the owner of the contactless card.

[0008] In one aspect, a computing device includes a processor circuit and a memory. The memory stores instructions operable, when executed by the processor, for the computing device to receive a notification that an authentication request from a user is received within a predetermined period of time after receiving the notification. The notification includes a verification identifier of the user entered during a transaction session with the website. The computing device may cause a prompt corresponding to the verification identifier of the user to be displayed on the mobile device. The presented prompt includes a request for confirmation of the pending transaction via near field communication with a contactless card associated with the financial institution. In response to a near field communication interaction in response to the presentation of the prompt, a financial transaction authentication request including an encrypted authentication payload may be received at an authentication web address of the financial institution system as confirmation of the pending transaction. A portion of the encrypted authentication payload is retained on the contactless card. The encrypted authentication payload may be decrypted and a plurality of parameters may be obtained from the decrypted authentication payload. The user may be authenticated as an owner of the contactless card using one or more of the plurality of parameters. Upon authenticating the user as an owner of the contactless card, sending an identification of the user to the website enables completion of the pending transaction.

[0009] Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of a system implementation of the disclosed subject matter. [Diagram 2] FIG. 2 illustrates an exemplary process according to an embodiment of the disclosed subject matter. [Diagram 3] FIG. 3 illustrates a functional block diagram of a system suitable for implementing the described techniques of the disclosed subject matter. [Figure 4] FIG. 4 shows an example of a contactless card that can be used in the examples described herein. [Diagram 5]FIG. 5 illustrates additional features of the example contactless card of FIG. [Figure 6] Figure 6 shows an example of a computing architecture suitable for implementing the example of Figures 1-5. [Figure 7] 1-5 show examples of mobile devices that can be used to implement the techniques and processes described with reference to the examples. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0013] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. However, it will be apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0014] The following describes improved transaction systems and techniques that enable online merchants and consumers to verify with a high degree of certainty that the person, or in the case of a business, entity a consumer claims to be, is in fact that person or entity.

[0015] 1 illustrates an example of a system implementation of the disclosed subject matter. The system 100 may include a financial institution system 118, a website 108, a mobile website 104, a mobile device 102, a contactless card 110, and a data network 106.

[0016] The data network 106 may be a network that allows various devices and systems to communicate with each other, such as the Internet, a wide area network, a local area network, a metropolitan area network, a cellular network, or a combination of networks.

[0017] The website 108 and the mobile website 104 may be services running on a server or cloud platform offering services or products from a service provider or merchant.

[0018] The financial institution system 118 may be provided by an organization such as a bank, a mortgage company, an investment company, a credit card issuer, etc., hereinafter referred to as a "financial institution." The financial institution may have a business relationship with a large number of merchants. The number of merchants may include merchants that do business through online businesses that sell goods and / or services through online transactions enabled by a website, such as the website 108 or the mobile website 104. Additionally or alternatively, the financial institution may have a business relationship with a large number of consumers that interact with the financial institution system 118 through a mobile device, such as the mobile device 102. As part of the consumer relationship, the financial institution may provide the consumer with a contactless card 110 after conducting a sufficient screening (to verify identity, address, income, household members, account information, etc.).

[0019] A contactless card 110, described in a later embodiment, may be operable to provide encrypted authentication information that is authenticable by a financial institution system 118. The contactless card 110 may include a near field communication (NFC) device 112. The NFC device 112 may be operable to communicate with an NFC device (not shown in this example) in the mobile device 102.

[0020] The mobile device 102 may be operable to communicate with the financial institution system 118 via the communication link 114. The mobile device 102 may be operable to provide information obtained from the contactless card 110 to the financial institution system 118 via an instance of a user application 132. The user application 132 may be an application that facilitates obtaining encrypted authentication information from the contactless card 110.

[0021] The financial institution system 118 may include a number of systems, memories, modules, and components, such as a user data storage 120, a financial institution processor 122, an authentication system 124, and a communication interface 126.

[0022] The communication interface 126 may be operable to facilitate communication between the financial institution system 118 and the mobile device 102, the mobile website 104, and / or the website 108 over the data network 106. The communication link 128 connects the mobile website 104 to the data network 106. Similarly, the communication interface 126 may be operable to receive information from each of the mobile device 102, the mobile website 104, and the website 108 transmitted over the data network 106. The communication interface 126 may communicate over the data network 106 using known communication protocols.

[0023] The user data storage 120 may securely hold information about the user that the authentication system 124 uses to authenticate the user. For example, the information held about the user may include personally identifiable information (PII) such as the user's name, home address, marital information, phone number, bank loan balance, account type, type of vehicle secured by the loan (e.g., Chevrolet, Tahoe), mobile phone identifiers (e.g., International Mobile Equipment Identity (IMEI) number, etc.), passwords, permanent account numbers, past virtual account numbers, transaction counts, etc.

[0024] The financial institution processor 122 may be operable to receive encrypted information, also referred to as the encrypted authentication payload, of the contactless card 110 from the communication interface 126. The financial institution processor 122 may be operable to process the encrypted information and forward the encrypted authentication information to the authentication system 124.

[0025] The authentication system 124 may be a component (e.g., a processor, software, or a combination of both) that decrypts and / or authenticates (if necessary) information provided by a user, such as an identifier provided by the user to the website 108, authentication information from the contactless card 110, etc. For example, the authentication system 124 may be a component that utilizes a decryption algorithm to decrypt encrypted authentication information and match the decrypted authentication information with user information retrieved from the user data storage 120. Optionally, the authentication system 124 may interface with a third-party authentication system 130, which may provide some or all of the same functionality as the authentication system 124.

[0026] The customer enters an identifier (such as a telephone identifier, email address, or permanent account number (PAN)) into a field on a web page displayed by the web browser. The user may enter the first five digits of the PAN, which provides the mobile website 104 with enough information to identify the user's financial institution. The identifier may include other additional information indicative of the website 108 and / or mobile website 104, such as special keywords, an account number or name held in association with the website 108 or mobile website 104, or the like. Alternatively, the user may select a financial institution displayed on the web page of the website 108 or mobile website 104 for use in the authentication process.

[0027] The website 108 may be operable to identify the user as a user or bank identification number in a centralized database. In a detailed example, the website 108 may have relationships with various financial institutions. When the website 108 receives the user's identification information, such as a phone identifier or email address, the website 108 may broadcast the information to all of the various financial institutions with which the website 108 has relationships. The first financial institution to return an acknowledgment is the financial institution with which the website 108 continues the transaction session with the financial institution that responded first. The mobile website 104 may be operable to be displayed and operated on a mobile device, such as a smartphone, laptop, or tablet device, and function similarly to the website 108.

[0028] The above-described system 100 may be operable to provide secure authentication of users and streamlined secure transactions, as outlined in the following example process.

[0029] The customer may be asked to tap a contactless card to the phone to read authentication information in the background that the financial institution can use to authenticate the user. In some examples, the disclosure refers to "tapping" the contactless card. However, it is understood that the invention is not limited to tapping and includes other gestures (e.g., waving the card or making other movements). The authentication information read by the phone may be a Uniform Resource Locator (URL) associated with the financial institution. The URL may include an encrypted payload that is authenticated by the authentication system 124 of the financial institution system 118. Alternatively, the authentication of the user may also serve as an authorization for the transaction, in which case account information, etc. required by the merchant to complete the transaction on the website 108 may be provided by the financial institution, and a notification that the transaction has been completed may be presented by the user.

[0030] The financial institution sends an authorization response to the merchant along with the remaining personally identifiable information (PII) data and possibly a Virtual Card Number (VCN), which is a 15 or 16 digit number like a credit card number, but where no physical credit card exists.

[0031] Essentially, the user simply provides their identifier (email address or phone number) and taps the contactless card 110 to the mobile device 102, and once authenticated, the information to complete the transaction (e.g. personal data, most frequently used shipping addresses, etc.) can be provided to the merchant.

[0032] A request to tap the card to the phone may launch a web browser on the portable device displaying the mobile website 104 or on the computing device displaying the website 108. For example, the financial institution may generate a request for a mobile phone tap alert (e.g., a prompt) via an in-app notification or SMS to initiate the authentication process described herein. When the website 108 generates a browsing session for a user transaction, the browsing session is assigned a browsing session identifier. Information entered during the browsing session, such as the username, shipping address, and product identifier identifying the product being purchased, is stored with reference to the browsing session identifier. The browsing session identifier allows the merchant to quickly resume the user's shopping experience. The authentication request to the financial institution may be provided with a link that includes the browsing session identifier. After authentication by the financial institution system, the user may resume the commerce session at the website 108 or the mobile website 104. For example, the authentication result may be delivered by the financial institution system 118's authentication system 124, etc., and may include the browsing session identifier and information about the user. The browsing session may be a secure or encrypted communications link. The information about the user provided by the authentication system 124 includes the user's name, the user's shipping address, the user's contact information, and the like.

[0033] As an example, an encrypted authentication payload is sent in a URL to a financial institution backend that expects a payload in the message for authentication. The encrypted authentication payload may include a version number (if there are multiple versions), a personal unique identifier, an application transaction counter, a one-time password, and a cipher used to verify the integrity of the message. For example, the URL message may be configured as "www.financialinstitutionname.com / fintech1?AUTHENTICATION MESSAGE". Upon receiving the URL message, the mobile device's OS may be operable to contact the financial institution at the URL and provide an AUTHENTICATION MESSAGE to the financial institution system 118. The financial institution system 118 associated with the URL may be operable to receive the authentication message, authenticate the user, determine if there is a pending transaction (e.g., based on a previous notification from the website 108), and provide the necessary information to complete the transaction. Alternatively, the URL message may be processed by the mobile device's OS and sent as a text message to the financial institution system, and the financial institution system may be operable to access the URL in the message. Information that can be used to complete the transaction may be provided to the merchant in an authorization response that includes additional PII data (that the user may not have already entered on the website 108) and a Virtual Card Number (VCN).

[0034] 2 illustrates an example process according to an embodiment of the disclosed subject matter. Process 200 may be performed by different components of system 100 as previously described.

[0035] Referring to FIG. 2, at block 202 of process 200, the financial institution system may receive a notification (or alert) from a website that an authentication request from a user, such as a user associated with mobile device 102 of FIG. 1, is received at the financial institution system within a predetermined time period from receipt of the notification. The notification may include a verification identifier (such as name, username, email address, mobile phone number, etc.) of the user entered during a transaction session with the website. For example, when entering information into the website during a transaction session, the user may enter payment card information or financial institution instructions to facilitate payment of the transaction in addition to the verification identifier. Based on the payment card or financial institution information, the website may be operable, for example, to send a notification message to the financial institution, alerting the financial institution to expect a financial transaction authentication request within a predetermined time frame or timeout period. The predetermined time frame or timeout period during which the financial institution is expected to receive the financial transaction authentication request may range, for example, from 30 seconds, 15 seconds, 20 seconds, 1 minute, 30 to 45 seconds, etc., from receipt of the notification.

[0036] In block 204, the financial institution system 118, when performing the process 200, may display a prompt on the mobile device corresponding to the user's verification identifier. Returning to FIG. 1, for example, the user application 132 executing on the mobile device 102 may communicate with the financial institution system 118. When received, the prompt includes a request for verification by near field communication with a contactless card associated with the financial institution. More specifically, the signal from the financial institution system 118 enters a message including instructions executable by the mobile device that cause the mobile device to initiate a background near field communication read of a contactless card associated with the user. The message is forwarded to the mobile device, and in response, the mobile device may display the prompt and initiate a background read of the contactless card by the near field communication device of the mobile device. For example, the forwarded message may include instructions to the mobile device to cause the mobile device to display the prompt and initiate a background read of the contactless card by the near field communication device of the mobile device. Alternatively, selectively based on the user's preferences, the user may interact with the prompt to initiate a background read of the contactless card. In some examples, the message including instructions may include a hyperlink to an authentication web address of the financial institution. The financial institution system 118 may forward the message to the mobile device corresponding to the user's verification identifier. In some examples, the message may be formatted as a Short Message Service message, a Multimedia Message Service message, or a financial institution in-application notification. The operating system of the mobile device may be operable to receive the message and execute the instructions, regardless of format.

[0037] In one example, the financial institution system 118 may receive a hyperlink / URL corresponding to a transaction session from the website 108 or mobile website 104 after a predetermined period of time has elapsed. After the predetermined period of time has elapsed, the transaction session may be deactivated by the website. The hyperlink / URL corresponding to the transaction session may include data that allows the website 108 or mobile website 104 to reactivate the transaction session without losing information already entered (e.g., shopping cart information, customer information, etc.). The financial institution system 118 may temporarily retain the hyperlink / URL in data storage in association with information related to the user (e.g., user data storage 120).

[0038] At block 206, process 200 receives the encrypted authentication payload at an authentication web address of the financial institution system in response to the near field communication interaction in response to the presentation of the prompt. The authentication web address may be a URL provided as part of a message obtained from the contactless card during the near field communication interaction. In this example, there may be two URLs: an authentication URL with a web address provided by the contactless card, and a transaction session URL. In some examples, a portion of the encrypted authentication payload is maintained on the contactless card.

[0039] A user application 132 executing on the mobile device 102 may communicate with the financial institution system 118. In response to instructions from the user application 132, the mobile device 102 may forward an encrypted financial transaction authentication request to the financial institution system 118 for authentication.

[0040] The financial transaction authorization request may include one or more Uniform Resource Locators (URLs), the first of which may be a URL generated by the website 108 that allows the user to resume the checkout flow if the user leaves the merchant website (such as when the financial transaction authorization request was submitted).

[0041] At block 208, as process 200 continues within financial institution system 118, a financial transaction authentication request may be received and forwarded to authentication system 124. Authentication system 124 may be operable to decrypt the encrypted authentication payload. For example, 124 may be operable to apply a decryption algorithm to decrypt the encrypted authentication payload.

[0042] In block 210, the process 200 obtains a number of parameters from the decrypted authentication payload. The parameters in the encrypted authentication payload include a version number, a unique identifier for the user, an application transaction counter, a one-time password, a cipher that can be used to verify the integrity of the message, etc. If the information or protocol version is updated and traditional contactless cards are still used, the version number may be required to select a different decryption algorithm, etc. The other parameters are described in more detail with reference to the examples below.

[0043] In block 212, the authentication system 124 may use one or more of the multiple parameters to authenticate the user as the owner of the contactless card. For example, the process 200 may use one or more of the multiple parameters to verify that information related to the user provided by the website is substantially identical to information of the user maintained by the financial institution system 118.

[0044] At block 214, process 200, in response to the user being authenticated as the contactless card owner, the financial institution system 118 enables completion of the transaction by transmitting the user identification information to the website 108 or mobile website 104. For example, the financial institution system 118 may transmit a hyperlink / URL of the transmission session to the website 108 or mobile website 104 along with the user identification information to enable the transaction session to be resumed at the website.

[0045] Additionally, if the authentication result confirms that the user information matches the encrypted authentication information, the shipping address and contact information that the financial institution system has on file for the user may be provided to the website 108 or mobile website 104 to further prevent fraudulent activity via the website 108 or mobile website 104. For example, the financial institution has a high degree of confidence that the shipping address is correct because they sent a contactless card to that address.

[0046] If the authentication results do not indicate a match between the information the user provided to the initiating website 108 and the encrypted authentication information, the authentication system 124 or third-party authentication system 130 may provide instructions that the pending transaction may be fraudulent, cancel the transaction, or that additional information is required.

[0047] Examples disclosed herein provide secure techniques for using contactless cards for user authentication to complete a transaction on a website. In general, a near field communication configuration of a computing device may be operable to perform background readings (e.g., near field communication readings are performed by an operating system of the computing device) of near field communication devices that are within communication range of the near field communication circuitry of the computing device. For example, a contactless card with a near field communication device may come within communication range of the computing device, such as by a tap gesture, and in response, the contactless card may generate a uniform resource locator (URL) that can be sent in a message to the computing device.

[0048] At least a portion of the URL may be transmitted to an application server that hosts one or more applications and / or application segments. An application or application segment may include an application available via an application store, while a segment of an application may include a portion of an application (e.g., one or more pages, one or more features, etc.). For example, an application segment may be an on-demand application, such as an instant application or a progressive web application. One or more application segments associated with the URL may be downloaded to and executed on a computing device.

[0049] The URL generated by the contactless card may further include data used by the authentication server as part of the verification process. For example, the URL may include encrypted data that is decrypted by the server as part of the verification process. The downloaded application segment may receive the URL and extract the encrypted data. The downloaded application may send the encrypted data to the authentication server for authentication and verification. Once verified, the authentication server may return an authentication result to the user application 132. The authentication result may include confirmation that the encrypted authentication information matched the information the user provided to the website 108.

[0050] Advantageously, the embodiments disclosed herein improve the consistency and speed of execution of authentication and completion of transactions between merchants and user devices. For example, the embodiments disclosed herein provide for authentication of a user when attempting to complete an online purchase with a merchant.

[0051] FIG. 3 illustrates a functional block diagram of a system suitable for interacting with a website utilizing the described techniques of the disclosed subject matter. As shown, the system 300 includes one or more contactless payment cards 318, a mobile device 302, an authentication server 308, and an application server 332. The application server 332 may include an account application 334 that responds to queries from an authentication application 336 and enables the authentication application 336 to authenticate a user as described in the previous examples. The contactless payment card 318 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, or the like. The contactless payment card 318 may include one or more chips (not shown in this example), such as a radio frequency identification (RFID) chip configured to communicate with the mobile device 302 via NFC, EMV standard, or other short-range protocols in wireless communication. For example, the contactless payment card 318 includes logic 346, a memory 320, and a communication interface 330. The memory 320 may include an applet 322, a private key 324, encrypted data 326, and a URL 328. Although NFC is used as an example of a communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as EMV standards, Bluetooth, and / or Wi-Fi. The mobile device contactless card 110 represents any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, etc. The server represents any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, etc.

[0052] As shown, the memory 304 of the mobile device 302 includes an instance of an operating system (OS), such as the Android® OS, iOS®, macOS®, Linux®, or Windows® operating systems.

[0053] As another example, a user may make a purchase from a merchant's website using a merchant-provided website 115 and / or other application 116. To complete the transaction, the user may provide card data in one or more forms within the web browser 312 and / or other application 314.

[0054] Typically, when conducting an online transaction, a user manually enters their name and address (either manually or using an auto-fill feature), followed by the card number, expiration date, and CVV. Some mobile operating systems allow for auto-filling of such data into forms, while other mobile operating systems impose limitations on the auto-filling of such data. Furthermore, operating systems that allow for auto-filling of data into forms require the user to authenticate through a dedicated application. Advantageously, however, the examples disclosed herein solve this problem by utilizing a contactless payment card 318 to authenticate the user.

[0055] To do this, the user may tap the contactless payment card 318 to the mobile device 302 and bring the contactless payment card 318 close enough to the card reader 316 of the mobile device 302 to enable NFC data transfer between the communication interface 330 of the contactless payment card 318 and the card reader 316 of the mobile device 302. In some embodiments, a user application, such as 132 of FIG. 1, running on the mobile device 302 may trigger the card reader 316 via an application program interface (API) call. In one example, the mobile device 302 triggers the card reader via an API call in response to a user tapping or selecting an element of the user interface. Additionally or alternatively, the mobile device may trigger the card reader 316 based on, for example, periodically polling the card reader 316. More generally, the mobile device 302 may trigger the card reader 316 to communicate using any feasible method. Once communication is established between the mobile device and the contactless card 318, an applet 322 executing on a processor (not shown in this example) of the contactless card 318 generates data and transmits it to the mobile device via the communication interface 330. In some embodiments, the data generated by the contactless card 318 may include a URL 328 and encrypted data 326 to form a URL with encrypted data 344 (in an example, the URL with encrypted data 344 may refer to both the URL and the encrypted data as one element) that is transmitted from the contactless payment card 318 to the card reader 316 of the mobile device 302 via NFC. The URL 328 included in the URL with encrypted data 344 may be transmitted to the authentication server 306. When the OS 310 of the mobile device 302 receives the URL 328 in the URL with encrypted data 344, the OS 310 may dynamically instruct a browser application on the mobile device 302 to communicate with the authentication server 306 using the address included in the URL 328.

[0056] The URL 328 generated by the applet 322 may further include encrypted data 326 as a parameter, such as an encrypted authentication payload. As described in more detail below, the encrypted authentication payload may be used by the authentication server 306 to verify data generated by the contactless payment card 318. For example, the applet 322 of the contactless card 318 may use an encryption algorithm to generate an encrypted payload of encrypted data 326 based at least in part on a private key 324 stored in the memory 320 of the contactless payment card 318. In such an embodiment, the private key 324 and other data (e.g., a customer identifier, an account identifier, etc.) are provided as inputs to the encryption algorithm, and the encrypted data 326 is output. In general, the applet 322 may use any type of encryption algorithm and / or system to generate the encrypted data 326, and the use of a particular encryption algorithm as an example herein should not be considered limiting of the disclosure. In some embodiments, the applet 322 may perform encryption using a key diversification technique to generate the encrypted payload.

[0057] As described above, the applet 322 of the contactless card 318 includes the encrypted data 326 as a parameter of the URL 328, thereby generating the URL with encrypted data 344. For example, if the URL to the authentication server 306 is "http: / / www.example.com / authtapp" and the encrypted data 326 is "ABC123", then the URL with encrypted data 344 is "http: / / www.example.com / authapp?data=ABC123", where the encrypted data is represented by ABC123. In some embodiments, the applet 322 may encode the encrypted data 326 according to a URL-compatible encoding format before including the encrypted data 326 as a parameter of the URL 328. For example, the encrypted data 326 may be a string of binary data (e.g., 0's and 1's) and may not be URL-compatible. Thus, the applet 322 may encode the encrypted data 326 into the American Standard Code for Information Interchange (ASCII) base64 encoding format. This converts the binary encrypted data 326 into a radix-64 representation ("ABC123" in the previous example) and represents it in the form of an ASCII string.

[0058] Once generated, the applet 322 may transmit the URL 328 including the encrypted data 326 to the mobile device 302, for example, via NFC. In one example, once received by the OS 310, the OS 310 or user application 132 causes the web browser 312 to access the URL 328 using the encrypted data 326. This causes information describing the mobile device 302 to be transmitted along with the encrypted data 344 in an authentication request to access the URL, directing the mobile device 302 to communicate with the authentication server 306. For example, the information may include attributes of the mobile device, such as a mobile device identifier, an operating system version, hardware capabilities, software capabilities, etc. Examples of mobile device identifiers include the IMEI and mobile phone number of the mobile device. In response, the authentication server 306 may be operable to decode the encrypted data 344, identify information based on the mobile device identifier, and transmit the decoded encrypted data 344 to the authentication server 306.

[0059] FIG. 4 shows an example of a contactless card that can be used in the examples described herein.

[0060] The system is comprised of a contactless card 402, a service provider 404, a substrate 406, an identification 408, and a contact pad 410. FIG. 4 illustrates a contactless card 402. The contactless card 402 may be a contactless payment card, such as a credit card, a debit card, and / or an ID card that functions as an authentication device. The contactless card 402 may also be referred to herein as an authentication device, a contactless payment card, or an authentication device. Other examples of authentication devices include key fobs, pendants, bracelets, smart wearable devices (e.g., fitness devices and smart watches), and the like. As shown, the contactless card 402 may be issued by a service provider 404 that is displayed on the front or back of the contactless card 402. In some examples, the contactless card 402 is not related to a payment card and may include, but is not limited to, an identification card or an insurance card. In some examples, the contactless card 402 may be a dual interface contactless card. For example, the contactless card 402 may include a substrate 406 having a single layer or one or more laminated layers composed of plastic, metal, or other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 402 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7610 standard, and the contactless card 402 may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that contactless cards 402 according to the present disclosure may have different characteristics and that contactless cards may be implemented as cards or devices other than payment cards.

[0061] The contactless card 402 may also include identification information 408 displayed on the front and / or back of the card, and a contact pad 410. The contact pad 410 may be configured to establish a connection with another communication device, such as a mobile device, a user device, a smart phone, a laptop, a desktop, or a tablet computer. The contactless card 402 may also include processing circuitry, an antenna, and other components not shown in FIG. 4. These components may be located behind the contact pad 410 or elsewhere on the substrate 406. The contactless card 402 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 4).

[0062] FIG. 5 illustrates additional features of the example contactless card of FIG.

[0063] As shown in Figure 5, an example of a contact pad 506 that can be used in the contactless card 402 of Figure 4 may include processing circuitry 502 for storing and processing information, including a microprocessor 508 and memory 510. It is understood that the processing circuitry 502 may include additional components, such as processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, and may be operable to perform the functions described herein.

[0064] For example, memory 510 may be read-only, write-once, or read / write memory, e.g., RAM, ROM, and EEPROM, and contactless card 402 of FIG. 4 may include one or more of these memories. Read-only memory may be programmed at the factory as read-only or one-time programmable. One-time programmable means it can be written once and then read many times. Write-once / read-multiple times memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it may be read many times. Read / write memory may be programmed and reprogrammed many times after it leaves the factory. Read / write memory may be read many times after it leaves the factory.

[0065] The memory 510 may be configured to store one or more applets 512, one or more counters 516, a customer identifier (Id) 514, and a virtual account number 518. The one or more applets 512 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 512 is not limited to a Java Card applet and may be any software application operable on a contactless card or other device with limited memory and processing power. The one or more counters 516 may include, for example, a numeric counter sufficient to store an integer number. The customer Id 514 may include, for example, a unique alphanumeric identifier assigned to a user of the contactless card 402, and may distinguish a user of a contactless card from other users of contactless cards by the customer Id 514. In some examples, the customer identifier 514 may identify both the user and an account assigned to the user at an entity such as a financial institution, and further identify the contactless card associated with the user's account. Alternatively, the UserId 514 may identify a user and a mobile device associated with the user. Or, the UserId 514 may identify a user, an account assigned to the user at an entity, and a mobile device associated with the user. In some examples, the account numbers 518 may include dozens, hundreds, or thousands of one-time use virtual account numbers associated with the contactless card 402. Another applet in the applets 512 may be configured to manage the account numbers 518.

[0066] Although the processor and memory elements of the foregoing illustrative examples are described with reference to contact pads, the disclosure is not limited thereto, and it will be appreciated that these elements may be implemented external to the contact pads 506, entirely separate from the contact pads 506, or as additional elements in addition to the microprocessor 508 and memory 510 elements disposed within the contact pads 506.

[0067] In some examples, the contact pad 506 may include one or more antennas 504. Alternatively, the one or more antennas 504 may be located within the contactless card 402, such as around the processing circuitry 502 of the contact pad 506. For example, the one or more antennas 504 may be integrated with the processing circuitry 502, or the one or more antennas 504 may be used with an external booster coil. As another example, the one or more antennas 504 may be external to the contact pad 420 and the processing circuitry 502. More generally, using the antennas 504, the processing circuitry 502, and / or the memory 510, the contact pad 506 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications, as described with reference to the examples of FIGS. 1-4.

[0068] As described above, the contactless card 402 may be built on a software platform capable of operating on a smart card or other memory-limited device, such as a Java Card, and may securely execute one or more applications or applets. The applet 512 may be configured to respond to one or more requests (e.g., Near Field Data Exchange (NDEF) requests) from a reader, such as a mobile NFC reader (e.g., mobile device 102 or 328), and to generate an NDEF message that includes, for example, cryptographically secure encrypted information encoded as an NDEF text tag.

[0069] In some examples, the contactless card 402 and / or the mobile device (e.g., 102 or 328) may include specific data such that the contactless card 402 and the user are properly identified and authentication information is obtained for processing. The contactless card 402 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 516 may be configured to increment. In some examples, each time data from the contactless card 402 is read (e.g., the mobile device 102 or 328), the counter 516, which is one of the multiple parameters, may be used by the authentication server 116 and / or the authentication app 306 or the authentication app 704 to authenticate other parameters of the multiple parameters. For example, the value of the counter 516 may be compared to a trusted counter value (e.g., maintained by the secure element or the authentication server 116) that is determined to be equal and therefore compared to other parameters (e.g., the user may be deemed to be authentic). Other examples of parameters in an encrypted authentication payload might include a version number, a unique identifier for the user, an application transaction counter, a one-time password, a cipher that can be used to verify the integrity of the message, etc.

[0070] In one example, one or more counters 516 may be configured to prevent replay attacks. For example, if a cryptogram is captured and replayed, it is immediately rejected if the counter 516 is read, used, or otherwise passed on. If the counter 516 is not used, it may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. In some examples, there is no communication between the applets 512 on the contactless card 402, so the contactless card 402 cannot determine the application transaction counter 516. In some examples, the contactless card 402 may include multiple applets 512, such as a first applet, which may be a transaction applet, and a second applet that monitors the number or timing of times the counter 516 is read.

[0071] For example, in response to the contactless card 402 being used to communicate with a mobile device (user's mobile device 102 or mobile device 302), the contactless card 402 may be operable to generate encrypted information. The encrypted information delivered to the mobile device, such as the user's mobile device 102 or mobile device 302, may include a reference link, such as a URL 522. When the user taps the contactless card 402 to the mobile device, the URL 522 delivered via the contact pad 506 may be provided to an authentication application, user application 132, etc., running on the mobile device. As shown, the URL 522 may be stored in memory 510 and may be generated by an applet 512.

[0072] In a particular example, the URL 522 may be directed to the authentication app 306 or authentication server 116 of FIG. 1. The URL 522 may further include data (e.g., parameters) used by the authentication server 116 to verify the data generated by the contactless card 402. For example, the applet 512 of the contactless card 402 may include multiple parameters of encrypted information as parameters of the URL. The authentication app 304, the authentication server 116, or both may attempt to decrypt the encrypted information using a private key associated with the contactless card 402 for the account associated with the user or the user's mobile device.

[0073] For example, the encrypted information may be a string such as "ABC123". Applet 512 may include the generated encrypted information as a parameter of URL 522, which generates a URL that includes the encrypted information. For example, URL 522 to authentication server 116 may be "http: / / www.example.com / ". Thus, URL 522 including encrypted information, such as URL with encrypted data 344 of FIG. 3, may be "http: / / www.example.com / ?ABC123". In some embodiments, applet 512 may encode the encrypted information according to a URL-compatible encoding format before including the encrypted information as a parameter of URL 522. For example, the encrypted information may be a string of binary data (such as 0's and 1's) and may not be URL-compatible. Thus, applet 103 may encode the encrypted information into the American Standard Code for Information Interchange (ASCII) base64 encoding format. This converts the binary encrypted information into a radix-64 representation and represents it in an ASCII string format ("ABC123" in the previous example).

[0074] Once generated, applet 512 may send URL 522 containing the encrypted information, for example via NFC, to user's mobile device 102 or mobile device 302. In one embodiment, once received by user's mobile device 102 or mobile device 302, an application, such as user application 132, may open and access URL 522 containing the encrypted information and send the encrypted information to an authentication server, such as authentication system 124 of FIG. 1, addressed by URL 522.

[0075] The key diversification technique described herein with reference to counter 516 having access to cryptographic keys 520 (e.g., master and diversified keys) is one example of a key diversification technique. This example key diversification technique applies to other types of key diversification techniques as well, and is not to be considered limiting of the disclosure.

[0076] For example, during the contactless card 402 creation process, two encryption keys 520 may be uniquely assigned per card. The encryption keys 520 may include symmetric keys that can be used to both encrypt and decrypt data. For example, 3DES (Triple Data Encryption Algorithm) is used by payment methods such as Europay, Mastercard, Visa (EMV), and may be implemented by hardware in the contactless card 402. A key diversification process may be used to derive one or more keys from the master key based on uniquely identifiable information for each entity that requires an encryption key.

[0077] In some examples, to overcome deficiencies in the 3DES algorithm that may be susceptible to vulnerabilities, a session key may be derived (such as a unique key per session), but instead of using a master key, a unique card derivation key and a counter may be used as diversification data. For example, each time the contactless card 402 is used in operation, a different key may be used to create tags such as message authentication codes (MACs) and to perform encryption. This results in three layers of encryption. The session key is generated by one or more applets and derived using an application transaction counter with one or more algorithms (EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation Definition).

[0078] Additionally, the increment for each card is unique and may be assigned by personalization or algorithmically by some identifying information. For example, odd cards may increment by 2 and even cards may increment by 5. In some instances, the increment may also change with successive reads, such that one card may increment by 1, 3, 5, 2, 2, ... and so on and so forth. The specific sequence or algorithmic sequence may be defined at the time of personalization and may be defined from one or more processes derived from the unique identifier. This makes it difficult for a replay attacker to generalize from a small number of card instances.

[0079] FIG. 6 illustrates an example of an exemplary computing architecture 602 suitable for implementing the various examples described above. In various examples, the computing architecture 602 may be included or implemented as part of an electronic device. In some examples, the computing architecture 602 may represent, for example, a user's mobile device 102, a server implementing or providing a website 108 or a mobile website 104, a third-party authentication system 130, and an authentication system 124 of the system 100. The examples are not limited in this context. More generally, the computing architecture 602 is operable to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to the examples of FIGS. 1-5.

[0080] Computing architecture 602 may include a variety of common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc., although these examples are not limited to implementation by computing architecture 602.

[0081] As shown in FIG. 6, computing architecture 602 includes processor 604, system memory system bus 606, and system bus 608. Processor 604 may be any of a variety of commercially available computer processors, including AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2)Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors, and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processor 604.

[0082] The system bus 606 provides an interface between the processor 604 and system components including, but not limited to, the system memory 656. The system bus 606 can be any of several types of bus structures that can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus 606 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Enhanced) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (PCI), PCI Extended (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

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

[0084] The computing architecture 602 may include various types of computer readable storage media in the form of one or more low speed memory units, such as an internal hard disk drive (HDD) 660, a magnetic floppy disk drive (FDD) 614 that reads from or writes to a removable magnetic disk 616, and an optical disk drive 618 that reads from or writes to a removable optical disk 620 (such as a CD-ROM or DVD). The HDD 660 or 612, the FDD 614, and the optical disk drive 618 may be connected to the system bus 606 by a HDD interface 622, a FDD interface 624, and an optical drive interface 626, respectively. The HDD interface 622 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing architecture 602 is generally configured to implement all of the logic, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-5.

[0085] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, the drives and memory units 608, 610 may store a number of program modules, including an operating system 628, one or more application programs (or “applications”) 630, other program modules 632, and program data 634. In one example, the one or more applications 630, other program modules 632, and program data 634 include various applications and / or components of the system 100, such as, for example, user applications 132.

[0086] For example, a user may enter commands and information into the computing architecture 602 through one or more wired or wireless input devices, such as a keyboard 636 and a pointing device, such as a mouse 638. Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (capacitive, resistive, etc.), trackballs, track pads, sensors, styluses, etc. These and other input devices are often connected to the processor 604 through an input device interface 640 coupled to the system bus 606, but may also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0087] A monitor 642 or other type of display device is also connected to the system bus 606 via an interface, such as a video adapter 644. The monitor 642 may be located inside or outside the computing architecture 602. In addition to the monitor 642, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0088] The computing architecture 602 may operate in a networked environment using wired and / or wireless communication logical connections to one or more remote computers, such as a remote computer 658. The remote computer 658 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and typically includes many or all of the elements described in conjunction with the computing architecture 602, although for purposes of brevity, only the memory / storage device 646 is shown. The logical connections shown include wired / wireless connections to larger networks, such as a local area network (LAN) 648 and a wide area network (WAN) 650. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks, such as an intranet, all of which may be connected to a global communications network, such as the Internet. In an example, the data network 106 of FIG. 1 may be one or more of the LAN 648 and the WAN 650.

[0089] When used in a LAN networking environment, the computing architecture 602 is connected to the LAN 648 via a wired and / or wireless communication network interface or adapter 652. The network adapter 652 can facilitate wired and / or wireless communication to the LAN 648, and a wireless access point can also be located on the LAN 648 for communicating with the wireless capabilities of the network adapter 652.

[0090] When used in a WAN networking environment, the computing architecture 602 includes a modem 654 or is connected to a communications server on the WAN 650 or other means for establishing communications over the WAN 650, such as via the Internet. The modem 654 is an internal or external wired and / or wireless device that connects to the system bus 608 via the input device interface 640. In a networked environment, program modules depicted relative to the computing architecture 602, or portions thereof, can be stored in the remote memory / storage device 646. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

[0091] The computing architecture 602 operates to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.16 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication may be of a predefined structure, as in a traditional network, or it may be ad-hoc communication between at least two devices. A Wi-Fi network uses radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, high-speed wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0092] Figure 7 illustrates an example system including a mobile device that can be used to implement the techniques and processes described with reference to the examples of Figures 1 to 5. The illustrated system 700 can include a mobile device 706 and a user identification device 702.

[0093] The mobile device 706 may be a smartphone with a display device such as a touch screen display 708. The touch screen display 708 may be connected to a microprocessor 710 to display screen content and receive input via a touch sensor 712. Input to the touch sensor 712 may be processed by a sense circuit 744. Examples of touch screen type mobile devices such as the mobile device 706 include, but are not limited to, smartphones, personal digital assistants (PDAs), tablet computers, smart watches, or other portable devices. However, the structure and operation of the mobile device 706 utilizing a touch screen is provided by way of example, and the subject technology described herein is not limited thereto. The logic implemented by the microprocessor 710 of the mobile device 706 configures the microprocessor 710 to control various functions implemented by the mobile device 706. Although the processor logic can be implemented in a variety of ways, in the example presented herein, the processor logic is implemented by programming for execution by the microprocessor 710.

[0094] There are various ways that the mobile device 706 may obtain information regarding the device's current location. In this example, the mobile device 706 includes a Global Positioning Satellite (GPS) receiver 716 and associated antenna 714. GPS is a space-based satellite navigation system that provides location and time information nearly anywhere on Earth. A rechargeable battery (not shown) may provide sufficient power to power the various components of the mobile device 706.

[0095] The mobile device 706 further includes a microprocessor 710 that serves as a programmable controller for the mobile device 706 by configuring the mobile device to perform various operations, for example, according to instructions or programming executable by the microprocessor 710. For example, such operations may include various general operations of the mobile device 706 as well as operations related to the user authentication functionality described herein. The flash memory 726 may be used, for example, to store programming or instructions executed by the microprocessor 710. Depending on the type of device, the mobile device 706 stores and executes an operating system capable of executing certain applications on the device. Examples of operating systems include Android, Apple iOS, Microsoft Windows OS, Bada, Tizen, Symbian OS, Blackberry OS, and the like. The flash memory 726 may also be used to store mobile configuration settings for various mobile applications or services executable by the mobile device 706 (using the microprocessor 710). The mobile device 706 may also include a non-volatile random access memory (RAM) 724 for working data processing memory. RAM 724 , flash memory 726 , and secure element storage 742 may be coupled to microprocessor 710 and may store programming code executable by microprocessor 710 .

[0096] Mobile devices supporting the claims processing and authentication techniques described herein may include various types of user interface elements. For purposes of illustration, in the smartphone example of a mobile device shown in FIG. 7, the user interface elements of the mobile device 706 may include a touch screen display 708. For output purposes, the touch screen display 708 may include a display screen, such as a liquid crystal display (LCD). For input purposes, the touch screen display 708 includes a number of touch sensors 712 that output signals processed by sense circuitry 744. Other interface elements may include a keypad including one or more keys 718. For example, the keypad may be implemented in hardware as a T9 or QWERTY keyboard on the mobile device 706, and the keys 718 may correspond to the physical keys of such a keyboard. Alternatively, the keys 718 (and keyboard) of the mobile device 706 may be implemented as "soft keys" of a virtual keyboard that is graphically represented in an appropriate arrangement via the touch screen display 708. Soft keys displayed on the touch screen display 708 allow a user of the mobile device 706 to invoke the same user interface functions as physical hardware keys. In some implementations, the microphone 720 and speaker 722 may be used as additional user interface elements for audio input and output for some functions related to processing associated with cooperation with the authentication app 704, as described herein. In a further example, in response to accessing contacts stored in RAM 724, the authentication app 704 may display a prompt in the user interface asking the user to have the mobile device 706 interact with a user identification device 702, such as a contactless card 110, to obtain encrypted information, an encrypted authentication payload, or a URL containing encrypted data (such as URL containing encrypted data 344) for processing by the user app 728 or the authentication app 704, or for transmission by a browser, such as the web browser 312.

[0097] For output, the touch screen display 708 is a display device used to present information (such as text, video, graphics, or other display content) to a user of the mobile device 706. The microprocessor 710 controls the visual display output on an LCD or other display element of the touch screen display 708 via a display driver 730 to present various visual outputs to the device user.

[0098] The microphone 720 and speaker 722 are communicatively coupled to a voice or audio encoder / decoder (vocoder) 732. For example, in the case of a voice telephone call, the vocoder 732 provides bidirectional conversion between analog audio signals representing voice or other audio and compressed bit rate digital samples compatible with the digital protocols of wireless telephone network communications or voice over packet (such as Internet Protocol) communications. The vocoder, speaker, and microphone may be used as elements of a user interface during other operations of the device, including some types of transactional communications.

[0099] Also shown in FIG. 7, the mobile device 706 includes at least one transceiver 734 (denoted in the figure as XCVR) and associated antenna 736, which may be a digital transceiver for digital wireless communication over a wide area wireless mobile communication network, although the mobile device 706 may include additional digital or analog transceivers (not shown). The transceiver 734 is compliant with one or more of the various digital wireless communication standards utilized in modern mobile networks. Examples of such transceivers include, but are not limited to, transceivers operable in accordance with Code Division Multiple Access (CDMA) and 3rd Generation Partnership Project (3GPP) network technologies, such as, for example, 3GPP Type 2 (or 3GPP2) and 3GPP Long Term Evolution (LTE) (or "4G"), 5th Generation Wireless (5G), and the like. For example, the transceiver 734 may provide two-way wireless communication of information including digitized audio signals, still images and / or video signals, web page information for display, web-related input, and various types of mobile message communication to and from the mobile device 706. The transceiver 734 may also support various types of mobile messaging services, such as Short Message Service (SMS), Enhanced Messaging Service (EMS), and / or Multimedia Messaging Service (MMS).

[0100] In one example, the transceiver 734 may be coupled to the microprocessor 710 and operable to exchange communications. The microprocessor 710 of the mobile device 706 may further be operable to perform additional functions, including the functionality of establishing a connection and exchanging communications with a server or entity, such as the authentication server 116 or website 108 of FIG. 1, using the transceiver. The mobile device 706 may be capable of obtaining various information, such as authentication information, product information, user information, etc., via the connection with the server or website. The processor, in executing the authentication app 704 and the user app 728, may implement the examples described above with reference to FIGS. 1-5.

[0101] The mobile device 706 may also include a Wi-Fi transceiver 740 and associated Wi-Fi antenna 738. Although Wi-Fi is used here as an example, the transceiver 740 may take the form of any available two-way wireless local area network transceiver of a type compatible with one or more standard communications protocols implemented in a wireless local area network, such as one of the Wi-Fi standards based on IEEE 702.11 and / or WiMAX.

[0102] Alternatively or additionally, the application may be stored in secure element (SE) storage 742, which may be solid-state memory storage or other memory device suitable for storing applications. In one example, secure element storage 742 may be a separate chip that includes tamper-resistant storage and execution memory and is capable of communicating with an operating system. Secure element storage 742 stores an instance of authentication app 704 for processing receipt data, communicating with one or more services or servers, and executing processes, for example as described with reference to the examples of Figures 1-3. Other applications, such as authentication app 704 and user app 728, may also be stored in secure element storage 742.

[0103] The mobile device 706 may also include a secure element storage 742 and a near field communication device 746 connected to the microprocessor 710. As described in the previous examples, the authentication app 704 and the user app 728, when executed by the microprocessor 710, may be operable to control the near field communication device 746 and receive signals from a user identification device 702 implemented as a contactless card 110, an authentication information device 330, or a contactless card 402. Details of the user identification device 702 may be obtained from the previous description of the contactless card 110, the authentication device 330, or the contactless card 402. As described above, the contactless card 402, when implemented as a user identification device 702, may be built on a software platform operable on a smart card or other memory-limited device such as a Java Card, and may securely execute one or more applications or applets. For example, applets may be added to the contactless card to provide authentication in various mobile application-based use cases, such as user authentication for transaction completion examples, as described above. The applet is configured to respond to one or more requests (e.g., a near-field data exchange request) from an application, such as the authentication app 704 or the user app 728, and enables a mobile NFC reader (e.g., the near-field communication device 746 of the mobile device 706) to receive or generate an NDEF message that includes a cryptographically secure payload encoded as an NDEF message.

[0104] In this example, the near field communication device 746 may include an NFC controller 748, an NFC transceiver 750, and an NFC antenna 752. The NFC controller 748 may initiate contact with the user identification device 702 according to a known NFC communication protocol, causing the NFC transceiver 750 to transmit signals and receive signals via the NFC antenna 752 to establish communication with the user identification device 702. The user app 728 may process signals received from the user identification device 702 as described above with reference to the examples of Figures 1-5. The authentication app 704 may process received signals as described in the examples of Figures 1-3.

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

[0106] The terms "system" and "component" and "module" as used in this application are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 800. For example, a component may include, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. As an example, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer or distributed across two or more computers. Furthermore, components can be communicatively coupled to each other by various types of communication media to coordinate operations. Coordination can include unidirectional or bidirectional exchange of information. For example, components can communicate information in the form of signals communicated over the communication media. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message becomes a signal. However, other examples may use data messages instead. Such data messages may be transmitted over a variety of connections, example connections include parallel interfaces, serial interfaces, and bus interfaces.

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

[0108] The foregoing description of example 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. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but by the claims appended hereto. Future applications claiming priority to this application may claim the disclosed subject matter in a different manner, and may generally include any set of one or more features variously disclosed or illustrated herein.

Claims

1. 1. A method comprising: Identifying, by the financial institution system, a pending transaction associated with the user's verification identifier; sending instructions to a mobile device associated with the verification identifier to initiate a near field wireless communication interaction with a portable physical token associated with the financial institution system; receiving, at the financial institution system, an authentication request generated in response to the near field communication interaction, the authentication request comprising an encrypted authentication payload derived from the portable physical token; verifying the encrypted authentication payload to authenticate the user as the holder of the portable physical token; In response to said verification, transmitting a signal to enable completion of said pending transaction; A method for providing the above.

2. The method of claim 1, wherein transmitting the instruction comprises displaying a prompt on the mobile device requesting confirmation of the pending transaction. The method of claim 1.

3. The method of claim 2, wherein transmitting the instruction comprises causing the mobile device to initiate a background read of the portable physical token without intervention by the user. The method of claim 1.

4. The instructions include a hyperlink to an authentication address of the financial institution system. The method of claim 1.

5. verifying the encrypted authentication payload decrypting the encrypted authentication payload; Obtaining at least one parameter comprising a version number, a unique identifier, an application transaction counter, a one-time password, or a cryptogram; Equipped with The method of claim 1.

6. Receiving a hyperlink corresponding to a trading session that has been deactivated by the remote trading interface after a period of time has elapsed; maintaining said hyperlinks in association with information relevant to said user; In response to a subsequent notification, utilizing the hyperlink to reactivate the trading session; Further provided with The method of claim 1.

7. The instruction is formatted as one of a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, or an in-application notification. The method of claim 1.

8. A computing device comprising: Processor circuit and a memory storing instructions that, when executed by the processor circuitry, cause the computing device to: The instructions may cause the computing device to: receiving a notification regarding a transaction request initiated via a remote interface, the notification including a user identifier; generating a trigger signal for a mobile device corresponding to the user identifier, the trigger signal causing the mobile device to attempt a wireless read of a contactless device associated with the user; receiving a transaction authorization request comprising cryptographic data obtained from a wireless reading of the contactless device; performing a verification operation on the encrypted data; If the verification is successful, approving the transaction request; A computing device that runs 9. The method of claim 8, wherein the trigger signal is configured to cause the mobile device to display a user interface prompt. The computing device of claim 8.

10. The trigger signal is configured to cause the mobile device to initiate the wireless reading as a background process. The computing device of claim 8.

11. The verifying operation comprises decrypting the encrypted data to extract an application transaction counter or ciphertext used to verify the integrity of the message. The computing device of claim 8.

12. The instructions further cause the computing device to: storing a recovery link associated with the transaction request upon expiration of a session timer; upon receiving a subsequent user instruction, reactivating the transaction request using the recovery link; The computing device of claim 8.

13. The method of claim 12, wherein the trigger signal is transmitted via a financial institution application installed on the mobile device. The computing device of claim 8.

14. The contactless device is a payment card associated with a financial institution. The computing device of claim 8.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to perform the following operations: receiving a notification that a transaction authorization request is received, the notification being associated with a user verification identifier; sending a message corresponding to the user verification identifier to a mobile device, the message comprising instructions executable by the mobile device to initiate local wireless communication with a physical token; receiving an encrypted payload obtained from the physical token via the local wireless communication; decrypting the encrypted payload to obtain authentication parameters; enabling completion of a transaction associated with the notification based on the authentication parameters; A non-transitory computer-readable storage medium that causes 16. The message includes a hyperlink to an authentication web address.

16. The non-transitory computer-readable storage medium of claim 15.

17. The instructions further cause the processor to: initiating a background reading of the physical token by a near field communication device of the mobile device; 16. The non-transitory computer-readable storage medium of claim 15.

18. The method of claim 17, wherein the authentication parameters include at least one of a unique identifier for the user or a dynamic cryptogram.

16. The non-transitory computer-readable storage medium of claim 15.

19. The instructions further include causing the processor to: verifying that information provided by the transaction originator is substantially identical to information maintained by the financial institution system using said authentication parameters; 16. The non-transitory computer-readable storage medium of claim 15.

20. The instructions further cause the processor to: receiving a session recovery link corresponding to the deactivated trading session; temporarily maintaining the session recovery link to facilitate reactivation of the trading session; Execute 16. The non-transitory computer-readable storage medium of claim 15.

Images