Portable device and communication device interaction process

Abstract

A method includes using a communication device comprising a first software application and a second software application. The method includes receiving, by a second software application from a second server computer, a URI (universal resource indicator) comprising a session identifier associated with a first server computer and providing, by the second software application to the first software application, the URI comprising the session identifier. The method includes contacting, by the first software application, the first server computer using the URI, receiving, by the first software application from the first server computer, interaction data, receiving, by the first software application from a portable device, access data, and initiating, by the first software application, a process using the access data and the interaction data.

Description

PORTABLE DEVICE AND COMMUNICATION DEVICE INTERACTION PROCESSCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of U .8.Provisional Application No. 63 / 676,012, filed on July 26, 2024, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] Device present interactions such as NFC (near field communication) or “tap” type interactions between portable device and other devices are common. Such interactions, however, cannot be used in some situations or are not desirable to use in other situations. For example, a remote resource provider such as an e-commerce merchant may not have the ability to conduct NFC transactions since they are remotely located with respect to a user seeking to interact with it. In the case of a remote interaction, the user may enter a username, password, and account number into the resource provider's Website to gain access to a desired resource. This type of remote interaction may not be secure, since passwords and account numbers can be obtained by unauthorized persons through hacking, social engineering, and the like. The resource provider’s Website may not have the ability to conduct NFC transactions to improve security.

[0003] In other situations, a resource provider may be proximate to a user and may have an access device that can interact with a portable device of a user. There may be instances, however, where the user may not feel comfortable interacting their portable device with the resource provider’s access device, since the portable device would be passing sensitive information (e.g., an account number) to the access device.

[0004] Still further, if the access device used by a resource provider is a commercially available mobile phone, then it may require specialized software to conduct device present type interactions (e.g., contactless).

[0005] Embodiments of the invention address these and other problems, individually and collectively.SUMMARY

[0006] One embodiment includes a method using a communication device comprising a first software application and a second software application. The method comprises; receiving, by the second software application from a second server computer, a URI (universal resource indicator) comprising a session identifierproviding, by the second software application to the first software application, the URI comprising the session identifier; contacting, by the first software application, a first server computer using the URI; receiving, by the first software application from the first server computer, interaction data; receiving, by the first software application from a portable device, access data; and initiating, by the first software application, a process using the access data and the interaction data.

[0007] Another embodiment of the invention includes a communication device comprising; a processor; and a computer readable medium, the computer readable medium comprising a first software application, a second software application, and code, executable by the processor, for performing a method comprising: receiving, by the second software application from a second server computer, a URI (universal resource indicator) comprising a session identifier; providing, by the second software application to the first software application, the URI comprising the session identifier; contacting, by the first software application, a first server computer using the URI; receiving, by the first software application from the first server computer, interaction data; receiving, by the first software application from a portable device, access data; and initiating, by the first software application, a process using the access data and the interaction data.

[0008] Another embodiment of the invention includes a method comprising: receiving, by a first server computer from a second server computer, interaction data associated with an interaction conducted using a communication device comprising a first software application and a second software application; generating, by the first server computer, a URI (uniform resource indicator) comprising a session identifier, the URI associated with the first server computer; transmitting, by the first server computer to the second server computer, the URI; retrieving, by the first server7computer using the session identifier from the URI, the interaction data; and providing, by the first server computer to the first software application, the interaction data, wherein the first software application receives access data from a portable device after receiving the interaction data

[0009] Another embodiment of the invention includes a first server computer comprising a processor, and a computer readable medium. The computer readable medium comprising code, executable by the processor, for performing a method comprising: receiving, from a second server computer, interaction data associated with an interaction conducted using a communication device comprising a first software application and a second software application; generating a URI (uniform resource indicator) comprising a session identifier, the URI associated with the first server computer; transmitting, to the second server computer, the URI; retrieving, using the session identifier from the URI, the interaction data; and providing, to the first software application, the interaction data, wherein the first software application receives access data from a portable device after receiving the interaction data,

[0010] These and other embodiments are described in further detaii below.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows a system and a flow diagram of a method for processing an interaction according to some embodiments of the disclosure.

[0012] FIG, 2 shows a system and another flow diagram of another method for processing an interaction according to some embodiments of the disclosure.

[0013] FIG. 3A shows an exemplary user interface of a pop-up window confirming an application being launched.

[0014] FIG, 38 shows an exemplary user interface prompting a contactless interaction.

