System and method for providing transaction cards to multiple merchants

Abstract

Systems, methods, apparatus, and computer-readable media for providing transaction cards from a single access point to multiple merchants are described. For example, a method may include receiving a payment card number request, sending a contactless payment card upgrade authentication request to a user device, receiving encrypted authentication information obtained from a contactless payment card from the user device in response to the contactless payment card upgrade request, authenticating the encrypted authentication information received from the user device, and sending the authenticated encrypted authentication information to the user device. A token identifying a communication session established with a merchant is granted, which can enable continuous data exchange with the merchant, and using the token to identify a respective communication session established with the merchant, providing account information to the merchant to associate a respective merchant account with a user of the contactless payment card.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 18 / 136,497, filed April 19, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0003] Consumers can store or register payment cards with various merchants. Registered payment cards can be automatically retrieved to process consumer purchases, making transactions more efficient, secure, and / or providing additional benefits to consumers. For example, a consumer might have an online account with an e-commerce retailer. This online account can store personal information as well as payment information, such as sufficient credit card information to process the payment. When a consumer makes a purchase, the credit card information can be automatically retrieved and used as the payment source (in response to the consumer's confirmation).

[0004] A typical consumer may have payment cards registered with multiple merchants. For example, a single credit card might be stored as a payment source at e-commerce retailers, grocery stores, and for automatic bill payments (e.g., for electricity service providers, gym memberships, media streaming memberships, and / or the like). If a user acquires a new payment card they prefer to use in place of their previous card, they need to update the payment information for each individual account, vendor, etc. Updating payment sources at multiple merchants using conventional technology is a cumbersome and time-consuming process, and is also prone to errors due to the manual data entry of payment card information. Furthermore, manually updating payment card information is an insecure process, where cardholders are vulnerable to unauthorized access to their information. Therefore, consumers would benefit from a more secure, efficient, and easier process for managing payment information across multiple merchants. Summary of the Invention

[0005] Systems, methods, apparatus, and computer-readable media for providing transaction cards to multiple merchants are described.

[0006] In one embodiment, a computer-implemented method may include: receiving multiple payment card number requests from a user device at a financial institution server, wherein the payment card number request is received for each of a plurality of merchant websites; sending an authentication request to the user device, wherein the authentication request is a request for the user device to interact with a contactless payment card associated with a user's financial institution account; in response to the authentication request, receiving encrypted authentication information received from the contactless payment card from the user device; authenticating the encrypted authentication information received from the user device; based on successful authentication, granting a corresponding token to each of the plurality of merchants, wherein each of the granted corresponding tokens identifies a corresponding communication session established with each corresponding merchant and enables continuous data exchange with each corresponding merchant; and using each corresponding token to identify the corresponding communication session established with each corresponding merchant, providing account information to each corresponding merchant as needed to associate the corresponding merchant account with the user of the contactless payment card.

[0007] In some embodiments of the method, the last payment card number request among multiple payment card number requests can be received within a predetermined time period.

[0008] In various embodiments of the method, the predetermined time period may be determined based on the reception time of the first payment card number request among a plurality of payment card number requests.

[0009] In some embodiments of the method, the predetermined time period can be about 5 minutes, about 10 minutes, or about 20 minutes.

[0010] In an exemplary embodiment of the method, receiving multiple payment card number requests may include establishing a secure connection with the user equipment.

[0011] In various embodiments of this method, the secure connection may be established based on the user's identification information for the contactless payment card.

[0012] In some embodiments of the method, the identification information may be received before the first payment card number request in a plurality of payment card number requests.

[0013] In various embodiments of the method, authenticating encrypted authentication information received from a user equipment may include: decrypting the encrypted authentication information; and confirming that the information input from the user equipment corresponds to the decrypted authentication information accessible to the financial institution's server.

[0014] In an exemplary embodiment of the method, authenticating the encrypted authentication information received from the user equipment may include: upon successful confirmation, generating an authorization to grant a corresponding token to each of the multiple payment card number requests.

[0015] In one embodiment, a computer-implemented method may include: receiving a first payment card number request from a first merchant among a plurality of merchants at a financial institution server, to associate user financial institution account information with the first merchant account; sending a contactless payment card upgrade authentication request to the user device, wherein the contactless payment card upgrade authentication request is a request for the user device to interact with a contactless payment card associated with the user financial institution account information; in response to the contactless payment card upgrade request, receiving encrypted authentication information maintained on the contactless payment card from the user mobile device; authenticating the encrypted authentication information received from the user device; and, based on successful authentication, granting a first token to the first merchant, wherein the first token identifies a communication session with the first merchant and enables continuous data exchange with the first merchant.

[0016] In some embodiments of the method, the method may include using a token to identify a communication session and providing account information as needed for the first merchant to populate the first merchant account.

[0017] In various embodiments of the method, the method may further include: receiving a second payment card number request from a second merchant; and, based on successful authentication, granting a second token to the second merchant, the second token identifying a communication session with the second merchant and enabling continuous data exchange between the user's financial institution account data and the second merchant.

[0018] In an exemplary embodiment of the method, the token enables data to be retrieved by each of a plurality of merchants.

[0019] In various embodiments of this method, the user's financial institution account information may include the user's payment card number and payment card-related information.

[0020] In one embodiment, a non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause the processor to: receive a plurality of payment card number requests from a user equipment, wherein the payment card number requests are received for each of a plurality of merchant websites; send a contactless payment card upgrade authentication request to the user equipment, wherein the contactless payment card upgrade authentication request is a request for the user equipment to interact with a contactless payment card associated with a user's financial institution account; in response to the contactless payment card upgrade request, receive encrypted authentication information obtained from the contactless payment card from the user equipment; authenticate the encrypted authentication information received from the user equipment; based on successful authentication, grant a corresponding token to each of the plurality of merchants, wherein each of the granted corresponding tokens identifies a corresponding communication session established with each corresponding merchant and enables continuous data exchange with each corresponding merchant; and use each corresponding token to identify the corresponding communication session established with each corresponding merchant, and provide account information to each corresponding merchant as needed to associate the corresponding merchant account with the user of the contactless payment card.

[0021] In some embodiments of the computer-readable storage medium, the last payment card number request among a plurality of payment card number requests can be received within a predetermined time period.

[0022] In various embodiments of the computer-readable storage medium, the predetermined time period may be determined based on the reception time of the first payment card number request among a plurality of payment card number requests.

[0023] In some embodiments of the computer-readable storage medium, the predetermined time period may be about 5 minutes, about 10 minutes, or about 20 minutes.

[0024] In an exemplary embodiment of the computer-readable storage medium, upon receiving multiple payment card number requests, the processor is operable to: establish a secure connection with a user device based on user identification information received prior to receiving a first payment card number request among the multiple payment card number requests.

[0025] In various embodiments of the computer-readable storage medium, authenticating encrypted authentication information received from a user equipment includes: decrypting the encrypted authentication information; confirming that the information input from the user equipment corresponds to the decrypted authentication information; and, upon successful confirmation, generating an authorization to grant a corresponding token to each of the multiple payment card number requests. Attached Figure Description

[0026] To facilitate identification of any particular element or behavior being discussed, the highest significant digit or digits in the reference numerals refer to the drawing number in which the element is first introduced.

[0027] Figure 1An exemplary operating environment according to this disclosure is described.

[0028] Figure 2 An exemplary operating environment according to this disclosure is described.

[0029] Figure 3 An exemplary operating environment according to this disclosure is described.

[0030] Figure 4 An embodiment of the first logical flow according to this disclosure is shown.

[0031] Figure 5 An embodiment of the second logical flow according to this disclosure is shown.

[0032] Figure 6 A contactless card according to this disclosure is shown.

[0033] Figure 7 The transaction card component according to this disclosure is shown.

[0034] Figure 8 A sequence stream according to this disclosure is shown.

[0035] Figure 9 The data structure according to this disclosure is shown.

[0036] Figure 10 It is a diagram of the key system based on this disclosure.

[0037] Figure 11 This is a flowchart of a method for generating a password according to this disclosure.

[0038] Figure 12 One or more features of the subject matter according to this disclosure are shown.

[0039] Figure 13 One or more features of the subject matter according to this disclosure are shown.

[0040] Figure 14 A computer architecture according to one embodiment is shown. Detailed Implementation

[0041] For the purpose of facilitating an understanding of the principles of this disclosure, reference will now be made to the embodiments shown in the figures, and they will be described using specific language. However, it should be understood that this is not intended to limit the scope of this disclosure. Any changes and further modifications to the described embodiments, and any further application of the principles of this disclosure as described herein, are contemplated as would normally be expected by those skilled in the art to be applicable to this disclosure.

[0042] The described technology generally relates to systems and methods for supplying transaction cards to multiple entities. In some embodiments, the transaction card may be a payment card, credit card, debit card, gift card, and / or the like. In various embodiments, the transaction card may be a contactless card (see, for example, see...). Figures 6-13 Non-limiting examples of entities may include merchants, retailers, suppliers, shopping clubs, membership organizations (e.g., cooperatives, gyms, and / or the like), e-commerce platforms, and / or the like. Although examples of merchant entities may be used in this disclosure, the embodiments are not so limited, as the described techniques can be used in relation to a wide variety of different types of entities.

[0043] Users can have a registered account with an entity (“Entity Account”) (e.g., Kroger®, Amazon®, Sam's Club®, Walmart®, Target®, and / or similar entities). A registered account may include personal information (e.g., name, address, demographic information, preferences, and / or similar) and payment information. In various embodiments, payment information may be or may include information about a transaction card (such as a credit card) that can be used to pay for a purchase. Transaction card information may include, but is not limited to, the cardholder's name, cardholder's address, card number, expiry date, card verification value (CVV), and / or similar. A registered account may allow users to perform transactions with entities via an online platform (e.g., a retailer's e-commerce website, mobile application (“app”), and / or similar) and / or at a physical retail location using the stored payment information. In this way, users can use the information stored in their account to automatically select a payment card to process payments without having to access the physical card.

[0044] Using the existing system, each time a user wants to use a new transaction card with one or more entities, they are required to manually update the account information for each individual entity. Updating payment sources across multiple entities is a cumbersome and time-consuming process, and is prone to errors due to the manual data entry of payment card information. Furthermore, manually updating payment card information is an insecure process, as cardholders are vulnerable to unauthorized access to their information. Therefore, when a user obtains a new transaction card, such as a credit or debit card, they must undertake the arduous and insecure process of updating payment information to each individual entity.

[0045] Therefore, some embodiments provide methods and systems to facilitate the delivery of transaction cards to multiple different and unrelated entities (e.g., "third-party entities") via a single process through an access point.

[0046] In some embodiments, for example, a user may access their account via a transaction platform (e.g., a website, application, app, and / or the like) of a financial service provider that manages the financial services functionality of the transaction card. Non-limiting examples of financial service companies may include banks, credit unions, credit card companies, government organizations (e.g., organizations that issue government-managed payment cards), and / or the like. In one non-limiting example, the financial service provider may be Capital One Financial Corporation (“Capital One”, the transaction card issuer), located in McLean, Virginia, United States of America. A financial service platform configured according to some embodiments may allow the user to specify which entity accounts should be associated with the transaction card. The financial service platform may use a process configured according to some embodiments to push this information to entity accounts operated by third-party entity systems. In this way, a financial service platform operating according to various embodiments may allow the user to update payment information across multiple entities through a single access point in an efficient, accurate, and secure process.

[0047] In an illustrative and non-limiting example, a financial service provider may establish authorization relationships with various entities. Examples of authorization relationships may be or may include “open authorization” or “OAuth” relationships. Typically, an OAuth relationship is an open standard authorization protocol or framework that specifies how unrelated services can securely allow authenticated access to their assets without actually sharing a single login credential. One example of an OAuth implementation is the OAuth 2.0 standard, which is based on open delegation established by the Internet Engineering Task Force (IETF). The OAuth 2.0 standard enables an authorization server to issue an access token to a third-party client with the approval of the resource owner. The third party then uses the access token to access protected resources hosted by the resource server. The access token is limited to a short period of time, such as approximately 5 minutes, approximately 10 minutes, approximately 20 minutes, and / or the like. Although OAuth is used as an example of an authorization relationship in this disclosure, the embodiments are not so limited, as any authorization relationship that can operate according to some embodiments is contemplated herein.

[0048] Authorization relationships allow third-party entities (e.g., e-commerce platforms) to accept or trust the authentication of financial services companies (e.g., Capital One) and progressively authorize access to archive a new card with a user's third-party entity account (i.e., the user's e-commerce platform account). Once an authorization relationship is established, the user can log in to the financial service provider's platform (e.g., the credit card's application programming interface) and perform authentication (e.g., upgrade authentication). This can be achieved using verification processes (e.g., contactless card authentication, e.g., see [link to relevant documentation]). Figures 6-13This includes authentication upgrades, multi-factor authentication, SMS one-time passwords (OTP), driver's license verification, and / or similar methods. Users can authorize financial service providers to archive their cards with the back-end services of third-party entities. Users can choose which third-party entities can update their account records to include the card (including replacing existing cards). In some embodiments, financial service providers can use past transactions to determine which merchants to present to customers. For example, if a user has already used a credit card with Merchant A and Merchant B, the user can be presented with the option to confirm pushing new credit card information to the platforms of Merchant A and Merchant B.

