Terminal type identification in interactive processing

Abstract

A method is disclosed. The method includes receiving an available application request message from an access device by a user device. The available application request message includes an access device type identifier. The method further includes determining whether an association exists between the access device type identifier and one or more application identifiers from a plurality of application identifiers stored on the user device. The plurality of application identifiers correspond to different applications on the user device. The method further includes sending an available application response from the user device to the access device, in part based on the existence of the association. The available application response includes the one or more application identifiers from the plurality of application identifiers associated with the access device type identifier.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 202080011544.1, entitled "Terminal Type Identifier in Interactive Processing".

[0002] Cross-referencing related applications

[0003] This international application claims priority to U.S. Patent Application No. 16 / 262,699, filed January 30, 2019, the disclosure of which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0004] Systems and methods for processing transactions between a user device and an access device are known. For example, in the case of a payment transaction, a consumer may use a user device (e.g., a payment card or digital wallet application on a smartphone device) to perform contactless (or contact) data exchange with an access device (e.g., a point-of-sale (POS) terminal). In another example, a user device may be used to perform data exchange with an access device (e.g., a smart card reader) to grant a user access to a building and / or event. In these examples, data is communicated or exchanged between the user device and the access device.

[0005] However, existing systems and methods for processing transactions have many problems. For example, when the user device is a smartphone, the device may indiscriminately prompt the user to enter their credentials whenever the device is used for any type of transaction (e.g., payment or non-payment). However, for some transaction types, this additional processing, such as user prompts, may be unnecessary or even detrimental to the transaction experience. For example, in a transportation transaction, a user taps their phone against a terminal with a revolving gate to enter a secure area in a transportation station. Each customer in the station needs to move quickly through the revolving gate. In this environment, having the user enter their credentials into their device before allowing them to enter the restricted area would be cumbersome and, in many cases, unnecessary.

[0006] Another issue arises when a user may maintain multiple applications on their user device. In this scenario, each application is capable of performing different types of transactions. As the user device approaches an access device, the applications on the user device (e.g., a digital wallet application) may send a list of applications associated with the digital wallet on the user device to the access device. However, the user may want to use a specific application when encountering a particular type of access device (e.g., using a specific credit card to pay at a specific retailer where the user has a loyalty account, or using a specific public transport application associated with a prepaid card to pass through a train terminal gate, rather than always using the default credit card). The user may want to do this without physically interacting with their user device, selecting the appropriate application at the time of the transaction.

[0007] The embodiments of this disclosure address these and other problems individually and collectively. Summary of the Invention

[0008] One embodiment includes a method comprising: receiving an available application request message from an access device by a user device, wherein the available application request message includes an access device type identifier; determining by the user device whether there is an association between the access device type identifier and one or more application identifiers of a plurality of application identifiers stored on the user device, wherein the plurality of application identifiers correspond to different applications on the user device; and sending an available application response from the user device to the access device, in part based on whether the association exists, the available application response including the one or more application identifiers of the plurality of application identifiers associated with the access device type identifier.

[0009] Another embodiment includes a communication device comprising: a processor; and a computer-readable medium coupled to the processor. The computer-readable medium includes code executable by the processor for implementing a method. The method includes: receiving an available application request message from an access device, wherein the available application request message includes an access device type identifier; determining whether an association exists between the access device type identifier and one or more application identifiers among a plurality of application identifiers stored on the user device, wherein the plurality of application identifiers correspond to different applications on the user device; and sending an available application response to the access device, in part based on the existence of the association, the available application response including the one or more application identifiers among the plurality of application identifiers associated with the access device type identifier.

[0010] Another embodiment includes a method comprising: generating an available application request message by an access device, wherein the available application request message includes an access device type identifier; sending the available application request message to a user device by the access device; and receiving an available application response from the user device by the access device, the available application response including one or more application identifiers associated with the access device type identifier.

[0011] Another embodiment includes a method comprising: receiving an available application request message from an access device by a user device, wherein the available application request message includes an access device type identifier; and determining, in part based on the access device type identifier, whether user interaction on the user device is necessary.

[0012] Further details regarding embodiments of this disclosure are described in the detailed description and the accompanying drawings. Attached Figure Description

[0013] Figure 1 A block diagram of a system according to an embodiment is shown.

[0014] Figure 2 A block diagram of a user device and an access device according to an embodiment is shown.

[0015] Figure 3 A diagram of a user device according to an embodiment is shown.

[0016] Figure 4 A flowchart illustrating a message exchange process between a user device and an access device according to an embodiment is shown.

[0017] Figure 5 A flowchart illustrating a message exchange process between a user device and an access device according to an embodiment is shown.

[0018] Figure 6 A flowchart illustrating a message exchange process between a user device and an access device according to an embodiment is shown.

[0019] Figure 7 An example diagram illustrating the relationship between different applications on a user device and access device type identifiers according to an embodiment.

[0020] Figure 8 A block diagram illustrating a building access system is shown.

[0021] Figure 9 A block diagram illustrating the payment processing system is shown. Detailed Implementation

[0022] Implementations may include methods and systems capable of facilitating transactions between user devices (e.g., mobile phones, contact / contactless cards) and access devices (e.g., POS terminals, transportation or event gates, smart card readers, etc.). Messages exchanged between the user device and the access device during a transaction may depend on the characteristics (e.g., software and / or hardware features) of both the user device and the access device. For example, an access device may be configured to send a message including an access device type identifier to the user device when the access device detects the user device's proximity. The access device identifier identifies the type of access device to the user device (e.g., a public transportation smart card reader, a point-of-sale (POS) terminal for a specific retailer, a baseball stadium electronic ticket reader, etc.).

[0023] The user device may receive messages from the access device, and the messages may include an access device type identifier. The user device may associate the access device type identifier with one or more application identifiers on the user device (each application identifier corresponds to a different application). Based on this association, the user device may send a response message to the access device containing one or more application identifiers associated with the access device type identifier.

[0024] Explained, if a user device receives a message containing a public transport terminal identifier from a transport terminal, the user device may send only the application identifier corresponding to the transport-specific application and / or payment application selected by the user for the transport transaction. This is more efficient than the user device sending a generic list of application identifiers from its device to the transport terminal. By reducing unnecessary data that might otherwise be sent from the user device to the transport terminal, processing speed is improved, and the need for additional computing resources (e.g., additional memory and processor power) is reduced. Furthermore, by sending a specific list of application identifiers to the transport terminal, this avoids the transport terminal needing to select one application from many, and potentially the application that the user does not necessarily prefer.

[0025] Additionally, the user device can be configured to determine whether to perform certain functions on the user device in part based on an access device type identifier received from the access device. For example, depending on the value of the access device type identifier, the user device may or may not prompt the user for verification information, such as a biometric sample, password, or PIN. This can make processing more efficient because the user device does not have to request such information from the user in all types of transactions.