[0015] FIG. 3C shows an exemplary user interface confirming a successful interaction.

[0016] FIG. 4 shows a block diagram of a first server computer according to an embodiment.

[0017] FIG. 5 shows a block diagram of a second server computer according to an embodiment.

[0018] FIG. 6 shows a block diagram of a communication device according to an embodiment,

[0019] FIG. 7 shows a diagram of a portable device according to an embodiment.DESCRIPTION

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

[0021] A “communication device” may be a device that Is operated by a user. Examples of communication devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, communication devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The communication device may include one or more processors capable of processing user input. The communication device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including , but not limited to, audio data, visual data, or biometric data. The communication 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,

[0022] AKportable device” may comprise a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or other, vise included at or near a surface of an object, A portable device may be a payment device 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 paymentprocessing 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 (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), 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.

[0023] 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.

[0024] 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 communication device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0025] "Access data" may include any suitable data that can be used to access a resource or create data that can access a resource. In some embodiments, access data may be account information for a payment account. Account information may include a PAN (primary account number), payment token, expiration date, verification values (e.g., CW, CW2, dCVV, dCW2), etc. In other embodiments, access data may be data that can be used to activate account data. For example, in some cases, account information may be stored on a mobile device but may not be activated until specific information is received by the mobile device. In other embodiments, access data could include data that can be used to access a location. Such access data may be ticket information for an event, data to access a building, transit ticket information, etc. In yet other embodiments, access data may include data used to obtain access to sensitive data. Examples of access data may include code or other data that are needed by a server computer to grant access to the sensitive data.

[0026] An “access request" may include a request for access to a resource. The resource may be a physical resource (e.g,, good), digital resources (e.g,, electronic documents, electronic data, etc.), or services. In some cases, an access request may be submitted by transmission of an access request message that includes accessrequest data. Typically, a device associated with a requestor may transmit the access request message to a device associated with a resource provider.

[0027] “Access request data” may include any information surrounding or related to an access request. Access request data may include access data. Access request data may include information useful for processing and / or verifying the access request. For example, access request data may include details associated with entities (e.g., resource provider computer, processor server computer, authorization computer, etc.) involved in processing the access request, such as entity identifiers (e.g., name, etc.), location information associated with the entities, and information indicating the type of entity (e.g., category code). Exemplary access request data may include information indicating an access request amount, an access request location, resources received (e.g., products, documents, etc.), information about the resources received (e.g., size, amount, type, etc.), resource providing entity data (e.g., resource provider data, document owner data, etc.), user data, date and time of an access request, a method utilized for conducting the access request (e.g., contact, contactless, etc ), and other relevant information. Access request data may also be known as access request information, transaction data, transaction information, or the like.

[0028] 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.

[0029] A “digital wallet” can store user profile information, payment information, bank account information, one or more digital wallet identifiers and / or the like and can be used in a variety of transactions, such as but not limited to eCommerce, social networks, money transfer / personal payments, mobile commerce, proximity payments, gaming, and / or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, and / or the like. A digital wallet may be designed to streamline the purchase and payment process. A digital wallet may allow the user to load one ormore payment cards onto the digital wallet so as to make a payment without having to enter an account number or present a physical card.

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

[0031] 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 mayalso comprise “transaction information;5such 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.

[0032] 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.

[0033] ‘Interaction data" can include data related to and / or recorded during an interaction. In some embodiments, interaction data can include an amount, a date, a time, one or more user identifiers, credentials, and / or additional data relating to an interaction between a sender user and receiver user,

[0034] A “resource provider5may 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.

[0035] 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."

[0036] 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.

[0037] 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 user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0038] A “processing network” may include data processing subsystems, networks, and operations. In embodiments of the invention, a processing network may be used to support and deliver authorization services, exception file services, and clearing and setlement services. A processing network may be a payment processing network able to transmit and receive financial system transaction messages (e.g., ISO 8583 messages), and process original credit and debit card transactions. An exemplary payment processing system may include VisaNet™. Payment processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions.

[0039] A “clearing and settlement process” may include a process of reconciling a transaction. A clearing process Is a process of exchanging financial details between an acquirer and an issuer to facilitate posting to a party’s account and reconciliation of the party’s settlement position. Settlement involves the delivery of funds from one party to another.

[0040] 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 be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. 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,

[0041] A "processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device ordevices. 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, AMD Ryzen, AMD Thread ripper, 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 processors).

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

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

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

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