[0049] In some embodiments, authorization relationships (such as OAuth) can be respected by third-party entity systems, enabling financial service provider backends and third-party entity backends to communicate various information items to third-party entities, such as account numbers, primary account numbers (PANs), virtual account numbers (VCNs) (including locked VCNs), and personally identifiable information (PII) data (e.g., names, addresses, phone numbers, email addresses, and / or the like).

[0050] In some embodiments, the process of updating transaction card information via a financial service provider platform can be performed using the credit card user's existing third-party entity account. In various embodiments, the financial service platform can operate to create a new account with transaction card information.

[0051] Figure 1 An exemplary operating environment according to this disclosure is depicted. Operating environment (or system) 100 may include financial institution system 118, website 108, mobile website 104, mobile device 102, contactless card 110, and data network 106.

[0052] Data network 106 can be a network, such as the Internet, wide area network, local area network, metropolitan area network, cellular network, combination of networks, or the like, which enables different devices and systems to communicate with each other.

[0053] Website 108 and mobile website 104 can be services executed on servers or cloud platforms that provide services or products from service providers or merchants.

[0054] The financial service provider (or financial institution) system 118 may be provided by an entity such as a bank, mortgage company, investment company, credit card issuer, financial service provider (e.g., Capital One), and / or the like, and this entity is referred to below as a “financial institution” or “financial service provider.” The financial institution may have business relationships with multiple third-party entities (or “merchants”). These merchants may include those conducting business online, selling goods and / or services through online transactions made possible by websites such as website 108 and mobile website 104. Additionally or alternatively, the financial institution may have business relationships with multiple consumers who interact with the financial institution system 118 via their mobile devices (such as mobile device 102). As part of the relationship with consumers, the financial institution may issue a contactless card 110 to consumers after a sufficient number of checks (to verify identity, physical address, income, family members, account information, and the like).

[0055] As illustrated in the examples below (see, for example, see...) Figures 6-13 The contactless card 110 may be operable to provide encrypted authentication information that can be authenticated by the financial institution system 118. The contactless card 110 may be equipped with 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.

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

[0057] The financial institution system 118 may include multiple systems, memories, modules and components, such as user data storage device 120, financial institution processor 122, authentication system 124 and communication interface 126.

[0058] Communication interface 126 is operable to facilitate communication between financial institution system 118 and mobile device 102, mobile website 104, and / or website 108 via data network 106. Communication link 128 can couple mobile website 104 to data network 106. Similarly, communication interface 126 is operable to receive information transmitted via data network 106 from each of mobile device 102, mobile website 104, and website 108. Communication interface 126 can communicate via data network 106 using known communication protocols.

[0059] User data storage device 120 can securely maintain information about users, which is used by authentication system 124 to authenticate users. For example, the maintained information about users may include personally identifiable information (PII), such as the user's name, home address, spouse information, telephone number, bank loan balance, account type, type of car secured by loan, mobile phone identifier (such as International Mobile Equipment Identity (IMEI) number or the like), password, permanent account number, past virtual account number, transaction count, and the like.

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

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

[0062] Customers can enter identifiers into fields on a webpage displayed by a web browser (such as a telephone number, email address, Permanent Account Number (PAN), or similar). For example, a user can enter the first five digits of the PAN, which provides mobile website 104 with sufficient information to identify the user's financial institution. This identifier may include other additional information, such as special keywords, an account number or name maintained in connection with website 108 or mobile website 104, or similar information, which is directed to website 108 and / or mobile website 104. Alternatively, users can select the financial institution presented on the webpages of website 108 and / or mobile website 104 for use in the authentication process.

[0063] Website 108 may be operable to identify users as users in a central database or bank identification number. In a detailed example, website 108 may have relationships with multiple different financial institutions and / or merchants. When website 108 receives a user's identification information, such as a telephone identifier or email address, website 108 may broadcast that information to all the different financial institutions with which website 108 has a relationship. The first financial institution to respond to the confirmation is the financial institution with which website 108 will continue the transaction session. Mobile website 104 may be operable to be presented and operated on mobile devices such as smartphones, laptops, and tablets, and function in a similar manner to website 108.

[0064] The aforementioned system 100 may be operable to provide secure authentication of users and simplified secure transactions as outlined in the following process example.

