Method for portable device and user device token processing

Abstract

Described herein is a method for obtaining a token to be used by one or more applications installed on a user device. The token is obtained in response to a portable device interacting with the user device. The user device receives portable device data from the portable device that is interacting with the user device. The user device transmits the portable device data and a device fingerprint to a remote server computer. The remote server computer is configured to subsequently obtain a token associated with the portable device data and the device fingerprint.

Description

METHOD FOR PORTABLE DEVICE AND USER DEVICE TOKEN PROCESSINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a PCT application, which claims priority to U.S. Provisional Application No. 63 / 578,878, filed on August 25, 2023, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] Existing storage applications (e.g., a digital wallet) that use tokens that are bound to user devices such as mobile phones have drawbacks. For instance, such storage applications do not readily share the tokens with all applications installed on the consumer mobile devices. Further, such storage applications may also require the creation of specialized APIs and / or privileges to be pre-configured for successful implementation. Such processes are typically time-consuming as well as resource intensive, and thus have a negative effect on user engagement.

[0003] Additionally, existing token types (e.g., device tokens, e-Commerce tokens, cloud tokens, etc.,) are not linked to portable devices held by the users, and are not associated with portable device cryptogram creation and verification processes. Moreover, the existing token types do not carry consumer device cardholder verification method (CDCVM) information e.g., biometric information, device PIN, device password, etc. As such, the existing security methods associated with the processing of existing token types can be improved.

[0004] Embodiments of the disclosure address this problem and other problems individually and collectively.SUMMARY

[0005] Embodiments of the present disclosure provide for a framework to enable cardholders to interact (e.g., tap) their portable device (e.g., a contactless card) with their own user device (e.g., an NFC smartphone device), in order to complete a transaction (e.g., a transaction to access secure data, a secure location or to purchase goods and / or services). The transactions may be completed from within applications (installed on the mobile devices), or via mobile web pages accessed via the mobile device. The framework described herein also provides for performing a verification of ensuring that a user is in physical possession of the portable device (e.g., a card) when performing certain actions e.g., providing verification of card possession while using a ride-sharing application.

[0006] One embodiment is related to a method comprising: receiving, by a user device, portable device data from a portable device that is interacting with the user device; and transmitting, by the user device, the portable device data and a device fingerprint to a remote server computer, wherein the remote server computer is configured to subsequently obtain a token associated with the portable device data and the device fingerprint.

[0007] One embodiment is related to a method comprising: receiving, by a user device operated by a user, portable device data from a portable device that is interacting with the user device; and transmitting, by the user device, the portable device data and a device fingerprint to a remote server computer, which obtains a token associated with the portable device data and the device fingerprint, wherein the remote server computer subsequently allows the user to access a resource using the token.

[0008] Another embodiment of the invention is directed to a user device comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for performing: receiving portable device data from a portable device that is interacting with the user device; and transmitting the portable device data and a device fingerprint to a remote server computer, wherein the remote server computer is configured tosubsequently obtain a token associated with the portable device data and the device fingerprint.

[0009] These and other embodiments are described in further detail below.

[0010] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows a block diagram of a token provisioning system and overlaid process flow according to embodiments.

[0012] FIG. 2 shows a block diagram of utilizing a token processing system according to embodiments.

[0013] FIG. 3 depicts a block diagram of verification system according to embodiments.

[0014] FIG. 4 depicts a block diagram of a token access system according to some embodiments.

[0015] FIG. 5A shows a block diagram of components of a user device according to embodiments.

[0016] FIG. 5B shows a diagram of an example portable device.

[0017] FIG. 6 shows a diagram showing an exemplary interaction between a portable device and a user device.

[0018] FIG. 7 shows a block diagram of a remote server computer according to an embodiment of the invention.DETAILED DESCRIPTION

[0019] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0020] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. There are a variety of input sensors capable of detecting user input. Exemplary input sensors include accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0021] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0022] A “portable device” can include any suitable device that may be portable. A portable device may be in any suitable form. For example, suitable portable devices may be hand-held and compact so that they can fit into a consumer's wallet and / or pocket (e.g., pocket-sized). They may include smart cards (e.g., contactless smart cards), magnetic stripe cards, keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples of portable devices include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, an electronic or digital wallet, wearable devices such as smart watches, fitness bands, ankle bracelets, rings, earrings, and the like. If the portable device is in the form of a debit, credit, or smartcard, the portable devicecan operate in either a contact or contactless mode, in some embodiments, a portable device may be used to conduct an interaction. For example, a portable device may be used to conduct a transaction, such as to provide payment information to a resource provider.

[0023] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment.

[0024] “Interaction data” can include data related to and / or recorded during an interaction. Interaction data can be provided from a portable device to another device (e.g., a user device, an access device, etc.). Interaction data can be provided in one or more communications between a portable device and a user device (e.g., in one or more application protocol data units (APDUs)). For example, interaction data can be provided from a portable device to a user device in a select PPSe message(s), select AID message(s), get processing options (GPO) message(s), read record message(s), etc. In some embodiments, interaction data can include a primary account number (PAN), a token, a cryptogram, etc.

[0025] “Application data” can include data related to an application. For example, application data can include data related to a resource provider application on a user device (or other device). Application data can include identifiers, certificates, amounts, country codes, currency codes, API keys, and / or any other suitable data created by or utilized by an application.

