+

WO2025071623A1 - Système et procédé de traitement de jeton interopérable - Google Patents

Système et procédé de traitement de jeton interopérable Download PDF

Info

Publication number
WO2025071623A1
WO2025071623A1 PCT/US2023/075534 US2023075534W WO2025071623A1 WO 2025071623 A1 WO2025071623 A1 WO 2025071623A1 US 2023075534 W US2023075534 W US 2023075534W WO 2025071623 A1 WO2025071623 A1 WO 2025071623A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
computer
credential
request message
processing
Prior art date
Application number
PCT/US2023/075534
Other languages
English (en)
Inventor
Yuexi Chen
Ken Tanabe
William TIKI
Zachary TEMKIN
Sonia Gupta
Ratna Deepthi JARUGU
Chia-Hua Chen
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
Priority to PCT/US2023/075534 priority Critical patent/WO2025071623A1/fr
Publication of WO2025071623A1 publication Critical patent/WO2025071623A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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

Definitions

  • Portable devices can be used to gain access to resources.
  • portable devices such as access badges can be used to access buildings or locations.
  • the portable devices may be unable to gain access to such resources.
  • the portable device may be incapable of gaining access to a location or a good or service in a foreign country. This is problematic.
  • Access devices such as access terminals and point of sale terminals may not be trusted by users. As such, users may hesitate to interact with certain access devices when conducting transactions. When users use their portable devices to interact with the access devices, credentials stored on the portable devices are passed to the access devices. If the access devices are untrustworthy (e.g., are dishonest access devices or are susceptible to being hacked), then users may hesitate to use them. If they do use them, the credentials that are passed to the access device may be stolen by unauthorized users.
  • Embodiments of the invention address these and other problems, individually and collectively.
  • Embodiments of the invention are directed to token provisioning systems and methods.
  • One embodiment includes a method comprising: receiving, by a token service computer from a communication device, a substitute device data request message comprising a credential; after receiving the substitute device data request message, determining, by the token service computer, a substitute device data response message comprising substitute device data comprising a token; transmitting, by the token service computer, the substitute device data response message to the communication device, which provides the token to an access device, wherein the access device transmits an authorization request message comprising the token to a first processing computer, wherein the access device and/or the first processing network computer are capable of processing a transaction with the token, but are not capable of processing a transaction with the credential, wherein the first processing computer thereafter transmits the authorization request message to a second processing computer, which obtains the credential using the token from the token service computer; receiving, by the token service computer, a token resolution request message comprising the token; responsive to receiving the token resolution request message, determining, by the token service computer, the credential using the token; and transmitting, by the token service computer,
  • a token service computer comprising: a processor; and a non-transitory computer readable medium coupled to the processor, the non-transitory computer readable medium comprising code executable by the processor for performing a method comprising: receiving, by the token service computer from a communication device, a substitute device data request message comprising a credential; after receiving the substitute device data request message, determining, by the token service computer, a substitute device data response message comprising substitute device data comprising a token; transmitting, by the token service computer, the substitute device data response message to the communication device, which provides the token to an access device, wherein the access device transmits an authorization request message comprising the token to a first processing computer, wherein the access device and/or the first processing network computer are capable of processing a transaction with the token, but are not capable of processing a transaction with the credential, wherein the first processing computer thereafter transmits the authorization request message to a second processing computer, which obtains the credential using the token from the token service computer; receiving, by the token service computer from a communication device
  • Another embodiment of the invention includes a method comprising: transmitting, by a communication device to a token service computer, a substitute device data request message comprising a credential; receiving, by the communication device from the token service computer, a substitute device data response message comprising substitute device data comprising a token; and providing, by the communication device to an access device, the token, wherein the access device transmits an authorization request message comprising the token to a first processing computer, wherein the access device and/or the first processing computer are capable of processing a transaction with the token, but are not capable of processing a transaction with the credential, wherein the first processing computer transmits the authorization request message to a second processing computer, which obtains the credential using the token from the token service computer, and wherein the second processing computer subsequently processes the authorization request message using the credential.
  • Another embodiment of the invention includes a communication device programmed to perform the above method.
  • FIG. 1 shows a system diagram and a process flow according to an embodiment of the invention.
  • FIG. 2 shows a block diagram of a token service computer according to an embodiment of the invention.
  • FIG. 3 shows a block diagram of a communication device according to an embodiment of the invention.
  • FIG. 4 shows diagram of an example a portable device.
  • FIG. 5 shows a diagram showing an exemplary interaction between a portable device and a communication device.
  • a “communication device” may comprise any suitable electronic device that may be operated by a user, which may also provide remote communication capabilities to a network.
  • a “mobile communication device” may be an example of a “communication device” that can be easily transported. 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. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, personal music players, hand-held specialized readers, etc.
  • a mobile communication device can function as a payment device (e.g., a mobile communication device can store and be able to transmit payment credentials for a transaction).
  • a “portable device” may be a device that is portable. In some embodiments, it can be used to conduct a transaction and can be a portable transaction device.
  • a portable transaction device may include a storage technology (e.g., electronic memory, magnetic stripe, etc.) to store credentials or tokens associated with an account of a user.
  • a portable transaction device can be in any of the forms described above with respect to the portable communication device, or in the form of a card (e.g., integrated chip card, magnetic stripe card) or a fob, etc.
  • the portable transaction device and the portable communication device may be the same device, and need not be separate devices.
  • Specific examples of portable transaction devices can include wearable devices, payment cards such as credit, debit, and prepaid cards, vehicles with remote communication capabilities, etc.
  • a “payment device” may include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant.
  • the payment device may be a software object, a hardware object, or a physical object.
  • the payment device may comprise a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise included at or near a surface of an object.
  • a hardware object can relate to circuitry (e.g., permanent voltage values), and a software object can relate to non-permanent data stored on a device.
  • a payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and/or pocket (e.g., pocket-sized).
  • Example payment devices may include smart cards, magnetic stripe cards, keychain devices, etc. Other examples of payment devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.
  • a “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority.
  • a credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include payment credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.
  • Payment credentials may include any suitable information associated with 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 a PAN (primary account number or “account number”), username, expiration date, and verification values such as CW, dCVV, CW2, dCVV2, and CVC3 values.
  • PAN primary account number or “account number”
  • 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 payment tokens, access tokens, personal identification tokens, 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).
  • PAN primary account number
  • a payment 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 payment 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 payment 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 payment token 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 data is replaced with substitute data.
  • a payment account identifier e.g., a primary account number (PAN)
  • PAN primary account number
  • tokenization may be applied to any other information that may be replaced with a substitute value (i.e. , token). Tokenization enhances transaction efficiency and security.
  • a "token issuer,” token provider,” token service computer,” or “token service system” can include a system that services tokens.
  • a token service system 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 system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding.
  • the token service system may include or be in communication with a token vault where the generated tokens are stored.
  • the token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PANs.
  • a token service system may include a tokenization computer alone, or in combination with other computers such as a transaction processing network computer.
  • Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention.
  • a “token domain” may indicate an area and/or circumstance in which a token can be used.
  • token domains 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.
  • a “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 a time duration as measured from the time of issuance.
  • 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 “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.
  • a “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
  • 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.”
  • 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 “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a portable device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.
  • An “access device” may be any suitable device that provides access to a remote system.
  • An access device may also be used for communicating with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system.
  • An access device may generally be located in any suitable location, such as at the location of a merchant.
  • An access device may be in any suitable form.
  • Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like.
  • An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a mobile communication or payment device.
  • an access device may comprise a POS terminal
  • any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium.
  • a reader may include any suitable contact or contactless mode of operation.
  • exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile device.
  • RF radio frequency
  • a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or an “mPOS” terminal.
  • An “authorization request message” may be an electronic message that requests authorization for a transaction. 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 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 CW (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 amount, 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.
  • 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.
  • FIG. 1 shows a block diagram of a system 100 according to an embodiment.
  • the system 100 comprises a portable device 102 in communication with a communication device 104.
  • the communication device 104 can comprise an interaction application 104A and a service application 104B.
  • the interaction application 104A can include code that can cause the communication device 104 to interact with the portable device 102 and/or an access device 114.
  • the service application 104B can include code that can cause the communication device 104 to interact with the token service computer 110.
  • the access device 114 can be in communication with an authorizing entity computer 120 via a first processing computer 116 and a second processing computer 118.
  • the first processing computer 116 may be in a first processing network such as first payment processing network.
  • the second processing computer 118 can be in a second processing network such as a second payment processing network.
  • the first processing network and/or the second processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services.
  • An exemplary payment processing network may include VisaNetTM.
  • Transaction processing systems such as VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions.
  • VisaNetTM in particular, may include a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
  • the first processing computer 116 is in a first processing network that routes messages between entities in a first geographic area
  • the second processing computer 118 is in a second interaction network that routes messages between entities in a second geographic area.
  • the first and second geographic areas are not limited, and can be different countries, different states, or different cities.
  • the token service computer 110 may be in communication with the communication device 104, the second processing computer 118 and the authorizing entity computer 120.
  • the authorizing entity computer 120 can be operated by an authorizing entity such as an issuer, which issues the portable device 102 to the user.
  • the service application 104B can be an application that is managed by the authorizing entity computer 120.
  • the authorizing entity computer 120 can be an issuer and the service application 104B can be an issuer application such as a banking application associated with the issuer.
  • Each of the entities in FIG. 1 may communicate through any suitable communication channel or communications network.
  • a suitable communications network may be 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.
  • WAP Wireless Application Protocol
  • One embodiment includes a method that comprises receiving from a communication device, a request message comprising a credential.
  • the method also includes determining a response message comprising substitute device data comprising a token, and the response message to the communication device.
  • the communication device provides the token to an access device, which transmits an authorization request message comprising the token to a first processing computer.
  • the access device and/or the first processing network computer are capable of processing a transaction with the token, but not with the credential.
  • the first processing computer transmits the authorization request message to a second processing computer, which obtains the credential using the token from the token service computer.
  • the second processing computer processes the authorization request message using the credential.
  • the authorizing entity computer 120 can provide registration information about the user of the portable device 102 and the communication device 104 to the token service computer 110.
  • the user registration information can include any suitable information including a username, a password, PIN, pattern, or biometric of the user.
  • the authorizing entity computer 120 may transmit suitable substitute device data that can be used with different processing computers.
  • the authorizing entity computer 120 can store a credential and other associated data associated with the portable device 102 in the token service computer 110.
  • the token service computer 110 can store various types of substitute device data.
  • the different substitute device data can be data that would be compatible with other processing computers and/or access devices that would not otherwise be compatible with the credential and its associated data.
  • the user may wish to conduct a transaction with a resource provider that operates the access device 114.
  • the user may be unable to use the portable device 102 to conduct the transaction with the access device 114 for one or more reasons.
  • the portable device 102 may not be compatible with the access device 114 and/or the first processing computer 116.
  • the portable device 102 may have a credential associated with an application identifier and a cryptogram.
  • the credential, application identifier, and the cryptogram may be suitable for use with an access device and a processing computer in a country such as the United States. However, it may not be suitable for use in a country such as Canada.
  • an access device such as a point of sale terminal in Canada may not be able to accept the credential from the portable device 102, because it will only interact with portable devices that have at least one of a set of application identifiers.
  • the application identifier in the portable device 102 would not be in the set of application identifiers and any interaction with the portable device 102 would be rejected by the access device 114.
  • the cryptogram associated with the credential may not be capable of being validated by the first processing computer 116 (e.g., in Canada), because it does not have the correct cryptographic key.
  • the user of the portable device 102 may not trust the access device 114. The user may be hesitant to directly interact the portable device 102 with the access device 114 since the access device 114 may be untrusted.
  • the service application 104B may be, for example, a mobile banking application associated with an authorizing entity associated with authorizing entity computer 120.
  • the service application 104B can request authentication data from the user.
  • the user can enter the authentication data into the service application.
  • This authentication data can be transmitted to the token service computer 110.
  • the token service computer 110 can then authenticate the user using the authentication data.
  • the token service computer 110 can then provide a message back to the service application 104B that the user has been authenticated.
  • the service application 104B can then communicate with the interaction application 104A, which may cause the communication device 104 to prompt the user to interact the portable device 102 with the communication device 104.
  • the user can interact the portable device 102 with the communication device 104.
  • the user can tap their portable device 102 against the communication device 104 or insert their portable device 102 into the communication device 104.
  • the portable device 102 and the communication device 104 can communicate with each other via a short range communication protocol such as NFC. After they interact with each other, the communication device 104 receives the credential from the portable device 102.
  • the portable device 102 and the communication device 104 are operated by the user, so the communication device 104 is trusted by the user.
  • An example message protocol is shown in FIG. 5 and is described below.
  • a substitute device data request message comprising the credential is transmitted to the token service computer 110 and the token service computer 110 receives the same.
  • the substitute device data request message can also comprise a first application identifier that is associated with a first payment application on the portable device. It may also comprise a first cryptogram that can validated by second processing computer 118 or an authorizing entity computer 130, but not the first processing computer 116.
  • the token service computer 110 can validate that this data are stored in the token vault of the token service computer 110. Once it is validated, the token service computer 110 determines substitute device data associated with the credential and generates a substitute device data response message comprising substitute device data.
  • the substitute device can comprise a token, a second application identifier associated with a second payment application that is compatible with the access device, and a second cryptogram that can be validated by the first processing computer 116, but not the second processing computer 118.
  • the substitute device data that is obtained for the communication device 104 is single or limited use, and can only be used for one transaction.
  • a different substitute device data set is created the next time that the user of the portable device 102 wants to perform a transaction with it.
  • the substitute device data can be calculated with an algorithm each time it is requested. This limits the ability of an unauthorized user (e.g., a hacker) from reusing the substitute device data for a transaction if they are somehow able to obtain it.
  • the token service computer 110 can store pools of substitute device data and a different instance of substitute device data can be selected for each transaction.
  • the user may also program characteristics into the token service computer 110 for the use of the substitute device data.
  • characteristics can include time validity, geolocation validity, transaction amount/currency validity, token presentation type (NFC, QR), messaging protocol (Visa/MasterCard/Domestic Networks), merchant type, etc.
  • the token service computer 110 can then transmit a substitute device data response message including the substitute device data to the communication device 104.
  • step S16 the communication device 104 provides the token to an access device 114.
  • This can be done using any suitable mechanism including through the use of a barcode (QR code), NFC, BluetoothTM, Wi-FiTM, contact, etc.
  • the token, the second application identifier associated with a second payment application that is compatible with and can be processed by the access device 114 is compatible with and can be processed by the first processing computer 116. Since the second application identifier is recognized as being compatible by the access device 114, it processes the transaction using the token.
  • the access device 114 can generate an authorization request message comprising the token, the second cryptogram, and an a value (e.g., an amount) associated with the transaction.
  • step S18 the access device 114 transmits the authorization request message comprising the token and the second cryptogram to the first processing computer 116.
  • the access device 114 transmits the authorization request message to the first processing computer 116 via a transport computer (not shown in FIG. 1 ) such as an acquirer computer.
  • the first processing computer 116 can review the token and/or the cryptogram and can determine that the token and the cryptogram should be sent to the second processing computer 118 for processing.
  • the token may have an indicator in it, which can indicate that the authorization request message is to be forwarded to the second processing computer 118 for processing.
  • the token may be a sixteen digit number in the same format as a primary account number for a credit or debit account, and that starts with the number “4.” This can indicate that the authorization request message should be sent to the second processing computer 118 for processing.
  • first processing computer thereafter transmits the authorization request message to the second processing computer 118.
  • step S22 the second processing computer 118 obtains the credential using the token from the token service computer 110.
  • the second processing computer 118 can transmit a token resolution request message comprising the token to the token service computer 110.
  • the token service computer can determine the credential using the token.
  • the token service computer can then transmit a token resolution response message comprising the credential to the second processing computer 118.
  • step S24 the second processing computer 118 subsequently processes the authorization request message using the credential.
  • the second processing computer 118 can forward the authorization request message to the authorizing entity computer 120 for authorization.
  • the authorizing entity computer 120 can approve or decline the authorization request message, and can then generate an authorization response message comprising the credential and an approve or decline indicator.
  • step S26 the authorizing entity computer 120 can transmit the authorization response message to the second processing computer 118.
  • step S28 the second processing computer 118 can obtain the token using the credential, and can replace the credential with the token in the authorization response message.
  • step S30 the second processing computer 118 can transmit the authorization response message with the token to the first processing computer 116.
  • step S32 the first processing computer 116 can transmit the authorization response message to the access device 114.
  • a clearing and settlement process can occur.
  • An acquirer associated with the resource provider operating the access device 114, the first processing computer 116, the second processing computer 118, and the authorizing entity computer 120 can perform a clearing and settlement process such as funds for the transaction are transferred from the authorizing entity computer 120 to the acquirer.
  • FIG. 2 shows a block diagram of a token service computer 200 according to an embodiment.
  • the token service computer 200 includes a processor 202 and a non-transitory computer readable medium 204, a token vault 206, and a network interface 208 coupled to the processor 202.
  • the non-transitory computer readable medium 204 may comprise a substitute device data module 204A, a token exchange module 204B, a validation module 204C, and a communication module 204D.
  • the computer readable medium may also comprise code, executable by the processor 202 to perform a method comprising: receiving, by the token service computer from a communication device, a substitute device data request message comprising a credential; after receiving the substitute device data request message, determining, by the token service computer, a substitute device data response message comprising substitute device data comprising a token; transmitting, by the token service computer, the substitute device data response message to the communication device, which provides the token to an access device, wherein the access device transmits an authorization request message comprising the token to a first processing computer, wherein the access device and/or the first processing network computer are capable of processing a transaction with the token, but are not capable of processing a transaction with the credential, wherein the first processing computer thereafter transmits the authorization request message to a second processing computer, which obtains the
  • the token vault 206 may store substitute data including tokens and their corresponding credential information.
  • the credential information may have been issued in country A, and the credential may be used at access devices and/or with processing computers in country A.
  • the credential may not be useable in countries B and C.
  • One set of substitute data that is capable of being used in country B and another set of substitute data that is capable of being used in country C can be stored in the token vault 206 along with the credential and its associated information.
  • the token vault 206 may store data in a database such as an OracleTM database.
  • the substitute device data module 204A may comprise code that causes the processor 202 to manage and store substitute device data.
  • the token exchange module 204B may comprise code that causes the processor 202 to provide substitute device data for credentials and vice-versa.
  • the validation module 204C may comprise code that causes the processor 202 to perform validation processes before taking action. For example, validation module 204C may validate substitute device data request messages before providing substitute device data to requestors. The validation module 204C in conjunction with the processor 202 can validate token resolution request messages before providing credentials associated with tokens.
  • the communication module 204D and the processor 202 can allow the token service computer 200 to communicate with external entities.
  • FIG. 3 illustrates a mobile communication device 300 according to an embodiment.
  • Mobile communication device 300 may include device hardware 304 coupled to a system memory 302.
  • Device hardware 304 may include a processor 306, a short range antenna 314, a long range antenna 316, input elements 310, a user interface 308, and output elements 312 (which may be part of the user interface 308).
  • input elements may include microphones, keypads, touchscreens, sensors, etc.
  • output elements may include speakers, display screens, and tactile devices.
  • the processor 306 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 300.
  • the processor 306 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 302, and can maintain multiple concurrently executing programs or processes.
  • the long range antenna 316 may include one or more RF transceivers and/or connectors that can be used by mobile communication device 300 to communicate with other devices and/or to connect with external networks.
  • the user interface 308 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of mobile communication device 300.
  • the short range antenna 314 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 316 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.
  • the system memory 302 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 302 may store computer code, executable by the processor 306, for performing any of the functions described herein.
  • the system memory 302 may comprise a computer readable medium comprising code, executable by the processor 306, for implementing a method comprising: transmitting, by a communication device to a token service computer, a substitute device data request message comprising a credential; receiving, by the communication device from the token service computer, a substitute device data response message comprising substitute device data comprising a token; and providing, by the communication device to an access device, the token, wherein the access device transmits an authorization request message comprising the token to a first processing computer, wherein the access device and/or the first processing computer are capable of processing a transaction with the token, but are not capable of processing a transaction with the credential, wherein the first processing computer transmits the authorization request message to a second processing computer, which obtains the credential using the token from the token service computer, and wherein the second processing computer subsequently processes the authorization request message using the credential.
  • the system memory 302 may also store a service application 302A, an interaction application 302B, an authentication module 302C, credentials/tokens 302D, and an operating system 302E
  • the service application 302A 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 302B may include code, executable by the processor 306, for forming a local connection or otherwise interacting with an external access device and/or a portable device.
  • the authentication module 302C may comprise code, executable by the processor 306, to authenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics.
  • System memory 302 may also store credentials and/or tokens 302D. Credentials may also include information identifying the mobile communication device 300 and/or the user of the mobile communication device 300.
  • FIG. 4 shows an example of a portable device 400 in the form of a card.
  • the portable device 400 can include a substrate with a memory 400A (which can store a credential and its associated information) and a contactless element interface 400B.
  • the contactless element interface 400B can allow the portable device 400 to communicate contactlessly with an external device such as a communication device or an access device.
  • FIG. 5 An example message exchange process between an exemplary portable device 502 and a communication device 503 is shown in FIG. 5.
  • the data exchange process in FIG. 5 can be used in, for example, step S12 in FIG. 1. It may also be used in step S16, where the communication device 104 perform the functions of the portable device 502 and the communication device 503 could perform the functions of the access device 114.
  • an authorizing entity e.g., an issuer, the user’s bank, etc.
  • the portable device 502 may be configured with one or more applications.
  • the issuer may assign a priority to these applications.
  • one application e.g., a U.S. payment or access application
  • another application e.g., a Canadian payment or access application
  • a different transaction processing protocol may be assigned a low priority on the same portable device.
  • 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 502.
  • the portable device 502 may store additional sensitive portable device data such as a PAN (primary account number), a CVV, an expiration date, and any other suitable information.
  • a user can subsequently use the portable device 402 to initiate a transaction (e.g., a request for substitute device data) using the communication device 503.
  • the user may hold the portable device 502 near the communication device 503, such that both devices may mutually detect each other.
  • the user may present (e.g., tap, hold near, etc.) the portable device 502 to the communication device 503 to exchange data with the communication device 503.
  • the portable device 502 may provide the communication device 503 with a list of available applications including at least a first application and a second application.
  • the communication device 503 may send an available applications request message to the portable device 502.
  • the available applications request message can request information regarding which applications (e.g., a list of application identifiers (AIDs)) are available on the portable device 502.
  • the available applications request message may be in the form of a SELECT PPSE command.
  • the portable device 502 identifies, from a memory of the portable device, available applications including at least a first application and a second application.
  • the portable device 502 then provides (e.g., transmits) an initial or first available applications response message to the communication device 503.
  • the available applications response message includes the list of the applications (e.g., a list of AIDs) available at the portable device 502 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 503 to use the first application over the second application to process the interaction.
  • the communication device 503 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 502 (step S512).
  • the communication device 503 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 502 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 503 may send transaction data to the portable device 502.
  • the communication device 503 may send such data in a processing options data object list (PDOL) message to the portable device 502.
  • the selected application e.g., the first application or international application
  • the portable device 502 upon receiving the application selection message at step S518, may send a terminal transaction data request to request transaction data from the communication device 503.
  • 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 503.
  • 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 502 for the transaction may include terminal processing options (TPO), an amount, and other information.
  • TPO terminal processing options
  • the transaction data may include one or more dynamic data elements (e.g., a random number).
  • the communication device 503 may send to the portable device 502, the terminal transaction data requested by the portable device 502.
  • 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).
  • GPO get processing options
  • PDOL processing options data object list
  • 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 503 supports.
  • the portable device 502 may obtain relevant credentials (e.g., card credentials), and may send a set of transaction processing information to the communication device 503 (arrow not shown in FIG. 5).
  • 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 503 to read account data stored on the portable device 502, 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, 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 502 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).
  • the 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).
  • IAD issuer application data
  • CVN cryptogram version number
  • DKI derived key indicator
  • the communication device 503 may send an account data request to the portable device 502 to read additional account data that may be stored on the portable device 502.
  • 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 503 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 503 from portable device 502.
  • the portable device 502 may send account data stored at the location indicated by the AFL to the communication device 503.
  • 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 502.
  • the account data, transaction processing information, and other data received by the communication device 503 in previous steps may be subsequently used by the communication device 503 to complete the payment transaction.
  • the user may remove the portable device 502 from the communication device 503, or otherwise disengage the portable device 502 from the communication device 503.
  • the portable device 502 may be powered off which also powers off the volatile memory of the portable device 502, clearing the flag previously set on the portable device 502.
  • Embodiments of the invention have several technical advantages. Embodiments of the allow a user to use a portable device storing a credential to access resources in situations that would otherwise not be possible. In addition, embodiments of the invention allow a user to use their own communication device and their own portable device when conducting a transaction. The credential of the user is never passed directly to an access device operated by a resource provider in a transaction with that resource provider. This improves data security since the credential is not exposed in any potential hacking or skimming attempts on the access device, or any attempts to obtain the real credential by unscrupulous resource providers.
  • 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++, or Perl 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, such as a 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 CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
  • RAM random access memory
  • ROM read only memory
  • Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La divulgation concerne un procédé. Le procédé consiste à : recevoir, en provenance d'un dispositif de communication, un message de demande comprenant un authentifiant. Le procédé consiste également à déterminer un message de réponse comprenant des données de dispositif de substitution comprenant un jeton et à transmettre le message de réponse au dispositif de communication. Le dispositif de communication fournit le jeton à un dispositif d'accès, qui transmet un message de demande d'autorisation comprenant le jeton à un premier ordinateur de traitement. Le dispositif d'accès et/ou le premier ordinateur de réseau de traitement sont capables de traiter une transaction avec le jeton, mais pas avec l'authentifiant. Le premier ordinateur de traitement transmet le message de demande d'autorisation à un second ordinateur de traitement, qui obtient l'authentifiant à l'aide du jeton provenant de l'ordinateur de service de jeton. Le second ordinateur de traitement traite le message de demande d'autorisation à l'aide de l'authentifiant.
