Application-based point-of-sale (POW) management systems for mobile operating systems

Abstract

To provide a point of sales information management system in an application-based operating system.SOLUTION: A first application is configured to generate a first URL directed to a second application, and a parameter of the first URL includes an identifier of the first application. A mobile OS is configured to access the first URL to open a second application. The second application is configured to: receive a virtual account (VAN) from a server; start the server on a port; and generate a second URL directed to the first application. A parameter of the second URL includes the port. The mobile OS is configured to access the second URL to open the first application. The first application is configured to: establish a connection to the server, using the designated port; receive the VAN from the second application via the connection; and automatically input the VAN to a form field of a payment form.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 16 / 876,473, entitled "Application - Based Point - of - Sale Information Management System in a Mobile Operating System", filed on May 18, 2020. The content of the aforementioned patent application is hereby incorporated by reference in its entirety.

[0002] Technical Field Embodiments of this specification generally relate to computing platforms, and more specifically, to providing an application - based point - of - sale information management system in a mobile operating system.

Background Art

[0003] In some mobile operating systems, communication between two or more applications running on the same device is restricted. For example, some mobile operating systems may prevent a first application from communicating directly with a second application. Similarly, some mobile operating systems may restrict data exchange between such applications. By doing so, legitimate and secure communication between applications can be unnecessarily restricted.

Summary of the Invention

[0004] Embodiments disclosed herein provide systems, methods, products, and computer-readable media for communication between applications in a mobile operating system. In one example, a first application may generate a first URL directed to a second application, the parameters of which include an identifier for the first application. The mobile operating system (OS) may access the first URL to open the second application. The second application may receive a virtual account number (VAN) from a server. The second application may start a server on a port and generate a second URL directed to the first application, the parameters of which include the port. The OS may access the second URL to open the first application. The first application may establish a connection with the server using the specified port and receive a VAN from the second application through that connection. The first application may automatically populate a form field in the first application's payment form with the VAN. [Brief explanation of the drawing]

[0005] [Figure 1A] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 1B] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 1C] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 1D] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 1E]This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 1F] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 2A] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 2B] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 2C] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 2D] This document illustrates an embodiment of a system for an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 3A] This document illustrates an embodiment of an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 3B] This document illustrates an embodiment of an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 3C] This document illustrates an embodiment of an application-based point-of-sale (POW) management system in a mobile operating system. [Figure 4] This shows one embodiment of the first logical flow. [Figure 5] This shows one embodiment of the second logical flow. [Figure 6A] An example of a contactless card is shown. [Figure 6B] An example of a contactless card is shown. [Figure 7] This shows one embodiment of a computing system. [Modes for carrying out the invention]

[0006] Embodiments disclosed herein provide technology for an application-based point-of-sale (POS) management system accessible by other applications within a mobile operating system (OS) that restricts communication between applications registered with different developers. Generally, a first application running on a device may benefit from data that may be provided by a second application on the device. For example, the first application may be a vendor application registered with the OS, and the second application may be an application provided by a financial institution registered with the OS. In such an example, a user of the vendor application may request that data from the financial institution application, such as payment information, biographical information, etc., be used in the vendor application. In response to the request, the vendor application may generate a first uniform resource locator (URL) directed to the financial institution application. Parameters of the first URL may include an identifier for the vendor application.

[0007] Next, the vendor application may instruct the mobile OS to open or otherwise access the first URL. This causes the mobile OS to open the financial institution application on the device. The financial institution application may then start a local server within the OS that is accessible only to applications running on the mobile device. The local server is started on a port and may be a Transmission Control Protocol / Internet Protocol (TCP / IP) server or other type of server (e.g., a Hypertext Transfer Protocol (HTTP) server). In some embodiments, the financial institution application may receive authentication credentials for the financial institution account before starting the server. For example, if a user has not provided login credentials within a threshold time, e.g., 30 days, the financial institution application may prompt the user to provide login credentials. Furthermore and / or alternatively, before starting the server, the financial institution application may receive encrypted data from a contactless card associated with the account and send the encrypted data to the authentication server. The authentication server may attempt to decrypt the encrypted data. If the server decrypts the encrypted data, it may send an instruction to the financial institution application that the encrypted data has been verified. Furthermore, once the server decrypts the encrypted data, the server may generate a Virtual Account Number (VAN) for the account. The server may provide the financial institution application with the generated VAN, the VAN's expiration date, and the VAN's Card Verification Value (CVV). Furthermore, the server may provide the financial institution application with other data such as first name, last name, phone number, email address, billing address, and / or shipping address.

[0008] The financial institution application may generate a second URL directed to the vendor application. The second URL may be at least partially based on the vendor application identifier specified as a parameter in the first URL. The second URL may further specify the local server's port as a parameter. The financial institution application may further register the local server and / or the financial institution application with the OS as background tasks so that the local server and / or the financial institution application continue to run in the background of the OS while other applications (e.g., the vendor application) are running in the foreground of the OS. The financial institution application may instruct the mobile OS to open the second URL or access it in some other way. This causes the OS to open the vendor application in the foreground of the OS.

[0009] Once opened, the vendor application can identify the port of the local server specified by the second URL and establish a connection with the local server on a specified port of the local interface (e.g., the local loopback IP address). In some embodiments, the vendor application may provide a certificate that can be verified by the server as part of establishing the connection. In addition, and / or instead, the vendor application may provide a token that can be verified by the server as part of establishing the connection. Once the connection is established, the financial institution application can exchange data with the vendor application over the connection, and vice versa. For example, the financial institution application may use the connection to provide the vendor application with VANs, expiration dates, and CVVs and / or other information (e.g., address information). In such an example, the vendor application may automatically populate a form with the received data, thereby allowing the user to complete a purchase or other operation using the received data. More generally, any number and type of data can be exchanged over the connection.