[0026] “Credentials” may comprise any evidence of authority, rights, or entitlement to privileges. For example, access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file. Examples of credentialsmay include passwords, passcodes, or secret messages. In another example, payment credentials may include any suitable information associated with and / or identifying an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include an “account identifier” such as a PAN (primary account number or “account number”), a token, a sub token, a gift card number or code, a prepaid card number or code, a username, an expiration date, a CW (card verification value), a dCVV (dynamic card verification value), a CW2 (card verification value 2), a CVC3 card verification value, etc. An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some embodiments, credentials may be considered sensitive information.

[0027] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0028] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, insome embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0029] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “de-tokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, de- tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).

[0030] A “token service computer” can include a system that that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and / or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN.

[0031] A “token domain” may indicate an area and / or circumstance in which a token can be used. Examples of the token domain may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e. token domain restrictioncontrols) may be established as part of token issuance by the token service computer that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

[0032] “Token expiry date” may refer to the expiration date / time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g. a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as an time duration as measured from the time of issuance.

[0033] A “token request message” may be an electronic message for requesting a token. A token request message may include information usable for identifying a payment account or digital wallet, and / or information for generating a payment token. For example, a token request message may include payment credentials, mobile communication device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token request message may include a flag or other indicator specifying that the message is a token request message.

[0034] A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, mobile communication device identification information (e.g. a phone number orMSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token response message may include a flag or other indicator specifying that the message is a token response message.

[0035] An “authorization request message” may be an electronic message that requests authorization for an interaction. In some embodiments, it is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction value, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0036] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval - transaction was approved; Decline -- transaction was not approved; or Call Center -response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0037] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorizing entity computer. An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer, or in some embodiments, a portable device.

[0038] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc.

[0039] The term “verification” and its derivatives may refer to a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and / or in good standing.

[0040] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0041] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices.A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0042] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0043] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0044] A “key” may include a piece of information that is used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (3DES), data encryption standard (DES), advanced encryption standard (AES), etc.

[0045] A “key store” is a hardware-implemented repository for security certificates and cryptographic keys. Certificates and keys may be manipulated within the key stores without extracting the private data associated therewith.

[0046] An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0047] A “cryptographic protocol” may include a protocol that performs a security- related function and applies cryptographic methods. The protocol describes how the cryptographic algorithms should be used to secure information. Cryptographic protocols applied to mobile payments may be employed with the various aspects of the present disclosure. Such cryptographic protocols can include AES, DES, 3-DES, and the like.

[0048] An “identifier” may include a primary account number (PAN) and / or an expiration date. In some aspects, an identifier may be “format preserving” and may have a numeric format such as that used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). Non-limiting examples include credit card numbers, bank account numbers, a member number or customer number linked to available resources.

[0049] A “cryptogram” may be an obscured or encoded representation of text. For example a cryptogram may be an obscured or encrypted text string repeating or generated by a cryptographic key.

[0050] An “electronic wallet” or “digital wallet” or “mobile wallet” can store user profile information, payment information (including tokens), bank account information, and / or the like and can be used in a variety of transactions, such as but not limited to eCommerce, social networks, money transfer / personal payments, mobile commerce, proximity payments, gaming, and / or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, and / or the like.

[0051] Aspects of the present disclosure provide for creation of a new token type e.g., a Tap-To-Your-Own-Device (TTYOD) token. According to some embodiments, the token is bound with portable device data (e.g., a primary account number) of a portable device (e.g., a card) held by a user, and a device fingerprint of a user device (e.g., a mobile device such as a smartphone) held by the user. In some embodiments, the device fingerprint may be generated by a software application (installed and executed on the user’s device), which takes as input, one or more parameters such as an ID of the device, a serial number of the device, MAC address of the device, an International Mobile Equipment Identity (IMEI) number of the device (i.e., IMEI number of the user device), etc. The software application may be configured to perform a hash operation or other operation on the input parameters to generate the fingerprint of the device. It is appreciated that each user device operated by a user is assigned a unique device fingerprint. For instance, a first user device (e.g., a smartphone) of the user is associated with a first device fingerprint and a second user device (e.g., a tablet computer) is associated with a second device fingerprint that is different than the first device fingerprint. Moreover, as described below with reference to FIG. 1 , it is appreciated that a request for the token (e.g., request made by the user device to a remote server), as well as the token (supplied to the user device) may carry authentication information of the user e.g., biometric information such as CDCVM information, that can be used for authentication.

[0052] An exemplary mapping of a token to a device fingerprint and portable device data (e.g., a PAN or primary account number) is shown in the Table I below. Table I shows mappings and associations of tokens with respect to three different user devices (e.g., device 1 , device 2, and device 3) and three portable devices (e.g., card 1 , card 2, and card 3). Each of the three devices can have a unique device fingerprint. For example, device 1 has a fingerprint of “998335c1-4c08-492b-83ca-8711824ad47e”, device 2 has a fingerprint of “26c7d731-7683-4736-abe0-cf39ea89f0ee”, and device 3 has a fingerprint of “36179e4a-adb9-4c42-987b-7e70c79b2581”. Further, for each unique portable device / user device combination, a unique token is generated and bound with the portable device data (e.g., a PAN) and the user device fingerprint. As will described below, thetoken is provisioned by a remote server computer. The token can be requested by any application (including web-browser(s)) that is executed on the user device after the provisioning process is completed.

