Application-based point-of-sale system in a mobile operating system

Abstract

Application-based point of sale system in a mobile operating system. A first application can generate a first URL to a second application, a parameter of the first URL including an identifier of the first application. A mobile operating system (OS) can access the first URL to open the second application. The second application can receive a virtual account number (VAN) from a server. The second application can initiate the server on a port and generate a second URL to the first application, a parameter of the second URL including the port. The OS can access the second URL to open the first application. The first application can establish a connection with the server using the specified port and receive the VAN from the second application via the connection. The first application can automatically populate the VAN into a form field of a payment form in the first application.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 876,473, filed May 18, 2020, entitled “Application-Based Point of Sale System in Mobile Operating Systems”. The contents of the aforementioned patent application are incorporated herein by reference in their entirety. Technical Field

[0003] The embodiments described herein generally relate to computing platforms, and more specifically to providing application-based point-of-sale systems within mobile operating systems. Background Technology

[0004] Some mobile operating systems impose restrictions on communication between two or more applications running on the same device. For example, some mobile operating systems may prevent one application from communicating directly with another. Similarly, some mobile operating systems may restrict data exchange between such applications. Doing so may unnecessarily restrict legitimate and secure communication between applications. Summary of the Invention

[0005] The embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for communication between applications in a mobile operating system. In one example, a first application may generate a first URL pointing to a second application, the parameters of which include an identifier of 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 initiate a connection to the server on a specified port and generate a second URL pointing 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 a specified port and receive the VAN from the second application via that connection. The first application may automatically populate the VAN into form fields of a payment form in the first application. Attached Figure Description

[0006] Figure 1A-1F An embodiment of a system for an application-based point-of-sale system in a mobile operating system is shown.

[0007] Figure 2A-2D An embodiment of a system for an application-based point-of-sale system in a mobile operating system is shown.

[0008] Figures 3A-3C An example of an application-based point-of-sale system in a mobile operating system is shown.

[0009] Figure 4 An embodiment of the first logic flow is shown.

[0010] Figure 5 An embodiment of the second logic flow is shown.

[0011] Figures 6A-6B An example of a contactless card is shown.

[0012] Figure 7 An embodiment of the computing system is shown. Detailed Implementation

[0013] The embodiments disclosed herein provide techniques for application-based point-of-sale systems accessible by other applications within a mobile operating system that restricts communication between applications registered to different developers. Generally, a first application running on a device can benefit from data available from a second application on the device. For example, the first application could be a merchant application registered with a merchant in the OS, while the second application could be an application provided by a financial institution registered with a financial institution in the OS. In such an example, a user of the merchant application could request data from the financial institution application, such as payment information, biographical information, etc., within the merchant application. In response to this request, the merchant application could generate a first Uniform Resource Locator (URL) pointing to the financial institution application. Parameters of the first URL could include an identifier for the merchant application.

[0014] The merchant app can then instruct the mobile OS to open or otherwise access the first URL. Doing so causes the mobile OS to open the financial institution app on the device. The financial institution app can then initiate a local server within the OS, which can only access apps running on mobile devices. The local server can be initiated on a port and can be a Transmission Control Protocol / Internet Protocol (TCP / IP) server or any other type of server (e.g., a Hypertext Transfer Protocol (HTTP) server). In some embodiments, the financial institution app can receive authentication credentials for the financial institution account before initiating the server. For example, if a user has not provided login credentials within a threshold time period (e.g., 30 days), the financial institution app can request login credentials from the user. Additionally and / or alternatively, before initiating the server, the financial institution app can receive encrypted data from a contactless card associated with the account and transmit the encrypted data to an authentication server. The authentication server can attempt to decrypt the encrypted data. If the server decrypts the encrypted data, the server can send an indication to the financial institution app that the encrypted data has been verified. Furthermore, if the server decrypts the encrypted data, the server can generate a Virtual Account Number (VAN) for the account. The server can provide financial institution applications with the generated VAN, the VAN's expiration date, and the VAN's Card Verification Value (CVV). Additionally, the server can provide financial institution applications with other data such as first and last name, phone number, email address, billing address, and / or delivery address.

[0015] The financial institution application can generate a second URL pointing to the merchant application. This second URL can be at least partially based on an identifier of the merchant application specified as a parameter in the first URL. The second URL can also specify the port of the local server as a parameter. The financial institution application can also register the local server and / or the financial institution application as background tasks with the OS, allowing the local server and / or the financial institution application to continue running in the background of the OS, while other applications (e.g., the merchant application) run in the foreground of the OS. The financial institution application can instruct the mobile OS to open or otherwise access the second URL. Doing so causes the OS to open the merchant application in the foreground of the operating system.

[0016] Once opened, the merchant application can identify the port of the local server specified in the second URL and establish a connection with the local server at the specified port on the local interface (e.g., the local loopback IP address). In some embodiments, the merchant application may provide a server-verifiable certificate as part of establishing the connection. Additionally and / or alternatively, the merchant application may provide a server-verifiable token as part of establishing the connection. Once the connection is established, the financial institution application can exchange data with the merchant application through the connection, and vice versa. For example, the financial institution application can use the connection to provide the merchant application with VAN, expiry date, and CVV and / or other information (e.g., address information, etc.). In such an example, the merchant application can automatically populate the received data into a form, allowing the user to complete a purchase or other action using the received data. More generally, any amount and type of data can be exchanged via this connection.

[0017] Advantageously, the mobile OS can restrict external entities' access to the local server. This enhances the security of the device and any data. Furthermore, payment data security is strengthened by securely receiving payment data from financial institution applications. For example, users are no longer required to manually enter VANs, expiry dates, and / or CVVs, which could compromise data security. Additionally, in some embodiments, financial institutions can provide a framework (e.g., a Software Development Kit, SDK) that includes the functionality required to perform the operations disclosed herein. This allows only the necessary functionality to be integrated into third-party applications (e.g., merchant applications), without requiring a full SDK and / or framework to perform the operations disclosed herein. For example, by providing one or more APIs to the merchant application that can be used to exchange data, the SDK allows the merchant application to be scaled down relative to the full codebase of the financial institution application included within the merchant application, to provide the required functionality within the merchant application.

