RU2461065C2 - Consumer authentication system and method - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: method involves receiving an authorisation request message associated with a consumer conducting a transaction with a portable consumer device. A challenge message is sent to the consumer, where the challenge message is dynamic or semi-dynamic. A challenge response message is received from the consumer, and an authorisation response message is sent to the consumer. The authorisation response message indicates whether or not the transaction is authorised.

EFFECT: high reliability of consumer authentication.

15 cl, 7 dwg

Description

CROSS RELATIONS TO RELATED APPLICATIONS

This application is not a provisional patent application and claims the priority of US patent application No. 60/815059, filed June 19, 2006, US patent application No. 60/815430, filed June 20, 2006, and US patent application No. 60/884089 filed January 9, 2007. All of these applications are incorporated herein by reference in their entirety for all purposes.

BACKGROUND

It is desirable to have a mechanism to ensure that a consumer who uses a portable consumer device, such as a credit card, is indeed the consumer associated with that credit card. Fraud can be very expensive for sellers, issuers of portable consumer devices and others.

Many consumer authentication mechanisms are known. In one example of a conventional consumer authentication process, a consumer can buy gas at a gas station using a credit card. Before a consumer is allowed to buy gas, and before a permit request message is sent to the issuer of the portable consumer device, the gas station may require the consumer to enter their zip code. This authentication request may be provided by the merchant as a way to ensure that the consumer is indeed a consumer associated with a credit card. The gas station wants to verify that the consumer is genuine, as the gas station may carry some of the risk from any fraudulent activity that results from purchases made at the gas station.

While such conventional authentication methods are effective, many improvements can be made. For example, regular authentication requests are typically static. If someone has stolen a portable consumer device and knows a custom zip code, for example, that person could still conduct fraudulent transactions using an authentic portable consumer device. Moreover, merchants have limited consumer information, and the types of requests that can be provided to the consumer are limited.

Better ways of authenticating consumers using portable consumer devices are desirable. Embodiments of the invention address the above problems and other problems individually and as a whole.

SUMMARY OF THE INVENTION

Embodiments of the invention may determine the authenticity of the consumer.

One embodiment of the invention relates to a method comprising receiving a permission request message associated with a consumer conducting a transaction with a portable consumer device. The call message is sent to the consumer, the call message being dynamic or semi-dynamic. A call response message is received from the consumer, and a permission response message is sent to the consumer. The permission response message indicates whether the transaction is permitted or not.

Another embodiment of the invention relates to a method comprising initiating a permission request message, the permission request message being associated with a consumer conducting a transaction with a portable consumer device, and sending a call message to the issuer associated with the portable consumer device, the call message being dynamic or semi-dynamic and then initiating a call answering message, the call answering message being dependent on the request message. An authorization response message is received, wherein the authorization response message indicates whether the transaction is permitted or not.

Another embodiment of the invention relates to a method comprising the issuer receiving a permission request message sent from an access device. In response to the receipt of a permission request message, one or more dynamic call questions are provided to the consumer before allowing the transaction conducted by the consumer.

Another embodiment of the invention relates to a method comprising receiving a first permission request message associated with a consumer conducting a transaction with a portable consumer device, receiving a request, sending a second permission request message including a request response message and receiving a permission response message, wherein the permission response message indicates whether a deal is allowed or not.

Another embodiment of the invention relates to a method comprising sending a first permission request message related to a consumer conducting a transaction with a portable consumer device, receiving a first call message, sending a second permission request message including a permission response message, and receiving a permission response message wherein the permission response message indicates whether the transaction is permitted or not.

Other embodiments of the invention relate to systems, portable consumer devices, and computer-readable media related to the above methods.

These and other embodiments of the invention are described in more detail below with reference to the drawings and detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a block diagram of a system in accordance with an embodiment of the invention.

Figure 2 shows a block diagram of one type of portable user device.

Figure 3 shows a General view of a second type of portable user device.

4 is a flowchart illustrating a method according to an embodiment of the invention.

5 shows another flowchart illustrating another method according to an embodiment of the invention.

6 shows a block diagram of certain aspects of the authentication of an embodiment of the invention.

7 shows a block diagram of a computer device.

DETAILED DESCRIPTION OF THE INVENTION

Currently, customer identification using call questions is typically performed in a trade. The merchant asks the consumer for authentication, such as a driver’s license, before allowing the purchase transaction with the portable consumer device to continue. In some cases, it may be better to envisage more customer identification processes for the “server application” whereby the issuer and / or the payment processing organization (such as Visa) verify the identity of the consumer. The issuer and / or the payment processing organization have much more consumer data than the merchant and are in a better position to authenticate the consumer. For example, the issuer has information such as the address of the consumer, mother's maiden name, and so on. In addition, the issuer and the payment processing organization have information, such as recent information on the purchase and consumer behavior on the purchase. Any of this information may be used to help authenticate the consumer in the purchase transaction.

