Method and system for provisioning payment credentials for a mobile device

Abstract

Several embodiments are described, relating to optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets. In some embodiments, for the provisioning of payment account credentials, one of a plurality of provisioning schemes may be selectively chosen based on an identified risk involved in a particular provisioning request. Low-risk provisioning requests result in the immediate provisioning of payment credentials, while high-risk provisioning requests result in the provisioning request being rejected. In some embodiments, medium-risk provisioning requests will result in additional user authentication being completed before the payment account provisioning is terminated. The additional user authentication may occur using a communication channel separate from the channel through which the provisioning request is received.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2014 / 050407, international application date August 8, 2014, Chinese national phase application number 201480055432.0, entitled "Method and System for Supplying Payment Certificates for Mobile Devices".

[0002] Cross-references to related applications

[0003] This application refers to U.S. Provisional Application No. 61 / 863,878, filed August 8, 2013, entitled "METHODS AND SYSTEMS FOR PROVISIONING MOBILE DEVICES WITH PAYMENT CREDENTIALS"; U.S. Provisional Application No. 61 / 898,428, filed October 31, 2013, entitled "METHODS AND SYSTEMS FOR PROVISIONING MOBILE DEVICES WITH PAYMENT CREDENTIALS"; U.S. Provisional Application No. 61 / 866,514, filed August 15, 2013, entitled "REMOTE MOBILE PAYMENT TRANSACTION WITH MOBILE APPLICATION USING SECUREELEMENT"; and U.S. Provisional Application No. 61 / 866,514, filed August 21, 2013, entitled "TRANSACTION ALERT". The interests in the following applications are claimed in whole or in part: U.S. Provisional Application No. 61 / 868,487, entitled “System Incorporating Encrypted Transaction Alerts System”; U.S. Provisional Application No. 61 / 978,172, filed April 10, 2014, entitled “Transaction Alert and Transaction History Delivery System Incorporating Encrypted Transaction Alerts System”; and U.S. Provisional Application No. 61 / 870,153, filed August 26, 2013, entitled “Transaction Log Payment Application”. Technical Field

[0004] Various aspects of this disclosure relate to computing technology. In particular, various aspects of this disclosure relate to apparatus for providing technologies such as systems, methods, devices, and computer-readable media for supplying payment credentials to mobile devices. Background Technology

[0005] With the continuous development and use of mobile technology, more and more features are being integrated into mobile devices. For example, GPS applications, mobile office products, messaging systems, video cameras, and even compass functions have been integrated into mobile devices, making them widely applicable to both business and personal use.

[0006] To further leverage mobile technology to better meet users' daily needs, several attempts have been made to replace conventional physical wallets with technologies implemented on mobile devices. For example, one way to provide mobile wallet functionality is by directly supplying the card issuer's account information to the secure element (SE) of a mobile device equipped with a Near Field Communication (NFC) chipset. The SE can be a smart card chip capable of storing various application and / or account-specific information that cannot be easily accessed by external parties. NFC technology is widely used for contactless short-range communication, based on the Radio Frequency Identification (RFID) standard, using magnetic field sensing to enable communication between electronic devices. This short-range, high-frequency wireless communication technology allows devices to exchange data over short distances (e.g., a few centimeters). Such mobile devices can therefore use mobile wallet applications, which, like conventional physical wallets, can "include" payment cards (e.g., credit cards, debit cards, prepaid cards), membership cards, transportation cards, loyalty cards, etc.

