WO2019166868A1

WO2019166868A1 - Method and system for providing attribute data with token

Info

Publication number: WO2019166868A1
Application number: PCT/IB2018/056202
Authority: WO
Inventors: Simon Law; Paul TAIT
Original assignee: Visa International Service Association
Priority date: 2018-02-27
Filing date: 2018-08-16
Publication date: 2019-09-06

Abstract

A method is disclosed. A server computer may receive an authorization request message comprising a token from a computer. The server computer may determine a real credential associated with the token. The server computer may transmit the authorization request message comprising the real credential to an authorization computer. The server computer may receive an authorization response message comprising the real credential from the authorization computer. The server computer may determine an attribute associated with the real credential. The server computer may transmit the authorization response message comprising the token and the attribute to the computer.

Description

METHOD AND SYSTEM FOR PROVIDING ATTRIBUTE DATA WITH TOKEN

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a PCT application which claims the benefit of the filing date of U.S. Provisional Application No. 62/635,719, filed on February 27, 2018, which is herein incorporated by reference in its entirety for all purposes.

BACKGROUND

[0002] User devices can utilize access data to obtain access to a resource or a location. For example, a user device may include data which is passed to an access device to allow the user of the user device to access a room in a building. In another example, the user device may have access data such as account data which may allow the user of the user device to access an account to obtain a good or service.

[0003] In many cases, an entity may provision the user device with the access data. For example, a building operator system may provision a user device with data that allows a user of the user device to access a building. In another example, a bank may provision the user device with access data that allows the user of the user device to access an account at the bank. In this particular situation, the entity can verify that the user of the user device is in fact an authentic user.

[0004] However, in some cases, user devices that are not capable of receiving long range transmissions and/or user devices are pre-provisioned with access data. Some examples of user devices can include rings or wristbands that are pre- provisioned with access data, and are useable after they are purchased. In such cases, additional data such as attributes associated with a user, account, or identifier cannot be provisioned on to such user devices. This can limit the functionality of such user devices. In addition, even if access data can be loaded into user devices, any access data that constitutes sensitive information may be subjected to hacking or malware when present on the user device. It would be desirable to provide for a user device and system that has improved data security over conventional systems as well as enhanced functionality.

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

[0006] Embodiments of the invention are include methods as well as systems and methods that can provide greater functionality and security to user devices that have been pre-provisioned with access data.

[0007] One embodiment of the invention is directed to a method comprising: receiving, by a server computer, an authorization request message comprising a token from a computer; determining, by the server computer, a real credential associated with the token; transmitting, by the server computer, the authorization request message comprising the real credential to an authorization computer; receiving, by the server computer, an authorization response message comprising the real credential from the authorization computer; determining, by the server computer, an attribute associated with the real credential; and transmitting, by the server computer, the authorization response message comprising the token and the attribute to the computer.

[0008] Another embodiment of the invention is directed to a server computer programmed to perform the above-noted method. [0009] Another embodiment of the invention is directed to a method comprising: receiving, by a computer, a token stored in a user device in a transaction, the user device being pre-provisioned with the token, wherein a real credential is linked to the token after the token is stored in the user device; obtaining, by the computer, one or more attributes associated with the real credential; processing, by the computer, an authorization request message comprising the token; transmitting, by the computer, the authorization request message comprising the token to a server computer to cause the server computer to determine a real credential instead of the token, and complete authorization, and transmit the modified authorization request message to an authorizing computer; receiving, by the computer, an authorization response message from the server computer comprising the token; and performing by the computer, further processing of the transaction using the token and the one or more attributes.

The computer can be a resource provider computer or a transport computer. [0010] Another embodiment of the invention is directed to a computer

programmed to perform the above-noted method.

[0011] Further details regarding embodiments of the invention can be found in the Detailed Description and the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS [0012] FIG. 1 shows a block diagram of a system along with a process flow according to an embodiment of the invention.

[0013] FIG. 2 shows a block diagram of a system along with a process flow according to another embodiment of the invention.

[0014] FIG. 3 shows a block diagram of an exemplary user device. [0015] FIG. 4 shows a block diagram of a server computer according to an embodiment of the invention.

