System and technique for transferring money using active links in uniform resource locators

Abstract

A payment card to mobile device tapping system is used to authenticate a user sending or requesting money from another user. When a first user taps a payment card to their device, a URL with an encrypted string is sent to the mobile device of the user receiving the money or requesting money. The mobile device of the other user launches a banking app as a result of opening the URL. The app uses the encrypted string to authenticate the first user sending or requesting money.

Description

[Technical field]

[0001] Related Applications This application claims priority to U.S. patent application Ser. No. 17 / 317,262, entitled "SYSTEMS AND TECHNIQUES TO UTILIZE AN ACTIVE LINK IN A UNIFORM RESOURCE LOCATOR TO PERFORM A MONEY EXCHANGE," filed May 11, 2021. The contents of the aforementioned application are incorporated herein by reference in their entirety. [Background technology]

[0002] There are many types of electronic payment systems that allow users to send and receive money to other users (i.e., peer-to-peer payment transactions). In theory, conventional electronic payment systems provide a convenient way to transfer money between users. However, conventional electronic payment systems have several drawbacks that often cause user frustration, confusion, and result in unsatisfactory transactions. One such drawback of conventional electronic payment systems is that electronic payment systems are typically stand-alone systems that both the sender and the recipient must subscribe to and that require the user to take several steps to complete a transaction. In some cases, the sender, the recipient, or both may need to go through a time-consuming process of setting up an account and providing confidential financial information in order to use the system to send or receive payments through another banking system. In many cases, after the initial transaction, the user rarely uses the electronic payment system.

[0003] The limited nature of conventional electronic payment systems also adds inconvenience. In particular, the standalone nature of conventional electronic payment systems typically requires a user to open a separate application dedicated to payment transactions in order to send or receive payments. The inconvenience of the standalone nature of conventional electronic payment systems may discourage users from using such systems. Thus, conventional electronic payment systems and methods suffer from several drawbacks. Summary of the Invention

[0004] Embodiments may include systems, devices, techniques, and methods including a mobile device including a display device, a processor, and a memory. The memory includes instructions that, when executed by the processor, cause the processor to receive an input to effect an electronic exchange of money with a second mobile device of a first user, present on the display device instructions to provide a contactless card on the mobile device, receive from the contactless card first data encrypted with a private key of the second user, generate a message including the first data to send to the second mobile device and including a Uniform Resource Locator (URL) that causes the second mobile device to perform authentication of the second user using the first data, communicate the message to the second mobile device, and effect an electronic exchange of money based on the authentication of the second user.

[0005] Embodiments also include systems, devices, techniques, and methods including a mobile device including an input device, a processor, and a memory. The memory includes instructions that, when executed by the processor, cause the processor to receive a message from a second mobile device including first data and including a uniform resource locator (URL) that causes the mobile device to authenticate a first user using the first data, detect an input via the input device that activates the URL, and in response to the input, launch an application that communicates with a server and authenticates the first user using the first data, receive an indication that the first user has been authenticated by the server, and effect an exchange of money based on the first data and the indication that the first user has been authenticated.

[0006] Embodiments also include systems, devices, techniques, and methods including a computer-implemented method that includes detecting, by a processor of a first mobile device associated with a first user, a request to transfer money to a second user of a second mobile device, requesting, via a prompt on a display device, the first user associated with the first user device to tap a contactless card on the first user device, receiving from the contactless card first data encrypted with a private key associated with the first user, further including the first data for transmission to the second user device, generating a text message including a Uniform Resource Locator (URL) that causes the second mobile device to perform authentication of the first user using the first data, communicating the message to the second mobile device, receiving an indication from the second mobile device indicating that the first user has been authenticated, and exchanging information with the second mobile device to transfer money. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example of a system 100 according to embodiments described herein. [Diagram 2] FIG. 1 illustrates a subject matter aspect according to an embodiment. [Diagram 3] FIG. 3 illustrates a routine 300 according to an embodiment described herein. [Figure 4] FIG. 4 illustrates a routine 400 according to an embodiment described herein. [Diagram 5] 1 is a diagram showing a contactless card 500 according to an embodiment. [Figure 6] FIG. 6 illustrates a transaction card component 600 according to an embodiment. [Figure 7] FIG. 7 is a diagram showing a sequence flow 700 according to the embodiment. [Figure 8] FIG. 8 is a diagram of a key system 800 according to an embodiment. [Figure 9] FIG. 9 is a diagram of an example of a flowchart 900 for generating ciphertext according to an embodiment. [Figure 10] FIG. 1 is a diagram showing an example of a flowchart 1000 according to an embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of 1100 according to an embodiment. [Figure 12] FIG. 12 illustrates a computer architecture 1200 according to one embodiment. [Figure 13] FIG. 13 illustrates a communication architecture 1300 according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The embodiments described herein may generally relate to devices, systems, and techniques that enable users to give and receive money in a secure and streamlined manner. For example, a user using a mobile device may send money to another user via the mobile device. The transfer may be performed by the sender interacting with a banking application on the mobile device. Specifically, the banking application may allow a user to enter a person or contact, enter an amount, and send money to the specific person or contact. The sender's banking application may generate a message that includes information identifying the sender and the amount. The message may be sent to the recipient's mobile device to initiate the transfer. In some cases, the message may include a Uniform Resource Locator (URL) with embedded information. The URL may be invoked by the recipient to automatically launch the banking application on the recipient's mobile device to authenticate the sender and perform the transfer.

[0009] As explained in more detail in the following description, the technology is more secure and streamlined than previous solutions because it utilizes a contactless card that contains secure data associated with the sender to authenticate the sender. The secure data can be embedded in a URL and sent to the recipient's mobile device in a message. The recipient's mobile device can authenticate the sender either locally or remotely via a server and then proceed to effect the transaction based on the results of the authentication process.

[0010] Furthermore, the transfer can be performed with a minimal number of actions performed by the sender and the recipient. For example, the sender can select or enter contacts, enter the amount, and tap a contactless card on a mobile device to perform the transfer. The recipient can read the message and activate a URL to confirm the transfer of money. The transfer can be performed based on actions performed by the sender's mobile device, the recipient's mobile device, and the banking system or a third party system. More details are provided in the following description.

[0011] 1 illustrates an example of a system 100 for performing operations discussed herein, including enabling users to send and receive money via mobile devices. The illustrated system 100 includes a limited number of components and devices for purposes of illustration. In an embodiment, the system 100 includes any number of servers, devices, networking equipment, etc. that enable any number of users to send money to other users via their devices.

[0012] 1, system 100 includes mobile device 102, mobile device 104, and system 106, all of which may be coupled via a network 108, such as the Internet. Examples of mobile devices may include cellular telephones, personal digital assistants, tablet computers, etc., and communicate according to cellular protocols, wireless protocols, etc. In one example, a mobile device may include a housing made of a material such as metal or plastic, and may include components such as one or more processors, memory, storage, input devices (e.g., touch screen interfaces, buttons, sensors, microphones, etc.), output devices (e.g., displays, speakers, vibrating devices, haptic devices, etc.), short-range communication radios, antennas, etc.

[0013] In the illustrated example, mobile device 102 can communicate with mobile device 104 over network 108, and vice versa. In some cases, mobile devices can communicate with each other over other networks, such as local area networks, wireless local area networks, wide area networks, etc. Mobile devices may also establish secure point-to-point (P2P) or direct connections between each other. P2P or direct connections can be established utilizing protocols such as, for example, Bluetooth Low Energy (BLE), Bluetooth, Wireless Fidelity (WiFi), HaLow (IEEE 802.11ah), Z-wave, or Zigbee.

[0014] In an embodiment, a mobile device includes software such as an operating system and applications or apps. The operating system may be any type of operating system, such as ANDRIOD®, IOS®, or WINDOWS®, and may manage the hardware, software resources of the mobile device and provide services to other applications. Applications may be software applications designed to run on the mobile device and provide services and experiences to the user. Examples of applications include productivity applications, such as email applications, messaging applications, phone applications, contact databases, calendar applications, etc. Other applications may include gaming applications, map applications, location-based services, etc.