Thus, in an embodiment of the invention, the payment processing organization, the issuer, or any other non-trading entity with consumer information can pose consumer calling issues to authenticate the consumer. Call questions can be static, where the same questions are asked on every purchase transaction, or dynamic, where over time you can ask different questions.

The question asked may also have a static or dynamic (semi-dynamic or fully dynamic) answer. For example, the question "When is your birthday?" requires a static response since the response does not change. The question "What is your zip code?" requires a semi-dynamic response, as this could change, or may change infrequently. Finally, the question "What did you buy yesterday at 16:00?" would require a dynamic response, as the response changes frequently. Thus, in preferred embodiments, the call issue would preferably be based on “operational” information that the issuer will most likely possess. For example, a consumer might be asked a more specific question, such as "Did you eat out at home in a Mexican restaurant last night?" By providing additional, more specific consumer knowledge into the database, consumer authentication is provided.

In one embodiment, the method includes conducting a transaction, such as a purchase transaction, using a portable consumer device. The portable consumer device may be a credit card or the like. A purchase transaction may take place in a trade where there is an access device, such as a point of sale terminal.

A consumer may use a portable consumer device to interact with an access device, such as a point of sale terminal, and begin the process. The point of the sales terminal can start and then generate a permission request message, which can then be sent to the payment processing network, and then, subsequently, to the issuer of the portable consumer device. When the permission request message is received by any of the payment processing network or the issuer, it is analyzed. A call message, which may be dynamic or semi-dynamic in nature, is formed and sent to the consumer. The call message can be sent back to the access device or to the portable consumer device of the consumer (for example, if the portable consumer device is a mobile phone).

The consumer then provides a response to the call message. A call answer message is received from the consumer. The call response message is then checked, and if it is checked, the permission response message is analyzed to determine if the transaction is permitted (for example, if there is enough money in the consumer’s account, or if there is enough credit in the consumer’s account). If the transaction is permitted, the issuer and also the payment processing network send a permission response message to the consumer. A permission response message indicates whether a transaction is permitted or not.

In certain embodiments described above and below, call questions are described in detail, but embodiments of the invention are not limited thereto. Embodiments of the invention may generally relate to the use of call messages, which may include call issues. In some embodiments, as will be described in further detail below, call messages may or may not be read by the consumer and may require authentication of the consumer in direct or indirect ways. Examples of calling questions include questions regarding the consumer’s portable consumer device (for example, what is CVV2 or the authentication code on the back of your card?), The location of the consumer (for example, what is your zip code), the consumer’s mobile or landline phone (for example, which number Your mobile phone?), Personal information of the consumer (for example, what is your mother’s maiden name?) And so on. Examples of call messages that are not questions specifically addressed by the consumer include messages that automatically poll the phone for its location or phone number and encourage the extraction of such information. Another example of a call message may be a message that delivers a code (or other identification tag) to the telephone, and the use of this code in the authentication of the user access device.

1. SYSTEMS

1 shows a typical system 20 according to an embodiment of the invention. Other systems according to other embodiments of the invention may include more or fewer components than shown in FIG.

The system 20 shown in FIG. 1 includes a merchant 22 and an acquirer 24 associated with a merchant 22. In a typical payment transaction, a consumer 30 may purchase goods or services from a merchant 22 using a portable consumer device 32. Merchant 22 may be a physical merchant or electronic merchant. The acquirer 24 may communicate with the issuer 28 through the payment processing network 26. Merchant 22 may alternatively be directly connected directly to payment processing network 26.

Consumer 30 may be a person or organization, such as a business, that is capable of purchasing goods or services. In other embodiments, the consumer 30 may simply be a person who wants to conduct some other type of transaction, such as a money transfer or a transaction in a vending machine. Consumer 30 may optionally control cordless telephone 34.

Portable consumer device 32 may be of any suitable form. For example, suitable portable consumer devices can be portable and compact enough to fit into a consumer's wallet and / or pocket (e.g. pocket size). These may include smart cards, regular credit or debit cards (with a magnetic stripe and without a microprocessor), keychain devices (such as Speedpass ™, commercially available from Exxon-Mobil Corporation), and so on. Other examples of portable devices include cell phones (e.g., telephone 34 described above), personal digital assistants (PDAs), pagers, pay cards, security cards, access cards, memory cards, transceivers and the like. Portable consumer devices may also be debit devices (e.g., debit card), credit devices (e.g., credit card), or devices with a stored amount (e.g., a card with a stored amount).

