CN108780547B - Proxy device for representing multiple certificates - Google Patents

Abstract

A payment device and a system and method for securely managing financial transactions using the same are provided. In one embodiment, a portable proxy device includes a memory configured to store a plurality of credentials. Each of the plurality of certificates belongs to one of a financial certificate, an identification certificate, or a contract certificate. The portable agent device also includes at least one interface, wherein each of the at least one interface is configured to transmit one of the plurality of credentials to the external device to perform one of a financial function, an identification function, or a contract function.

Description

Proxy device for representing multiple certificates

Cross Reference to Related Applications

This application claims the benefit of U.S. provisional application US62/283769, filed on 9/10/2015, the entire disclosure of which is incorporated herein by reference.

Technical Field

The present disclosure relates generally to financial services, and more particularly to payment devices and systems for settling financial transactions.

Background

In the late 40 s of the 20 th century, plastic payment cards such as credit cards were introduced in the united states as a way of paying the most trusted customers of banks for meals and travel without carrying large amounts of cash. Since then, hundreds of thousands of banks have issued billions of payment cards.

However, many types of illegal activities pose a threat to the security of conventional payment card systems. Identity theft, impersonation, fraud, unauthorized account access, and other illegal activities compromise the integrity of the system. Conventional payment cards, as well as networks for authorizing and settling card transactions, are vulnerable to widespread attacks by identity thieves and other criminals. One primary form of payment account fraud is unauthorized use of details of a payment account in conducting electronic commerce. Another major form of payment account fraud is the production of counterfeit cards and use at the point-of-sale (POS) device of the merchant. These forms of fraud are inherent in the way the payment card itself is produced. In particular, credit card numbers and other payment account details printed or embossed on conventional plastic payment cards can be easily copied or stolen. In addition, the magnetic stripe of the payment card can be forged. In fact, the losses to banks, merchants and consumers caused by payment card fraud are rapidly increasing. Payment card fraud costs the industry approximately $ 200 million per year.

These activities are the source of major financial risks to banks and payment brands, and in order to combat counterfeiting and fraud, major card issuing networks have adopted new technologies to ensure that only legitimate cards are used at the physical point of sale. These technologies developed by the payment card industry and the issuing network alliance (EMVCo) add tamper resistant computer microchips with secure storage and computing capabilities to plastic cards. EMVCo is a payment industry consortium named EuroPay, masterCard and Visa, which was the original originator of the organization, but now also includes american express, discover, JCB and union pay as equity partners.

The microchip securely stores the information and programs needed to generate a unique cryptographic signature when a transaction is conducted at the merchant POS. The calculation process is performed securely and secretly inside the embedded microchip at each transaction and the results are passed along with the payment account data over the existing payment network to the issuing bank where they are verified using the same information stored in the card. The stored information is never disclosed by the issuing authority and cannot be extracted from the microchip by any practical means. The microchip embedded card thus provides a one-time code for each card transaction performed at the physical point of sale. If all merchants adhere to this new mechanism, the risk of being able to make counterfeit cards by misappropriating account data is largely eliminated.

Another way in which issuers attempt to combat fraud is to provide cards with Near Field Communication (NFC) components. A card that enables an NFC component allows a user to tap or swipe the card within about 10 centimeters of the NFC reader's proximity.

However, microchip embedded cards (also known as EMV cards or smart cards) as well as NFC enabled cards must also work in environments that have not adopted new standards. Many merchants have not adopted an EMV-enabled terminal or NFC reader that can read wireless communication signals that can activate a microchip card and read a password. To ensure widespread acceptance of payment cards, the issuing authority places a conventional magnetic stripe on the back of the card.

In addition, to enable e-commerce and telephone transactions, issuing authorities also set payment account numbers printed on cards and/or embossed in plastic. Thus, not only the microchip and NFC assembly may be used to conduct financial transactions, but the magnetic stripe may also be used for financial transactions using a POS swipe or the account may also be used for telephone or Internet transactions. The method by which the card communicates account information to the merchant terminal is referred to as a mode. In other words, the microchip card may be used in at least four different financial transaction modes including, for example, a magnetic stripe swipe mode, various modes using EMV chips, an NFC mode, and a manual card number entry mode. The microchip may also enable other modes, which is one reason that there may be more than four different financial transaction modes.

A thief who encounters one of these new EMV or NFC payment cards and even physically controls the card for a brief period of time can easily steal sensitive payment account data without regard to the embedded chip or NFC component. This may be done by reading the payment data from the magnetic stripe to prepare a counterfeit card. A thief may also steal data for fraudulent electronic commerce by taking a picture of the card to capture the card number. It should be noted that neither the magnetic stripe data nor the print data is protected by digital security means such as cryptography. The revealed data may then be used at less secure retailers who have not employed the EMV system, or a thief may go online for e-commerce transactions.

Therefore, a more secure payment card is needed. To address the above issues and improve customer satisfaction and control over the payment card experience, the present invention introduces several innovative elements for payment card and financial networks, as well as financial transaction authorization and settlement.

Disclosure of Invention

The present disclosure describes payment devices and related systems and methods for securely managing financial transactions using payment devices. The payment device may take the form of, for example, a portable proxy device, a plastic payment card, a virtual card, a wearable commerce device, one or more components embedded in a mobile device, an application running on a mobile device or computer, and other forms of payment credentials. According to one embodiment, a portable proxy device includes a memory configured to store a plurality of credentials. Each of the plurality of certificates is associated with one of a financial certificate, an identification certificate, or a contract certificate. The portable agent device further comprises at least one interface, wherein each of the interfaces is configured to communicate one of the plurality of credentials with an external device to perform one of a financial function, an identification function, or a contract function.

According to another embodiment, a system includes a point of sale (POS) device configured to obtain at least one certificate from a mobile agent device, each of the at least one certificate being associated with one of a financial certificate, an identification certificate, or a contract certificate. The system also includes a payment processor configured to receive the at least one certificate obtained from the mobile proxy device and to perform at least one of a financial function, an identification function, or a contract function.

The various embodiments described in this disclosure may include additional systems, methods, features, and advantages that may not necessarily be explicitly disclosed herein, but will be apparent to one of ordinary skill in the art upon examination of the following detailed description and accompanying drawings. It is intended that all such systems, methods, features and advantages be included within this disclosure and be protected by the accompanying claims.

Drawings

The features and components of the following drawings are illustrated to emphasize the general principles of the disclosure and are not necessarily drawn to scale. Corresponding features and components are designated by matching reference numerals throughout the figures for consistency and clarity.

Fig. 1 is a block diagram illustrating a payment system according to embodiments of the present disclosure.

Fig. 2A and 2B illustrate front and rear views, respectively, of a first payment device according to embodiments of the present disclosure.