[0018] Referring primarily to the symbols and nomenclature used herein, one or more parts of the detailed description below may be presented based on procedural processes executed on a computer or computer network. Those skilled in the art use these procedural descriptions and representations to most effectively convey the substance of their work to others skilled in the art. The processes described herein are generally conceived as a self-consistent sequence of operations leading to a desired result. These operations are those that require physical manipulation of physical quantities. Typically, although not strictly necessary, these physical quantities take the form of electrical, magnetic, or optical signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. Primarily for the sake of convention, these signals are sometimes referred to as bits, values, elements, symbols, characters, terms, numbers, etc., as it proves convenient. However, it should be noted that all these and similar terms are associated with appropriate physical quantities and are merely convenient notations applicable to those quantities.

[0019] Furthermore, these manipulations are often referred to by terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such capability of a human operator is not necessary, or in most cases undesirable. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings of this document, and / or including devices or digital computers specifically constructed for the desired purpose. The various embodiments also relate to devices or systems for performing these operations. These devices can be specifically constructed for the desired purpose. The necessary structures for the various such machines will be apparent from the given description.

[0020] Referring now to the accompanying drawings, wherein the same reference numerals are consistently used to refer to the same elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding thereof. However, it will be apparent, however, that these novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate the description thereto. It is intended to cover all modifications, equivalents, and substitutions within the scope of the claims.

[0021] Figure 1A A schematic diagram of an exemplary system 100 consistent with the disclosed embodiments is depicted. As shown, system 100 includes one or more mobile computing devices 110. Mobile device 110 represents any type of network-enabled computing device running a mobile operating system, such as a smartphone, tablet, wearable device, laptop, portable gaming device, etc. Mobile device 110 may include a processor 101 and memory 111. Processor 101 may be any computer processor, including but not limited to: and processor; Applications and security embedded processors; and and Processors; IBM and Cell processor; Core(2) and Processor; and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures may also be used as processor 101. Memory 111 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual 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 memory arrays), polymer memory such as ferroelectric polymer memory, austenite memory, phase change or ferroelectric memory, silicon-silicon oxide-silicon nitride-silicon oxide-silicon (SONOS) memory, magnetic cards or optical cards, device arrays such as redundant array of independent disk drives (RAID), solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage medium suitable for storing information.

[0022] As shown in the figure, the memory 111 of the mobile device 110 includes an instance of a mobile operating system (OS) 112. Example mobile operating system 112 includes... and Mobile operating system. As shown in the figure, OS 112 includes an account application 113 and one or more other applications 114. The account application 113 allows users to perform various account-related operations, such as activating payment cards, checking account balances, purchasing items, processing payments, etc. In some embodiments, users can authenticate using authentication credentials to access certain features of the account application 113. For example, authentication credentials may include a username (or login name) and password, biometric credentials (e.g., fingerprint, Face ID, etc.), and the like. Other applications 114 represent any type of computing application, such as a web browser, merchant application, shopping application, delivery service application, ride-sharing application, messaging application, word processing application, social media application, etc. For example, the first of other applications 114 could be a merchant application provided by a merchant to purchase goods, services, or any other type of item. Another example is a ride-sharing application that allows users to arrange and pay for transportation services. Yet another example is a delivery service application that allows users to order takeout.

[0023] Due to the limitations imposed by OS 112, applications registered (or assigned) to different developers (or entities) may be unable to communicate and / or exchange data. For example, if such limitations are in place, account application 113 (registered with a financial institution as the developer) cannot communicate and / or exchange data with other applications 114 (registered with entities other than financial institutions). 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). Application registration can be performed when these applications are submitted to an app store associated with the provider of OS 112. However, advantageously, the embodiments disclosed herein provide techniques to securely allow communication and / or data exchange between applications registered with different developers (e.g., account application 113 with any other application 114, and / or any two other applications 114).

[0024] Figure 1BAn embodiment is illustrated where application 114-1 has received a request to communicate with account application 113. For example, application 114-1 could be an application registered with a merchant. In such an example, a user can select one or more items to purchase via application 114-1. During the checkout process, application 114-1 can offer the user the option to use account application 113 to provide payment and / or personal information. The user can then accept the option, thereby instructing application 114-1 to communicate with account application 113 to receive data. In response to this request, application 114-1 can generate URL 125. URL 125 can point to account application 113. URL 125 may also include a parameter indicating that application 114-1 has generated URL 125. URL 125 can be a generic link or any type of URL. The parameter can be any identifier suitable for uniquely identifying application 114-1, such as a unique identifier, token, or URL string. For example, URL 125 could be “capitalone: / / ?appid=merchantapp”, where the “capitalone: / / ” part points to an instance of account application 113 on device 110, and “appid=merchantapp” is the identifier of application 114-1 that generated URL 125.