A typical portable consumer device 32 'in the form of a telephone may include computer-readable media and a housing, as shown in FIG. (FIG. 2 shows a set of components, and a portable consumer device according to embodiments of the invention may comprise any suitable combination or subset of such components). The computer-readable medium 32 (b) may be in the housing 32 (h) or may be separable from it. The housing 32 (h) may be in the form of a plastic board, box, or other structure. Machine-readable medium 32 (b) may be a memory that stores data, and may be in any suitable form, including a magnetic strip, a memory chip, and so on. The memory preferably stores information such as financial information, transit information (for example, as in a metro or train pass), access information (for example, as in an access card), and so on. Financial information may include information such as bank account information, bank identification number (BIN), credit or debit card number information, account balance information, expiration date, consumer information such as name, date of birth, and so on. Any of this information may be transmitted by portable consumer device 32.

The information in memory may also be in the form of data tracks that are traditionally associated with a credit card. Such tracks include Track 1 and Track 2. Track 1 (the "International Air Transport Association") stores more information than Track 2 and contains the name of the card holder, as well as the account number and other controlled data. This track is sometimes used by airlines to provide credit card reservations. Lane 2 ("American Banking Association") is currently the most commonly used. This is a track that is read by a vending machine and credit card testers. ABA (American Banking Association) has designed the specification for this track, and all global banks must comply with it. It contains the cardholder’s account, encrypted PIN data plus other controlled data.

The portable consumer device 32 may further include a proximity element 32 (g), which is typically in the form of a semiconductor chip (or other data storage element) combined with a wireless transmission element (eg, data transmission) such as an antenna. The contactless element 32 (g) is connected to (for example, integrated inwardly) the portable consumer device 32, and data or a control instruction transmitted over the cellular network can be applied to the contactless element 32 (g) via a contactless element interface (not shown). The interface of the contactless element is designed to allow the exchange of data and / or control instructions between the circuit of the mobile device (and, therefore, the cellular network) and the additional contactless element 32 (g).

The non-contact element 32 (g) is capable of transmitting and receiving data using the close radio communication (NFC) capability (or the close radio communication environment), usually in accordance with a standardized protocol or data transmission mechanism (e.g., ISO 14443 / NFC). The close radio capability is a short range communication ability such as RFID, Bluetooth ™, infrared, or other data transfer ability that can be used to exchange information between portable consumer device 32 and the interrogator. Thus, the portable consumer device 32 is capable of communicating and transmitting data and / or control instructions via both the cellular network and the close radio capability.

The portable consumer device 32 may also include a processor 32 (c) (e.g., a microprocessor) for processing the functions of the portable consumer device 32, and a display 32 (d) to allow the consumer to see phone numbers and other information and messages. The portable consumer device 32 may further include input elements 32 (e) to allow the consumer to input information into the device, a speaker 32 (f) to allow the consumer to hear voice communication, music, and so on, and a microphone 32 (i) to allow the consumer to transmit his voice through portable consumer device 32. Portable consumer device 32 may also include an antenna 32 (a) for wireless data transmission (eg, data transfer).

If the portable consumer device is in the form of a debit, credit or smart card, the portable consumer device may also additionally have features such as a magnetic strip. Such devices can operate either in contact or in non-contact mode.

An example of a portable consumer device 32˝ in the form of a card is shown in FIG. 3. Figure 3 shows a plastic base 32 (m). The contactless element 32 (o) in order to connect with the access device 34 may be present on or be integrated into the plastic base 32 (m). Consumer information 32 (p), such as account number, expiration date and consumer name, may also be on plastic base 32 (m).

As shown in FIG. 3, the portable consumer device 32˝ may include both a magnetic strip 32 (n) and a contactless member 32 (o). In other embodiments, both the magnetic strip 32 (n) and the contactless element 32 (o) may be in the portable consumer device 32˝. In other embodiments, any of the magnetic strip 32 (n) or the proximity element 32 (o) may be present in the portable consumer device 32˝.

The payment processing network 26 may include data processing subsystems, networks and operations used for support, and provide permission services, file exclusion services, clearing and settlement services. A typical payment processing network may include VisaNet ™. Payment processing networks such as VisaNet ™ are able to process credit card transactions, debit card transactions and other types of business transactions. VisaNet ™, in particular, includes the VIP system (Visa Integrated Payments system), which processes the request for permission, and the Base II system, which provides clearing and settlement services.

The payment processing network 26 may include a server computer. A server computer is usually a powerful computer or group of computers. For example, a server computer may be a large universal computer, a microcomputer group, or a group of servers that function as a single node. In one example, the server computer may be a database server connected to a Web server. The payment processing network 26 may use any suitable wired or wireless network, including the Internet.

As shown in FIG. 1, the payment processing network 26 may comprise a server 26 (a), which may comprise a call question generator 26 (a) -1. Server 26 (a) can also exchange data with transaction history database 26 (b) and call questions database 26 (c). As will be explained in more detail below, the call question generator 26 (a) -1 can simply retrieve the call questions from the call question database 26 (c). Alternatively or additionally, the call question generator 26 (a) -1 may generate call questions using the information in the transaction history database 26 (b).