[0026] The embodiments improve upon conventional systems and offer several technical advantages. As explained above, the embodiments save user time by reducing or eliminating the need for users to interact with their user devices to conduct transactions in certain situations. Additionally, the user device can automatically select one or more appropriate applications based on the terminal type. This reduces the risk of human error, ensuring that any desired transactions are conducted efficiently and using the applications the user requires.

[0027] It should be noted that this improvement can also be similarly applied to user devices, such as those using contact and / or contactless cards. For example, a card may contain multiple applications (e.g., credit cards, debit cards, etc.), and each application may correspond to one or more access device types. Users can securely and conveniently use a single card to perform various transaction types, and the appropriate application on the card is automatically presented to the specific access device type. This increases security and convenience because users need to carry fewer user devices to perform a wider variety of transactions.

[0028] Finally, the embodiments also enable or disable the user device to perform functions based on the type of transaction being executed. For example, the user device executes a transaction with an appropriate level of security and / or convenience (e.g., speed) for a specific type of transaction. In non-payment transactions, such as when a user taps their user device against a public transport terminal reader at a turntable, the user device may not prompt the user for a PIN, password, or biometric signature, allowing the transaction to proceed without hindrance to the user authentication process. However, payment transactions at a retailer's POS terminal may require higher security, and the user device may authenticate the user before allowing the user device to complete the transaction with the POS terminal.

[0029] Before discussing the details of some embodiments of this disclosure, the description of some terms may help to understand the various embodiments.

[0030] A “user device” can be any suitable device that can be used by a user (e.g., a payment card or mobile phone). A user device can take any suitable form. Some examples of user devices include cards with magnetic stripes or contactless elements (e.g., payment cards such as debit cards, credit cards, and prepaid cards), cellular phones, PDAs, personal computers (PCs), tablet computers, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, memory, processor, computer-readable medium, and any other suitable components.

[0031] A “mobile device” (sometimes referred to as a mobile communication device) can include any electronic device that a user can transport or operate, and that also provides the ability to communicate remotely with a network. A mobile communication device can communicate using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that provides access to networks such as the Internet or private networks. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptops, wearable devices (e.g., watches), vehicles (e.g., cars and motorcycles), personal music players, handheld dedicated readers, etc. A mobile device can include any suitable hardware and software for performing such functions, and can also include multiple devices or components (e.g., when a device remotely accesses a network by being attached to another device—that is, using another device as a modem—two devices used together can be considered a single mobile device).

[0032] "Contactless" communication can be communication that exchanges data between two devices without the two devices being physically coupled. Without limiting the generality of the foregoing, "contactless" communication can include data transmission via near field communication (NFC) transceivers, laser, radio frequency, infrared communication, or other radio frequency or wireless communication protocols, such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc.

[0033] An "access device" can be any suitable device for providing access to something. Access devices can take any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablets, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, transportation or event gates, access systems, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data to or from a user device, or associate with a user device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a user device.

[0034] A "resource provider" can be an entity that provides resources (such as goods, services, access to secure data, access to location, etc.) during a transaction. For example, a resource provider can be a merchant, a transportation or venue operator, a building owner, a government entity, etc. A "merchant" is typically an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0035] "Authentication data" can include any data suitable for authenticating an entity. Authentication data can be obtained from a user or a device operated by the user. Examples of authentication data obtained from a user may include a PIN (Personal Identification Number), biometric data, password, etc. Examples of authentication data obtained from a device may include a device serial number, hardware security element identifier, device fingerprint, phone number, IMEI number, etc.

[0036] "Access data" can include any suitable data that can be used to access resources or create data that allows access to resources. In some embodiments, access data can be account information for a payment account. Account information can include a PAN, payment token, expiration date, and verification value (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data can be data that can be used to activate account data. For example, in some cases, account information can be stored on a mobile device but may not be activated until the mobile device receives specific information. In other embodiments, access data can include data that can be used to access a location. Such access data can be event ticket information, data for accessing buildings, transportation ticket information, etc. In other embodiments, access data can include data for obtaining access rights to sensitive data. Examples of access data can include code or other data required by a server computer to authorize access rights to sensitive data.

[0037] An "access request" can include a request to access a resource. A resource can be a physical resource (e.g., a product), a digital resource (e.g., electronic documents, electronic data, etc.), or a service. In some cases, an access request can be submitted by sending an access request message that includes access request data. Typically, the device associated with the requester can send the access request message to the device associated with the resource provider.

[0038] "Access request data" may include any information about or related to the access request. Access request data may include access data. Access request data may include information that can be used to process and / or verify the access request. For example, access request data may include details associated with entities involved in processing the access request (e.g., resource provider computers, processing server computers, authorizing computers, etc.), such as entity identifiers (e.g., names, etc.), location information associated with the entity, and information indicating the entity type (e.g., category codes). Exemplary access request data may include information indicating the amount of access request, the location of the access request, the resources received (e.g., products, documents, etc.), information about the received resources (e.g., size, quantity, type, etc.), resource provider entity data (e.g., resource provider data, document owner data, etc.), user data, the date and time of the access request, information about the method used to make the access request (e.g., contact, contactless, etc.), and other relevant information.

[0039] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, and any object or document that can be used for authentication. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information. Other instances of credentials include PANs (Master Accounts), PIIs (Personally Identifiable Information) (e.g., name, address, and phone number), etc.

[0040] An "authorizing entity" can be an entity that typically uses an authorized computer to authorize a request. Authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. An "issuer" can typically include a commercial entity that maintains user accounts (e.g., a bank). Issuers may also issue payment credentials to users that are stored on user devices such as cellular phones, smart cards, tablets, or laptops.

[0041] A "service provider" can be an entity that can typically provide resources such as goods, services, information, and / or access through a service provider's computer. Examples of service providers include data providers, transportation agencies, merchants, digital wallets, payment processors, etc.

[0042] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0043] A "payment token" may include an identifier for a payment account, which is an alternative to an account identifier such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 0000 1234". In some embodiments, the token may be "formatted" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may replace the PAN in initiating, authorizing, processing, or resolving payment transactions, or represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be computably recoverable from the token value. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0044] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the authorization request message is sent to the issuer of the processing network computer and / or payment card to request transaction authorization. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information related to electronic transactions 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 the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction. The "authorization request message" can also be used to request authorization to access a location, access security data, etc.

[0045] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or a processing network computer. An authorization response message may include (by way of example only) one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - the response is to wait for more information, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via a processing network computer). This code can serve as evidence of authorization.