[0010] Advantageously, mobile operating systems can restrict external entities from accessing local servers, thereby improving device and data security. Furthermore, securely receiving payment data from financial institution applications enhances the security of payment data. For example, users do not need to manually enter VANs, expiration dates, and / or CVVs, which could compromise data security. In addition, in some embodiments, financial institutions may provide a framework (e.g., a software development kit (SDK)) containing the functionality necessary to perform the operations disclosed herein. This allows third-party applications (e.g., vendor applications) to integrate only the necessary functionality without requiring the complete SDK and / or framework necessary to perform the operations disclosed herein. For example, by providing vendor applications with one or more APIs that can be used for data exchange, the SDK allows vendor applications to be smaller in size compared to including the complete codebase of the financial institution application in the vendor application to provide the functionality required by the vendor application.

[0011] Referring generally to the notation and nomenclature used herein, one or more parts of the following detailed descriptions may be presented relating to program procedures performed on a computer or a network of computers. The descriptions and representations of these procedures are intended to convey to those skilled in the art in the most effective way to the substance of their work. Procedures, as described herein, are generally considered to be a set of self-consistent operations that lead to a desired result. These operations are operations that require the physical manipulation of physical quantities. Usually, but not always, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, and otherwise manipulated. For reasons of common use, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

[0012] Furthermore, these operations are often referred to in terms such as addition and comparison, and these are generally associated with intelligent calculations performed by human operators. However, in any of the calculations described herein that form part of one or more embodiments, such ability of a human operator is neither necessary nor, in most cases, desirable. Rather, these calculations are machine calculations. Useful machines for performing the calculations of the various embodiments include digital computers selectively invoked or configured by computer programs stored therein, written in accordance with the teachings herein, and / or devices or digital computers specifically constructed for the required purpose. The various embodiments also relate to devices or systems for performing these operations. These devices may be specifically constructed for the required purpose. The structures required for these various machines will become apparent from the given description.

[0013] Herein, we refer to the drawings. Similar reference numbers are used throughout to refer to similar elements. In the following description, many specific details are given for illustrative purposes and to fully understand them. However, it may be apparent that novel embodiments can be carried out without these specific details. In other examples, well-known structures and devices are shown in block diagram form to facilitate their description. The intent is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0014] Figure 1A shows a schematic diagram of an exemplary system 100 consistent with the disclosed embodiments. As shown, system 100 includes one or more mobile computing devices 110. A mobile device 110 represents any type of network-enabled computing device running a mobile operating system, such as a smartphone, tablet computer, wearable device, laptop, or portable gaming device. A mobile device 110 may include a processor 101 and memory 111. Processor 101 may be any computer processor, including but not limited to AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2)Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors, and similar processors. Processor 101 may also employ dual microprocessors, multi-core processors, and other multiprocessor architectures.Memory 111 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon oxynitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant arrays of independent disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD), and other types of storage media suitable for storing information).

[0015] As shown, the memory 111 of the mobile device 110 includes an instance of a mobile operating system (OS) 112. Exemplary mobile operating systems 112 include the Android® and iOS® mobile operating systems. As shown, the OS 112 includes an account application 113 and one or more other applications 114. The account application 113 allows the user to perform various account-related operations, such as activating a payment card, viewing account balances, purchasing items, and processing payments. In some embodiments, the user may authenticate using authentication credentials to access certain functions of the account application 113. For example, authentication credentials may include a username (or login) and password, biometric credentials (e.g., fingerprint, Face ID, etc.). The other applications 114 represent any type of computing application, such as a web browser, vendor application, shopping application, delivery service application, ride-sharing application, messaging application, word processing application, or social media application. For example, a first of the other applications 114 could be a vendor application provided by a vendor for purchasing goods, services, or any other type of item. As another example, a second of the other applications 114 could be a ride-sharing application that allows users to arrange and pay for transportation services. Yet another example, a third of the other applications 114 could be a delivery service application that allows users to purchase food for delivery.

[0016] Due to the restrictions imposed by the OS 112, applications registered (or assigned) to different developers (or entities) may not be able to communicate and / or exchange data. For example, if such restrictions are provided, the account application 113 (registered as a developer with a financial institution) cannot communicate and / or exchange data with another application 114 (registered with an entity other than a financial institution). Similarly, the first of the other applications 114 (registered with a first entity) cannot communicate with another of the other applications 114 (registered with a second entity different from the first entity). Registration of an application may occur when the application is submitted to an application store associated with the provider of the OS 112. Advantageously, however, the embodiments disclosed herein provide techniques that enable secure communication and / or data exchange between applications registered to different developers (e.g., either the account application 113 and another application 114, and / or any two of the other applications 114).

[0017] Figure 1B shows an embodiment in which application 114-1 receives a request to communicate with account application 113. For example, application 114-1 may be a vendor-registered application. In such an example, a user may select one or more items to purchase through application 114-1. During the checkout process, application 114-1 may give the user the option to use account application 113 to make a payment and / or provide personal information. The user may then accept the option, thereby instructing application 114-1 to communicate with account application 113 and receive the data. In response to the request, application 114-1 may generate a URL 125. URL 125 may be directed to account application 113. URL 125 may further include parameters indicating that application 114-1 generated the URL 125. URL 125 may be a universal link or any type of URL. The parameters may be any identifier suitable for uniquely identifying application 114-1, such as a unique identifier, token, or URL string. For example, URL 125 is "capitalone: / / ?appid=merchantapp", where "capitalone: / / " is directed to an instance of the account application 113 on device 110, and "appid=merchantapp" is the identifier of the application 114-1 that generates URL 125.

[0018] In some embodiments, application 114-1 uses the OS 112's Application Programming Interface (API) to determine whether URL 125 is valid (for example, whether the application targeted by URL 125 is installed on device 110). For example, OS 112 may provide a "canOpenURL" API that indicates whether a URL provided as input to the API is valid. Generally, application developers may register one or more URLs with OS 112 providers when submitting an application to an application store. Doing so can facilitate verification by APIs provided by the OS. In such an example, application 114-1 may provide URL 125 (and / or a portion of URL 125 directed to account application 113) to the API, indicating whether account application 113 is installed on the device and can be opened using URL 125. Doing so enhances security by verifying that the correct application is installed and preventing attempts by third parties to provide applications that impersonate account application 113. In the latter case, the third-party application is not registered with the URL provided as input to the API, so masquerading attempts can be prevented. In such an example, if the API returns an invalid response, accessing URL125 may cause OS112 to launch a web browser directed to a website associated with the entity registering the account application 113 (for example, the website of a financial institution and / or an application store from which the account application 113 can be downloaded).