As will be explained in more detail below, call questions can be static or dynamic in nature. For example, the call question generator 26 (a) -1 may receive a permission request message, and the permission request message may include a consumer account number and a purchase amount. He can then search for the consumer account number and any consumer information associated with the consumer account number. He may then recover a suitable question from the call questions database 26 (c), or may generate a suitable call question himself. For example, in some cases, the call question generator 26 (a) -1 may restore the question "What is your mobile phone number?" from a database of call questions 26 (c) after receiving a permission request message. Alternatively, call question generator 26 (a) -1 can generate a dynamic question, such as "Did you use this credit card at McDonald's last night?" Information related to a particular restaurant where consumer 30 was on the previous day could be retrieved from transaction history database 26 (b).

The call questions database 26 (c) may be filled with questions of any suitable type. Questions may relate to the past location (for example, the current location of the consumer, the city the consumer recently visited), or the current location (for example, the current location of the store where the consumer is currently), the type or name of the merchant the consumer is currently visiting or visited in the past, the consumer’s family or personal data (for example, name, phone number, social security number and so on) and so on. Questions in the call question database 26 (c) can be generated by the call question generator 26 (a) -1 and subsequently stored in the call question database 26 (c).

Alternatively or additionally, call questions can be generated from an external source and then stored in call question database 26 (c). For example, a consumer 30 may use a browser on a personal computer or the like to deliver specific calling questions to a server 26 (a) through a communication medium (not shown) such as the Internet.

In some embodiments, a consumer may determine the types and / or number of call questions to ask themselves. For example, a consumer can determine that a consumer wants to be asked three call questions if the consumer is visiting a jewelry store, but only one question if the consumer is visiting a fast food restaurant. The type of questions posed by the consumer can be based on the type of merchant, frequency of purchase, and so on. Some concepts regarding user-defined resolution settings are described in US Patent Application No. 10/093002, filed March 5, 2002, which is incorporated herein by reference in its entirety for any purpose.

In preferred embodiments, the call questions are derived from past transaction data in the transaction history database 26 (b). Consumer 30 can make many, many transactions with payment processing network 26 (and / or issuer 28) over time. This consumer transaction information can be stored in the transaction history database 26 (b) for a long time, and call questions can be generated using transaction information. Past transaction information provides a good basis for authenticating the consumer 30, as the consumer 30 will be aware of the transactions that the consumer 30 has conducted in the past. For example, consumer 30 may have used his credit card to pay for a hotel room in New York on the previous day, and the next day a question may be asked, such as "Did you stay at a hotel in New York yesterday?" In another example, consumer 30 may have bought a product that costs more than $ 2000 the day before, and the next day may be asked: "Did you make a purchase for more than $ 2000 yesterday?" The questions / answers that are presented to the consumer 30 may be essentially free and / or may include pre-formatted answers, such as multiple choice or true-false answers, from which the user can choose.

The merchant 22 may also have, or may receive communications from, an access device 34 that can interact with portable consumer device 32. The access devices according to embodiments of the invention may be in any suitable form. Examples of access devices include point of sale (POS) devices, cell phones, personal digital assistants (PDAs), personal computers (PCs), tablet computers (PCs), handheld computers for reading, television set-top boxes, electronic cash registers (ECRs), ATMs (ATMs), instant payment points (VCRs), kiosks, security systems, access systems and the like.

If the access device 34 is a point of sale terminal, then any suitable point of sale terminal may use a built-in card reader. Card readers can use any suitable contact or non-contact mode of operation. For example, a typical card reader may include RF (radio frequency) antennas, magnetic stripe readers, and so on to interact with portable consumer device 32.

Issuer 28 may be a bank or other organization that may have an account associated with customer 30. Issuer 28 may manage server 28 (a), which may have a call question generator 28 (a) -1. The transaction history database 28 (b) and the call questions database 28 (c) may be in communication with the server 28 (a). Issuer server 28 (a), call question generator 28 (a) -1, transaction history database 28 (b) and call question database 28 (c) may function in the same way or differently as server 26 (a ) payment processing, call question generator 26 (a) -1, transaction history database 26 (b) and call question database 26 (c). The above descriptions regarding elements 26 (a), 26 (a) -1, 26 (b) and 26 (c) may refer to elements 28 (a), 28 (a) -1, 28 (b) and 28 (c) .

Embodiments of the invention are not limited to the above embodiments. For example, although individual functional blocks are shown for the issuer, the payment processing network, and the buyer, some entities perform all or any suitable combination of these functions and may be included in embodiments of the invention. Additional components may also be included in the implementation of the invention.