[0046] "Authorizing entity" can be the entity requesting authorization. Examples of authorizing entities include issuers, transportation agencies, government agencies, document repositories, access administrators, etc. An authorizing entity can operate an authorizing entity computer. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. An issuer can also issue payment credentials stored on a user device, such as a cellular phone, smart card, tablet computer, or laptop computer, to consumers, or in some embodiments, to portable devices.

[0047] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers acting as a unit. In one example, a server computer could be a database server coupled to a web server.

[0048] "Processor" can include any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to achieve a desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0049] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0050] An "application" can be a computer program used for a specific purpose. Examples of applications may include transportation applications, secure data access applications, banking applications, digital wallet applications, event ticketing applications, loyalty reward applications, and so on. In some embodiments, an application may be associated with a user account (e.g., a bank account, a public transportation prepaid account, a building access account, etc.) maintained by a resource or service provider.

[0051] An "Application Identifier" (AID) can be data that identifies an application. In some embodiments, an AID can be a 16-byte value used to uniquely identify each application. Both the user device and the access device can support multiple AIDs. AIDs can also be used to identify the system environment (e.g., PSE, PPSE) supported by the access device. The user device can store a list of application identifiers, where each application identifier corresponds to a different application on the user device. One or more application AIDs from the list can be sent to the access device during the transaction initiation process for the access device to use in determining which applications both the access device and the user device support and which application the access device should ultimately select from the candidate list to initiate the transaction. In some embodiments, an AID can be formed by concatenating a 5-byte Registered Application Provider Identifier (RID), which may be a hexadecimal value, with an optional Proprietary Application Identifier Extension (PIX), which is typically a numeric value. For example, the AID of an access device supporting PPSE can be hexadecimal 325041592E5359532E4444463031 (i.e., the RID of hexadecimal 325041592E and the PIX extension of hexadecimal 5359532E4444463031). Alternatively, the AID of a credit card application can, for example, have an RID value of hexadecimal A000000003 and a PIX value of hexadecimal 1010. Therefore, concatenated, the AID can be hexadecimal A0000000031010.

[0052] A "Payment System Environment" (PSE) can be a mechanism for a user device to store and maintain a directory structure containing several applications available on the user device for executing transactions. A "Proximity Payment System Environment" (PPSE) is only applicable to contactless communication between a user device and an access device. The PPSE on the user device contains a list of all applications supported by the contactless interface, and this list is returned from the user device to the access device that issues a SELECT command to the PPSE. Both PSE and PPSE mechanisms can be used to facilitate message exchange protocols, whereby the access device can (e.g., from the returned list of applications) select an application on the user device to proceed with the transaction. Messages exchanged under both PSE and PPSE mechanisms can utilize the "Application Protocol Data Unit" (APDU) format. An APDU is a unit of data transmitted between the access device and the user device. A transaction may include multiple APDU exchanges to read data from the user device and perform necessary processing steps.

[0053] A "Cardholder Authentication Method" (CVM) is a function performed by a system (e.g., an access device or user device) to verify the identity of a cardholder or user. A CVM may include authentication mechanisms such as entering a PIN or online PIN, cardholder signature, etc. A "Consumer Device Cardholder Authentication Method" (CDCVM) is a type of CVM in which the cardholder is authenticated via their user device (e.g., a smartphone) rather than by the terminal. In addition to the mechanisms listed above (performed locally on the user device), a CDCVM may also include biometric authentication (e.g., fingerprint or facial recognition) or entering a user device PIN. In some cases, the access device may require the user to perform a CDCVM before initiating a transaction.

[0054] Details of some embodiments of this disclosure will now be described in more detail.

[0055] Figure 1 A system 100 comprising several components is illustrated according to an embodiment of the present invention. The system 100 includes a user device 102 used by a user 101, and an access device 103. For clarity, Figure 1 A specific number of components are shown. It should be understood that embodiments of this disclosure may include more than one of each component.

[0056] In some embodiments, user device 102 may include a service provider application, such as a mobile wallet application, payment application, or access application, to which access data may be pre-configured to enable user device 102 to perform access transactions. Additionally, in some embodiments, user device 102 may perform operational communication with access device 103 via contactless or contact communication. In some embodiments, user device 102 may communicate via, for example, NFC (Near Field Communication), Bluetooth, etc. TM Low-power Bluetooth TM Short-range contactless communication modes such as BLE and Wi-Fi communicate with the access device 103. In some embodiments, the contactless communication mode may also include the use of audible signals and optical signals.

[0057] Figure 2 Block diagram 200 shows a user device 102 and an access device 103 according to an embodiment.

[0058] User device 102 may also include a processor 102A (e.g., a microprocessor) for processing the functions of user device 102 and a display 102G that allows users to view information. User device 102 may also include input elements 102E (e.g., touchscreen, keyboard, touchpad, biometric sensor, etc.), a speaker 102H, and a microphone 102F, each of which is operatively coupled to processor 102A. Contactless element interface 102I, antenna 102D, memory 102C, and computer-readable medium 102B may also be operatively coupled to processor 102A.

[0059] Computer-readable medium 102B and memory 102C may reside within body 102J. Body 102J may be in the form of a plastic substrate, housing, or other structure. In some cases, memory 102C may be a security element and / or may also store information such as access data, including tokens, PANs, tickets, etc. Information in memory 102C may be transmitted by user device 102 to another device using antenna 102D or contactless element interface 102I. User device 102 may use antenna 102D for wireless data transmission (e.g., using wireless networking protocols such as IEEE (Institute of Electrical Engineers) 802.11) or mobile phone communication (e.g., 3G, 4G, and / or LTE). Antenna 102K of contactless element interface 102I may be configured to transmit and receive wireless signals at frequencies specified by different wireless protocols such as NFC (Near Field Communication), BLE (Bluetooth Low Energy), RFID (Radio Frequency Identification), or any other suitable form of short- or medium-range communication mechanism.

[0060] In some embodiments, the contactless element interface 102I is implemented as a semiconductor chip (or other data storage element) having associated wireless transmission (e.g., data transmission) elements, such as an antenna. Data or control commands transmitted via a cellular network can be applied to the contactless element interface 102I. The contactless element interface 102I is capable of transmitting and receiving data using short-range wireless communication capabilities. Therefore, the user device 102 can communicate and transmit data or control commands via a cellular network (or any other suitable wireless network, such as the Internet or other data networks) or any short-range communication mechanism.

[0061] Computer-readable medium 102B may include code executable by a processor to implement a method according to an embodiment. For example, computer-readable medium 102B may include code executable by processor 102A to implement a method comprising: receiving an available application request message from an access device, wherein the available application request message includes an access device type identifier; determining whether an association exists between the access device type identifier and one or more application identifiers of a plurality of application identifiers stored on a user device, wherein the plurality of application identifiers correspond to different applications on the user device; and sending an available application response to the access device, in part based on whether the association exists, the available application response including the one or more application identifiers of the plurality of application identifiers associated with the access device type identifier.