[0025] In some embodiments, application 114-1 uses the application programming interface (API) of OS 112 to determine whether URL 125 is valid (e.g., indicating whether the application targeted by URL 125 is installed on device 110). For example, OS 112 may provide a "canOpenURL" API, which indicates whether a URL provided as input to the API is valid. Generally, when submitting an application to an app store, the application developer may register one or more URLs with the provider of OS 112. This facilitates verification of the API provided by the OS. In such an example, application 114-1 may provide the API with URL 125 (and / or a portion of URL 125 pointing to account application 113), indicating whether account application 113 is installed on the device and can be opened using URL 125. This enhances security by ensuring the correct application is installed and by preventing third parties from attempting to provide an application impersonating account application 113. In the latter case, impersonation attempts can be prevented because third-party applications will not register with the URL provided as input to the API. In such an example, if the API returns an invalid response, accessing URL 125 can cause OS 112 to launch a web browser pointing to a website associated with the entity of the registered account application 113 (e.g., a financial institution's website and / or an app store where account application 113 can be downloaded).

[0026] Application 114-1 and / or OS 112 can then access, open, or otherwise follow URL 125, thereby opening account application 113 in the foreground of OS 112. Figure 1C An embodiment is depicted in which an account application 113 is opened in response to accessing URL 125. In response, the account application 113 may optionally receive authentication credentials for the account. In some embodiments, the account application 113 determines whether the user's last provision of authentication credentials exceeded a threshold (e.g., 30 days, 60 days, etc.). For example, if the user has not provided a login / password within 75 days, and the threshold is 30 days, the account application 113 may request the user to provide a login / password, biometric credentials, etc. Additionally and / or alternatively (and as referenced) Figure 2A-2D (Discussed in more detail), account application 113 may optionally initiate verification of previously generated encrypted data on the contactless card.

[0027] Account application 113 can then initiate a local server 115 to run on mobile device 110. Local server 115 can be any type of server, such as a TCP / IP server, HTTP server, Hypertext Transfer Protocol Secure (HTTPS) server, streaming server, etc. However, only local applications (e.g., applications running on mobile device 110) can access local server 115. OS 112 can restrict external sources (e.g., via the network) from attempting to access local server 115. Account application 113 can initiate a local server 115 on a specific port number. Account application 113 can choose the port based on any feasible options, such as randomly generating a port number, using a pre-defined port number, etc.

[0028] Figure 1DAn embodiment of account application 113 generating URL 126 is depicted. URL 126 may point to application 114-1 and may include the port number of local server 115. For example, URL 126 may be “merchantapp: / / ?port=2080”, where the “merchantapp: / / ” portion points 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 pointing 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 include any parameters sufficient to establish a connection to local server 115 at a selected port. In some embodiments, account application 113 may encrypt the port number or any additional parameters of URL 126, for example, using an encryption key or public key. In such embodiments, application 114-1 may decrypt the port number and / or additional parameters, for example, using a corresponding decryption key (e.g., a private key). Furthermore, any URL parameters exchanged between any applications may be encrypted to enhance security.

[0029] Furthermore, account application 113 can register local server 115 and / or account application 113 as background tasks with OS 112. This allows local server 115 and / or account application 113 to continue running in the background of OS 112, while other applications run in the foreground of OS 112. Although local server 115 has already been initiated, in some embodiments, account application 113 can initiate local server 115 after URL 126 has been generated.

[0030] Figure 1EAn embodiment is illustrated where account application 113 and / or OS 112 have opened URL 126 to open application 114-1, while local server 115 and / or account application 113 continue to execute in the background of OS 112. In response to receiving URL 126, application 114-1 can identify the port number of local server 115 that is specified as a parameter in URL 126. As described above, if URL 126 includes encrypted data, application 114-1 can decrypt the encrypted port number (or any other relevant parameter) in URL 126. Application 114-1 can then request the establishment of a connection with local server 115 at a specified port, such as a local loopback IP address (e.g., 127.0.0.1 for IPv4, ::1 for IPv6, etc.), the hostname "localhost", or another predefined local IP address. This connection can be established using protocols supported by local server 115 (e.g., TCP / IP connection establishment, etc.). In some embodiments, application 114-1 provides a token and / or digital certificate (or signature) as part of the connection request to local server 115-1. Local server 115 can determine whether the token is valid and / or expected (e.g., the token identifies application 114-1 and matches a token received as a parameter of URL 125). Similarly, local server 115 can verify the certificate using the public key associated with application 114-1. If the token and / or certificate is verified, local server 115 can establish a connection with application 114-1. Otherwise, local server 115 can reject the connection request.

[0031] Figure 1E An embodiment is illustrated where a connection has been established between application 114-1 and local server 115 (and local server 115 continues to execute as a background task in OS 112). As shown, account application 113 may include data 117. Data 117 may be any type of data stored on a local device. 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, phone number, or any other attribute of account application 113's account. Advantageously, local server 115 may provide data 117 to application 114-1 while local server 115 executes in the background of OS 112 and application 114-1 executes in the foreground of OS 112. In some embodiments, local server 115 may encrypt data 117. In such an embodiment, application 114-1 may decrypt data 117 upon receipt.

[0032] Figure 1FAn embodiment is shown where application 114-1 has received data 117 from local server 115. As described above, in some embodiments, application 114-1 can decrypt data 117, if it is encrypted. Application 114-1 can identify data 117 and determine that data 117 includes one or more attributes of a user and / or associated account. Application 114-1 can then automatically populate data 117 into one or more form fields, allowing the user to complete checkout using data already securely received from local server 115. As described above, this allows data 117 to be securely transferred between applications on the same device 110. Furthermore, by requiring only a minimal set of requirements (e.g., API, minimal SDK, etc.), application 114-1 is able to receive any amount of data from local server 115. Otherwise, application 114-1 would be much larger to support the disclosed functionality. Additionally, the embodiments disclosed herein allow application 114-1 and application 113 to exchange data even if these applications are registered with different developers.

[0033] Figure 2A A schematic diagram of an exemplary system 200 consistent with the disclosed embodiments is depicted. As shown, 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, gift card, etc. The contactless card 201 may include one or more communication interfaces 209, such as a radio frequency identification (RFID) chip, configured to communicate with the computing device 110 in wireless communication via NFC, EMV standards, or other short-range protocols. While NFC is used as an example 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, computing cluster, cloud computing platform, virtualized computing system, etc.

[0034] As shown in the figure, the contactless card's memory 202 includes an applet 203, a counter 204, a private key 205, a variability 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, variability key 206, and customer ID 207 are used to provide security in system 200, as described in more detail below.

[0035] As described above, 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. Therefore, Figure 2A An embodiment is depicted where account application 114-1 has generated and accessed URL 125 pointing to account application 113. OS 112 can then open account application 113, which can receive authentication credentials for the user account. Account application 113 can then instruct the user to tap contactless card 201 against device 110. Typically, once contactless card 201 is brought within communication range of device 110's communication interface 218 (e.g., card reader / card writer), applet 203 of contactless card 201 can generate encrypted data as part of the authentication process required to activate contactless card 201. To enable NFC data transfer between contactless card 201 and mobile device 110, account application 113 can communicate with contactless card 201 when contactless card 201 is sufficiently close to the communication interface 218 of mobile device 110. Communication interface 218 can be configured to read from and / or communicate with the communication interface 209 of contactless card 201 (e.g., via NFC, Bluetooth, RFID, etc.). Therefore, example communication interface 218 includes an NFC communication module, a Bluetooth communication module, and / or an RFID communication module.

[0036] As described above, system 100 is configured to implement key diversification to protect data, which may be referred to herein as key diversification techniques. Typically, server 220 (or another computing device) and contactless card 201 may be equipped with the same private key 205 (also referred to as the master key or master symmetric key). More specifically, each contactless card 201 is programmed with a unique private key 205, which has a corresponding key pair in server 220 (or is managed by server 220). For example, when contactless card 201 is manufactured, the unique private key 205 may be stored in the memory 202 of contactless card 201. Similarly, the unique private key 205 may be stored in the account data 224 of server 220 in the records (or profiles) of customers associated with contactless card 201 (and / or stored in a different secure location, such as a hardware security module (HSM) 225). The private key 205 can be kept secret from parties other than contactless card 201 and server 220, thereby enhancing the security of system 100. In some embodiments, the applet 203 of the contactless card 201 can encrypt and / or decrypt data (e.g., customer ID 207) using a private key 205 and data as input cryptographic algorithms. For example, encrypting customer ID 207 using private key 205 can result in an encrypted customer ID. Similarly, the authentication server 220 can encrypt and / or decrypt data associated with the contactless card 201 using the corresponding private key 205.

[0037] In some embodiments, a counter 204 and / or a private key 205 of the contactless card 201 and server 220 may be used in conjunction with counter 204 to enhance security using key diversification. Counter 204 includes a value synchronized between a given contactless card 201 and server 220. Counter value 204 may include a number that changes each time data is exchanged between contactless card 201 and server 220 (and / or contactless card 201 and mobile device 110). When ready to send data (e.g., to server 220 and / or mobile device 110), applet 203 of contactless card 201 may increment counter value 204. Contactless card 201 can then provide private key 205 and counter value 204 as input to a cryptographic algorithm that produces a diversified key 206 as output. The cryptographic algorithm may include encryption algorithms, hash-based Message Authentication Code (HMAC) algorithms, ciphertext-based Message Authentication Code (CMAC) algorithms, etc. Non-limiting examples of cryptographic 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 more detail in U.S. Patent Application 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0038] Continuing with the key diversification example, the contactless card 201 can then use a diversification key 206 and data as input to a cryptographic algorithm to encrypt data (e.g., customer ID 207 and / or any other data). For example, encrypting customer ID 207 using diversification key 206 can result in encrypted customer ID 208. Once generated, applet 203 can transmit the encrypted customer ID 208 to mobile device 110, for example, via NFC. Account app 113 can then transmit the encrypted customer ID 208 to authentication server 220 via network 230.