[0016] FIG. 5 show a block diagram of a system along with a process flow according to yet another embodiment of the invention.

DETAILED DESCRIPTION [0017] Prior to discussing embodiments of the invention, some terms can be described in further detail.

[0018] A“user device” may be any suitable device that may be operated by a user. A user device may not have long range communication capabilities. Examples of user devices may include wearable devices (e.g., watches, rings, etc.), cards (e.g., credit cards), PDAs, personal music players, hand-held specialized readers, vehicles (e.g., cars), etc. User devices may also include portable devices, communication devices, and mobile devices. A user device may comprise any suitable hardware and software for performing such functions, and may include multiple devices or

components. A user device may be pre-provisioned with token. For example, a user device may be manufactured with a memory containing a token.

[0019] “Provisioning” may include a process of providing data for use. For example, provisioning may include providing, delivering, or enabling a token on a device. Provisioning may be completed by any entity within or external to the transaction system. For example, in some embodiments, tokens may be provisioned by an issuer or a transaction processing network onto a mobile device. The provisioned tokens may have corresponding token data stored and maintained in a token vault or token registry. In some embodiments, a token vault or token registry may generate a token that may then be provisioned or delivered to a device. “Pre-provisioning” may include a process of providing data on a device before the device is purchased, used, and/or obtained. For example, pre-provisioning may include providing, delivering, or enabling a token on a device when the device is manufactured.

[0020] "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, payment token, expiration date, verification values (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data may be data that can be used to activate account data. In some embodiments, access data could include data that can be used to access a location. Such information may be ticket information for an event, data to access a building, transit ticket information, etc. In other embodiments, access data could include data that can be used to obtain a resource.

[0021] An“access device” may be any suitable device for obtaining access to a resource. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a payment device and/or a user device.

[0022] 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. [0023] A“real credential” may comprise any evidence of authority, rights, or entitlement to privileges. For example, access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file. In another example, payment credentials may include any suitable information associated with and/or identifying an account (e.g., a payment account and/or a payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include an“account identifier” such as a PAN (primary account number or“account number”), a token, a subtoken, a gift card number or code, a prepaid card number or code, a user name, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, etc. An example of a PAN is a 16-digit number, such as“4147 0900 0000 1234”. In some embodiments, real credentials may be considered sensitive information.

[0024] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or“account number”), user name, expiration date, and verification values such as CVV, dCVV, CVV2, dCVV2, and CVC3 values. [0025] A“token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0026] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a payment token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token“4900 0000 0000 0001” may be used in place of a PAN“4147 0900 0000 1234.” In some

embodiments, a payment token may be“format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a payment token may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. 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.

[0027] “Tokenization” is a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g. a token) that may be associated with the payment account identifier. Further, tokenization may be applied to any other information that may be replaced with a substitute value (i.e. , token). Tokenization enhances transaction efficiency and security.

[0028] A "token issuer," token provider” or“token service system” can include a system that services tokens. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may include or be in communication with a token vault where the generated tokens are stored. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PANs. In some embodiments, a token service system may include a tokenization computer alone, or in combination with other computers such as a transaction processing network computer. Various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to embodiments of the present invention.

[0029] A“user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or user devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments.

[0030] A“resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc. A resource provider may operate a resource provider computer.

[0031] A“merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

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

[0033] An“authorizing entity” may be an entity that authorizes a request.

Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorization computer. [0034] 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.

[0035] 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 CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or“account number”), a payment token, a user name, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction 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. In some embodiments, the authorization request message may comprise access data. In other embodiments, the authorization request message may comprise a real credential.

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

[0037] A“processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).

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

[0039] 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. [0040] An“attribute” can be a characteristic of something. Attributes can include data, functions, or limitations or processes that might be associated with something.

For example, an attribute of a payment account may include an issuer country code, a US acceptance type, a PIN at point-of-sale indicator, an authorization only indicator, a brand indicator, an account funding source subtype (e.g., a credit, debit, or prepaid account), a plus shared deposits indicator, no surcharge alliance indicator, a service indicator, a fast funds indicator, a money transfer acceptance, a token indicator, an authentication mode, an installment payments indicator or interchange information. An attribute of an access account may include information relating to access to specialized features or data, the ability to access certain data or locations at certain times and/or under certain conditions, etc.