Fig. 3A and 3B illustrate front and rear views, respectively, of a second payment device according to embodiments of the present disclosure.

FIG. 4 is a block diagram illustrating the account association apparatus shown in FIG. 1 according to embodiments of the present disclosure.

FIG. 5 is a block diagram illustrating the user account module shown in FIG. 4 according to embodiments of the present disclosure.

FIG. 6 is a diagram illustrating a proxy device representing multiple cards according to embodiments of the present disclosure.

Fig. 7 is a diagram illustrating a mobile proxy device representing multiple devices according to embodiments of the present disclosure.

Fig. 8 is a flow diagram illustrating a general use of the proxy device of fig. 6 and 7 to enable optional certificates according to embodiments of the present disclosure.

Fig. 9 is a flow chart illustrating a general use of the proxy device of fig. 6 and 7 in a default mode according to embodiments of the present disclosure.

Fig. 10 is a flow chart illustrating a detailed method of operation of the payment system 10 of fig. 1, in accordance with embodiments of the present disclosure.

Fig. 11 is a flow chart illustrating another detailed method of operation of the payment system 10 of fig. 1, in accordance with embodiments of the present disclosure.

Fig. 12 is a flowchart illustrating a financial information transmitting method of a financial transaction according to embodiments of the present disclosure.

Fig. 13 is a flow chart illustrating a method of operation of a tokenization process for user enrollment in accordance with embodiments of the disclosure.

Fig. 14 is a flow diagram illustrating a method of operation of a tokenization process for registration according to embodiments of the present disclosure.

FIG. 15 illustrates a transaction flow architecture according to embodiments of the present disclosure.

16-20 are flow diagrams illustrating an overview of a transaction flow process according to embodiments of the present disclosure.

Detailed Description

The present invention relates to payment devices, such as, for example, plastic payment cards, virtual cards, wearable commerce devices, components embedded in mobile devices, applications running on mobile devices or computers, and other payment credentials. The invention also relates to a system and method for conducting financial transactions using a payment device. The present invention may include commercially viable computing services, mobile applications, and websites, and may be implemented with issuers using the payment cards or other payment devices described herein. The present invention introduces several novel elements that can be employed by existing devices and valid certificate issuing authorities to counter various forms of fraud. The term "valid certificate" as used in this document refers to a valid funds scheduling tool that may include, but is not limited to, a credit card, a debit card, a direct deposit account, a savings account, a checking account, a membership card, a gift card, or other card or device.

The present invention includes a multi-mode payment device that can be used in various modes for different types of financial transactions. For example, the payment devices described herein may include multiple modes for completing a transaction. Some modes may include those involving a microchip embedded in the device, those involving Near Field Communication (NFC) components, those involving a magnetic stripe, those involving the entry of a device number and a Card Verification Value (CVV) in an online transaction, and/or other modes. The present invention includes a novel fraud reduction feature, a mobile phone application and an accompanying web site to control the novel fraud reduction feature. In addition, computing services may be used in both online and retailer authorization and settlement network services.

The current issuing practice of payment devices is to include a single master account number (PAN) detail of the user in all the various modes of the payment device (i.e., including magnetic stripe, EMV chip, NFC, etc.), which directly corresponds to the user's actual valid credentials. However, as described in this disclosure, by using a substitute account number or token in place of the Primary Account Number (PAN), an account association device may be inserted between the merchant and the issuing bank to complement the security of the transaction, or invoked by the issuing bank as part of processing the payment. The payment device system described herein securely replaces the user's PAN details in the network prior to transaction authentication and settlement. In this way, the user's PAN details are prevented from being revealed to the merchant.

The present invention uses multiple sets of different, anonymous and unpredictable substitute account details per payment device and/or per mode per payment device. In the example of a physical payment card, one set of substitute account details may be associated with one or more modes of the EMV chip, another set may be associated with another mode of the EMV chip, another set of substitute account details may be associated with the NFC component, another set for a magnetic stripe, another set for use in electronic commerce, and another set for manual input. Cross-mode payment fraud may be prevented using multiple different sets of alternate account details.

It is current practice to include the same PAN in an EMV chip that is contained in a magnetic stripe and printed on the device. Financial transactions are accepted when any of a variety of patterns occur, which makes cross-pattern fraud possible. For example, a thief may intercept EMV device details and generate a counterfeit magnetic stripe device. In addition, a thief may use the device data reader to collect EMV and magnetic stripe account details simultaneously and perform unauthorized e-commerce transactions. However, the invention is not limited to the same PAN being used for all modes. Rather, the present invention uses multiple sets of different alternate account details corresponding to multiple valid credentials, where each alternate account may be associated with a different schema. In this way, cross-mode payment fraud may be prevented.

It should be noted that the payment devices described in this disclosure may be implemented as credit cards, debit cards, virtual cards, wearable devices, internet of things (loT) devices, components and/or applications embedded in mobile devices, and/or other financial credentials. In other embodiments, the payment devices described in this disclosure may be applied to non-payment devices used in other environments besides commerce. For example, non-payment devices (e.g., loyalty cards, mobile devices, and other non-financial credentials) may be applied to other functions as a proxy certificate for electronically authenticating identity, such as for health insurance purposes, driver license purposes, etc., to access a secure location, provide visual identification of a user, and other uses. Further, valid credentials that may be associated with the alternate account details may be payment and/or non-payment credentials, such as membership credentials, health insurance credentials, and other financial or non-financial credentials.

Fig. 1 is a block diagram illustrating one embodiment of a payment system 10 in which an issuer 28 issues a payment device, such as a credit or debit card, to a user. In other embodiments, the user may use other types of proxy certificates other than payment cards, such as mobile devices. According to the embodiment of fig. 1, payment system 10 includes a public network 12, one or more user devices 14, one or more merchant terminals 16, one or more wireless communication antennas 18, one or more mobile devices 20, and an account association device 24.

The term "merchant terminal" is used to describe a physical terminal, website, or other device that provides functionality for a merchant that initiates a payment. The merchant terminal may be embedded in the POS device and may be "virtual" as in commerce website processing. Further, the merchant terminal may be a backend device that does not involve a device, card, customer, merchant, or goods, for example, when initiating recurring payments for services, the "merchant terminal" may represent a POS device, a merchant online system, and other mechanisms owned/controlled by the merchant to launch various modes of purchase. The merchant terminal may include any merchant system that uses one or more types of technology (e.g., EMV chip, magnetic stripe, NFC, e-commerce, etc.) for different payment modes.

Network 12 may include a wide area network, the internet, a private network, and/or other publicly accessible network. Moreover, network 12 may include a local area network associated with each merchant. Network 12 may also communicate with one or more cellular networks connected to antenna 18.

