[go: up one dir, main page]

WO2025049260A1 - Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur - Google Patents

Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur Download PDF

Info

Publication number
WO2025049260A1
WO2025049260A1 PCT/US2024/043500 US2024043500W WO2025049260A1 WO 2025049260 A1 WO2025049260 A1 WO 2025049260A1 US 2024043500 W US2024043500 W US 2024043500W WO 2025049260 A1 WO2025049260 A1 WO 2025049260A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
portable device
user device
user
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/043500
Other languages
English (en)
Inventor
Yuexi Chen
Ratna Deepthi JARUGU
Esha Dutta
Jennifer Kim ASTREIN
Geraldine MITCHLEY
Sonia Gupta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of WO2025049260A1 publication Critical patent/WO2025049260A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • existing token types e.g., device tokens, e-Commerce tokens, cloud tokens, etc.
  • CDCVM consumer device cardholder verification method
  • Embodiments of the disclosure address this problem and other problems individually and collectively.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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 to subsequently obtain a token associated with the portable device data and the device fingerprint.
  • FIG. 1 shows a block diagram of a token provisioning system and overlaid process flow according to embodiments.
  • FIG. 2 shows a block diagram of utilizing a token processing system according to embodiments.
  • FIG. 3 depicts a block diagram of verification system according to embodiments.
  • FIG. 4 depicts a block diagram of a token access system according to some embodiments.
  • FIG. 5A shows a block diagram of components of a user device according to embodiments.
  • FIG. 5B shows a diagram of an example portable device.
  • FIG. 6 shows a diagram showing an exemplary interaction between a portable device and a user device.
  • FIG. 7 shows a block diagram of a remote server computer according to an embodiment of the invention.
  • a “user device” may be a device that is operated by a user.
  • 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.
  • PDA personal digital assistant
  • 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.
  • a “user” may include an individual.
  • 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.
  • a “portable device” can include any suitable device that may be portable.
  • a portable device may be in any suitable form.
  • 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 SpeedpassTM 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.
  • the portable device can operate in either a contact or contactless mode, in some embodiments, a portable device may be used to conduct an interaction.
  • a portable device may be used to conduct a transaction, such as to provide payment information to a resource provider.
  • 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)).
  • APDUs application protocol data units
  • 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.
  • interaction data can include a primary account number (PAN), a token, a cryptogram, etc.
  • Application data can include data related to an application.
  • 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.
  • “Credentials” may comprise any evidence of authority, rights, or entitlement to privileges.
  • access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file.
  • credentials may include passwords, passcodes, or secret messages.
  • 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”.
  • credentials may be considered sensitive information.
  • 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.
  • 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.
  • a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier.
  • a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.”
  • 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).
  • 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.
  • 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.
  • 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.
  • Tokenization is a process by which sensitive data is replaced with substitute data.
  • a real credential e.g., a primary account number (PAN)
  • PAN primary account number
  • 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.
  • a token exchange may include replacing a payment token with its associated primary account number (PAN).
  • de- tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token.
  • 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).
  • API application programming interface
  • a “token service computer” can include a system that that services tokens.
  • 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).
  • PANs primary account numbers
  • 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.
  • a “token domain” may indicate an area and/or circumstance in which a token can be used.
  • 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 restriction controls
  • the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes.
  • 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.
  • 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).
  • the token expiry date can be expressed as an time duration as measured from the time of issuance.
  • 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.
  • 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).
  • the token request message may include a flag or other indicator specifying that the message is a token request message.
  • 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 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 response message can be encrypted (e.g., with an issuer-specific key).
  • the token response message may include a flag or other indicator specifying that the message is a token response message.
  • 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.
  • 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.
  • 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.
  • a “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access.
  • resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc.
  • 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.
  • 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.”
  • a “processor” may include a device that processes something.
  • 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).
  • 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.
  • a “server computer” may include a powerful computer or cluster of computers.
  • the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • An “identifier” may include a primary account number (PAN) and/or an expiration date.
  • PAN primary account number
  • 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.
  • a “cryptogram” may be an obscured or encoded representation of text.
  • a cryptogram may be an obscured or encrypted text string repeating or generated by a cryptographic key.
  • 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.
  • Aspects of the present disclosure provide for creation of a new token type e.g., a Tap-To-Your-Own-Device (TTYOD) token.
  • TTYOD Tap-To-Your-Own-Device
  • 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.
  • 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.
  • IMEI International Mobile Equipment Identity
  • 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.
  • 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.
  • a first user device e.g., a smartphone
  • a second user device e.g., a tablet computer
  • a request for the token e.g., request made by the user device to a remote server
  • the token supplied to the user device
  • Table I 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.
  • device 1 has a fingerprint of “998335c1-4c08-492b-83ca-8711824ad47e”
  • device 2 has a fingerprint of “26c7d731-7683-4736-abe0-cf39ea89f0ee”
  • device 3 has a fingerprint of “36179e4a-adb9-4c42-987b-7e70c79b2581”.
  • a unique token is generated and bound with the portable device data (e.g., a PAN) and the user device fingerprint.
  • the token is provisioned by a remote server computer.
  • 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).
  • 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 e.g., a token vault 107
  • an authorizing entity computer 109 e.g., an issuer computer
  • 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.
  • 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.
  • the biometric reader can be an iris scanner, a palm/hand scanner, a voice scanner, DNA scanner and/or the like.
  • the capture module 103B may be configured to obtain any information that may be used to authenticate the user 111.
  • 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.
  • CDCVM consumer device cardholder verification method
  • the portable device 101 and the user device 103 can communicate with each other via a short range communication protocol such as NFC.
  • 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.
  • the user device 103 may capture such data via the NFC driver 103D.
  • 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 .
  • PAN primary account number
  • CVV a CVV
  • 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.
  • SSL Secure Socket Layer
  • 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).
  • the provisioning process i.e., to provision a TTOD token
  • 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.
  • the authorizing entity computer 109 may transmit an off-band message to user 111 (depicted as step S6).
  • 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).
  • the token and associated data e.g., key(s), counters, expiry information, token cryptogram(s) etc.
  • the token and associated data e.g., key(s), counters, expiry information, token cryptogram(s) etc.
  • 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).
  • 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.
  • a token can be accessed after the user 111 interacts their portable device 101 with their user device 103.
  • 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.
  • 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.
  • 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.
  • the system 200 further includes an application backend 201 , a gateway 202, a transport computer 203, and a communications network 205.
  • 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.
  • a contactless card e.g., a contactless card
  • 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
  • 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
  • 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.
  • 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.
  • the network 205 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.
  • the remote server computer 105 or the token vault 107 may also verify the token cryptogram using a cryptographic key corresponding to the one that was used to create token cryptogram.
  • 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.
  • the authorizing entity computer 109 can verify the credential and the portable device cryptogram.
  • 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.
  • 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.
  • a clearing and settlement process can occur between the transport computer 203, the network, and the authorizing entity computer 109.
  • 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 .
  • the system 300 further includes an application backend 301 that is communicatively coupled with the application 103A (installed on the user device 103).
  • the application 103A installed on the user device 103.
  • the portable device 101 e.g., contactless card
  • the user device 103 e.g., a smartphone
  • 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.
  • 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.
  • portable device information e.g., PAN and portable device cryptogram
  • 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).
  • the application i.e., application 103A.
  • 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.
  • TLS transport layer security
  • 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.
  • 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 communicates with 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.
  • 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.
  • applications e.g., application 1 401 and application 2 403
  • the same portable device data e.g., PAN
  • device fingerprint information i.e., of the user device 103
  • same token can be returned by the remote server computer 105 to the different applications/websites in different use cases. As shown in FIG.
  • 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.
  • 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.
  • 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 by issuer 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.
  • the embodiments described above are more secure than conventional systems.
  • 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.
  • 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.
  • FIG. 5A illustrates a user device 500 according to an embodiment.
  • 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.
  • 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).
  • input elements may include microphones, keypads, touchscreens, sensors, etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 6 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.
  • portable device data such as a domestic currency code (e.g., “CAD” for Canadian Dollars) and a country code (e.g., “CAN” for Canada) 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.
  • 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.
  • 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.
  • 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.
  • the available applications request message may be in the form of a SELECT PPSE command.
  • 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).
  • 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.
  • the portable device 602 may transmit a request for terminal transaction data (e.g., a PDOL request).
  • a request for terminal transaction data e.g., a PDOL request
  • the communication device 603 may send transaction data to the portable device 602.
  • 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
  • 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.
  • 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).
  • the transaction data requested by the portable device 602 for the transaction may include terminal processing options (TPO), an amount, and other information.
  • the transaction data may include one or more dynamic data elements (e.g., a random number).
  • the communication device 603 may send to the portable device 602, the terminal transaction data requested by the portable device 602.
  • 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.
  • 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).
  • the transaction processing information can be sent in the form of a “get processing options” (GPO) response.
  • 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.
  • AFLs application file locators
  • AIP application interchange profile
  • 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.
  • 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).
  • issuer application data may include a length indicator indicating the length of the IAD, a cryptogram version number (CVN) indicating the version of the transaction cryptogram, 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).
  • 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.
  • 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.
  • AFL application file locator
  • 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.
  • the portable device 602 may send account data stored at the location indicated by the AFL to the communication device 603.
  • 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.
  • 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.
  • 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.
  • 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.
  • an authorizing entity computer e.g., authorizing entity computer 109 of FIG. 1
  • 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 token generation module 704B of the remote server computer 700 may utilize cryptographic algorithms (e.g., RSA) to generate the token.
  • cryptographic algorithms e.g., RSA
  • 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.
  • 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 OracleTM database.
  • the communication module 704D and the processor 707 can allow the remote server computer 700 to communicate with external entities.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Bioethics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé d'obtention d'un jeton destiné à être utilisé par une ou plusieurs applications installées sur un dispositif utilisateur. Le jeton est obtenu en réponse à l'interaction d'un dispositif portable avec le dispositif utilisateur. Le dispositif utilisateur reçoit des données de dispositif portable en provenance du dispositif portable qui interagit avec le dispositif utilisateur. Le dispositif utilisateur transmet les données de dispositif portable et une empreinte numérique de dispositif à un ordinateur serveur à distance. L'ordinateur serveur à distance est configuré pour obtenir ensuite un jeton associé aux données de dispositif portable et à l'empreinte numérique de dispositif.