[0062] Computer-readable medium 102B may contain one or more service provider applications 102B-1 to 102B-n. Service provider applications 102B-1 to 102B-n may be combined with processor 102A to allow user device 102 to communicate with various service provider computers. Each application provides functionality provided by its respective service provider. Examples of service provider applications may include digital wallet applications, payment applications (e.g., mobile banking applications designed and maintained by a bank or payment processing network), merchant applications (e.g., applications enabling users to participate in loyalty reward programs), transportation applications (e.g., applications storing credit limits from prepaid cards), ticketing applications (e.g., applications that can store pre-purchased tickets for accessing events or locations), applications for accessing secure data, etc.

[0063] Access device 103 includes a processor 103A. Processor 103A is operatively coupled to a memory 103B that may include an access device type identifier 103C, a contactless element interface 103D that may include an antenna 103F, and a communication port 103E. Contactless element interface 103D is configured to communicate (send and / or receive data) with contactless element interface 102I of user device 102. In one embodiment, communication port 103E includes hardware to facilitate wireless network communication (e.g., IEEE 802.11).

[0064] In one embodiment, identifier 103C may be an Access Device Type Identifier (ADTI) that identifies one or more functions of the access device (e.g., the ability to process specific proprietary message formats, the ability to provide enhanced services beyond typical payment transactions (e.g., loyalty reward programs offered by specific merchants)) and / or the types of behavior that access device 103 allows and / or expects user device 102 to support (e.g., not prompting the user for authentication, or sending a customized list of AIDs to the access device as candidates for application selection by the access device). In some embodiments, identifier 103C may be an Application Identifier (AID), which may further include an ADTI.

[0065] Figure 3 A user device 105 in card form is shown. User device 105 includes a substrate 105A, such as a plastic substrate. A contactless element 105B for connection to a data access or data transmission device may be on or embedded in the user device substrate 105A. The contactless element 105B may include a chip and is capable of conveying and transmitting data using Near Field Communication (NFC) technology or other short-range communication technologies. User device 105 may also include a memory 105C that may store user information such as account number, expiration date, and username. Such information may also be printed or embossed on the substrate 105A. A magnetic stripe 105D may also be present on the substrate 105A.

[0066] Figure 4 A system diagram and method according to embodiments of the present disclosure are shown. System 400 includes an access device 403 that can be associated with a resource provider. The system also includes a user device 402 that can be associated with a user. The user can use the user device 403 to interact with the access device 403 to obtain access to resources.

[0067] In some embodiments, a user can use user device 402 to make a purchase at a merchant access device 403. During the purchase transaction, user device 402 can provide payment credentials to access device 403, which can initiate a payment authorization process.

[0068] User device 402 may store or has access to certain types of user information. For example, user device 402 may store the user's payment credentials, such as PAN (primary account), payment token, name, address, CVV, expiry date, and any other suitable information. Such data may be securely stored via hardware (e.g., a secure element) or software.

[0069] User device 402 may also include a digital wallet application, which may include information about one or more user accounts. Accounts may include a variety of possible types, including payment accounts such as credit or debit card accounts, and non-payment accounts such as public transportation accounts associated with prepaid cards, building access accounts, loyalty reward program accounts linked to specific merchants, accounts maintaining pre-purchased ticket information that can be used to obtain access to events, etc. Users can add accounts, set default accounts, prepare user device 402 for transactions, and perform other transaction-related functions via the digital wallet application. In some embodiments, different accounts at the digital wallet application may be associated with different applications, and each application may be associated with an application identifier (AID), as previously described.

[0070] User device 402 may also store information indicating whether there is an association between one or more applications on user device 402 and one or more access device types, wherein each access device type may correspond to an Access Device Type Identifier (ADTI). This association information may be stored in the memory of user device 402 (e.g., computer-readable medium 102B), which may contain association information for multiple applications on user device 402. In some embodiments, the association information may be stored directly within a specific application on user device 402.

[0071] exist Figure 7 The diagram illustrates an example of the relationship (i.e., association) between applications on user device 402 and access device types. For example, if user device 402 is a mobile phone, applications 702, 704, 706, 708, 710, and 712 may be applications stored on computer-readable medium 102B of user device 402 and associated with a digital wallet application. Each application 702, 704, 706, 708, 710, and 712 may have an associated AID. Terminal type identifiers 714, 716, and 718 may each correspond to a different access device type. Each identifier 714, 716, and 718 may be a unique ADTI value. The ADTI value may be within the data field of the AID associated with the access device. In contrast, a generic terminal identifier 720 may correspond to an access device that is not associated with any ADTI value and therefore cannot be specifically identified by the user device as a particular terminal type. Figure 7 As shown, multiple applications can be associated with a single ADTI.

[0072] exist Figure 7 In this configuration, the first authorized entity application 702, the second authorized entity application 704, and the third authorized entity application 706 can each correspond to different credit card payment applications. All three credit card payment applications can be associated with the universal terminal identifier 720 by default. That is, the access device with the universal terminal identifier 720 may not be associated with any specific ADTI or terminal type and may be configured only to process standard payment transactions. For example, a user device that receives the universal terminal identifier 720 from the access device can return a list of AIDs for all three payment applications 702, 704, and 706 to the access device.

[0073] In contrast, the access device with terminal type identifier 718 can be a 'loyalty' ADTI. Both credit card payment application 704 and loyalty application 710 can be associated with a 'loyalty' ADTI. Therefore, after receiving a message with terminal type identifier 718 (i.e., 'loyalty' ADTI) from the access device, the user device can selectively send only the associated AID of applications 704 and 710 to the access device for further processing.

[0074] The access device with terminal type identifier 716 can be an 'Event' ADTI. The venue access application 712 can be, for example, a cinema application that maintains pre-purchased movie tickets for future use. After receiving a message with terminal type identifier 716 (i.e., 'Event' ADTI) from the access device, the user device can selectively send only the associated AID of the venue access application 712 to the access device for further processing.

[0075] The access device with terminal type identifier 714 can be a 'Transportation' ADTI. Both credit card payment application 706 and transportation application 708 can be associated with a 'Transportation' ADTI. Credit card payment application 706 may correspond to a corporate credit card account, which may be provided to the user by the user's employer for shopping or use on public transportation systems. After receiving a message with terminal type identifier 714 (i.e., 'Transportation' ADTI) from the access device, user device 402 may selectively send only the associated AIDs of applications 706 and 708 to the access device for further processing.

[0076] Return to Figure 4 A method according to an embodiment may also be described. Although the following description includes a description of payment processing, it should be understood that the method can be used in other situations (e.g., accessing secure locations or secure data).