User device 14, merchant terminal 16, and antenna 18 may be connected to network 12 by one or more wired or wireless connection means to enable electronic communication between the various components. The wireless communication antenna 18 may include one or more cellular towers, orbiting satellites, or other wireless communication hubs for communicating with the mobile device 20.

The account associating means 24 may be a server, a web server, software running on a server, a hardware device, or any suitable intermediary computing device for providing various transaction services. The account associating means 24 is also connected to a network 26, which network 26 is also connected via wired or wireless connections to one or more issuers 28 and one or more databases 30. The network 26 may be a private network, a local area network, a Virtual Private Network (VPN), or a public network with a high level of encryption. The account association device 24 may be configured to store information in a database 30 that directs one or more alternate accounts to real accounts owned by the user or customer of the issuer 28.

During the purchase operation, the user to whom the payment device has been issued may use the payment device for payment of goods or services. The payment device may be presented to the merchant at one of the merchant terminals 16. It should be noted that multiple merchant terminals 16 may be associated with the same merchant to obtain account information through various modes. In practice, multiple merchant terminals 16 may be associated with a single device used by the merchant to obtain information at a single POS device. The POS device may obtain information from the payment device by utilizing a first mode of a microchip embedded in the device or by other modes, which may involve the use of an NFC component or magnetic strip on the device. In other transactions, such as online or telephone transactions, the device number printed and/or embossed on the device may be entered electronically or by a representative of the merchant's order.

According to an alternative embodiment, the payment system 10 may alternatively be configured as a system for performing non-payment actions. Instead of performing various functions related to financial accounts as disclosed herein, the non-payment system may process other types of credentials for entities other than the issuer.

The account association means 24 uses the database 30 to associate any alternate account data value into the details of the user's valid certificate details. Any alternative account data values and valid credential details may be provided by the user upon logging into the service provided by the account associating means 24. In one embodiment, the user may change the valid credential details associated with the alternate account at any time using a mobile application on one of the mobile devices 20 or using a web service provided by one of the user devices 14 via the account association device 24, the user device 14 may be a conventional computer or web browser. The account associating means 24 enables a plurality of valid certificates associated with a plurality of alternative accounts, the valid certificates being possibly financial certificates or non-financial certificates. In one embodiment, the account association device 24 associates valid credentials from the issuer 28 with a plurality of alternate accounts. In one embodiment, the account association device 24 associates valid certificates from the issuer 28 and other financial or non-financial institutions with a plurality of alternative accounts.

The account association device 24 is deployed into the payment system 10 such that all transactions presented by the merchant through one of the merchant terminals 16 are received by the account association device 24 for authorization against one of the multiple substitute accounts represented on each device. The account association device 24 associates a plurality of substitute accounts with one or more user valid credentials using a customizable rules engine that is sensitive to one or more facts including, but not limited to, current transaction data. The current transaction data may include, but is not limited to, for example, a merchant category code, a merchant ID, a transaction amount, an alternate account number, a service code, a device security code, and the like.

The account association device 24 may also access data through the database 30 including, but not limited to, previous transactions presented for a particular alternate account, previous transactions presented for another alternate account associated with the same user, previous transactions for other users of the same merchant or merchant location, geographic location of the user's primary mobile phone at the time of the transaction. The geographic location may be determined, for example, by Global Positioning System (GPS), and by a wireless communication device such as Wi-Fi ^TM 、Bluetooth ^TM Bluetooth low energy beacon and Zigbee ^TM 、Z-wave ^TM Or the range of the radio signal of any combination of these and other location sensitive factors. Alternative accounts may be associated with a valid certificate, which, unless otherwise associated, have no balance or established credit of their own, and cannot be used to settle any transaction.

The payment system 10 may be used to provide security for the use of payment devices. The payment system 10 may include a first merchant terminal 16 connected to the public network 12, wherein the first merchant terminal 16 is configured to obtain details of a first alternate account from a first set of information associated with a payment device owned by a user. The payment system 10 may include a second merchant terminal 16 connected to the public network 12, wherein the second merchant terminal 16 is configured to obtain details of a second alternate account from a second set of information associated with the payment device. In this embodiment, the payment system 10 further comprises an account association means 24 connected to the public network 12. The account association means 24 is configured to receive details of the first and second alternative accounts from the first and second merchant terminals 16, respectively. The account associating means 24 is further configured to associate the first and second alternative accounts with valid credentials belonging to the user. The account associating means 24 also manages financial transactions between the issuer 28 and the first and second merchant terminals 16, with the user holding valid credentials from the issuer 28. Furthermore, it should be noted that the first set of information is preferably different from the second set of information.

The payment system 10 may also include a third merchant terminal 16 connected to the public network 12, wherein the third merchant terminal 16 may be configured to obtain details of a third alternate account from a third and preferably different set of information associated with the payment device. In some embodiments, the first set of information is obtained from a microchip on the payment device, the second set of information is obtained from an NFC component embedded in the payment device, the third set of information is obtained from a magnetic stripe on the payment device, and the fourth set of information is obtained from a card number printed and/or embossed on the payment device. The first, second, third, fourth and other sets of information may be generated by an issuer. Some of this set of information may be manually entered into the merchant terminal.

An alternative embodiment includes a payment system 10 in which the payment device does not print and/or emboss an account number. Also, the payment device may not have a magnetic stripe or other mode. In this case, the user may use the payment device only at the merchant terminal, only the microchip and/or NFC component, or the remaining modes on the device.

Different sets of account details may be communicated to the user for online or telephonic transactions. The different sets of details may be mailed, emailed, or otherwise communicated to the user by a computer (e.g., user device 14) and/or via mobile device 20.

In some embodiments, a mobile device 20 associated with a user may be incorporated into the payment system 10. One of the merchant terminals 16 may be configured as an online merchant device that conducts online transactions, and the mobile device 20 may be configured to store, retrieve, or calculate a dynamic card verification value (d-CVV) generated from the account association device 24 that is sent to or manually entered into the online merchant device. In some cases, one or more merchant terminals 16 may be embedded within a point of sale (POS) device.

The user device 14 associated with the user is configured to enable the user to manage the alternate account and valid credentials via the account associating device 24. The account association device 24 is configured to enable a user to enter enrollment information, monitor activity of alternate accounts, enable and disable one or more modes of transactions with the payment device, alert if the payment device is lost or stolen, and provide information relating to various valid credentials. For example, the account association device 24 may provide a website that includes one or more web pages such that the user is able to browse the website using the user device 14.