[0065] Customers may be asked to tap their contactless card against a phone for background reading of authentication information that a financial institution can use to authenticate the user. In some examples, this disclosure refers to a “tapping” of the contactless card. However, it should be understood that this disclosure is not limited to tapping and includes other gestures (e.g., waving or other movements of the card). The authentication information read by the phone may be a Uniform Resource Locator (URL) (also referred to as a “link”) associated with the financial institution. The URL may contain an encrypted payload that is authenticated by the authentication system 124 of the financial institution system 118. Alternatively, the user’s authentication may also be used as approval for a transaction, in which case any account information or similar required for the merchant to complete the transaction at website 108 may be provided by the financial institution and a notification of transaction completion may be presented to the user.

[0066] The financial institution system 118 sends an authentication response to the merchant along with the remainder of the personally identifiable information (PII) data and a possible virtual card number (VCN), which can be a 15 or 16-digit number like a credit card number but without a physical credit card.

[0067] Essentially, users simply provide their identifier (email address or phone number) and tap a contactless card 110 onto a mobile device 102, and once authenticated, information used to complete the transaction (such as PII data, most frequently used delivery addresses, and the like) can be provided to the merchant.

[0068] A request to tap a card onto a phone can trigger a web browser launch on a portable device displaying mobile website 104 or a computing device displaying website 108. For example, financial institutions can also initiate an authentication process as discussed herein by generating a tap alert (e.g., a notification) on their phones via in-app notifications or SMS. When website 108 generates a browsing session for a user transaction, this browsing session is assigned a browsing session identifier. Information entered during the browsing session (such as the user's name, delivery address, product identifier identifying the product to be purchased, and the like) is saved with reference to the browsing session identifier. The browsing session identifier allows merchants to quickly reactivate the user's shopping experience. A link containing the browsing session identifier can be provided to the financial institution along with the authentication request. After authentication by the financial institution's system, the user can resume the business session at website 108 or mobile website 104. For example, the authentication result can be delivered by authentication system 124 of financial institution system 118 or the like and can include the browsing session identifier and information about the user. The browsing session can be a secure or encrypted communication link. The information about the user provided by authentication system 124 can include the user's name, the user's delivery address, the user's contact information, and the like.

[0069] In one example, an encrypted authentication payload is sent to the financial institution's backend in a URL, with the expected payload contained in a message used for authentication. The encrypted authentication payload may include a version number (if multiple versions exist), a unique identifier for the individual, an application transaction counter, a one-time password, and a cipher used to verify message integrity. For example, the URL message could be structured as "www.financialinstitutionname.com / fintech1?AUTHENTICATIONMESSAGE" or similar. Upon receiving the URL message, the mobile device's OS can be operable to contact the financial institution at the URL and provide the authentication message to the financial institution's system 118. The financial institution's system 118 associated with the URL can be operable to retrieve the authentication message and authenticate the user, determine if there are any pending transactions (e.g., based on earlier notifications from website 108), and provide the information needed to complete the transaction. Alternatively, the URL message can be processed by the mobile device's OS to be sent as a text message to the financial institution's system, which can be operable to access the URL within the message. Information that can be used to complete a transaction can be provided in the merchant’s authentication response, which includes some additional PII data (which may not have been entered into the website by the user) and a possible virtual card number (VCN).

[0070] Figure 2 An exemplary operating environment according to this disclosure is described. For example... Figure 2As shown, the operating environment 200 may include a mobile / network client (e.g., a user device) 201, a service provider (e.g., a financial service provider) backend 202, and multiple third-party entity (or merchant) backends 203a-n. In some embodiments, the operating environment 100 may provide a system configured to deliver transaction cards to multiple merchants, such as via client device 201, through a single access point (e.g., an application running on a user device, such as an app operating on a user's smartphone). In various embodiments, client device 201 may have a financial service provider application installed thereon for interacting with the financial service provider (or financial service provider backend 202).

[0071] In some embodiments, the service provider backend (e.g., server) 202 may establish a trust relationship with one or more merchant backend platforms 203a-n. In a non-limiting example, the trust relationship may be or may include an authorization relationship, such as an OAuth relationship. The authorization relationship between the financial service provider and the merchant can be determined according to various processes. For example, the authorization relationship may be established via a contractual relationship or by a procedure provided to the merchant by the financial service provider. Typically, the authorization process may include authentication procedures and processes (and / or vice versa) that allow the merchant to trust the financial service provider and processes, systems, etc., that allow the financial service provider to archive its users and / or users' transaction cards (e.g., add them to the user's merchant account as a payment option).

[0072] In some embodiments, a user can establish a transaction card with a merchant via a request 220 (e.g., a payment card number request) through client device 201. For example, in response to accessing a transaction account with a financial service provider's backend 202, the user may be provided with an option or prompt to associate the transaction card with a third-party entity. In another example, for contactless cards (e.g., see...), Figures 6-13 Tapping the card onto the client device 201 may allow selection or prompt a message to add the card to a third-party entity.

[0073] In various embodiments, request 220 may include generating a VCN that will be used for a specific merchant (or set of merchants). The financial service provider backend 202 may receive request 220 and request 221 authentication. For example, request 221 may be for the financial service provider to use multi-factor authentication, upgraded authentication, and / or the like to allow the user to authenticate themselves on client device 201. For instance, a user may initiate a transaction on a website or app, but the financial service provider may seek to ensure the user's identity; therefore, the financial service provider may request 221 that the user authenticate themselves on client device 201, where the financial service provider's app is already installed. The financial service provider may have trust / authentication of client device 201 and may have various policies required to process transaction card requests (e.g., 7 days without password or phone number changes, 7-day device stability, etc.) to ensure that the financial service provider trusts client device 201.

[0074] If authentication (e.g., upgrade authentication) is confirmed 222, then the financial service provider backend 202 can grant 224 a token for data retrieval. In some embodiments, confirmation 222 may occur via an authentication / password process for a contactless card configured according to various embodiments (see, for example, see...). Figures 6-13 ).

[0075] In some embodiments, the financial service provider backend 202 may provide a token for this transaction to the merchant 203a-n. In some embodiments, the token may identify a communication session established with the merchant. If the merchant 203a-n agrees to proceed with account setup (or add a transaction card to an existing merchant account), the merchant 203a-n may return the token and an affirmative response 225 to retrieve details of this particular user, thereby opening a new account or updating an existing account with the new card number. In some embodiments, the token may operate as a header to uniquely identify the transaction when multiple requests are made from and from the two backends 202, 203a-n.

[0076] Exchanges of account information 225 may occur between the financial service provider backend 202 and the merchant backends 203a-n. For example, in exchange 2230, the merchant backend 203a-n may indicate to the financial service provider backend 202 whether an account exists at that merchant. If a match determined for the user (e.g., via a matching account number, email address, phone number, and / or the like) is found and an account exists, transaction card information (e.g., VCN and / or card number, CCV, expiry date, and / or the like) may be shared in future exchanges 225 (and / or 226). In various embodiments, if no match is found, a new account may be created and exchange 225 may involve more account creation information (e.g., name, address, phone number, email address, and / or the like) that may be needed before the card information is shared, which may require multiple steps / exchanges 225.

[0077] Once an account has been established (or located or created), the merchant backend 203a-n can make a call to retrieve information 226, such as PII, PCI data, and / or the like. PCI data may or may include VCN and / or card number, CCV, expiry date, and / or the like. Exchanges 225 and / or 226 can satisfy the transaction with a minimal amount of information. For example, if an account is found in exchange 225, there is no need to exchange the PII, and only card information can be shared; however, if no account is found, the PII may be shared in addition to the transaction card information.

[0078] Figure 3 An exemplary operating environment according to this disclosure is described. For example... Figure 3 As shown, the operating environment 300 may include a business client 301, an OAuth server 302, and a resource server 303. In some embodiments, the operating environment 300 may operate to perform an authentication process, thereby performing the functions described in this disclosure. Although Figure 3 An OAuth server is described, but the embodiments are not limited thereto, as an OAuth server can operate as an authentication server using various known authentication protocols other than OAuth authentication, which can be operated using the described embodiments.

[0079] Business client 301 may request an access token from OAuth server 302 at step 320. OAuth server 302 may perform various authentication processes, such as verifying business client 301 (321) and / or obtaining user consent (322). In response to verification (321) and consent (322), OAuth server 302 may return an access token to business client 301 at step 323. Business client 301 may request resources from resource server 303 at step 324. In various embodiments, the request may include the token returned from OAuth server 302 to business client 301 at step 323. Resource server 303 may operate to verify (325) the token provided by business client 301 to OAuth server 302. If the token is valid at step 326, as indicated by OAuth server 302 to resource server 303, resource server 303 may return resources to business client at step 327.