[0039] Then, authentication application 223 can attempt to authenticate the encrypted data. For example, authentication application 223 can attempt to decrypt the encrypted customer ID 208 using a copy of the private key 205 stored by server 220. In another example, authentication application 223 can provide the private key 205 and counter value 204 as input to a cryptographic algorithm that produces a diversification key 206 as output. The generated diversification key 206 can correspond to the diversification key 206 of contactless card 201, which can be used to decrypt the encrypted customer ID 208. Therefore, authentication application 223 can successfully decrypt the encrypted data, thereby verifying the encrypted customer ID 208. For example, as described above, customer ID 207 can be used to generate the encrypted customer ID 208. In such an example, authentication application 223 can use the private key 205 of authentication server 220 to decrypt the encrypted customer ID 208. If the decryption results in a customer ID 207 associated with an account in account data 224, authentication application 223 verifies the encrypted customer ID 208. Furthermore, authentication application 223 can instruct VAN generator 226 to generate a virtual account, expiration date, and CVV for the account corresponding to the customer ID. VAN generator 226 can then store the generated VAN, expiration date, and CVV indication in a record associated with the account in account data 224. A virtual account is a temporary (e.g., one-time use) number generated using a random number generator or other random function. In some embodiments, the VAN can be linked to contactless card 201, which is tapped onto device 110 to generate an encrypted customer ID 208. In other embodiments, if a user has already authenticated their account using valid account credentials from account application 113, the VAN can be linked to a different contactless card 201 associated with the authenticated account (e.g., where the authenticated account holder has two or more cards 201, and taps the first card 201 onto device 110 to generate a VAN linked to the second card 201). Advantageously, using a VAN instead of an actual account (e.g., an account printed on a contactless card 201) maintains the security of the actual account.

[0040] If authentication application 223 is unable to decrypt the encrypted customer ID 208 to produce the expected result (e.g., customer ID 207 of the account associated with contactless card 201), then authentication application 223 does not verify the encrypted customer ID 208, and VAN generator 226 does not generate a VAN. Due to the verification failure, authentication application 223 may return an error to account application 113, which may prevent the initiation of local server 115.

[0041] Regardless of the decryption technology used, authentication application 223 can successfully decrypt the encrypted customer ID 208, thereby verifying the encrypted customer ID 207 (e.g., by comparing the generated customer ID 208 with the customer ID stored in account data 224, and / or based on an indication of successful decryption using keys 205 and / or 206). While keys 205 and 206 are described as being stored in memory 222, they can be stored elsewhere, such as in a secure element and / or HSM 225. In such an embodiment, the secure element and / or HSM 225 can decrypt the encrypted customer ID 207 using keys 205 and / or 206 along with cryptographic functions. Similarly, the secure element and / or HSM 225 can generate a diversified key 206 based on the private key 205 and counter value 204 as described above. Although depicted as being hosted on the same system, authentication application 223 and VAN generator 226 can be hosted on different systems. In some embodiments, the orchestration layer (OL) may arrange for the authentication application 220 to check the encrypted data and / or for the VAN generator 226 to generate the VAN.

[0042] Figure 2B An embodiment of authentication application 223 verifying encrypted customer ID 208 is depicted. As shown, authentication application 223 can return an indication of verification 210 to account application 113. Similarly, VAN generator 226 can transmit VAN 227 (which includes an expiration date and CVV) to account application 113. In some embodiments, VAN 227 is transmitted along with verification 210. In other embodiments, VAN 227 is transmitted separately from verification 210. Based on verification 210 and / or receiving VAN 227, account application 113 can determine the initiating local server 115. In some embodiments, VAN 227 is generated and / or transmitted after initiating local server 115. Furthermore, account application 113 can receive other data from server 220, such as first name, last name, phone number, email address, billing address, and / or delivery address associated with the account in account data 224.