Fig. 2A and 2B illustrate a first type of payment device 36 in accordance with embodiments of the present invention. Fig. 2A shows a front 38 of the payment device 36, while fig. 2B shows a back 40 of the payment device 36. The payment device 36 may include on its front side 38 the name 42 of the issuer 28, a microchip 44, a device number 46, a customer name 48, and an expiration date 50. In some embodiments, the device number 46 may be imprinted on the payment device 36. Additionally, the back 40 of the payment device 36 may include a magnetic stripe 52, a signature box 54, and a Card Verification Value (CVV) 56. The payment device 36 may further include an NFC component, possibly embedded below the surface of the payment device 36, for enabling contactless transactions.

In one embodiment, the payment device 36 may be a plastic EMV microchip card issued by an issuing bank according to an issuing rule of one of several global branded payment networks. The payment device 36 includes configuration and personalization such that it can be used at any EMV-enabled merchant POS.

However, the account details contained in the microchip 44 or other schema are not account details of the primary account number, but are arbitrary values generated by the issuer. The account details may be referred to herein as "substitute account details". The substitute account details serve as a substitute for a valid certificate, but are unable to identify any particular user. But instead refers to an alternate account generated by the issuer, but not associated with any particular valid certificate.

In the embodiment of fig. 2, microchip 44 and magnetic stripe 52 contain different payment account numbers, expiration dates and other token account details for two different alternative accounts. In short, the microchip 44 and magnetic stripe 52 appear to represent disparate payment accounts. A transaction performed at an EMV-enabled merchant using microchip 44 will contain account details that are different from transactions performed at merchants using magnetic stripe 52 on the same device 36. Further, the NFC transaction may use different payment account details than the EMV enabled mode and the magnetic stripe mode.

In one embodiment, the issuer 28 provides the customer with alternate account details for use in e-commerce and phone commerce transactions such that the details are different from the alternate account details of the microchip 44 or magnetic strip 52. It will be appreciated that fax, email, and other forms of electronic and telephone communication may also be used. It will also be appreciated that the substitute account details may be recorded on a mail order form for a transaction conducted by post. The e-commerce substitute account details may not be printed or embossed on the payment device 36 but may be provided separately to the user or may also be printed or embossed on the payment device, depending on the embodiment.

Fig. 3A and 3B illustrate a second payment device 60 according to embodiments of the present invention. Fig. 3A shows a front 62 of the payment device 60, while fig. 3B shows a back 64 of the payment device 60. Payment device 60 may include an issuer name 66 and a microchip 68 on its front face 62. It should be noted that the payment device 60 is devoid of the device number and user name that may typically be present on conventional payment devices. The back 64 of the payment device 60 may be blank or may simply include the name and address of the issuer. The back 64 therefore has no conventional magnetic strip and CVV number. The payment device 60 has no pre-printed account number, embossed account data, expiration data, user name, or other account data. By making the device anonymous and not including a human-readable account number, account data can be prevented from being easily stolen from the front and back of the device.

At present, visa ^TM And MasterCard ^TM Including the provision of cards and other devices issued in accordance with their franchise agreements, require the name and account number of the user to be displayed on the device. Thus, the embodiment of FIG. 3 does not follow these current rules. Nevertheless, the payment device 60 of the present invention can be carried in the open without risk of loss or theft, since the user's name and account number cannot be visually retrieved. For online, mail order, telephone, and similar transactions, it may be in the user's homeA separate device or electronic file is securely stored.

In some embodiments, the payment device 36, 60 may be formed from a plastic substrate ("card"). The first component (e.g., microchip 44) may be incorporated into the plastic substrate on the card shown in fig. 2 and 3. The first component may be configured to provide a specification of a first alternate account associated with a valid credential of a user. The payment card 36 of fig. 2 may also include additional components incorporated into the plastic substrate. The add-in component is configured to provide details of other alternative accounts associated with the user's valid credentials. The first alternate account includes details that are different from the second alternate account details and also different from all other alternate accounts. At least one of the first, second, or other alternate accounts is provided to the merchant (e.g., using merchant terminal 16) for a financial transaction with the merchant.

The merchant is configured to communicate the at least one substitute account details to the account associating means 24 via the network 12. The account associating means 24 is configured to associate the at least one alternate account with one of the user's valid credentials, and wherein the account associating means 24 is further configured to manage financial transactions between an issuer 28 associated with the user's primary financial account and a merchant terminal 16 associated with a merchant.

According to some embodiments, the payment device 36 of fig. 2 may further include other components (e.g., device number 46) incorporated into the plastic substrate. The device number may be printed and/or embossed on the plastic substrate. In alternative embodiments, the payment device (e.g., payment card 60) may lack at least one of a printed or embossed account number, magnetic stripe, and/or other pattern.

The details of the first, second and other alternative accounts may be read from the first, second and additional components by a point of sale (POS) device, such as merchant terminal 16. To conduct a financial transaction, some embodiments may include using a mobile device 20 associated with a user.

FIG. 4 is a block diagram illustrating one embodiment of the account association apparatus 24 shown in FIG. 1. In the embodiment of FIG. 4, the account association apparatus 24 includes a security module 74, one or more web pages 76, a user account module 78, one or more network interfaces 80, and a transaction authentication module 82. One or more network interfaces 80 are configured to enable communication over first public network 12 and also enable communication over network 26. The user account module 78 allows a user or customer to perform a number of different actions related to financial accounts and how the payment devices 36, 60 are used. The user account module 78 is described in more detail below with reference to FIG. 5.

The security module 74 may include a random number generator for generating a temporary dynamic card verification value (d-CVV). The d-CVV may be transmitted to the mobile device. And security module 74 may include an encryption engine for encrypting data transmitted over public network 12. The account association device 24 may be configured as a web server that allows one or more users to access information from the web page 76 and establish secure connections to enable the transmission of sensitive data (e.g., user information, device numbers, etc.). The transaction authentication module 82 is configured to authenticate financial transactions using the payment device 36, 60.

In one embodiment, the token account details are protected by encryption using an encryption key that may be provided by the security module 74. In one embodiment, the encryption key is derived from a user-created password. Rather, in another embodiment, the encryption key may depend on other data including, but not limited to, the identity of the mobile device 20, a user identification number known to the security module 74 of the account associating device 24, a country in which the user is registered with a computing service, a master key controlled by the user's biometric authentication, such as a fingerprint, iris scan, facial or voice recognition, or a biorhythmic pattern matching one or more body rhythms including, but not limited to, pulse rate, epidermal conductivity, iris size, blink rate, electroencephalogram, electrocardiogram, or other factors considered separately or jointly as individual biomarkers.