[0015] In the embodiments described herein, the mobile device may also include a banking application associated with one or more bank accounts to provide banking services to the user, including enabling users to send / receive money to each other. The banking application may also provide additional banking services, e.g., account management, bill payment, account auditing, etc. At a high level, the banking application may provide banking services by presenting information to the user on one or more graphical user interface (GUI) displays, processing user input and selections, communicating with other applications, communicating with one or more back-end systems (bank servers) and services, etc.

[0016] The mobile devices 102 and 104 may also be coupled to a system 106 via a network 108. The system 106 may include one or more servers or computing devices and may provide one or more services for a mobile application to send / receive money. In one example, the system 106 may be a banking system that performs authentication operations to authenticate a user requesting to send money to another user or requesting money from another user. The system 106 may also provide additional services, such as general banking services, account management, payment services, etc. The embodiments are not so limited. In some cases, the system 106 may process the transfer of money between the mobile devices 102 and 104. For example, the system 106 may electronically deduct money from a sender's account and electronically add money to a recipient's account. In some cases, the sender may be associated with a first banking system and the recipient may be associated with a second banking system. The banking systems may transmit data to each other to coordinate the transfer of money. In the following description, FIG. 2 shows additional details of utilizing the system 100 to perform a money transfer.

[0017] 2 is an example of a sequence diagram 200 that may be implemented in the system 100 to send money from a first mobile device 102 to a second mobile device 104. Note that FIG. 2 illustrates one possible sequence, and in some embodiments, one or more operations may occur before, after, and simultaneously with other operations. Also, as described in more detail below, a user may request money from another user.

[0018] At 202, the mobile device 102 may present one or more GUI displays where the user enters information to send (or request) money. Specifically, a mobile device 102 including a mobile application, such as a banking application or a web browser, presents one or more GUI displays. The displays may allow the user to interact, e.g., make selections, navigate options and menus, and perform actions. The GUI displays may include any type of input elements, e.g., input fields, drop-down menus, touch-based menus or buttons, etc., and the mobile device 102 processes user input detected by an input device, e.g., buttons, scroll wheels, touch screen interfaces, etc. In the illustrated example, the banking application presents an area where the user enters contact information and amounts. The text fields may include features such as auto-fill, suggestions, and accept contacts in several formats, e.g., email addresses, phone numbers, usernames, etc. The embodiments are not limited to the particular GUI displays illustrated, and the displays may be in another format. For example, the banking application may provide a list of contacts from a contact database on the mobile device 102. In some cases, the list may be ordered based on criteria such as frequency of use, closest contacts, friends versus family, etc. In some cases, the mobile application may present two or more GUI displays, for example, a first GUI display (or page) for entering contacts and a second GUI display for entering an amount. As noted above, in some cases, a user may request money from another user. In these examples, the user may be presented with a similar GUI display, however, the GUI display provides an indication that the user is requesting money rather than sending money.

[0019] At 202, a user may select or input a contact and provide an amount to send (or request). The mobile device 102 may process the input to determine a device associated with the selected contact, e.g., the mobile device 104. The mobile device 102 performs an authentication operation to authenticate the user to send or request money. In the illustrated example, the mobile device 102 performs the authentication utilizing a contactless card associated with the user.

[0020] At 204, the mobile device 102 including the banking application can present a GUI display instructing the user to tap the card on the mobile device 102. In some cases, the GUI display can instruct the user to tap the card on a particular surface, e.g., the display or back of the mobile device 102. Tapping the card on the mobile device 102 initiates an exchange of data between the mobile device 102 and the card. Both the mobile device 102 and the contactless card 500 communicate with each other utilizing a short-range communication protocol. For example, the contactless card and the mobile device 102 can perform one or more Near Field Communication (NFC) exchanges. As part of the exchange, the contactless card 500 can transmit information and data to the 102 that can be used to authenticate the user. For example, at 206, the 500 can transmit a string, e.g., an alphanumeric string, that is stored in the 500 and uniquely identifies the user. In some cases, the contactless card 500 can transmit the string based on a request or a read performed by the mobile device 102. Additionally, the contactless card 500 may encrypt the string using a private key stored on the contactless card 500 and transmit the string as an encrypted string to the mobile device 102. The private key may be part of a key pair and associated with a public key that may be used to authenticate a user. In an embodiment, the private key may be a unique key generated by and associated with the card provider. In another example, the private key may be associated with performing operations according to the Europay, Mastercard, Visa (EMV) standard.

[0021] At 206, the mobile device 102 may process the information received from the contactless card 500 and generate a message to send to a device (mobile device 104) associated with the selected contact. In an embodiment, the mobile device 102 may use an identifier or attribute of the contact, e.g., a phone number, a username, an electronic mail (email) address, etc., to determine to send the message to the mobile device. In the illustrated example, the mobile device 102 generates the text message according to a text messaging protocol, e.g., SMS, MMS, RCS, etc. However, in an embodiment, other formats, e.g., e-mail, real-time messaging, etc., may be utilized, and protocols such as User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) may be used.

[0022] The message may include information indicating to the recipient that another user wishes to send (or request) money, information received from the contactless card 500, and information based on user input, e.g., selected contacts and entered amount. In an embodiment, the message may also include an active link or active URL. An active URL may be used by the recipient to facilitate the sending or receiving of money. For example, the recipient may select or activate a URL, which launches a mobile application on the recipient's device. An active URL may be, for example, a deep link that launches a banking app or web page on the mobile device 104. In an embodiment, the URL may be embedded with information including one or more of an encrypted string generated by the contactless card 500, a recipient identifier, an amount identifier, and a sender identifier. The URL may be formatted according to one or more operating systems and APIs. For example, the message may include a URL formatted according to the standards and APIs of the operating systems IOS, ANDROID, and / or MICROSOFT. An exemplary format is "appam: / / <string><recipient identifier><amount identifier>" or "https: / / site.com / <string> / <recipient identifier> / <amount identifier> ", but embodiments are not so limited.

[0023] At 208, the mobile device 102 may send a message to the mobile device 104, i.e., a device associated with the contact. The message may be sent according to one or more communication protocols based on the type of message. At 210, the mobile device 104 may receive the message and present the message on a display device. As described above, the message may include an active URL selectable by a user of the mobile device 104. The mobile device 104 may present the message on a GUI display of a messaging application. The user may interact with the message and select or click on the URL. The mobile device 104 may detect that the user has selected and / or activated the URL and launch an application or web page based on the information in the URL. The mobile device 104 may launch an application, such as a banking application or web page in a web browser. In an embodiment, the mobile device 104 including the application also processes the information embedded in the URL. For example, the application may process the encrypted string at 212 and pass the encrypted string to the system 106 via an API to authenticate the sender. In an embodiment, the application may also transmit other data to the system 106, including the sender's identifier, the recipient's identifier, and the amount.

[0024] At 214, the system 106 can authenticate the sender based on the information received from the mobile device 104. For example, the system 106 can utilize the sender's identifier to perform a lookup to determine a stored authentication string from a database or data store. The system 106 can also determine a public key associated with the sender and attempt to decrypt the string. The decrypted string can then be compared to the authentication string to determine if they match and authenticate the sender. If the system 106 determines that the strings match, the sender is authenticated; if they do not match, the sender is not authenticated.