[0041] “Further processing” of an event such as a transaction may include additional process steps that can be performed in relation to an initial event. In embodiments of the invention,“further processing” may be based upon attributes. For example, further processing associated with an account may involve additional authentication or fee processing associated with an initial transaction event. In the context of data or location access,“further processing” may involve causing a computer to perform certain operations in accordance with a set of attributes (e.g., allow a user to pass through an expedited queue for a ride).

[0042] FIG. 1 shows a system comprising a number of components. For simplicity of illustration, a certain number of components is shown in FIG. 1. It is understood, however, that embodiments of the invention may include more than one of each component.

[0043] The system illustrated in FIG. 1 may comprise a user device 102, a resource provider computer 104, a transport computer 106, a server computer 108, and an authorization computer 1 10. The user device 102 may be in operative

communication with the resource provider computer 104. In some embodiments, the user device 102 may be in close proximity to the resource provider computer 104, for example, to allow near-field communication (NFC). The resource provider computer 104 may be in operative communication with the transport computer 106. The transport computer 106 may be in operative communication with the server computer 108. The server computer 108 may be in operative communication with the authorization computer 1 10.

[0044] Messages between the resource provider computer 104, the transport computer 106, the server computer 108, and the authorization computer 1 10 may be transmitted using a secure communication protocol such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and/or the like. [0045] The user device 102 may be any suitable device that may be operated by a user. The user device 102 may be pre-provisioned with access data such as a token. For example, a user device 102 may be a watch comprising a processor, a computer readable medium a BLE component, and a memory comprising the access data.

[0046] In some embodiments, the user device 102 may be a ring comprising a processor, a computer readable medium, and BLE component, and a memory including the token. The token may be pre-provisioned when the ring is manufactured. In an example, the token may a payment token and may subsequently be associated with a card. The token and the card may both be associated with an attribute. For example, an attribute may be a product type, wherein the product type may be the type of card, i.e. , gold, platinum, signature, etc. In some embodiments, different product types may be associated with different interchange rates and thus different interchange indicators. Since the token is pre-provisioned to the ring and is initially loaded with attribute data from a range of possible attribute data, a payment network or issuer will have no idea as to what product type of the card is later associated with the pre-provisioned token. For example, if a platinum card product type is later associated with the token that has a gold card product type, a payment network or issuer receiving the token would try to process the token as a gold card product type and have no idea that it is to process the token according to a platinum card product type interchange rate since the attribute data is loaded as a gold card product type onto the ring with the pre-provisioned token. Embodiments of the invention address this problem by providing attribute data to the necessary parties and computers during an authorization process for a transaction.

[0047] In another example, the user device 102 may be pre-provisioned with a token and an attribute such as a funding type (e.g., a credit device, a debit device, or a prepaid device). In embodiments of the invention, the attribute associated with the token may be changed so that it matches the attribute associated with a real credential that is associated with the token after it was pre-provisioned in the user device. For example, a user device may be pre-provisioned with a token that has an attribute that indicates that it is associated with a prepaid account. In embodiments of the invention, as will be described below, the user may link the token to an existing credit card account number. The attribute of a credit account may then be provided to a resource provider computer or transport computer during a transaction involving the token so that the token can be processed as a credit account rather than a prepaid account.

[0048] In a non-financial example, the user device 102 may be pre-provisioned with a token and an attribute such as“standard access” to indicate that the user can access standard data in a secure data center. The user may subsequently link the token with an account that has an attribute such as“special access” instead of “standard data.” The attribute of“standard access” may be provided to a resource provider computer or transport computer during a transaction involving a token. The alllows the token to be used to access special data instead of standard data.