[0019] Next, application 114-1 and / or OS 112 may access, open, or otherwise navigate to URL 125, thereby opening account application 113 in the foreground of OS 112. Figure 1C shows an embodiment in which account application 113 is opened in response to access to URL 125. In response, account application 113 may optionally receive account authentication credentials. In some embodiments, account application 113 determines whether the authentication credentials last provided by the user have exceeded a threshold (e.g., 30 days, 60 days, etc.). For example, if the user has not provided a login / password for 75 days and the threshold is 30 days, account application 113 may request the user to provide a login / password, biometric credentials, etc. In addition and / or instead (as also described in more detail with reference to Figures 2A-2D), account application 113 may optionally pre-initiate verification of encrypted data generated by a contactless card.

[0020] Next, the account application 113 may start a local server 115 to run on the mobile device 110. The local server 115 can be any type of server, such as a TCP / IP server, an HTTP server, a Hypertext Transfer Protocol Secure (HTTPS) server, or a streaming server. However, only local applications (e.g., applications running on the mobile device 110) can access the local server 115. The OS 112 may restrict attempts to access the local server 115 from external sources (e.g., over a network). The account application 113 may start the local server 115 on a specific port number. The account application 113 may select a port according to any feasible selection method, such as randomly generating a port number or using a predetermined port number.

[0021] Figure 1D shows an embodiment in which account application 113 generates URL 126. URL 126 may be directed to application 114-1 and may include the port number of local server 115. For example, URL 126 is "merchantapp: / / ?port=2080", where the "merchantapp: / / " portion is directed to application 114-1 and the "port=2080" portion indicates that local server 115 is open on port 2080. Account application 113 determines the portion of URL 126 directed to application 114-1 based on the identifier of application 114-1 specified in URL 125. In some embodiments, similar to URL 125, account application 113 makes an API call to OS 112 to determine whether URL 126 is valid before accessing it. More generally, URL 126 may have any parameters sufficient to establish a connection to local server 115 on the selected port. In some embodiments, the account application 113 may encrypt the port number or any additional parameters of the URL 126 using, for example, an encryption key or a public key. In such embodiments, the application 114-1 may decrypt the port number and / or additional parameters using, for example, a corresponding decryption key, for example, a private key. Furthermore, any URL parameters exchanged between applications may be encrypted for enhanced security.

[0022] Furthermore, the account application 113 may register the local server 115 and / or the account application 113 as background tasks with the OS 112. This allows the local server 115 and / or the account application 113 to continue running in the background of the OS 112, while other applications run in the foreground of the OS 112. The local server 115 is started, but in some embodiments, the account application 113 may start the local server 115 after generating the URL 126.

[0023] Figure 1E shows an embodiment in which the account application 113 and / or OS 112 open URL 126 to open application 114-1, while the local server 115 and / or account application 113 continue to run in the background of OS 112. In response to receiving URL 126, application 114-1 may identify the port number of the local server 115 specified as a parameter of URL 126. If URL 126 contains encrypted data as stated, application 114-1 may decrypt the encrypted port number (or any other relevant parameter) of URL 126. Application 114-1 may then request to establish a connection with the local server 115 on the specified port, e.g., a local loopback IP address (e.g., 127.0.0.1 for IPv4, ::1 for IPv6, etc.), a "localhost" hostname, or other predefined local IP address. The connection may be established using a protocol supported by the local server 115 (e.g., TCP / IP connection establishment). In some embodiments, application 114-1 provides a token and / or digital certificate (or signature) as part of a connection request to local server 115-1. Local server 115 may determine whether the token is valid and / or expected (for example, the token identifies application 114-1 which may match a token received as a parameter in URL 125). Similarly, local server 115 may verify the certificate using the public key associated with application 114-1. If the token and / or certificate is valid, local server 115 may establish a connection with application 114-1. Otherwise, local server 115 may reject the connection request.

[0024] Figure 1E shows an embodiment in which a connection is established between application 114-1 and local server 115 (local server 115 continues to run as a background task of OS 112). As shown, account application 113 may include data 117. Data 117 may be any type of data stored locally on device 110. Data 117 may include remotely stored data received by account application 113. For example, data 117 may include payment card number, expiration date, CVV, address, first name, last name, email address, telephone number, or any other attributes of the account having account application 113. Advantageously, local server 115 may provide data 117 to application 114-1 while local server 115 is running in the background of OS 112 and application 114-1 is running in the foreground of OS 112. In some embodiments, local server 115 may encrypt data 117. In such embodiments, application 114-1 may decrypt data 117 upon receipt.

[0025] Figure 1F shows an embodiment in which application 114-1 receives data 117 from local server 115. As stated, in some embodiments, application 114-1 may decrypt the data 117 if it is encrypted. Application 114-1 may identify the data 117 and determine that the data 117 contains one or more attributes of a user and / or associated account. Application 114-1 may then automatically populate one or more form fields with the data 117 so that the user can complete checkout using the data securely received from local server 115. As stated, doing so allows for the secure transfer of data 117 between applications on the same device 110. Furthermore, application 114-1 can receive any amount of data from local server 115 by requiring only a minimal set of requirements (e.g., API, minimal SDK, etc.). Otherwise, the size of application 114-1 would be much larger to support the disclosed functionality. In addition, the embodiments disclosed herein allow applications 114-1 and 113 to exchange data even if the applications are registered with different developers.

[0026] Figure 2A shows a schematic diagram of an exemplary system 200 consistent with the disclosed embodiment. As shown, the system 200 includes one or more contactless cards 201, one or more mobile computing devices 110, and an authentication server 220. The contactless card 201 represents any type of payment card, such as a credit card, debit card, ATM card, or gift card. The contactless card 201 may have one or more communication interfaces 209, such as a radio frequency identification (RFID) chip, configured to communicate with the computing device 110 via NFC, EMV standards, or other short-range protocols in wireless communication. While NFC is used as an exemplary communication protocol, this disclosure is equally applicable to other types of communication, such as EMV standards, Bluetooth®, and / or Wi-Fi. The authentication server 220 represents any type of computing device, such as a server, workstation, compute cluster, cloud computing platform, or virtualized computing system.