[0025] At 216, the system 106 can return the result of the comparison or an indication as to whether the sender is authenticated. The indication may result in an API call to perform the authentication operation. At 218, the mobile device 104 can present the indication to the user on a GUI display. In some cases, the mobile device 104 can display an option for the user to accept or reject the money. The mobile device 104 can process the user input to reject the transfer and stop operation or not perform additional operations to transfer the money. Alternatively, the mobile device 104 can process the user input to accept or proceed with the transfer of the money and perform additional operations to perform the transfer at 220. For example, the mobile device 104 can provide instructions or communication to the mobile device 102 to proceed with the transfer of the money. The mobile device 102 can send instructions to one or more backend servers, such as a bank server, to electronically transfer the money to an account associated with the recipient and the mobile device 104. In another example, the application can send instructions to the bank server to proceed with the transfer of the money.

[0026] In some cases, a secure connection may be established between the mobile device 102 and the mobile device 104 to transfer money. The secure connection may be a P2P localized connection between the mobile device 102 and the mobile device 104. The mobile device 102 may send money to the mobile device 104 as an electronic token. The mobile device 104 may process the token and communicate with a bank server to provide instructions for the transfer. The token may include information that may be used by the bank server to complete the transfer. The information may include a sender identifier, a recipient identifier, an amount, etc. The embodiments are not so limited.

[0027] 3 illustrates an example routine 300 that may be implemented by the system 100. In particular, the routine 300 may be implemented by a mobile device that sends money (or requests money) from another user via the mobile device.

[0028] At block 302, the routine 300 includes detecting, by a processor of a first mobile device associated with the first user, a request to send or receive money from a second user of a second mobile device. For example, the mobile device may include a banking application in which a user may be presented with one or more options to send or request money from another person via a P2P transfer. The user may provide an input to select whether to send or request money via the banking application. The user may also provide additional information for the transfer. For example, the application may allow the user to enter a contact or person to send or request money from and an amount to transfer. The mobile device may receive an input selection, for example, via a touch screen interface to send money to another user. In one example, the input selection may include a selection of a contact from a contact list stored on the mobile device. In another example, the user may type a contact into a field using a keyboard, such as a physical keyboard or a virtual keyboard. In another example, the user may provide other identifying information, such as a phone number, an email address, a username, etc. The embodiments may not be limited to these examples.

[0029] To effect a monetary transaction, the user must be authenticated to the second mobile device and the second user. Typical authentication methods may be utilized, including providing a password, performing a biometric analysis, sending a code via text message, and the like. However, the embodiments described herein may provide additional security by utilizing a contactless card. In the illustrated routine 300, the first user is authenticated utilizing a contactless card associated with the first user. Authenticating a user using a contactless card provides an advantage over other techniques by ensuring that the user owns the card and that the contactless card contains a token or string unique to the user. As will be described in more detail, the token or string may be used to authenticate the user via a third party, such as a banking system or other third party authentication system. In some cases, the second user may authenticate the first user utilizing a local authentication string and a public key associated with the first user.

[0030] An authentication operation performed with a contactless card includes a mobile device exchanging information with the contactless card, which may be initiated by a user bringing the contactless card within communication range of the mobile device (NFC communication range is approximately 10 cm). At block 304, the routine 300 includes requesting, by a prompt on the display device, a first user associated with the first mobile device to tap the contactless card on the first mobile device. Once the contactless card is within sufficient range of the mobile device, a connection can be established between the device and the card, and the mobile device can exchange data with the card, and the card can exchange data with the mobile device. Instructing the user to tap the card on the mobile device ensures that the card is within communication range. However, other embodiments may include instructing the user to bring the contactless card close to or near the mobile device, and the mobile device can provide an indication when the card is within communication range, e.g., displaying a message or icon, lighting an LED, etc.

[0031] At block 306, the routine 300 includes receiving data from the contactless card. The data may be encrypted by the contactless card with a private key associated with the first user and securely stored on the contactless card, e.g., a unique private key or an EMV-based private key. In some cases, the contactless card may transmit the data to the mobile device in one or more NFC Data Exchange Format (NDEF) messages. The encrypted data may include information identifying the first user, such as a token or string also securely stored on the contactless card. The mobile device may provide an indication to the user that a message should be sent to the second mobile device when the exchange is complete.

[0032] In an embodiment, the mobile device may generate and send instructions to a second mobile device associated with a second user to transfer money. For example, in block 308, the routine 300 includes generating a text message including text including information of the transfer, a uniform resource locator (URL), and data from the contactless card. The text may identify the sender and the amount. The URL may be an active URL or a deep link that, when activated by the recipient, causes the recipient mobile device to launch an application and perform authentication of the first user using the data from the contactless card. In an embodiment, the mobile device may generate a message and embed data in the message and / or URL. For example, data including an encrypted string may be embedded in the URL as a parameter. Thus, when the URL is activated, the encrypted string is passed to the launched application. In some cases, the mobile device may include additional information in the URL including an identifier identifying the sender, an identifier identifying the recipient, and a specified amount to transfer. The identifier and the specified amount may also be passed to the launched application as parameters and used by the application to process the transfer.

[0033] At block 310, the routine 300 includes sending a message to the second mobile device. The message may be a text message and may be communicated to the second mobile device based on an associated phone number. The text message may be sent according to any type of messaging protocol, such as SMS, MMS, and RCS. In some cases, other mediums may be used to send the message, email, chat applications, and the like. The embodiments are not so limited.

[0034] In an embodiment, the second mobile device can receive the message and process the message. For example, the second mobile device can present the message to the second user on the display device of a GUI display. When the URL is activated by the second user, the second mobile device can perform additional operations including authenticating the first user. In some cases, the authentication may be performed locally by the second mobile device, and in other cases, the second mobile device may utilize a banking system or other third party system to authenticate the first user. The second mobile device can determine a result of the authentication operation and provide the result to the first mobile device.

[0035] At block 312, the routine 300 includes receiving an indication from the second mobile device indicating whether the first user was authenticated. The indication may be received from the second mobile device in a text message or other communication medium. The indication may include a result of the authentication and an indication as to whether the second user accepts or rejects the monetary transaction. If the first user cannot be authenticated or the second user rejects the transaction, the first and second mobile devices may stop the operation of transferring money. Alternatively, if the first user is authenticated and the second user accepts the transaction, the device may continue to perform the operation of transferring money. At block 314, the routine 300 includes exchanging information with the second mobile device to transfer money.

[0036] In some cases, for example, when the first mobile device and the second mobile device cannot form a remote, e.g., localized, P2P connection with each other, the mobile device can conduct the transfer of money through a banking system. In one example, the sender and the recipient may have accounts at the same bank and banking system. The banking application on each device may also communicate directly with the banking system. In this example, the second mobile device can send an indication to the banking system indicating that the transfer has been accepted if the first user is authenticated and the second user accepts the transfer. The indication may be sent via API communication from the banking application on the second mobile device to the banking system. The banking system can then electronically conduct the transaction by debiting the money from the sender's account and adding the money to the recipient's account. In some cases, the first mobile device can initiate and cause the transfer of money upon receiving an indication that the first user is authenticated and the second user approves the transfer. Similarly, the first mobile device can communicate with a banking system via a banking application on the first mobile device to effect the transaction. The banking system can then effect the transaction as described above, for example, electronically debiting money from the sender's account and adding money to the recipient's account.

[0037] In an embodiment, the first and second users may utilize different banks having different banking systems, and the banking systems may communicate with each other to effect the monetary transaction. For example, the first user may provide an identifier identifying the first user's banking system to the second mobile device. Once the transaction is approved, the second mobile device may transmit information to the banking system associated with the second user. The second user's banking system may then communicate with the first user's banking system to effect the transaction. In another example, the second mobile device may transmit information identifying the second user's banking system to the first mobile device, and the first mobile device may initiate the transaction by communicating with the first user's banking system.

[0038] In some embodiments, the banking application may be a third-party banking application, e.g., an application not directly operated by the banking system. The third-party banking application may be each mobile device, including having one or more bank accounts that operate with the third-party banking application. Once the transfer is approved, the third-party applications on each of the sender and recipient devices may communicate with the respective banks to effect the transfer. In some cases, the third-party application, including the third-party system, may communicate with the sender's banking system to debit the money from the sender's account. The third-party system may hold the money for a period of time to earn fees or interest, and then send the money to the recipient's account. The embodiments are not so limited.