[0043] Figure 2C An embodiment is depicted in which account application 113 has initiated a connection to local server 115 on device 110. As shown, local server 115 includes VAN 227. Account application 113 can then generate a URL that includes the port number of local server 115, where the URL points to requesting application 114-1. The URL then opens requesting application 114-1, allowing application 114-1 to establish a connection with local server 115, which is running in the background of OS 112.

[0044] Figure 2D An embodiment is illustrated where another application 114-1 has established a connection with the local server 115. As shown, the local server 115 can provide the other application 114-1 with VAN 227 (including the expiry date and CVV). The other application 114-1 can then automatically populate VAN 227 into forms presented in the other application 114-1, such as payment forms. As mentioned above, the local server 115 can also provide other account-related details, such as the billing address associated with VAN 227, the account billing address in account data 224, the shipping address from account data 224, the account holder's name, etc. This allows the other application 114-1 to automatically populate relevant data into one or more form fields to automate at least a portion of the checkout process (or other processes or workflows in the other application 114-1). More generally, the account application 113, which includes the local server 115, provides an application-based point-of-sale system that can access other applications in the mobile operating system 112, even if these applications may be registered to different entities in OS 112.

[0045] Figure 3A This is a schematic diagram 300 depicting an example embodiment enabling communication between applications in a mobile operating system. As shown in the figure... Figure 3A This includes a mobile device 110 executing example application 114. For example, application 114 could be an application that allows users to place orders and provide order or payment information. As shown, the graphical user interface (GUI) of application 114 includes a payment form with fields 301-305, where field 301 is a name field, field 302 is an account number field, field 303 is an expiration date field, field 304 is a CVV field, and field 305 is an address field. As shown, application 114 can output notification 309, specifying the selection notification 309 to complete checkout using a virtual account from a banking application (e.g., account application 113).

[0046] Figure 3B This is a schematic diagram 310 illustrating an embodiment where the user has selected notification 309. Doing so causes application 114 to generate a URL 125 to account application 113, where URL 125 includes an identifier for application 114 as a parameter. Once opened, URL 125 causes account application 113 to open in the foreground of OS 112. Figure 3BAs shown, account application 113 can instruct the user to provide authentication credentials (not shown) and output notification 306, specifying that the contactless card 201 be tapped onto mobile device 110 to continue authentication. Once the contactless card 201 is tapped onto mobile device 110, account application 113 transmits an instruction to contactless card 201 via communication interface 218 to generate encrypted data as described above (e.g., encrypted customer ID 208), and transmits the encrypted data to account application 113. Once received, account application 113 can then transmit the encrypted data to server 220, where authentication application 223 verifies the encrypted data using key diversification as described above. Authentication application 223 can then transmit a verification instruction to account application 113. Furthermore, if the encrypted data is verified, authentication application 223 can instruct VAN generator 226 to generate a VAN, VAN expiration date, and VAN account number. VAN generator 226 can then transmit the VAN, expiration date, and CVV to account application 113. In addition, server 220 can send additional data to account application 113, such as account holder's name, billing address, delivery address, phone number, email address, etc.

[0047] Once account application 113 receives an instruction from designated server 220 that the encrypted data has been verified, account application 113 can initiate a request to local server 115 on device 110. Account application 113 can then generate a URL 126 pointing to requesting application 114, wherein the parameters of URL 126 include the port number of local server 115. Application 114 can then connect to local server 115 as described above and request relevant data, such as name, address, VAN, expiration date, and CVV.

[0048] Figure 3C This is a schematic diagram 320 depicting an embodiment where application 114 has received requested data from local server 115. Application 114 may include an SDK or API that allows application 114 to request and / or receive data and parse any received data. As shown, application 114 can automatically populate the user's name into name field 201, virtual account into account field 302, expiration date into expiration date field 303, CVV into CVV field 304, and address into address field 305. The user can then complete the purchase using button 311. This completes the purchase. Furthermore, the data populated in fields 301-305 can be stored in a user profile associated with application 114.

[0049] The operation of the disclosed embodiments can be further described with reference to the following accompanying drawings. Some of the drawings may include logical flows. While these drawings presented herein may include specific logical flows, it should be understood that these logical flows merely provide examples of how the general functions described herein can be implemented. Furthermore, unless otherwise stated, the given logical flows do not necessarily have to be executed in the order presented. Moreover, the given logical flows may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. The embodiments are not limited to this context.

[0050] Figure 4 An embodiment of logic flow 400 is illustrated. Logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 400 may include some or all of the operations providing an application-based point-of-sale system in a mobile operating system. The embodiments are not limited to this context.

[0051] As shown in the figure, logic flow 400 begins at box 405, where device 110 outputs a first application in the foreground of mobile OS 112. For example, the first application could be application 114-1, which could be an application provided by a merchant. At box 410, the first application can receive an instruction specifying that data be received from a second application. The second application could be account application 113. For example, while attempting to order goods using the merchant application, the user can specify that payment for the goods be made using a virtual account from account application 113. At box 415, the first application generates a first URL pointing to the second application. The first URL may include a unique identifier of the first application as a parameter.

[0052] At box 420, OS 112 allows access to the first URL, thereby opening a second application (e.g., account application 113) in the foreground of OS 112. At box 425, the second application can receive authentication credentials for the account and / or encrypted data from contactless card 201. For example, a user can provide biometric credentials and tap their contactless card 201 against device 110, causing card 201 to generate and transmit encrypted data. The second application can then transmit the encrypted data to authentication server 220. When the encrypted data is verified, server 220 can generate a VAN, expiry date, and CVV for the account. At box 430, the second application receives the VAN, expiry date, CVV, and verification of the encrypted data from server 220. At box 435, the second application creates a local server 115 on a designated port on mobile device 110.