[0027] As shown, the memory 202 of the contactless card includes an applet 203, a counter 204, a private key 205, a diversified key 206, and a unique customer identifier (ID) 207. The applet 203 is executable code configured to perform the operations described herein. The counter 204, private key 205, diversified key 206, and customer ID 207 are used to provide security in the system 200, as will be described in more detail below.

[0028] As stated, the contactless card 201 can be used to enhance the security of the local server 115 and the mobile device 110. For example, a user of device 110 may want to use data from account application 113 in application 114-1. Thus, Figure 2A shows an embodiment in which account application 114-1 generates and accesses URL 125 directed to account application 113. The OS 112 can then open account application 113, which may receive authentication credentials for the user's account. The account application 113 can then instruct the user to tap the contactless card 201 on device 110. Generally, once the contactless card 201 is brought within range of the communication interface 218 of device 110 (e.g., card reader / writer), the applet 203 for contactless card 201 may generate encrypted data as part of the authentication process required to activate the contactless card 201. To enable NFC data transfer between the contactless card 201 and the mobile device 110, the account application 113 may communicate with the contactless card 201 when it is close enough to the communication interface 218 of the mobile device 110. The communication interface 218 may be configured to read from and / or communicate with the communication interface 209 of the contactless card 201 (e.g., via NFC, Bluetooth®, RFID, etc.). Thus, the exemplary communication interface 218 may include an NFC communication module, a Bluetooth® communication module, and / or an RFID communication module.

[0029] As stated herein, system 100 is configured to implement key diversification to protect data, which may be referred to herein as key diversification technique. Generally, the server 220 (or other computing device) and the contactless card 201 may be provisioned with the same secret key 205 (also called a master key or master symmetric key). More specifically, each contactless card 201 is programmed with a unique secret key 205 that has a corresponding pair within (or is managed by) the server 220. For example, when a contactless card 201 is manufactured, the unique secret key 205 may be stored in the contactless card 201's memory 202. Similarly, the unique secret key 205 may be stored in the customer record (or profile) associated with the contactless card 201 within the server 220's account data 224 (and / or in another secure location such as a hardware security module (HSM) 225). The secret key 205 may be kept secret from all parties other than the contactless card 201 and the server 220, thereby enhancing the security of system 100. In some embodiments, the applet 203 of the contactless card 201 may use the secret key 205 and the data as input to an encryption algorithm to encrypt and / or decrypt the data (e.g., customer ID 207). For example, encrypting customer ID 207 with the secret key 205 may yield an encrypted customer ID. Similarly, the authentication server 220 may use the corresponding secret key 205 to encrypt and / or decrypt the data associated with the contactless card 201.

[0030] In some embodiments, the contactless card 201 and the server 220 may use a counter 204 and / or a secret key 205 together with the counter 204 to enhance security using key diversification. The counter 204 has a value that is synchronized between a given contactless card 201 and the server 220. The counter value 204 may have a number that changes each time data is exchanged between the contactless card 201 and the server 220 (and / or between the contactless card 201 and the mobile device 110). When preparing to send data (e.g., to the server 220 and / or the mobile device 110), the applet 203 of the contactless card 201 may increment the counter value 204. The contactless card 201 may then provide the secret key 205 and the counter value 204 as input to an encryption algorithm, which may produce a diversified key 206 as output. The encryption algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cryptographic-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of encryption algorithms may include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in detail in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0031] Continuing with the example of key diversification, the contactless card 201 may use the diversified key 206 and data as input to an encryption algorithm to encrypt data (e.g., customer ID 207 and / or any other data). For example, encrypting customer ID 207 with the diversified key 206 may yield an encrypted customer ID 208. Once generated, the applet 203 may send the encrypted customer ID 208 to a mobile device 110, for example, via NFC. The account application 113 may then send the encrypted customer ID 208 to an authentication server 220 via the network 230.

[0032] Next, the authentication application 223 may attempt to authenticate the encrypted data. For example, the authentication application 223 may attempt to decrypt the encrypted customer ID 208 using a copy of the secret key 205 stored by the server 220. In another example, the authentication application 223 may provide the secret key 205 and counter value 204 as input to an encryption algorithm, which may generate a diversified key 206 as an output. The resulting diversified key 206 may correspond to the diversified key 206 of the contactless card 201 and can be used to decrypt the encrypted customer ID 208. Thus, the authentication application 223 may successfully decrypt the encrypted data and thereby verify the encrypted customer ID 208. For example, as mentioned, the customer ID 207 may be used to generate the encrypted customer ID 208. In such an example, the authentication application 223 may use the secret key 205 of the authentication server 220 to decrypt the encrypted customer ID 208. If decryption yields a customer ID 207 associated with an account in account data 224, the authentication application 223 verifies the encrypted customer ID 208. Furthermore, the authentication application 223 may instruct the VAN generator 226 to generate a virtual account number, expiration date, and CVV for the account corresponding to customer ID 207. The VAN generator 226 may then store the generated VAN, expiration date, and CVV instructions in the record associated with the account in account data 224. The virtual account number is a temporary (e.g., one-time use) number that can be generated using a random number generator or other randomization function. In some embodiments, the VAN may be linked to a contactless card 201 tapped to device 110 to generate the encrypted customer ID 208.In other embodiments, if a user authenticates their account using valid account credentials in the account application 113, the VAN may be linked to other contactless cards 201 associated with the authenticated account (for example, if the authenticated account holder has two or more cards, and taps the first card 201 on the device 110 to generate a VAN linked to the second card 201). Using a VAN instead of the actual account number (for example, the account number printed on the contactless card 201) has the advantage of maintaining the security of the actual account number.

[0033] If the authentication application 223 is unable to decrypt the encrypted customer ID 208 and obtain the expected result (e.g., the customer ID 207 for the account associated with the contactless card 201), the authentication application 223 will not verify the encrypted customer ID 208, and the VAN generator 226 will not generate a VAN. Due to the verification failure, the authentication application 223 may return an error to the account application 113, which may cause the local server 115 to refrain from starting.