[0039] In an embodiment, the first and second mobile devices can communicate data to transfer money via a secure P2P connection. For example, in response to the first user being authenticated and the second user approving the transfer, the second mobile device can communicate with the first mobile device to establish a P2P connection. The connection can be established according to a particular P2P protocol, such as BLE, Bluetooth, ZigBee, Wi-Fi, etc. Once the connection is established, the first and / or second mobile devices can initiate the transfer of money by sending a message. For example, the second mobile device can send a request for data or a token to transfer money to the first mobile device. The first mobile device can send data to the second mobile device, which may include a token or secure information having an indication of an amount to transfer. The second mobile device can communicate with a banking system to effect the transfer between the bank accounts of the first and second users. In some cases, the data may also include a sender identifier, a recipient identifier, sender bank account information, etc. The data is transmitted securely and can be encrypted.

[0040] 4 illustrates an example routine 400 that may be implemented by system 100. In particular, routine 400 may be implemented by a mobile device that receives a communication from another mobile device, the communication indicating that the other user wishes to send (or request) money.

[0041] At block 402, the routine 400 includes receiving, by a first mobile device associated with a first user, a message including text indicating that the user wishes to send (or request) money, and data including a uniform resource locator (URL). The text may identify the sender and amount of the message. In an embodiment, the message may be received from a second mobile device associated with a second user via a communication protocol, such as SMS, MMS, RCS, or another protocol.

[0042] In an embodiment, the URL may be an active URL or deep link that, when activated by the recipient, causes the second mobile device to launch an application and perform authentication of the second user using the data received from the first mobile device and the contactless card. In an embodiment, the data may include a token or encrypted string and be embedded in the URL. The data may be passed to the application at launch as a parameter that may be used by the application to perform authentication of the second user. Other information, such as identifiers of the first and second users and the amount to be paid or received, may also be embedded in the URL.

[0043] At block 404, the routine 400 includes detecting, by the first mobile device, an input that activates the URL. For example, the first mobile device can include an input device, such as a touch screen interface, where a user can select or "click" on the URL. Embodiments are not limited to this example, and the input may be provided via another input device, such as a button, a microphone (voice command), etc.

[0044] At block 406, the routine 400 includes launching, by the first mobile device, an application in response to the input, which communicates with a server to perform authentication of the second user using the data. As discussed above, the URL may point to a location or may be a deep link that provides instructions processed by the operating system to launch the application. For example, the URL may indicate a particular application to launch or point to a website to launch in a web browser. In some cases, the URL may include instructions to launch an application or specify a landing spot or location. Thus, the application or web browser may open a GUI display that displays information regarding the monetary transaction, such as the sender / requester's name, contact information, amount, etc. In an embodiment, the URL may include data such as a token or encrypted string, an identifier identifying the sender, an identifier identifying the recipient, and an indication of the amount that may be passed to the application as parameters when the application is launched.

[0045] In an embodiment, the first mobile device including the launched application may initiate an authentication operation to authenticate the second user when the URL is activated. Specifically, the launched application may utilize information embedded in the URL, such as a token or an encrypted string, to authenticate the user. In some cases, the application may perform the authentication operation locally by decrypting the encrypted string and comparing the decrypted string with the authenticated string. In some cases, the first mobile device may first obtain the authenticated string from the banking system over a secure communication.

[0046] In the illustrated example, the second mobile device including the application can send the encrypted string to a server of the banking system or a third party system to perform an authentication operation. The application can send data including the encrypted string to the server via API communication. The server can decrypt the encrypted string based on a public key associated with the second user and compare the decrypted string to an authentication string stored in the banking system. If the strings match, the second user can be authenticated, and vice versa.

[0047] At block 408, the routine 400 includes receiving, by the first mobile device, an indication of whether the second user has been authenticated by the server. The indication may be returned to the application in response to the API communication. In some cases, the GUI display may display an indication that an authentication operation is being performed to authenticate the second user and display the results of the authentication operation once they have been determined. If the user cannot be authenticated, the operation of transferring money may be aborted. If the user is authenticated, the application may request confirmation from the first user that they wish to proceed with transferring money.