[0049] The resource provider computer 104 may be associated with a merchant. The resource provider computer 104 may be an access device such as a POS terminal at a merchant location, a computer coupled with an access device of a merchant, or a remote server computer that operates a web site operated by the merchant. In some embodiments, the merchant operating the resource provider computer 104 may be a card-on-file (COF) merchant. The card-on-file merchant may store consumer account information in a remote database for future payments (e.g., recurring or periodic payments). The resource provider computer 104 may be configured to generate an authorization request message for a transaction that is initiated by the user. [0050] The transport computer 106 may be operated by an acquirer. An acquirer is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant, a wallet provider or another entity. The transport computer 106 may issue and manage an account of the merchant. In some embodiments, the transport computer 106 may forward the authorization request message to the server computer 108 and the authorization response message to the resource provider computer 104 during a transaction to confirm processing of a payment transaction.

[0051] The resource provider computer 104 or the transport computer 106 may comprises a processor, and a computer readable medium coupled to the processor.

The computer readable medium may comprise code, executable by the processor, to implement a method comprising: receiving, by a computer, a token stored in a user device in a transaction, the user device being pre-provisioned with a token, wherein a real credential is linked to the token after the token is stored in the user device;

obtaining, by the computer, one or more attributes associated with the real credential; processing, by the computer, an authorization request message comprising the token; transmitting, by the computer, the authorization request message comprising the token to a server computer to cause the server computer to determine a real credential instead of the token, and complete authorization, and transmit the modified

authorization request message to an authorizing computer; receiving, by the computer, an authorization response message from the server computer comprising the token; and performing, by the computer, further processing of the transaction using the token and the one or more attributes

[0052] The server computer 108 may be configured to provide authorization services, and clearing and settlement services for payment transactions. A server computer 108 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include

VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular includes a Visa Integrated Payments (VIP) system which processes authorization requests and a Base II system which performs clearing and settlement services. Furthermore, the payment processing network may include a server computer and may use any suitable wired or wireless telecommunications network, including the Internet. [0053] The authorization computer 1 10 may be a computer operated by an authorizing entity such as an account issuer, a transit agency, a secure location access provider, or a secure data access provider. Typically, an issuer is an entity (e.g., a bank) that issues and maintains an account of the user. The account may be a credit, debit, prepaid, or any other type of account. [0054] FIG. 2 also shows a user device 102, resource provider computer 104, transport computer 106, server computer 108, and authorization computer 1 10, and the descriptions of these components are provided above. The process flow in FIG. 2 is described in further detail below.

[0055] FIG. 3 shows a block diagram of a user device 104 according to an embodiment of the invention. The user device may include a processor 104A

operatively coupled to input / output elements 104B, secure element 104C, a

contactless element 104D, and a memory 104E. The user device 104 may also include a housing that houses the components shown in FIG. 3.

[0056] The input/output elements 104B may include any suitable devices that may allow for the input or output of data from the user device 104. Examples of input devices can include touchscreens, buttons, switches, etc. Examples of output devices can include displays, speakers, tactile devices, etc.

[0057] The secure element 104C may store sensitive data such as a token data or real credentials. A secure element can be a tamper-resistant hardware platform, capable of securely hosting applications and storing confidential and cryptographic data.

[0058] The contactless element 104D may comprise a short range

communication device, such as a short range RF antenna. In other embodiments, it may comprise medium range communication devices such as Bluetooth or Wi-Fi enabled communication devices. [0059] The memory 104E may comprise a computer readable medium. The computer readable medium may include an operating system (OS) 104E-1 , a token 104E-2, and an interaction application 104E-3.

[0060] The interaction application 104E-3 may comprise any suitable software application including an access application to access a secure location or secure data, a digital wallet application, a banking application, a payment application, etc.

[0061] A server computer 108 is shown in FIG. 4. The server computer 108 can be used as server computer 108 in FIGs. 1 -2 and 5. The server computer 108 may include a processor 108A. A network interface 108B, a computer readable medium 108C, an attribute database 108D, and a token mapping database 108D may be operatively coupled to the processor 108A.

[0062] The computer readable medium 108C may comprise a token exchange module 108C-1 , a message modification module 108C-2, an authorization module 108C-3, and a clearing module 108C-4. [0063] The token exchange module 108C-1 may comprise code for receiving a token and communicating with the token mapping database 108D to retrieve a corresponding real credential. It may also comprise code for receiving a real credential, and identifying and retrieving a corresponding token.