[0077] In one embodiment, a user can select one or more goods and / or services to purchase from a merchant and then initiate a payment transaction. The user can choose to make the payment via user device 402. In some embodiments, the user can activate a digital wallet application, select a payment account, and initiate the payment function on the digital wallet application. In step S402, the user can keep user device 402 in the vicinity of access device 403, so that the two devices can detect each other.

[0078] In some embodiments, a contactless transaction can then be performed by exchanging messages (e.g., Application Protocol Data Unit (APDU) messages) between user device 402 and access device 403. Messages may be in the form of APDU commands sent from access device 403 to user device 402 and APDU responses sent from user device 402 to access device 403. As described in this method, NFC will be used for communication. However, embodiments also allow the use of other communication means (e.g., BLE, RFID).

[0079] In step S404, user device 402 may determine that it should delay prompting the user to provide authentication data until the user device receives a message from access device 403 indicating the transaction type supported by access device 403. Later (e.g., step S408), user device 402 may determine whether to prompt the user to provide authentication data. By delaying the prompting for authentication data until the type of access device 403 interacting with the user device 402 is determined, user device 402 can perform transactions more efficiently (i.e., only prompting for authentication data when it is necessary to complete a specific type of transaction).

[0080] In step S406, access device 403 may send an Available Application Request message to user device 402 to request information about which applications (e.g., a list of AIDs) are available on user device 402's digital wallet application. The Available Application Request message contains the access device 403's ADTI. In some embodiments, the Available Application Request message may be an Enhanced Available Application Request message in the form of an "enhanced PPSE" (ePPSE) command.

[0081] In some embodiments, ADTI can be sent by access device 403 as a value in a data field within a select command message. Table 1 below shows example codes and values ​​that can be included in a select command message. Table 2 below further provides examples of ADTI values ​​for data fields within a select command message, which, if included in the select command message, would cause the message to be presented as a select ePPSE command (enhanced PPSE command). ADTI values ​​can be inserted into existing data fields, or data fields can be added for ADTI values.

[0082] Table 1: Selection Command Messages

[0083]

[0084] Table 2: Example ADTI values ​​(included in the data fields of the select ePPSE command message)

[0085]

[0086]

[0087] As shown in Table 2, an Enhanced Available Application Request message in the form of an ePPSE selection command may include a data field containing an AID, which is formed by concatenating RID and PIX values ​​as described above. To indicate the payment environment supported by the access device, the AID may include a payment environment identifier (e.g., 325041592E5359532E4444463031 (indicating PPSE support) or 315041592E5359532E4444463031 (indicating PSE support)) within the RID value. The ADTI for the ePPSE selection command may be a value contained within the PIX of the AID. Examples of ADTI values ​​include, but are not limited to, the string values ​​shown in Table 2. Therefore, for example, the AID of a public transport enhanced access device supporting PPSE can be a concatenation of RID (32 50 41 59 2E) and PIX (54 52 41 4E 53 49 54), which can be further represented as 32 50 4159 2E 54 52 41 4E 53 49 54 and sent to the user device.

[0088] In step S408, user device 402 may determine, at least in part, whether user interaction on the user device is necessary based on the ADTI received from access device 403. For example, user device 402 may determine whether to prompt the user for authentication data. For example, in an embodiment where the ADTI value is 'loyalty', user device 402 may determine from the ADTI that access device 403 supports payment transactions and has additional functionality to process loyalty reward information associated with the user's payment account. Therefore, user device 402 may decide to prompt the user for authentication data, then continue the transaction and respond to access device 403 with an Enhanced Available Application Response message.

[0089] In step S410, user device 402 may determine whether there is an association between the ADTI received from access device 403 and one or more AIDs among a plurality of AIDs stored on user device 402. The plurality of AIDs correspond to different applications on user device 402. User device 402 may access, for example, an association table maintained by a digital wallet application on user device 402 (e.g., similar to...). Figure 7 This determination is performed using the associations described in the document.

[0090] In step S412, user device 402 may send an enhanced available application response to access device 403, in part based on the existence of the association determined in step S410, the enhanced available application response including one or more AIDs associated with ADTI among the plurality of AIDs. In some embodiments, the enhanced available application response message may be in the form of an enhanced PPSE (ePPSE) response.

[0091] As mentioned above, the same data fields can be used as the selection PPSE response message, and may include File Control Information (FCI). This may include, but is not limited to, Application Definition File (ADF) name, application tag, application priority indicator, language preference, kernel identifier indicating application kernel preference, and / or additional information associated with a specific ADF. Additionally, each ADF name may correspond to an AID of an application on user device 402. Therefore, user device 402 may return a list of applications with one or more directory entries, each directory entry corresponding to an associated AID on user device 402, and including one or more data fields listed above. For example, if access device 403 has an ADTI value 718 for 'loyalty', the user device may decide to send a list of applications containing associated AIDs (e.g., loyalty application 710 and second authorized entity application 704). A portion of the data fields listed above can be represented in list form as follows:

[0092] Directory entry ('61){

[0093] ADF name = 'A0 00 00 00 06 01'

[0094] Application tag = "My Best Buy Rewards"

[0095] Application priority indicator = '0002'

[0096] …

[0097] }

[0098] Directory entry ('61')

[0099] ADF name = 'A0 00 00 00 03 90 10'

[0100] Application tag = "My Best Buy Visa"

[0101] Application priority indicator = '0001'

[0102] …

[0103] }

[0104] In the example list above, each directory entry includes an ADF name (represented as an AID in hexadecimal form, i.e., RID||PIX)), a mnemonic as an application tag, and an application priority indicator with a numerical value. In some embodiments, a value of 1 may correspond to the highest priority application. Thus, in this example, when transacting with access device 403 having a 'Loyalty' ADTI value, the 'My Best Buy Visa' application may have a higher priority than the 'My Best Buy Rewards' application. Enhanced Available Application responses may also include other data, such as data determined by the FCI issuer or any other relevant information.