[0048] In response to the second user being authenticated and the first user confirming the transaction, at block 410, the routine 400 includes effecting a monetary transaction by the first mobile device. As described above in FIG. 3, the first mobile device can communicate with one or more banking systems to effect the monetary transaction. In another example, the first mobile device can send an indication to the second mobile device (the sender's device) that the authentication was successful and that the first user has approved the transaction. The second mobile device can communicate with one or more banking systems to effect the transaction. In yet another example, a P2P connection can be established between the first and second mobile devices, and data can be exchanged between the devices to effect the transaction.

[0049] FIG. 5 illustrates an exemplary configuration of a contactless card 500, which may include a payment card, such as a contactless card, credit card, debit card, or gift card, issued by a service provider, as displayed as a service provider indicia 502 on the front or back of the contactless card 500. In some examples, the contactless card 500 may include identification cards that are not related to payment cards, but are not limited to such cards. In some examples, transaction cards may include dual interface contactless payment cards, reward cards, and the like. The contactless card 500 may include a substrate 508, 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, palladium, gold, carbon, paper, and biodegradable materials. In some examples, contactless card 500 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7816 standard, while transaction cards may otherwise conform to the ISO / IEC 14443 standard. However, it is understood that contactless card 500 according to the present disclosure may have different characteristics, and the present disclosure does not require the implementation of a transaction card in a payment card.

[0050] The contactless card 500 may also include identification information 506 displayed on the front and / or back of the card, and a contact pad 504. The contact pad 504 may include one or more pads and may establish contact with another client device, such as an ATM, a user device, a smartphone, a laptop, a desktop, or a 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 may enable communication according to an EMV protocol. The contactless card 500 may also include processing circuitry, an antenna, and other components, as further described in FIG. 6. These components may be located behind the contact pad 504 or elsewhere on the substrate 508, such as within a different layer of the substrate 508, and may be electrically and physically coupled to the contact pad 504. The contactless card 500 may also include a magnetic strip or tape that may be located on the back of the card (not shown in FIG. 5). The contactless card 500 may also include a near field communication (NFC) device coupled to an antenna that may communicate via an NFC protocol. The embodiments are not so limited.

[0051] 5, the contact pad 504 of the contactless card 500 may include processing circuitry 616 for storing, processing, and communicating information, including a processor 602, memory 604, and one or more interfaces 606. It will be understood that the processing circuitry 616 may include additional components including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware as necessary to perform the functions described herein.

[0052] The memory 604 may 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 500 may include one or more of these memories. The read-only memory may be factory programmable as read-only or one-time programmable. One-time programmable provides the opportunity to write once and then read many times. The write-once / read-many memory may be programmed at a point in time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. The read / write memory can be programmed and reprogrammed many times after leaving the factory. The read / write memory can also be read many times after leaving the factory. In some cases, the memory 604 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 602 on the encrypted data.

[0053] The memory 604 can store one or more applets 608, one or more counters 610, a customer identifier 614, such as a token or string, and an account number 612, which can be a virtual account number. The one or more applets 608 can include one or more software applications that run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 608 is not limited to a Java Card applet, but can instead be any software application operable on a contactless card or other device with limited memory. The one or more counters 610 can include a numeric counter sufficient to store an integer number. The customer identifier 614 can include a unique alphanumeric identifier, token, or string assigned to a user of the contactless card 500, the identifier can distinguish a user of the contactless card from other contactless card users. In some examples, the customer identifier 614 can identify both the customer and the account assigned to that customer, and can further identify the contactless card 500 associated with the customer's account. In some cases, the memory 604 can include a customer identifier 614 and one or more tokens or additional strings that can be used to identify the customer. As described above, the account numbers 612 can include thousands of single-use virtual account numbers associated with the contactless card 500. An applet 608 on the contactless card 500 can manage the account numbers 612 (e.g., select an account number 612, mark the selected account number 612 as used, and send the account number 612 to a mobile device for auto-fill by an auto-fill service).

[0054] Although the processor 602 and memory elements of the foregoing example embodiments are described with reference to contact pads 504, the disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pads 504, or may be completely separate from the contact pads 504, or may be implemented as additional elements in addition to the processor 602 and memory 604 elements disposed within the contact pads.

[0055] In some examples, the contactless card 500 can include one or more antennas 618. The one or more antennas 618 may be mounted around the processing circuitry 616 on the contact pad 504 within the contactless card 500. For example, the one or more antennas 618 may be integral with the processing circuitry 616, or the one or more antennas 618 may be used in conjunction with an external booster coil. As another example, the one or more antennas 618 may be external to the contact pad 504 and the processing circuitry 616.

[0056] In one embodiment, the coil of the contactless card 500 can function as the secondary of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting power or amplitude modulation. The contactless card 101 can infer data sent from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained via one or more capacitors. The contactless card 500 can return communication by switching the load of the coil of the contactless card, or by load modulation. Load modulation can be detected in the coil of the terminal by interference. More generally, using the antenna 618, the processor 602, and / or the memory 604, the contactless card 101 provides a communication interface to communicate via NFC, Bluetooth, and / or Wi-Fi communication.

[0057] As described above, the contactless card 500 can be built on a software platform capable of running on a smart card or other device with limited memory, such as a JavaCard, and can securely execute one or more applications or applets. An applet 608 can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 608 can respond to one or more requests, such as a near-field wireless data exchange request, from a reader, such as a mobile NFC reader (e.g., a mobile device or a point-of-sale terminal), and generate an NDEF message that includes a cryptographically secure OTP encoded as an NDEF text tag.

[0058] One example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 608 can encode the OTP as a well-known type of text tag in NDEF Type 4. In some examples, an NDEF message may contain one or more records. The applet 608 can add one or more static tag records in addition to the OTP record.

[0059] In some examples, the one or more applets 608 can emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different encrypted data is presented that can indicate the authenticity of the contactless card. Based on the one or more applets 608, an NFC read of the tag can be processed, the data can be sent to a server, such as a server of a banking system, and the data can be verified at the server.

[0060] In some examples, the contactless card 500 and the server may include specific data so that the card may be properly identified. The contactless card 500 may include one or more unique identifiers, such as a token or string (not shown). Each time a read operation is performed, the counter 610 may increment. In some examples, each time data from the contactless card 500 is read (e.g., by a mobile device), the counter 610 is sent to the server for validation, which determines (as part of the validation) whether the counter 610 is equal to the server's counter.

[0061] The one or more counters 610 can prevent replay attacks. For example, if a ciphertext is captured and replayed, the ciphertext is immediately rejected if the counter 610 is read, used, or otherwise passed on. If the counter 610 is not used, it can be replayed. In some instances, the counter that is incremented on the card is different from the counter that is incremented for the transaction. The contactless card 101 cannot determine the application transaction counter 610 because there is no communication between the applet 608 on the contactless card 500.

[0062] In some examples, the counter 610 may not be synchronized. In some examples, the counter 610 may increment to account for accidental reads that initiate a transaction, such as a read at an angle, but the application does not process the counter 610. In some examples, NFC may be enabled when the mobile device 110 wakes up, and the device 110 may read available tags, but no action is taken in response to the read.

[0063] To keep the counter 610 synchronized, an application may be run, such as a background application, that detects when the mobile device 110 wakes up, synchronizes with a banking system server that indicates the lead that occurred due to the detection, and then moves the counter 610 forward. In another example, a hashed one-time password may be utilized so that a window of mis-synchronization may be accommodated. For example, if within a threshold of 10, the counter 610 may move forward. However, if within a different threshold, such as 10 or 1200, a request to perform a re-synchronization may be processed, which the user requests via one or more applications that the user taps, gestures, or otherwise indicates one or more times via the user's device. If the counter 610 increments in the proper sequence, the user may know.

[0064] The key diversification technique described herein with reference to the counter 610, the master key, and the diversified keys is one example of an encryption and / or decryption key diversification technique. This exemplary key diversification technique should not be considered as limiting of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0065] During the contactless card 500 creation process, two encryption keys may be uniquely assigned per card. The encryption keys may include symmetric keys that may be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by hardware within the contactless card 500. A key diversification process may be used to derive one or more keys from a master key based on uniquely identifiable information for each entity that requires a key.

[0066] In some examples, to overcome the shortcomings of the 3DES algorithm, which is susceptible to vulnerabilities, a session key (such as a unique key per session) can be derived, but rather than using a master key, a unique card derivation key and a counter can be used as diversification data. For example, a different key may be used to create a message authentication code (MAC) and perform encryption each time the contactless card 101 is used in operation. This results in a triple layer of encryption. The session key can be derived by using an application transaction counter generated by one or more applets and with one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0067] Additionally, the increments for each card may be unique, assigned by personalization, or algorithmically assigned by some identifying information. For example, odd numbered cards may increment by 2, and even numbered cards may increment by 5. In some instances, the increments may also vary over a series of leads, such that a card may increment sequentially by repeating 1, 3, 5, 2, 2, ... The specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

[0068] The authentication message may be delivered as the contents of a textual NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0069] 7 is a timing diagram illustrating an example sequence for providing an exchange of data in accordance with one or more embodiments of the present disclosure. Sequence flow 700 may include a contactless card 500 and a mobile device that may include an application 702 and a processor 704.

[0070] At line 708, the application 702 communicates with the contactless card 500 (e.g., after being brought into proximity of the contactless card 500). The communication between the application 702 and the contactless card 500 may involve the contactless card 500 being sufficiently close to a card reader (not shown) of the mobile device to enable NFC data transfer between the application 702 and the contactless card 500.

[0071] At line 706, after communication is established between the mobile device and the contactless card 500, the contactless card 500 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 500 is read by the application 702. In particular, this may occur upon a read, such as an NFC read of a Near Field Wireless Data Exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader application, such as the application 702, may send a message, such as an applet selection message, with the applet ID of the NDEF generation applet. Upon confirming the selection, a series of select file messages followed by read file messages may be sent. For example, the sequence may include "select capability file", "read capability file", and "select NDEF file". At this point, a counter value maintained by the contactless card 500 may be updated or incremented, followed by "read NDEF file". At this point, a message may be generated, which may include a header and a shared secret, such as a token or string. A session key may then be generated. A MAC ciphertext can be created from the message, which may include a header and a shared secret. The MAC ciphertext can then be concatenated with one or more blocks of random data, and the MAC ciphertext and the random number (RND) can be encrypted with a session key. The ciphertext and header can then be concatenated, encoded as ASCII hex, and returned in the NDEF message format (in response to a "read NDEF file" message).

[0072] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, while in other examples, the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string.) In some examples, the application 702 may send a request to the contactless card 500, where the request includes instructions to generate the MAC cryptogram.

[0073] At line 710, the contactless card 500 transmits the MAC cryptogram to the application 702. In some examples, the transmission of the MAC cryptogram occurs via NFC, but the disclosure is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 712, the application 702 transmits the MAC cryptogram to the processor 704.

[0074] At line 714, the processor 704 verifies the MAC ciphertext according to instructions from the application 122. For example, the MAC ciphertext may be verified as described below. In some examples, the verification of the MAC ciphertext may be performed by a device other than the mobile device, such as a server of a banking system in data communication with the mobile device. For example, the processor 704 may output the MAC ciphertext for transmission to a server of the banking system, which may verify the MAC ciphertext. In some examples, the MAC ciphertext may serve as a digital signature of the verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the digital signature algorithm and the RSA algorithm, or zero-knowledge protocols, may be used to perform this verification.