[0064] The message modification module 108C-2 may comprise code for receiving an authorization request message including a token, and then modifying the authorization request message to include a corresponding real account identifier. It may also comprise code for receiving an authorization response message including a real credential and substituting the real credential with a corresponding token.

[0065] The authorization module 108C-3 may comprise code for performing authorization processing, including determining an appropriate authorizing entity based on a token or real credential, and then forwarding an authorization message to the authorizing entity. It may also comprise code for determining an appropriate transport computer or resource provider computer from an authorization response message, and then forwarding the authorization response message to the determined transport computer or resource provider computer.

[0066] The clearing module 108C-4 may comprise code for performing clearing and settlement services. This module may comprise code for routing and sending clearing messages between transport computers and authorizing entity computers, and also transferring funds between those entities.

[0067] The attribute database 108D may store attributes that may be associated with real account identifiers and/or tokens.

[0068] The token mapping database 108E may store mappings between tokens and real credentials. It may also store the real credentials and/or the tokens so that they may be retrieved and inserted into appropriate messages.

[0069] In some embodiments, the server computer 108 may comprise a processor; and a computer readable medium, the computer readable medium. The computer readable medium comprises code, executable by the processor, to implement a method comprising: receiving an authorization request message comprising a token from a computer; determining a real credential associated with the token; transmitting the authorization request message comprising the real credential to an authorization computer; receiving the server computer, an authorization response message comprising the real credential from the authorization computer; determining, by the server computer, an attribute associated with the real credential; and transmitting, by the server computer, the authorization response message comprising the token and the attribute to the computer.

[0070] A method according to an embodiment of the invention can be described with respect to FIG. 1. Before step S1 1 , the user device 102 may have a token stored in a memory. The user device 102 may receive the token, for example, when the user device 102 is manufactured. In some embodiments, pre-provisioning the token may include any of the systems and/or methods included in Patent Application No.

15/476,160, filed on March 31 , 2017, which is herein incorporated by reference in its entirety. In some embodiments, the token that was pre-provisioned may subsequently be associated with a real credential. For example, a user device such as a wrist band may be pre-provisioned with a token, and data regarding the token may be stored at a remote server computer. A user may subsequently contact the remote server computer, through browser to instruct the remote server computer to link a real credential and its attributes to the token. Thus, the real credential and the token may be may initially be associated with different attributes, but may be associated with the same attributes at a later point in time. The attributes associated with the token in a pre- provisioned user device 102 may be out-of-date or otherwise incorrect, but cannot be updated or altered since the user device 102 does not have long distance

communication capabilities, and/or the ability to be modified with updated attributes.

[0071] At step S1 1 , the user device 102 may initiate a transaction, or other suitable interaction, with the resource provider computer 104. For example, the user may bring the user device 102 into contact range with the resource provider computer 104. The contact range may vary based on the capabilities of the user device 102. For example, a user device 102 capable of BLE or NFC may be within a few inches of the resource provider computer 104 to initiate a transaction. The user device 102 may transmit the token to the resource provider computer 104.

[0072] At step S12, the resource provider computer 104 may transmit an attribute request message comprising the token to the server computer 108.

[0073] At step S13, after receiving the attribute request message comprising the token, the server computer 108 may determine a real credential associated with the token. The server computer 108 may then determine an attribute associated with the real credential. The server computer 108 may then generate and transmit an attribute response message comprising the attribute associated with the resource provider to the resource provider computer 104. In other embodiments, the attribute response message may be transmitted to the user device 102 and/or the transport computer 106, in addition to, or as an alternative to the resource provider computer 104.

[0074] In some embodiments, the attribute may be used in payment processing.

In such instances, the attribute may be an issuer country code, a US acceptance type, a PIN at point-of-sale indicator, an authorization only indicator, a brand indicator, an account funding source subtype, a plus shared deposits indicator, no surcharge alliance indicator, a service indicator, a fast funds indicator, a money transfer acceptance, a token indicator, or an installment payments indicator. In other embodiments, the attribute may contain any suitable data related to the real credential. In yet other embodiments, the attribute may be data or information relating to interchange.