[0007] For this purpose, user financial credentials (e.g., account master number (PAN), expiry date, etc.) can be supplied on mobile devices. Once these financial credentials are supplied on a mobile device, an NFC-enabled device can transact with another NFC-enabled device by bringing the devices close together (e.g., transferring information, making payments). Additionally, the mobile device supplied with the account can also be used to perform transactions with other remote systems (e.g., a merchant's website) using other wireless protocols (such as via cellular or wireless (e.g., IEEE 802.11) networks).

[0008] While the benefits of integrating wallet functionality into mobile devices are significant and still evolving, major technologies still lack effective and secure processes and means to securely and efficiently supply financial credentials to user devices. The various embodiments of the present invention address these and other problems individually and collectively. Summary of the Invention

[0009] A typical payment credential provisioning process involves multiple messages between a third-party wallet provider and the provisioning server. Additionally, unnecessary delays are often encountered when authenticating user accounts during provisioning. Therefore, there is a need to accelerate the process of provisioning payment accounts on mobile devices (e.g., on Secure Element) and to provide more efficient methods for provisioning large numbers of card instances on Secure Element. Furthermore, enhanced authentication services are needed during the provisioning process, as some legitimate consumers may have questionable initial authentication results. Therefore, additional authentication processes are required that do not disrupt or delay the provisioning process.

[0010] Embodiments of the present invention relate to optimizing the supply of payment account credentials to mobile devices utilizing mobile wallets. According to some embodiments, for the supply of payment account credentials, a supply scheme can be selectively chosen from multiple supply channels based on the determined risks involved in a particular supply request.

[0011] In some embodiments, low-risk supply requests may result in immediate commencement of supply, while high-risk supply requests may result in rejection of the supply request. In some embodiments, medium-risk supply requests will result in additional user authentication being completed before the payment account supply is terminated. In some embodiments, additional user authentication includes communicating with the user via a communication channel separate from the channel through which the supply request is received. This communication may include sending a one-time password to the user on the second communication channel, which may be an SMS message, email, or HTTP message sent by the issuer to the user.

[0012] In some embodiments, a medium-risk request will result in the payment account credentials supplied to the mobile device being inactive. This inactivity will prevent the use of the payment credentials, and the supplied inactive credentials will be activated for use once the authentication process is complete.

[0013] According to one embodiment, a method performed by a service provider to supply account credentials includes receiving a first supply request at a server computer via a first communication channel to supply a first payment credential to a first mobile device. The first payment credential is associated with a first account of a first user. A first risk level associated with the first supply request is determined. In response to the first risk level being within a predetermined risk threshold range, the method includes having an authentication process performed by the first user. In response to the successful execution of the authentication process, the first payment credential is supplied to the first mobile device. The method further includes receiving a second supply request at a server computer via the first communication channel to supply a second payment credential to a second mobile device. The second payment credential is associated with a second account of a second user. The method further includes determining a second risk level associated with the second supply request, and in response to the second risk level being below a predetermined risk threshold range, supplying the second payment credential to the second mobile device. In an embodiment, a non-transient computer-readable medium stores instructions that, when executed by a processor of the server, cause the server to perform the method. In an embodiment, a server computer is described, including a processor and the described non-transient computer-readable medium. In an embodiment, a payment account credential supply system is described, including the server computer, one or more issuing computers, a wallet provider server computer, and a mobile device.

[0014] Embodiments of the present invention relate to optimizing Secure Element (“SE”) application provisioning on a mobile device with a mobile wallet and a consumer registration process. Some embodiments involve provisioning card data on the SE by generating and transmitting multiple possible personalized scripts to achieve multiple provisioning results in a single communication. Therefore, by providing all possible provisioning scripts to the wallet provider or other payment account manager before completing card data activation, the embodiments optimize SE application provisioning so that the final activation of the supplied card account on the secure account requires less communication and / or computational resources at activation time. Thus, card application data can be provisioned on the Secure Element of the mobile device with only a single provisioning message from the provisioning system, minimizing the number of messages between the mobile wallet server and the payment processing network service provider.

[0015] Therefore, embodiments of the present invention provide an efficient supply process that can selectively provide enhanced user authentication within a single efficient process.

[0016] These and other embodiments of the present invention are described in further detail below. Attached Figure Description

[0017] Figure 1 A block diagram is shown, which includes various entities in a payment transaction system.

[0018] Figure 2 A block diagram is shown that includes various entities in an account provisioning system according to some embodiments of the present invention.

[0019] Figure 3 The diagram illustrates a combination sequence and flowchart of account supply, including low-risk and high-risk supply, in an account supply system according to some embodiments of the present invention.

[0020] Figure 4 The illustration depicts some embodiments according to the present invention. Figure 2 Combination sequence and flowchart of medium-risk account supply in the account supply system.

[0021] Figure 5 The process of a server computer for account provisioning is illustrated according to some embodiments of the present invention.

[0022] Figure 6 The diagram illustrates a combination sequence and flowchart of two dynamic verification value confirmation configurations in an account supply system according to some embodiments of the present invention.

[0023] Figure 7 The diagram illustrates a combination sequence and flowchart depicting, according to some embodiments of the present invention, a combination of consumer-specific cryptographic key supply and secure message transmission via a wallet provider.

[0024] Figure 8 The diagram illustrates a combination sequence and flowchart depicting the use of a unique transaction identifier for transaction log updates according to some embodiments of the present invention.

[0025] Figure 9 It is a high-level block diagram of a computer system that can be used to implement any of the entities or components described herein. Detailed Implementation

[0026] A typical payment credential provisioning process involves multiple messages between a third-party wallet provider and the provisioning gateway. Additionally, unnecessary delays are often encountered when authenticating user accounts during provisioning. Therefore, there is a need to accelerate the process of provisioning payment accounts on Secure Element and to provide more efficient methods for provisioning (potentially large numbers of) card instances on Secure Element.

[0027] Additionally, enhanced authentication services are needed during the supply process, as some legitimate consumers may have questionable initial authentication results. Therefore, an additional authentication process is required that does not disrupt or delay the supply process.

[0028] Embodiments of the present invention relate to optimizing the supply of payment account credentials to mobile devices utilizing mobile wallets. According to some embodiments, for the supply of payment account credentials, a supply scheme can be selectively chosen from multiple supply channels based on the determined risks involved in a particular supply request.

[0029] In some embodiments, low-risk supply requests may result in immediate commencement of supply, while high-risk supply requests may result in rejection of the supply request. In some embodiments, medium-risk supply requests will result in additional user authentication being completed before the payment account supply is terminated. In some embodiments, medium-risk requests will result in the payment account credentials supplied to the mobile device being inactive, which disallows the use of the payment credential, and the supplied inactive credential may be activated for use upon completion of the authentication process.

[0030] Embodiments of the present invention relate to optimizing Secure Element (“SE”) application provisioning on mobile devices with mobile wallets, including a consumer registration process. Some embodiments involve provisioning card data on the Secure Element by generating and transmitting multiple possible personalized scripts to achieve multiple provisioning results in a single communication. Therefore, by providing all possible provisioning scripts to the wallet provider or other payment account manager before completing card data activation, the embodiments optimize Secure Element application provisioning so that the final activation of the supplied card account on the Secure Element requires less communication and / or computational resources at activation time. Thus, card application data can be provisioned on the Secure Element of the mobile device with only a single provisioning message from the provisioning system, minimizing the number of messages between the mobile wallet server and the payment processing network service provider.

[0031] Therefore, embodiments of the present invention provide an efficient supply process that can selectively provide enhanced authentication for users within a single efficient process.

[0032] I. Terminology

[0033] Before discussing embodiments of the invention, descriptions of some terms are presented to aid in understanding this disclosure.

[0034] As used herein, the term "comprising" is not intended to be limiting, but can be a transitional phrase synonymous with "including," "containing," or "characterized by." The term "comprising," when used in claims, can thus be inclusive or open-ended and does not exclude additional, unassigned elements or method steps. For example, when describing a method, "comprising" indicates that the claim is open-ended and allows for additional steps. When describing a device, "comprising" can indicate that the named element may be critical to the embodiment, while other elements may be added and still form the construction within the scope of the claim. Conversely, the transitional phrase "consisting of" excludes any element, step, or ingredient not specified in the claim.

[0035] The use of these terms is consistent throughout the instruction manual.

[0036] In the following description and claims, the terms "coupled" and "connected" may be used. The term "coupled" may be used to indicate two or more elements that may or may not be in direct physical or electrical contact with each other, but still cooperate or interact with each other. The term "connected" may be used to indicate the establishment of communication between two or more elements coupled to each other.

[0037] As used herein, "mobile device" can include any electronic and / or communication device that can be transported and operated by a user and provides the ability to communicate remotely with resources via one or more networks. Examples of mobile devices include mobile phones (e.g., cellular phones), personal digital assistants (PDAs), tablet computers, portable computers (e.g., netbooks), personal music players, handheld electronic reading devices, wearable computing devices, and the like.

[0038] A "server computer" can include a powerful computer or a combination of two or more computers. For example, a server computer can be a mainframe, a cluster of microcomputers, or a group of servers that acts as a unit (such as a cluster). In one example, a server computer could be a database server coupled to a web server. Server computers typically run server applications and act as servers in client-server interactions, including but not limited to database server applications, web server applications, application server applications, etc.

[0039] As used herein, a “communication channel” can refer to any suitable path for communication between two or more entities. A suitable communication channel may exist directly between two entities, such as a payment processing network and a merchant's or issuer's computer, or it may include multiple different entities. Any suitable communication protocol can be used to generate a communication channel. In some instances, a communication channel may include a “secure communication channel” that can be established in any known manner, including the use of mutual authentication and session keys, and the establishment of a Secure Sockets Layer (SSL) session. However, any method for creating a secure channel can be used. By establishing a secure channel, sensitive information associated with a payment device (such as account number, card verification value (CVV) value, expiration date, etc.) can be securely transmitted between two entities, thereby facilitating transactions.

[0040] As used herein, a “risk score” may include any label or rating indicating the risk associated with a transaction potentially being fraudulent. Risk scores may be represented by numbers (and any scale), probabilities, or any other relevant means of conveying such information. A risk score may include an aggregation of information about the transaction, including transaction information, account information, and verification information, as defined above. A risk score may be used by any authorized entity (such as a merchant or issuer) to determine whether to authorize a transaction. A risk score may include and / or utilize current and past transaction information, and such information may be weighed in any appropriate manner.

[0041] As used in this article, a “payment account” (which may be associated with one or more payment devices) may refer to any appropriate payment account, including credit card accounts, checking accounts, prepaid card accounts, etc.

[0042] As used herein, “identification information” may include any appropriate information associated with an account (e.g., a payment account and / or a payment device associated with that account). This type of information may be directly related to the account or may be derived from account-related information. Examples of account information may include PAN (primary account number or “account number”), username, expiry date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values ​​are generally visible to the user (e.g., a consumer), while CVV and dCVV values ​​are typically embedded in memory or authorization request messages and are not easily known to the user (although they are known to the issuer and payment processor).

[0043] II. Payment System

[0044] Figure 1A block diagram is shown that includes multiple entities in a payment transaction system 100. The payment transaction system 100 shown includes a user 107, a payment device 108, a mobile device 101, an access device 102, a merchant computer 103, an acquiring computer 104, a payment processing network 105, and an issuing computer 106.

[0045] System 100 includes a user 107 who can operate a mobile device 101. User 107 can use the mobile device 101 to conduct financial transactions (e.g., payment transactions) at an access device 102 connected to a merchant computer 103. User 107 can also conduct financial transactions at the access device 102 using a payment device 108. Merchant computer 103 can be connected to acquiring computer 104. Acquiring computer 104 can be connected to issuing computer 105 via payment processing network 106. Of course, some or all of these connected entities can be connected on one or more communication networks or can be directly connected.

[0046] As used herein, a “merchant” is generally an entity that engages in transactions and may sell goods and / or services. An “issuer” may generally refer to a business entity (e.g., a bank) that maintains a user’s financial account and may issue payment credentials to be stored on the user’s mobile device 101 (e.g., a cellular phone, smart card, tablet, laptop, etc.). An “acquiring party” is generally a business entity (e.g., a bank) that has a business relationship with a particular merchant or other entity. Some entities may perform both issuing and acquiring functions, and some embodiments may include such a single-entity issuer-acquiring party. Each of these entities (e.g., merchant computer 103, acquiring computer 104, payment processing network 105, and issuing computer 106) may include one or more computer devices to allow communication or to perform one or more of the functions described herein.

[0047] As used herein, “payment device” 108 can refer to any device that can be used to conduct financial transactions, such as providing payment information to merchants. A payment device can be any suitable form. For example, suitable payment devices include, but are not limited to: smart cards, magnetic stripe cards, keychain devices (such as the Speedpass commercially available from ExxonMobil). TMPayment devices 108 may include, but are not limited to, cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, 2-D barcodes, electronic or digital wallets, etc. Such devices can operate in contact or contactless modes. In some configurations, payment device 108 interacts directly with access device 102 (i.e., without the use of any other devices and / or networks), while in other configurations, payment device 108 communicates with access device 102 using intermediary devices and / or communication networks. Mobile device 101 is a mobile device (as described above) and may be considered a type of payment device (e.g., payment device 108) in some embodiments. For example, mobile device 101 may include, but is not limited to, cellular phones, laptops, tablets, wearable computing devices, etc., and may interact with access device 102 (e.g., using NFC) and / or merchant computer 103 (e.g., accessing websites via the Internet or utilizing applications provided by merchant computer 103) to initiate and / or conduct financial transactions.

[0048] Payment processing network 105 may include a data processing subsystem, a network, and operations for supporting and delivering certificate authorization services, authorization services, exception handling services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM Such as VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, digital wallet transactions, and other types of commercial transactions. TM This includes a VIP system (Visa-integrated payment system) for processing authorization requests and a Base II system for performing clearing and settlement services. In some embodiments, the payment processing network 105 can process transactions substantially in real time (e.g., in less than a few seconds or a second). The payment processing network 105 may include one or more server computers (as described above). The payment processing network 105 can use any suitable wired or wireless network, including the Internet.

[0049] In an exemplary purchase transaction, user 107 uses mobile device 101 (e.g., a mobile phone) to purchase goods or services from a merchant. The user's mobile device 101 can interact with an access device 102 at the merchant's premises, associated with the merchant's computer 103. For example, user 107 can tap mobile device 101 against an NFC reader in access device 102. Alternatively, using a digital wallet or through an online transaction, user 107 can electronically instruct the merchant on payment details. In some purchase transactions, mobile device 101 may not use access device 102 but can interact directly with the merchant's computer 103 (e.g., a computer system providing the merchant's website or a "back-end" service of the merchant application 208A running on mobile device 101). In these examples, the merchant's computer 103 can be considered as implementing a virtual access device.

[0050] To enable the financial transaction to be executed, an authorization request message is generated by access device 102 (or a virtual access device, which may be on merchant computer 103) and forwarded to acquirer computer 104. Acquiring computer 104 is a system that provides the merchant's account (as described above) and will ultimately receive the transaction funds from the issuer of the account provided to user 107. This "authorization request message" may be an electronic message sent to payment processing network 105 and / or the issuer of the payment card (e.g., issuer computer 106) to request authorization for the transaction. According to some embodiments, the authorization request message may be compatible with the message type defined by the International Organization for Standardization (ISO) 8583 standard, which is a standard for systems exchanging information about electronic transactions associated with payments made by a user using payment device 108 (which may be mobile device 101) or a 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 the "identification information," which, for example only, include: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and / or authorize a transaction. The authorization request message may also include other information, such as the identifier of the access device 102 that generated the authorization request message, information about the location of the access device 102, etc.

[0051] Typically, the authorization request message will include a field for the primary account number (PAN) associated with the account of user 107 provided by mobile device 101 (or payment device 108). Upon receiving the authorization request message, acquiring computer 104 will send the authorization request message to payment processing network 105. Payment processing network 105 will then forward the authorization request message to issuing computer 106 associated with the issuer of the user's account. The PAN included in the authorization request message can be used by payment processing network 105 to identify the appropriate issuing computer 106 for routing or processing (e.g., determining the risk of the authorization request, possibly based on known rules about the issuer) of this message.

[0052] After receiving the authorization request message, the issuing computer 106 sends an authorization response message back to the payment processing network 105 to indicate whether the current transaction has been authorized. The "authorization response message" can be an electronic message generated by the issuing financial institution or payment processing network in response to the authorization request message and can be compatible with the ISO 8583 standard. As an example only, the authorization response message may include one or more of the following status indicators: "Approved" – the transaction is approved; "Rejected" – the transaction is not approved; or "Call Center" – the response is pending due to the need for more information, and the merchant must call the toll-free authorization telephone number. The authorization response message may also include an authorization code, which can be a code returned by the issuing computer to the merchant's access device 102 (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network), indicating permission for the transaction and serving as proof of authorization.

[0053] Payment processing network 105 receives an authorization response message from issuing computer 106 and transmits it to receiving computer 104. Receiving computer 104 then sends the authorization response message back to merchant computer 103, where the merchant can determine whether to proceed with the transaction. In some embodiments, such as when a fraud rule is triggered at payment processing network 105, payment processing network 105 may reject a transaction previously authorized by issuing computer 106. After merchant computer 103 receives the authorization response message, access device 102 may subsequently provide the authorization response message to user 107. The response message may be displayed by a display device (e.g., a display device that is part of or coupled to access device 102), printed on a receipt, delivered to user's mobile device 101, etc. Optionally, if the transaction is an online transaction (e.g., via a website or application), then merchant computer 103 may provide the authorization response message to mobile device 101 via a webpage, display module, or other indication.

[0054] At the end of the day, the payment processing network 105 can perform normal clearing and settlement processes. The clearing process involves exchanging financial details between the acquirer and the issuer to facilitate posting to the consumer's payment account and reconciling the user's settlement location. However, it should be noted that embodiments of the present invention are not limited to a single settlement process.

[0055] III. Systems using pre-generated scripts to supply card vouchers

[0056] In some cases, a user 107 with mobile device 101 may expect mobile device 101 to be "supplyed" with payment credentials (e.g., payment credential 207) for use by a merchant (e.g., merchant computer 103, typically via application 208, such as merchant application 208A, web browser 208B, third-party application, etc.) or for other transactions. Payment credential 207 may be an account maintained by issuer 240. Therefore, in some embodiments, mobile device 107 may need to be supplied with personalized data, such as payment information and information about user 107, first. Figure 2 An example of a system 200 for device provisioning according to some embodiments of the present invention is shown. System 200 includes a mobile device 107, an application provider 209 (e.g., wallet provider 210) server computer 211, a service provider 230 (e.g., payment processing network 105) server computer 212, and an issuer 240 server computer 106. Each of the mobile device 101 and the server computers 211, 212, and 106 may be implemented using one or more computing devices. In some embodiments, the mobile device 101 includes a secure element 202, which may be the location where payment credentials 207 are provisioned, and the mobile device 101 may also optionally include a secure payment application 206 and / or a transaction log 204 (both of which may reside outside the secure element 202 of the mobile device 101).

[0057] Application provider 209 and server computer 211 can be a server computer or other computing device operated by or on behalf of application provider 209. Application provider 209 can be any entity that provides an application (e.g., application 208) to user 107. An example of application provider 209 could be digital wallet provider 210 (e.g., Visa Checkout). TM Or Google TM(Wallet). Digital wallet provider 210 can maintain digital wallets for users, each digital wallet including payment data from one or more payment accounts. Application provider 209 can be associated with an application installed on mobile device 101. For example, the Visa Checkout application on mobile device 101 can be configured to connect to the server computer 211 of application provider 209 operated by Visa.

[0058] Service provider 230 server computer 212 may be a server computer or other computing device operated by or on behalf of service provider 230. Service provider 230 may be any entity that provides provisioning or personalization services. For example, service provider 230 computer may maintain a personalization database (not shown herein) containing information about users and may be configured to communicate with one or more issuers 240 to determine personalized payment data for user 107. Service provider 230 server computer 212 may provide "provision as a service" to one or more application providers 209 via its provisioning service module 225, wherein application provider 209 server computer 211 utilizes an application programming interface (API) to communicate with service provider 230 server computer 212.

[0059] Service provider 230—such as payment processing network 105—may provide supply service module 225 and / or device supply Consumer Authentication System (DPCAS) 214 as part of its server computer 212. DPCAS 214 may serve as an authentication server providing authentication services and may include access control server 216 (e.g., for determining whether an account is legitimate for a particular service or whether an account is participating in a particular service) and / or directory server 218 (e.g., for identifying the associated issuer 240 and / or ACS 216 for an account). In some embodiments, DPCAS 214 may verify user 107 authentication information, such as user identification information, one-time password, challenge response information, etc. In other embodiments, some or all of DPCAS 214 may be associated with (or provided by) issuer 240 or another entity. For example, in some embodiments, ACS 216 may be provided by issuer 240. In some embodiments, DPCAS 214 is simply configured to determine the appropriate authentication system used for authentication, which may be implemented by service provider 230, issuer, wallet provider, or other third party.

[0060] Additionally, service provider 230 may provide supplementary services, including but not limited to alert service 220 (e.g., one or more processes executed via or by server computer 212), which can generate and provide alerts to user 107 based on transactions occurring with user 107's account. For example, alert service 220 may analyze one or more transactions in user 107's account using one or more sets of alert rules configurable by user 107, and if any of these rules have a condition met (i.e., one or more rules are "triggered"), then alert service 220 may provide user 107 with an alert message indicating and / or describing the triggering of these rules. As an example, user 107 may configure a rule to be triggered when a transaction with a value exceeding a defined threshold occurs on their account (therefore, an alert message is provided). Service provider 230 may also provide token service 222, which can generate and / or store "tokens" (e.g., a first data value) associated with another potentially sensitive second data value. For example, token service 222 can generate and provide a token value for the account's main account (PAN) while maintaining a stored association (or mapping) between this token value and the PAN, so that token service 222 (or a restricted group of entities) can "translate" this token value back to the actual PAN, which provides enhanced security. Additionally, server computer 212 (such as when it is operated by payment processing network 105) can maintain / store transaction logs 224 of the financial transactions it processes.

[0061] In some embodiments, the issuing computer 106 may provide the service provider 230 server computer 212 with personal information about the user 107 associated with the issuing computer 106. For example, the issuing computer 106 may provide payment information, user information, account information, etc. In some embodiments, the service provider 230 server computer 212 may provide the issuing computer 106 with data related to the provisioning process. For example, if a payment token is generated for the user 107's account during the provisioning process (e.g., by token service 222), this payment token may be provided by the service provider 230 server computer 212 to the account's issuer 240.

[0062] Therefore, in one use case of system 200, user 107 can operate mobile device 101 to initiate a request for provision of a mobile application (e.g., a digital wallet application, which could be payment application 208C and / or secure payment application 206). This provision request can be sent to application provider 209 server computer 211. Application provider 209 server computer 211 can forward this request to service provider 230 server computer 212, specifically to provisioning service module 225. Provisioning service module 225 can generate provisioning scripts (e.g., one or more of partial personalization scripts, activation scripts, deletion scripts, etc.) using personalized data determined from issuer computer 106 and / or one or more databases and transmit these scripts to application provider 209 server computer 211. Application provider 209 server computer 211 can then initiate the execution of one or more of these scripts on mobile device 101. For example, application provider 209 server computer 211 can cause partial personalization scripts to be executed by mobile device 101. At the same or different times, the service provider 230 server computer 212 (e.g., provisioning service module 225) can authenticate the user, possibly using their DPCAS 214. Once a portion of the personalization script has been executed and the user 107 has been authenticated, the provisioning service module 225 can instruct the application provider 209 server computer 211 to execute an activation script on the mobile device 101 to complete the provisioning, thereby fully "installing" the payment credentials 207 set on the mobile device 101 for use.

[0063] In various embodiments, the authentication process is selectively utilized to avoid using additional authentications when they are not needed, while efficiently incorporating them when additional authentications are helpful.

[0064] It should be noted that any of server computers 211, 212, and / or 106 may be operated by the same or different entities or otherwise associated with the same or different entities. For example, in one embodiment, server computer 212 may be operated by payment processing network 105, while in some embodiments, DPCAS 214 may be operated by a third-party entity not shown or, for example, by issuer 240.

[0065] A. Payment voucher supply

[0066] To help understand Figure 2The illustrated entities depict an exemplary process for supplying payment account credentials 207 according to the present invention. User 107 can send a request for supply using a mobile application 208 running on mobile device 101. For example, in a payment application 208C (e.g., a digital wallet application), user 107 can request the supply of an account, credit card, or any other payment credential for mobile device 101. The supply request message may include device information such as a mobile device 101 identifier, a security element 202 identifier, a security element key identifier (or key), a user identifier (for identifying a user or account), and user authentication information (e.g., passwords, such as CVV2 for card-based authentication processes, ZIP codes for geo-authentication, etc.). Application provider 209, server computer 211, receives the supply request message and can perform risk detection or risk analysis on the requesting user 107, account, mobile device 101, or any other data present in or associated with the user account in the received supply request message. For example, risk verification may include determining how many times this user account has been supplied and how many accounts have been supplied on mobile device 101. Risk checks, for example, can indicate the likelihood that a request for supply is fraudulent. If the risk check indicates that the risk of the supply is acceptable, then application provider 209 server computer 211 can send the request for supply to the supply service module 225 executed on service provider 230 server computer 212. The supply request message may include any information contained in the message received from mobile device 101, and may include additional information determined by application 209 server computer 211, such as the master account (PAN) associated with the user's account and the reference number associated with the supply request.

[0067] The provisioning service module 225 may then attempt to verify the provided user authentication information. For example, if the provisioning request includes a PAN and a password, the provisioning service module 225 may retrieve the master encryption key, decrypt the password using the master encryption key, and ensure that this decrypted value is the expected value (e.g., corresponding to the received PAN value). The provisioning service module 225 may then generate a payment token to be provided on the mobile device using the token service 222. The payment token represents the PAN or other account to be provided on the mobile device and may include the actual PAN provided in the provisioning request, the generated token, the PAN serial number along with other items for identifying the account when used via the mobile payment application 208C. The payment token may be included in personalized data subsequently stored on the mobile device 101.

[0068] The provisioning service module 225 may then generate a partial personalization script, an activation script, and a deletion script, and send these "provisioning scripts" to the application provider 209 server computer 211 in a provisioning script message. The partial personalization script (or "perso" script) is operable to store personalization data on the mobile device 101, the activation script is operable to activate or allow access to the personalization data, and the deletion script is operable to delete or otherwise remove the personalization data from the mobile device 101. The provisioning script message may also include device information (allowing the application provider 209 server computer 211 to identify which mobile device 101 is associated with the provisioning script), a reference identifier (for a similar purpose), and a card pattern (which may be provided to the mobile device as a graphical representation of the provisioned account). In some embodiments, the provisioning script may be encrypted such that only the mobile device 101 or the secure element 202 of the mobile device 101 can decrypt the script. For example, the original request for provisioning sent by the mobile device 101 may include the public key (or shared key) of the secure element 202, allowing other entities to use this public key to encrypt a message that can then only be decrypted by the secure element 202 using the corresponding private key.

[0069] When the provisioning script message is received by the application provider 209 server computer 211, it can initiate the execution of that partial personalization script on the mobile device 101. This execution can be initiated, for example, by sending a partial personalization script message to the mobile device 101, the message including the partial personalization script and instructions (i.e., commands) to execute the script. Once received, the mobile application 208, the secure element 202, or another suitable element on the mobile device 101 can cause its processor to execute the partial personalization script.

[0070] The mobile device 101 can then send a partial personalization confirmation message to the application provider 209 server computer 211 indicating whether the partial personalization script has been successfully installed. This partial personalization confirmation message can be forwarded to the provisioning service module 225 of the service provider 230 server computer 212.

[0071] At an earlier or later time, the provisioning service module 225 may use DPCAS 214 to authenticate user 107. For example, the provisioning service module 225 may send an authentication request message to DPCAS 214. The authentication request message may include user authentication information (such as a PAN) provided by the mobile device 101 or the application provider 209 server computer 211, and may also include a reference identifier and device information. DPCAS 214 may then perform further risk assessment and authentication processes and determine whether the user is authenticated and authorized to supply mobile device 101. This may include performing detailed verification (such as whether user 107's account has previously been flagged as compromised) or analysis of past transactions (e.g., using transaction log 224). Thus, DPCAS 214 may determine whether user 107 is authenticated, unauthenticated, or may request additional information from user 107. For example, DPCAS 214 may cause the authentication request message sent to mobile device 101 to request additional user authentication data and then receive an authentication response message in return. Some examples of additional user authentication information may include answers to challenge questions, security questions, one-time passwords, etc. Finally, DPCAS 214 can provide an authentication response message back to the provisioning service module 225 to indicate the result of this authentication.

[0072] For example, when the provisioning service module 225 has determined that it has received a partial personalization confirmation message and has made an authentication decision, the provisioning service module 225 may send an activation message or a deletion message to the application provider 209 server computer 211. For example, if the partial personalization confirmation message indicates successful script execution and the authentication result indicates successful user authentication, then the provisioning service module 225 may send an activation message. Similarly, if the partial personalization confirmation message or the authentication result indicates failure, then the provisioning service module 225 may send a deletion message. The application provider 209 server computer 211 may then initiate the execution of an activation script or a deletion script by the mobile device 101, depending on whether an activation message or a deletion message has been received. The initiation of the execution of the activation script / deletion script can be performed in the same manner as the initiation of the partial personalization script as described above.

[0073] During script execution, mobile device 101 can then send a provisioning confirmation message to application provider 209 server computer 211, indicating whether activation or deletion was successfully performed, and this message can be returned to provisioning service module 225. Upon successful confirmation that the account has been provisioned and activated on the device, service provider 230 server computer 212 can fully activate the provisioned account by informing issuer computer 106 of this activation. For example, if a payment token was previously generated for the payment account, provisioning service module 225 can send a token association message containing the payment token and account PAN to issuer computer 106, indicating the associated token and PAN.

[0074] IV. Risk-based authentication for adapting to individual differences in voucher supply

[0075] As previously mentioned, a typical account credential provisioning process requires multiple messages between wallet provider 210 and provisioning service module 225 (or service provider 230 server computer 212). Furthermore, unnecessary delays are often incurred when authenticating users during provisioning, thus necessitating acceleration of the process for provisioning payment accounts on mobile devices (e.g., using secure elements) and providing a more efficient way to provision a large number of payment accounts across a large number of mobile devices 101. Additionally, enhanced authentication services are needed during the provisioning process, as some legitimate consumers may have questionable initial authentication results or may not be able to easily use typical authentication schemes. Therefore, an additional authentication process is required that does not interrupt or delay the provisioning process.

[0076] Embodiments of the present invention address these problems individually and collectively by using risk-based supply adapted to individual differences. Figure 3 A combined sequence and flowchart 300 illustrating an account supply system comprising low-risk and high-risk supplies according to some embodiments of the present invention are shown. As used herein, the terms “account supply,” “payment account supply,” “card supply,” “credential supply,” etc., may be used interchangeably to refer to the process of placing (or “installing”) information associated with user 107 and / or user account on mobile device 101, thereby enabling mobile device 101 to use this account to perform financial transactions, unless the distinction referred to is clearly derived from the usage of the term and / or its context.

[0077] The illustrated sequence and flowchart 300 shows messages sent between a group of entities and actions performed by that group. This group of entities includes mobile device 101, wallet provider 210, service provider 230, and issuer 240. In some embodiments, one or more computing devices (e.g., server computers) implement each of entities 210, 230, and 240. Therefore, for simplicity of understanding, the actions and messages illustrated herein are described with reference to higher-level entities. Additionally, in some embodiments, some entities are involved in performing this set of actions, while in other embodiments, fewer entities are used to perform the set of actions. Therefore, this illustration is merely illustrative of one possible embodiment and is not intended to be exclusive or limiting.

[0078] The illustrated process begins when user 107 first logs into the e-wallet application on their mobile device 101 at box 302 to request the provision of an account, credit card, or any other payment credential for the mobile device 101 for the first time.

[0079] However, in some embodiments, payment credential 207 may be installed on the mobile device even before the user attempts to activate, use, or otherwise supply the card. Therefore, the following process can occur automatically without the user's knowledge. At this point, the user can request the supply of the card credential on the mobile device, and at this point, there may be no further data to be sent to the mobile device, and the supplied account can be accessed by the user almost immediately. Therefore, embodiments can complete the card credential supply process even before the consumer requests the supply of a card instance on the mobile device. For example, user 107 can download a mobile wallet application on their mobile device 101 and can enter their registered username, identifier, card, etc.

[0080] At this point, wallet provider 210 can initiate the described process for all cards registered to the mobile wallet.

[0081] Therefore, the implementation can apply the supply script even before the user requests the supply of a specific card.

[0082] However, when user 107 provides wallet credentials to mobile device 101 at box 302, mobile device 101 (e.g., at the request of a mobile payment application) transmits credentials 350 to wallet provider 210. In the illustrated embodiment, upon confirming that credentials 350 are correct and for a valid account, a verification account message 352 for one or more accounts of user 107 (e.g., an API call to a card eligibility request) is transmitted to service provider 230. In some embodiments, this verification account message 352 includes one or more PANs (or other types of account identifiers) for the user's account, which may be provided by user 107 earlier (e.g., to the wallet provider) or may be provided by user 107 along with the credentials (i.e., at box 302) and sent together with wallet credential message 350.

[0083] Service provider 230 may verify the eligibility of the relevant account to which the credentials to be supplied are targeted for a PAN (or for one or more PANs provided in, identified by, or otherwise associated with the verification account message 352). In some embodiments, service provider 230 verifies eligibility at block 304, while in some embodiments, service provider 230 transmits an account eligibility request message 354 to issuer 240, and issuer 240 then verifies eligibility at block 306 and returns an account eligibility response message 356 indicating the eligibility of the account. In some embodiments, account eligibility request message 354 may include an indication of a risk value associated with the request, generated by service provider 230 or wallet provider 210, which allows issuer 240 to consider an additional factor when verifying the eligibility of the request.

[0084] For example, for a specific PAN, box 304 may include identifying the issuer 240 of the account (e.g., based on a Bank Identification Number (BIN)) and then determining whether the issuer 240 allows the provisioning to occur. Box 304 may also include utilizing a database of qualified and / or unqualified accounts (e.g., existing in an anomalous file listing those lost, stolen, or blocked accounts), which may be provided by the issuer 240. In some embodiments, this verification in box 304 may include performing a verification number calculation using the PAN based on an issuer verification number scheme to determine whether the account has been provisioned to a device (same or different device), etc. Similarly, the issuer 240 may verify the eligibility of an account at box 306 in various ways determined by configuration preferences, such as allowing all accounts to be provisioned, disallowing any accounts from being provisioned, or allowing only some accounts to be provisioned, which may be based on account history, the history of other accounts of the user at the issuer 240, whether the account has been previously provisioned, etc.

[0085] At this point, whether via box 304 or box 306, service provider 230 will have determined the eligibility of the account and will transmit an account eligibility response message 358 (e.g., send an API response message) to wallet provider 210, identifying one or more accounts and instructing each account on whether it is eligible for credential provision.

[0086] At box 308, if the account is ineligible, wallet provider 210 may transmit an ineligibility message 360 ​​to mobile device 101, which may cause this message to be presented to user 107 (e.g., via a display device) to indicate that the account is ineligible. Then, at box 310, the process ends, and user 107 may selectively try to start the process again for a different account.

[0087] If the account is qualified at box 308, the process continues, and wallet provider 210 sends an Enable Payment Inquiry Message 362 indicating account qualification. In response, user 107 and / or wallet application may cause another Enable Payment Inquiry Response Message 362 to be sent back to wallet provider 210 to indicate that user 107 is indeed seeking to “enable” the provision of payment credentials 207 associated with the account to mobile device 101 (i.e., to “add” their account to mobile device 101). This Enable Payment Inquiry Message 362 may also cause mobile device 101 to present the user with a set of terms and conditions that the user must accept to continue during this service activation phase.

[0088] Wallet provider 210 then transmits a CVV2 prompt message 264 to mobile device 101 in response to request input of further card information for the account (e.g., the CVV2 or CVV value of a credit card), which may prompt user 107 on mobile device 101. Upon receiving this card information (e.g., the CVV2 value) from user 107 at box 312, mobile device 101 transmits a supply request message 366, which may include the provided card information value (e.g., the CVV2 value).

[0089] In some embodiments, the supply request message 366 includes device information (for identifying the mobile device 101 and the secure element 202, and may include any unique identifier of the device to identify the required secure element key), consumer credentials (e.g., PAN and / or card verification value (e.g., CVV2 for a card-based authentication process)) and / or zip code (for a geographic authentication process). The supply request message 366 is sent by the mobile device 101 to the wallet provider 210, and a risk score may be generated at box 313 based on this supply request message 366 (or a "risk check" or "risk analysis" may be performed to generate risk assessment data). This risk analysis may be based on the requesting user 107, account, card, mobile device 101, or any other data present in the supply request message 366 (e.g., CVV2 value, zip code, user identifier, etc.) or any other data associated with the account of the user 107 submitting this supply request (e.g., previously registered / provided card data, determining how long the account has been open, how many cards this consumer has used or has used in total, the quantity of past purchases, etc.).

[0090] Assuming the identified risk is not excessive, wallet provider 210 sends a supply request 368 to service provider 230 (e.g., supply service module 225). The supply request may include device information, the primary account (PAN) associated with the account to which the view is being supplied, the expiration date, a CVV2 value entered by the user, a ZIP code, a time-sensitive token returned with the account eligibility response message 358 (i.e., one that will expire if the period has passed), or any other information that may be associated with the user account, as well as a reference identifier for the supply request.

[0091] In some embodiments, the supply request 352 may include a reference identifier (ID) for the PAN (or token) instead of the PAN itself. In some embodiments, this reference ID is pre-configured (or otherwise agreed upon) by both the wallet provider 210 and the service provider 230 so that both are aware of the mapping between the reference identifier and the PAN (or may be otherwise translated).

[0092] In some embodiments, at block 314, service provider 230 determines (or “assigns”) the requested risk (e.g., based on rules and / or data previously provided by issuer 240) to generate token activation response 372A. However, in some embodiments, service provider 230 identifies issuer 240 of the account (e.g., based on PAN) and transmits token activation request message 370 to issuer 240 (which may include a risk value instructing service provider to assign risk 314 and / or a risk value generated by wallet provider 210) so that at block 316, issuer 240 will determine / assign its own risk and return token activation response message 372B to service provider 230.

[0093] Similar to the account eligibility verification described above regarding boxes 304 / 306, the risk allocation at boxes 314 / 316 can be performed according to the implementing entity's preferences and therefore can be based on a variety of factors, including but not limited to: the existence and verification of the provided CVV2 value; whether the previously provided token is included in the supply request 352; whether the requested account has already been supplied on mobile device 101 or another device; whether the provided address can be verified as correct; account configuration data previously provided by user 107; wallet provider data (e.g., risk value); device information (such as its available hardware or software capabilities); fingerprints or other identifiers, etc.

[0094] In some embodiments, after sending the token activation request message 370, the service provider 230 may be configured to wait for the corresponding token activation response message 372B for only a period of time. In some of these embodiments, if the period expires, the service provider 230 may use its own generated risk assessment 314 result (i.e., token activation response 372A) to continue the process, and may optionally (not shown) transmit another message to the issuer 240 to identify what risk assessment 314 result it assigned and / or how the service provider 230 chose to continue. This embodiment allows the process to continue in a highly responsive manner to avoid the user 107 continuously waiting.

[0095] Regardless of the exact risk allocation plan in boxes 314 / 316, token activation response messages 372A / 372B can indicate the risk level. In some embodiments, at least three risk levels can be generated, including: “low” risk for unconditionally granting a supply request, “medium” risk for conditionally granting a supply request, and “high” risk for rejecting a supply request. The illustrated process varies based on these three risk levels.

[0096] At box 318, the service provider 230 determines which level of risk has been identified. As shown, box 318 includes identifying whether the risk level is "high," "medium," or "low." Of course, while in some embodiments the risk level may be explicitly categorized (and thus uniquely identify which risk category is determined), in other embodiments the risk level may take other forms (e.g., generating risk scores, such as risk scores being integers between 0 and 100, and therefore the determination of risk classification may include determining whether the risk score is within a certain range of values, whether it meets or exceeds a value, whether it is below a value, etc.).

[0097] Figure 3 The process is outlined to indicate how to proceed based on "high" and "low" risk levels. Figure 4 For a "medium" risk level, the procedure is shown as follows: Figure 3 The line leading to the bottom of the page and the label next to the circle 'A' " to Figure 4 As instructed.

[0098] If the risk level is marked as "high" at box 318, service provider 230 may transmit a supply request rejection message 374, indicating that this supply request message 368 has been rejected. In response, wallet provider 210 may transmit a rejection message 376 to mobile device 101, which presents the rejection message to user 107 and / or instructs user 107 to contact the account issuer (e.g., request the issuer to allow the account to be supplied). At this point, the "high-risk" process ends at box 320.

[0099] If the risk level is identified as “low” at box 318, service provider 230 can acquire token 322. In an embodiment, this token acquisition 322 includes: supply service module 255 requesting the token of the PAN from token service module 222 (which may be part of server computer 212 (as shown) or part of another device) by sending the PAN to token service module 222. Token service module 222 can then use various transmission technologies to generate and return the token, and may store the mapping between the token and the PAN for future transactions. For example, in an embodiment, the token may be created with the same size as the PAN (e.g., having the same number of digits), and have the same BIN value as the PAN (or another BIN value within the range of related BIN values). Token service module 222 (and / or supply service module 225) may store the token's serial number (e.g., 0 for the initial token creation of the PAN), the token's validity period (e.g., 24 or 36 months from the request date), and may set the token as an “active” token at box 324 by setting a value within its record or by modifying the token value itself.

[0100] At box 326, the provisioning service module 225 prepares message 376 and sends it to wallet provider 210. This message 376 includes a token (received from token service module 222) along with one or more provisioning script sets. In some embodiments, this message 376 includes one or more tokens (which may be encrypted), a token expiration date, a portion of the associated PAN (e.g., the last four digits), associated card metadata, a token reference identifier, a PAN reference identifier, a token returned with further messages, and / or a personalization script. Wallet provider 210 may then forward some or all of the information from message 376 (e.g., the provisioning script and the token) back to mobile device 101 in another message 378 to supply the account's token on mobile device 101 (by executing the script at box 328). In some embodiments, the provisioning script set includes a partial personalization script and an activation script, although in some embodiments, the functionality provided by the partial personalization script and the activation script is combined into one (or more) scripts.

[0101] At box 379, service provider 230 may transmit token notification message 379 to issuer 240. This token notification message 379 includes some or all of the information from message 376, including but not limited to: token, token expiration date, part or all of PAN, etc., to inform issuer 240 of the generated token.

[0102] Upon execution of the provisioning script received by mobile device 101 in message 378, mobile device 101 may return a token activation result message 380 to the wallet provider to confirm and / or deny whether the token (i.e., payment credential 207) was successfully provisioned (i.e., installed). Wallet provider 230 may forward this message 380 to service provider 230 in the token activation result message 381, and may further forward this message to issuer 240 as message 382.

[0103] Returning to box 318, if the assigned risk value is considered "medium" risk, the process continues to the bottom of the graph and leads to... Figure 4 . Figure 4 The illustration depicts some embodiments according to the present invention. Figure 2 The combination sequence and flowchart of medium-risk account supply in the account supply system 400.

[0104] Circle 'A' indicates the start of a "medium" risk process, where at box 402, service provider 230 acquires a token in a manner similar to the token acquisition described above in box 322 of the "low" risk process. Therefore, service provider 230 may produce a token, retrieve a stored token, or request a token from another entity (e.g., a third-party token provider service). At box 404, the token is set to inactive, which may include modifying the token (e.g., encrypting it), and / or modifying the supply script to set the token to inactive (i.e., currently unavailable for payment use by mobile device 101), such as by setting a flag within the memory location of mobile device 101 (e.g., setting a protection flag within the memory of secure element 202). At box 406, service provider 230 prepares one or more supply scripts, which in some embodiments include personalized scripts without an activation script.

[0105] In message 450, the supply script and inactive tokens are sent to wallet provider 210. Message 450 may include information such as... Figure 3 In the "low" risk process, message 376 describes some or all of the items in the project, specifically, it may include an inactive token indicator and / or a dynamic verification value delivery option that wallet provider 210 wants to obtain from user 107 (described below). Wallet provider 210 then forwards the supply script and the inactive token to mobile device 101 in a message, where the script is executed at box 407 to install the inactive token. Similar to message 379, service provider 230 may transmit token notification message 453 to issuer 240 to notify issuer 240 of the tokens produced and their mapping to the PAN.

[0106] In some embodiments, the mobile device 101 transmits a message (not shown) to the wallet provider 210 to indicate whether the installation of an inactive token was successful, and in response, the wallet provider 210 transmits a device provisioning result message 454 back to the service provider 230, which may then forward the device provisioning message 454 as message 456 back to the issuer 240.

[0107] At this point, based on the token being active and / or the wallet provider 210 needing an indication from user 107 (from message 450) to select a dynamic verification value delivery option, wallet provider 210 will send an inquiry message 458 to seek the user's preferred method of receiving the dynamic verification value (DVV). In some embodiments, this DVV serves as an element of an additional (or "enhanced") user authentication process, which can be used to increase confidence that the final supply of credentials is appropriate and therefore less likely to be fraudulent. In these examples, the DVV as a one-time password has been discussed; however, many other authentication methods may be employed, including but not limited to: performing a challenge / response test on the user via mobile device 101 (based on information previously provided or likely known by the legitimate user), having the user call a phone number (for example, the issuer's consumer service center phone number) to deliver a set of challenge / response tests, having the user submit a voice sample or other biometric sample (e.g., fingerprint imprint, iris scan, facial image, etc.) for identification, or another known authentication technology.

[0108] As an example, a set of delivery options for DVV may be presented to the user, including but not limited to: receipts via a mobile payment application, receipts via text message (e.g., Short Message Service (SMS) or other similar messaging service messages), receipts for making or receiving phone calls to obtain DVV (e.g., to a call center), receipts for DVV within emails sent to an email address on the user's file, etc. User 107 can select one of these options, and thus at box 408, mobile device 101 will receive the user's selected DVV delivery option and transmit a message 460 containing the selected delivery option to wallet provider 210, which forwards this delivery option to service provider 230 in another message 462 (e.g., in a "Send OTP" message). Furthermore, some or all of the delivery options may include obfuscated information, such as partially hidden / obfuscated phone numbers (along with one or more incorrect phone numbers) or email addresses.

[0109] In some embodiments, the service provider 230 will verify message 462 by performing one or more of the following: whether the token reference ID passed in the verification request is valid, whether the token is known to exist for the PAN mapping, whether the token has been previously supplied, whether the token is currently inactive, and whether the maximum number of OTP code attempts (permitted by the issuer) is met or exceeded.

[0110] At this point, several configurations exist for generating and / or validating DVV inputs. Although in Figure 6 Two other variants are then shown in the text. Figure 4The diagram illustrates a first DVV variant 420. However, in the first DVV variant 420, at box 410, the service provider 230 generates the DVV, which may include generating a random character / number / value of a certain length. For example, in one embodiment, the DVV is a randomly generated four-digit number. The generation at box 410 may further include setting an expiration date / time for the generated DVV, and / or setting a "retry count" indicating how many times a user can attempt to provide the DVV, both of which may be sent and / or stored.

[0111] In this first variant 420, service provider 230 transmits a consumer recognition request message 464 to issuer 240 (including the user-selected DVV delivery choice and the generated DVV). In some embodiments, if issuer 240 does not respond to the consumer recognition response message within a configured timeout period, service provider 230 may transmit an error message to wallet provider 210, instructing wallet provider 210 to send another message (e.g., message 462) after a specific amount of time.

[0112] Upon receiving the consumer authentication request message 464, the issuer 240 contacts the consumer 170 via the selected delivery selection mechanism (see message 466) to provide the generated DVV to the user 107. Thus, the selected delivery selection mechanism can be considered to utilize a second “channel” for communicating with the user (e.g., via SMS), as opposed to the first “channel” from the user’s mobile device 101 through the wallet provider 210 to the service provider 230.

[0113] At this moment, the DVV is provided to the user 107 according to the selected delivery mechanism, and the user can input the DVV into the mobile device 101 (e.g., via a mobile wallet application). The mobile device 101 receives the DVV input at box 412 and transmits the DVV to the wallet provider 210 in the DVV message 468.

[0114] At this point, wallet provider 210 may transmit account recovery message 470, which includes the entered DVV (from message 468) and the identifier of the corresponding account (e.g., PAN, reference ID, inactive token, etc.). Service provider 230 may verify account recovery message 470 by performing one or more of the following: verifying whether the token reference ID in message 470 is valid, whether the token mapping relative to the PAN is known, whether the token has been previously issued to wallet provider 210, and whether the token is in an inactive state, etc.

[0115] At box 414, service provider 230 then verifies the DVV based on a stored copy of the DVV (from when it was generated in box 410) or by generating a copy of the DVV (e.g., in embodiments where the DVV is generated based on a constraint and can be regenerated). In some embodiments, service provider 230 also verifies whether the DVV has expired based on the DVV submission time and / or verifies whether the number of times a user attempts to submit the DVV exceeds the configured allowed number of attempts.

[0116] If the DVV is not verified at box 414, there are several (not shown) options to continue, depending on the needs of the system implementer. In some embodiments, one of the DVV variants may be performed one or more additional times until the DVV is verified or the number of attempts is met. In other embodiments, the service provider 230 simply transmits an error code to the wallet provider 210.

[0117] However, when the DVV is verified (at box 414), the service provider 230 may update its records to indicate that the token is now active (e.g., update the token service module 222 for the token's maintained state), and may generate and / or provide an activation script to the wallet provider 210 in message 472, which is forwarded to the module device 101 as message 474. The mobile device 101 can then activate the token at box 416 by executing the token activation script, which may disable the token's protection flag (at box 418) or decrypt previously encrypted tokens (at box 419). In some embodiments, the mobile device 101 reports an indicator to the wallet provider 210 indicating whether the token activation was successful (for illustration, this may include an identifier for the account / token and a yes / no or other description of whether the token activation was successful or failed), and the wallet provider 210 then transmits a token activation result message 476 to the service provider 230, which may forward this result to the issuer 240. At this point, the "intermediate" process ends at box 422.

[0118] Figure 5 A process 500 for an account provisioning server computer is illustrated according to some embodiments of the present invention. In some embodiments, the operation of process 500 may be performed by service provider 230 server computer 212, while in some embodiments, the operation of process 500 is performed by provisioning service module 225.

[0119] Process 500 at block 502 includes receiving a provisioning request 207 on a first communication channel to provision a payment credential 207 of a user's account to a mobile device. The first communication channel may include a connection from service provider 230 server computer 212 to wallet provider 210. The provisioning request may include a PAN (Payment Approval Number) of the account, and in some embodiments may include a reference identifier for the PAN instead of the actual PAN itself. The account may be a credit card account, debit card account, checking or savings account, prepaid account, etc. Payment credential 207 may include one or more of the following: the account's account number, a token associated with the account, the expiration date of the token or account number, personal information associated with the account, public and / or private keys used to encrypt and / or decrypt information associated with transactions concerning the account, a card designation of the account (e.g., an image such as a depiction of an actual debit card or payment device), an identifier and / or name of the user associated with the account, an identifier and / or name of the issuer associated with the account, etc.

[0120] At box 504, process 500 includes determining the risk level associated with the supply request. This determination of the risk level may include performing risk verification or risk analysis on the requesting user, card, mobile device, or any other data present in the received supply request (e.g., CVV2 value, ZIP code, user identifier, etc.) or any other data associated with the consumer's account linked to the supply request (e.g., previously registered / supplyed card data, etc.). The model used for risk analysis may be configured according to the operator's expectations and may take into account historical information provided by the wallet provider in each request (e.g., how long the account has been open, how many times the consumer has used this card, the number or quantity of past purchases, etc.). The model may also combine payment processing network data on spending patterns on the account with network-level fraud trends (e.g., data compromise trends, common merchants / directories of spending).

[0121] At decision box 506, process 500 includes determining whether the risk level is below a predetermined risk threshold range, within the predetermined risk threshold range, or above the predetermined risk threshold range. In some embodiments, the risk level is set to "high" (i.e., above the risk threshold range), "medium" (i.e., within the risk threshold range), or "low" (i.e., below the risk threshold range). In some embodiments, the risk threshold range defines a range of values ​​describing at least three categories of risk values. For example, in embodiments where the generated risk values ​​are numbers between 0 and 100, the predetermined risk threshold range may be configured as [0025, 50], so any generated risk value score greater than or equal to 25 and less than or equal to 50 will be considered "medium" risk, any risk value above this range (i.e., greater than 50) will be considered "high" risk, and any risk score below this range (i.e., less than 25) will be considered "low" risk. Of course, other ranges / cutoffs can be used to configure other predetermined risk threshold ranges, and can be configured according to different types (e.g., integers, real numbers, letters, etc.) and schemes of generated risk scores.

[0122] In the illustrated embodiment, if the risk level is deemed to be below a predetermined risk threshold range (i.e., “low” risk), then process 500 includes supplying payment credential 207 to the mobile device at box 508. In some embodiments, this includes one or more supply script sets executed by the mobile device to supply payment credential 207 in an active state. In some embodiments, this transmission is made by a wallet provider as the destination, and the wallet provider then forwards this supply script set to the mobile device for execution. In some embodiments, the supply script set includes a personalized script containing account supply data and an activation script, which, when executed, supply account credential 207 in an active state (i.e., usable by the mobile device for payment transactions). In other embodiments, the supply script set includes only one script supplying account credential.

[0123] In the illustrated embodiment, if the risk level is deemed to be above a predetermined risk threshold range (i.e., "high" risk), then process 500 includes transmitting a supply request rejection message at block 510 indicating that the supply request has been rejected. In some embodiments, the supply request rejection message is transmitted to a wallet provider, which then forwards the supply request rejection message to the user's mobile device or otherwise transmits the message to the mobile device to indicate that the supply request has been rejected.

[0124] If the risk level in the illustrated embodiment is considered to be within a predetermined risk threshold (i.e., "medium" risk), process 500 continues, optionally optimizing the following at block 512: transmitting a supply script set to be executed by the mobile device to store the payment credential 207 in an inactive state on the mobile device. In some embodiments, the supply script set includes a personalized script that, when executed, supplies the payment account credential 207 in an inactive state that cannot be used by the mobile device. For example, in some embodiments, the supplied token is obfuscated (encrypted or otherwise transformed) to be invalid, and in some embodiments, a protection flag is set (e.g., within the security element 202 of mobile device 101) to prevent mobile device 101 from accessing the payment credential 207. In some embodiments, the execution of box 512 allows some credential provisioning work to be performed "early" (i.e., before the actual time when credentials are allowed to be activated). By allowing these potentially computationally expensive steps to be performed earlier and using a relatively computationally lightweight script executed later (e.g., at box 530) to activate pre-provisioned but inactive account credentials, the required workload can be allocated from a time perspective. However, in some embodiments, this box 512 is not executed, and all payment account credential provisioning subsequently occurs at box 526.

[0125] At box 514, process 500 includes having the authentication process performed by user 107. In some embodiments, this authentication process includes, at box 516, providing a Dynamic Validation Value (DVV) to the user via a second communication channel. In some embodiments, the second communication channel includes communication between the account issuer 240 and user 107, and may not include any direct communication between service provider 230 and user 107 or between service provider 230 and wallet provider 210. In some embodiments, this communication channel includes the issuer transmitting SMS messages, emails, making or receiving phone calls to the user, transmitting web pages to the user, etc. In some embodiments, the DVV includes a One-Time Password (OTP). In some embodiments, the OTP is generated by service provider 230, while in some embodiments, the OTP is generated by issuer 240. In some embodiments, service provider 230 server computer 212 generates (or obtains) the OTP and provides it (at box 518) to issuer computer 106, which manages the user's account, for delivery to the user. In some embodiments, the issuing computer 106 generates an OTP and transmits it to the user 107 (via a second communication channel) and the service provider 230 server computer 212 so that the server computer 212 can subsequently verify the user input of the OTP. However, in some embodiments, the issuing computer 106 generates an OTP but does not need to provide the OTP to the service provider 230 server computer 212. For example, the issuing computer 106 may generate an OTP according to a determined algorithm, such that the OTP can be regenerated using the same algorithm based on the server computer 212 for verification by the service provider 230 server computer 212. Therefore, at some point after providing the DVV to the user 107 via the second communication channel, the user 107 may return the DVV via the mobile device 101. This allows the mobile device 101 to send the input DVV to the wallet provider 210, which can then generate and provide a consumer verification response message containing the input DVV to the service provider 230 server computer 212 at block 520.

[0126] At box 522, process 500 includes determining whether the authentication process was successful. For example, this determination may include determining whether the DVV entered by the user in the consumer verification response message is a “correct” dynamic verification value. In some embodiments, this determination includes finding a stored copy of the DVV (e.g., generated by service provider 230, issuer 240, or a third party) and comparing it to the received DVV to determine if they are the same. In some embodiments, this determination includes generating a DVV using a DVV generation algorithm (e.g., one previously used to generate DVVs) and comparing the generated DVV to the received user-entered DVV. In some embodiments, when the user-entered DVV in the consumer verification response message differs from the “correct” DVV, the authentication process is indicated as a failure and the process continues to box 524, where an error message is sent. In some embodiments, this message is transmitted to wallet provider 210 and / or issuer computer 106.

[0127] However, in some embodiments, when the authentication process is deemed successful (e.g., the DVV provided by the user is the same as the "correct" DVV), process 500 proceeds to box 526, including supplying payment credential 207 to the mobile device. In some embodiments, this includes switching payment credential 207 (previously) supplied to the mobile device from an inactive state to an active state, which may include decrypting / deobfuscating the account's token, changing data protection procedures (e.g., within secure element 202), etc. In some embodiments, this supply includes transmitting an activation script executed by the mobile device at box 530. In some embodiments, the activation script is sent to wallet provider 210, which in turn provides the activation script to mobile device 101, causing the activation script to be executed so that payment credential 207 is installed / activated. In some embodiments, service provider 230 server computer 212 also receives a token activation result message 381 from wallet provider 210, indicating whether the supply was successful, and may forward this information 382 to issuer 240. In some embodiments, the service provider 230 server computer 212 may also transmit a token notification message 379 to the issuer 240 to notify the issuer 240 of the token and the account associated therewith.

[0128] V. A variant of generating and validating dynamic validation values

[0129] Figure 6 The diagram illustrates a combination sequence and flowchart of two dynamic verification value confirmation configurations 600A-600B in an account provisioning system according to some embodiments of the present invention. Figure 4The first DVV variant 420 is replaced by either the second DVV variant 600A or the third DVV variant 600B. However, these are only a few possible DVV variants, and other variants may or may not include features from these variants. The second and third DVV variants 600A-600B begin operation after the service provider 230 server computer 212 receives the DVV delivery selection message 462 from the wallet provider 210.

[0130] The second DVV variant 600A includes: (instead of as in...) Figure 4 In box 410, a DVV is generated. A DVV request message 650 (including a delivery selection indicated in DVV delivery selection message 462) is transmitted to issuer 240. Issuer 240 itself generates the DVV at box 602; provides the DVV to the user at box 466 according to the delivery selection on the second communication channel; and returns the generated DVV to service provider 230 in message 652. Service provider 230 may store this DVV at box 604. After the user receives the DVV on the second communication channel, the user inputs this DVV into mobile device 101 (e.g., using a mobile wallet application), and mobile device 101 sends the input DVV to wallet provider 210 in message 468. Wallet provider 210 then transmits a recovery account message 470 containing the DVV to service provider 230, which can determine the validity of the authentication by verifying the DVV at box 606. This involves comparing the stored DVV (from box 604) with the received user-input DVV (from message 470). If the values ​​match or are otherwise considered equivalent, the DVV is verified and authentication is successful; otherwise, the DVV is not verified and authentication fails.

[0131] The third DVV variant 600B is similar to the second DVV variant 600A, except for several key differences. First, in the third DVV variant 600B, the issuer 240 does not report the generated DVV back to the service provider (see message 652 in the second DVV variant 600A). Instead, when the service provider 230 receives a recovery account message 470 containing a DVV with user input, the service provider 230 can verify the DVV according to an algorithm at box 608. In some embodiments, the issuer 240 generates the DVV 602 using a specific algorithm known to the service provider 230, allowing the service provider 230 to either regenerate the DVV itself (using the same algorithm) or reverse the algorithm to "restore" the user-provided DVV value to the plaintext value, and then test this plaintext value to determine if it is correctly formatted. For example, in one embodiment, issuer 240 can generate DVV 602 by encrypting a plaintext value (using issuer 240's private key). This plaintext value could be based on a value associated with a user (e.g., the account's PAN, user identifier, etc.) and further based on the current date or time value (of course, many other possibilities exist for creating plaintext values, and this example merely illustrates one possible use case). Service provider 230 can then access issuer 240's public key to decrypt the user-provided DVV and determine whether the resulting plaintext value includes the correct PAN and the correct date / time value.

[0132] VI. Secure communication using consumer-specific encryption keys

[0133] In many of the disclosed embodiments, information flows between user 107 (and mobile device 101) and service provider 230 or issuer 240 via wallet provider 210. However, consumers have significant privacy concerns, and third parties (such as wallet provider 210) can often hold consumer data during transmission as it is transferred from the information source to the consumer. For example, a large amount of potentially sensitive financial / transactional data of user 107 flows through wallet provider 210. Therefore, sensitive data needs to be protected where a third-party system can route transaction alerts, transaction history, payment credentials, etc., to the consumer device (e.g., mobile device 101).

[0134] Providing encryption keys to the mobile communication device 101 is problematic when the service provider 230 (e.g., payment processing network 105) does not communicate directly with the mobile communication device 101, because the encryption keys are passed through a third-party computer (e.g., server computer 211) and the third-party computer can access and use the keys to decrypt future communications. Thus, the traditional method of delivering transaction history data to the mobile device 101 via a third-party server cannot be implemented using a TLS / SSL tunnel to adequately protect the data, as the TLS / SSL tunnel terminates at the third-party server computer, thus granting the third-party server computer unimpeded access to the data.

[0135] However, by incorporating a unique, consumer-specific key into a supply script (previously described regarding payment credential supply) designed to be supplied to the user's mobile communication device 101, the encryption key can be protected from interception by third parties because this script is encrypted using a security element key associated with a secure storage area on the security element 202 of the mobile communication device 101. Thus, the supply script is encrypted using a key inaccessible to a third-party computer, and the embedded consumer-specific key can be supplied to the security element during the personalization process of a mobile payment application with the user's payment token or other payment credential. Subsequently, the unique consumer-specific encryption key can be accessed through communication with the mobile payment application on the mobile communication device and used to decrypt encrypted communication information received at the mobile communication device.

[0136] Therefore, embodiments of the present invention provide enhanced security for sensitive data (e.g., transaction alerts, other consumer data, transaction history, etc.). For example, a third party with a specific consumer base may want to provide transaction alerts to its consumers but may not expect the third party to be able to view the data in the alert message, as this information can be considered confidential to consumers, and the third party may not want access to the transaction alert data. Embodiments of the present invention can incorporate encryption keys at both the data source (e.g., service provider 230 / payment processor 105) and the data destination (e.g., in the end user's mobile device 101). Thus, sensitive messages can be transmitted from service provider 230 through a third-party computer system (e.g., wallet provider 210 server computer 211) to the user's mobile device 101. The user's mobile device 101 may include encryption keys so that it can decrypt sensitive data.

[0137] Figure 7 A flowchart 700 is shown illustrating a combination of consumer-specific cryptographic key supply and secure message transmission via a wallet provider, according to some embodiments of the invention. In the embodiment illustrated here, asymmetric cryptography using public / private keys is used for data protection, although other obfuscation techniques may be similarly used in other embodiments.

[0138] Figure 7 A Consumer-Specific Encryption Key (CSEK) provisioning scheme 760 is illustrated to securely provide the CSEK for use. In this embodiment, mobile device 101 provides a Secure Element Encryption Key (SEEK) in message 750A, which may be a public key that allows other entities to encrypt messages and can only be read (i.e., decrypted) by the secure element 202 of mobile device 101 (e.g., using an associated private key). In other embodiments, this key is not associated with the secure element 202; instead, it is simply a public key associated with the private key of mobile device 101. Wallet provider 210 may forward this SEEK to service provider 230 in message 750B.

[0139] At box 702, service provider 230 may obtain or generate a set of consumer-specific encryption keys. For example, service provider 230 may generate a public key and a private key for use in communication with mobile device 101. This key may be...

[0140] Service provider 230 can then include a public CSEK and supply script in the package at box 704, and encrypt the package using the SEEK initially provided by mobile device 101. Therefore, even if this package is routed / forwarded through wallet provider 210 in messages 752A and 752B (and other potential computing devices of other entities), these entities cannot access the public CSEK or supply script in the package, as only mobile device 101 has the corresponding private key to allow it to "open" the package. It is particularly noteworthy that this package (in messages 752A and 752B) (containing the public CSEK) can be... Figure 3 and 4 The supply script generated / sent in any of them. For example, in box 326 (in Figure 3 The preparation of supply scripts in the "low" risk process may include preparing a package containing the scripts and common CSEKs. Similarly, for example, box 406 ( Figure 4 The preparation of the supply script and / or the transmission of the token activation script (see message 472) in the “medium” risk process may similarly include sending a public SEEK encrypted packet containing the supply script and / or the public CSEK. Of course, in some embodiments, the public SEEK encrypted packet may not include the supply script (e.g., such as when they do not contain sensitive information) but may include other data such as the public CSEK.

[0141] Turn back Figure 7Following CSEK provisioning scheme 760, the service provider 230 and mobile device 101 are thus enabled to communicate securely via the use of the CSEK key, without the wallet provider 210 or another entity knowing the transmitted data. For example, at box 716, the service provider 230 may generate a message such as an account warning message (e.g., based on a financial transaction event that violates configuration rules) or a transaction history message (e.g., listing one or more previous transactions of a user's account). The service provider 230 then uses its private CSEK to encrypt this message at box 718 to generate an encrypted message. This encrypted message can be sent from the service provider 230 to the wallet provider 210 as message 754A, and arrives at the mobile device 101 (as message 754B). The mobile device 101 can then decrypt the encrypted message using a public CSEK at box 720, which it may have received in an encrypted packet 752B as part of the receipt of the payment credential 207 provisioning script. The mobile device 101 can then utilize this message internally and / or display it to the user 107 at box 722. Similarly, at some point in time, mobile device 101 may use a public CSEK to encrypt a message intended for service provider 230 at box 720, and then securely transmit the message to service provider 230.

[0142] In some embodiments, encryption and / or decryption can occur at the secure element 202 of the mobile device 101 via a secure mobile payment application 206, which is embedded in or installed on the secure element 202 of the mobile device 101. By performing encryption / decryption at the secure element 202, the encryption key and information received in the message can be further protected from malicious third parties who may install malware in the general-purpose memory of the mobile device 101. Therefore, a more secure implementation of the encryption and decryption process can be achieved in some embodiments.

[0143] VII. Unique Transaction Identifier

[0144] Payment transactions originating from mobile device 101 provide consumers with convenient payment options, but can lead to incomplete and complex transaction processing and reporting issues. For example, mobile device 101 can only access partial transaction data at the time of transaction initiation; therefore, mobile payment applications 208C and 206 on mobile device 101 may not have access to the complete transaction details and may only have partial transaction logs 204. Consequently, payments initiated by the Near Field Communication (NFC) chip on mobile device 101 can result in several unsuccessful payment attempts due to complex radio frequency environments or outdated terminal software and / or hardware. However, when NFC payments fail, the information stored in transaction logs 204 on mobile device 101 may not match transaction information stored at different entities within the transaction processing system (e.g., transaction logs 224 at payment processing network 105, merchant 103, acquirer 104, issuer 240, etc.). Therefore, a method is needed to match transactions received at the back end of the transaction processing system with those initiated at mobile device 101. Thus, a method is needed to easily and efficiently identify unique transactions between the front end and back end of the transaction processing system. The various embodiments of the present invention address these and other problems individually and collectively.

[0145] One embodiment relates to a method for generating a unique transaction identifier on a mobile device 101 using a shared digest. This method includes initiating a payment transaction from the mobile device 101. The method continues with the steps of: selecting a transaction element associated with the payment transaction based on the shared digest, hashing the selected transaction element according to a predetermined hash algorithm, and concatenating the hashed transaction element. The unique transaction identifier is then stored in a transaction log 204. Another embodiment relates to a method for matching transactions using a unique transaction identifier. This method includes receiving an authorization request message for a transaction from the mobile device 101 and generating a unique transaction identifier for this transaction. The unique transaction identifier is generated using the shared digest and predetermined transaction elements in the authorization request message. A server computer (e.g., server computer 212) sends transaction matching information containing the unique transaction identifier to the mobile device. The mobile device 101 searches the transaction log 204 for transactions associated with the unique transaction identifier, identifies the transaction information associated with the unique transaction identifier, and updates the transaction log with the transaction matching information. Furthermore, other embodiments may relate to using the transaction identification technology described herein for several different purposes, including: transaction reporting, loyalty program monitoring, and any other purpose desired to match transaction data between front-end and back-end systems.

[0146] For these purposes, Figure 8A combined sequence and flowchart 800 illustrating the use of a unique transaction identifier for transaction log updates according to some embodiments of the present invention are shown. The illustrated embodiment relates to providing complete transaction information to a transaction log 204 located at a mobile device 101.

[0147] For example, at box 802, a transaction is initiated by mobile device 101 using a payment application. At this point, mobile device 101 can only access partial transaction information. At box 804, mobile device 101 generates a first unique transaction identifier (UTI) for the transaction according to an algorithm. At box 806, mobile device 101 stores the first UTI along with partial transaction information in the transaction log 204, which can be stored in "general" memory or memory accessible only by secure element 202.

[0148] Therefore, service provider 230 (e.g., payment processing network 105) server computer 212 receives an authorization request message or authorization response message at box 808. Service provider 230 generates a second UTI for the transaction at box 810 according to an algorithm, and this second UTI will have the same value as the first UTI generated by mobile device 101. Service provider 230 can update the transaction information in mobile device 101's transaction log 204 by sending transaction matching information (e.g., the second UTI) to mobile device 101 via messages 850 and 851 with complete transaction information (i.e., thus including "additional" transaction information not yet part of transaction log 204).

[0149] At block 814, mobile device 101 can identify a record in transaction log 204 for this transaction based on the received second UTI. In an embodiment, mobile device 101 performs this identification by searching within the transaction log for a record with a stored UTI that has the same value as the received second UTI. Upon finding a match, this record is selected as the transaction record, and mobile device 101 can update the record at block 818 based on additional transaction information received in message 851. Therefore, service provider 230 can use a shared digest (or index) to generate a unique transaction identifier, which both service provider 230 and mobile device 101 can use to identify the transaction associated with the transaction match.

[0150] Using a similar approach, embodiments of the present invention also enable mobile device 101 to report UTIs to service provider 230. For example, another embodiment allows service provider 230 to identify merchants with faulty or expired terminals (e.g., access device 102) by receiving information about unsuccessful transactions attempted by mobile device 101. Therefore, when service provider 230 receives an authorization request message in the transaction processing system, the server computer can generate a unique transaction identifier using a hash algorithm on the data elements in the authorization request message and can send the unique transaction identifier to the mobile device. Mobile device 101 can then identify the transaction associated with the received unique transaction identifier and can report any unsuccessful transactions since the last reported transaction to service provider 230. Thus, service provider 230 can determine the number of unsuccessful transactions, the merchants associated with these transactions, and any other relevant information from the transaction log.

[0151] VIII. Exemplary Computer Systems

[0152] The various participants and components described herein may operate one or more computer devices to facilitate the functions described herein. Figure 1-8 Any component, including any server or database, can use any appropriate number of subsystems to facilitate the functionality described herein.

[0153] Examples of these subsystems or components are in Figure 9 As shown in the image. Figure 9 The subsystems shown are interconnected via a system bus 902, which may include one or more buses. Additional subsystems are shown, such as a printer 910, a keyboard 918, a disk 920 (or other memory containing computer-readable media, including non-transient computer-readable storage media), a monitor 912 (or "display device") coupled to a display adapter 914, etc. Peripheral devices and input / output (I / O) devices coupled to an I / O controller 904 (which may be a processor or other suitable controller) can be connected to the computer system via any number of means known in the art, such as a serial port 916 (or a USB port, parallel port, etc.). For example, a serial port 916 or an external interface 922 can be used to connect a computer device to a wide area network (WAN) such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus 902 allows a central processing unit 908 (which may include one or more processing units, processor cores, combinations thereof, etc.) to communicate with each subsystem and allows control over the execution of instructions from the system memory 906 or the disk 920, as well as the exchange of information between the subsystems. System memory 906 and / or fixed disk 920 may include computer-readable media, such as non-transient computer-readable storage media.

[0154] Any of the software components or functions described in this application can be implemented as software code, which is executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (such as, for example, Java, C++, C, Python, JavaScript, or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as hard drives or floppy disks, or optical media such as CD-ROMs. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

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

[0156] One or more features from any embodiment may be combined with one or more features from any other embodiment without departing from the scope of the invention.

[0157] A reference to one (“a”, “an”) or the (“the”) is intended to mean “one or more”, unless specifically indicated otherwise.

[0158] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. Nothing is acknowledged as prior art.

Claims

1. A method for configuring payment credentials for a mobile device, comprising: The mobile device sends a first configuration request to a server computer to configure a first payment credential on the mobile device, wherein the payment credential is associated with a user's account, and wherein the first configuration request includes a first verification value associated with the first payment credential but does not include the first payment credential. When the risk level associated with the first configuration request is within a predetermined risk threshold range: The mobile device receives a first set of configuration scripts and a first token that is in an inactive state; The mobile device executes the first set of configuration scripts to store the first token in the inactive state at the mobile device. The mobile device stores the first token in the inactive state, wherein the inactive state does not allow the mobile device to use the first token for financial transactions before performing an authentication process on the user; In response to the successful execution of the authentication process, the mobile device receives an activation script; The activation script is executed by the mobile device to switch the first token from the inactive state to an active state that allows the mobile device to use the first token for financial transactions; A second configuration request is sent from the mobile device to the server computer to configure a second payment credential on the mobile device, wherein the second configuration request includes a second verification value associated with the second payment credential but does not include the second payment credential. When the risk level associated with the second configuration request is lower than the predetermined risk threshold range: The mobile device receives a second set of configuration scripts and a second token in the active state without requiring the user to perform an authentication process for the second configuration request; The mobile device executes the second set of configuration scripts to store the second token in the active state at the mobile device. as well as The mobile device initiates a financial transaction using the first token or the second token.

2. The method according to claim 1, further comprising: When the risk level reaches or exceeds the predetermined risk threshold range The mobile device receives a configuration request rejection message indicating that the configuration request has been rejected.

3. The method according to claim 1, wherein executing the activation script further comprises: The mobile device stores a protection flag associated with the payment credential in the mobile device's memory based on the execution of the first set of configuration scripts. The protection flag indicates the inactive state of the payment credential. as well as The mobile device disables the protection flag associated with the payment credential within the mobile device's security element.

4. The method according to claim 1, wherein: The authentication process includes providing the user with a dynamic verification value via a separate communication channel; and The successful execution of the authentication process includes the user providing a consumer verification response that includes the dynamic verification value.

5. The method according to claim 1, further comprising: The mobile device receives at least one of a set of consumer-specific encryption keys from the first set of configuration scripts or the second set of configuration scripts from the server computer. The mobile device receives encrypted communication messages from a wallet application provider, which are encrypted by the server computer using one of the set of consumer-specific encryption keys, wherein the wallet application provider does not have any of the set of consumer-specific encryption keys; as well as The mobile device uses at least one of the set of consumer-specific encryption keys to decrypt the encrypted communication message.

6. The method of claim 1, wherein the first set of configuration scripts or the second set of configuration scripts is encrypted using a security element key associated with a security memory region on the security element of the mobile device.

7. The method according to claim 1, further comprising: During the financial transaction with the trading entity, the mobile device sends the payment voucher in the active state to the trading entity.

8. The method of claim 1, wherein the first set of configuration scripts or the second set of configuration scripts is received by the mobile device before the user's account is activated.

9. The method according to claim 1, further comprising: The mobile device receives from the server computer a unique transaction identifier and additional transaction information relating to the payment voucher associated with the user's account; The mobile device identifies the transaction log record based on the unique transaction identifier; as well as The mobile device updates the record based on the additional transaction information.

10. The method of claim 1, wherein the configuration request includes a reference identifier of the user's account's primary account PAN instead of the PAN.

11. A mobile device, comprising: One or more processors; as well as A non-transient computer-readable storage medium communicatively coupled to the one or more processors and storing instructions that, when executed by the one or more processors, cause the mobile device to perform operations including: Send a first configuration request to a server computer to configure a first payment credential on the mobile device, wherein the payment credential is associated with a user's account, and wherein the first configuration request includes a first verification value associated with the first payment credential but does not include the first payment credential. When the risk level associated with the first configuration request is within a predetermined risk threshold range: Receive the first set of configuration scripts and the first token, which is inactive. Execute the first set of configuration scripts to store the first token in the inactive state at the mobile device; The first token is stored in the inactive state, wherein the inactive state does not allow the mobile device to use the first token for financial transactions before performing an authentication process on the user; In response to the successful execution of the authentication process, an activation script is received; The activation script is executed to switch the first token from the inactive state to an active state that allows the mobile device to use the first token for financial transactions; Send a second configuration request to the server computer to configure a second payment credential for the mobile device, wherein the second configuration request includes a second verification value associated with the second payment credential but does not include the second payment credential; When the risk level associated with the second configuration request is lower than the predetermined risk threshold range: Receive the second set of configuration scripts and the second token in the active state without performing an authentication process for the user to request the second configuration; Execute the second set of configuration scripts to store the second token at the mobile device in the active state; as well as Initiate a financial transaction using the first token or the second token.

12. The mobile device of claim 11, wherein the operation further comprises: When the risk level reaches or exceeds the predetermined risk threshold range Receive a configuration request rejection message indicating that the configuration request has been rejected.

13. The mobile device of claim 11, wherein executing the activation script further comprises: Based on the execution of the first set of configuration scripts, a protection flag associated with the payment credential is stored in the memory of the mobile device, the protection flag indicating the inactive state of the payment credential; as well as Disable the protection flag associated with the payment credential within the secure element of the mobile device.

14. The mobile device according to claim 11, wherein: The authentication process includes providing the user with a dynamic verification value via a separate communication channel; and The successful execution of the authentication process includes the user providing a consumer verification response that includes the dynamic verification value.

15. The mobile device of claim 11, wherein the operation further comprises: Receive at least one of a set of consumer-specific encryption keys from the first set of configuration scripts or the second set of configuration scripts from the server computer; Receive encrypted communication messages from a wallet application provider, which are encrypted by the server computer using one of the set of consumer-specific encryption keys, wherein the wallet application provider does not have any of the set of consumer-specific encryption keys; as well as The encrypted communication message is decrypted using at least one of the said set of consumer-specific encryption keys.

16. The mobile device of claim 11, wherein the first set of configuration scripts or the second set of configuration scripts is encrypted using a security element key associated with a security memory region on the security element of the mobile device.

17. The mobile device of claim 11, wherein the operation further comprises: During the financial transaction with the trading entity, the payment voucher in the active state is sent to the trading entity.

18. The mobile device of claim 11, wherein the first set of configuration scripts or the second set of configuration scripts is received by the mobile device before the user's account is activated.

19. The mobile device of claim 11, wherein the operation further comprises: Receive from the server computer a unique transaction identifier and additional transaction information relating to the financial transaction involving the payment voucher associated with the user's account; The transaction log records are identified based on the unique transaction identifier; as well as The record is updated based on the additional transaction information.

20. The mobile device of claim 11, wherein the configuration request includes a reference identifier of the user's account's primary account PAN, rather than the PAN itself.

Images