A typical plastic card may have a single three or four position CVV printed on the back or front of the card. Electronic commerce web sites now often require this value to ensure that the user has possession of the card. But because the CVV is a short number printed on the card, it is easily stolen along with the account data. Thus, this form of theft may be prevented using a dynamic CVV (d-CVV) that may be generated by the security module 74 at the time of the transaction and is applicable to only one transaction. In some embodiments, the generated d-CVV is not used for only one transaction, but may be applied to multiple transactions associated with a particular merchant, or may be used multiple times according to other criteria, such as a certain date range, a certain number of days of the week, a merchant area code, a purchase category, and so forth. According to some embodiments, a mobile application running on a mobile device 20 associated with a user may be configured to retrieve a d-CVV on demand. In another embodiment, a mobile application running on a mobile device 20 associated with a user may be configured to generate a d-CVV on demand. Alternatively, a website provided by the account associating means 24 may be used when the mobile device 20 is not available. Thus, in this case, the account associating means 24 may generate the d-CVV.

The payment system 10 may alternatively be applied for non-payment purposes in addition to use during financial transactions. For example, the payment system 10 may be used to replace some form of identifier with a token or alternative identifier. These identifiers may include social security numbers (in the united states), public health identification numbers, membership plans, other forms of account numbers where the use of a real number may present a risk of leakage, identity theft, or other fraud.

The account association device 24 may also find application in providing limited transactional access to protected record groups, such as medical record requests, laboratory results, credit inquiries, professional permissions, business permissions, and other forms of relying party inquiries utilizing government or enterprise issued identification account numbers.

The payment system 10 may also be used for transactions for some non-payment purposes, including driver's licenses, border control documents, building and resource access cards, and gift cards. In this embodiment, the payment device 36, 60 may use one or more modes of non-payment use while still using one or more modes of payment transactions that use separate alternate account details for the different modes.

In some embodiments, account association apparatus 24 may include at least one network interface 80, the network interface 80 configured to communicate with a plurality of merchant terminals 16 via first public network 12 and with issuer 28 via network 26. For example, the issuer 28 may be a bank that issues payment devices 36, 60 to users. The account association apparatus 24 may also include a transaction authentication module 82, the transaction authentication module 82 configured to authenticate a first financial transaction for a first merchant terminal of the plurality of merchant terminals 16 based on a first set of details obtained by the first merchant terminal of a first alternate account associated with the user-owned payment device 36, 60. The transaction authentication module 82 may be further configured to authenticate a second financial transaction for a second merchant terminal of the plurality of merchant terminals 16 based on a second different set of details obtained by a second merchant terminal of a second alternate account associated with the user-owned payment device 36, 60.

The transaction authentication module 82 may be further configured to determine whether the substitute account corresponds to a valid user credential. The transaction authentication module 82 may be further configured to determine whether the received substitute account details correspond to substitute account details for an expected mode of payment device usage. The transaction authentication module 82 is further configured to manage financial transactions between the issuer 28 and the first and second merchant terminals 16. The transaction authentication module 82 is further configured to obtain other sets of details, authenticate other financial transactions for other ones of the plurality of merchant terminals 16, based on other merchant terminals of other alternative accounts associated with the primary account of the user-owned payment device 36, 60. The first set of details may be obtained from microchip 44 on payment device 36, 60, the second set of details may be obtained from magnetic stripe 52 on payment device 36, and the third set of details may be obtained from account number 46 printed and/or embossed on payment device 36.

The network interface 80 may be further configured to communicate with a remote device (e.g., the user device 14 or the mobile device 20) associated with the user via the network 12. The network interface 80 may be further configured to receive instructions from the remote device 14, 20 to enable a user to manage a primary account associated with the payment device 36, 60, wherein managing the primary account includes at least one of: entering registration information 86, monitoring activities 94 of the primary account, enabling and disabling one or more modes of transactions 90 through the payment device, reporting 92 that the payment device has been lost or stolen, and providing information 88 regarding the first and second alternate accounts.

FIG. 5 is a block diagram illustrating one embodiment of the user accounts module 78 shown in FIG. 4. In this embodiment, the user account module 78 includes a registration module 86, a provisioning module 88, an enablement module 90, a reporting module 92, and a monitoring module 94. The user may access the user account module 78 using a mobile application running on the user's mobile device 20, or by accessing a website provided by the account association device 24 using the user's user device 14.

The user account module 78 enables the user to create and manage rules that the account association device 24 enforces on behalf of the user. Such rules may be sensitive to one or more facts known to the user, including but not limited to payment value, merchant ID, local time and date encoded in the transaction message, distance between the registered location of the merchant at the time of the transaction and the geographic location of the user's mobile device, local currency of the transaction, country from which the transaction originated, country in which the merchant is established, whether the transaction is presented as a magnetic stripe transaction, an EMV transaction, or an e-commerce, phone, or mail order transaction, and user authentication methods such as, but not limited to, one or more of entering a Personal Identification Number (PIN) code into a merchant POS terminal, signing a receipt, entering a password into a mobile device, and fingerprint or other biometric methods.

The registration module 86 may be configured such that a user (which may be, inter alia, a cardholder, a valid certificate holder, or an individual appropriately approved by an issuing authority) may register other alternative accounts and other valid certificates. The enablement module 90 may be used to allow a user to engage in various uses, enable or disable certain modes or types of transactions, according to various criteria that the user may be based on, or to allow the user to enable or disable a particular transaction on their own prior to authentication. Enablement module 90 may be used to allow a user to choose which valid certificate to pay for in a variety of scenarios or criteria. The reporting module 92 allows the user to report if the payment device 36, 60 is lost or stolen. One embodiment of the reporting module 92 may enable the account-associating device 24 to manually or automatically report relevant information to the user or issuer 28, including reporting all alternate account details and/or potential fraudulent activity on the payment device. The monitoring module 94 allows the user to view previous transactions to monitor all activity of the device.

The provisioning module 88 may allow a user to differentiate between a plurality of different sets of alternate account details, respectively.

Conventional device issuing systems may assume that certain data elements are shared between the microchip, the magnetic stripe, and the printed/embossed account number. However, in contrast to conventional device publishing systems, the provisioning module 88 allows separate data elements to be used to provide each of these schemas, as well as additional elements and/or schemas. The provisioning module 88 is configured to separately identify these multiple different sets of alternative account data, which may be stored in a common provisioning data file transmitted during the card or device provisioning step.

If the payment device 36, 60 is lost or stolen, the user may be exposed to unauthorized use of the payment device. However, while in some countries a thief may be able to make purchases using the NFC functionality within a certain spending threshold (e.g., $ 100), the thief is typically unable to use the EMV functionality of the device without the user's PIN code, which may be entered during the provisioning process using the provisioning module 88. Moreover, stolen devices cannot be used for electronic or telephone transactions due to the different account details of the separate transaction patterns.