[0053] FIG. 1 shows a block diagram of a token provisioning system 100 according to certain embodiments. The system comprises a portable device 101 (e.g., a contactless card), a user device 103 (e.g., smartphone), a remote server computer 105 (e.g., a token cloud wallet), a token vault 107, and an authorizing entity computer 109 (e.g., an issuer computer). For simplicity of illustration, a certain number of components are shown in FIG. 1. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all the components shown in FIG. 1 .

[0054] The user device 103 can be a mobile device operated by a user 111. The user device 103 can comprise one or more resource provider applications (e.g., application 103A), a capture module 103B, a contactless kernel 103C, and an NFC driver 103D. According to some embodiments, the capture module 103B may correspond to a biometric reader that can obtain a biometric sample from the user 111 of the user device 103. For instance, the biometric reader can be an iris scanner, a palm / hand scanner, a voice scanner, DNA scanner and / or the like. According to some embodiments, the capture module 103B may be configured to obtain any information that may be used to authenticate the user 111. For instance, the capture module 103B may be configured to obtain a credential, secret, or a password to authenticate the user. Such information (including the biometric information of the user) may be collectively referred to herein as consumer device cardholder verification method (CDCVM) information that may be used to authenticate the user 111.

[0055] According to some embodiments, the portable device 101 and the user device 103 can communicate with each other via a short range communication protocol such as NFC. For example, the user 111 may present (e.g., tap, hold near, etc.) the portable device 101 to the user device 103 to exchange data with the user device 103. It is appreciated that the user device 103 may capture such data via the NFC driver 103D. In some implementations, the data transferred from the portable device 101 to the user device 103 may include information such as a primary account number (PAN), a CVV, an expiration date, and / or any other suitable information of the portable device 101 . These data elements can be examples of portable device data. It is noted that the portable device 101 and the user device 103 are operated and held by the user 111 , so they are trusted by the user 111. An example message protocol (i.e., information exchange) included in the interaction between the portable device 101 and the user device 103 is shown in FIG. 6 and is described below.

[0056] The user device 103 includes the contactless kernel 103C that comprises a core program that manages the user device’s processor resources, memory, etc. The contactless kernel may also be configured to handle background threads used byapplications that are installed and executed on the user device 103. In some embodiments, the contactless kernel 103C may be a software component that processes EMV (Europay MasterCard, Visa) transactions conducted via the user device 103. For instance, the contactless kernel 103C may be responsible for processing and authenticating the transaction data between a payment chip card and a payment terminal.

[0057] According to some embodiments, the authorizing entity computer 120 can be operated by an authorizing entity such as an issuer, which issues the portable device 101 to the user 111. Also, in some embodiments, one or more applications installed on the user device 103 may be managed by the authorizing entity computer 120. For example, the authorizing entity computer 120 can be an issuer and an issuer application such as banking application can be on the user device 103. In some embodiments, the remote server computer 105 can facilitate requesting, determining (e.g., generating) and / or issuing tokens, as well as maintaining (e.g., in a repository (e.g., token vault 107)) an established mapping of tokens to a tuple including portable device data (e.g., PANs) and device fingerprint information. In some embodiments, the remote server computer 105 may establish a token assurance level for a given token to indicate the confidence level of the token to the tuple binding. The remote server computer 105 may include or be in communication with the token vault 107, where the generated tokens are stored. In some embodiments, the remote server computer 105 may be a wallet server in a cloud infrastructure. The token issued by the remote server computer to the user device can permit a user operating the user device to access one or more resources using the token.

[0058] The user 111 can initiate an interaction with a resource provider using a resource provider application (e.g., application 103A) on the user device 103. The portable device 101 can be, for example, a contactless payment card associated with the user 111 of the user device 103. The portable device 101 can be configured to communicate with the user device 103 and can provide interaction data to the user device 103 via a short-range communication channel (e.g., Bluetooth, Bluetooth low energy (BLE), near-field communication (NFC), etc.).

[0059] Information from the user device 103 may be communicated to the remote server computer 105 via a communications network using a secure communications protocol such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0060] In some embodiments, in operation, when the portable device 101 is first tapped on the user device 103 (step S1 ), an application (e.g., application 103A) on the user device 103 can request the remote server computer 105 for a token (step S3) by supplying the portable device information (e.g., PAN and EMV cryptogram) and a device fingerprint of the user device 103. The request may optionally include user verification information such as CDCVM verification information. User verification information can be information that the user was verified or authenticated such as in step S2. The application 103A may obtain the user verification information (in step S2’) from the capture module 103B and the portable device information (depicted as step ST) from the contactless kernel 103C. In an embodiment, when the portable device 101 is tapped to the user device 103 for the first time and the request is sent to the remote server computer 105, the remote server computer 105 can determine that no token is available for this user device / portable device pair in the remote server computer 105. In response to this determination, a provisioning process is triggered.

[0061] Upon the remote server computer 105 receiving the request (step S3), the remote server computer 105 may initially verify the portable device data (e.g., PAN and portable device cryptogram such as an EMV). The remote server computer 105 can do this, or it can communication with the authorizing entity computer 109 (step S4) so that the authorizing entity computer 109 can do it. The remote server computer 105 may also verify the CDCVM information for the device ownership verification purposes. Upon successful verification of the portable device data, the remote server computer 105 commences the provisioning process (i.e., to provision a TTOD token) with the token vault 107 (step S5).