PCT/US2024/043500 2023-08-25 2024-08-22 Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur Pending WO2025049260A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363578878P 2023-08-25 2023-08-25
US63/578,878 2023-08-25

Publications (1)

Publication Number Publication Date
WO2025049260A1 true WO2025049260A1 (fr) 2025-03-06

Family

ID=94820116

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/043500 Pending WO2025049260A1 (fr) 2023-08-25 2024-08-22 Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur

Country Status (1)

Country Link
WO (1) WO2025049260A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170061422A1 (en) * 2015-09-01 2017-03-02 Bank Of America Corporation System for authenticating the use of a wearable device to execute a transaction
US20190251561A1 (en) * 2016-11-01 2019-08-15 Entersekt International Limited Verifying an association between a communication device and a user
US20190279199A1 (en) * 2016-07-29 2019-09-12 Visa International Service Association Multi-device authentication process and system utilizing cryptographic techniques
US20210081928A1 (en) * 2014-05-23 2021-03-18 Samsung Electronics Co., Ltd. Systems and methods for linking devices to user accounts
US20210256495A1 (en) * 2018-04-20 2021-08-19 Visa International Service Association Portable device loading mechanism for account access

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210081928A1 (en) * 2014-05-23 2021-03-18 Samsung Electronics Co., Ltd. Systems and methods for linking devices to user accounts
US20170061422A1 (en) * 2015-09-01 2017-03-02 Bank Of America Corporation System for authenticating the use of a wearable device to execute a transaction
US20190279199A1 (en) * 2016-07-29 2019-09-12 Visa International Service Association Multi-device authentication process and system utilizing cryptographic techniques
US20190251561A1 (en) * 2016-11-01 2019-08-15 Entersekt International Limited Verifying an association between a communication device and a user
US20210256495A1 (en) * 2018-04-20 2021-08-19 Visa International Service Association Portable device loading mechanism for account access