The provisioning module 88 may further include receiving user identification information not printed on the payment device 36, 60. According to some embodiments, the provisioning module 88 may set the usage rules for the user using the payment device 36, 60 by requiring the user's mobile device 20 to be presented at the time of the transaction. Additionally, the mobile application of the mobile device 20 may also be used to immediately block transactions for stolen devices reported stolen by the reporting module 92. Unless the user unlocks each time using the mobile application on the mobile device 20, the user account module 78 may configure its rules to block the magnetic stripe transaction. The latter approach will effectively prevent the use of counterfeit magnetic stripe devices. The user account module 78 may also configure its rules to block transactions from any and all of the different modes, or to block transactions that meet certain criteria, unless the user unlocks these transactions each time.

In one embodiment, a mobile application is available on the user's primary mobile device 20. The user may use the mobile application to register an alternate account or valid certificate with the account association device 24, control the provision of valid certificates or the association with one or more alternate account details supplied to the payment device. The mobile application also allows the user to enable or disable authorization for transactions presented through any substitute accounts on the plastic payment device, report that the payment device is lost or stolen, and report other authentication factors for sensitive or high value or high risk transactions.

The mobile device 20 may also store in memory alternate account details, which may be associated with "card present" and "card not present" transactions. These alternate account details may be stored in memory and may be recalled by the user by entering a password and/or another authentication factor into mobile device 20. As a means for interacting with an e-commerce web site, the mobile application securely saves e-commerce substitute account details and displays them to the user upon proper authentication with a password, biometric, and/or other factors. In another embodiment, the alternate account details are transmitted by the account associating device 24 and received by the mobile device 20, and may then be recalled by the user by entering a password and/or another authentication factor into the mobile device 20.

Fig. 6 illustrates an example of a proxy device 100 configured to represent multiple valid certificates 102a, 102b. The details of each valid certificate 102a, 102b.., 102n are combined into a single proxy device 100, which single proxy device 100 may then be used to replace any valid certificate 102a, 102b.., 102n. Valid credentials 102 may be credit cards, debit cards, loyalty cards, membership cards, identification cards, health insurance cards, gift cards, and other cards that include account information, identity information, and other types of data. During use, a user picking up a single proxy device 100 may select any set of valid certificates to use normally as if the actual valid certificate 102 were presented. In some embodiments, proxy device 100 may include one or more microchips, one or more contactless circuits (e.g., NFC circuits), magnetic stripes, printed and/or embossed substitute account numbers, and/or CVV codes. Agent device 100 may also include printed information identifying the user, such as the user's name and contact information.

Fig. 7 illustrates one example of a mobile proxy device 104 that may be configured to represent any number of valid certificates 102a, 102b. Instead of being configured in the form of a credit card, the mobile proxy device 104 may instead be implemented as a mobile phone, a smart phone, a tablet, a wearable mobile device, or another suitable processor-based mobile device. In some embodiments, the mobile proxy device 104 may include software and/or firmware that is downloaded into existing mobile phones, smart phones, tablets, wearable mobile devices, and the like. During use, the mobile proxy device 104 may tap on an NFC enabled reader or otherwise use in accordance with other methods described in this disclosure.

FIG. 8 is a flow diagram illustrating one embodiment of a method 110 for enabling transactions that exceed a predetermined threshold. For example, the threshold may be established by the user or by the issuer based on preferences or based on predetermined rules for the financial stability of the user. In one example, the threshold may be set at $ 100. Thus, any pending financial transaction that exceeds $ 100 will execute the method of FIG. 8.

In operation, the reading step (1) is performed between an agent device (e.g., agent card 100 or mobile agent device 104) and a reader 112 associated with a merchant. The reader 112 may be one embodiment of the merchant terminal 16 shown in FIG. 1. The reading step (1) involves giving the agent device 100,104 to a cashier or the customer himself using the agent device 100, 104. The agent devices 100,104 are swiped across a magnetic stripe sensor of the reader 112, tapped on an NFC sensor of the reader 112, inserted into a chip slot of the reader 112, or otherwise operated to enable the reader 112 to read financial information stored in the agent devices 100, 104.

In step (2), the Bank Identification Number (BIN) associated with the agent device 100,104 is sent to the payment processor 114, which payment processor 114 may be a third party representative, for processing various credits and debits of the acquiring bank associated with the merchantAnd (6) trading. For example, the payment processor 114 may be a suitable processor for processing a single card or proxy device. In step (3), authorization is performed, which includes payment processor 114 flagging the user's payment for payment by authorization module 116 (such as a padloc) ^TM Or another authorization module). The transaction details are sent to the authorization module 116, and the authorization module 116 may include an application that has been downloaded to the user's mobile device 20. In some embodiments, the mobile device 20 may be the same device as the mobile proxy device 104, both for initiating transactions (step (1)) and for receiving authorizations (step (3)).

Step (4) of the method 110 includes communicating with the user to receive a selection of one of the plurality of valid certificates 102 represented by the single proxy device 100, 104. The authorization module 116 receives the user's selection and any PIN code or other security code required to complete the transaction. In step (5), authorization module 116 includes securely retrieving the details of the selected certificate from certificate selection database 118.

In step (6), the authorization module 116 sends the payment information with the BIN code to the issuer of the selected card. The payment processor 114 receives the payment information and BIN code information and sends the information to the appropriate issuer to process the payment (step (7)).

FIG. 9 is a flow diagram illustrating another embodiment of a method 120 of enabling transactions below the predetermined threshold described in FIG. 8. According to the above example in which the threshold is set at $ 100, any pending financial transaction below $ 100 would execute the method of FIG. 9. In this embodiment, the user may pre-select a valid credential to be used when the transaction is below the threshold. In this way, smaller transactions may be simplified without requiring some of the additional steps described in FIG. 8.

The device shown in fig. 9 may be the same as the device in fig. 8. Also, steps (1) and (2) of fig. 9 are the same as fig. 8 and are not repeated here. However, step (3) involves sending the identified user payment preferences and retrieving the selected valid credentials from the credential selection database 118. Step (4) includes sending payment information with the BIN code to the payment processor 114 for the preselected issuing authority of the valid certificate. Step (5) includes processing the payment as usual.

FIG. 10 illustrates one embodiment of a method 130 of operation in accordance with the present invention. The user uses the agent card 100 (or mobile agent device 104) to conduct a transaction at a point-of-sale (POS) device 132. POS device 132 transmits encrypted financial messages that conform to at least one financial transaction standard including, for example, ISO8583, ISO 20022, and AS 2805. The encrypted message is received by the merchant acquirer 134, the merchant acquirer 134 may be configured to decrypt the message and re-encrypt the message for the payment switch 136, and the payment switch 136 may be configured to process the encrypted and/or tokenized financial transaction message. The encrypted financial transaction message may be stored in the encryption database 138.