[0080] The one or more logical flows included herein represent exemplary methods for performing novel aspects of the disclosed embodiments. Although, for simplicity of explanation, the one or more methods shown herein are illustrated and described as a series of actions, those skilled in the art will understand and recognize that the method is not limited to the order of actions. Accordingly, some actions may occur in a different order and / or concurrently with other actions shown and described herein. For example, those skilled in the art will understand and recognize that the method may alternatively be represented as a series of related states or events, such as in a state diagram. Furthermore, not all actions shown in a method are necessary for the novel implementation. Blocks designated by dashed lines may be optional blocks of the logical flow.

[0081] This logical flow can be implemented in software, firmware, hardware, or any combination thereof. In software and firmware embodiments, the logical flow can be implemented by computer-executable instructions stored on a non-transitory computer-readable medium or a machine-readable medium. Embodiments are not limited in this context.

[0082] Figure 4 An embodiment of logic flow 400 is illustrated. Logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein, such as operating environments or systems 100-300 and / or components thereof. In some embodiments, logic flow 400 may represent some or all of the operations for providing transaction cards to multiple third-party entities according to some embodiments.

[0083] At box 402, logic flow 400 can establish an authorization relationship between the financial service provider and a third-party entity. For example, the financial service provider backend 202 can establish an authorization relationship, such as an OAuth relationship, with one or more merchants. The authorization relationship can allow the financial service provider to access the merchant's user accounts or interact with the merchant to update (or allow the merchant to update) user accounts using information provided by the financial service provider, such as user accounts shared by both the financial service provider and the merchant.

[0084] At box 404, logic flow 400 may receive a request to provide a transaction card to a third-party entity. This request may be a payment card number request. For example, a user may have a credit card from a financial service provider and wish to associate it with a merchant as a payment source. The user can access their financial service provider account (e.g., via an online platform, app, and / or the like) and submit a provision request through the financial service provider's platform. In some embodiments, the request may include a transaction card (or card) and a selection of the third-party entity to which the transaction card is to be provided. The request may include additional request information such as card priority (e.g., the transaction card should be the primary transaction card at merchant A, but a secondary card at merchant B), card usage rules (e.g., the transaction card is used for all purchases at merchant A, but only for recurring / pre-ordered purchases and / or the like at merchant B), and / or other usage specifications.

[0085] In some embodiments, a request may include multiple requests, wherein a corresponding payment card number request is received for each of a plurality of merchants (or merchant websites). In various embodiments, it may be required that the last of a plurality of payment card number requests be received within a predetermined time period following the receipt of the first payment card number request (or any prior request in a series of requests). In some embodiments, the predetermined time period may be approximately 5 minutes, approximately 10 minutes, approximately 20 minutes, approximately 30 minutes, approximately 60 minutes, or any time or range (including endpoints) between any two of these values.

[0086] Logical flow 400 can authenticate the requesting user at box 406. For example, the financial service provider backend 202 can authenticate the user via a username / password process, multi-factor authentication, upgrade authentication, OAuth process, and / or similar methods. The financial service provider backend 202 can authenticate the user, the user's device, and / or other elements associated with the requesting user.

[0087] At box 408, logic flow 400 can establish a connection between a financial service provider and a third-party entity. For example, the financial service provider backend 202 can establish a network connection with one or more merchant backends 203a-n. In some embodiments, the financial service provider backend 202 and the merchant backends 203a-n can have dedicated communication channels for facilitating the provision of transaction cards.

[0088] At box 410, logic flow 400 can operate to authenticate user accounts using a third-party entity. For example, the financial service provider backend 202 (either independently or via prompts / exchanges with client device 201) can provide account information to the merchant backends 203a-n to allow them to locate the user account associated with the provision request. For instance, the financial service provider backend 202 can request merchant account information from a user or request the user to log in to their merchant account (including via a merchant interface outside or within the financial service provider platform, such as an interface identical or similar to the PayPal® login interface, to process payments within the merchant platform). In another example, the financial service provider backend 202 can store merchant authentication information in the financial service provider's user account, for example, during the registration process of registering a merchant as a supply entity. In a further example, if the merchant does not have a user account, the financial service provider backend 202 can facilitate the creation of a new account for the merchant.

[0089] At box 412, logic flow 400 may provide transaction card information to a third-party entity. For example, in response to authentication of the user (and / or user device) and a user account established by the financial service provider at the merchant (newly created or pre-existing), verified by the financial service provider (including through confirmation by the merchant backend 203a), the financial service provider backend 202 may provide transaction card information to the third-party entity. Transaction card information may include information sufficient for the user to use the card through the merchant, such as cardholder name, cardholder address, VCN and / or card number, expiry date, CVV and / or similar.

[0090] Logical flow 400 can update the user account at box 414. For example, the merchant backend 203a-n can use the merchant system to update the user account to include the transaction card as the payment source.

[0091] Figure 5 An embodiment of logic flow 500 is illustrated. Logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein, such as operating environments or systems 100-300 and / or components thereof. In some embodiments, logic flow 500 may represent some or all of the operations for providing transaction cards to multiple third-party entities according to some embodiments.

[0092] At box 502, logic flow 500 may receive multiple payment card number requests from the user device at the financial institution's server, wherein the corresponding payment card number request is received for each of the multiple merchant websites. For example, client device 201 may submit a request (which may or may include request 220) to the financial service provider's backend 202.

[0093] At box 504, logic flow 500 can send a contactless payment card upgrade authentication request to the user device. This request is a request for interaction between the user's mobile device and a contactless payment card associated with the user's financial institution account. For example, the financial service provider backend 202 can send a request 221 to the client device 201 for authentication, such as multi-factor or "upgrade" authentication.

[0094] At box 506, logic flow 500 may, in response to a contactless payment card upgrade request, receive encrypted authentication information obtained from the contactless payment card from the user's mobile device (see, for example, see...). Figures 6-13 At box 508, logic flow 500 can authenticate encrypted authentication information received from the user's mobile device. For example, the encrypted authentication information can be obtained via an authentication / password process for a contactless card configured according to various embodiments (see, for example, [link to relevant documentation]). Figures 6-13 ).

[0095] At box 510, logic flow 500 can, based on successful authentication, grant a corresponding token to each of the multiple merchants, wherein each of the granted corresponding tokens identifies the corresponding communication session established with each corresponding merchant and enables continuous data exchange with each corresponding merchant.

[0096] At box 512, logic flow 500 can use each corresponding token to identify the corresponding communication session established with each corresponding merchant, and provide account information to each corresponding merchant as needed to associate the corresponding merchant account with the user of the contactless payment card.

[0097] Figure 6This is a schematic diagram 600 illustrating an example configuration of a contactless card 611, which may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider whose service provider mark 602 is displayed on the front or back of the contactless card 611. In some examples, the contactless card 611 is not a payment card and may include, but is not limited to, an identity card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 611 may include a substrate 604, which may include a single layer or one or more laminates composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 611 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 611 according to this disclosure may have different characteristics, and this disclosure does not require the transaction card to be implemented in a payment card.

[0098] The contactless card 611 may also include identification information 606 displayed on the front and / or back of the card, and a contact pad 608. The contact pad 608 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user equipment, smartphone, laptop, desktop computer, or tablet computer) via the transaction card. The contact pad may be designed according to one or more standards, such as the ISO / IEC 7816 standard, and enable communication according to the EMV protocol. The contactless card 611 may also include processing circuitry, an antenna, and [other components]. Figure 7 Other components are discussed further below. These components may be located behind the contact pad 608 or elsewhere on the substrate 604 (e.g., within different layers of the substrate 604) and may be electrically and physically coupled to the contact pad 608. The contactless card 611 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card. Figure 6 (Not shown in the image). The contactless card 611 may also include a near-field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. The embodiments are not limited in this manner.

[0099] like Figure 7As shown, the contact pad 608 of the contactless card 611 may include processing circuitry 710 for storing, processing, and communicating information, which includes a processor 712, a memory 784, and one or more communication interfaces 724. It should be understood that the processing circuitry 710 may include additional components, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as required to perform the functions described herein.

[0100] Memory 784 can be a read-only memory, a write-once-read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 611 may include one or more of these memories. Read-only memory can be programmed by the manufacturer to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read multiple times. Write-once / read-many memory can be programmed at some point after the memory chip has left the factory. Once programmed, the memory cannot be rewritten but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can also be read multiple times after leaving the factory. In some instances, memory 784 can be encrypted memory that uses an encryption algorithm executed by processor 712 to encrypt data.

[0101] Memory 784 can be configured to store one or more applets 110, one or more counters 772, a unique ID 773, a master key 775, a UDK 774, a master key 776, and a PAN sequence 777. One or more applets 771 may include one or more software applications, such as the Java® Card applet, configured to execute on one or more contactless cards 611. However, it should be understood that applet 771 is not limited to the Java Card applet, but can be any software application operable on a contactless card or other device with limited memory. One or more counters 772 may include numeric counters sufficient to store integers. The unique ID 773 may include a unique alphanumeric identifier assigned to the contactless card 611, and this identifier can distinguish the contactless card 611 from other contactless cards 611. In some examples, the unique ID 773 may identify both the customer and the account assigned to that customer.