[0034] Regardless of the decryption technique used, the authentication application 223 may successfully decrypt the encrypted customer ID 208 and thereby verify the encrypted customer ID 207 (for example, by comparing the resulting customer ID 208 with the customer ID stored in the account data 224 and / or based on the indication that decryption using keys 205 and / or 206 was successful). Although the keys 205 and 206 are shown to be stored in memory 222, they may be stored elsewhere, such as in the secure element and / or HSM 225. In such embodiments, the secure element and / or HSM 225 may use keys 205 and / or 206 and an encryption function to decrypt the encrypted customer ID 207. Similarly, the secure element and / or HSM 225 may generate a diversified key 206 based on the secret key 205 and counter value 204 as described above. Although shown to be hosted on the same system, the authentication application 223 and the VAN generator 226 may be hosted on different systems. In some embodiments, the orchestration layer (OL) may arrange for the authentication application 223 to verify the encrypted data and / or the VAN generator 226 to generate a VAN.

[0035] Figure 2B shows an embodiment in which an authentication application 223 verifies an encrypted customer ID 208. As shown, the authentication application 223 may return instructions for verification 210 to the account application 113. Similarly, the VAN generator 226 may send a VAN 227 (including the expiration date and CVV) to the account application 113. In some embodiments, the VAN 227 is sent together with the verification 210. In other embodiments, the VAN 227 is sent separately from the verification 210. Based on the receipt of the verification 210 and / or the VAN 227, the account application 113 may decide to start the local server 115. In some embodiments, the VAN 227 is generated and / or sent after the local server 115 has been started. Furthermore, the account application 113 may receive other data from the server 220, such as first name, last name, phone number, email address, billing address, and / or shipping address, associated with the account in the account data 224.

[0036] Figure 2C shows an embodiment in which the account application 113 starts the local server 115 on device 110. As shown, the local server 115 includes VAN227. The account application 113 may then generate a URL containing the port number of the local server 115, which is directed to the requesting application 114-1. The URL then opens the requesting application 114-1, allowing the application 114-1 to establish a connection with the local server 115 running in the background of OS 112.

[0037] Figure 2D shows an embodiment in which another application 114-1 establishes a connection with the local server 115. As shown, the local server 115 may provide the other application 114-1 with the VAN 227 (including the expiration date and CVV). The other application 114-1 may then automatically populate the VAN 227 into forms presented in the other application 114-1, such as payment forms. As described above, the local server 115 may further provide other account-related details, such as the billing address associated with the VAN 227, the billing address of the account in account data 224, the shipping address from account data 224, and the name of the account owner. In doing so, the other application 114-1 can automatically populate one or more form fields with the relevant data, thereby automating at least part of the checkout process (or other processes or workflows of the other application 114-1). More generally, an account application 113, including a local server 115, provides an application-based point-of-sale (POS) management system that can access other applications within the mobile operating system 112, but these applications may be registered with different entities within the OS 112.

[0038] Figure 3A is a schematic diagram 300 showing an exemplary embodiment that enables communication between applications within a mobile operating system. As shown, Figure 3A includes a mobile device 110 running an exemplary application 114. For example, application 114 may be an application that allows a user to place an order and provide payment information or order details. As shown, the graphical user interface (GUI) of application 114 includes a payment form having fields 301-305, where field 301 is the name field, field 302 is the account number field, field 303 is the expiration date field, field 304 is the CVV field, and field 305 is the address field. As shown, application 114 may output a notification 309 specifying that the user should select notification 309 to complete checkout using a virtual account number from a banking application such as account application 113.

[0039] Figure 3B is a schematic diagram 310 showing an embodiment in which the user selects notification 309. In doing so, application 114 may generate a URL 125 to account application 113, the URL 125 including the identifier of application 114 as a parameter. When opened, the URL 125 opens account application 113 in the foreground of OS 112. As shown in Figure 3B, account application 113 may instruct the user to output notification 306 specifying that they provide authentication credentials (not shown) and tap contactless card 201 on mobile device 110 to proceed with authentication. When contactless card 201 is tapped on mobile device 110, account application 113 sends instructions to contactless card 201 via communication interface 218 to generate encrypted data (e.g., encrypted customer ID 208) as described above and send the encrypted data to account application 113. Upon receiving the encrypted data, the account application 113 may send it to the server 220, where the authentication application 223 verifies the encrypted data using key diversification as described above. The authentication application 223 may then send a verification instruction to the account application 113. Furthermore, if the encrypted data has been verified, the authentication application 223 may instruct the VAN generator 226 to generate a VAN, a VAN expiration date, and an account number for the VAN. The VAN generator 226 may then send the VAN, expiration date, and CVV to the account application 113. In addition, the server 220 may send additional data to the account application 113, such as the account holder's name, billing address, shipping address, telephone number, and email address.

[0040] When account application 113 receives an instruction indicating that server 220 has verified the encrypted data, account application 113 may start local server 115 on device 110. Next, account application 113 may generate a URL 126 directed to requesting application 114, the parameters of which include the port number of local server 115. Then, application 114 may connect to local server 115 as described above and request relevant data such as name, address, VAN, expiration date, and CVV.

[0041] Figure 3C is a schematic diagram 320 showing an embodiment in which application 114 receives data requested from local server 115. Application 114 may include an SDK or API that enables application 114 to request and / or receive data and parse the received data. As shown, application 114 may automatically populate the user's name in the name field 301, the virtual account number in the account number field 302, the expiration date in the expiration date field 303, the CVV in the CVV field 304, and the address in the address field 305. The user can then complete the purchase using button 311. In doing so, the purchase can be completed. Furthermore, the data entered in fields 301-305 may be stored in the user profile associated with application 114.

[0042] The operation of the disclosed embodiments can be further described with reference to the following figures. Some figures may include logical flows. While such figures presented herein may include specific logical flows, it should be understood that logical flows merely provide examples of how general functions as described herein can be performed. Furthermore, a given logical flow does not necessarily have to be performed in the order presented unless otherwise specified. Moreover, a given logical flow may be performed by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited in this context.