[0075] FIG. 8 illustrates a diagram of a system 800 for implementing one or more embodiments of the present disclosure. As described below, during the contactless card creation process, two encryption keys can be uniquely assigned to each card. The encryption keys can include symmetric keys that can be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm can be used by EMV and is performed by hardware in the contactless card. A key diversification process can be used to derive one or more keys from a master key based on uniquely identifiable information for each entity that requires a key.

[0076] With regard to master key management, two issuer master keys 802, 826 may be required for each portion of a portfolio in which one or more applets are issued. For example, the first master key 802 may include an issuer cryptogram generation / authentication key (Iss-Key-Auth) and the second master key 826 may include an issuer data encryption key (Iss-Key-DEK). As described further herein, the two issuer master keys 802, 826 are diversified into unique card master keys 808, 820 for each card. In some examples, the network profile record ID (pNPR) 522 and derived key index (pDKI) 824 as back office data may be used to identify which issuer master key 802, 826 to use in the encryption process of authentication. The system implementing the authentication may obtain the values ​​of pNPR 822 and pDKI 824 of the contactless card at the time of authentication.

[0077] In some examples, to increase the security of the solution, a session key (such as a unique key per session) can be derived, but as described above, a unique card derived key and counter can be used as diversification data rather than using a master key. For example, a different key can be used to create a message authentication code (MAC) and perform encryption each time the card is used in operation. With regard to session key generation, the key used to generate the ciphertext and encrypt data in one or more applets can include a session key based on a card specific key (Card-Key-Auth 808 and Card-Key-Dek 820). The session keys (Aut-Session-Key 832 and DEK-Session-Key 810) are generated by one or more applets and can be derived by using an application transaction counter (pATC) 804 in one or more algorithms. Only the two lowest bytes of the four-byte pATC 804 are used to fit the data into one or more algorithms. In some examples, a 4-byte session key derivation method may include F1:=PATC(lowest 2 bytes) || "F0" || "00" || PATC(4 bytes) F1:=PATC(lowest 2 bytes) || "0F" || "00" || PATC(4 bytes) SK:={(ALG(MK)[F1]) || ALG(MK)[F2]}, where ALG may include 3DES ECB and MK may include a card-specific derived master key.

[0078] As described herein, the lower two bytes of the pATC 804 counter can be used to derive one or more MAC session keys. At each tap of the contactless card, the pATC 804 is updated and the card master keys Card-Key-AUTH 704 and Card-Key-DEK 820 are further diversified into session keys Aut-Session-Key 832 and DEK-Session-KEY 810. The pATC 804 may be initialized to 0 upon personalization or applet initialization. In some examples, the pATC counter 804 may be initialized upon or before personalization and may increment by 1 upon each NDEF read.

[0079] Additionally, updates for each card may be unique, assigned by personalization, or algorithmically assigned by the pUID or other identifying information. For example, odd numbered cards may be incremented or decremented by 2, and even numbered cards may be incremented or decremented by 5. In some examples, updates may also vary over a series of leads, such that a card may be incremented sequentially by repeating 1, 3, 5, 2, 2, .... The specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from the unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0081] The MAC may be performed by a function key (AUT-Session-Key) 832. The data specified in the ciphertext may be processed with the javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 to correlate with the EMV ARQC verification method. The key used for this calculation may include a session key AUT-Session-Key 832, as described above. As mentioned above, the lower two bytes of the counter may be used to diversify one or more MAC session keys. As described below, the AUT-Session-Key 832 may be used to MAC data 806, and the resulting data or ciphertext An 814 and the random number RND may be encrypted using the DEK-Session-Key 810 to create the ciphertext B or output 818 that is sent in the message.

[0082] In some examples, one or more HSM commands may be processed for decryption such that the last 16 (binary, 32 hex) bytes may include a 3DES symmetric encryption using CBC mode with a zero IV random number followed by MAC authentication data. The key used for this encryption may include a session key DEK-Session-Key 810 derived from Card-Key-DEK 820. In this case, the ATC value for the session key derivation is the least significant byte of the counter pATC 804.

[0083] The following format represents an example embodiment of the binary version: Additionally, in some examples, the first byte may be set to an ASCII "A". [Table 1]

[0084] Another exemplary format is shown below: In this example, the tag may be encoded in hexadecimal format. [Table 2]

[0085] The UID field of the received message can be extracted to derive the card master keys (Card-Key-Auth 808 and Card-Key-DEK 820) for that particular card from the master keys Iss-Key-AUTH 500 and Iss-Key-DEK 826. The card master keys (Card-Key-Auth 704 and Card-Key-DEK 820) can be used to derive the session keys (Aut-Session-Key 832 and DEK-Session-Key 810) for that particular card using the counter (pATC) field of the received message. Ciphertext B 818 can be decrypted using the DEK-Session-KEY to produce ciphertext An 814 and RND, which may be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the Ver, UID, and pATC fields of the message, can be processed through an encrypted MAC using the recreated Aut-Session-Key to create a MAC output such as MAC'. If the MAC' is the same as the ciphertext An814, this indicates that the message decryption and MAC checks all pass. The pATC can then be read to determine if it is valid.

[0086] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, the one or more ciphertexts may be generated using algorithm 3 of ISO 9797-1 with method 2 padding as a 3DES MAC over one or more session keys, such as Aut-Session-Key 832. Input data 806 may take the following form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the shared secret may be generated by one or more random number generators that may ensure that the random numbers are unpredictable through one or more secure processes. In some examples, the shared secret may include a random 4-byte binary number that is injected into the card at personalization time, which is known to the authentication service. During an 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 a 0x'00' byte that may be added to the end of the result data up to an 8-byte boundary. The resulting ciphertext may be 8 bytes in length.

[0087] In some instances, one advantage of encrypting an unshared random number with a MAC cipher as the first block is that it acts as an initialization vector while using the CBC (block chaining) mode of a symmetric encryption algorithm, allowing for "scrambling" between blocks without the need to pre-establish either a fixed or dynamic IV.

[0088] By including an application transaction counter (pATC) as part of the data included in the MAC ciphertext, the authentication service can determine if values ​​carried in the clear data have been tampered with. Additionally, including the version in one or more ciphertexts makes it more difficult for an attacker to intentionally falsify the application version in an attempt to weaken the strength of the cryptographic solution. In some examples, the pATC may start at 0 and be updated by 1 each time one or more applications generate authentication data. The authentication service may keep track of the pATC used during an authentication session. In some examples, if the authentication data uses a pATC that is less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message and the authentication may be rejected. In some examples, if the pATC is greater than a previous value received, this may be evaluated to determine if it is within an acceptable range or threshold, and if it is greater or outside the range or threshold, the verification may be considered to have failed or to be unreliable. In a MAC operation 812, the data 806 is processed through a MAC using the Aut-Session-Key 832 to produce an encrypted MAC output (ciphertext A) 814.

[0089] To provide additional protection against brute force attacks that expose the card's keys, the MAC ciphertext 814 is desirably encrypted. In some examples, the data or ciphertext An 814 included in the ciphertext may include a random number (8), ciphertext(8). In some examples, the number in parentheses may include the length in bytes. In some examples, the random number may be generated by one or more random number generators, which may ensure that the random number is unpredictable via one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include a DEK-Session-Key 810. In an encryption operation 816, the data or ciphertext An 814 and RND are processed using the DEK-Session-Key 706 to generate the encrypted data, ciphertext B 818. The data 814 may be encrypted using 3DES in cipher block chaining mode to ensure that an attacker must perform an attack on all of the ciphertext. Other algorithms may be used, such as the Advanced Encryption Standard (AES), as a non-limiting example. In some instances, an initialization vector of 0x'00000000000000000' can be used: because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random appearance, an attacker attempting to brute force the key used to encrypt this data will not be able to determine when the correct key was used.