[0046] “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 token ization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g,, a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.

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

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

[0049] An “application” may be computer code or other data stored on a computer readable medium (e.g., memory element or secure element) that may be executable by a processor to complete a task.

[0050] Embodiments of the invention can allow users to use their own communication devices and portable devices to securely conduct interactions with resource providers that may not otherwise have the ability to conduct device present interactions. For example, embodiments of the invention allow for the use of device interactions such as contactless interactions (e.g., NFC interactions) in situations where a resource provider is not preconfigured to conduct them.

[0051] FIG. 1 shows a system diagram with overlaid process flow. The system includes a communication device 102 comprising a first software application 102A and a second software application 102B. The communication device 102 can be under the control of a user that also holds or owns the portable device 103, or it may be operated by a different person. In some embodiments, the first software application 102A can be a storage application such as a wallet application. In some embodiments, the first software application 102A can also include an SDK (software development kit). In some embodiments, the first software application 102A could be managed by an application server (not shown in FIG, 1 ) such as a wallet server, while the SDK can be managed by and can directly communicate with the first server computer 104. In otherembodiments, the first software application 102A and / or the SDK can be in direct communication with and can be directly supported by the first server computer 104.

[0052] The second software appiication 1028 can be an internet browser or a dedicated resource provider application. The second software appiication 1028 can allow the communication device 102 to communicate with a second server computer 106. The second server computer 106 could be a resource provider computer operating a resource provider site (e.g.(a merchant Website).

[0053] The portable device 103 can interact with the communication device 102. The portable device 103 and the communication device 102 can interact via a short range communication medium such as NFC (near field communication), Bluetooth™, or the like,

[0054] The first server computer 104 and / or the second server computer 106 may also be in communication with a service provider computer 108. a transport computer 110, a processing network computer 112, and an authorizing entity computer 114. The service provider computer 108 can be a wallet server, a gateway computer, or other type of computer that provides data to and receives data from the transport computer 110. In some embodiments, the transport computer 110 can manage an account of the resource provider, and can be an acquirer computer. The processing network computer 112 may route transaction messages between various transport computers and authorizing entity computers. In some embodiments, the processing network computer may be in a payment processing network. The authorizing entity computer 114 may be an issuer computer which holds an account associated with a credential or a token on the portable device 103.

[0055] For simplicity of illustration, a certain number of components are shown in FIG. 1 . It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG. 1 .

[0056] Messages between at least the devices illustrated 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.

[0057] Methods in which a first server computer initiates authorization for a transaction can be described with respect to FIG. 1 . A user may wish to access a resource (e.g., secure data, a secure location, a good or service, etc.) from a resource provider associated with the second server computer 106. For example, the second server computer 106 may operate a host site such as a merchant Website. The user may operate the portable device 103 (e.g., contactless card) and the communication device 102 (e.g., smartphone). The communication device 102 can comprise the first software application 102A and the second software application 102B. In some embodiments, the first software application 102A may be a digital wallet application, and the second software application 102B may be an application that allows access to a resource provider such as a merchant. It may be, for example, a web browser, a resource provider application, etc.

[0058] Before any interactions are conducted, the first software application 102A can be installed on the communication device 102. The first software application 102A may be a generic wallet application (merchant agnostic) with an SDK built into it. The wallet application can be a third party wallet application, a device OEM (original equipment manufacturer) wallet, a PSP (payment service provider) wallet, etc.

[0059] In the case where the second server computer 106 is a resource provider computer (e.g., a merchant computer), the second server computer 106 can register with the first server computer 104 to obtain a resource provider identifier. In some embodiments, the first software application 102A can declare a URI scheme. The URI scheme can enable redirection from other applications (e.g., the second softwareapplication 102B) to the first software application 102A. in some embodiments, the second software application 1028 also declares a redirect URI back to the second software application 1028, The redirect URI back to the second software application 102B can enable the first software application 102A to launch the second software application 102B. For example, the second software application 102B can declare a URI scheme such as "fooddelivery: / / taptransaction?id=t01020304.”

[0060] At step S2, the user initiates the interaction (e.g., a transaction to obtain a resource, secure data, or access to a secure location) with a resource provider operating a host site on the second server computer 106 via the second software application 102B in the communication device. In some embodiments, the interaction is initiated when the user opens a resource provider link in a Web browser or application. The link can be originated from a QR code, NFC NDEF tag, proximity wireless connection (e.g., Airdrop, Nearby Share), instant message, e-mail, etc. The second software application 1028 could be a browser, which displays a host site on the second server computer 106. Alternatively, the second software application 102B can be a dedicated software application supported by the second server computer.

[0061] In some embodiments, the resource provider is a Web-based merchant. The user can navigate to the resource provider website (e.g., https:, 7sweeticecream.mymarketplace.com) using the second software application 1028 to select items to purchase, and checkout. The second software application 102B provides interaction data (e.g,, the selected Items, a value associated with the selected items, etc,) to the second server computer 106, After receiving the interaction data, the second server computer 106 may configure the interaction data (e.g., set a value for the interaction based on taxes, a currency, etc.).

[0062] At step S4, after receiving the interaction data, the second server computer 106 calls the first server computer 104 with a resource provider identifier (e.g,, a merchant name, a merchant identification code, etc.) to set up an interaction session. The resource provider is identified to the first server computer 104 as a registered resource provider by the resource provider identifier. The second server computer 106 provides the interaction data (e.g., the resource provider identifier, the value for the interaction) to the first server computer 104. The second server computer 106 can also provide a tap type identifier to indicate the type of interaction to beprocessed. In this example, the tap type identifier may indicate that the current interaction is for the user to obtain a resource from a resource provider. The first server computer 104 can then generate a session identifier for the request and transmits a URI comprising the session identifier (e.g., visattd: / / cybersource? id-012345678, where “012345678” is an exemplary session identifier) back to the second server computer 106, The first server computer 104 can aiso generate a tap session expiration date and time (e.g.,!!tap_session_expiry_utc: 2025-03-04 10:15:20”). The tap session expiration date and time can accompany the URI and can be used to ensure that the session does not extend beyond an acceptable time.

[0063] At step S6, after receiving the URI, the second server computer 106 transmits the URI string comprising the session identifier to the second software application 1028 on the communication device 102. For example, the URI may be pushed to the second software application 102B using javascript. In some embodiments, a Web browser pop-up window may launch to confirm the URI redirection.

[0064] FIG. 3A shows an exemplary user interface with an optional redirection pop-up window according to some embodiments. The pop-up window 301 can ask the user if they wish to continue opening the URI in the first software application (e.g., “Visa TTCD”). The user can select “open” to launch the first software application 102A.

[0065] Referring back to FIG. 1 , at step S8 the user confirms the redirect (e.g. , in the pop-up window) and the first software application 102A is launched.

[0066] At step S10, the first software application 102A can obtain the session identifier from the URI, and can use it to retrieve the interaction data from the first server computer 104. The interaction data may also include any messages or images that the operator of the second server computer 106 wants to provide to the user of the portable device 103. For example, the first software application 102A on the communication device 102 may contact the first server computer 104 and can provide a request comprising the session identifier to the first server computer 104. The first server computer 104 may provide the interaction data associated with the session identifier such as the value for the interaction, the resource provider identifier, etc, to the first software application 102 A. The first software application 102A on the communication device 102 may then display the interaction data to the user, and canprompt the user to interact their portable device 103 with the communication device 102, For example, the first software application 102A on the communication device 102 may request that the user provide payment for the interaction by tapping their portable device 103 against an NFC reader in the communication device 102 in a contactless interaction.

[0067] In some embodiments, if the resource provider is close to the user of the portable device 103, the interaction data may also include a location of the resource provider. The first software application 102A can check the location of the communication device and compare it against the location of the resource provider for added security. For example, if the resource provider operates an Ice cream truck, it may provide an extra layer of security to confirm that the user and the ice cream truck are within a given distance of one another,

[0068] FIG. 3B shows an exemplary user interface prompting a contactless Interaction according to some embodiments. A first software application 305 can display interaction details 306 and a prompt 308 to tap their portable device against the screen of the communication device.

[0069] Referring back to FIG. 1 , at step S12, the user conducts the contactless interaction by tapping the portable device 103 to an NFC reader in the communication device 102. The communication device 102 can obtain access data from the portable device 103 using NFC. In some embodiments, the access data may be a credential or a token.

[0070] In some embodiments, the communication device 102 may provide at least some of the interaction data received from the first server computer 104 to the portable device 103, The portable device 103 can then generate a cryptogram by encrypting the at least some of the interaction data and the access data on the portable device 103 using a first cryptographic key. The portable device 103 then provides the cryptogram and the access data to the first software application 102A on the communication device 102 via NFC.

[0071] If the first server computer 104 is processing the interaction, the method proceeds with steps S14 and S16. At step S14, the interaction data, the access data, and the cryptogram are sent from the first software application 102A to the first server computer 104. In step S16, the first server computer 104 generates and transmits anauthorization request message comprising the access data, the cryptogram, and the amount to the authorizing entity computer 114 via the service provider computer 108, transport computer 110, and processing network computer 112 for authorization . Upon receiving the authorization request message, the authorizing entity computer 114 analyzes the access data in the authorization request message and then determines if the interaction shouid be authorized, it can make this determination by determining if the account associated with the access data has sufficient credit or value to pay for the amount in the authorization request message. The authorizing entity computer 114 then generates an authorization response message indicating whether the interaction is approved or declined. The authorization response message is sent by the authorizing entity computer 114 to the first server computer 104 via the service provider computer 108, the transport computer 110, and the processing network computer 112.

[0072] At step S18A, after the authorization response message is received by the first server computer 104, the first server computer 104 generates a redirect URI back to the second software application 102B comprising the session identifier and a return code. The UR! may be the second software application 102B URL For example, the second software application 102B can be a web browser and the redirect URI may re-direct the user operating the communication device 102 to the resource provider website (e.g., https: / / sweeticecream.mymarketpiace.com) on the second server computer 106.

[0073] At steps 20A and 22A:the first software application 102A retrieves from the first server computer 104 the redirect URI, and the communication device 102 is re-directed back to the second software application 102B and the second server computer 106.

[0074] At step 24A, the second server computer 106 may confirm with the first server computer 104 that the interaction was completed successfully. The user may then be granted access to a resource by the resource provider. FIG. 3C shows an exemplary user interface confirming that the interaction was successful, in FIG. 3C, the user interface can display a QR code which will allow the user to obtain the desired resource from the resource provider.

[0075] In other embodiments, steps S18A and S20A can be conducted earlier, after step S14, without waiting for the completion of authorization process in S16. This is a Ul (user interface ) / UX (user experience) optimization that can be used to avoid a situation where the user waits too long while waiting for S16 to complete.

[0076] If steps S 18A and S20A are cond ucted earlier than the completion of the authorization process in step S16, then the first server computer 104 can respond to the second server computer 106 that the result is not yet available. The first server computer 104 would then need to communicate with the second server computer 106 when the authorization process in step S16 is completed.

[0077] The flow in FIG. 2 shows a situation where the second server computer 106 initiates authorization of the interaction instead of the first server computer 104. In FIG. 2, steps S2 to S14 are the same as in FIG. 1 and will not be repeated here.

[0078] If the second server computer 106 processes the interaction, after step S14, the first server computer 104 can encrypt the access data from the portable device 103 using a secret (e.g., a symmetric key) that is shared with one or more of the service provider computer 108, the transport computer 110, the processing network computer 112, or the authorizing entity computer 114. The first server computer 104 also generates a redirect URI that redirects the user from the first software application 102A back to the second software application 102B. The redirect URI comprises the session identifier and a return code. If the second software application 102B displays a webpage of the second server computer 106, the first server computer 104 may generate a redirect URL back to the webpage (e.g., https : / / sweetice area m. mymarketplace . com ) .

[0079] At steps S17, S19, and S21 , the first software application 102A retrieves from the first server computer 104 the redirect URI and the communication device 102 launches the second software application 102B and navigates to the second server computer 106.

[0080] At step 23, the second server computer 106 retrieves the encrypted access data from the first server computer 104 (e.g., using the session identifier). The second server computer 106 then generates and sends an authorization request message comprising the encrypted access data and the interaction data to the authorizing entity computer 114 for authorization as in FIG. 1 via the service providercomputer 108, the transport computer 110, and the processing network computer 112. Upon receiving the authorization request message, the authorizing entity computer 114 analyzes the access data in the authorization request message and then determines if the interaction should be authorized. It can make this determination by determining if the account associated with the access data has sufficient credit or value to pay for the amount in the authorization request message. The authorizing entity computer 114 then generates an authorization response message indicating whether the interaction is approved or declined. The authorization response message is sent by the authorizing entity computer 114 to the first server computer 104 via the service provider computer 108, the transport computer 110, and the processing network computer 112. Any of the entities 108, 110, 112, and 114 can decrypt the encrypted credential or token with a corresponding secret.

[0081] In some embodiments, URI redirection is used for registration (e.g., tap to add card) or identity authentication (e.g., tap to confirm) methods, and are not limited to the authorization steps described above with respect to FIGs. 1 and 2. For example, after the credential is captured by the first software application in step S12, it can be used to register to or add a card to the second software application 102B. For example, after step S12, the first server computer 104 could be a token requestor computer, which may send an access data request message (e.g., a token request message) to a service computer (not shown) such as a token service computer, and may receive an access data response message with the access data. The access data could be provided to the second software application 102B via the first software application 102A. In another example, in a “tap to confirm" interaction, the tap interaction between the portable device 103 and the communication device 102 can be used by a resource provider operating the second sewer computer 106 or an authorizing entity operating the authorizing entity computer 114 to confirm that the user is in possession of the portable device 103.

[0082] In the processes in FIGs. 1 and 2, after authorization processing, a clearing and settlement process can occur between the transport computer 110, the processing network computer 112 and the authorizing entity computer 114.

[0083] In the processes in FIGs. 1 and 2, the access data may be a token in some embodiments. If the access data comprises a token, then the processingnetwork computer 112 can de-tokenize the token to obtain a credential associated with the token from a token service computer. It can then modify an authorization request message to include the credential instead of the token before forwarding the authorization request message to the authorizing entity computer 114 for authorization. The processing network computer 112 can also perform a re- tokenization process with respect to the authorization response message.

[0084] FIG. 4 illustrates a block diagram of a first server computer 400 according to embodiments. The first server computer 400 may comprise a processor 402, which may be coupled to a computer readable medium 404, a data storage 406, and a network interface 408. The data storage 406 may contain data such as tokens, credentials, token credential mappings, generated session identifiers, authentication data, user information, communication device information, etc.

[0085] The computer readable medium 404 may comprise executable code for performing a method. The method comprises: receiving, by the first server computer from a second server computer, interaction data associated with an interaction conducted using a communication device comprising a first software application and a second software application; generating, by the first server computer, a URI (uniform resource indicator) comprising a session identifier, the URI associated with the first server computer; transmitting, by the first server computer to the second server computer, the URI; retrieving, by the first server computer using the session identifier from the URI, the interaction data; and providing, by the first server computer to the first software application, the interaction data, wherein the first software application receives access data from a portable device after receiving the interaction data

[0086] The computer readable medium 404 may comprise a number of software modules including a communication module 404A, a cryptography module 404B, an authorization module 404C, a URI generation module 404D, a session identifier generation module 404E, and a registration module 404F.

[0087] The communication module 404A may comprise code that causes the processor 402 to generate, forward, reformat, and receive messages, and / or otherwise communicate with other entities. For example, the communication module 404 A can comprise code that enables the processor 402 to receive transaction requestmessages from the communication device and transmit data and information requests to a second server computer or a communication device.

[0088] The cryptography module 404B may comprise code, executable by the processor 402 to perform cryptography functions. Encryption functions may include encrypting or decrypting data, signing and verifying signed data, generating cryptographic keys, etc.

[0089] The authorization moduie 404C comprises code, executable by the processor 402 to perform authorization processing. Authorization processing can include generating authorization request messages, processing authorization request messages, sending authorization request messages, and receiving authorization request messages.

[0090] The URI generation module 404D can comprise code, executable by the processor 402 to generation URIs.

[0091] The session identifier generation moduie 404E may comprise code executable by the processor 402 to generation session identifiers,

[0092] The registration module 404F may comprise code executable by the processor 402 to perform registration processes,

[0093] FIG. 5 illustrates a block diagram of a second server computer 500 according to embodiments. The second server computer 500 may comprise a processor 502, which may be coupled to a computer readabie medium 504, data storage 506, and a network interface 508. The data storage 506 may contain data such as tokens, credentials, token credential mappings, generated session identifiers, authentication data, user information, communication device information, etc.

[0094] The computer readable medium 504 may comprise executable code for performing method as described above.

[0095] The computer readabie medium 504 may comprise a number of software modules including a communication module 504A, an authorization module 504B, and a host site module 504 D.

[0096] The communication module 504 A may comprise code that causes the processor 502 to generate, forward, reformat, and receive messages, and / or otherwise communicate with other entities,

[0097] The authorization module 504B comprises code, executable by the processor 402 to perform authorization processing. Authorization processing can include generating authorization request messages, processing authorization request messages, sending authorization request messages, and receiving authorization request messages.

[0098] The host site moduie 504c can comprise code that causes the processor 502 to run and operate a host site such as a Web site.

[0099] FIG. 6 is a biock diagram illustrating an example of a communication device 600. The communication device 600 can be a mobile device (e.g„ mobile phone) with a computer readable medium 604. The communication device 600 may include device hardware 608 coupled to a system memory 602.

[0100] Device hardware 608 may include a processor 610, input elements 612, a short range antenna 614, a user interface 616, output elements 618, and a long range antenna 620. Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Exampies of output elements may include speakers, display screens, and tactile devices. The processor 610 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 the communication device 600. The processor 610 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 602, and can maintain multiple concurrently executing programs or processes.

[0101] The long range antenna 620 may include one or more RF transceivers and / or connectors that can be used by the communication device 600 to communicate with other devices and / or to connect with externa! networks. The input and output elements 618, 618 allow a user to interact with and invoke the functionalities of the communication device 600. The short range antenna 614 may be configured to communicate with externa! devices through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 620 may beconfigured to communicate with a remote base station and a remote cellular or data network, over the air.

[0102] The system memory 602 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.

[0103] The system memory 602 can comprise a computer readable medium 604 comprise a first application 604A and a second application 602A. The first application 604A can be a storage application such as a wallet application, and may comprise an SDK 604A-1 , The second application 602B can be dedicated resource provider application or a browser.

[0104] The computer readable medium 604 can comprise code, executable by the processor 610 to perform operations comprising: receiving, by the second software application from a second server computer, a URI (universal resource indicator) comprising a session identifier; providing, by the second software application to the first software application, the URI comprising the session identifier; contacting, by the first software application, a first server computer using the URI; receiving, by the first software application from the first server computer, interaction data; receiving, by the first software application from a portable device, access data; and initiating, by the first software application, a process using the access data and the interaction data.

[0105] FIG. 7 shows an exampie portable device 700 in the form of a card. The portable device 700 comprises a substrate 702 such as a plastic substrate. A contactless element interface 710 for interfacing with a data access or data transfer device may be on or embedded within the substrate 702. The contactless element interface 710 may include a chip and an RF antenna, 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 700 may be issued to a user by an authorizing entity operating an authorizing entity computer.

[0106] The portable device 700 may also comprises a processor 706, which can process data.

[0107] The portable device 700 may also include a memory 708. which may store user information such as an account number, expiration date, and a username, in some cases, the memory 708 may include a secure element, and / or may also store information such as access data such as a sender credential (e.g., a sender PAN) or a receiver credential (e.g., a receiver PAN). The memory 708 may also comprise a number of applications and application identifiers.

[0108] Information in the memory 708 can be transmitted by the portable device 700 to another device such as a communication device using the contactless element interface 710. Information may also be printed or embossed on the substrate 702. The substrate 702 may also have a magnetic stripe 704 on it.

[0109] Embodiments of the invention provide a number of advantages. Embodiments of the disclosure enable a user to conduct contactless interactions even when resource providers do not have the capability to directly accept and process such contactless interactions. Further, if the communication device with which the user interacts is the user’s own device, then the user can be assured that the user is not providing information from their portable device to a potential fraudulent device. As a result, embodiments provide for improved security over conventional processes that do not use contactless interactions.

[0110] Further, embodiments of the invention can be used to perform any suitable device present type interaction. Examples of such interactions can include a “tap to add card device token," a “tap to add card card-on~file token,” an “issuer tap to authenticate,” a “tap to pay merchant," and a “tap to pay by link."

[0111] Other embodiments are also contemplated. For example, another embodiment includes a method comprising: providing, by a second server computer to a first server computer, interaction data associated with an interaction conducted using a communication device comprising a first software application and a second software application; receiving, by the second server computer from the first server computer, a URI (uniform resource indicator) comprising a session identifier; and transmitting, by the second server computer to the second software application, the URI comprising the session identifier, wherein the URI redirects the communication device to the first server computer via the first software application.

[0112] Another embodiment includes a second server computer programmed to perform the above method.

[0113] 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.

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

[0115] 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.

[0116] 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,

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

Claims

WHAT IS CLAIMED IS:

1. A method using a communication device comprising a first software application and a second software application, the method comprising: receiving, by the second software application from a second server computer, a URI (universal resource indicator) comprising a session identifier associated with a first server computer; providing, by the second software application to the first software application, the URI comprising the session identifier; contacting, by the first software application, the first server computer using the URI: receiving, by the first software application from the first server computer, interaction data for an interaction; receiving, by the first software application from a portable device, access data; and initiating, by the first software application, a process using the access data and the interaction data.

2. The method of claim 1, wherein the process is a provisioning process or an authentication process.

3. The method of claim 1 , wherein the process is an authorization process.

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

5. The method of claim 1 , wherein the first software application is a storage application with an SDK (software development kit) associated with the first server computer, and the second software application is a browser.

6. The method of claim 1 , further comprising, prior to receiving theURI:providing, by the second software application to the second server computer, the interaction data.

7. The method of claim 6. the second server computer provides the interaction data to the first server computer, and the first server computer generates the URI in response to receipt of the interaction data by the first server computer.

8. The method of claim 1, wherein the access data comprises a credential or a token.

9. The method of claim 1 , further comprising: providing, by the first software application to the first server computer, the access data and the interaction data, wherein the first server computer generates an authorization request message comprising the access data and the interaction data and transmits the authorization request message to an authorizing entity computer for authorization.

10. The method of claim 1, wherein the URI is a first URI, and the method further comprises: providing, by the first software application to the first server computer, the access data, wherein the access data Is encrypted by the first server computer; and receiving, by the first software application from the first server computer, a second URI with the session identifier, wherein the communication device is thereafter redirected to the second server computer and the second server computer retrieves the encrypted access data using the session identifier in the second URI, and generates an authorization request message with the encrypted access data and transmits the authorization request message to an authorizing entity computer via a transport computer and a processing network computer, wherein the authorizing entity computer, the processing network computer, and the transport computer decrypts the encrypted access data before the authorizing entity computer authorizes the interaction.

11. A communication device comprising a processor; anda computer readable medium, the computer readable medium comprising a first software application, a second software application, and code, executable by the processor, for performing a method comprising.' receiving, by the second software application from a second server computer, a UR! (universal resource indicator) comprising a session identifier associated with a first server computer; providing, by the second software application to the first software application, the URI comprising the session identifier; contacting, by the first software application, the first server computer using the URI; receiving, by the first software application from the first server computer, interaction data for an interaction; receiving, by the first software application from a portable device, access data; and initiating, by the first software application, a process using the access data and the interaction data.

12. The communication device of claim 11 , wherein the communication device is a mobile phone,13. The communication device of claim 11 , wherein the first software application is a storage application with an SDK (software development kit) associated with the first server computer, and the second software application is a browser.

14. The communication device of claim 11 , wherein the first software application is a storage application with an SDK (software development kit) associated with the first server computer, and the second software application is a resource provider application.

15. The communication device of claim 11, wherein the access data comprises a credential.

16. A method comprising:receiving, by a first server computer from a second server computer, interaction data associated with an interaction conducted using a communication device comprising a first software application and a second software application; generating, by the first server computer, a URI (uniform resource indicator) comprising a session identifier, the URI associated with the first server computer; transmitting, by the first server computer to the second server computer, the URI; retrieving, by the first server computer using the session identifier from the URI, the interaction data; and providing, by the first server computer to the first software application, the interaction data, wherein the first software application receives access data from a portable device after receiving the interaction data.

17. The method of claim 16, further comprising: receiving, by the first server computer from the first software application, the access data and the interaction data; generating an authorization request message comprising the access data and the interaction data; and transmitting the authorization request message to an authorizing entity computer for authorization.

18. The method of claim 16, wherein the URI is a first URI, and the method further comprises: receiving, by the first server computer from the first software application, the access data; encrypting, by the first server computer, the access data; and transmitting, by the first server computer to the first software application, a second URI with the session identifier, wherein the communication device is thereafter redirected to the second server computer and the second server computer retrieves the encrypted access data using the session identifier in the second URI, and generates an authorization request message with the encrypted access data and transmits the authorization request message to an authorizing entity computer via a transport computer and a processing network computer, wherein the authorizing entitycomputer, the processing network computer, and the transport computer decrypt the encrypted access data before the authorizing entity computer authorizes the interaction,19. The method of claim 16, wherein the portable device is card.

20. The method of claim 16, wherein the access data comprises a credential or a token.

Images