[0043] Figure 4 shows one embodiment of the logical flow 400. The logical flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 400 may include some or all of the operations for providing an application-based point-of-sale (POS) management system in a mobile operating system. Embodiments are not limited to this context.

[0044] As shown, the logical flow 400 begins in block 405, where device 110 outputs a first application in the foreground of the mobile OS 112. For example, the first application could be application 114-1, which could be an application provided by a vendor. In block 410, the first application may receive instructions specifying that it should receive data from a second application. The second application could be an account application 113. For example, while attempting to order groceries using the vendor application, the user might specify that they should pay for the groceries using a virtual account number from the account application 113. In block 415, the first application generates a first URL directed to the second application. The first URL may include a unique identifier for the first application as a parameter.

[0045] In block 420, OS 112 allows access to a first URL, thereby opening a second application (e.g., an account application 113) in the foreground of OS 112. In block 425, the second application may receive account authentication credentials and / or encrypted data from the contactless card 201. For example, a user may provide biometric credentials and tap the contactless card 201 on device 110, thereby allowing the card 201 to generate and transmit encrypted data. The second application may then send the encrypted data to the authentication server 220. Once the encrypted data is verified, the server 220 may generate the account's VAN, expiration date, and CVV. In block 430, the second application receives the VAN, expiration date, CVV, and verification of the encrypted data from the server 220. In block 435, the second application creates a local server 115 on the mobile device 110 on the specified port.

[0046] In block 440, the second application generates a second URL, which may be directed to the first application. The parameters of the second URL may include the port number of the local server 115. In block 445, the second application registers the local server 115 and / or the second application as background tasks with OS 112, thereby allowing the local server 115 and / or the second application to run in the background of OS 112 for a period of time. In some embodiments, the second application encrypts the parameters of the second URL. In block 450, the first application is opened in the foreground of OS 112 by accessing the second URL, while the local server 115 and / or the second application continue to run in the background of OS 112. The first application may decrypt the parameters of the second URL (if encrypted).

[0047] In block 455, the first application establishes a connection with the local server 115. In block 460, the first application requests and receives data from the local server 115, which includes the VAN, expiration date, and CVV. If encrypted, the first application may decrypt the received VAN, expiration date, and CVV. In block 465, the first application processes the received data. For example, application 114 may automatically fill in the VAN, expiration date, CVV, address information, first name, and last name into a payment form. The user can then complete a grocery purchase using the payment information automatically entered by vendor application 114.

[0048] Figure 5 shows one embodiment of the logical flow 500. The logical flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 500 may include some or all of the operations for providing an application-based point-of-sale (POS) management system in a mobile operating system. Embodiments are not limited to this context.

[0049] As shown, the logical flow 500 begins in block 505, when the user brings the contactless card 201 within range of the mobile device 110 (e.g., using a tap gesture) and causes the contactless card 201 to generate and transmit encrypted data (e.g., encrypted customer ID 208). In block 510, the applet 203 of the contactless card 201 generates a diversified key 206 by encrypting a counter value 204 and a master key 205 stored in the contactless card's memory 202 using an encryption algorithm. In some embodiments, the applet 203 may increment the counter 204 before encryption. In block 515, the contactless card 201 encrypts the data (e.g., customer identifier 207) using the diversified key 206 and the encryption algorithm, generating encrypted data (e.g., encrypted customer ID 208).

[0050] In block 520, the contactless card 201 may transmit encrypted data to the account application 113 on the mobile device 110, for example, using NFC. In block 525, the account application 113 on the mobile device 110 may transmit the data received from the contactless card 201 to the authentication application 223 on the server 220. In block 530, the authentication application 223 on the server 220 may use the secret key 205 and the counter value 204 as input to an encryption algorithm to generate a diversified key 206. In one embodiment, the authentication application 223 increments the counter value 204 on the server 220 to synchronize it with the counter value 204 in the memory of the contactless card 201.

[0051] In block 535, the authentication application 223 uses the diversified key 206 to decrypt the encrypted customer ID 208 received from the contactless card 201 via the mobile device 110. In doing so, it may obtain at least the customer ID 207. By obtaining the customer ID 207, the authentication application 223 may verify the data received from the contactless card 201 in block 540. For example, the authentication application 223 may compare the customer ID 207 with the customer identifier of the associated account in the account data 224 and verify the data based on the match. In block 545, the VAN generator 226 generates a VAN, expiration date, and CVV based on the verification of the encrypted data in block 540.

[0052] In block 550, the server 220 may send instructions to the account application 113 indicating that the VAN, expiration date, CVV, and encrypted data have been verified. In some embodiments, no verification instructions are sent. In such embodiments, the transmission of the VAN, expiration date, and CVV (and / or any other account-related data) serves to indicate that the encrypted data has been verified. In block 555, the account application 113 may start the local server 115. By doing so, the local server 115 can function as a point-of-sale application to other applications running on the mobile device 110, for example, by providing the VAN and related data to complete purchases in those applications.

[0053] Figure 6A shows a contactless card 201 which may include a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 201 may be issued by a service provider 602 which is displayed on the front or back of the card 201. In some examples, the contactless card 201 may include an identification card which is not related to a payment card, but is not limited to this. In some examples, the payment card may be a dual-interface contactless payment card. The contactless card 201 may include a substrate 610 which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 201 may have physical properties that conform to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, please understand that the contactless card 201 relating to this disclosure may have different characteristics, and this disclosure does not require that payment cards be contactless.

[0054] The contactless card 201 may also include identification information 615 displayed on the front and / or back of the card, and a contact pad 620. The contact pad 620 may be configured to establish contact with other communication devices such as a mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 201 may also include processing circuits, an antenna, and other components not shown in Figure 6A. These components may be located behind the contact pad 620 or elsewhere on the substrate 610. The contactless card 201 may also include a magnetic strip or tape that may be located on the back of the card (not shown in Figure 6A).

[0055] As shown in Figure 6B, the contact pads 620 of the contactless card 201 may include a processing circuit 625 for storing and processing information, which includes a microprocessor 630 and memory 202. It is understood that the processing circuit 625 may include additional components, such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and tamper-proof hardware, as necessary to perform the functions described herein.