[0105] In step S414, access device 403 may determine mutually supporting applications based on the list of received applications associated with the AID received in step S412. It should be noted that access device 403 may utilize any suitable mechanism, including but not limited to an application priority indicator received from user device 402, for selecting an application from the application list (e.g., also considering access device 403's preferred application). Access device 403 may then send an "application selection" command, including the selected AID, to user device 402.

[0106] exist Figure 4 In the embodiments described in the subsequent steps (i.e., S416 to S424), a specific application selected by access device 403 can be used to conduct payment transactions using APDU formatted messages. For example, in the case where access device 403 is a 'loyalty' ADTI value, the subsequent APDU messages in S416 to S424 can not only be used to conduct standard payment transactions, but can also convey additional information about the user's loyalty reward account, which can be updated based on this specific transaction. However, as described below... Figure 5 As discussed in the text, in other embodiments, access device 403 may select a proprietary application (i.e., step S514), in which case subsequent messages exchanged may be exchanged according to a proprietary protocol.

[0107] In step S416, after receiving the application selection message from step S414, user device 402 may send a terminal transaction data request to access device 403 to request transaction data that may be needed to complete the provisioning process of the selected application associated with the selected AID. In some embodiments, the terminal transaction data request may be in the form of a "selected AID response" and may include Application Identifier (AID) File Control Information (FCI) with the selected AID as the proprietary filename. The terminal transaction data request may include a list of transaction data identifiers to request appropriate data from access device 403. The list of transaction data identifiers may be in the form of a Processing Option Data Object List (PDOL).

[0108] The transaction data requested by user device 402 for a transaction may include an entity identifier associated with access device 403, Terminal Processing Option (TPO), amount, and other information. Additionally, the transaction data may include one or more dynamic data elements (e.g., a random number). In other embodiments, the transaction information may be provided as part of the application selection message at step S414.

[0109] In step S418, after receiving a terminal transaction data request from user device 402, access device 403 may send the terminal transaction data requested by user device 402 to user device 402. In some embodiments, the terminal transaction data may be sent in the form of a Get Processing Option (GPO) command and may include the terminal transaction data requested in the Processing Option Data Object List (PDOL). The terminal transaction data (e.g., a Transaction Processing Option (TPO)) may include a TPO indicator indicating which transaction data types are supported by access device 403. In some embodiments, to facilitate the access data provisioning process by utilizing APDU commands, access device 403 may send a zero-dollar value as part of the terminal transaction data to user device 402. It should be understood that in some embodiments, the value may be any amount.

[0110] In step S420, after the user device 402 receives the terminal transaction data, the user device 402 can obtain relevant credentials (e.g., card credentials) and can send a set of transaction processing information to the access device 403. In some embodiments, the transaction processing information can be sent in the form of a "Give Processing Option" (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used by the access device 403 as file addresses to read account data stored on the user device 403, and an application exchange profile (AIP) that can be used to indicate the capabilities of the payment application.

[0111] Transaction processing information may include any transaction credentials, including a PIN generated using the transaction information, Track-2 equivalent data (e.g., PAN, expiry date), and / or additional data. For example, the transaction information may be used to generate a PIN, which may include dynamic data elements (e.g., random numbers), a User Device 402 identifier (e.g., PAN), and optionally other information such as a session identifier, a value such as a zero dollar amount, and a transaction counter. Transaction processing information may also include Issuer Application Data (IAD), Form Factor Indicator (FFI), Card Transaction Qualifier (CTQ), Password Information Data (CID), and / or Application PAN Serial Number (PAN). In some embodiments, the Issuer Application Data (IAD) may include a length indicator indicating the length of the IAD, a Password Version Number (CVN) indicating the version of the transaction PIN, a Derived Key Indicator (DKI) that can be used to identify the master key (e.g., a master key associated with the issuer), and / or Card Verification Result (CVR).

[0112] In step S422, after receiving the transaction processing information, the access device 403 may send an account data request to the user device 402 to read additional account data that can be stored on the user device 402. In some embodiments, the account data request may be in the form of a "read record" command and may include an application file locator (AFL) indicating the location of the account data that the access device 403 is attempting to read. The AFL included in the account data request may correspond to the AFL in the transaction processing information provided from the user device 402 to the access device 403.

[0113] In step S424, in response to receiving an account data request from access device 403, user device 402 may send account data stored at a location indicated by the AFL to access device 402. In some embodiments, the account data may be sent in the form of a "read record" response. The account data may include, for example, application use controls indicating restrictions on the use and services allowed by the issuer for the application, the cardholder's name, customer-specific data, the issuer's country code, and / or other account-related data accessible at the AFL location and stored in user device 402. In some embodiments, the account data may include user data regarding user participation in a loyalty rewards program, which access device 403 may be configured to further process (e.g., add points to the customer's loyalty rewards account). The account data, transaction processing information, and other data received by access device 403 in the previous steps may then be used by access device 403 to complete a payment transaction.

[0114] Figure 5A system diagram and method according to embodiments of the present disclosure are shown. System 500 may be similar to the contents of system 400, including access device 503 and user device 502. However, Figure 5 The method depicted illustrates a transaction between a proprietary application (e.g., for non-payment transactions) on user device 502 and an access device 503 configured to receive and process proprietary messages (e.g., in non-APDU format) from the proprietary application. Access device 503 can then be configured to perform proprietary actions based on the proprietary message exchange. This is described below and is also... Figure 8 Examples of such proprietary trading systems are depicted in the text.

[0115] User device 502 may be a mobile phone. Applications (e.g., digital wallet applications) may also be stored on user device 502. These applications may be associated with applications stored on user device 502, each application having a corresponding AID. One or more applications on user device 502 may each be associated with a specific type of access device.

[0116] Access device 503 may include a device reader and a rotating gate in a public transport environment that requires a user to touch or hold a user device 502 to access device 503 to obtain public transport services.

[0117] In step S504, user device 502 may decide to delay prompting the user to provide authentication data until the user device receives a message from access device 503 indicating the transaction type supported by access device 503.

[0118] In step S506, similar to Figure 4 In step S406, access device 503 can initiate a transaction by sending an Enhanced Available Application Request message (e.g., a Select ePPSE command) to user device 402 to request information about which applications (e.g., a list of AIDs) are available on the applications of user device 402. The Select ePPSE command may have an ADTI value of 'Transport'.

[0119] In step S508, user device 502 may determine, at least in part, whether user interaction on the user device is necessary (e.g., whether to prompt the user for authentication data) based on the ADTI (e.g., 'Transportation') received from access device 503. User device 502 may determine from the ADTI that access device 503 supports public transport transactions. Therefore, user device 502 may determine that access device 503 will not require authentication to continue. Therefore, user device 402 will not prompt the user for authentication data.

[0120] In step S510, user device 502 may determine whether there is an association between the ADTI received from access device 503 and one or more AIDs stored on user device 402. In one embodiment, using Figure 7 To clarify, user device 502 can return the AIDs of both the third-authorized entity application 706 and the transportation application 708 to access device 503, since both applications are associated with the 'transportation' ADTI value. In some embodiments, an application priority indicator may also be included within the enhanced available application response, which can be used by access device 503 to select the appropriate application that is supported and / or preferred by both access device 503 and user device 502.

[0121] In step S512, similar to Figure 4 In step S412, user device 502 may send an enhanced available application response to access device 503, in part based on whether the association determined in step S510 exists. The enhanced available application response includes one or more AIDs associated with ADTI.

[0122] In step S514, the access device 503 may determine mutually supported applications based on the list of receiving applications associated with the AID received in step S512. Figure 5 In this embodiment, access device 503 may select a proprietary application (e.g., one capable of processing messages using a non-APDU format). It should be understood that while the messages exchanged to process a transaction may themselves have a proprietary format, the message exchange process (S502-S514) used to facilitate the determination of the appropriate application selected on the user device may utilize APDU-formatted messages. It should also be noted that access device 503 may utilize any suitable mechanism, including but not limited to application priority indicators received from user device 502, for selecting an application from an application list (e.g., the preferred application of access device 503 is also considered). For example, access device 503 may determine that the application priority indicator for transport application 708 is ranked higher than that for third-authorized entity application 706. Therefore, access device 503 may select the transport application. Access device 503 may then send an "application selection" command, including the selected AID, to user device 502.

[0123] In step S516, user device 502 and access device 503 may continue to exchange proprietary messages to conduct transactions. This exchange may include messages such as instructing a proprietary application to deduct a certain amount from a prepaid transportation card, or prompting the user that the transportation card needs to be recharged.

[0124] Figure 6A schematic system and method according to an embodiment of this disclosure are illustrated. System 600 may include user device 602 and access device 603. In this example, access device 603 does not contain a terminal type identifier or ADTI. Additionally, user device 602 may have applications stored on user device 602. These applications may be associated with applications stored on user device 602, each application having a corresponding AID. However, in this example, user device 602 is not configured with features to analyze or process ADTI values ​​within Enhanced Available Application Request messages received from access device 603. For example, the digital wallet application on user device 602 may be an earlier version that cannot process ADTI values.

[0125] In step S602, the user can keep the user device 602 near the access device 603 so that the two devices can detect each other.

[0126] In step S604, user device 602 may prompt the user to provide authentication data. In this embodiment, user device 602 neither delays the prompt until it receives an available application request message from access device 603, nor makes a later determination on whether to prompt for authentication data based on the ADTI value received from access device 603. Alternatively, user device may consistently prompt the user to provide authentication data (CDCVM).

[0127] In step S606, access device 603 may generate a first available application request message (i.e., an enhanced available application request message) that may be an ePPSE command, and send the message to user device 602.

[0128] In step S608, user device 602 may determine that it cannot process the first available application request message (i.e., because the user device cannot interpret the ADTI value within the enhanced available application request message). Therefore, user device 602 may return an error message (e.g., "File not found" or other suitable format) to access device 603.

[0129] In step S610, after receiving the "file not found" error message from step S608, the access device 603 may send a second available application request message (i.e., a non-enhanced available application request message) to the user device 602, which may be in the form of a PPSE / PSE command. In some embodiments, the additional time elapsed between the first and second available application request messages (i.e., the additional time added to the transaction due to the error message) may be up to 20 milliseconds (ms).

[0130] In step S612, user device 602 may send an available application response (i.e., a non-enhanced available application response determined independently of the ADTI value previously received from access device 603) to access device 603. The available application response (e.g., a PPSE selection response) may include a list of AIDs stored on the user device. The available application response may also include... Figure 4 Some or all of the data fields described in step S412.

[0131] In step S614, access device 603 may determine mutually supporting applications based on the list of received applications associated with the AID received in step S612. It should be noted that access device 603 may utilize any suitable mechanism, including but not limited to an application priority indicator received from user device 602, for selecting an application from the application list (e.g., also considering access device 603's preferred application). Access device 603 may then send an "application selection" command, including the selected AID, to user device 602.

[0132] Figure 6 The remaining steps (i.e., S616 to S624) can be performed between the access device 603 and the user device 602 for standard payment transactions (i.e., without using ADTI to provide additional functionality (e.g., adding points to a customer's loyalty reward account based on a payment transaction)). Thus, the remaining steps S616 to S624 can be substantially similar to... Figure 4 Steps S416 to S424 for processing standard payment transactions. Figure 4 The description of the steps in that section is incorporated here.

[0133] After the access device has received the appropriate data from the user device as described above, different types of transactions or interactions can be performed. Figure 8 and 9 The text discusses two examples of different types of transactions.

[0134] Figure 8 A block diagram of a building access system and a user device 102 operated by user 101 is shown. User device 102 can interact with access device 810 and obtain access data required for entering buildings, events, etc. Access device 810 can locally verify the received access data, or it can communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer can verify the authenticity of the access data and can send a signal indicating this back to access device 810. Access device 810 can then proceed to allow user 101 to enter building 820.

[0135] Figure 9A block diagram of a transaction processing system is shown. User 101 operates a user device 102 pre-configured with access data (e.g., a token). User 101 can use user device 102 to pay for goods or services from resource providers, such as merchants. Merchants can operate resource provider computers 920 and / or access devices 910. Merchants can communicate with authorized entity computers 950 operated by the issuer via a transmission computer 930 operated by the acquirer and a processing network 940, such as a payment processing network.

[0136] A payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM For example, VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, this includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base II system that performs clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0137] A typical payment transaction flow using user device 102 interacting with access device 910 can be described as follows. User 101 presents their user device 102 to access device 910 to pay for goods or services. User device 102 and access device 910 interact such that access data from user device 102 (e.g., PAN, payment token, verification value, expiration date, etc.) is received by access device 910 (e.g., via a contact or contactless interface). Resource provider computer 920 can then receive this information from access device 910 via an external communication interface. Resource provider computer 920 can then generate an authorization request message including information received from access device 910 (i.e., information corresponding to user device 103) and additional transaction information (e.g., transaction amount, merchant-specific information, etc.) and send this information electronically to transmission computer 930. Transmission computer 930 can then receive, process, and forward the authorization request message to processing network 940 for authorization.

[0138] Generally, prior to a credit or debit card transaction, the processing network 940 has established an agreement with each issuer regarding the authorization method for the transaction. In some cases, such as when the transaction amount is below a threshold, the processing network 940 can be configured to authorize the transaction based on its information about the user account without generating an authorization request message and sending it to the authorization entity computer 950. In other cases, such as when the transaction amount is above a threshold, the processing network 940 may receive the authorization request message, identify the issuer associated with the user device 102, and forward the authorization request message for the transaction to the authorization entity computer 950 for verification and authorization. Once the transaction is authorized, the authorization entity computer 950 can generate an authorization response message (which may include an authorization code indicating that the transaction is approved or rejected) and send this electronic message to the processing network 940 via the external communication interface of the authorization entity computer. The processing network 940 can then forward the authorization response message to the transmission computer 930, which can then subsequently send an electronic message including authorization instructions to the resource provider computer 920, and then to the access device 910.

[0139] If the access data is in the form of a token, the processing network 940 can exchange the token for a real credential (e.g., a PAN). Any authorization request message can then be modified to include the real credential, and the authorization request message can be forwarded to the authorizing entity computer 950 for verification. The authorizing entity computer 950 can generate an authorization response message with approval or rejection. The authorization response message can be sent to the processing network 940, and the processing network 940 can replace the credential with the token. The processing network 940 can then send the authorization response message back to the access device 910.

[0140] At the end of the day or at some other suitable time interval, the clearing and settlement process between the resource computer 920, the transmission computer 930, the processing network 940 and the authorized entity computer 950 can be performed on the transaction.

[0141] It should be understood that any embodiment of this disclosure may be implemented using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic, wherein the general-purpose programmable processor is modular or integrated. As used herein, the processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked together. Based on the disclosure and teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing embodiments of this disclosure using hardware and combinations of hardware and software.

[0142] Any software component or function described in this application may be implemented as processor-executable software code using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing 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), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0143] Such programs can also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of this disclosure can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist 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 a user with any of the results mentioned herein.

[0144] The foregoing description is illustrative and not restrictive. Many variations of this disclosure will become apparent to those skilled in the art upon reading it. Therefore, the scope of this disclosure should not be determined by reference to the foregoing description, but rather by reference to the pending claims and their full scope or equivalents.

[0145] Without departing from the scope of this disclosure, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0146] Unless explicitly indicated otherwise, the use of “a” or “the” is intended to mean “one or more”.

[0147] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method for conducting a transaction using an access device type identifier, the method comprising: The user device receives an available application request message from the access device before receiving the application selection message. The available application request message includes a data field, which includes a first application identifier. The first application identifier includes: (1) a first registered application provider identifier, which includes a proximity payment system environment identifier. The first registered application provider identifier is concatenated with (2) a first proprietary application identifier extension, which includes an access device type identifier. The user device determines whether there is a relationship between the access device type identifier and one or more application identifiers among a plurality of application identifiers stored on the user device, wherein the plurality of application identifiers correspond to different applications on the user device. The user device selects at least one application identifier from the plurality of application identifiers based on whether the connection exists; The user device sends an available application response to the access device, the available application response including at least one application identifier, wherein the at least one application identifier is used to generate the application selection message, the application selection message indicating the selection of a specific application among different applications on the user device; and The user device sends one or more messages to the access device that are operable to complete the transaction involving the specific application on the user device. The available application request message and the available application response are respectively sent using a near-field communication protocol. The available application request message and the available application response are Application Protocol Data Unit (APDU) messages, and The format of the available application request message is a command APDU format, and the access device type identifier is received as a data field of the command APDU format.

2. The method according to claim 1, wherein the access device type identifier identifies: (1) the function of the access device or (2) the type of behavior that the access device allows or expects the user device to support.

3. The method of claim 1, wherein the determination of whether the relationship exists between the access device type identifier and one or more application identifiers among the plurality of application identifiers stored on the user device is performed in part based on characteristics of the user device.

4. The method of claim 3, wherein the user device is a mobile phone and wherein the access device is a public transport terminal.

5. The method of claim 1, further comprising: It is not necessary for the user device to determine user interaction on the user device based in part on the access device type identifier.

6. A user equipment, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: Before receiving the application selection message, receive an available application request message from the access device, wherein the available application request message includes a data field, the data field including a first application identifier, the first application identifier including: (1) a first registered application provider identifier, the first registered application provider identifier including a proximity payment system environment identifier, the first registered application provider identifier being concatenated with (2) a first proprietary application identifier extension, the first proprietary application identifier extension including an access device type identifier. Determine whether there is a relationship between the access device type identifier and one or more application identifiers among a plurality of application identifiers stored on the user device, wherein the plurality of application identifiers correspond to different applications on the user device; At least one application identifier from the plurality of application identifiers is selected based on whether the connection exists; Sending an available application response to the access device, the available application response including the at least one application identifier, wherein the at least one application identifier is used to generate the application selection message, the application selection message indicating the selection of a specific application among different applications on the user device; and Send one or more messages to the access device that can operate to complete a transaction involving the specific application on the user device. The available application request message and the available application response are respectively sent using a near-field communication protocol. The available application request message and the available application response are Application Protocol Data Unit (APDU) messages, and The format of the available application request message is a command APDU format, and the access device type identifier is received in the data field of the command APDU format.

7. The user device according to claim 6, wherein the method further comprises: The access device is detected to be near the user device.

8. The user device of claim 7, wherein the user device is a mobile phone and wherein the access device is a public transport terminal.

9. The user device of claim 6, wherein the determination of whether the association exists between the access device type identifier and one or more application identifiers among the plurality of application identifiers stored on the user device is performed in part based on characteristics of the user device.

10. The user device of claim 9, wherein the feature of the user device is an application stored on the user device, the application being configured to analyze the access device type identifier of the available application request message.

11. A method for conducting a transaction using an access device type identifier, the method comprising: Before sending an application selection message to a user device, the access device generates an available application request message, wherein the available application request message includes a data field, the data field including a first application identifier, the first application identifier including: (1) a first registered application provider identifier, the first registered application provider identifier including a proximity payment system environment identifier, the first registered application provider identifier being concatenated with (2) a first proprietary application identifier extension, the first proprietary application identifier extension including an access device type identifier; The access device sends the available application request message to the user device; The access device receives an available application response from the user device, the available application response including one or more application identifiers from a plurality of application identifiers stored on the user device, each of the plurality of application identifiers being selected by the user device based on a contact with the access device type identifier, and wherein the plurality of application identifiers correspond to different applications on the user device. The access device sends an application selection message to the user device, the application selection message indicating the selection of a specific application among different applications on the user device; and The access device sends one or more messages to the user device that can operate to complete a transaction involving the specific application on the user device. The available application request message and the available application response are respectively sent using a near-field communication protocol. The available application request message and the available application response are Application Protocol Data Unit (APDU) messages, and The format of the available application request message is a command APDU format, and the access device type identifier is received in the data field of the command APDU format.

12. The method of claim 11, wherein the access device type identifier is a string value from a set of predefined string values.

13. The method of claim 11, further comprising: The access device selects an application identifier from one or more application identifiers received from the user device. as well as The access device generates an application selection message that includes the selected application identifier.

14. The method of claim 13, wherein selection is partly based on one or more application priority indicators received from the user device in the available application response, the one or more application priority indicators corresponding to different application identifiers among the one or more application identifiers.

15. The method of claim 11, further comprising: The access device receives an error message from the user device, the error message indicating that the user device is unable to process the available application request message, wherein the available application request message is an enhanced available application request message; The access device generates a second available application request message, wherein the second available application request message is a non-enhanced available application request message; as well as The access device sends the second available application request message to the user device.

16. An access device, comprising: A processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to carry out the method according to any one of claims 11-15.

Images