[0062] In some implementations, the token vault 107 or the remote server computer 105 may first notify the authorizing entity computer 109 to start an identity and verification (ID&V) process. In such a process, the authorizing entity computer 109 may transmit an off-band message to user 111 (depicted as step S6). In one embodiment, the ID&V process includes verifying the user using a one-time code that transmitted to a device operated by the user 111 (e.g., via email in an OTP or one time password verification process). Once the ID&V process is completed i.e., the user is verified, the token and associated data (e.g., key(s), counters, expiry information, token cryptogram(s) etc.) for the given tuple (i.e., portable device data and device fingerprint information) is provisioned by the remote server computer 105 and may be stored in the token vault 107 (step S7). According to some embodiments, the provisioned token may also be stored in a database associated with the remote server computer 105 in a data object (e.g., Table I depicted above). Thus, when the user 111 performs a future transaction, the user 111 can interact (e.g., tap) the portable device 101 with the user device 103. A request for a token is transmitted from the user device 103 to the remote server computer 105. The remote server computer 105 can perform a lookup operation within the database using the table which includes mapping information of tuple (portable device information and device fingerprint) to the corresponding token.

[0063] Thus, in embodiments of the present disclosure, a token can be accessed after the user 111 interacts their portable device 101 with their user device 103. In aspecific example, the user 111 can tap the portable device 101 on the user device 103 when the user 111 is on a checkout page of an application on the user device 103. Information related to a PAN and a device fingerprint the user device can be transmitted to the remote server computer 105. Upon receiving the PAN and device fingerprint, the remote server computer 105 may retrieve the token that is related to this information from the database, and provide the token and any related information (e.g., a token cryptogram) to any application(s) or web browser on the user device 103 for the purposes of completing a transaction.

[0064] FIG. 2 shows a block diagram of a token processing system 200 according to certain embodiments. The system 200 as depicted in FIG. 2 includes a user 111 operating a portable device 101 and a user device 103. Further, the system 200 also includes a remote server computer 105, a token vault 107, and an authorizing entity computer 109. These devices or components of system 200 are similar to corresponding entities described previously with reference to FIG. 1. Thus, a description of these components is not repeated herein. As shown in FIG. 2, the system 200 further includes an application backend 201 , a gateway 202, a transport computer 203, and a communications network 205.

[0065] The user 111 may interact with an application 103A to obtain a resource such as a secure location, good, service, or secure data in a transaction. The application can be storage application such as a wallet application, a resource provider application (e.g., a merchant application), or a browser. The user 111 can tap the portable device 101 (e.g., a contactless card) to the user device 103 (e.g., a smartphone device) to complete the transaction. As the process described above with respect to FIG. 1 , the application 103A can obtain a user device fingerprint from the user device 103, portable device data 101 (e.g., including a PAN, a portable device cryptogram, and expiration date) from the portable device 101 , and user verification data (e.g., a biometric template or an indication that the user was authenticated by the user device 103) from the user 111 via the capture module 103B. The application on the user device 103 (e.g., application 103A)transmits a request with this information to the remote server computer 105 to request a token.

[0066] The remote server computer 105 upon receiving the request, validates the portable device data (e.g., PAN and portable device cryptogram) and the user verification data. It can perform this validation, or alternatively or additionally, it can request that the authorizing entity computer 109 verify the information in the request. Upon successful verification, the remote server computer 105 obtains the token from its repository (e.g., database) by performing a lookup operation using the portable device data and the user device fingerprint information. The token associated with the particular pair of portable device data and the user device fingerprint information was previously provisioned and stored in a repository as described with reference to FIG. 1

[0067] In some implementations, the remote server computer 105 may generate a token cryptogram using a key (e.g., symmetric key associated with the remote server computer). The token cryptogram can optionally include the CDCVM result (i.e., verification information) as an input. The token and the token cryptogram are then transmitted back to the application 103A on the user device 103.

[0068] The application 103A then communicates the token, the token cryptogram, the user verification information and any other details regarding the current transaction to the application backend 201 , which may be an application server supporting the application 103A, a resource provider server (e.g., a merchant server), or a wallet server. The application backend then generates and transmits an authorization request message comprising an amount for the transaction, the token, the token cryptogram, the portable device cryptogram, and any other suitable information. The authorization request message is then transmitted to the network 205 via the transport computer 203.

[0069] After the network 205 receives the authorization request message, the network can communicate with the token vault 107 and / or the remote server computer 105 to obtain the credential or primary account number associated with the token. During this process, the remote server computer 105 or the token vault 107 may also verify thetoken cryptogram using a cryptographic key corresponding to the one that was used to create token cryptogram.

[0070] The network 205 can then modify the authorization request message to include the credential, the portable device cryptogram, the expiration date of the credential, etc. and can send it to the authorizing entity computer 109 for authorization. In some embodiments, the authorizing entity computer 109 can verify the credential and the portable device cryptogram. In some embodiments, the portable device cryptogram may have been generated by portable device. The portable device generates the portable device cryptogram by encrypting information on the portable device (e.g., a PAN) and information regarding the current transaction (e.g., an amount) using a symmetric key that is shared with the authorizing entity computer 109. The portable device cryptogram ties the current transaction to the portable device 101 to ensure that the credential on the portable device is not used in an unauthorized transaction.