[0056] Memory 202 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and contactless card 201 may contain one or more of these memories. Read-only memory may be read-only or programmable once at the factory. One-time programming allows it to be written once and read multiple times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritable but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can be read multiple times after leaving the factory.

[0057] Memory 202 may be configured to store one or more applets 203, a counter value 204, a secret key 205, a diversified key 206, and one or more customer IDs 207. One or more applets 203 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java® card applet. However, it is understood that applet 203 is not limited to a Java card applet, but could instead be any software application capable of running on a contactless card or other device with limited memory. Customer ID 207 may comprise a unique alphanumeric identifier assigned to a user of a contactless card 201, the identifier being able to distinguish a user of a contactless card from other contactless card users. In some examples, customer ID 207 may identify both the customer and the account assigned to that customer, and further identify the contactless card associated with the customer's account. In some embodiments, applet 203 may use customer ID 207 as input to an encryption algorithm with keys 205 and / or 206 to encrypt customer ID 207. Similarly, applet 203 may construct a URL that includes the encrypted customer ID 207 as a parameter.

[0058] While the processor and memory elements of the exemplary embodiments described above have been described with reference to the contact pads, the disclosure is not limited thereto. It is understood that these elements may be implemented as additional elements in addition to the processor 630 and memory 202 elements located outside or completely separated from the pads 620, or within the contact pads 620.

[0059] In some examples, the contactless card 201 may have one or more antennas 655. One or more antennas 655 may be located within the contactless card 201 and around the processing circuit 625 of the contact pads 620. For example, one or more antennas 655 may be integrated with the processing circuit 625, or one or more antennas 655 may be used with an external booster coil. In other examples, one or more antennas 655 may be located outside the contact pads 620 and the processing circuit 625.

[0060] In one embodiment, the coil of the contactless card 201 may function as the secondary side of an air-core transformer. A terminal may communicate with the contactless card 201 by disconnecting power or amplitude modulation. The contactless card 201 may infer data transmitted from the terminal by using a gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 201 may return communication by switching the load of the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil by interference. More generally, using an antenna 655, processing circuit 625, and / or memory 202, the contactless card 201 provides a communication interface for communication via NFC, Bluetooth®, and / or Wi-Fi communication.

[0061] As described above, the contactless card 201 may be built on a software platform capable of running on memory-limited smart cards or other devices such as Java cards, and one or more applications or applets may be securely executed. The applet may be added to the contactless card and provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to 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., the communication interface 218 of device 110), and generate an NDEF message with a cryptographically secure OTP (e.g., an encrypted customer ID) encoded as an NDEF text tag.

[0062] Figure 7 shows an exemplary embodiment of a computing architecture 700 comprising a computing system 702 suitable for implementing the various embodiments described above. In various embodiments, the computing architecture 700 may be implemented with or as part of an electronic device. In some embodiments, the computing architecture 700 may represent a system that implements, for example, one or more components of systems 100 and / or 200. In some embodiments, the computing system 702 may represent, for example, a contactless card 201, a mobile device 110, and an authentication server 220. Embodiments are not limited to this context. More generally, the computing architecture 700 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to Figures 1 to 6B.

[0063] The terms “system,” “component,” and “module” as used in this application are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or running software, examples of which are provided by the exemplary computing architecture 700. For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized to one computer and / or distributed across two or more computers. Furthermore, components may be coupled together in a communicative manner by various types of communication media and their operation may be coordinated. Coordination may include the one-way or two-way exchange of information. For example, components may communicate information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. Such data messages can be transmitted over various connections. Examples of connections include parallel interfaces, serial interfaces, and bus interfaces.

[0064] The computing system 702 includes various common computing elements such as one or more processors, multicore processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, and power supplies. However, the embodiments are not limited to those implemented by the computing system 702.

[0065] As shown in Figure 7, the computing system 702 comprises a processor 704, system memory 706, and a system bus 708. The processor 704 may be any of a variety of commercially available computer processors, including but not limited to AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2)Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures may also be used as the processor 704.

[0066] The system bus 708 provides an interface to system components, including but not limited to the system memory 706 and the processor 704. The system bus 708 can be one of several types of bus structures that can further interconnect to the memory bus (with or without a memory controller), peripheral buses, and local buses using any of various commercially available bus architectures. Interface adapters can connect to the system bus 708 via slot architectures. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extensible) (PCI(X)), PCI Express, and Personal Computer Memory Card International Association (PCMCIA).