[0102] The processor 712 and memory elements of the foregoing exemplary embodiments are described with reference to contact pad 608, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of or completely separated from contact pad 608, or implemented as additional elements besides the processor 712 and memory 784 elements located within contact pad 608.

[0103] In some examples, the contactless card 611 may include one or more antennas 714. The one or more antennas 714 may be placed within the contactless card 611 and around the processing circuitry 710 of the contact pad 608. For example, the one or more antennas 714 may be integrated with the processing circuitry 710, and the one or more antennas 714 may be used in conjunction with an external boost coil. As another example, the one or more antennas 714 may be external to the contact pad 608 and the processing circuitry 710.

[0104] In an embodiment, the coil of the contactless card 611 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 611 by cutting off power or by amplitude modulation. The contactless card 611 can infer data transmitted from the terminal using gaps in its power connection, which can be functionally maintained by one or more capacitors. The contactless card 611 can communicate in reverse by switching the load or load modulation on its coil. Load modulation can be detected in the terminal's coil by interference. More generally, using an antenna 714, a processor 712, and / or a memory 784, the contactless card 611 provides a communication interface for communication via NFC, Bluetooth, and / or Wi-Fi.

[0105] As explained above, the contactless card 611 can be built on a software platform operable on a smart card or other device with limited memory, such as a JavaCard, and one or more applications or applets can be securely executed. An applet 771 can be added to the contactless card to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. The applet 771 can be configured to respond to one or more requests (such as a near-field data exchange request) from a reader (such as a mobile NFC reader, e.g., a mobile computing device 102 or a point-of-sale terminal) and generate an NDEF message that includes a password-secured OTP encoded as an NDEF text tag. This NDEF message may include a password or any other data.

[0106] An example of NDEF OTP is the NDEF short record layout (SR=1). In such examples, one or more applets 771 can be configured to encode the OTP as NDEF type 4, which is a well-known type of text tag. In some examples, the NDEF message may include one or more records. The applet 771 can be configured to add one or more static tag records in addition to the OTP record.

[0107] In some examples, one or more applets 771 can be configured to emulate RFID tags. The RFID tag may include one or more polymorphic tags. In some examples, different cipher data is presented each time the tag is read, and this data can indicate the reliability of the contactless card. Based on one or more applets 110, NFC readings of the tag can be processed, the data can be transmitted to a server, such as a banking system server, and the data can be verified at the server.

[0108] In some examples, the contactless card 611 and the server may include data that allows the card to be correctly identified. The contactless card 611 may include one or more unique identifiers (not shown). A counter 772 may be configured to increment each time a read operation occurs. In some examples, each time data is read from the contactless card 611 (e.g., via a mobile device), the counter 772 is sent to the server for verification and to determine whether the counter 772 equals (as part of the verification) the server's counter.

[0109] One or more counters 772 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 772 has been read, used, or otherwise ignored. If counter 772 has not yet been used, it can be replayed. In some examples, the counter incremented on the contactless card 611 is different from the counter incremented for a transaction. The contactless card 611 cannot determine the application of the transaction counter 772 because there is no communication between the applets 772 on the contactless card 611. In some examples, the contactless card 611 may include a first applet 440-1 and a second applet 440-2, where the first applet 440-1 may be a transaction applet. Each applet 440-1 and 440-2 may include a corresponding counter 772.

[0110] In some examples, counter 772 may be out of sync. In some examples, to account for unexpected reads that initiate a transaction, such as reads at an angle, counter 772 may increment, but the application does not process counter 772. In some examples, when device 102 is woken up, NFC may be enabled and computing device 102 may be configured to read available tags, but no action is taken in response to the read.

[0111] To keep counter 772 synchronized, an application, such as a background application, can be executed. This application would be configured to detect when computing device 102 wakes up and synchronize with the bank system's server to indicate reads that have occurred due to the detection, then move counter 772 forward. In other examples, a hashed one-time password can be used to allow for windows of erroneous synchronization. For example, if it is within a threshold of 10, counter 772 can be configured to move forward. However, if it is within a different threshold number, such as 10 or 600, requests for resynchronization can be processed, which are requested by one or more applications via a tap, gesture, or other indication from the user on the user's device, one or more times. If counter 772 increments in the appropriate order, then it can be known that the user has done so.

[0112] The key diversification technique described herein with reference to counter 772, master key 775, UDK 774, and diversification key 776 is an example of encryption and / or decryption techniques in key diversification. This example key diversification technique should not be considered as a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0113] During the creation process of the contactless card 611, each card can be uniquely assigned two cryptographic keys. These cryptographic keys can include symmetric keys that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware within the contactless card 611. Through a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity requiring a key.

[0114] In some examples, to overcome the vulnerabilities of the 3DES algorithm, which can be susceptible to exploits, session keys (such as a unique key for each session) can be derived. However, instead of using a master key, a unique card-derived key (e.g., UDK 774) and a counter can be used as diversification data. For example, each time the contactless card 611 is used in operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. This results in three layers of cryptography. Session keys can be generated by one or more applets and derived using an application transaction counter with one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0115] Furthermore, the increment for each card can be unique and assigned either through personalization or algorithmically through some identifying information. For example, odd-numbered cards can increment by 2, and even-numbered cards can increment by 5. In some examples, the increment can also vary in the order of reading, allowing a card to increment in a repeating sequence of 1, 3, 5, 2, 2, ... The specific order or algorithmic order can be defined during personalization or in one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0116] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format.

[0117] Figure 8 This is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. Sequence stream 800 may include a contactless card 611 and a client device, which may include an application 802 and a processor 804.

[0118] At point 812, application 802 communicates with contactless card 611 (e.g., after being brought near contactless card 611). Communication between application 802 and contactless card 611 may include: contactless card 611 being sufficiently close to a card reader (not shown) of client device 804 to enable data transfer (e.g., via NFC) between application 802 and contactless card 611.