The payment switch 136 is configured to forward the original encrypted message from the merchant acquirer 134 to the transaction vault of the transaction server 142 for tokenization. The transaction vault of the transaction server 142 decrypts the original message and sends the tokenized message back to the payment switch 136. The transaction rules engine 140 may be configured to exchange proxy tokens as target certificate tokens. Also, the transaction rules engine 140 may be configured to edit rules as needed.

The payment switch 136 then provides the selected valid certificate and the requested transaction compilation token to the transaction guardian 146 of the transaction server 142. The transaction guardian 146 and transaction rejection rules are used to validate the rules to take allowance, denial or other actions on the submitted transaction. If the transaction is allowed, the transaction guardian 146 passes the original message to the target token according to the editing rules. The transaction vault of the transaction server 142 returns encrypted and edited transaction messages to the payment switch 136. The payment switch 136 then encrypts the message and sends the encrypted message to the merchant acquirer 134.

Figure 11 is a flow diagram of one embodiment of a method 160 for securely storing and enabling access to valid credentials via a proxy device. The method 160 includes loading valid certificate details into a data store 162 of the account association device 24 using the proxy device (proxy card 100 or mobile proxy device 104). The valid credential details may be obtained using a magnetic swipe reading or any other means to obtain the substitute account details from other modes of the payment device. The substitute account details associated with the used mode are sent to the certificate management device 164. The certificate authority 164 is configured to send the encrypted swipe data to the certificate means 180 of the certificate transfer means 174 of the issuer 172.

The payment switch 166 exchanges inbound data 168 with a tokenization apparatus 176 of the credential transfer apparatus 174 and outbound data 170 with a decryption apparatus 178 of the credential transfer apparatus 174. The certificate transfer device 174 also exchanges encrypted certificate data with a data store 186 that stores the data in encrypted form. The certificate transfer means 174 also exchanges the decrypted certificate decrypted by the decryption means 178 with the certificate data store 182. The key from key cache 184 is provided to certificate transfer device 174. The keys may include a pane (pod) specific credential data storage key, a derived tokenization key, and a swipe key. The high speed memory HSM188 provides the swipe key, the per pane CMAC, the pane specific storage key, and the derived tokenized key to the key cache 184.

Fig. 12 is a financial information transmitting method 196 for a financial transaction. The acquirer 198 sends an ISO8583 message or other message type to the upstream channel 200. The upstream channel 200 sends an ISO 20022 message (canonical) to the switch 202. The switch 202 sends the PAN and expiration information to the tokenization pane 204 of the account association device 24. Tokenization pane 204 sends the PAN and token back to switch 202. The switch 202 then sends ISO 20022 (white list key) to the mapping pane 206 of the account association device 24. The mapping pane 206 compares the mapping and sends a mapping action back to the switch 202, and the switch 202 then applies the mapping action. The switch 202 then sends the mapped PAN token to the decryption pane 208 of the account association device 24. The decryption pane 208 then sends the decrypted credential data back to the switch 202.

The next few steps may be optional in some embodiments and may involve a log sending function when associated with an atomic ID. The switch 202 sends the mapped and sanitized mapped 20022 message to the log pane 210 of the account association device 24. The journal pane 210 sends a confirmation message back to the switch 202. Switch 202 then sends the mapped 20022 message to downstream channel 212. The downstream channel 212 then sends the mapped 8583 message or other message type to the issuer 214.

The issuer 214 sends a response to the ISO8583 message or other message type back to the downstream channel 212. The downstream channel 212 sends a response 20022 message to the switch 202, and the switch 202 then applies the inverse of the cached mapping.

The next few steps may also be optional and may involve a log sending function when associated with an atomic ID. As described above, the switch 202 sends the mapped and sanitized mapped 20022 message to the log pane 210, and the log pane 210 responds with an acknowledgement signal. In this embodiment, the switch 202 then sends a 20022 message to the upstream channel 200, and the upstream channel 200 sends a 8583 message or other message type to the acquirer 198.

Fig. 13 is a method 220 of operation of a tokenization process for user enrollment. The user 222 uses the swipe 224, the swipe accessory 226 connected to the mobile device 228, and/or the mobile device 229 to obtain valid credentials. The encrypted card information is sent to a network service 230, such as the account associating means 24. The web service 232 includes an enrollment Application Program Interface (API) 234 and a tokenizer 236. Registration API 234 allows a user to register one or more certificates to associate a certificate with a proxy device 100, 104. The tokenizer 236 assigns tokens to certificates. The enrolled certificates and tokens are stored in a database 238, such as database 30 shown in fig. 1. Also, exchange cache 240 may be used to store a mapping of tokens to corresponding credentials.

Fig. 14 illustrates a method 250 of operation of a tokenization process for registration. The user 252 may create an account with a financial institution or issuer 254. During the registration process, customer data is securely sent 256 from the issuer 254 to the account correlation device 258 or other network server. The account association device 258 may correspond to the account association device 24 shown in FIG. 1 and includes a registration API 260 and a tokenizer 262. Registration and token data is stored in database 264 and exchange cache 266.

Fig. 15 is a transaction flow diagram. In a first embodiment of the process, a user presents payment device 100 at a first merchant 302 of a plurality of merchants. First merchant 302 initiates a payment transaction using the first account details from user payment device 100 and sends the financial transaction to acquirer 306. The acquirer 306 sends the financial transaction to the issuer processor 310. The acquirer 306 may optionally use the scheme 308 to send the financial transaction to the issuer processor 310. The issuer processor 310 sends the financial transaction to the account association device 312, and the account association device 312 maps the first substitute account details to the first valid certificate and sends the financial transaction to the issuer of the first valid certificate 316. The account associating means 312 may optionally send the financial transaction to a scheme 314, which in turn sends the financial transaction to an issuer of the first valid certificate 316. The response from issuer 316 follows a reverse path to merchant 302. In a second embodiment of the process, a user presents payment device 104 at a first merchant 302 of a plurality of merchants. The second merchant 304 initiates a payment transaction using the second account details from the user payment device 104 and sends the financial transaction to the non-partner acquirer 320. The non-partner acquirer 320 sends the financial transaction to the issuer processor 310 using the schema 308. The issuer processor 310 sends the financial transaction to the account association means 312, the account association means 312 maps the second account details to the second valid certificate and sends the financial transaction to the issuer of the second valid certificate 316. The SecureOne solution 312 may optionally send the financial transaction to a solution 314, which solution 314 then sends the financial transaction to the issuer of the second valid certificate 316. The response from the issuer 316 follows a reverse path to the merchant 304.

If the transaction is between partner acquirers, such as those represented by merchant A302, then the account association device 312 exchanges credentials as partner acquirers 306. The partner acquirer 306 routes the transaction to the issuer 316 and settles the transaction as usual. The account association device 312 is configured to document all transaction activities.