[0075] At step S14, after receiving the attribute response message comprising the attribute, the resource provider computer 104 may generate an authorization request message comprising the token and a transaction amount. The resource provider computer 104 may store the attribute data in a database and/or may include it with the token. After the authorization request message is generated, the resource provider computer 104 may transmit the authorization request message to the transport computer 106.

[0076] At step S15, after receiving the authorization request message comprising the token and optionally the attribute, the transport computer 106 may transmit the authorization request message to the server computer 108.

[0077] At step S16, after receiving the authorization request message from the transport computer 106, the server computer 108 may determine the real credential associated with the token. The server computer 108 may replace the token in the authorization request message with the real credential. The server computer 108 may transmit the authorization request message comprising the real credential and the transaction amount to the authorization computer 1 10.

[0078] At step S17, after receiving the authorization request message comprising the real credential, the authorization computer 1 10 may decide to authorize the transaction. The authorization computer 1 10 may generate an authorization response message comprising the real credential. The authorization computer 1 10 may then transmit the authorization response message comprising the real credential to the server computer 108.

[0079] At step S18, after receiving the authorization response message comprising the real credential from the authorization computer 1 10, the server computer 108 may determine the token associated with the real credential. The server computer 108 may replace the real credential in the authorization response message with the token. The server computer 108 may transmit the authorization response message comprising the token.

[0080] At step S19, the resource provider computer 104 may receive the authorization response message comprising the token. The resource provider computer 104 may then proceed with the transaction with the user device 102.

[0081] At a later time, a clearing and settlement process may occur. The stored attribute data at the resource provider computer 104 may be provided to the transport computer 106 if the transport computer 106 did not previously receive it. The transport computer 106 may provide the attribute data to the server computer 108, and the server computer 108 may alter processing of the transaction based upon the attribute data.

[0082] Illustratively, the attribute data that was transmitted to the resource provider computer may be that the real credential associated with the token was for a “signature” payment card, rather than a“standard” payment card. While the token associated with the user device 102 may have been associated with a“standard” payment card before the attribute request message was sent in step S12, it will subsequently be associated with a“signature” payment card since the token is now linked to the real credential which is a account for a“signature” payment card. A “signature” payment card may have a higher (or lower) interchange fee associated with it than a“standard” payment card. As such, the transaction will be further processed using the token using an interchange rate associated with the“signature” payment card rather than the“standard” payment card.

[0083] FIG. 2 shows a system 200 comprising a number of components. System 200 may comprise the user device 102, the resource provider computer 104, the transport computer 106, the server computer 108, and the authorization computer 1 10. The process flow in FIG. 2 differs from the process flow in FIG. 1. In FIG. 2, attribute data can be provided to the resource provider computer 104 or the transport computer 106 via an authorization response message, instead of through a separate

communication to the server computer 108. [0084] At step S21 , the user device 102 may initiate a transaction with the resource provider computer 104. The user device 102 may transmit the token to the resource provider computer 104 (e.g., via NFC, contact, or Bluetooth).

[0085] At step S22, the resource provider computer 104 may generate an authorization request message comprising the token and a transaction amount. The resource provider computer 104 may transmit the authorization request message to the transport computer 106.

[0086] At step S23, after receiving the authorization request message comprising the token, the transport computer 106 may transmit the authorization request message comprising the token and the transaction amount to the server computer 108.

[0087] At step S24, the server computer 108 may determine a real credential associated with the token. The server computer 108 may replace the token in the authorization request message with the real credential. The server computer 108 may transmit the authorization request message comprising the real credential and the transaction amount to the authorizing computer 1 10.

[0088] At step S25, after receiving the authorization request message comprising the real credential, the authorizing computer 1 10 may determine to authorize the transaction. The authorizing computer 1 10 may then generate an authorization response message comprising the real credential. The authorizing computer 1 10 may transmit the authorization response message comprising the real credential to the server computer 1 10.

[0089] At step S26, after receiving the authorization response message comprising the real credential from the authorizing computer 1 10, the server computer 108 may determine an attribute associated with the real credential. The server computer 108 may determine the token associated with the real credential. The server computer 108 may replace the real credential in the authorization response message with the token and the attribute. The server computer 108 may then transmit the authorization response message comprising the token and the attribute to a computer. In some embodiments the computer may be the transport computer 106. In other embodiments, the computer may be the resource provider computer 104.