[0071] Once authorized, the authorizing entity computer 109 can generate and transmit an authorization response message comprising the credential and an authorization decision back to the network 205. The network 205 can re-tokenize the credential to obtain the token and can replace the credential with the token in the authorization response message. The modified authorization response message may then be transmitted back to the application backend 201 via the transport computer 203 and the gateway 202.

[0072] At the end of the day or any other period of time, a clearing and settlement process can occur between the transport computer 203, the network, and the authorizing entity computer 109.

[0073] FIG. 3 depicts a block diagram of system 300 that can perform a verification process. The components depicted in the system 300 of FIG. 3 are similar to the ones depicted in FIG. 1 . However, the system 300 further includes an application backend 301 that is communicatively coupled with the application 103A (installed on the user device 103). In the embodiments described with respect to FIG. 3, the portable device 101 (e.g.,contactless card) is tapped on the user device 103 (e.g., a smartphone) for authentication / verification purposes, such as: (1 ) a merchant validating card possession against card on file (COF), (2) a peer-to-peer (P2P) wallet application that is verifying the ownership of the card linked to the wallet, (3) identification of a user ID at a venue such as a movie theater, etc. In such cases, the application on the device (application 103A) can request remote server computer 105 a token by supplying the portable device information (e.g., PAN and portable device cryptogram), a device fingerprint, and an optional user verification result as described above.

[0074] The remote server computer 105 validates the portable device information i.e., PAN and cryptogram information with the authorizing entity computer 109, and thereafter upon successful verification, obtains the token from its repository (e.g., database) by performing a lookup operation using the portable device information and device fingerprint information for verification (e.g., found - successful, not found - failed). The verification result is then returned to the application (i.e., application 103A).

[0075] In some embodiments, the verification result may be returned in a secure channel like transport layer security (TLS) channel. It is noted that in some embodiments, the verification result may be optionally signed using a private key of the remote server computer 105. In this manner, verification of the user of the contactless card (i.e., verify if user is a legitimate user) may be performed by an application that has information of the portable device 101 (e.g., contactless card) of the user on file.

[0076] FIG. 4 depicts a system and mechanism of accessing a token by different components of a user device according to some embodiments. Specifically, FIG. 4 depicts a scenario 400 of sharing a token between different applications installed on the user device 103. It is noted that the mechanism described herein is equally appliable to sharing of the token by different web browsers that are executed on the user device 103. For example, as shown in FIG. 4, the user device 103 includes two applications i.e., application 1 401 , and application 2 403 that are installed in and executed on the user device. FIG. 4 also depicts a web browser 405 that may be executed on the user device 103. Each of application 1 401 , application 2 403, and web browser 405 communicateswith a respective backend entity, i.e. , application 1 backend 401A, application 2 backend 403A, and a web backend 405A, respectively. It is appreciated that the depiction in FIG. 4 is for illustrative purposes only and is in no way limiting the scope of the present invention. Rather, the user device 103 may include more or less number of applications and / or web-browsers deployed on the user device 103.

[0077] In some embodiments, one can have multiple applications (e.g., application 1 401 and application 2 403) that are installed on the same user device 103 and that connect to the remote server computer 105. Similarly, one can have multiple websites in the browser on the same user device that are communicatively coupled with the remote server computer 105. In such situations, as long as the same portable device data (e.g., PAN) and device fingerprint information (i.e., of the user device 103) is provided in the request for a token to the remote server computer 105. Then, same token can be returned by the remote server computer 105 to the different applications / websites in different use cases. As shown in FIG. 4, application 1 , application 2, and browser obtain the same token from the remote server computer 105 and can conduct transactions (using the TTOD token) with their respective application / web backends. In some implementations, as shown previously in Table I, the remote server computer 105 may be configured to construct a mapping of a token to a tuple including the portable device data and fingerprint of the user device. The remote server computer may be configured to store such a mapping in a database. For example, the remote server computer may construct a first mapping of a first token to a first tuple including first portable device data and a fingerprint of the user device, and construct a second mapping of a second token to a second tuple including second portable device data and the fingerprint of the user device. Such first and second mappings may be stored in a data object in a database.

[0078] Embodiments of the disclosure have a number of advantages. The present disclosure provides for a unique framework for binding a token to the portable device data (e.g., PAN) and user device fingerprint information. It is noted that optionally the CDCVM information may also be used in such a binding. The present disclosure provides for token lifecycle management which includes features such as - (i) the token can be pushed byissuer wallet application once it gets installed, (ii) the token can be invalidated if the card is lost / stolen, (e.g., by providing operators information regarding PAN and the mechanism of generating the device fingerprint) (iii) the token can be invalidated if a device is lost / stolen, and (iv) the token can be invalidated if a device is inactive for prolong time.

[0079] Also, the embodiments described above are more secure than conventional systems. First, the token is a substitute for a real credential such as a primary account number, and the primary account number is protected from hackers and man-in-the- middle attracts. Second, the token is bound to a particular user device via a device fingerprint, and can only to obtained or used if the user has a separate portable device in their possession. Third, through the user of the portable device cryptogram in the transaction, the transaction is tied to the use of the portable device. With this combination of security features, it would be very difficult for any unauthorized person to conduct transactions using a real credential such as a primary account number on a user device.