7 shows typical components or subsystems of a computer device. Such components or any subset of such components may be present in various components shown in FIG. 1, including access device 34, server computers 26 (a), 28 (a), and so on. The subsystems shown in FIG. 7 are connected through a system bus 775. Additional subsystems, such as a printer 774, keyboard 778, removable disk 779, monitor 776, which is connected to adapter 782, and others, are shown. The peripherals and input / output (I / O) devices that are connected to the input / output controller 771 may be connected to a computer system by any number of means known in the art, for example, such as serial port 777. For example, serial port 777 or external interface 781 can be used to connect a computer device to a global network, such as the Internet, a mouse input device, or a scanner. Interconnection via the system bus 775 allows the central processor 773 to communicate with each subsystem and control the execution of commands from the system memory 772 or non-removable disk 779 as well as the exchange of information between the subsystems. System memory 772 and / or non-removable disk 779 may embody a computer-readable storage medium.

2. METHODS

Methods according to embodiments of the invention can be described with reference to FIGS. 1 and 4. In a typical purchase transaction, a consumer 30 purchases a product or service from a merchant 22 using a portable consumer device 32, such as a credit card. The portable consumer consumer device 32 may interact with an access device 34, such as a POS (point of sale) of a terminal at a merchant 22 (step 102). For example, consumer 30 can take a credit card and pass it through the appropriate slot in the POS terminal. Alternatively, the POS terminal may be a contactless reader, and portable consumer device 32 may be a contactless device, such as a contactless card.

The first permit request message is then forwarded to the acquirer 24. After the acquirer 24 receives the first permit request message, the first permit request message is then sent to the payment processing network 26 (step 104). The first permission request message is then received by the payment processing network server 26 (a), and the payment processing network server 26 (a) then determines if a call is necessary.

Various criteria can be used to determine if a call is needed. For example, the payment processing network server 26 (a) may decide that a particular transaction is a transaction of high value (for example, more than $ 1000), and that the call is therefore appropriate. In another example, the payment processing network server 26 (a) may decide that there is something suspicious in an existing transaction, and may then decide that the call is appropriate. For example, the payment processing network server 26 (a) may decide that the portable consumer device 32 is currently being used in a location that is different from the consumer’s home location, and a recent consumer shopping history shows that the consumer is not traveling.

Once it has been determined that the call is appropriate for the present transaction, the call question generator 26 (a) -1 may then cause (locally or remotely) a call question (step 108). In some embodiments, a call question generator 26 (a) -1 may retrieve a question from a call question database 26 (c).

At this stage, instead of sending the first permission request message to the issuer 28, the payment processing network 26 sends the first permission request message back to the access device 34 through the merchant 22 and the acquirer 24 (step 110). The first permission response message may contain data representing a call request that was previously received by the call question generator 26 (a) -1. The call request may be a call question sent by the database computer or instructing the access device to create a call based on a set of preloaded questions in the access device. The first message of the permission request can be characterized as an initial refusal, since it does not indicate confirmation of the transaction.

As soon as the call question is received by the access device 34, the consumer 30 delivers the call response to the access device 34. The call response can be supplied to the access device 34 in any suitable way (for example, via a keyboard, proximity reader, and so on). As soon as the access device 34 receives the call response, the access device 34 sends the call response to the payment processing network server 26 (a) through the merchant 22 and the acquirer 24, and it is received by them (step 112). A call response message (or a call and a response or a call indicator and a response) may be part of a second permission request message.

The payment processing network server 26 (a) then approves the call response message (step 114). If the call response message is not approved, then the payment processing network server 26 (a) may send a response message back to the access device 34 indicating that the transaction is not approved. Alternatively or additionally, the payment processing network server 26 (a) may send another call issue to the access device 34. On the other hand, if the call is approved, the payment processing network server 26 (a) may send a second permission request message to the issuer 28 (step 116) along with a sign that the consumer 30 has satisfied any calls made by the payment processing network 26.

After the issuer 28 receives a second permission request, the issuer 28, using the issuer's server 28 (a), determines whether the transaction is permitted or not (step 118). The transaction may not be allowed because consumer 30 has insufficient funds or credit. If consumer 30 does have sufficient funds or credit, the issuer 28 may then send a second permission response message indicating that the transaction is allowed back to the access device 34 through the payment processing network 26, the acquirer 24 and the merchant 22 (step 122).

At the end of the day, the normal clearing and settlement process can be carried out by the transaction processing system 26. The clearing process is the process of exchanging financial details between a buyer and an issuer in order to facilitate registration to a consumer account and agreeing on a consumer settlement. Clearing and settlement may occur simultaneously.

Many alternative embodiments are also possible. For example, the issuer 28 may generate a call question and then send to the consumer 30 instead of or in addition to the payment processing network 26. Call question generator 28 (a) -1, transaction history database 28 (b) and call question database 28 (c) managed by issuer 28 can be used in the same or different way as generator 26 (a) described above -1 call questions, a transaction history database 26 (b) and a call questions database 26 (c), which are managed by the payment processing network 26.