[0053] At box 440, the second application generates a second URL. The second URL may point to the first application. Parameters of the second URL may include the port number of the local server 115. At box 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 execute in the background of OS 112 for a period of time. In some embodiments, the second application encrypts the parameters of the second URL. At box 450, the second URL is accessed to open the first application in the foreground of OS 112, while the local server 115 and / or the second application continue to execute in the background of OS 112. The first application may decrypt the parameters of the second URL (if encrypted).

[0054] At box 455, the first application establishes a connection with local server 115. At box 460, the first application requests and receives data (including VAN, expiry date, and CVV) from local server 115. If encrypted, the first application can decrypt the received VAN, expiry date, and CVV. At box 465, the first application processes the received data. For example, application 114 can automatically populate the VAN, expiry date, CVV, address information, first name, and last name into a payment form. The user can then use the automatically populated payment information to complete the purchase in merchant application 114.

[0055] Figure 5 An embodiment of logic flow 500 is illustrated. Logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 500 may include some or all of the operations providing an application-based point-of-sale system in a mobile operating system. The embodiments are not limited to this context.

[0056] As shown in the figure, logic flow 500 begins at block 505, where a user brings a contactless card 201 into the communication range of mobile device 110 (e.g., using a tap gesture) to cause the contactless card 201 to generate and transmit encrypted data (e.g., an encrypted customer ID 208). At block 510, applet 203 of the contactless card 201 generates a diversity key 206 by encrypting a counter value 204 and a master key 205 stored in the memory 202 of the contactless card using a cryptographic algorithm. In some embodiments, applet 203 may increment the counter 204 before encryption. At block 515, the contactless card 201 encrypts data (e.g., a customer identifier 207) using the diversity key 206 and a cryptographic algorithm to generate encrypted data (e.g., an encrypted customer ID 208).

[0057] At block 520, the contactless card 201 can, for example, use NFC to transmit encrypted data to the account application 113 of the mobile device 110. At block 525, the account application 113 of the mobile device 110 can transmit data received from the contactless card 201 to the authentication application 223 of the server 220. At block 530, the authentication application 223 of the server 220 can use the private key 205 and the counter value 204 to generate a diversity key 206 as input to a cryptographic algorithm. In one embodiment, the authentication application 223 increments the counter value 204 of the server 220 to synchronize with the counter value 204 in the memory of the contactless card 201.

[0058] At box 535, authentication application 223 uses diversity key 206 to decrypt the encrypted customer ID 208 received from contactless card 201 via mobile device 110. This generates at least customer ID 207. By generating customer ID 207, at box 540, authentication application 223 can verify the data received from contactless card 201. For example, authentication application 223 can compare customer ID 207 with the customer identifier of the associated account in account data 224 and verify the data based on the match. At box 545, VAN generator 226 generates a VAN, expiration date, and CVV based on the verification of the encrypted data at box 540.

[0059] At box 550, server 220 may transmit the VAN, expiry date, CVV, and an indication that the encrypted data has been verified to account application 113. In some embodiments, the verification indication is not transmitted. In such embodiments, the transmission of VAN, expiry date, and CVV (and / or any other account-related data) serves as an indication that the encrypted data has been verified. At box 555, account application 113 may initiate local server 115. Doing so allows local server 115 to act as a point-of-sale application for other applications running on mobile device 110, for example, by providing VAN and related data to complete a purchase in other applications.

[0060] Figure 6AA contactless card 201 is shown, which may include payment cards such as credit cards, debit cards, and / or gift cards. As shown, the contactless card 201 may be issued by a service provider 602 displayed on the front or back of the card 201. In some examples, the contactless card 201 is not a payment card and may include, but is not limited to, an identity card. In some examples, the payment card may include 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 layers composed of plastics, metals, and other materials. Exemplary substrate materials include: polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 201 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 201 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of a contactless card in a payment card.

[0061] 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 a connection with another communication device, such as a mobile device 110, user equipment, smartphone, laptop, desktop computer, or tablet computer. The contactless card 201 may also include... Figure 6A The processing circuitry, antenna, and other components are not shown. These components may be located behind the contact patch 620 or elsewhere on the substrate 610. The contactless card 201 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card. Figure 6A (Not shown in the image).

[0062] like Figure 6B As shown, the contact pad 620 of the contactless card 201 may include a processing circuitry system 625 for storing and processing information, which includes a microprocessor 630 and a memory 202. It should be understood that the processing circuitry system 625 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware necessary to perform the functions described herein.

[0063] Memory 202 can be a read-only memory, a write-once-read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 201 may include one or more of these memories. Read-only memory can be manufacturer-programmable or one-time programmable memory. One-time programmability provides the opportunity to write once and then read many times. Write-once / read-many memory can be programmed at some point after the memory chip has left the factory. Once the memory is programmed, it may not be able to be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can also be read multiple times after leaving the factory.

[0064] Memory 202 can be configured to store one or more applets 203, counter values ​​204, private keys 205, diversity keys 206, and one or more customer IDs 207. The one or more applets 203 may include one or more software applications configured to execute on one or more contactless cards, such as... The Card app. However, it should be understood that the Card app is not limited to... The Card app, instead, can be any software application that operates on contactless cards or other devices with limited memory. Customer ID 207 can include a unique alphanumeric identifier assigned to the user of contactless card 201, and this identifier can distinguish the user of the contactless card from other contactless card users. In some examples, Customer ID 207 can identify both the customer and the account assigned to that customer, and can also identify the contactless card associated with the customer account. In some embodiments, app 203 can use Customer ID 207 as input to a cryptographic algorithm with keys 205 and / or 206 to encrypt Customer ID 207. Similarly, app 203 can construct a URL that includes the encrypted Customer ID 207 as a parameter.

[0065] The processor and memory elements of the foregoing exemplary embodiments have been described with reference to the contact patch, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of or completely separate from the patch 620, or may be implemented as other elements besides the processor 630 and memory 202 elements located within the contact patch 620.

[0066] In some examples, the contactless card 201 may include one or more antennas 655. The one or more antennas 655 may be located within the contactless card 201 and around the processing circuitry system 625 of the contact patch 620. For example, the one or more antennas 655 may be integrated with the processing circuitry 625, and the one or more antennas 655 may be used in conjunction with an external boost coil. As another example, the one or more antennas 655 may be located outside the contact patch 620 and the processing circuitry system 625.