[0080] FIG. 5A illustrates a user device 500 according to an embodiment. It is noted that the user device 500 may correspond to a mobile communication device such as a smartphone. The terms mobile communication device and user device are thus used synonymously herein. Mobile communication device 500 may include device hardware 504 coupled to a system memory 502.

[0081] Device hardware 504 may include a processor 506, a short range antenna 514, a long range antenna 516, input elements 510, a user interface 508, and output elements 512 (which may be part of the user interface 508). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 506 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers) and is used to control the operation of mobile communication device 500. The processor 506 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 502 and can maintain multiple concurrently executing programs or processes.

[0082] The long range antenna 516 may include one or more RF transceivers and / or connectors that can be used by mobile communication device 500 to communicate with other devices and / or to connect with external networks. The user interface 508 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of mobile communication device 500. The short range antenna 514 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 516 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0083] The system memory 502 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 502 may store computer code, executable by the processor 506, for performing any of the functions described herein. For example, the system memory may comprise a computer readable medium comprising, code for causing the processor 506 to perform a method comprising: receiving, by a user device, portable device data from a portable device that is interacting with the user device; and transmitting, by the user device, the portable device data and a device fingerprint to a remote server computer, wherein the remote server computer is configured to subsequently obtain a token associated with the portable device data and the device fingerprint.

[0084] The system memory 502 may also store a service application 502A, an interaction application 502B, an authentication module 502C, credentials / tokens / device fingerprints 502D, and an operating system 502E, The service application 502A may include instructions or code initiating and conducting a transaction with an external device such as an access device or a processing computer. The interaction application 502B may include code, executable by the processor 506, for forming a local connection or otherwise interacting with an external access device and / or a portable device. The authentication module 502C may comprise code, executable by the processor 506, toauthenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics.

[0085] System memory 502 may also store credentials and / or tokens 502D. Credentials may also include information identifying the mobile communication device 500 and / or the user of the mobile communication device 500.

[0086] FIG. 5B shows an example of a portable device 550 in the form of a card. The portable device 550 can include a substrate with a memory 550A (which can store a credential and its associated information) and a contactless element interface 550B. The contactless element interface 550B can allow the portable device 550 to communicate in a contactless manner with an external device such as a communication device (e.g., user device) or an access device. The portable device 550 can cryptographic keys for creating portable device cryptograms.

[0087] An example message exchange process between an exemplary portable device 602 and a communication device 603 is shown in FIG. 6. The data exchange process in FIG. 6 can be used in, for example, step S10 in FIG. 1. It may also be used in other instances such as when the communication device performs the functions of the portable device 602.

[0088] Prior to performing the message exchange process, an authorizing entity (e.g., an issuer, the user’s bank, etc.,) may initialize the portable device 602 with a number of data fields (e.g., as part of a process for personalization of the portable device 602). The portable device 602 may be configured with one or more applications. In some embodiments, the issuer may assign a priority to these applications. By way of example, one application (e.g., a U.S. payment or access application) on a portable device can be associated with a particular transaction processing protocol and may be assigned a high priority. Another application (e.g., a Canadian payment or access application) associated with a different transaction processing protocol may be assigned a low priority on the same portable device. In some embodiments, portable device data such as a domestic currency code (e.g., “CAD” for Canadian Dollars) and a country code (e.g., “CAN” forCanada) can be stored on the portable device 602. The portable device 602 may store additional sensitive portable device data such as a PAN (primary account number), a CW, an expiration date, and any other suitable information.

[0089] At step S604, a user can subsequently use the portable device 602 to initiate a transaction (e.g., a request for token) using the communication device 603. The user may hold the portable device 602 near the communication device 603, such that both devices may mutually detect each other. The user may present (e.g., tap, hold near, etc.) the portable device 602 to the communication device 603 to exchange data with the communication device 603.

[0090] At step S606, during a process for exchanging data between the portable device 602 and the communication device 603, the portable device 602 may provide the communication device 603 with a list of available applications including at least a first application and a second application. In an interaction, the communication device 603 may send available applications request message to the portable device 602. The available applications request message can request information regarding which applications (e.g., a list of application identifiers (AIDs)) is available on the portable device 602. In some embodiments, the available applications request message may be in the form of a SELECT PPSE command.

[0091] At step S608, the portable device 602 then identifies, from a memory of the portable device, available applications including at least a first application and a second application. The portable device 602 then provides (e.g., transmits) an initial or first available applications response message to the communication device 603. The available applications response message includes the list of the applications (e.g., a list of AIDs) available at the portable device 602 in a SELECT PPSE response in response to receiving the SELECT PPSE command. The available applications response message can comprise an application list comprising at least the first application and the second application. The application list can be ordered according to a first priority and a second priority to indicate a preference for the communication device 603 to use the first application over the second application to process the interaction.

[0092] As shown in step S610, the communication device 603 selects an application from the received application list, and then transmits the selection of the application in a select AID message to the portable device 602 (step S612). In some embodiments, the communication device 603 selects the application highest in the list (e.g., the application associated with the highest priority, in this case the first application). If the interaction is a payment transaction, then this process for application selection may conform to a payment standard such as EMV 1 .0 and / or EMV 2.0.

[0093] At step S616, the portable device 602 may transmit a request for terminal transaction data (e.g., a PDOL request).