Similar Documents

Publication Publication Date Title
US12170730B2 (en) Unique token authentication verification value
US12008088B2 (en) Recurring token transactions
US10417542B2 (en) Mobile device with scannable image including dynamic data
US11750368B2 (en) Provisioning method and system with message conversion
US12413580B2 (en) Token processing system and method
US20230062507A1 (en) User authentication at access control server using mobile device
US12211034B2 (en) Virtual terminal
US20240406151A1 (en) Efficient and protected data transfer system and method
CN113259308B (zh) 预防令牌认证重放攻击的系统和方法
WO2025049260A1 (fr) Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur
WO2024168176A1 (fr) Continuité d'interaction inter-plateformes variable
WO2025071597A1 (fr) Interactions segmentées en jetons à l'aide d'un identifiant électronique
WO2024077127A1 (fr) Flux de messagerie pour interactions distantes à l'aide de données sécurisées
WO2025085220A1 (fr) Vérification d'identification électronique pour dispositif mobile
WO2024220432A1 (fr) Interaction à distance sécurisée à l'aide d'un dispositif de transaction portable
WO2025244630A1 (fr) Intégration de navigateur pour interactions sans contact
WO2025071623A1 (fr) Système et procédé de traitement de jeton interopérable
CN120584474A (zh) 可信认证上下文
CN115777190A (zh) 用于基于接近度的访问装置交互的具选择性去令牌化的令牌处理

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24860763

Country of ref document: EP

Kind code of ref document: A1