[0067] In an embodiment, the coil of the contactless card 201 can act as the secondary winding of an air-core transformer. The terminal can communicate with the contactless card 201 by cutting off power or by amplitude modulation. The contactless card 201 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained by one or more capacitors. The contactless card 201 can perform backhaul by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the coil of the terminal by interference. More generally, using antenna 655, processing circuitry 625, and / or memory 202, the contactless card 201 provides a communication interface for communication via NFC, Bluetooth, and / or Wi-Fi.

[0068] As described above, the contactless card 201 can be built on a software platform operable on smart cards or other devices with limited memory (such as JavaCard), and one or more applications or applets can be securely executed. In various mobile application-based use cases, applets can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA). The applet can be configured to respond to one or more requests (such as a near-field data exchange request) from a reader (e.g., communication interface 218 of device 110) such as a mobile NFC reader, and generate an NDEF message that includes an encrypted secure OTP (e.g., an encrypted customer ID) encoded as an NDEF text tag.

[0069] Figure 7 An embodiment of an exemplary computing architecture 700 is illustrated, which includes a computing system 702 suitable for implementing the various embodiments described above. In various embodiments, the computing architecture 700 may include or be implemented as part of an electronic device. In some embodiments, the computing architecture 700 may represent, for example, a system implementing one or more components of system 100 and / or system 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. The embodiments are not limited to this context. More generally, the computing architecture 700 is configured to implement all the logic, applications, systems, methods, apparatuses, and functions described herein with reference to FIG1-6B.

[0070] As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, which are hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component can be, but is not limited to: a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself can be components. One or more components can reside within a process and / or an execution thread, and components can be located on a single computer and / or distributed between two or more computers. Furthermore, components can be communicatively coupled to each other via various types of communication media to coordinate their operation. This coordination can involve one-way or two-way information exchange. For example, components can transmit information in the form of signals conveyed through a communication medium. Information can be implemented as signals assigned to various signal lines. In this assignment, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages can be sent via various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0071] The computing system 702 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, the embodiments are not limited to the implementation of the computing system 702.

[0072] like Figure 7 As shown, the computing system 702 includes: a processor 704, a system memory 706, and a system bus 708. The processor 704 can be any of a variety of commercially available computer processors, including but not limited to: and processor; Applications and security embedded processors; and and Processors; IBM and Cell processor; Core(2) and Processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures can also be used as processor 704.

[0073] System bus 708 provides interfaces for system components, including but not limited to system memory 706 to processor 704. System bus 708 can be any of several types of bus architectures, which can also interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 708 via slot architectures. Example slot architectures can include, but are not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), Network User Bus (NuBus), Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, PCMCIA, etc.

[0074] System memory 706 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), dual 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 memory arrays), polymer memory such as ferroelectric polymer memory, austenite memory, phase change or ferroelectric memory, silicon-silicon oxide-silicon nitride-silicon oxide-silicon (SONOS) memory, magnetic cards or optical cards, device arrays such as redundant array of independent disk drives (RAID), solid-state storage devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage media suitable for storing information. Figure 7 In the illustrated embodiment, system memory 706 may include non-volatile memory 710 and / or volatile memory 712. The basic input / output system (BIOS) may be stored in non-volatile memory 710.

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

[0076] The drive and associated computer-readable medium provide volatile and / or non-volatile storage for data, data structures, computer-executable instructions, etc. For example, multiple program modules (including operating system 730, one or more application programs 732, other program modules 734, and program data 736) may be stored in the drive and memory units 710, 712. 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 applets 203, counters 204, private keys 205, diversity keys 206, customer IDs 207, operating system 112, account applications 113, other applications 114, authentication applications 223, account data 224, and / or encrypted customer IDs 208.

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

[0078] A monitor 744 or other type of display device is also connected to the system bus 708 via an interface such as a video adapter 746. The monitor 744 can be internal or external to the computing system 702. In addition to the monitor 744, a computer typically includes other peripheral output devices such as speakers, printers, etc.

[0079] Computing system 702 can operate in a networked environment using logical connections to one or more remote computers (such as remote computer 748) via wired and / or wireless communications. Remote computer 748 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computing system 702, although for simplicity, only memory / storage device 750 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 752 and / or a larger network (e.g., a wide area network (WAN) 754). Such LAN and WAN network environments are extremely common in offices and corporations and facilitate enterprise-wide computer networks (such as intranets), all of which can connect to global communications networks (e.g., the Internet). In the embodiment, network 230 of FIG2 is one or more of LAN 752 and WAN 754.

[0080] When used in a LAN networking environment, the computing system 702 is connected to the LAN 752 via a wired and / or wireless communication network interface or adapter 756. Adapter 756 facilitates wired and / or wireless communication to the LAN 752, and the LAN 752 may also include a wireless access point configured thereon for communicating with the wireless functionality of adapter 756.

[0081] When used in a WAN networking environment, computing system 702 may include a modem 758, or a communication server connected to WAN 754, or other means for establishing communication via WAN 754 (such as by means of the Internet). Modem 758 may be a built-in or external wired and / or wireless device connected to system bus 708 via input device interface 742. In a networked environment, program modules depicted relative to computing system 702 or a portion thereof may be stored in remote memory / storage device 750. It will be understood that the network connections shown are exemplary, and other means of establishing communication links between computers may be used.

[0082] The computing system 702 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively configured in wireless communication (e.g., IEEE 802.16 air modulation techniques). This includes, among other things, at least Wi-Fi (or wireless fidelity), WiMax, and Bluetooth. TM Wireless technology. Therefore, communication can be a predefined structure like a regular network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technology called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, connect to the Internet, and connect to wired networks (which use IEEE 802.3 related media and functions).