[0094] At step S618, responsive to the request for terminal transaction data, the communication device 603 may send transaction data to the portable device 602. In some embodiments, the communication device 603 may send such data in a processing options data object list (PDOL) message to the portable device 602. The selected application (e.g., the first application or international application) may receive the data via the PDOL message.

[0095] At step S634, the portable device 602, upon receiving the application selection message at step S618, may send a terminal transaction data request to request transaction data from the communication device 603. In some embodiments, the terminal transaction data request may be in the form of a “Select AID Response” and may include application identifier (AID) and file control information (FCI) associated with the selected AID as the dedicated file name. The terminal transaction data request may include a list of transaction data identifiers to request the appropriate data from the communication device 603. The list of transaction data identifiers can be in the form of a processing options data object list (PDOL).

[0096] The transaction data requested by the portable device 602 for the transaction may include terminal processing options (TPO), an amount, and other information. In addition, the transaction data may include one or more dynamic data elements (e.g., a random number).

[0097] At step S636, after receiving the terminal transaction data request from portable device 602, the communication device 603 may send to the portable device 602, the terminal transaction data requested by the portable device 602. In some embodiments, the terminal transaction data may be sent in the form of a get processing options (GPO) command, and may include the requested terminal transaction data in a processing options data object list (PDOL). The terminal transaction data (e.g., Transaction Processing Options (TPO)) may include a TPO indicator that indicates which transaction data types of the communication device 603 supports.

[0098] Once the portable device 602 receives the terminal transaction data, the portable device 602 may obtain relevant credentials (e.g., card credentials), and may send a set of transaction processing information to the communication device 603 (arrow not shown in FIG. 6). In some embodiments, the transaction processing information can be sent in the form of a “get processing options” (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used as file addresses by communication device 603 to read account data stored on the portable device 602, and an application interchange profile (AIP) that can be used to indicate the capabilities of the payment application.

[0099] The transaction processing information may include any credentials for the transaction including a cryptogram generated using transaction information (e.g., a portable device cryptogram), Track-2 equivalent data (e.g., PAN, expiration date), and / or additional data. For example, the cryptogram may be generated using transaction information, which may include a dynamic data element (e.g., the random number), the portable device 602 identifier (e.g., a PAN), and optionally other information such as a session identifier, a value such as a zero dollar amount, and a transaction counter. The transaction processing information may also include issuer application data (IAD), a form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), and / or an application PAN sequence number (PAN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, a cryptogram version number (CVN) indicating the version of the transactioncryptogram, a derived key indicator (DKI) that can be used to identify a master key (e.g., a master key associated with the issuer), and / or card verification results (CVR).

[0100] In some embodiments, after the communication device 603 receives the transaction processing information, in step S638, the communication device 603 may send an account data request to the portable device 602 to read additional account data that may be stored on the portable device 602. In some embodiments, the account data request may be in the form of a “read record” command and may include an application file locator (AFL) indicating a location of the account data that the communication device 603 is attempting to read. The AFL included in the account data request may correspond to an AFL in the transaction processing information that was provided to the communication device 603 from portable device 602.

[0101] In response to receiving the account data request from the communication device 603 in step S640, the portable device 602 may send account data stored at the location indicated by the AFL to the communication device 603. In some embodiments, the account data may be sent in the form of a “read record” response. The account data may include, for example, application usage control that indicates the issuer’s restrictions on usage and services allowed for the application, the cardholder’s name, customer exclusive data, issuer country code, and / or other account related data that is accessible at the AFL location and is stored in the portable device 602. The account data, transaction processing information, and other data received by the communication device 603 in previous steps may be subsequently used by the communication device 603 to complete the payment transaction.

[0102] At some point, the user may remove the portable device 602 from the communication device 603, or otherwise disengage the portable device 602 from the communication device 603. Upon removal or disengagement, the portable device 602 may be powered off which also powers off the volatile memory of the portable device 602, clearing the flag previously set on the portable device 602.

[0103] FIG. 7 shows a block diagram of a remote server computer 700 according to an embodiment. The remote server computer 700 includes a processor 702, a non- transitory computer readable medium 704, a token vault 706, and a network interface 708 coupled to the processor 702.

[0104] The non-transitory computer readable medium 704 may comprise a request processing module 704A, a token generation module 704B, a mapping module 704C, and a communication module 704D. The computer readable medium may also comprise code, executable by the processor 702 to perform a method comprising: receiving, by a remote server computer, a request for a token from a user device, the request including a fingerprint of the user device and portable device data; verifying, by the remote server computer, validity of the portable device data; responsive to successfully verifying the portable device data, generating the token that is to be associated with the fingerprint of the user device and the portable device data, wherein the remote server computer is configured to store the token, the portable device data and the device fingerprint together in a user record; and transmitting, by the remote server computer, the token to the user device, wherein the user device subsequently uses the token to conduct a transaction.

[0105] The request processing module 704A may be configured to receive a request for a token from a user device. It is noted that the request received from the user device may include information corresponding to a fingerprint of the user device and portable device data i.e., information associated with the portable device that interacts with the user device. Upon receiving such a request, the request processing module 704A may verify validity of the portable device data. In one implementation, the request processing module 704A may communicate (e.g., via the communication module 704D) with an authorizing entity computer (e.g., authorizing entity computer 109 of FIG. 1) to validate the portable device data (e.g., PAN and portable device cryptogram) and the user verification data. Upon receiving a message from the authorizing entity computer indicating that the portable device data is authentic, the token generation module 704B may generate a token that is to be associated with the fingerprint of the user device and the portable device data (i.e., received in the request for a token). It is noted that the tokengeneration module 704B of the remote server computer 700 may utilize cryptographic algorithms (e.g., RSA) to generate the token.

[0106] The mapping module 704C is configured to establish a mapping of the token generated by the token generation module 704B to a tuple including portable device data (e.g., PANs) and device fingerprint information. For instance, the mapping module 704C may construct a first mapping of a first token to a first tuple including first portable device data and a fingerprint of the user device and construct a second mapping of a second token to a second tuple including second portable device data and the fingerprint of the user device. Such first and second mappings may be stored as respective user records in a token vault 606. Specifically, a user record includes portable device data and device fingerprint information (received in a request for a token) mapped to a corresponding token generated for the request e.g., by the token generation module 704B. The token vault 706 may store data in a database such as an Oracle™ database. Further, it is noted that the communication module 704D and the processor 707 can allow the remote server computer 700 to communicate with external entities.

[0107] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0108] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object- oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0109] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0110] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0111] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0112] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:1 . A method comprising: receiving, by a user device, portable device data from a portable device that is interacting with the user device; and transmitting, by the user device, the portable device data and a device fingerprint to a remote server computer, wherein the remote server computer is configured to subsequently obtain a token associated with the portable device data and the device fingerprint, the remote server computer being further configured to store the token, the portable device data and the device fingerprint together in a user record.