[0090] In order for the authentication service to validate one or more cryptograms provided by one or more applets, the following data must be conveyed in the clear from the one or more applets to the mobile device during an authentication session: a version number that determines the cryptographic method used and a message format to validate the cryptogram that allows the method to be changed in the future, a pUID to obtain the cryptographic assets and derive the card key, and a pATC to derive the session key used for the cryptogram.

[0091] 9 illustrates a method 900 for generating a ciphertext. For example, in block 902, a network profile record ID (pNPR) and a derived key index (pDKI) can be used to identify which issuer master key to use in the encryption process for authentication. In some examples, the method can include performing an authentication to obtain values ​​of the pNPR and pDKI of the contactless card at the time of authentication.

[0092] At block 904, the issuer master key may be diversified by combining the issuer master key with a card unique ID number (pUID) and the PAN sequence number (PSN) of one or more applets, for example a payment applet.

[0093] In block 906, the Issuer Master Key can be diversified to create a Card-Key-Auth and a Card-Key-DEK (Unique Card Key) to generate a session key that can be used to generate a MAC ciphertext.

[0094] In block 908, the keys used to generate the ciphertext and encrypt the data in the one or more applets may include session keys in block 1230 that are based on the card specific 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 the pATC, resulting in the session keys Aut-Session-Key and DEK-Session-Key.

[0095] Figure 10 shows an example process 1000 illustrating key diversification according to one example. Initially, the sender and payee may be provisioned 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 may be updated in block 1002 and other data, such as data to be protected that can be securely shared with the payee.

[0096] In block 1004, the counter value may be encrypted by the sender using a data encryption master key to generate a data encryption derived session key, and the counter value may also be encrypted by the sender using a 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 may be used during both encryptions.

[0097] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted in the clear, i.e., without encryption, between the sender and the payee.

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

[0099] In block 1008, the data to be protected may be encrypted by the sender using a data encryption derived session key in conjunction with a symmetric encryption algorithm. In some examples, the MAC is combined with an equal amount of random data, e.g., each 8 bytes long, and then encrypted using a second session key (DEK-Session-Key).

[0100] In block 1010, the encrypted MAC is sent from the sender to the recipient along with sufficient information to identify additional secret information (eg, a shared secret, a master key, etc.) to verify the ciphertext.

[0101] In block 1012, the recipient independently derives two derived session keys from the two master keys using the received counter value, as described above.

[0102] In block 1014, the data encryption derived session key is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing of the exchanged data is then performed. In some instances, after the MAC is extracted, it is desirable to recreate and match the MAC. For example, when verifying the ciphertext, it may be decrypted using an appropriately generated session key. The protected data can be reconstructed for verification. A MAC operation can be performed using an appropriately generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

[0103] At block 1016, the data integrity derived session key is used in conjunction with a cryptographic MAC operation to verify that the protected data has not been altered.

[0104] Some examples of the methods described herein can advantageously ascertain when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key was proper. The MAC may only be correct if the decryption is successful and results in a proper MAC value. Successful decryption can indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Because the derived session key is created using a master key known only to the sender (e.g., the sending device) and the payee (e.g., the receiving device), it can be trusted that the contactless card that originally created the MAC and encrypted the MAC is in fact genuine. Additionally, the counter values ​​used to derive the first and second session keys may be shown to be valid and may be used to perform the authentication operation.

[0105] The two derived session keys may then be discarded, and the next iteration of the data exchange may update the counter value (returning to block 1002), and a new set of session keys may be created (block 1010). In some examples, the combined random data may be discarded.

[0106] 11 illustrates a method 1000 of card activation according to an exemplary embodiment. For example, card activation can be completed by a system including a card, a device, and one or more servers. The contactless card, the device, and the one or more servers can refer to the same or similar components as previously described, such as the contactless card 500, the mobile device, and the server.

[0107] In blocks, the card can dynamically generate data. In some examples, this data can include information such as an account number, a card identifier, a card verification value, or a phone number that can be transmitted from the card to the device. In some examples, one or more portions of the data can be encrypted via the systems and methods disclosed herein.

[0108] At block 1104, one or more portions of the dynamically generated data can be transmitted to an application on the device via NFC or other wireless communication. For example, tapping the card in proximity to the device can enable an application on the device to read one or more portions of data associated with the contactless card. In some examples, if the device does not have an application that assists in activating the card, tapping the card can direct the device to download an associated application that activates the card or prompt the customer to a software application store. In some examples, the user may be prompted to make a sufficient gesture, placement, or orientation of the card toward the surface of the device, e.g., placed at an angle or flat on, near, or in close proximity to the surface of the device. In response to a sufficient gesture, placement, and / or orientation of the card, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0109] At block 1106, the one or more portions of the data may be transmitted to one or more servers, such as a card issuer server. For example, the one or more encrypted portions of the data may be transmitted from the device to a card issuer server for card activation.

[0110] At block 1108, the one or more servers may decrypt the one or more encrypted portions of the data via the systems and methods disclosed herein. For example, the one or more servers may receive encrypted data from the device and decrypt it to compare the received data to record data accessible to the one or more servers. If the result of the comparison of the one or more decrypted portions of the data by the one or more servers results in a successful match, the card may be activated. If the result of the comparison of the one or more decrypted portions of the data by the one or more servers results in an unsuccessful match, one or more processes may be performed. For example, in response to a determination of an unsuccessful match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold that includes the number of attempts that the user is allowed to activate the card. Alternatively, the user may receive a notification such as a message to their device indicating the failed card verification attempt and to call, email or text an associated service for assistance in activating the card, or another notification such as a call to their device indicating the failed card verification attempt and to call, email or text an associated service for assistance in activating the card, or another notification such as an email indicating the failed card verification attempt and to call, email or text an associated service for assistance in activating the card.

[0111] In block 1110, the one or more servers may send a return message based on successful activation of the card. For example, the device may receive an output from the one or more servers indicating successful activation of the card by the one or more servers. The device may display a message indicating successful activation of the card. Once the card is activated, the card may cease dynamic generation of data to avoid unauthorized use. In this manner, the card may not be subsequently activated and the one or more servers are notified that the card has already been activated.

[0112] 12 illustrates an embodiment of an exemplary computer architecture 1200 suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 1200 may include or be implemented as part of one or more of the systems or devices described herein.

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

[0114] Computing computer architecture 1200 may include various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to execution by computing computer architecture 1200.

[0115] 12, the computing computer architecture 1200 includes a processor 1212, a system memory 1204, and a system bus 1206. The processor 1212 can be any of various commercially available processors.

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

[0117] Computer architecture 1200 may include or be implemented in a variety of articles of manufacture. The article of manufacture may include a computer-readable storage medium that stores 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 the like. 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 may be read and executed by one or more processors to enable performance of the operations described herein.

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

[0119] The computer 1202 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 1230, a magnetic disk drive 1216 that reads from and writes to a removable magnetic disk 1220, and an optical disk drive 1228 that reads from and writes to a removable optical disk 1232 (e.g., a CD-ROM or DVD). The hard disk drive 1230, the magnetic disk drive 1216, and the optical disk drive 1228 may be connected to the system bus 1206 by a HDD interface 1214, a FDD interface 1218, and an optical disk drive interface 1234, respectively. The HDD interface 1214 of an external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0120] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. A number of program modules may be stored in the drives and nonvolatile memory 1208, as well as in volatile memory 1210, including, for example, an operating system 1222, one or more applications 1242, other program modules 1224, and program data 1226. In one embodiment, the one or more applications 1242, other program modules 1224, and program data 1226 may include, for example, various applications and / or components of the systems described herein.