[0119] At point 810, after communication is established between client device 804 and contactless card 611, contactless card 611 generates a Message Authentication Code (MAC) cipher. In some examples, this can occur when application 802 reads contactless card 611. Specifically, this can occur when reading (e.g., NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a reader application such as application 802 can transmit messages such as an app selection message with an app ID that generates the app's NDEF. After confirming the selection, a file selection message can be transmitted, followed by a sequence of file read messages. For example, the sequence could include "select function file," "read function file," and "select NDEF file." At this point, a counter value maintained by contactless card 611 can be updated or incremented, followed by "read NDEF file." At this point, a message that may include a header and a shared secret can be generated. A session key can then be generated. A MAC cipher can be created from the message, which may include a header and a shared secret. The MAC cipher can then be concatenated with one or more blocks of random data, and the MAC cipher and random number (RND) can then be encrypted using a session key. Afterward, the cipher and header can be concatenated, encoded into ASCII hexadecimal, and returned in NDEF message format (in response to a "Read NDEF file" message).

[0120] In some examples, the MAC PIN may be transmitted as an NDEF tag, and in other examples, the MAC PIN may be included as a Uniform Resource Indicator (e.g., as a formatted string). In some examples, application 802 may be configured to transmit a request to contactless card 611 that includes instructions for generating the MAC PIN.

[0121] At line 814, contactless card 611 sends the MAC password to application 802. In some examples, the transmission of the MAC password occurs via NFC; however, this disclosure is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi, or other wireless data communication methods. At line 812, application 802 communicates the MAC password to processor 804.

[0122] At point 816, processor 804 verifies the MAC cipher according to instructions from application 132. For example, the MAC cipher can be verified as explained below. In some examples, MAC cipher verification can be performed by a device other than client device 804, such as a server in a banking system that communicates data with client device 804. For example, processor 804 can output the MAC cipher for transmission to the server in the banking system, which can verify the MAC cipher. In some examples, the MAC cipher can be used as a digital signature for verification purposes. Other digital signature algorithms, such as public-key asymmetric algorithms like the Digital Signature Algorithm and RSA, or zero-knowledge protocols, can be used to perform this verification.

[0123] Figure 9 A short record layout (SR=1) data structure 900 for NDEF according to an example embodiment is shown. One or more applets can be configured to encode OTP as NDEF type 4, which is a well-known type of text tag. In some examples, the NDEF message may include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, encoded English (en); Applet ID: D2760000850101; functionality: read-only access; encoding: the authentication message may be encoded as ASCII hexadecimal; a type-length value can be provided as a personalized parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record having a well-known index for providing the actual dynamic authentication data.

[0124] Figure 10 A diagram is shown of a system 1000 configured to implement one or more embodiments of the present disclosure. As explained below, during the contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys may include symmetric keys that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm can be used by EMV, and it is implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity that requires a key.

[0125] Regarding master key management, each part of a portfolio to which one or more applets are published may require two issuer master keys 1002 and 1026. For example, the first master key 1002 may include an issuer password generation / authentication key (Iss-Key-Auth), and the second master key 1026 may include an issuer data encryption key (Iss-Key-DEK). As further explained herein, the two issuer master keys 1002 and 1026 are diversified into card master keys 1008 and 1020, which are unique to each card. In some examples, the network profile record ID (pNPR) 522 and / or derived key index (pDKI) 1024, as background data, can be used to identify which issuer master keys 1002 and 1026 are to be used in the password process for authentication. The system performing authentication can be configured to retrieve the values ​​of pNPR 1022 and pDKI 1024 for the contactless card during authentication.

[0126] In some examples, to improve the security of the solution, session keys (such as a unique key for each session) can be derived. However, instead of using a master key, it is better to use a unique card-derived key and counter as diversification data, as explained above. For example, each time the card is used in an operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. Regarding session key generation, the key used to generate passwords and encrypt data in one or more applets can include session keys based on the card's unique key (Card-Key-Auth 1008 and Card-Key-Dek 1020). Session keys (Aut-Session-Key 1032 and DEK-Session-Key 1010) can be generated by one or more applets and derived using an Application Transaction Counter (pATC) 1004 and one or more algorithms. To fit the data into one or more algorithms, only the two lower-order bytes of the 4-byte pATC 1004 are used. In some examples, the four-byte session key derivation method may include: F1:= PATC (lower 2 bytes) || 'F0' || '00' || PATC (4 bytes) F1:= PATC (lower 2 bytes) || '0F' || '00' || PATC (4 bytes) SK:={(ALG(MK) [F1] ) || ALG (MK) [F2]}, where ALG may include 3DES ECB and MK may include the card-uniquely derived master key.

[0127] As described in this document, one or more MAC session keys can be derived using the lower two bytes of the pATC 1004 counter. The pATC 1004 is configured to be updated with each tap of the contactless card, and the card master keys Card-Key-AUTH 508 and Card-Key-DEK 1020 are further diversified into session keys Aut-Session-Key 1032 and DEK-Session-KEY 1010. The pATC 1004 can be initialized to zero at personalization or applet initialization time. In some examples, the pATC counter 1004 can be initialized during or before personalization and can be configured to increment by 1 with each NDEF read.

[0128] Furthermore, updates for each card can be unique and assigned either through personalization or algorithmically through pUID or other identifying information. For example, odd-numbered cards can increment or decrement by 2, and even-numbered cards can increment or decrement by 5. In some examples, the increment can also vary in the order of reading, allowing a card to increment in a repeating sequence of 1, 3, 5, 2, 2, ... The specific order or algorithmic order can be defined during personalization or in one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0129] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may consist only of authentication data and an 8-byte random number followed by the MAC. In some examples, the random number may precede the password A and can be a block length. In other examples, there may be no limit to the length of the random number. In further examples, the total data (i.e., the random number plus the password) may be a multiple of the block size. In these examples, an additional 8-byte block can be added to match the block generated by the MAC algorithm. For example, if the algorithm used employs a 16-byte block, an even multiple of the block size can be used, or the output can be automatically or manually padded to a multiple of that block size.

[0130] MAC can be performed using the function key (AUT-Session-Key) 1032. The data specified in the cipher can be processed using the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 to be associated with the EMV ARQC verification method. The key used for this calculation can include the session key AUT-Session-Key 1032, as explained above. As explained above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As explained below, AUT-Session-Key 1032 can be used for MAC data 1006, and the resulting data or cipher A 1014 and random number RND can be encrypted using DEK-Session-Key 1010 to create cipher B or output 1018 sent in the message.

[0131] In some examples, one or more HSM commands can be processed for decryption, such that the final 16 bytes (binary, 32-byte hexadecimal) can include 3DES symmetric encryption using CBC mode, where the zero IV of the random number is followed by MAC authentication data. The key used for this encryption can include a session key DEK-Session-Key 1010 derived from Card-Key-DEK 1020. In this case, the ATC value used for deriving the session key is the least significant byte of the counter pATC 1004.

[0132] The following format represents an example embodiment of the binary version. Further, in some examples, the first byte may be set to ASCII 'A'.

[0133]

[0134]

[0135] Another exemplary format is shown below. In this example, the label can be encoded in hexadecimal format.

[0136]

[0137]

[0138] The UID field of the received message can be extracted to derive the card master key (Card-Key-Auth 1008 and Card-Key-DEK 1020) for that specific card from the master keys Iss-Key-AUTH 502 and Iss-Key-DEK 1026. Using the card master key (Card-Key-Auth 508 and Card-Key-DEK 1020), the received message counter (pATC) field can be used to derive the session key (Aut-Session-Key 1032 and DEK-Session-Key 1010) for that specific card. Password B 1018 can be decrypted using DEK-Session-KEY, which produces password A 1014 and RND, and the RND can be discarded. The UID field can be used to find the shared secret of the contactless card. This shared secret, along with the message version, UID, and pATC fields, can be processed using the MAC password with a recreated Aut-Session-Key to create a MAC output, such as 'MAC'. If 'MAC' is the same as the MAC password A 1014, this indicates that message decryption and MAC checks have both passed. The pATC can then be read to determine its validity.

[0139] During the authentication session, one or more passwords may be generated by one or more applications. For example, one or more passwords may be generated as a 3DES MAC using ISO 9797-1 algorithm 3 with method 2 padding via one or more session keys (such as Aut-Session-Key 1032). Input data 1006 may take the form of: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include a length in bytes. In some examples, the shared secret may be generated by one or more random number generators that may be configured to ensure that the random numbers are unpredictable through one or more security processes. In some examples, the shared secret may include a random 4-byte binary number injected into the card at a personalized time known to the authentication service. During the authentication session, the shared secret may not be provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte to the end of the input data, and adding 0x'00' bytes that may be added to the end of the resulting data up to an 8-byte boundary. The resulting password may include 8 bytes in length.

[0140] In some examples, one benefit of encrypting an unshared random number as the first block along with the MAC cipher is that it acts as an initialization vector when using the CBC (Block Chaining) mode of a symmetric encryption algorithm. This allows for block-to-block "scrambling" without having to pre-establish fixed or dynamic IVs.

[0141] By including the Application Transaction Counter (pATC) as part of the data included in the MAC cipher, the authentication service can be configured to determine whether the value conveyed in the plaintext data has been tampered with. Furthermore, by including the version in one or more ciphers, it is difficult for an attacker to intentionally distort the application version to attempt to weaken the strength of the cipher solution. In some examples, the pATC can start from zero and be updated to 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC equal to or less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated message can be rejected. In some examples, when the pATC is greater than a previously received value, this can be estimated to determine if it is within an acceptable range or threshold, and if it exceeds the range or threshold or is outside of it, the verification can be considered a failure or unreliable. In MAC operation 1012, data 1006 is processed via MAC using the Aut-Session-Key 1032 to produce an encrypted MAC output (cipher A) 1014.

[0142] To provide additional protection against brute-force attacks on the exposed key, MAC cipher 1014 is expected to be encrypted. In some examples, the data or cipher A 1014 to be included in the ciphertext may include: a random number (8) and a cipher (8). In some examples, the number in parentheses may include a length in bytes. In some examples, the random number may be generated by one or more random number generators that can be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include DEK-Session-Key 1010. In encryption operation 1016, the data or cipher A 1014 and RND are processed using DEK-Session-Key 510 to produce encrypted data, namely cipher B 1018. Cipher 1014 may be encrypted using 3DES in ciphertext block chaining mode to ensure that an attacker must run any attack within all the ciphertext. As a non-limiting example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000000' can be used. Any attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key has been used, because due to its random appearance, correctly decrypted data will be indistinguishable from incorrectly decrypted data.

[0143] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile device during the authentication session: version number, used to determine the cipher method used and the message format used to verify the password, which allows the method to be changed in the future; pUID, used to retrieve the cipher asset and derive the card key; and pATC, used to derive the session key used for the cipher.

[0144] Figure 11 A method 1100 for generating a password is illustrated. For example, at box 1102, the Network Profile Record ID (pNPR) and Derived Key Index (pDKI) can be used to identify which issuer master keys are used for authentication during the encryption process. In some examples, the method may include performing authentication to retrieve the values ​​of the pNPR and pDKI for the contactless card during authentication.

[0145] At box 1104, the issuer master key can be diversified by combining the issuer master key with the card unique ID (pUID) and PAN serial number (PSN) of one or more mini-apps (e.g., payment mini-apps).

[0146] At box 1106, Card-Key-Auth and Card-Key-DEK (unique card key) can be created by diversifying the issuer master key to generate a session key (which can be used to generate a MAC password).