2. The method of claim 1 , wherein the portable device data includes a credential and an expiration date.

3. The method of claim 1 , wherein the user device receives the portable device data upon the portable device being tapped on the user device.

4. The method of claim 1 , wherein the device fingerprint is generated by an application installed on and executed on the user device, the device fingerprint being generated by hashing one or more parameters including a serial number of the user device, a MAC address of the user device, or an IMEI number of the user device.

5. The method of claim 1 , further comprising: receiving, by one or more applications installed on the user device, the token from the remote server computer, wherein the one or more applications utilize the token to conduct a transaction.

6. The method of claim 1 , wherein a first user device has a first device fingerprint and a second user device has a second device fingerprint that is different than the first device fingerprint.

7. The method of claim 1 , wherein a first token is associated with a first portable device and the user device and a second token is associated with a second portable device and the user device, the second token being different than the first token.

8. The method of claim 1 , wherein the user device and the portable device are operated by a user and communicate via a short range communication protocol.

9. The method of claim 1 , wherein the user device is a mobile phone and the portable device is a card.

10. The method of claim 1 , wherein the remote server computer subsequently permits a user to access a resource using the token.

11. A user device comprising: a processor; and a non-transitory computer readable medium coupled to the processor and comprising code, executable by the processor, for implementing a method comprising receiving, portable device data from a portable device that is interacting with the user device; and transmitting the portable device data and a device fingerprint to a remote server computer, wherein the remote server computer is configured to subsequently obtain a token associated with the portable device data and the device fingerprint, the remote server computer being further configured to store the token, the portable device data and the device fingerprint together in a user record.

12. The user device of claim 11 , wherein the portable device data includes a primary account number, an expiration date, and a CVV.

13. The user device of claim 11 , wherein the user device receives the portable device data upon the portable device being tapped on the user device.

14. The user device of claim 11 , wherein the device fingerprint is generated by an application installed on and executed on the user device, the device fingerprint being generated by hashing one or more parameters including a serial number of the user device, a MAC address of the user device, or an IMEI number of the user device.

15. The user device of claim 11 , wherein a first token is associated with a first portable device and the user device, and a second token is associated with a second portable device and the user device, the second token being different than the first token.

16. The user device of claim 11 , wherein the user device is a mobile phone and the portable device is a card.

17. A method comprising: receiving, by a remote server computer, a request for a token from a user device, the request including a fingerprint of the user device and portable device data; verifying, by the remote server computer, validity of the portable device data; responsive to successfully verifying the portable device data, generating the token that is to be associated with the fingerprint of the user device and the portable device data, wherein the remote server computer is configured to store the token, the portable device data and the fingerprint of the user device together in a user record; and transmitting, by the remote server computer, the token to the user device, wherein the user device, subsequently uses the token to conduct a transaction.

18. The method of claim 17, further comprising:receiving, a first request for a first token from a first application installed on the user device, the first request including the fingerprint of the user device and first portable device data; receiving, a second request for a second token from a second application installed on the user device, the second request including the fingerprint of the user device and second portable device data; transmitting, by the remote server computer, the first token to the first application in response to successfully verifying the first portable device data; and transmitting, by the remote server computer, the first token to the second application in response to successfully verifying the second portable device data and determining that the second portable device data is same as the first portable device data.

19. The method of claim 18, further comprising: transmitting, by the remote server computer, the second token to the second application in response to successfully verifying the second portable device data and determining that the second portable device data is different than the first portable device data, the second token being different than the first token.

20. The method of claim 18, further comprising: constructing, by the remote server computer, a first mapping of the first token to a first tuple including the first portable device data and the fingerprint of the user device; constructing, by the remote server computer, a second mapping of the second token to a second tuple including the second portable device data and the fingerprint of the user device; and storing, by the remote server computer, the first mapping and the second mapping in a database.

Images