When a transaction is conducted between non-partner acquirers, such as those represented by merchant B304, the non-partner acquirer 320 routes the transaction to a partner acquirer, such as acquirer 306. The account association device 312 exchanges certificates and records transaction activity as a partner acquirer. In this case, a second exchange fee may apply.

Thus, the account associating means 312 may be configured to exchange credential data, collect transaction data, and settle transactions. The account associating means 312 may also enforce user rules, require verification that the user is present in the transaction, and may involve the consumer, the issuer 316, 322, and/or other parties in the process of identifying fraud.

16-20 are flow diagrams illustrating an overview of a transaction flow process. Fig. 16 may be a conventional method 330 for conducting a transaction. In this example, the cardholder 332 or user makes a purchase with the merchant 334 using the proxy device 100, 104. The merchant 334 obtains transaction information, such as first account information, and creates an authorization request. The merchant 334 passes this information to the acquirer 336. The acquirer 336 then passes the authorization request to the scheme or switch 338, which scheme or switch 338 then sends the authorization request to the issuer 340. The issuer 340 responds to the authorization request from the merchant 334 with an authorization response that is sent to the merchant over the reverse path.

In fig. 17, the method 330 of fig. 16 includes an account association device 352, which may correspond to the account association device 24 shown in fig. 1. The account association means 352 may include a proxy translation means 354. In this embodiment, the issuer 340 is the issuer of both the first account details and the first valid certificate details. The transaction proceeds in the usual manner as described in fig. 16, except that the scheme/switch 338 sends an authorization request to the account association device 352.

The account association means 352 places the first authorization request in a hold state. The proxy translation device 354 analyzes the consumer rule to map the first account details to a substitute valid certificate. The account correlation means 352 creates a second authorization request (which may be a new financial transaction or an API call directly to the issuer) and the account correlation means 352 sends the second authorization request to the issuer 340.

The issuer 340 processes the second authorization request and sends a response. The account association means 352 creates a response to the first authorization request using the second authorization response request and sends the response to the merchant 334.

Method 360 is the same as method 350 of fig. 17 in fig. 18, except that in this embodiment issuer (proxy) 362 is the issuer of the first account details and issuer (certificate) 366 is the issuer of the first valid certificate details. In method 360, the transaction flow is the same as method 350, except that the account association device 352 sends a second authorization request to the solution/switch 364, where the solution/switch 364 sends the second authorization request to the issuing authority (certificate) 366.

The issuer (certificate) 366 processes the second authorization request and sends a response. The account association means 352 creates a response to the first authorization request using the second authorization response request and sends the response to the merchant.

The method 370 in fig. 19 is the same as the method 350 of fig. 17, except that in this embodiment a third party token bank 372 is included in the transaction flow. In this embodiment, cardholder 332 may be the device on which the tokenized substitute first account details are stored. The merchant creates a first authorization request containing the tokenized substitute first account details and sends the first authorization request to the scenario/switch in the same manner as described for method 350 of fig. 17. However, in method 370, the plan/switch 338 sends the tokenized substitute first account details to the third party token vault 372, which translates the token into the de-tokenized substitute first account details and sends the de-tokenized substitute first account details to the plan/switch. The solution/switch then sends the de-tokenized substitute first account details to the account association means 352. Upon receiving the response, the account association device 352 processes the response in the manner described in method 350.

Method 380 in fig. 20 is the same as method 370 of fig. 20, except that in this embodiment, issuer (proxy) 362 is the issuer of the first account details and issuer (certificate) 366 is the issuer of the first valid certificate details. In the method 380, the transaction flow is the same as the method 370, except that the account association device 352 sends a second authorization request to the solution/switch 364, and the solution/switch 364 sends the second authorization request to the issuing authority (certificate) 366. The issuer (certificate) 366 processes the second authorization request and sends a response. The account association means 352 creates a response to the first authorization request using the second authorization response request and sends the response to the merchant in the manner described by method 370.

The embodiments described herein represent many possible implementations and examples and are not intended to limit the disclosure to any particular embodiment. Rather, various modifications may be made to these embodiments, as would be understood by those of ordinary skill in the art. Any such modifications are intended to be included within the spirit and scope of this disclosure.

Claims (13)

1. A system, comprising:

a point-of-sale (POS) device configured to obtain a proxy certificate corresponding to a valid certificate of a user from a mobile proxy device as part of a financial transaction and to send an encrypted financial message including the proxy certificate to a merchant acquirer;

a merchant acquirer configured to receive, decrypt, re-encrypt financial messages to generate an original encrypted message including the proxy certificate, and send the original encrypted message to a payment switch;

a payment switch configured to receive the original encrypted message from the merchant acquirer and send the original encrypted message to an issuer processor;

an issuer processor configured to receive the original encrypted message from the payment switch and send the proxy certificate to an account association device;

account association means configured to receive the original encrypted message from the issuer processor, decrypt the original encrypted message, generate an edited transaction message, and re-encrypt the edited transaction message, the edited transaction message including a tokenized message including a valid credential of the user corresponding to the proxy credential; and

an issuer for receiving the re-encrypted edited transaction message from the account association device, sending a response message indicating whether to accept or decline the financial transaction based at least in part on the re-encrypted edited transaction message;

wherein the account association means is configured to generate an edited response message from the response message by reversing the mapping from the proxy certificate to the user valid certificate and to send the edited response message to the merchant acquirer.

2. The system of claim 1, wherein the mobile proxy device is in the form of a card.

3. The system of claim 1, wherein the mobile proxy device is a smartphone.

4. The system of claim 1, wherein the account association device is configured to select a valid credential for the user from a plurality of credentials based on configurable rules related to usage of the mobile agent device.

5. The system of claim 4, wherein the configurable rules are predetermined by at least one of a user of the mobile proxy device and the issuer.

6. The system of claim 5, wherein the configurable rules are generated by the user using a web browser on a mobile device or computer.

7. The system of claim 5, wherein the configurable rules are generated by an operator associated with the issuer.

8. The system of claim 4, wherein the configurable rule depends on a computed location of the mobile proxy device.

9. The system of claim 4, wherein the configurable rule depends on a value of a transaction.

10. The system of claim 1, wherein the account correlation device is configured to generate the edited raw transaction message using a customizable rules engine.

11. The system of claim 1, further comprising:

a transaction repository configured to:

decrypting and tokenizing the original encrypted message to produce the tokenized message; and

sending the tokenized message.

12. The system of claim 1, further comprising:

a transaction guardian configured to receive the selected valid certificate and the requested transaction-edited token.

13. The system of claim 12, wherein the transaction guardian is further configured for verifying the original encrypted message and the original transaction of the requested transaction compilation.

Images