In the above embodiments, there are two permission request messages that are sent to the payment processing network 26 (and / or issuer 28). This is desirable since existing payment processing systems have “timers” that are set at various points between the access device 34 and the issuer 28 during the payment authorization process. Timers determine how long various events should occur during the payment authorization process. The timers can be set and implemented as a computer program with the acquirer 24, the payment processing network 26 and the issuer 28. For example, the timers with the acquirer 24, the payment processing network 26 and the issuer 28 can be set to 3 seconds, 6 seconds and 10 seconds, respectively. If the permission request message is not received within these respective times, then some actions may be triggered. For example, an erroneous message may be sent back to the access device 34, requiring that the merchant 22 resubmit the permission request message if the permission message is not received by the issuer 28 within 10 seconds. If a call request is created during the authorization process and before the permission request message reaches the issuer 28, the issuer timer may trigger an action indicating that an error has occurred. Creating call requests and responses during a single resolution process can potentially conflict with existing timers in the payment system.

When using at least two permission request messages in two separate permission processes, it is useful not to affect the timers described above. Timers should not be changed to send calling questions to consumer 30. This allows embodiments of the invention to be used in an existing payment infrastructure and widespread changes are not necessary in embodiments of the invention. In comparison, if a call issue is received during the payment authorization process using a single permission request message, this may delay the permission request message and may require changes to the current timers in the payment processing system.

At least two permission request messages may have information such as BIN (bank identification numbers), transaction sizes, account numbers, service codes, and so on. They may also contain the same transaction size for the transaction and / or different transaction sizes. For example, the first permission request message may have an actual transaction size and the second permission request message may have a dollar amount or other identifier to indicate that that previous permission request with a transaction size has already been submitted. A transaction code may be used to associate the first and second permission requests in some embodiments.

The method described in accordance with FIG. 4 can be characterized as a “closed channel” process since the access device 34 receives a call question and provides an answer to the call question. However, other embodiments of the invention may use an open channel solution whereby a call question can be sent to a device other than the access device that sent the first permission response message.

Examples of open channel methods according to embodiments of the invention can be described in accordance with FIGS. 1 and 5. In a typical purchase transaction, a consumer 30 purchases a product or service from a merchant 22 using a portable consumer device 32, such as a credit card. The portable consumer consumer device 32 may interact with an access device 34, such as a POS (point of sale) terminal at a merchant 22 (step 202). For example, the consumer 30 can take a credit card and can pass it through the corresponding slot in the POS terminal. Alternatively, the POS terminal may be a contactless reader, and portable consumer device 32 may be a contactless device, such as a contactless card.

The first permission request message is then sent to the acquirer 24. After receiving the first permission request message, the first permission request message is then sent to the payment processing network 26 (step 204). The first permission request message is received by the payment processing network server 26 (a) and the payment processing network server 26 (a) then determines if a call is necessary.

Various criteria can be used to determine if a call is needed. For example, the processing network server 26 (a) may decide that a particular transaction is a transaction of high value (that is, more than $ 1000), and that the call is therefore appropriate. In another example, the processing network server 26 (a) may decide that there is something suspicious in the present transaction and may then decide that the call is appropriate.

Once it has been determined that the call is appropriate for the existing transaction, the call question generator 26 (a) -1 can then generate a (local or remote) call question (step 208). In some embodiments, the call question generator 26 (a) -1 may select a question from the call question database 26 (c).

Instead of sending the first permission request message to the issuer 28, and instead of sending the first permission response message back to the access device 34, the payment processing network 26 sends the first permission response message back to the consumer’s mobile phone 34 (step 210) or another type of access device . The first permission response message can be sent back to the consumer’s mobile phone 34. This can be done directly or through some intermediate entity. The first permission response message may contain data representing a call request that was previously received by the call question generator 26 (a) -1. The first permission response message may be characterized as an initial failure, as it does not indicate transaction confirmation.

Once the call question is received on the mobile phone 34, the consumer 30 provides a call response to the access device 34 (step 212). The access device 34 then directs the call response to the server 26 (a) of the payment processing network through the merchant 22 and the acquirer 24, and it is received by them (step 214). The call response message may be part of a second permission response message.

It is worth noting that although the call questions that the user actively answers are described in detail in accordance with FIG. 5, other types of call requests can be sent to the mobile phone 34. For example, in some cases, the call request may not require an answer, which is actively provided by the consumer 30. Passive responses to the call request can be provided. For example, in some embodiments, a call request sent to a mobile phone 34 may be a matter of the physical location of the mobile phone 34. The mobile phone 34 may have a GPS device or other location device, and this information (or other information, such as a cryptogram and so on) payment processing networks 26 can be transmitted, and payment processing network 26 can authenticate consumer 30 using this location information.