[0121] A user can enter commands and information into the computer 1202 through one or more wired / wireless input devices, such as, for example, a keyboard 1250 and a pointing device, such as a mouse 1252. Other input devices can include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, gloves, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a track ball, a track pad, a sensor, a stylus, etc. These and other input devices are often connected to the processor 1212 through an input device interface 1236 coupled to the system bus 1206, but may also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0122] A monitor 1244 or other type of display device is also connected to the system bus 1206 via an interface, such as a video adapter 1246. The monitor 1244 may be internal or external to the computer 1202. In addition to the monitor 1244, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0123] The computer 1202 can operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 1248. The remote computer 1248 can be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, and typically includes many or all of the elements described relative to the computer 1202, although for purposes of brevity, only a memory and / or storage device 1258 is shown. The logical connections shown include wired / wireless connections to a local area network 1256 and / or larger networks, e.g., a wide area network 1254. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks, such as intranets, all of which can be connected to a global communications network, e.g., the Internet.

[0124] When used in a local area network 1256 networking environment, the computer 1202 is connected to the local area network 1256 through a wired and / or wireless communication network interface or adapter 1238. The network adapter 1238 can facilitate wired and / or wireless communication to the local area network 1256, which may also include a wireless access point disposed thereon to communicate with the wireless capabilities of the network adapter 1238.

[0125] When used in a wide area network 1254 networking environment, the computer 1202 may include a modem 1240 or be connected to a communication server on the wide area network 1254 or have other means of establishing communications over the wide area network 1254, such as via the Internet. The modem 1240 may be an internal or external wired and / or wireless device and connects to the system bus 1206 via the input device interface 1236. In a networked environment, program modules depicted relative to the computer 1202, or portions thereof, may be stored in the remote memory and / or storage device 1258. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0126] The computer 1202 is operable to communicate with wired and wireless devices or entities using standards of the IEEE 802 family, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.11 wireless modulation technology). This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, communication can be a predefined structure, similar to a traditional network, or simply ad-hoc communication between at least two devices. A Wi-Fi network provides secure, reliable, and high-speed wireless connectivity using radio technologies called IEEE 802.11 (a, b, g, n, etc.). A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0127] Various elements of devices such as those described herein may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, 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 units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements 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 program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as desired computational speeds, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints desired for a given implementation.

[0128] The components and features of the devices described above may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single chip architectures. Furthermore, device features may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing, where appropriate. It should be noted that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0129] 13 is a block diagram illustrating an example communications architecture 1300 suitable for implementing various embodiments as described above. Communications architecture 1300 includes various common communications elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to implementation with communications architecture 1300 that may be consistent with the systems and devices described herein.

[0130] 13, the communications architecture 1300 includes one or more client(s) 1302 and server(s) 1304. The server(s) 1304 can perform one or more of the functions and embodiments described herein. The client(s) 1302 and server(s) 1304 are operatively connected to one or more respective client data store(s) 1306 and server data store(s) 1308 that can be used to store information local to the respective client(s) 1302 and server(s) 1304, such as cookie(s) and / or associated contextual information.

[0131] The clients 1302 and the servers 1304 can send information to each other using a communications framework 1310. The communications framework 1310 can implement any well-known communications technology and protocol. The communications framework 1310 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., the Public Switched Telephone Network), or a combination of packet-switched and circuit-switched networks (with appropriate gateways and converters).

[0132] The communications framework 1310 can implement various network interfaces that accept, communicate, and connect to communications networks. A network interface can be considered a specialized form of an input / output (I / O) interface. The network interfaces can use connection protocols including, but not limited to, direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1200Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.11a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. Additionally, multiple network interfaces can be used to participate in various communications network types. For example, multiple network interfaces can be used to enable communications over broadcast, multicast, and unicast networks. When processing requirements call for a greater amount of speed and capacity, a distributed network controller architecture can similarly be used to pool and distribute load and otherwise increase the communications bandwidth required by the clients 1302 and servers 1304. The communications network may be any one and combination of wired and / or wireless networks, including, but not limited to, direct interconnects, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), Operating Missions as Nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communications networks.< / string> < / string>

Claims

1. 1. A mobile device comprising: A display device; A processor; [0023] a memory; The memory, when executed by the processor, causes the processor to: receiving an input to effect an electronic transaction of money with a second mobile device of a first user; causing the display device to present instructions for providing a contactless card on the mobile device; receiving first data from the contactless card, the first data being encrypted with a private key of a second user; generating a message including the first data for transmission to the second mobile device, the message including a Uniform Resource Locator (URL) that causes the second mobile device to perform authentication of the second user using the first data; communicating the message to the second mobile device; and electronically transferring the money based on the authentication of the second user. Including instructions, Mobile devices.

2. an input device coupled to the memory and the processor, the input device receiving the input including a selection of a contact, an indication of an amount to be electronically transferred, or a combination thereof; The mobile device of claim 1 .

3. the URL further includes a first identifier that identifies the amount and a second identifier that identifies the first user. The mobile device of claim 2 .

4. The processor, Detecting the contactless card via a Near Field Communication (NFC) signal; Initiating an NFC exchange with the contactless card based on the contactless card coming within communication range of the mobile device; and receiving the first data from the contactless card via the NFC exchange; The mobile device of claim 1 .

5. the URL includes a link that, when activated, launches a web page on the second mobile device to perform the authentication of the second user using the first data. The mobile device of claim 1 .

6. The mobile device of claim 1 , wherein the first data comprises a string encrypted with the private key stored on the contactless card.

7. the private key is part of a key pair, the key pair further including a public key associated with the contactless card, the first user, or a combination thereof; The mobile device of claim 1 .

8. The mobile device of claim 1 , wherein the processor receives a result indicating that the second user has been successfully authenticated from the second mobile device and triggers the electronic transaction based on the result.

9. 10. The mobile device of claim 1, wherein the processor transmits the message to the second mobile device as a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, or a Rich Communication Services (RCS) message.

10. 1. A mobile device comprising: An input device; A processor; [0023] a memory; The memory, when executed by the processor, causes the processor to: receiving a message including a Uniform Resource Locator (URL) from a second mobile device, the message including first data and causing the mobile device to perform authentication of the first user using the first data; detecting an input via the input device that activates the URL; in response to said input, initiating an application that communicates with a server and uses said first data to perform said authentication of said first user; receiving an indication that the first user has been authenticated by the server; performing a monetary transaction based on the first data and the indication that the first user has been authenticated; Including instructions, Mobile devices.

11. the input device comprises a touch screen interface, the touch screen interface detecting a selection of the URL on a display device; The mobile device of claim 10.

12. the URL includes a link that, when selected, launches the application; The mobile device of claim 11.

13. a display device configured to present the message on a graphical user interface (GUI) display; The mobile device of claim 10.

14. the processor communicating the first data to the server to perform the authentication of the first user. The mobile device of claim 10.

15. The URL further includes a first identifier of an amount to be exchanged and a second identifier for identifying the first user; The processor transmits at least one of the first identifier and the second identifier to the server. The mobile device of claim 14.

16. the processor causes the execution of the transaction based on the amount and the authenticated first user.

16. The mobile device of claim 15.

17. the first data includes an encrypted string associated with the first user; the instructions include information indicating that the encrypted string was successfully decrypted using a private key associated with the first user. The mobile device of claim 10.

18. the encrypted string is encrypted with a private key stored on a contactless card associated with the first user; 20. The mobile device of claim 17.

19. the processor receives the message as a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, or a Rich Communication Services (RCS) message. The mobile device of claim 10.

20. Detecting, by a processor of a first mobile device associated with the first user, a request to exchange money with a second user of a second mobile device; requesting, via a prompt on a display device, the first user associated with the first mobile device to tap a contactless card on the first mobile device; receiving first data from the contactless card, the first data being encrypted with a private key associated with the first user; generating a text message including the first data for transmission to a second user device, the text message including a Uniform Resource Locator (URL) that causes the second mobile device to perform authentication of the first user using the first data; communicating the text message to the second mobile device; receiving an indication from the second mobile device that the first user has been authenticated; exchanging information with the second mobile device to exchange the money; The computer-implemented method includes:

Images