PCT/US2023/075534 2023-09-29 2023-09-29 Système et procédé de traitement de jeton interopérable WO2025071623A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2023/075534 WO2025071623A1 (fr) 2023-09-29 2023-09-29 Système et procédé de traitement de jeton interopérable

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2023/075534 WO2025071623A1 (fr) 2023-09-29 2023-09-29 Système et procédé de traitement de jeton interopérable

Publications (1)

Publication Number Publication Date
WO2025071623A1 true WO2025071623A1 (fr) 2025-04-03

Family

ID=95202024

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/075534 WO2025071623A1 (fr) 2023-09-29 2023-09-29 Système et procédé de traitement de jeton interopérable

Country Status (1)

Country Link
WO (1) WO2025071623A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080078714A (ko) * 2005-12-12 2008-08-27 퀄컴 인코포레이티드 암호 키들의 대체를 위한 인증 및 분할 시스템 및 방법
US20150248686A1 (en) * 2014-02-28 2015-09-03 Cellco Partnership D/B/A Verizon Wireless Integrated platform employee transaction processing for buy your own device (byod)
US20180302223A1 (en) * 2012-01-10 2018-10-18 Jpmorgan Chase Bank, N.A. System and method for device registration and authentication
US20220400177A1 (en) * 2018-08-05 2022-12-15 Michael Francis Byrne Systems and methods for blockchain wireless services in a controlled environment
US11595373B2 (en) * 2015-12-04 2023-02-28 Visa International Service Association Secure token distribution

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080078714A (ko) * 2005-12-12 2008-08-27 퀄컴 인코포레이티드 암호 키들의 대체를 위한 인증 및 분할 시스템 및 방법
US20180302223A1 (en) * 2012-01-10 2018-10-18 Jpmorgan Chase Bank, N.A. System and method for device registration and authentication
US20150248686A1 (en) * 2014-02-28 2015-09-03 Cellco Partnership D/B/A Verizon Wireless Integrated platform employee transaction processing for buy your own device (byod)
US11595373B2 (en) * 2015-12-04 2023-02-28 Visa International Service Association Secure token distribution
US20220400177A1 (en) * 2018-08-05 2022-12-15 Michael Francis Byrne Systems and methods for blockchain wireless services in a controlled environment

Similar Documents

Publication Publication Date Title
US12074974B2 (en) Method and system for access token processing
US12120117B2 (en) Method and system for token provisioning and processing
US20190362341A1 (en) Binding cryptogram with protocol characteristics
US20210279734A1 (en) Real time interaction processing system and method
US20230179587A1 (en) Token processing system and method
JP7318042B2 (ja) 相互作用処理における端末タイプ識別
US20240078304A1 (en) Mobile user authentication system and method
WO2025071623A1 (fr) Système et procédé de traitement de jeton interopérable
US20240372728A1 (en) Multiple interaction processing
US20220343314A1 (en) Processing using machine readable codes and secure remote interactions
WO2024220432A1 (fr) Interaction à distance sécurisée à l'aide d'un dispositif de transaction portable
WO2024077127A1 (fr) Flux de messagerie pour interactions distantes à l'aide de données sécurisées
WO2025049260A1 (fr) Procédé de traitement de jeton de dispositif portable et de dispositif utilisateur

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: 23954548

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载