As soon as the payment processing network server 26 (a) receives the call response message, the payment processing network server 26 (a) then approves the call response message (step 216). If the call response message is not approved, then the payment processing network server 26 (a) may send the response message back to the access device 34, indicating that this transaction is not approved. Alternatively or additionally, the payment processing network server 26 (a) may send another call message to the access device 34 and / or the mobile phone 34. On the other hand, if the call is approved, the payment processing network server 26 (a) can then send a second request message authorizing the issuer 28 (step 218) along with a designation that the consumer 30 has satisfied any calls set forth by the payment processing network 26.

After the issuer 28 receives the second request for permission, the issuer 28, using the issuer's server 28 (a), determines whether the transaction is allowed or not (step 220). The transaction may not be allowed because consumer 30 has insufficient funds or credit. If consumer 30 does have sufficient funds or credit, the issuer 28 may then send a second permission response message indicating that the transaction is permitted back to the access device 34 through the payment processing network 26, the acquirer 24 and the merchant 22 (step 222).

At the end of the day, the normal clearing and settlement process can be carried out by the transaction processing system 26. The clearing process is the process of exchanging financial details between a buyer and an issuer in order to facilitate registration to a consumer account and agreeing on a consumer settlement. Clearing and settlement may occur simultaneously.

Many alternative embodiments are also possible. For example, the issuer 28 may generate a call question and then send to the consumer 30 instead of or in addition to the payment processing network 26. Call question generator 28 (b) -1, transaction history database 28 (b) and call question database 28 (c) managed by issuer 28 can be used in the same or different way as the generator 26 (a) described above - 1 call questions, a transaction history database 26 (b) and a call question database 26 (c) managed by the payment processing network 26.

In another embodiment, instead of sending a call question, the payment processing network server 26 (a) may send an electronic coupon to the consumer’s mobile phone 34. The payment processing network 26 may decide that the call is appropriate and may send an electronic coupon to the mobile phone 34. Upon receipt of this electronic coupon, the consumer then must use the coupon in the access device 34. If the consumer 30 used the coupon in the access device 34, then the access device 34 receives the coupon of the payment processing network 26, and the receipt of the coupon of the payment processing network 26 indicates that the consumer 30 is authenticated. It is assumed that the consumer 30 is genuine because the non-genuine consumer does not have 34 consumer telephone.

3. CERTIFICATION OF THE AUTHORITY OF THE TRANSACTION

The above call authentication process is a process for authenticating a consumer, and can be part of a larger general “authentication” process.

6 shows a conceptual flowchart 100, authentication of a purchase transaction may have various aspects. Such aspects include authentication of the portable consumer device 100 (a), consumer authentication 100 (b), a data processing process including real-time risk analysis 100 (c), and consumer purchase transaction notice 100 (d) .

Portable consumer device authentication is related to portable consumer device authentication. Thus, in the authentication process of the portable consumer device, a determination is made as to whether the portable consumer device that is used in the purchase transaction is genuine or whether it is a fake portable consumer device. Certain exemplary methods for improving the authentication of a portable consumer device include:

- dynamic CVV (card verification code) on a portable consumer device such as magnetic stripe cards,

- card security features (existing and new),

- contactless chip (limited use),

- magnetic stripe identification,

- card authentication values (CVV and CVV2),

- Contact EMV (Europay, MasterCard and Visa) chips.

The consumer authentication is related to the determination as to whether the person conducting the transaction is the owner or user authorized by the portable consumer device. Conventional consumer authentication processes are conducted by merchants. For example, merchants may be asked to see a driver’s license for a credit card holder before conducting a business transaction with a credit card holder. Other ways to authenticate the consumer may be desirable, as the merchant does not authenticate the consumer in each case. Specific examples of possible ways to improve the consumer authentication process include at least the following:

- knowledge-based call responses,

- hardware symbols (multiple-solution options),

- OTPs (one time password) (one-time password, limited use),

- AVSs (address verification system) (not as a single solution),

- signatures

- software symbols,

- PIN (personal identification number) (via network / remotely),

- ID (identification document) of the user / access codes,

- two channel identification processes (for example, via telephone),

- biometrics.

The data processing process is related to processing that may occur on the side of the issuer or the payment processing network, or other non-commercial location. Various processes can be performed on the payment transaction "server" to help ensure that any transactions are genuine. The data processing process can also prevent transactions that should not be allowed, and may allow transactions that should be allowed.

Lastly, consumer notice is another aspect of transaction authentication. In some cases, the consumer may be notified that a purchase transaction is occurring or has occurred. If the consumer is notified (for example, via a cell phone) that the transaction is using his portable consumer device, and the consumer does not actually conduct the transaction, then appropriate steps can be taken to prevent the transaction from being completed. Specific examples of consumer notification processes include:

- notification of purchase via SMS (short message service),

- notice of purchase via email,

- notice of purchase by phone.