[0147] At box 1108, the key used to generate the password and encrypt data in one or more applets may include the session keys from box 1030, which are based on the card-unique keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and derived using pATC to produce session keys Aut-Session-Key and DEK-Session-Key.

[0148] Figure 12 An exemplary process 1200 illustrating key diversification according to one example is depicted. Initially, the sender and receiver may be equipped with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value that can be updated at box 1202, as well as other data that can be securely shared with the receiver, such as data to be protected.

[0149] At box 1204, the counter value can be encrypted by the sender using the data encryption master key to generate a data encryption-derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to generate a data integrity-derived session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryption processes.

[0150] In some examples, the counter value may not be encrypted. In these examples, the counter value can be transmitted between the sender and receiver in plaintext, that is, without encryption.

[0151] At box 1206, the data to be protected is processed using a cryptographic MAC operation by the sender using a data integrity session key and a cryptographic MAC algorithm. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0152] At box 1208, the data to be protected can be encrypted by the sender using a session key derived from the data encryption, combined with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data, for example, every 8 bytes, and then encrypted using a second session key (DEK-Session-Key).

[0153] At box 1210, the encrypted MAC, along with information sufficient to identify additional secret information (such as the shared secret, master key, etc.), is transmitted from the sender to the receiver for password verification.

[0154] At box 1212, the receiver uses the received counter value to independently derive two derived session keys from the two master keys as explained above.

[0155] At box 1214, the session key derived from the data encryption is used in conjunction with a symmetric decryption operation to decrypt the protected data. Further processing of the exchanged data then occurs. In some examples, after the MAC is extracted, it is expected that the MAC will be regenerated and matched. For example, when verifying a password, it can be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. The MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Because the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0156] At box 1216, the session key derived from data integrity is used in conjunction with the cipher MAC operation to verify that the protected data has not been modified.

[0157] Some examples of the methods described herein can advantageously confirm when successful authentication is determined when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is correct. A MAC can only be considered correct if decryption is successful and a correct MAC value is generated. Successful decryption indicates that a correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the transmitting device) and the receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed authentic. Furthermore, the counter values ​​used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

[0158] After this, the two derived session keys can be discarded, and the next iteration of the data exchange will update the counter value (returning to box 1202), and (at box 1210) a new set of session keys can be created. In some examples, the combined random data can be discarded.

[0159] Figure 13A method 1300 for card activation according to an example embodiment is shown. For example, card activation can be performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components previously explained above, such as contactless card 132, client device 134, and server.

[0160] In box 1302, the card can be configured to dynamically generate data. In some examples, this data may include information such as account number, card identifier, card verification value, or telephone number, which can be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted using the systems and methods disclosed herein.

[0161] In box 1304, one or more portions of dynamically generated data can be communicated to an application of the device via NFC or other wireless communications. For example, tapping a card near the device can allow the device's application to read one or more portions of the data associated with the contactless card. In some examples, if the device does not include an application for assisting card activation, tapping the card can guide the device or prompt the customer to download the associated application from an app store to activate the card. In some examples, the user can be prompted to gesture, place, or orient the card toward a surface of the device, such as placing it at an angle or flat on, near, or close to the surface. In response to the card's gesture, placement, and / or orienting, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0162] In box 1306, one or more portions of data can be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of data can be transmitted from the device to the card issuer server for card activation.

[0163] In box 1308, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and decrypt it to compare the received data with record data accessible to one or more servers. If a successful match is found by the comparison of one or more decrypted portions of the data by one or more servers, the card may be activated. If an unsuccessful match is found by the comparison of one or more decrypted portions of the data by one or more servers, one or more processes may occur. For example, in response to the determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, a predetermined threshold may exist, including the number of attempts by the user to activate the card. Alternatively, the user may receive notifications such as a message on his or her device indicating an unsuccessful attempt at card verification and a call, email, or text notification associated with the service to assist in card activation, or another notification such as a telephone call on his or her device indicating an unsuccessful attempt at card verification and a call, email, or text notification associated with the service to assist in card activation, or another notification such as an email on his or her device indicating an unsuccessful attempt at card verification and a call, email, or text notification associated with the service to assist in card activation.

[0164] In box 1310, one or more servers can send a return message based on successful card activation. For example, the device can be configured to receive output from one or more servers indicating that the card has been successfully activated by one or more servers. The device can be configured to display a message indicating successful card activation. Once the card has been activated, the card can be configured to stop dynamically generating data to prevent fraudulent use. In this way, the card may not be activated thereafter, and one or more servers will be notified that the card has been activated.

[0165] Figure 14 An embodiment of an exemplary computer architecture 1400 suitable for implementing the various embodiments described above is illustrated. In one embodiment, computer architecture 1400 may include or be implemented as part of computing architecture 100.

[0166] As used herein, the terms "system" and "component" are intended to refer to computer-related entities, hardware, combinations of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 1400. For example, a component can be, but is not limited to, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a process running on a computer. By way of example, an application running on a server and the server itself can both be components. One or more components may reside within an executing process and / or thread, and components may be localized on a single computer and / or distributed across two or more computers. Furthermore, components may communicatively couple with each other to coordinate operation via various types of communication media. This coordination may involve one-way or two-way exchange of information. For example, components may communicate information via a communication medium in the form of communicated signals. This information may be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages can be sent via various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0167] Computer architecture 1400 includes various general-purpose computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, and so on. However, embodiments are not limited to those implemented by computer architecture 1400.

[0168] like Figure 14 As shown, computer architecture 1400 includes computer 1412, which includes processor 1402, system memory 1404, and system bus 1406. Processor 1402 can be any of various commercially available processors. Computer 1412 can represent computing device 102 and / or server 118.

[0169] System bus 1406 provides processor 1402 with interfaces for system components, including but not limited to system memory 1404. System bus 1406 can be any type of bus architecture that can be further interconnected to memory bus (with or without a memory controller), peripheral bus, and local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 1406 via slot architecture. Example slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), card bus, (E)ISA (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and so on.

[0170] Computer architecture 1400 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and so on. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium that can be read and executed by one or more processors to enable the performance of the operations described herein.

[0171] System memory 1404 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, 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, polymer memory (such as ferroelectric polymer memory, bidirectional memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory), magnetic cards or optical cards, device arrays such as redundant array of independent disk drives (RAID), solid-state storage devices (e.g., USB storage, solid-state drives (SSDs), and any other type of storage media suitable for storing information. Figure 14 In the illustrated embodiment, system memory 1404 may include non-volatile memory 1408 and / or volatile memory 1410. The basic input / output system (BIOS) may be stored in non-volatile memory 1408.

[0172] Computer 1412 may include various types of computer-readable storage media in the form of one or more low-speed memory cells, including an internal (or external) hard disk drive 1414, a disk drive 1416 for reading from or writing to a removable disk 1418, and an optical disc drive 1420 for reading from or writing to a removable optical disc 1422 (e.g., a CD-ROM or DVD). Hard disk drive 1414, disk drive 1416, and optical disc drive 1420 may be connected to system bus 1406 via HDD interface 1424, and FDD interface 1426 and optical disc drive interface 1428, respectively. HDD interface 1424 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0173] Drives and associated computer-readable media provide volatile and / or non-volatile storage for data, data structures, computer-executable instructions, and so on. For example, multiple program modules may be stored in the drive and non-volatile 1408, as well as in the volatile 1410, including an operating system 1430, one or more applications 1432, other program modules 1434, and program data 1436. In one embodiment, one or more applications 1432, other program modules 1434, and program data 1436 may include, for example, various applications and / or components of system 100.

[0174] Users can type commands and information into computer 1412 using one or more wired / wireless input devices, such as keyboard 1438 and pointing devices (such as mouse 1440). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are typically connected to processor 1402 via input device interface 1442 coupled to system bus 1406, but can be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc.

[0175] Monitor 1444 or other types of display devices are also connected to system bus 1406 via an interface, such as via video adapter 1446. Monitor 1444 can be internal or external to computer 1412. In addition to monitor 1444, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0176] Computer 1412 can operate in a networked environment using logical connections to one or more remote computers (such as remote computer 1448) via wired and / or wireless communications. Remote computer 1448 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 1412, although only memory and / or storage device 1450 is shown for brevity. The depicted logical connections include wired / wireless connections to a local area network 1452 and / or a larger network (e.g., a wide area network 1454). Such LAN and WAN networking environments are commonplace in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks, such as the Internet.

[0177] When used in a networked environment of local area network 1452, computer 1412 connects to local area network 1452 via a wired and / or wireless communication network interface or network adapter 1456. Network adapter 1456 facilitates wired and / or wireless communication to local area network 1452, and may also include a wireless access point disposed thereon for communicating with the wireless function of network adapter 1456.