[0090] At step S27, the transport computer 106 may transmit the authorization response message comprising the token and the attribute to the resource provider computer 104. After receiving the authorization response message comprising the token and the attribute, the resource provider computer 104 may allow the user of the user device 102 to receive the requested resource (e.g., a good or service) if the request was authorized.

[0091] After step S27, the transport computer 106, the server computer 108, and the authorization computer 1 10 may perform additional processing. In some

embodiments, additional processing may be based on the attribute associated with the real credential. In other embodiments, additional processing may include a settlement process between the transport computer 106, the server computer 108, and the authorization computer 1 10. Settlement may occur in a different manner due to the presence of the received attribute (e.g., different processing method, different interchange rates, etc.).

[0092] In some embodiments, the resource provider computer 104 may transmit the authorization response message comprising the token and the attribute to the user device 102. Even if the real credential associated with the token were to be altered, or if the attributes of the real credential did not match the attributes of the token, the user device 102 may still be capable of initiating transactions with the token.

[0093] FIG. 5 shows another system according to another embodiment of the invention. As in FIGs. 1 -2, FIG. 5 shows a user device 102, a resource provider computer 104, a server computer 108, and an authorization computer 1 10. FIG. 5 also shows an unrestricted zone 550 and a restricted zone 552. The unrestricted zone 550 may be, for example, an area outside of a secure network that houses secure data, while the restricted zone 552 is an area that houses secure data. In other

embodiments, the unrestricted zone 550 may be, for example, an area outside of a secure location (e.g., the street), while the restricted zone 552 is an area that is a restricted area such as a building or a transit station. [0094] In step S51 , user device 102 may initiate a transaction with the resource provider computer 104. The user device 102 may transmit the token to the resource provider computer 104. For purposes of illustration, the unrestricted zone 550 may be an area outside of an amusement park ride while the restricted zone 552 may be an area inside of the amusement park ride. The user device 102 may be in the form of a wearable device such as a wristband, and may have been pre-provisioned with a token when the wearable device was obtained (e.g., purchased). The token may have been subsequently linked to a payment account identifier that was used to pay for the wristband. For example, when the user obtained the user device 102, the user may have requested specific services or special treatment upon entry to the secure location (e.g., through a Website or in person). Illustratively, the user requested that she be allowed to pass into an expedited queue instead of a standard queue for a shorter wait time. However, this attribute information corresponding to this request may not be stored on the wristband.

[0095] At step S52, the resource provider computer 104 may generate an authorization request message comprising the token. The resource provider computer 104 may transmit the authorization request message to the server computer 106.

[0096] At step S56, the server computer 108 may determine a real credential associated with the token. The server computer 108 may replace the token in the authorization request message with the real credential. The server computer 108 may transmit the authorization request message comprising the real credential to the authorizing computer 1 10.

[0097] At step S57, after receiving the authorization request message comprising the real credential, the authorizing computer 1 10 may determine whether or not to authorize the transaction. The authorizing computer 1 10 may then generate an authorization response message comprising the real credential. The authorizing computer 1 10 may transmit the authorization response message comprising the real credential to the server computer 108.

[0098] After step S57, after receiving the authorization response message comprising the real credential from the authorizing computer 1 10, the server computer 108 may determine an attribute associated with the real credential. In this example, the attribute may be, for example, information informing the resource provider computer 104 to grant the user of the user device 102 access to an expedited queue instead of a standard queue. The server computer 108 may determine the token associated with the real credential. The server computer 108 may replace the real credential in the authorization response message with the token and the attribute. The server computer 108 may then transmit the authorization response message comprising the token and the attribute to a computer. The computer may be the resource provider computer 104.

[0099] Once the resource provider computer 104 receives the authorization and attribute information, it may perform further processing in accordance with those attributes. For example, the resource provider computer 104 could direct the user of the user device 102 into an expedited queue instead of a standard queue for faster processing.