Other details regarding some of the above aspects are provided in US Patent Application No. 60/815059 filed June 19, 2006, US Patent Application No. 60/815430 filed June 20, 2006, and US Patent Application No. 60/884089 filed January 9. 2007, which are incorporated herein by reference in their entirety for all purposes. Certain details of certain aspects can be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. For example, portable consumer device authentication, consumer authentication, data processing, and transaction notification to a consumer can all be combined in some embodiments of the invention. However, other embodiments of the invention may be directed to certain embodiments regarding each individual aspect or certain combinations of these individual aspects.

It should be understood that the existing invention, as described above, can be implemented in the form of control logic using software in a modular or integrated form. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods of implementing the existing invention using hardware and a combination of hardware and software.

Any of the software components or functions described in this application can be implemented as software code that will be executed by the processor using any suitable computer language, such as, for example, Java, C ++ or Perl, for example, regular or object oriented methods. The software code can be stored as a series of instructions or instructions on a machine-readable device, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or an optical medium such as CD -ROM. Any such computer-readable device may be located within or outside the boundaries of a separate system unit and may be present on or within various system units within a system or network.

The above description is illustrative and not restrictive. Many changes to the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should therefore not be determined in relation to the above description, but instead should be determined in respect of pending applications along with their full scope or equivalents.

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

The use of "a", "an" or "the" is intended to mean "one or more" unless the contrary is explicitly indicated.

All patents, patent applications, publications, and descriptions mentioned above are hereby incorporated by reference in their entirety for all purposes. None of these are prior art.

Claims (15)

1. A method of minimizing risk from a consumer performing a fraudulent transaction, comprising the steps of:
receive a permission request message associated with a consumer conducting a transaction with a portable consumer device;
sending a call message to the consumer, the call message being dynamic or semi-dynamic;
receive a call response message from the consumer; and
send a permission response message to the consumer, wherein the permission response message indicates whether the transaction is permitted or not. 2. The method according to claim 1, in which the call question is dynamic and uses the history of consumer transactions to create a call question. 3. The method according to claim 1, in which the permission request message is received by the payment processing network, and in which the payment processing network sends a call message to the consumer and receives a call response message from the consumer and, if the consumer provides the correct call response message:
sends a request permission message to the issuer of the portable consumer device; and
receives the permission response message from the issuer before sending the permission response message to the consumer. 4. The method according to claim 1, in which the permission request message is received by the issuer, and the issuer sends a call message to the consumer and receives a call response message from the consumer, and in which the issuer further analyzes the call response message from the consumer to determine if the consumer is providing the correct message answer the call before sending the permission response message to the consumer. 5. The method according to claim 1, in which the call message includes a question that is dynamic, and uses the location of the consumer to create a call message. 6. A machine-readable medium to minimize risk from a consumer performing a fraudulent transaction, comprising:
code for performing the method according to claim 1. 7. A server computer to minimize risk from a consumer performing a fraudulent transaction containing a computer-readable medium according to claim 6. 8. A method of minimizing risk from a consumer performing a fraudulent transaction, comprising the steps of:
triggering a permission request message, wherein the permission request message is associated with a consumer conducting a transaction with a portable consumer device and sent to an issuer associated with the portable consumer device;
receiving a call message, the call message being dynamic or semi-dynamic;
trigger a call answering message, the call answering message being dependent on the call message; and
receive a permission response message, wherein the permission response message indicates whether the transaction is permitted. 9. The method of claim 8, wherein the permission request message and the call question are triggered by at least one of the merchants involved in the transaction, or by the consumer. 10. A machine-readable medium to minimize risk from a consumer performing a fraudulent transaction, comprising:
a code for triggering a permission request message, wherein the permission request message is associated with a consumer conducting a transaction with a portable consumer device and sent to an issuer associated with the portable consumer device;
code for receiving a call message, the call message being dynamic or semi-dynamic;
code for triggering a call answering message, the call answering message depending on the call message; and
a code for receiving a permission response message, wherein the permission response message indicates whether the transaction is permitted or not. 11. A machine-readable medium for minimizing risk from a consumer performing a fraudulent transaction, comprising:
code for receiving, on the issuer's side, a permission request message sent from the access device; and
a code to provide one or more dynamic call questions to the consumer before authorizing a transaction conducted by the consumer. 12. A method of minimizing risk from a consumer performing a fraudulent transaction, comprising the steps of:
receiving a first permission request message associated with a consumer conducting a transaction with a portable consumer device;
send a call message to the consumer;
receiving a second permission request message including a call response message; and
send a permission response message, wherein the permission response message indicates whether the transaction is allowed or not. 13. The method according to item 12, in which the call message is sent to a mobile phone that is controlled by the consumer. 14. A computer-readable storage medium to minimize risk from a consumer performing a fraudulent transaction containing a code in order to perform the method of claim 12. 15. A server to minimize the risk from a consumer performing a fraudulent transaction containing a computer-readable medium according to claim 14.

Images