[0178] When used in a wide area network (WAN) 1454 networking environment, computer 1412 may include modem 1458, or a communication server connected to WAN 1454, or other means for establishing communication via WAN 1454, such as via the Internet. Modem 1458, which may be internal or external and wired and / or wireless, is connected to system bus 1406 via input device interface 1442. In a networking environment, program modules or portions thereof depicted relative to computer 1412 may be stored in remote memory and / or storage device 1450. It should be understood that the network connections shown are exemplary, and other means of establishing communication links between computers may be used.

[0179] Computer 1412 is operable to communicate with wired and wireless devices or entities using IEEE 802 series standards, such as wireless devices operably configured in wireless communication (e.g., IEEE 802.11 air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth. TM Wireless technologies, etc. Therefore, communication can be a predefined structure like a regular network or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide secure, reliable, and fast wireless connectivity. Wi-Fi networks can be used to interconnect computers, connect to the internet, and connect to wired networks (using IEEE 802.3 related media and functions).

[0180] As previously referenced Figures 6-13The various components of the device may include a variety of hardware components, software components, or combinations thereof. Examples of hardware components may include devices, logic devices, parts, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software components may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware and / or software components can vary based on any number of factors, such as the expected computing rate, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other related or performance constraints desired for a given implementation.

[0181] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium, representing various logic within a processor that, when read by a machine, causes machine manufacturing logic to perform the techniques described herein. This representation, referred to as an "IP core," can be stored on a tangible, machine-readable medium and provided to various clients or manufacturing facilities for loading into a manufacturing machine or processor of manufacturing logic. Some embodiments can be implemented, for example, using a machine-readable medium or article of manufacture that can store instructions or sets of instructions, which, if executed by a machine, cause the machine to perform the methods and / or operations described in the embodiments. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and can be implemented using any suitable combination of hardware and / or software. Machine-readable media or articles may include, for example, any suitable type of memory cell, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage cell, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital multifunction discs (DVDs), magnetic tape, cassette tape or the like. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0182] The components and features of the devices described above can be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Additionally, the features of the devices can be implemented, where appropriate, using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof. Note that hardware, firmware, and / or software components may be collectively or individually referred to herein as "logic" or "circuit".

[0183] It will be appreciated that the exemplary devices shown in the block diagrams described above may represent a functionally descriptive example of many potential implementations. Therefore, the division, omission, or inclusion of block functions depicted in the figures does not imply that hardware components, circuits, software, and / or elements used to implement these functions will necessarily be divided, omitted, or included in the embodiments.

[0184] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

[0185] Some implementations may be described using the expressions “one embodiment” or “embodiment” together with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearance of the phrase “in one embodiment” in various places in the specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise stated, the features described above are considered to be used in any combination. Thus, any feature discussed individually may be used in combination with each other unless it is noted that such features are incompatible with each other.

[0186] It is important to emphasize that this summary of the disclosure is provided to allow the reader to quickly determine the nature of the technical disclosure. It is understood at the time of submission that it is not intended to be construed as limiting the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features have been grouped together in a single embodiment for the purpose of simplifying the disclosure. The approach of this disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly stated in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the following claims are incorporated herein by reference, wherein each claim stands independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as concise English equivalents to the respective terms “comprising” and “wherein”. Furthermore, the terms “first,” “second,” and “third” are not intended to impose numerical requirements on their objects.

[0187] The examples of the disclosed architectures described above are included. It is certainly impossible to describe every conceivable combination of components and / or methods, but those skilled in the art will recognize that many further combinations and permutations are possible. Therefore, the novel architecture is intended to include all such changes, modifications, and variations falling within the spirit and scope of the appended claims.

[0188] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit this disclosure to the precise forms disclosed. Many modifications and variations are possible based on this disclosure. The scope of this disclosure is not intended to be limited by this detailed description, but rather by the appended claims. Future applications claiming priority to this application may claim the disclosed subject matter in different ways and may generally include any set of one or more limitations as disclosed herein or otherwise demonstrated.

Claims

1. A computer-implemented method comprising: receiving, at a financial institution server, a plurality of payment card number requests from a user device, wherein a respective payment card number request is received for each of a plurality of merchant websites; sending an authentication request to the user device, wherein the authentication request is a request for the user device to interact with a contactless payment card associated with a user financial institution account; receiving, from the user device in response to the authentication request, encrypted authentication information received from the contactless payment card; authenticating the encrypted authentication information received from the user device; based on the authentication being successful, granting a respective token to each respective merchant of the plurality of merchants, wherein each respective token of the granted respective tokens identifies a respective communication session established with each respective merchant and enables ongoing data exchange with each respective merchant; and using each respective token to identify the respective communication session established with each respective merchant, providing account information to each respective merchant as needed to associate a respective merchant account with a user of the contactless payment card.

2. The computer-implemented method of claim 1, wherein, receiving a last payment card number request of the plurality of payment card number requests within a predetermined time period.

3. The computer-implemented method of claim 2, wherein, the predetermined time period is determined based on a time of receipt of a first payment card number request of the plurality of payment card number requests.

4. The computer-implemented method of claim 2, wherein, the predetermined time period is about 5 minutes, about 10 minutes, or about 20 minutes.

5. The computer-implemented method of claim 1, wherein, receiving the plurality of payment card number requests includes establishing a secure connection with the user device.

6. The computer-implemented method of claim 5, wherein, the secure connection is established based on identification information of a user of the contactless payment card.

7. The computer-implemented method of claim 6, wherein, the identification information is received prior to receiving a first payment card number request of the plurality of payment card number requests.

8. The computer-implemented method of claim 1, wherein, authenticating the encrypted authentication information received from the user device includes: decrypting the encrypted authentication information; and confirming that information entered from the user device corresponds to decrypted authentication information accessible to the financial institution server.

9. The computer-implemented method of claim 8, wherein, authenticating the encrypted authentication information received from the user device includes, upon successful confirmation, generating an authorization to grant a respective token to each payment card number request of the plurality of payment card number requests.

10. A computer-implemented method comprising: receiving, at a financial institution server, a first payment card number request from a first merchant of a plurality of merchants from a user device to associate user financial institution account information with a first merchant account; sending a contactless payment card upgrade authentication request to the user device, wherein the contactless payment card upgrade authentication request is a request for the user device to interact with a contactless payment card associated with the user financial institution account information; receiving, from the user mobile device in response to the contactless payment card upgrade request, encrypted authentication information maintained on the contactless payment card; authenticating the encrypted authentication information received from the user device; and based on the authentication being successful, granting a first token to the first merchant, wherein the first token identifies a communication session with the first merchant and enables ongoing data exchange with the first merchant.

11. The computer-implemented method of claim 10, further comprising: use the token to identify the communication session and provide account information for the first merchant as needed to populate the first merchant account.

12. The computer-implemented method of claim 10, further comprising: receiving a second payment card number request from a second merchant; based on the authentication being successful, granting a second token to the second merchant, wherein the second token identifies a communication session with the second merchant and enables continued data exchange of user financial institution account data with the second merchant.

13. The computer-implemented method of claim 10, wherein, the token enables retrieval of data by each of the plurality of merchants.

14. The computer-implemented method of claim 10, wherein, the user financial institution account information includes a payment card number and payment card number related information of a user of the user device.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: receiving a plurality of payment card number requests from user devices, wherein, receive, for each of a plurality of merchant websites, a respective payment card number request; send, to the user device, a contactless payment card upgrade authentication request, wherein the contactless payment card upgrade authentication request is a request for the user device to interact with a contactless payment card associated with a user financial institution account; in response to the contactless payment card upgrade request, receive, from the user device, encrypted authentication information obtained from the contactless payment card; authenticate the encrypted authentication information received from the user device; based on the authentication being successful, grant a respective token to each respective merchant of the plurality of merchants, wherein each respective token granted identifies a respective communication session established with each respective merchant and enables continued data exchange with each respective merchant; and use each respective token to identify the respective communication session established with each respective merchant and provide account information to each respective merchant as needed to associate a respective merchant account with a user of the contactless payment card.

16. The computer-readable storage medium of claim 15, wherein, receive a last payment card number request of the plurality of payment card number requests within a predetermined time period.

17. The computer-readable storage medium of claim 16, wherein, the predetermined time period is determined based on a time of receipt of a first payment card number request of the plurality of payment card number requests.

18. The computer-readable storage medium of claim 16, wherein, the predetermined time period is about 5 minutes, about 10 minutes, or about 20 minutes.

19. The computer-readable storage medium of claim 15, wherein, receive the plurality of payment card number requests, the processor operable to: establish a secure connection with the user device based on identification information of the user received prior to receipt of a first payment card number request of the plurality of payment card number requests.

20. The computer-readable storage medium of claim 19, wherein, authenticate the encrypted authentication information received from the user device includes: decrypt the encrypted authentication information; confirm that information entered from the user device corresponds to the decrypted authentication information; and upon successful confirmation, generate an authorization to grant a respective token for each payment card number request of the plurality of payment card number requests.

Images