Browser integration for contactless interactions
By establishing a communication session between a user computing device and a mobile device to obtain and transmit tokens for authorization, the method addresses the inconvenience and security issues of manual credential input, enabling secure and convenient interactions on devices lacking contactless capabilities.
Patent Information
- Application Number
- PCT/US2024/030277
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-05-20
- Publication Date
- 2025-11-27
AI Technical Summary
Many user computing devices lack contactless interaction capabilities, making it inconvenient and insecure to input credentials manually or store them, which can lead to security concerns.
A method that enables user computing devices to establish a communication session with a mobile device to obtain a token from a portable device, using a token service computer, and transmit this token to a resource provider for authorization, bypassing the need for direct contactless interaction capabilities in the user device.
Enables secure and convenient credential transactions without manual input, enhancing security by using tokens instead of credentials, and allowing interactions on devices without contactless capabilities.
Smart Images

Figure US2024030277_27112025_PF_FP_ABST
Abstract
Description
BROWSER INTEGRATION FOR CONTACTLESS INTERACTIONSCROSS-REFERENCE TO RELATED APPLICATIONS
[0001] None.BACKGROUND
[0002] Some interactions may require a credential associated with the user. The user can input the credential into an application or webpage on a user computing device to initiate the interaction. The credential may be associated with an account managed by an authorizing entity (e.g., issuer) on behalf of the user.
[0003] Contactless interactions are known to be convenient and secure.However, many user computing devices do not have contactless interaction capability (e.g., near-field communication (NFC)). It is more common for mobile devices (e.g., smartphones) and portable devices (e.g., payment cards) to be equipped with this technology.
[0004] Additional problems exist with providing credentials to a resource provider. Traditionally, credentials can be manually entered, which is inconvenient and timeconsuming. Credentials can also be stored to a device, but this can create security concerns.
[0005] Embodiments of the disclosure address these and other problems, individually and collectively.SUMMARY
[0006] One embodiment is related to a method comprising: establishing a communication session between a user computing device and a mobile device of a user; receiving, by the user computing device from the mobile device, a token, whereinthe token is received by the mobile device after the mobile device transmits a credential obtained from a portable device of the user to a token service computer; and transmitting, by the user computing device, the token to a resource provider computer, which generates and transmits an authorization request message comprising the token to a processing network computer for authorization.
[0007] Another embodiment is related to a computer-implemented method comprising receiving, by a computing system from a user computing device, a credential, wherein the user computing device obtained the credential from a portable device via a mobile device in communication with the user computing device; obtaining, by the computing system based on the credential, a token; transmitting, by the computing system to the mobile device, the token, thereby causing the mobile device to transmit the token to a user computing device, wherein the user computing device provides the token to a resource provider computer which generates an authorization request message comprising the token; receiving, by the computing system, the authorization request message; obtaining, by the computing system, the credential using the token; modifying, by the computing system, the authorization request message to include the credential; and transmitting, by the computing system to an authorizing entity computer, the authorization request message.
[0008] Other embodiments are related to server computers programmed to perform the above-described methods.
[0009] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.BRIEF DESCRIPTION OF THE DRAWINGS
[0010] FIG. 1 shows a block diagram of an interaction processing system according to embodiments.
[0011] FIG. 2 shows a block diagram of a user computing device.
[0012] FIG. 3 shows a block diagram of a mobile device.
[0013] FIG. 4 shows a block diagram of components of a processing network computer.
[0014] FIG. 5 shows a block diagram of a portable device.
[0015] FIG. 6 illustrates a process flow of an interaction according to various embodiments.
[0016] FIG. 7A shows a user computing device interface prompting a user to conduct a contactless interaction between a mobile device and a portable device.
[0017] FIG. 7B shows a user computing device interface with browser fields filled by a token.TERMS
[0018] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.
[0019] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.
[0020] A “user computing device” may be a computing device that is operated by a user. Examples of user computing devices may include a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. The user computing device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi- Max, or any other communication medium that may provide access to a network such as the Internet or a private network.
[0021] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two partiesand a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment. An interaction can include a transaction interaction, a data transfer interaction, an access interaction, etc.
[0022] “Interaction data” can include data related to and / or recorded during an interaction. Interaction data can include an amount, a date, a time, a resource identifier, a resource provider identifier, a user identifier, credentials, and / or additional data relating to an interaction between a user and a resource provider.
[0023] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc. A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
[0024] 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 value credentials, identification cards, certified documents, access cards, passcodes and other login information, etc.
[0025] 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.
[0026] “Tokenization” is a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g. a token) that may be associated with the payment account identifier. Further, 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.
[0027] A “cryptogram” may include a piece of obscured text such as encrypted text. A cryptogram may be formed by encrypting input data with an encryption key such as a symmetric encryption key. In some embodiments, a cryptogram is reversible so that the inputs that are used to form the cryptogram can be obtained using the same symmetric key to perform a decryption process. In some embodiments, if input data is encrypted using a private key of a public / private key pair, the cryptogram may also be a digital signature. A digital signature may be verified with a public key of the public / private key pair. In some embodiments, a cryptogram may include a dCW (dynamic card verification value).
[0028] A cryptogram can be generated in any suitable manner. In some embodiments, the input to the cryptogram can include data elements including an account identifier such as primary account number, and a variable data element such as a counter, a time of day, or interaction value. Such data may be included using an encryption process such as DES, triple DES, or AES using any suitable encryption keys. The encryption keys may also be UDKs or unique derived keys, and may be generated based upon device specific information such as an account number, which may be encrypted using a master derivation key (MDK). The cryptogram can be verified by another computer such a remote computer by either decrypting the cryptogram to and verifying the decrypted contents with other data (e.g., an account number stored on file), or by encrypting other inputs and then comparing the encrypted result to the cryptogram.
[0029] 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 authorizationrequest 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 user name, 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.
[0030] 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., PCS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.
[0031] 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.
[0032] A “digital wallet” can include a software-based system that allows an individual to conduct electronic interactions. A digital wallet may store user profile information, credentials, account information, one or more digital wallet identifiers, one or more tokens specific to the individual and / or electronic device, one or more token authentication cryptograms (TACs) specific to the individual and / or the electronic device, and / or the like and can be used in a variety of interactions, 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. A digital wallet may allow the user to load one or more payment cards onto the digital wallet so as to make a payment without having to enter an account number or present a physical card.
[0033] A “service provider application” may include an application maintained and operated by an entity that provides a service (e.g., a digital wallet) to a user. In some embodiments, a service provider application may also be referred to as a “digital wallet provider.” A service provider application may provide standalone user-facing software applications that store account numbers, or representations of the account numbers (e.g., token(s)), on behalf of a user to facilitate interactions at more than one unrelated entity (e.g., resource providers), perform person-to-person interactions, or load amounts into the digital wallet. Additionally, a service provider application may also provide one or more of the following functions: generating a token authentication cryptogram (TAC), storing multiple tokens behalf of a user, storing other information including a physical address, an email address, and an interaction history, initiating an interaction by one or more methods, such as providing a user name and password, near field communication (NFC) or a physical token, and may facilitate pass-through or two-step interactions.
[0034] The term “verification” and its derivatives may refer to a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and / or in good standing.
[0035] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).
[0036] 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.
[0037] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.DETAILED DESCRIPTION
[0038] Embodiments allow for contactless interaction tokens to be used by user computing devices when initiating an interaction, even if the user computing device is not equipped with contactless interaction capability.
[0039] A user who operates a user computing device may also operate a mobile device and a portable device comprising a credential. When the user initiates aninteraction from the user computing device, they may be prompted for the credential. The user computing device can establish a communication session with the mobile device and prompt the user to conduct a contactless interaction between the mobile device and the portable device. The mobile device can obtain the credential from the portable device, obtain a token for the credential from a token service computer, and transmit the token back to the user computing device. The token can be used by the user computing device to conduct the interaction.
[0040] To illustrate, a user requesting a resource from a resource provider may enter a checkout webpage using a browser on a user computing device. The checkout webpage may prompt the user for a credential, such as a PAN. Because the credential may be sensitive, or cumbersome to input manually, the user may select to provide the credential using a mobile device and a portable device. In response, the browser may establish a communication session with the mobile device, instructing the user to conduct a contactless interaction between the mobile device and portable device. The user can bring the portable device near the mobile device so that the mobile device can obtain the credential from the portable device over a short range communication protocol via its contactless interface. The user device can obtain a token for the credential, for example from a token service computer, and transmit it over the communication session to the user computing device. The user computing device can obtain the token and the user can proceed with the checkout process.
[0041] As an advantage of embodiments, the user does not need to manually input the credential when the device that the user is initiating the interaction from is not equipped to conduct a contactless interaction. Moreover, with embodiments, a token can be used in place of the credential, which is more secure than sending the credential itself.
[0042] FIG. 1 shows an interaction processing system 100 according to embodiments of the disclosure. The system 100 comprises a portable device 104, a mobile device 102, a user computing device 101 , a resource provider computer 106, a processing network computer 108, a token service computer 110, a transport computer114, and an authorizing entity computer 112. The portable device 104 may interact with the mobile device 102 to transmit information such as a credential to the mobile device 102. The mobile device 102 can be in operative communication with the user computing device 101 and token service computer 110. The processing network computer 108 can be in operative communication with the token service computer 110, the transport computer 114, and the authorizing entity computer 112. The resource provider computer 106 may be in operative communication with the user computing device 101 and the transport computer 114.
[0043] For simplicity of illustration, a certain number of components are shown in FIG. 1 . It is understood, however, that the system may include more than one of each component. In addition, some embodiments of the system may include fewer than or greater than all of the components shown in FIG. 1 .
[0044] Messages between at least the devices of the system 100 in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.
[0045] An interaction may require a token of a credential from the portable device 104. The user computing device 101 may not have the capability to obtain the credentialfrom the portable device 104 via a contactless interaction, so it may obtain the token of the credential through the mobile device 102.
[0046] The mobile device 102 can be a device such as a mobile phone with a contactless interface. The portable device 104, which may be in the form of a card, can interact with the mobile device 102 via contactless interaction to transmit the credential. The mobile device 102 can capture the credential from the portable device 104 and obtain a token for the credential from the token service computer 110. For example, the mobile device 102 can generate and transmit a token request message comprising the credential to the token service computer 110, and in return may receive a token response message comprising a token for the credential.
[0047] The token service computer 110 can include one or more computers that generate, process, and maintain tokens. For example, the token service computer 110 may include or be in communication with a token database where the generated tokens are stored. Additionally or alternatively, the token database may maintain one-to-one mapping between a token and a credential represented by the token. In some embodiments, various entities of a tokenization ecosystem may assume the roles of the token service computer 110. For example, the processing network computer 108 can include the token service computer 110 by implementing the token services.
[0048] The token service computer 110 can store tokens in association with their corresponding credentials. Furthermore, the credentials can be installed in association with an account identifier for the user for which the account for the credentials is maintained.
[0049] The mobile device 102 can provide the token to the user computing device 101 by establishing a communication session with the user computing device 101. The user computing device 101 can then utilize the token in an interaction with the resource provider computer 106. The user computing device 101 can provide the token to the resource provider computer 106, which may generate and transmit an authorization request message comprising the token to the processing network computer 108. In some embodiments, the resource provider computer 106 transmits authorizationrequest messages to the processing network computer 108 via a transport computer 114. The transport computer 114 may be operated by an entity (e.g., acquirer) that manages an account on behalf of the resource provider of resource provider computer 106.
[0050] After receiving the token, the processing network computer 108 can process the interaction. The processing network computer 108 may validate the token and detokenize the token with the token service computer 110. The processing network computer 108 may modify the authorization request message to include the credential and an indication of whether or not the token is validated. The processing network computer 108 can transmit the authorization request message to authorizing entity computer 112.
[0051] The authorizing entity computer 112 can include hardware and / or software configured to determine whether to authorize interactions. The authorizing entity computer 112 can issue and manage one or more accounts associated with the user of the portable device 104. Managing an account can include authorizing interactions on the account. The authorizing entity computer 112 can also store credentials (e.g., account numbers) associated with various users.
[0052] The authorizing entity computer 112 can generate and transmit an authorization response message comprising an authorization result. The authorization result can be based upon the credential and the indication of whether or not the token is validated. The authorization response message may be transmitted to the resource provider computer 106 and the user computing device 101.
[0053] In some embodiments, the interaction is initiated in order to gain access to a resource associated with the resource provider computer 106. The resource provider computer 106 may determine whether or not to grant the user access to the resource based upon the authorization result. If the authorizing entity computer 112 generates an authorization result indicating that the authorization is approved, then access to the resource may be granted. If the authorizing entity computer 112 determines that the authorization is not approved, then access to the resource may be denied.
[0054] FIG. 2 shows a block diagram of a user computing device 101 . The user computing device 101 may comprise a processor 204 coupled to a memory 202, a network interface 206, and a computer readable medium 208. The computer readable medium can comprise a resource provider application 208A, a communication module 208B, a browser 208C, and a service provider application 208D.
[0055] The memory 202 can be used to store data and code. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. For example, the memory 202 can store interaction data, tokens, etc.
[0056] The computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: establishing a communication session between the user computing device and a mobile device of a user; receiving, from the mobile device, a token, wherein the token is received by the mobile device after the mobile device transmits a credential obtained from a portable device of the user via a contactless interaction to a token service computer; and transmitting the token to a resource provider computer, which generates and transmits an authorization request message comprising the token to a processing network computer for authorization.
[0057] The resource provider application 208A can be an application that is operated or provided by a resource provider. The resource provider application 208A can allow a user to obtain a resource for an interaction. For example, in some embodiments, the resource provider application 208A can allow a user to purchase resources, which can be provided to the user of the user computing device 101 after completion and authorization of an interaction (e.g., a transaction).
[0058] The communication module 208B may comprise code or software, executable by the processor 204, for communicating with other devices. The communication module 208B may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronicmessages for transmission. The communication module 208B, in conjunction with the processor 204, may receive information from the computer readable medium 208 and generate an electronic message in an appropriate data format in conformance with a transmission protocol so that the message may be sent to one or more entities within system 100 of FIG. 1 . The electronic message may then be passed to the network interface 206 for transmission.
[0059] The browser 208C may be a program executable by the processor 204, for displaying and navigating between webpages. For example, in some embodiments, the browser 208C can allow a user to obtain a resource for an interaction from a resource provider operating a resource provider webpage. The browser 208C may also enable the processor 204 to detect a field for a credential on a webpage.
[0060] The service provider application 208D can include an application configured to establish and manage a communication session between the user computing device 101 and the mobile device 102. The service provider application 208D can enable the processor 204 to transmit and receive data from the mobile device 102. In some instances, the service provider application 208D synchronizes operations between the mobile device 102 and the user computing device 101.
[0061] The network interface 206 may include an interface that can allow the user computing device 101 to communicate with external computers. The network interface 206 may enable the user computing device 101 to communicate data to and from another device (e.g., mobile devices, resource provider computers, etc.). Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include Wi-Fi™. Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronicmessages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.
[0062] FIG. 3 shows a block diagram of a mobile device 102. The exemplary mobile device 102 may comprise a processor 354. The processor 354 may be coupled to a memory 352, a network interface 356, input elements 360, output elements 362, a contactless interface 364, and a computer readable medium 358. The computer readable medium 358 can comprise a communication module 358A and a service provider application 358B.
[0063] The memory 352 can be used to store data and code. For example, the memory 352 can store one or more tokens, one or more credentials, interaction data, etc. The memory 352 may be coupled to the processor 354 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.
[0064] The input elements 360 may include any suitable device(s) capable of inputting data into the mobile device 102. Examples of input elements 360 include buttons, touchscreens, touch pads, microphones, etc.
[0065] The output elements 362 may include any suitable device(s) that may output data. Examples of output elements 362 may include display screens, speakers, and data transmission devices. For example, the output elements 362 can include a display screen capable of displaying a response value to a user of the mobile device 102.
[0066] The contactless interface 364 may include any suitable hardware and / or software capable of sending and receiving data over a contactless interaction. Forexample, the contactless interface 364 may include an NFC chip which enables short- range, wireless communication between two devices.
[0067] The computer readable medium 358 may comprise code, executable by the processor 354, for performing a method comprising: obtaining a credential from a portable device via a contactless interaction, transmitting the credential to a token service computer to receive a token, and transmitting the token to a user computing device.
[0068] The communication module 358A may comprise code or software, executable by the processor 204, for communicating with other devices. The communication module 358A may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronic messages for transmission through the mobile device 102 to or from a portable device, token service computer, user computing device, etc. When an electronic message is received by the mobile device 102 via the network interface 356, it may be passed to the communication module 358A. The communication module 358A, in conjunction with the processor 354, may identify and parse the relevant data based on a particular messaging protocol used. The communication module 358A, in conjunction with the processor 354, may transmit any received information to an appropriate module within the mobile device 102. The communication module 358A, in conjunction with the processor 354, may receive information from one or more of the modules in the mobile device 102 and generate an electronic message in an appropriate data format in conformance with a transmission protocol so that the message may be sent to one or more entities within system 100 illustrated in FIG. 1. The electronic message may then be passed to the network interface 356 for transmission.
[0069] The service provider application 358B can include an application configured to establish a communication session with a user computing device. The service provider application 358B may be similar to the service provider application 208D described above with respect to FIG. 2.
[0070] The network interface 356 may include an interface that can allow the mobile device 102 to communicate with external devices. The network interface 206 may enable the user computing device 101 to communicate data to and from another device (e.g., portable devices, token service providers, user computing devices, etc.). Some examples of the network interface 356 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, a contactless interface (e.g., an NFC antenna), or the like. The wireless protocols enabled by the network interface 356 may include Wi-Fi™. Data transferred via the network interface 356 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 356 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.
[0071] FIG. 4 shows a block diagram of a processing network computer 108. The processing network computer 108 can include functionality for facilitating the processing of interactions. The processing network computer 108 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the processing network computer 108 may comprise a server coupled to a network interface 406 (e.g., by an external communication interface), and databases of information. The processing network computer 108 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Paymentssystem) which processes authorization requests and a Base II system which performs clearing and settlement services. The processing network computer 108 may use any suitable wired or wireless network, including the Internet.
[0072] The processing network computer 108 can communicate with a token service computer 110 to tokenize credentials and detokenize tokens. The processing network computer 108 can determine whether or not a token is validated.
[0073] The processing network computer 108 can comprise a processor 404 coupled to a memory 402, a network interface 406, and a computer readable medium 408. The computer readable medium can comprise an authorization processing module 408A and a communication module 408B.
[0074] The memory 402 can be used to store data and code. The memory 402 may be coupled to the processor 404 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. For example, the memory 402 can store interaction data, tokens, credentials, etc.
[0075] The computer readable medium 408 may comprise code, executable by the processor 404, for performing a method comprising: receiving an authorization request message; obtaining, a credential using a token; modifying, the authorization request message to include the credential; and transmitting, to an authorizing entity computer, the authorization request message.
[0076] The authorization processing module 408A may comprise code that can cause the processor 404 to evaluate authorization request messages for interactions so the authorizing entity computer 112 can determine if the interactions should be authorized. For example, the processing network computer 108 may evaluate the risk associated with the interaction. The authorization processing module 408A may also include code for routing or modifying authorization request and response messages as they pass between various parties such as authorizing entity computers (e.g., issuer computers) and transport computers (e.g., acquirer computers).
[0077] The communication module 408B may comprise code or software, executable by the processor 404, for communicating with other devices. The communication module 408B may be configured or programmed to perform some or all of the functionality associated with receiving, sending, and generating electronic messages for transmission through the processing network computer 108 to or from any of the devices shown in FIG. 1 . When an electronic message is received by the processing network computer 108 via the network interface 406, it may be passed to the communication module 408B. The communication module 408B, in conjunction with the processor 404, may identify and parse the relevant data based on a particular messaging protocol used. As examples, the received information may comprise identification information, authorization information, request information, response information, and / or any other information that processing network computer 108 may utilize. The communication module 408B, in conjunction with the processor 204, may transmit any received information to an appropriate module within the processing network computer 108. The communication module 408B, in conjunction with the processor 404, may receive information from one or more of the modules in the processing network computer 108 and generate an electronic message in an appropriate data format in conformance with a transmission protocol so that the message may be sent to one or more entities within system 100 of FIG. 1. The electronic message may then be passed to the network interface 406 for transmission.
[0078] The network interface 406 can be similar to the network interface 206 of FIG. 2 and its description will not be repeated here.
[0079] FIG. 5 shows a portable device 105 in the form of a card. The portable device 105 comprises a substrate 500A such as a plastic substrate. A contactless element interface 500B for interfacing with a data access or data transfer device may be on or embedded within the substrate 500A. The contactless element interface 500B may include a chip and may include the capability to communicate and transfer data using near field communications (NFC) technology or other short range communications technology. The portable device 105 may be assigned to a user by an authorizing entity.
[0080] The portable device 500 may also include a memory 500C, which may store user information such as an account number, expiration date, and a user name. In some cases, the memory 500C may include a secure element, and / or may also store information such as access data. Information in the memory 500C can be transmitted by the portable device 105 to another device such as a user device using the contactless element interface 500B. Information may also be printed or embossed on the substrate 500A. The substrate 500A may also have a magnetic stripe 500D on it.
[0081] FIG. 6 illustrates an interaction process flow according to embodiments. The process flow can relate to the system 100 of FIG. 1 . A user may initiate an interaction from a browser on a user computing device 101. Initially, the browser on the user computing device may load a website, e.g., a resource provider website.
[0082] In some embodiments, the user computing device 101 is not configured to capture a credential from the portable device 104 (e.g., the user computing device 101 does not include a contactless interface). However, the mobile device 102 may be NFC- enabled and capable of conducting contactless interactions. Embodiments may utilize the contactless interaction capability of the mobile device 102 to obtain the credential.
[0083] At step S2 a webpage accessed by a browser on the user computing device 101 may request a credential in order to conduct the interaction. For example, there may be browser fields requesting a PAN of the account that will be debited to pay for a resource. The browser may detect the browser fields. The browser may determine that the user computing device 101 does not support contactless interactions. The browser may present to the user an interface with options for providing the credential. The user can interface with the user computing device 101 and select the option to provide the credential using contactless interaction capability of their mobile device 102.
[0084] FIG. 7A shows an example user computing device interface 700A requesting a credential for a contactless interaction between a mobile device and a portable device. Interface 700A may be presented to the user during step S4 of the process flow of FIG. 6. The interface 700A can comprise a browser field 702 prompting the user to provide a credential (e.g., card number), and three credential options: 704A,704B, and 704C. Credential options 704B and 704C may reference credentials that were stored using autofill. Credential option 704A can reference providing a credential through a contactless interface of a mobile device.
[0085] As an advantage over existing autofill methods associated with credential options 704B and 704C, credential option 704A does not statically store credential or token information. The user can select credential option 704A, and hold the portable device (e.g., card) near the mobile device (e.g., phone) to conduct a contactless interaction, and the mobile device can capture the credential (and optionally a cryptogram).
[0086] At step S3, in response to the user input, the browser can cause the user computing device 101 to establish a communication session with the mobile device 102. The communication session may be established via the service provider applications executing on the user computing device 101 and the mobile device 102. The communication session may be over Wi-Fi™, Bluetooth™, or other suitable communication channels. In some embodiments, the communication session with may be established over the Internet or a cellular network. In some instances, the communication session with the mobile device of the user is further established based on determining that the user computing device does not support contactless interactions.
[0087] At step S4, via the communication session, the browser can trigger the mobile device 102 to enable NFC and prompt the user to interact the portable device 104 with the mobile device 102. The mobile device 102 can capture the credential, and optionally a cryptogram for the interaction. In some embodiments, the mobile device 102 can perform an authentication process (e.g., CDCVM).
[0088] Referring back to FIG. 6, at step S6, the mobile device 102 can transmit the credential obtained from the portable device 104 to the token service computer 110, and the token service computer 110 can return a token for the credential. For example, the mobile device 102 may transmit a token request message to the token service computer comprising the credential. Upon receiving the token request message, thetoken service computer 110 can retrieve a token from a pool of available tokens in a token database. In other embodiments, the token service computer 110 can generate the token. The generated token may be based on the credential. For example, the token service computer 110 can generate the token, which may appear to be a random value, using the credential and / or other data associated with the user, the mobile device 102, and / or the user account. In other embodiments, the token service computer 110 can generate a random or pseudorandom value for the token. The token service computer 110 can transmit to the mobile device 102 a token response message comprising the token.
[0089] In some aspects, the token service computer 110 verifies the credential and / or the cryptogram before obtaining the token. For example, the token service computer 110 may decrypt the token cryptogram included in the message, confirm that the payment credentials are authentic and associated with the requesting device, and / or assess risk associated with the requesting device.
[0090] The mobile device 102 may optionally transmit the cryptogram to the token service computer 110 to obtain a token cryptogram (e.g., TAVV / DTW) for the interaction.
[0091] At step S8, after receiving the token from the token service computer 110, the mobile device 102 can transmit the token to the user computing device 101 . The service provider application on the mobile device 102 can transmit the token over the established communication session with the user computing device 101.
[0092] In some aspects, the user computing device receives the token and populates populating fields in the browser. The user computing device 101 can use the token to populate fields in the browser on the resource provider webpage requesting the credential (e.g., checkout webpage). The token may then be used by the resource provider computer in generating the authorization request message, as further described below.
[0093] FIG. 7B shows an exemplary user computing device interface 700B after receiving a token from a mobile device. The token can be used to fill the browser field 702B which prompts for the credential. The user may proceed with a checkout process after the browser field 702B has been filled by the token.
[0094] Referring back to FIG. 6, at step S10, after receiving the token from the mobile device 102, the user computing device 101 can transmit the token to the resource provider computer 106. The user computing device 101 may transmit the token to the resource provider computer 106 over a network such as the Internet.
[0095] At steps S12-S13, after receiving the token from the user computing device 101 , the resource provider computer 106 can generate an authorization request message comprising the token and transmit it to the processing network computer 108 via the transport computer 114. The resource provider computer 106 can request authorization for the interaction with the processing network computer 108 and the authorizing entity computer 112 before granting or denying the user access to a resource.
[0096] At step S1 , after receiving the authorization request message comprising the token, and optionally the token cryptogram, from the user computing device 101 , the processing network computer 108 may detokenize the token by communicating with the token service computer 110. The processing network computer 108 may make a request to obtain the credential that was associated with the token. The token service computer 110 may look up the credentials (e.g., a primary account number) corresponding to the received token, and may return the credentials to the processing network computer 108.
[0097] In some aspects, e.g., prior to detokenizing the tokenized credentials, the processing network computer validates the token and / or the cryptogram. For example, After the token service computer 110 receives the request, it may confirm that a token request message is authentic by decrypting the token cryptogram included in the message, by confirming that the payment credentials are authentic and associated with the requesting device, and / or assessing risk associated with the requesting device.
[0098] At step S16, the processing network computer 108 can modify the authorization request message to include the credential and an indication of the validation, and transmit the authorization request message to the authorizing entity computer 112.
[0099] At step S18, after receiving the authorization request message from the processing network computer 108, the authorizing entity computer 112 can generate an authorization result based on the credential and the indication of the validation. The authorizing entity computer 112 can further generate and send an authorization response message comprising the authorization result to the resource provider computer 106 via the processing network computer 108. If the interaction is in connection with a request for access to a resource, the authorization result can indicate whether the access to the resource is granted, and based on the authorization result, the resource provider computer 106 can grant or deny the user access to the resource.
[0100] At a later date or time, a clearing and settlement process may take place between the transport computer 114 operated by an acquirer associated with the resource provider computer 106, the processing network computer 108 and the authorizing entity computer 112.
[0101] For added security, in some embodiments, the mobile device 102 can perform an authentication process to validate the identity of the user. Moreover, in some embodiments, during the contactless interaction between the mobile device 102 and the portable device 104, the mobile device 102 may obtain a cryptogram for the interaction in addition to the credential at step S4. The cryptogram may be specific to the interaction and may further provide an extra layer of security. The mobile device 102 can transmit the cryptogram, which may be tokenized, along with the token to the processing network computer 108 via the user computing device 101 and the resource provider computer 106, and the processing network computer 108 can validate the cryptogram.
[0102] Embodiments of the disclosure have a number of technical advantages. As shown above, the methods according to various embodiments enable a contactlessinteraction to be initiated from a user computing device without contactless interaction capability. Moreover, embodiments do not disrupt existing rails and thus may not be costly to implement. Resource providers do not need to reformat websites or applications to integrate embodiments. Users may benefit from added convenience and security because they do not have to manually input the credential to a browser field on the user computing device, and the credential information is less susceptible to fraud because it is not statically stored.
[0103] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the disclosure.
[0104] 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.
[0105] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment 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), andmay 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.
[0106] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
[0107] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
[0108] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.
Claims
WHAT IS CLAIMED IS:1 . A computer implemented method comprising: establishing a communication session between a user computing device and a mobile device of a user; receiving, by the user computing device from the mobile device, a token, wherein the token is received by the mobile device after the mobile device transmits a credential obtained from a portable device of the user to a token service computer; and transmitting, by the user computing device, the token to a resource provider computer, which generates and transmits an authorization request message comprising the token to a processing network computer for authorization.
2. The method of claim 1 , wherein the mobile device obtained the credential from the portable device via a contactless interaction.
3. The method of claim 2, wherein the mobile device further obtained a cryptogram via the contactless interaction with the portable device.
4. The method of claim 1 , further comprising: populating fields in a browser with the token which is used by the resource provider computer in generating the authorization request message.
5. The method of claim 1 , further comprising: loading a website in a browser on the user computing device; detecting field of the website for entering credentials; determining that the user computing device does not support contactless interactions; and based on determining that the user computing device does not support contactless interactions, establishing the communication session with the mobile device of the user.
6. The method of claim 1 , wherein: the processing network computer validates the token, modifies the authorization request message to include the credential and an indication of the validation, and transmits the authorization request message to an authorizing entity computer.
7. The method of claim 6, wherein: the credential was received in connection with a request for access to a resource, and the authorizing entity computer generates an authorization result, based on the credential and the indication of the validation, indicating whether the access to the resource is granted, and generates and sends an authorization response message comprising the authorization result, thereby causing access to the resource to be granted or denied.
8. The method of claim 1 , wherein: the mobile device comprises a contactless interface used to obtain the credential; and the user computing device does not include a contactless interface.
9. A user computing device comprising: a processor; and a non-transitory computer-readable medium comprising code, executable by the processors, for implementing a method comprising: establishing a communication session between the user computing device and a mobile device of a user; receiving, from the mobile device, a token, wherein the token is received by the mobile device after the mobile device transmits a credential obtained from a portable device of the user via a contactless interaction to a token service computer; andtransmitting the token to a resource provider computer, which generates and transmits an authorization request message comprising the token to a processing network computer for authorization.
10. The user computing device of claim 9, wherein the mobile device further obtained a cryptogram via the contactless interaction with the portable device, the method further comprising: populating fields in a browser with the token which is used by the resource provider computer in generating the authorization request message.11 . The user computing device of claim 9, the method further comprising: loading a website in a browser on the user computing device; and detecting field of the website for entering credentials.
12. The user computing device of claim 11 , the method further comprising: determining that the user computing device does not support contactless interactions; and based on determining that the user computing device does not support contactless interactions, establishing the communication session with the mobile device of the user.
13. The user computing device of claim 11 , wherein: the processing network computer validates the token, modifies the authorization request message to include the credential and an indication of the validation, and transmits the authorization request message to an authorizing entity computer.
14. The user computing device of claim 13, wherein: the credential was received in connection with a request for access to a resource, andthe authorizing entity computer generates an authorization result, based on the credential and the indication of the validation, indicating whether the access to the resource is granted, and generates and sends an authorization response message comprising the authorization result, thereby causing access to the resource to be granted or denied.
15. The user computing device of claim 9, wherein: the mobile device comprises a contactless interface used to obtain the credential; and the user computing device does not include a contactless interface.
16. A computer-implemented method comprising: receiving, by a computing system from a user computing device, a credential, wherein the user computing device obtained the credential from a portable device via a mobile device in communication with the user computing device; obtaining, by the computing system based on the credential, a token transmitting, by the computing system to the mobile device, the token, thereby causing the mobile device to transmit the token to a user computing device, wherein the user computing device provides the token to a resource provider computer which generates an authorization request message comprising the token; receiving, by the computing system, the authorization request message; obtaining, by the computing system, the credential using the token; modifying, by the computing system, the authorization request message to include the credential; and transmitting, by the computing system to an authorizing entity computer, the authorization request message.
17. The method of claim 16, wherein a cryptogram is further received with the credential, the method further comprising: verifying, by the computing system, the credential and the cryptogram before obtaining the token.
18. The method of claim 16, wherein the mobile device obtained the credential from the portable device via a contactless interaction.
19. The method of claim 18, wherein the mobile device further obtained a cryptogram via the contactless interaction with the portable device.
20. The method of claim 16, wherein the user computing device further populates fields in a browser with the token which is used by the resource provider computer in generating the authorization request message.21 . The method of claim 16, further comprising: validating the token before modifying the authorization request message to include the credential; wherein the authorization request message further comprises an indication of the validation.
22. The method of claim 21 , wherein: the credential was received in connection with a request for access to a resource, and the authorizing entity computer generates an authorization result, based on the credential and the indication of the validation, indicating whether the access to the resource is granted, and generates and sends an authorization response message comprising the authorization result to the computing system, the method further comprising: receiving, by the computing system from the authorizing entity computer, the authorization response message; and transmitting, by the computing system, the authorization response message thereby causing access to the resource to be granted or denied based on the authorization result.
23. The method of claim 16, wherein: the mobile device comprises a contactless interface used to obtain the credential; andthe user computing device does not include a contactless interface.
24. A system comprising: one or more processors; and one or more non-transitory computer-readable media comprising code, executable by the one or more processors, for implementing the method of any one of claims 16-23.
Citation Information
Patent Citations
System user authentication using short-range wireless communication
JP2014530410A
Authentication of user computers
JP2016208510A
Sponsored Connectivity to Cellular Networks Using Existing Credentials
JP2018513462A
How to use certificate safely at mobile terminal
KR1020130060736A
Mobile device transaction credential lending
US20230169501A1