[0083] Various embodiments can be implemented using hardware components, software components, or a combination of both. Examples of hardware components 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 components 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, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination of whether to implement an embodiment using hardware components and / or software components can vary depending on any number of factors, such as desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0084] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium, representing various logic within a processor, which, when read by a machine, cause the machine to manufacture the logic to perform the techniques described herein. This representation, referred to as an "IP core," can be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into manufacturing machines that manufacture logic or processors. Some embodiments can be implemented, for example, using a machine-readable medium or article of manufacture capable of storing instructions or instruction sets that, when executed by a machine, can cause the machine to perform the methods and / or operations according to the embodiments. Such a machine 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 of manufacture may include, for example, any suitable type of memory cell, memory device, memory article of manufacture, memory medium, storage device, storage article of manufacture, storage medium and / or storage cell, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile optical discs (DAD), magnetic tape, cassette tape, etc. The instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

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

Claims

1. A method for communication between applications in a mobile operating system, comprising: A first URL pointing to a second application is generated by a first application executing on the processor, wherein the parameters of the first URL include an identifier of the first application; The mobile operating system (OS) executing on the processor accesses the second application based on the first URL; The second application receives account-related data from the server; The Transmission Control Protocol / Internet Protocol (TCP / IP) server on the port initiated by the second application; The second application generates a second URL pointing to the first application, wherein the parameters of the second URL include the port; The OS accesses the first application based on the second URL; The first application uses the port specified in the second URL to receive data via a connection to the TCP / IP server; and The data is automatically populated into the form fields of the payment form in the first application by the first application.

2. The method according to claim 1, further comprising: The first application establishes a connection with the TCP / IP server using the port specified in the second URL.

3. The method of claim 1, wherein the data includes one or more of the following: account number associated with the account, account expiry date, account card verification value (CVV), and account billing address.

4. The method of claim 1, further comprising, before the second application receives the data: The second application receives encrypted data from the contactless card; The encrypted data is transmitted from the second application to the server; and The second application receives from the server an instruction specifying that the server decrypts the encrypted data, wherein the second application receives the data at least in part based on the instruction received from the server.

5. The method according to claim 1, further comprising: The second application selects a port number from multiple port numbers as the port.

6. The method according to claim 1, further comprising: The TCP / IP server receives a request to establish the connection from the first application, wherein the request includes the certificate of the first application; The certificate of the first application is verified by the second application; as well as The connection is established by the second application based on the identifier of the first application in the request and the verification of the certificate of the first application, wherein the TCP / IP server can only access applications running on the processor.

7. The method according to claim 1, further comprising: The first application uses the application programming interface (API) of the OS to verify at least a portion of the first URL; as well as The second application uses the OS's API to verify at least a portion of the second URL.

8. A computing device, comprising: processor; and Memory, storage instructions, which, when executed by the processor, cause the processor to: A first URL pointing to a second application is generated by a first application executing on the processor, wherein the parameters of the first URL include an identifier of the first application; The mobile operating system (OS) executing on the processor accesses the second application based on the first URL; The second application receives account-related data from the server; The Transmission Control Protocol / Internet Protocol (TCP / IP) server on the port initiated by the second application; The second application generates a second URL pointing to the first application, wherein the parameters of the second URL include the port; The OS accesses the first application based on the second URL; The first application receives the data via a connection to the TCP / IP server using the port specified in the second URL; and The data is automatically populated into the form fields of the payment form in the first application by the first application.

9. The computing device of claim 8, wherein the instructions further cause the processor to: The first application establishes a connection with the TCP / IP server using the port specified in the second URL.

10. The computing device of claim 8, wherein the data includes one or more of the following: an account number associated with the account, an account expiry date, a card verification value (CVV) of the account, and a billing address of the account.

11. The computing device of claim 8, wherein the instructions further cause the processor, before the second application receives the data: The second application receives encrypted data from the contactless card; The encrypted data is transmitted from the second application to the server; and The second application receives from the server an instruction specifying that the server decrypts the encrypted data, wherein the second application receives the data at least in part based on the instruction received from the server.

12. The computing device of claim 8, wherein the instructions further cause the processor to: The second application selects a port number from multiple port numbers as the port.

13. The computing device of claim 8, wherein the instructions further cause the processor to: The TCP / IP server receives a request to establish the connection from the first application, wherein the request includes the certificate of the first application; The certificate of the first application is verified by the second application; as well as The connection is established by the second application based on the identifier of the first application in the request and the verification of the certificate of the first application, wherein the TCP / IP server can only access applications running on the processor.

14. The computing device of claim 8, wherein the instructions further cause the processor to: The first application uses the OS's application programming interface (API) to verify at least a portion of the first URL; and The second application uses the OS's API to verify at least a portion of the second URL.

15. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: A first URL pointing to a second application is generated by a first application executing on the processor, wherein, The parameters of the first URL include the identifier of the first application; The mobile operating system (OS) executing on the processor accesses the second application based on the first URL; The second application receives account-related data from the server; The Transmission Control Protocol / Internet Protocol (TCP / IP) server on the port initiated by the second application; The second application generates a second URL pointing to the first application, wherein the parameters of the second URL include the port; The OS accesses the first application based on the second URL; The first application uses the port specified in the second URL to receive data via a connection to the TCP / IP server; and The data is automatically populated into the form fields of the payment form in the first application by the first application.

16. The computer-readable storage medium of claim 15, wherein the instructions further cause the processor to: The first application establishes a connection with the TCP / IP server using the port specified in the second URL.

17. The computer-readable storage medium of claim 15, wherein the data includes one or more of the following: an account number associated with the account, an account expiry date, a card verification value (CVV) for the account, and a billing address for the account.

18. The computer-readable storage medium of claim 15, wherein the instructions further cause the processor, before the second application receives the data: The second application receives encrypted data from the contactless card; The encrypted data is transmitted from the second application to the server; and The second application receives from the server an instruction specifying that the server decrypts the encrypted data, wherein the second application receives the data at least in part based on the instruction received from the server.

19. The computer-readable storage medium of claim 15, wherein the instructions further cause the processor to: The second application selects a port number from multiple port numbers as the port.

20. The computer-readable storage medium of claim 15, wherein the instructions further cause the processor to: The TCP / IP server receives a request to establish the connection from the first application, wherein the request includes the certificate of the first application; The certificate of the first application is verified by the second application; as well as The connection is established by the second application based on the identifier of the first application in the request and the verification of the certificate of the first application, wherein the TCP / IP server can only access applications running on the processor.

Images