[0067] The system memory 706 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon oxide nitride (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 (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in Figure 7, the system memory 706 may include non-volatile memory 710 and / or volatile memory 712. The non-volatile memory 710 may store the Basic Input / Output System (BIOS).

[0068] The computing system 702 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 714, a magnetic floppy disk drive (FDD) 716 for reading from or writing to a removable magnetic disk 718, and an optical disk drive 720 for reading from or writing to a removable optical disk 722 (e.g., a CD-ROM or DVD). The HDD 714, FDD 716, and optical disk drive 720 may be connected to the system bus 708 by an HDD interface 724, an FDD interface 726, and an optical drive interface 728, respectively. The HDD interface 724 for external drive implementation may include at least one or both of the Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 702 is generally configured to implement all the logic, systems, methods, apparatus, and functions described herein with reference to Figures 1 to 6B.

[0069] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, a number of program modules may be stored in drives and memory units 710, 712, including an operating system 730, one or more application programs 732, other program modules 734, and program data 736. In one embodiment, one or more application programs 732, other program modules 734, and program data 736 may include, for example, various applications and / or components of systems 100, 200, such as an applet 203, a counter 204, a secret key 205, a diversified key 206, a customer ID 207, an operating system 112, an account application 113, other applications 114, an authentication application 223, account data 224, and / or an encrypted customer ID 208.

[0070] The user may input commands and information to the computing system 702 via one or more wired / wireless input devices, such as a keyboard 738 and a pointing device such as a mouse 740. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, gamepad, stylus pen, card reader, dongle, fingerprint reader, grab, graphics tablet, joystick, keyboard, retina reader, touchscreen (e.g., capacitive, resistive, etc.), trackball, trackpad, sensor, stylus, etc. These and other input devices are often connected to the processor 704 via an input device interface 742 coupled to the system bus 708, but may also be connected via other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, or IR interface.

[0071] Monitor 744 or other types of display devices are also connected to the system bus 708 via interfaces such as the video adapter 746. Monitor 744 can be located inside or outside the computing system 702. In addition to Monitor 744, the computer typically includes other peripheral output devices such as speakers and printers.

[0072] The computing system 702 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computers 748. The remote computers 748 could be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer devices, or other common network nodes, typically including many or all of the elements described in relation to the computing system 702, but for brevity, only the memory / storage device 750 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 752 and / or a larger network, such as a wide area network (WAN) 754. Such LAN and WAN network environments are common in offices and businesses and facilitate enterprise-scale computer networks such as intranets. All of these may connect to global communication networks, such as the Internet. In embodiments, the network 230 in Figure 2 is one or more of the LAN 752 and WAN 754.

[0073] When used in a LAN networking environment, the computing system 702 is connected to the LAN 752 via a wired and / or wireless network interface or adapter 756. The adapter 756 may facilitate wired and / or wireless communication to the LAN 752, which may include a wireless access point placed on it to communicate with the wireless capabilities of the adapter 756.

[0074] When used in a WAN networking environment, the computing system 702 may include a modem 758, or be connected to a communication server on the WAN 754, or have other means of establishing communication on the WAN 754, such as via the Internet. The modem 758 may be internal or external, wired and / or wireless, and connect to the system bus 708 via an input device interface 742. In a network environment, the program modules, or parts thereof, shown with respect to the computing system 702 may be stored in a remote memory / storage device 750. The shown network connections are illustrative, and it will be understood that other means of establishing communication links between computers may be used.

[0075] Computing system 702 is capable of communicating with wired and wireless devices or entities using the IEEE 802 standard family, such as wireless devices configured to operate wirelessly (e.g., IEEE 802.16 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMAX, and Bluetooth® wireless technologies. Thus, communication can be a predefined structure, similar to conventional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies known as IEEE 802.11x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to connect to the Internet, or to wired networks (using IEEE 802.3 related media and functions).

[0076] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The decision of whether an embodiment is implemented using hardware and / or software elements may vary depending on any number of factors, such as desired computing speed, power level, heat resistance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

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

[0078] The foregoing description of exemplary embodiments is provided for illustrative and explanatory purposes only. It is not intended to be exhaustive or to limit this disclosure to the exact form disclosed. Many modifications and changes are possible in light of this disclosure. The scope of this disclosure is intended to be limited by the appended claims rather than by this detailed description. Future applications claiming priority to this application may assert the disclosed subject matter in different ways and may generally include any set of one or more limitations, as variously disclosed or demonstrated herein.

Claims

1. A first application running on the processor of a mobile device receives encrypted data from a contactless card, The first application sends the encrypted data to the server for verification, The first application receives an instruction from the server that the encrypted data has been verified, The first application starts a local server on the port based on the received verification, The first application generates a link directed to a second application running on the processor, the parameters of which the link includes the port, The second application receives data via the port, The second application automatically enters data into the form fields of the second application, A method for providing this.

2. The data received by the second application comprises a virtual account number (VAN), and the automatic input of the data comprises the automatic input of the VAN into the payment form field of the second application. The method according to claim 1.

3. The first application further comprises receiving the VAN from the server after the encrypted data has been verified. The method according to claim 2.

4. The link is a uniform resource locator (URL), The method according to claim 1.

5. The parameters of the URL include the identifier of the second application, The method according to claim 4.

6. Generating the link directed to the second application is based on the identifier of the second application received at the URL. The method according to claim 5.

7. The first application further comprises registering the local server as a background task with the mobile operating system of the mobile device. The method according to claim 1.

8. The second application further comprises establishing a connection with the local server on a designated port on a local loopback Internet Protocol (IP) address. The method according to claim 1.

9. The parameters of the link having the port are encrypted by the first application, and the method further comprises the second application decrypting the parameters to identify the port. The method according to claim 1.

10. The method further comprises the second application providing a token or certificate to the local server and establishing a verified connection before receiving the data through the port. The method according to claim 1.

11. The data further comprises at least one of an expiration date, a card verification value (CVV), a name, and an address, and the auto-filling comprises auto-filling at least one of the expiration date, the CVV, the name, or the address into the corresponding form field. The method according to claim 1.

12. The first application is a financial institution application, and the second application is a vendor application. The method according to claim 1.

13. The method further comprises the first application calling the application programming interface (API) of a mobile operating system and confirming that the second application is installed on the mobile device before generating the link directed to the second application. The method according to claim 3.

14. A computing device, Processor and The system includes a memory that stores instructions for configuring a mobile device as follows, which are executed by the aforementioned processor, The instruction refers to the mobile device, The first application is, Receiving encrypted data from a contactless card, Sending encrypted data to a server for verification, Receiving an instruction from the server that the encrypted data has been verified, Based on the received verification, the local server will be started on the port, The process involves generating a link to a second application that runs on the aforementioned processor, wherein the parameters of the link include the aforementioned port. It is configured to perform, The second application is, Receiving data from the local server via the port, The received data is automatically entered into the form fields of the second application, Configured to perform, Configure it as follows: Computing device.

15. The data received by the second application comprises a virtual account number (VAN), and the automatic input of the data comprises the automatic input of the VAN into the payment form field of the second application. The computing device according to claim 14.

16. The first application further comprises receiving the VAN from the server after the encrypted data has been verified. The computing device according to claim 15.

17. The first application further comprises registering the local server as a background task with the mobile operating system of the mobile device, wherein the local server continues to run even while the second application is running in the foreground. The computing device according to claim 14.

18. The second application further comprises establishing a connection with the local server on a designated port on a local loopback Internet Protocol (IP) address. The computing device according to claim 14.

19. The parameters of the link having the port are encrypted by the first application, and the computing device further comprises the second application decrypting the parameters to identify the port. The computing device according to claim 14.

20. The data further comprises at least one of an expiration date, a card verification value (CVV), a name, and an address, and the auto-filling comprises auto-filling at least one of the expiration date, the CVV, the name, or the address into the corresponding form field. The computing device according to claim 14.

Images