[0100] Embodiments of the invention have a number of advantages. For example, embodiments of the invention allow for one to use user devices with pre- provisioned tokens with enhanced functions, even though data pertaining to those functions does not reside on the user devices. Contrary to conventional systems, in embodiments of the invention, it is not necessary for a manufacturer to manufacture many different types of user devices with different tokens and special attributes for each and every user.

[0101] Embodiments of the invention have a number of additional advantages.

For example, the transport computer 106 may receive the attribute when receiving the authorization response message. This optimizes the number of messages and reduces network traffic relative to the case where attributes are provided out of band. Due to this, the system can handle more authorization request and response messages with the same amount of overall network traffic. Additionally, since the transport computer 106, the authorization computer 1 10, and the server computer 108 may obtain the attribute, the computers may efficiently process the transaction according to the attribute. For example, the transport computer 106 may perform additional processing with the server computer 108 and the authorization computer 1 10, based on the recently received attribute rather than the original attribute associated with the pre- provisioned token.

[0102] It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner. As used herein, a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.

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

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

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

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

[0107] 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 comprising:

receiving, by a server computer, an authorization request message comprising a token from a computer;

determining, by the server computer, a real credential associated with the token;

transmitting, by the server computer, the authorization request message comprising the real credential to an authorization computer;

receiving, by the server computer, an authorization response message comprising the real credential from the authorization computer;

determining, by the server computer, an attribute associated with the real credential; and

transmitting, by the server computer, the authorization response message comprising the token and the attribute to the computer.

2. The method of claim 1 , wherein the computer is a transport computer or a resource provider computer.

3. The method of claim 1 , wherein the token was pre-provisioned on a user device that interacted with an access device that generated the authorization request message.

4. The method of claim 1 , wherein the token allows access to secure data, and wherein the attribute relates to an ability to access a particular type of data.

5. The method of claim 1 , further comprising:

replacing the token in the authorization request message with the real credential; and

replacing the real credential in the authorization response message with the token and the attribute.

6. The method of claim 1 , wherein the server computer comprises a token mapping database comprises data mapping real credentials and tokens.

7. The method of claim 1 , wherein the token has 16 digits.

8. A server computer comprising:

a processor; and

a computer readable medium, the computer readable medium comprising code, executable by the processor, to implement a method comprising:

receiving an authorization request message comprising a token from a computer;

determining a real credential associated with the token;

transmitting the authorization request message comprising the real credential to an authorization computer;

receiving an authorization response message comprising the real credential from the authorization computer;

9. The server computer of claim 8, wherein the token was pre- provisioned on a user device that interacted with an access device that generated the authorization request message.

10. The server computer of claim 8, wherein the token is used to access secure data.

1 1. The server computer of claim 8, wherein the token allows access to secure location, and wherein the attribute is the ability to access a particular type of location.

12. The server computer of claim 8, wherein the server computer comprises a token mapping database comprises data mapping real credentials and token.

13. The server computer of claim 8, wherein the server computer comprises an attribute database storing attribute data associated with real credentials.

14. The server computer of claim 8, wherein the computer readable medium in the server computer comprises a token exchange module, a message modification module, and an authorization module.

15. A method comprising:

receiving, by a computer, a token stored in a user device in a transaction, the user device being pre-provisioned with a token, wherein a real credential is linked to the token after the token is stored in the user device;

obtaining, by the computer, one or more attributes associated with the real credential;

processing, by the computer, an authorization request message comprising the token;

transmitting, by the computer, the authorization request message comprising the token to a server computer to cause the server computer to determine a real credential instead of the token, and complete authorization, and transmit a modified authorization request message to an authorizing computer;

receiving, by the computer, an authorization response message from the server computer comprising the token; and

performing, by the computer, further processing of the transaction using the token and the one or more attributes.

16. The method of claim 15, wherein the computer is a transport computer.

17. The method of claim 15, wherein the computer is a resource provider computer.

18. The method of claim 15, wherein the token is 16 digits.

19. A computer comprising: a processor; and

a computer readable medium, the computer readable medium comprising code, executable by the processor, for performing the method according to any of claims 15-18.

20. A system comprising:

the computer of claim 19; and

the server computer.