RU2480922C2 - Authentication of operations using network - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: method of authentication includes authentication of a portable user device using dynamic data generated by the portable user device or an access device being connected to the portable user device, besides, dynamic data differs for each operation and are generated from at least one of data of a certain operation and data of a certain user, and authentication of a user, including sending a message with a request to the user, and receipt of the response to the request from the user.

EFFECT: reduced risk of fraud operations.

14 cl, 15 dwg, 1 tbl

Description

Cross reference to related applications

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

State of the art

There are a number of ways to guarantee secure payment transactions. For example, there are a number of different ways to authenticate a consumer to ensure that the person who conducts the payment transaction is a genuine consumer. There are also a number of different methods for authenticating a portable consumer device that is used by that consumer.

Although there are various ways to authenticate payment transactions, improved authentication mechanisms are required to further reduce the risk of fraudulent transactions.

Embodiments of the invention address these and other problems collectively and individually.

SUMMARY OF THE INVENTION

Disclosed are systems and methods for improved authentication of a consumer and a portable consumer device. Embodiments of the invention include methods for authenticating a portable consumer device, such as a payment card, authenticating a consumer using a portable consumer device, performing server processing, and providing consumer notification of purchase transactions.

One embodiment of the invention is directed to a method comprising: performing a consumer authentication process in which a consumer uses a consumer’s portable device to conduct an operation; performing an authentication process for a portable consumer device, wherein performing an authentication process for a portable consumer device comprises verifying an identification tag or a dynamic verification value associated with the portable consumer device; and performing a risk analysis after the consumer authentication and authentication of the portable consumer device has been completed, in which the risk analysis determines whether the operation is indeed subject to authorization.

One embodiment of the invention is directed to a method comprising: authenticating a portable consumer device using dynamic data generated by a portable consumer device or access device in communication with a portable consumer device; and consumer authentication, comprising sending a request message to the consumer and receiving a response to the request from the consumer.

Another embodiment of the invention is directed to a method comprising: receiving an authorization request message associated with an operation using a portable consumer device, in which the portable consumer device contains an identifier for the portable consumer device and in which the authorization request message contains a modified identifier for the portable device consumer and algorithm identifier; selecting an algorithm from among a plurality of algorithms using an algorithm identifier; determining the identification tag of the portable consumer device using the selected algorithm and the modified identification tag of the portable consumer device; determining whether the identification tag of the portable consumer device matches the stored identification tag of the portable consumer device; sending a request message to a consumer associated with a portable consumer device; and sending a validation response message to the consumer, in which the validation response message indicates whether the operation is approved or not.

Another embodiment of the invention is directed to a method comprising: authenticating a portable consumer device without a battery, wherein the portable consumer device comprises a portable consumer device without a battery, comprising an antenna; authentication of the consumer and sending a notification message to the consumer that the operation is ongoing.

Other embodiments of the invention are directed to certain combinations of other aspects of authentication, which are provided below in the detailed description.

Brief Description of the Drawings

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

2 shows a block diagram of aspects of a payment transaction authentication system in accordance with an embodiment of the invention.

3 (a) -3 (c) show schematic views of cards without a battery in accordance with embodiments of the invention.

Figure 4 shows a portable security device.

5 shows a representation of data fields associated with a portable consumer device, such as a credit card.

6 shows portions of a primary account number (PAN).

7 shows a block diagram of a system comprising a security question mechanism.

8, 9 show flowcharts illustrating methods comprising using a request message to authenticate a consumer.

10 (a) shows a block diagram of a system that can use an algorithm ID.

FIG. 10 (b) shows a block diagram illustrating modules that may be present in a server computer in the system shown in FIG. 10 (a).

11, 12 show flowcharts illustrating methods in accordance with embodiments of the invention.

Detailed description

I Sample systems and payment transactions

Embodiments of the invention may be used to authenticate traditional purchase transactions, as well as for other types of transactions (eg, money transfer transactions). Specific authentication systems and methods may include authenticating a consumer (e.g., a customer), a portable consumer device (e.g., a credit card) and / or an access device (e.g., a POS (point of sale) terminal) to ensure that the operation is genuine.

In a typical purchase operation, a consumer uses a consumer’s portable device (such as a credit card) to purchase goods or services from an accepting firm.

Figure 1 shows a system 20 that can be used in an embodiment of the invention. System 20 includes an acceptor 22 and a service bank 24 interacting with an acceptor 22. In a typical payment transaction, a consumer 30 may purchase goods or services from an acceptor 22 using a portable consumer device 32. The service bank 24 may communicate with the issuer 28 through the payment processing network 26.

Consumer 30 may be an individual or organization, such as an enterprise that is capable of acquiring goods or services.

Portable consumer device 32 may take any suitable form. For example, suitable portable consumer devices may be pocket-sized and compact so that they can be inserted into a consumer's wallet and / or pocket (e.g., be pocket-sized). These may include microprocessor-based credit cards, ordinary credit or debit cards (with and without magnetic stripe), keyfob devices (such as Speedpass ™, commercially available from Exxon-Mobil Corp.), etc. Other examples of portable consumer devices include cell phones, personal digital assistants (PDAs), pagers, payment cards, pass cards, access cards, smart storage media, transponders, and the like. Portable consumer devices can also be debit devices (e.g., debit card), credit devices (e.g., credit card), or prepaid devices (e.g., prepaid card).

The payment processing network 26 may include data processing subsystems, networks, and operations used to support and supply authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet ™. Payment processing networks such as VisaNet ™ are capable of processing credit card transactions, debit card transactions, and other types of business transactions. VisaNet ™, in particular, includes the VIP system (Visa integrated payment system), which processes authorization requests, 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 typically a powerful computer or cluster of computers. For example, a server computer can be a large mainframe, a cluster of minicomputers, or a group of servers that function as a block. 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.

The acceptor 22 may also have or may receive transmissions from the access device 34, which may interact with the portable consumer device 32. Access devices in accordance with embodiments of the invention may take any suitable form. Examples of access devices include point of sale (POS) devices, cell phones, PDAs, personal computers (PCs), tablet PCs, specialized handheld readers, television set-top boxes, electronic retail outlets (ECRs), ATMs, and virtual retail outlets (VCM), public terminals, security systems, access systems, etc.

If the access device 34 is a point of sale terminal, any suitable point of sale terminal may be used, including card readers. Card readers may include any suitable contact or non-contact mode of operation. For example, exemplary card readers may include RF (radio frequency) antennas, magnetic stripe readers, etc., for interacting with portable consumer devices 32.

In a typical purchase operation, a consumer 30 purchases a product or service from an acceptor 22 using a consumer’s portable device 32, such as a credit card. A portable consumer device 32 may interact with an access device 34, such as a POS terminal (point of sale) from an acceptor 22. For example, a consumer 30 can take a credit card and can draw it through the corresponding slot in the POS terminal. Alternatively, the POS terminal may be a proximity reader, and the portable consumer device 32 may be a proximity device, such as a proximity card.

The authorization request message is then sent to the serving bank 24. After receiving the authorization request message, the authorization request message is sent to the payment processing network 26. Thereafter, the payment processing network 26 forwards the authorization request message to the issuer 28 of the portable consumer device 32.

After the issuer 28 receives the authorization request message, the issuer 28 sends the authorization response message back to the payment processing network 26 (step 56) to indicate whether the current operation is authorized (or not authorized). Then, the payment processing network 26 forwards the authorization response message back to the service bank 24. Then, the service bank 24 sends a response message back to the acceptor 22.

After the accepting firm 22 receives the authorization response message, the access device of the accepting firm 22 may provide an authorization response message to the consumer 30. The response message may be displayed by the access device 24 or may be printed upon receipt.

At the end of the day, the payment processing network 26 may conduct a normal clearing and settlement process. The clearing process is the process of exchanging financial details between the servicing bank and the issuer in order to facilitate sending to the consumer’s financial account and reconciliation of accounts the consumer’s mutual settlement provisions. Clearing and settlement can occur simultaneously.

II Authentication of operations

Consider FIG. 2, which shows a conceptual flowchart 100, where the authentication of a purchase operation, similar to that described above, may have various aspects. Such aspects include authenticating the portable consumer device 100 (a), authenticating the consumer 100 (b), server processing including real-time risk analysis 100 (c), and notifying the consumer of the purchase transaction 100 (d).

The authentication of a portable consumer device relates to the authentication of this portable consumer device. That is, 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 operation is an authentic portable consumer device or is it a fake consumer portable device. Specific exemplary methods for improving the authentication of a portable consumer device include:

- dynamic CVV (test value of the card) on portable consumer devices, such as magnetic stripe cards;

- Card protection features (existing and new);

- contactless microcircuits (limited use);

- identification of the magnetic strip;

- verification values of cards (CVV and CVV2);

- contact microcircuits EMV.

Consumer authentication refers to determining whether the person conducting the operation is the owner or authorized user of the consumer’s portable device. Acceptor firms conduct traditional consumer authentication processes. For example, accepting firms may request that a credit card holder be presented with a driver's license before conducting a business transaction with that credit card holder. Other methods of authenticating the consumer may be desirable, since authentication of the consumer by the accepting firm does not occur in each case. Specific examples of possible ways to improve the consumer authentication process include at least the following:

- knowledge-based responses to inquiries;

- hardware markers (numerous solutions);

- OTP (one-time passwords, limited use);

- AVS (address confirmation services) (not as a standalone solution);

- signatures;

- signs of software;

- PIN (personal identification numbers) (online / offline);

- ID (identification) of users / pass codes;

- two-channel authentication processes (for example, via telephone);

- biometric characteristics.

Server processing refers to processing that may occur at the issuer, or in a payment processing network, or at another non-trading location. As will be explained in detail below, various processes can be performed in the back of the payment transaction (on the server - approx. Transl. ) To help ensure that any transactions are genuine. Server processing can also prevent operations that should not be authorized, and may allow operations that should be authorized.

Finally, consumer notification is another aspect of authenticating an operation. In some cases, the consumer may be notified that a purchase operation has been completed or completed. If the consumer is notified (for example, via a cell phone) that an operation is being performed using his consumer portable device, and the consumer is not actually conducting the operation, appropriate steps can be taken to prevent this operation from being performed. Specific examples of consumer notification processes include:

- purchase notification via SMS (short message service);

- notice of purchase via e-mail;

- notice of purchase by phone.

The following are specific details regarding some of the aspects described above. Certain details of specific aspects can be combined in any suitable way, without going beyond the essence and scope of embodiments of the invention. For example, in some embodiments of the invention, the authentication of a portable consumer device, the authentication of a consumer, server processing, and notification of consumer operation can all be combined. However, other embodiments of the invention may be directed to specific embodiments related to each of the individual aspects or to specific combinations of these individual aspects.

III. Authentication of a portable consumer device

Improvements can be made regarding various authentication processes for portable consumer devices. Examples of such enhancements are provided below.

A. Dynamic Card Values (dCVV)

To help ensure that the portable consumer device used in the payment transaction is indeed a genuine portable consumer device, “dynamic” data can be provided from the portable consumer device. Dynamic data is data that can change over time and therefore is more reliable than static data (for example, name). The authentication process of the portable consumer device may include, for example, “dynamic” verification data, such as dynamic CVV (or dynamic verification value of the card).

When comparing "static" data can be data that does not change over time. For example, credit cards currently have card verification values (CVV values) printed on the back of cards. These values can be used to verify that the portable consumer device used is genuine. For example, when conducting a purchase operation by phone or online using a credit card, the acceptor may ask for the CVV value on the back of the credit card. The CVV value can match the credit card number to ensure that the subscriber does have a genuine consumer portable device. One problem with modern CVVs is that they are static. They can be stolen and used.

Dynamic CVV ("dCVV") is described in US patent application No. 10/642878, which is incorporated herein by reference in its entirety for all purposes. US patent application No. 10/642878 describes the formation of a test value using information including PAN (primary account number), expiration date, service code and automatic transaction counter. This verification value is transferred from the accepting company to the service provider (for example, to the payment processing organization or issuer), where it is decoded and evaluated for possible approval. An automatic transaction counter monitors the number of times a consumer’s portable device is used, and if there is a discrepancy between the counter value that is received from the issuer and the counter at the issuer, this may indicate a possible fraudulent copying of data from one card to another or fraudulent use.

The dCVV value or other dynamic data can be transmitted using any suitable secure data transfer process, and DES (Dynamic Encryption Standard), like ECC (Elliptic Curve Cryptography) or AEC (Advanced Encryption Cryptography) can be used. Any symmetric or asymmetric cryptographic elements may be used.

Other dCVV processing security enhancements may include the use of a longer DES number and a longer counter.

B. dCVV created using specific input

It may be desirable to make an improvement over previous dCVV processes by generating various dynamic check values using different data or various types of varying information. For example, to verify that the portable consumer device is correct, more operation data and / or specific user data can be dynamically changed. This can be more reliable than using just a simple counter. For example, specific information may include the following: terminal ID, time of day, phone number, SIM card number, number of operations, account number, service code (two digits), expiration date, current date, random numbers from the terminal, and etc. The specific information preferably includes at least one dynamic data item, such as a counter, time of day, volume of purchases, etc. In other embodiments, the specific information used to create the dynamic check value includes dynamic customer-specific or operation-specific information, such as time of day when the transaction is completed, purchase volume, previous transaction data, etc. Some or all of them can be used to produce a test value or other specific pieces of information that can be dynamically changed to produce a new dCVV. Then, the new dCVV can be processed in a manner that is similar or different from the general processing scheme described in US patent application No. 10/642878. In one specific example, data regarding a previous transaction (eg, previous purchase volume, previous purchase time, etc.) may be a dynamic data item that can be used to authenticate a consumer’s portable device for future operations. Additional details regarding such dCVV methods can be found in US Patent Application No. ___________, entitled “Verification Assessment System and Method”, registered on the same day as this application (Attorney Dossier No. 16222U-031900US).

C. Reduction in the number of dCVV rejected operations

The dCVV processes described above are useful. However, there may be a number of examples where dynamic data (for example, a counter value) transmitted from a consumer’s portable device and received at a service provider's server does not match the corresponding dynamic data (another corresponding counter value) that is generated in the issuer’s server. For example, sometimes an accepting company cannot send transaction data to the issuer in a timely manner. If this happens, it is possible that future operations by the consumer may be overlooked or rejected. For example, if the consumer’s portable device used by the consumer has a counter in order to count the number of operations performed, and if the counter in the issuer’s server does not save the corresponding account of operations due to the delayed reception of transaction data from one or more acceptor firms, some of consumer transactions may be overlooked rejected. It is advisable to approve as many operations as possible, while at the same time not approving the operations, which may be fraudulent copying of data from one card to another.

A solution to this problem may include expanding the range of the operation counter (or expanding the tolerance of some other variable data, such as time, date, etc.) so that there is some margin of regulation for the potential error. For example, a consumer’s portable consumer device may have a counter that currently has a transaction amount of 100. When a consumer performs an operation in a POS terminal, an authorization message can be sent from the POS terminal to the issuer server or the payment processing network. An authorization message may indicate that for consumer A there is a number of operations equal to 100. The issuer server can then check the appropriate counter range. If the received operation counter falls within the appropriate range of the counter determined by the issuer, then the operation is approved. For example, the corresponding counter range may be between 98 and 102. Since the consumer counter is 100 and falls within the range between 98 and 102, the operation is approved. Thus, if the issuer's server has a counter that has a value slightly different from the counter in the consumer’s portable device, the operation will not be rejected inadvertently. If the actual fraudulent copying of data from one card to another or if the consumer’s payment account number is used without authorization, the counter in the issuer’s server is likely to differ significantly from the actual counter in the consumer’s portable device.

These embodiments of the invention can help reduce the number of false rejections of operations. As an alternative or additional criterion for establishing authenticity, the issuer may ask the consumer a security question (for example, when is your birthday) if the issuer server finds that the operation counter received from the POS terminal and the operation counter in the issuer server do not match, or if the counter is not within the predetermined range of the counter determined by the issuer's server computer. If the consumer answers the security question correctly, then the operation is authorized. If the question is not correctly answered, then it is not authorized. Further details about possible request messages and security questions that may be used in such embodiments are provided below.

In yet other embodiments, the decision on whether to perform further authentication processing (e.g., sending a security question to a consumer) or not to perform further authentication processing if the counter (or other dynamic data element) falls within a predetermined range may be based on other factors. For example, if a counter or other dynamic data element falls within a predetermined range, further authentication processing can be performed only if the analyzed operation exceeds a predetermined dollar limit (for example, over $ 1000) or the analyzed operation is carried out from a location or an accepting company that may indicate a higher tendency for fraudulent transactions. Thus, embodiments of the invention may include other variables that may be considered in determining whether to perform an additional authentication process.

Further details regarding embodiments that use ranges in connection with dynamic data elements used with test values are found in US Patent Application No. ___________ entitled "Verification Error Reduction System" registered on the same day as this application (dossier Attorney No. 16222U-031800US), which is hereby incorporated by reference in its entirety for all purposes.

D. Portable consumer devices that can produce dCVV values

A number of different consumer portable devices can be produced that are capable of providing variable operation data, such as counters. An example of this type of portable consumer device includes a magnetic stripe card that can overwrite data provided on its magnetic stripe. A dubbing device such as a magnetic recording head can be used to dub data on a magnetic strip. A patent discussing this type of card is US Pat. No. 7,044,394, which is incorporated herein by reference in its entirety for all purposes. Inside the card is a battery that can provide power for the dubbing device.

The use of batteries in payment cards is not particularly desirable in some cases. For example, batteries need to be replaced and disposed of in an environmentally friendly way. Also, if the battery-powered card does not have enough power at the moment, the specific operation being performed with this card cannot be performed as planned. In addition, if a consumer has many battery-powered cards in their wallet, this can increase potential safety concerns when traveling on airlines. Therefore, cards without batteries are preferred.

In some embodiments, portable consumer devices are battery-free cards (or other battery-free form factors) that contain (or) may contain a chip that may include a counter. These battery-free cards are powered by some external power source instead of the internal battery. Examples of external power supplies include access devices such as POS terminals and operation calculators. In embodiments of the invention, each time a card without a battery is powered by an external power source, such as a POS terminal, a counter value (or other variable data) can be generated by a card without a battery. A number of specific embodiments are shown in FIGS. 3 (a) -3 (c).

3 (a) shows a magnetic strip card 202 including a plastic body 202 (a). The magnetic strip 202 (e) is located on the plastic body 202 (a). The plastic body 202 (a) may include an extruded relief region, which may have information such as the name of the card holder, card number, and expiration date (not shown). A processor (e.g., microprocessor) 202 (b) is located on a plastic body 202 (a), and a read / write device 202 (d) and an antenna 202 (c) are connected to the processor 202 (b). In this example, the antenna 202 (c) is a coil of wire that can receive energy from a contactless credit card reader (not shown).

During use, the antenna 202 (c) may enable the magnetic stripe card 202 to communicate with an external proximity reader (not shown) so that the account number and, if necessary, counter information (or other variable data) can be obtained with magnetic strip 202 (e) through a processor 202 (b) and a read / write device 202 (d). At the same time, the antenna 202 (c) can also be used to power the processor 202 (b) and temporarily the read-write device 202 (d) so that the read-write device 202 (d) can also change dynamic data (e.g., counter) on the magnetic strip 202 (e). Thus, as illustrated by this example, embodiments of the invention may include the use of cards without batteries with a magnetic stripe that can provide dynamic data that can be used in the authentication operation of a portable consumer device.

Although the example in FIG. 3 (a) includes a reader / writer 202 (d) for the magnetic strip 202 (e), in other embodiments, a reader / writer may be implemented by logic that can read and / or write data into a volatile or semi-volatile solid state memory device, such as a flash memory chip or the like.

Another embodiment 204 of the card of the invention is shown in FIG. 3 (b). In FIGS. 3 (a) and 3 (b), like reference numerals denote like elements. However, FIG. 3 (b) shows the conductive contact region 202 (f), and the conductive contact is connected to the processor 202 (b) instead of the antenna. In this example, the contact area 202 (f) may include a plurality of electrical contacts so that they can mate and electrically come into contact with the corresponding contact area in a credit card reader (not shown). When a card 204 is used, power may be provided to the processor 202 (b) through the conductive contact 204 (f), and the read / write device 202 (d) may function as described above.

3 (c) shows another magnetic stripe card 206 in accordance with an embodiment of the invention. It includes a mating region of a reader of a portable consumer device, such as a mating region 202 (g), which may take the form of the antenna 202 (c) described above or the electrically conductive contact 202 (f). Electricity may be provided for the processor 202 (b) and the read / write device 202 (d) through the interface region 202 (g), as described above.

However, in this embodiment, a semi-static display 202 (h) is connected to the processor 202 (b). Each time the processor 202 (b) is powered by the credit card reader during the purchase operation, the processor 202 (b) may cause the display 202 (h) to display a check value, such as a dynamic check card value (dCVV). The dCVV value can be viewed by the consumer and used in ordering goods by mail, telephone, or over the Internet to help verify that the consumer has a genuine card. In this example, the same or different dCVV value (or other dynamic data) can be transmitted electronically to a credit card reader and subsequently transmitted in an authorization request message to the issuer for further verification.

FIG. 4 shows a protection device 300 that can be used to power the cards of the type shown in FIGS. 3 (a) -3 (c). The protection device 300 may have a data input area 300 (b) (e.g., a key) on the housing 300 (a). The housing 300 (a) may define a slot 300 (d) that can receive a card without a battery, similar to those described above. A display 300 (c) is also present on the housing 300 (a).

The protection device 300 may include a microprocessor, batteries, and memory containing a machine code in order to produce a one-time operation code or a number for a consumer purchase operation. The logic for producing a one-time transaction code can also reside in another server or computer (for example, in the issuer's server) so that the issuer, the acceptor or the other party can verify that the person who holds the card is indeed an eligible card holder. In this example, the security device 300 may be characterized as a reliable security feature and may be used to assist in authenticating the consumer.

During use, a consumer may insert a card without a magnetic stripe battery (as described above) into slot 300 (d). Then, a one-time operation code may be displayed on the screen 300 (c). When the card is inserted into the security device 300, energy from the power source in the security device 300 powers the processor and the reader / writer in the card so that dynamic data (eg, counter) on the card can change. Thus, the protection device 300 can produce a one-time operation number for the operation, as well as temporarily provide power to the card without the battery so that the counter in the card (or other dynamic element) can change. A system using both the security device 300 and a card without a battery, which may have dynamic data, can favorably authenticate both the consumer and the portable consumer device.

Further details regarding embodiments that use portable consumer devices without batteries are found in US Patent Application No. ___________ entitled "Portable Consumer Device without Battery" registered on the same day as this application (Attorney Dossier No. 16222U-031700US), which is incorporated herein by reference in its entirety for all purposes.

E. Disguised Primary Account Numbers (PAN)

Another way to authenticate a portable consumer device is to use a masked PAN or primary account number. In this example, a partial portion of the transmitted PAN is masked and / or dynamically changed. The PAN includes an identification number portion, such as a BIC number or bank identification code. Other examples of ID numbers include the location of the acceptor, the location of the financial institution, or even the IP address. The last four digits of the PAN and the NIR numbers will remain the same, while the other numbers in the PAN will change. These dynamically changing numbers usually disguise upon receipt of the payment card that the consumer receives, so that the consumer does not see anything unusual.

5 shows a schematic representation of data fields for data that is transferred from an acceptor to an issuer in a purchase operation. Data fields include PAN fields, expiration dates, service code, CVV PIN, and discretionary data.

An exemplary PAN 380, which may reside in memory (e.g., on a magnetic strip) in a portable consumer device, is shown in FIG. 6. In this example, the first six digits (i.e., the first terminal portion) of “123456” 380 (a) of the PAN number 380 may correspond to the NIR number. The next 6 digits 380 (b) may be variable or different from the 6 digits of the real PAN and in this example are represented as "XXXXXX". The last four digits 380 (c) (that is, the last terminal portion) in this example are “9999”, and they can remain the same. If the BIC is kept the same and the last four digits are the same, the operation looks real for the acceptor and consumer. In a preferred embodiment, the middle six digits are dynamically changed using a counter or the like. This makes it more difficult for any unauthorized person to determine the real PAN.

In one embodiment, the middle portion of the PAN that resides in the memory of the portable consumer device may differ from the middle portion of the real PAN. A PAN number that resides in memory may be referred to as a secondary PAN, while a real PAN may be referred to as a primary PAN. An appropriate algorithm or lookup table (for example, stored by the issuer or in an access device such as a POS device) can be used to associate the primary and secondary PAN numbers. For example, the middle six digits of the PAN number in the primary PAN may be 666666 (e.g. 1234566666669999), but in the secondary PAN, which is stored in a storage device located in the consumer's portable device, the middle six digits may be 222222 (e.g. 1234562222229999). In one embodiment, the secondary PAN may be received at the POS terminal, and the POS terminal may convert the secondary PAN to the primary PAN, and the primary PAN may be transferred from the POS terminal to the issuer for processing and / or authorization. In another embodiment, a secondary PAN may be transmitted to the issuer, and the issuer may convert the secondary PAN to the primary PAN and thereafter may process and / or authorize the operation.

In this embodiment, the issuer can receive both the primary PAN and the secondary PAN to verify that the portable consumer device used is genuine. If an unauthorized person tries to use a primary PAN, then this unauthorized person will not know the secondary PAN and will not be able to fraudulently conduct a purchase operation without knowledge of the secondary PAN. Alternatively, if an unauthorized person electronically intercepts or “fraudulently copies” a secondary PAN, the unauthorized person will not be able to conduct a purchase operation without knowledge of the primary PAN.

In another embodiment, the middle portion of the PAN may change dynamically. For example, an appropriate algorithm or counter may be used to dynamically change the middle portion of the PAN each time a portable consumer device is used. Thus, even if the PAN is electronically intercepted by an unauthorized person and knows the primary PAN, the secondary PAN will dynamically change. Even if an unauthorized person knows the primary PAN and intercepts the secondary PAN once, an intercepted secondary PAN can be useless, because it is a dynamically changing secondary PAN. In this case, an unauthorized person needs to know the algorithm used to dynamically change the PAN, in addition to the primary PAN and secondary PAN. Thus, this embodiment is particularly useful for conducting secure operations.

Further details regarding embodiments that use masked primary account numbers are found in US Patent Application No. 11/761821, entitled "Encrypting Path Data", filed June 12, 2007, which is incorporated herein by reference in its entirety for all purposes.

VI Consumer authentication

As noted above, a number of consumer authentication processes may be used in embodiments of the invention. Specific examples of possible ways to improve consumer authentication include:

- knowledge-based responses to inquiries;

- signs of hardware (numerous solutions);

- OTP (one-time password, limited use);

- AVS (not as an independent solution);

- signatures;

- software markers;

- PIN (online / offline);

- user ID / passcodes;

- two-channel authentication via telephone;

- biometrics.

As illustrated above, a variety of mechanisms can be used to authenticate the consumer, and these mechanisms can use the consumer’s non-input (e.g., an automatic software security token), limited consumer input (e.g., the consumer presses a button), or full consumer input (e.g., biometrics).

In addition, a variety of “security tokens” can be used to help authenticate the consumer. A security token is a paragraph or piece of information that can be used to verify real information or data. For example, a PIN can be a security token and can be used to verify consumer identity when a consumer makes a purchase. In another example, the security question and the corresponding answer can be seen as a security token that helps establish the identity of the consumer. This last example is an example of a token having a “bidirectional channel” whereby information flows to the consumer and the consumer sends information back to the other side, such as the issuer, so that the consumer can authenticate himself.

A. Knowledge-based queries

In embodiments of the invention, the accepting firm, the payment processing organization, the issuer, or any other appropriate entity may formulate security questions for the consumer in order to establish the authenticity of the consumer. Test questions can be static, where the same questions are asked for each purchase operation, or dynamic, where over time you can ask different questions.

Asked questions can also have static or dynamic (semi-dynamic or fully dynamic) answers. For example, the question "When is your birthday?" requires a static response because the response does not change. Question "What is your zip code?" requires a semi-dynamic response, because it could change or can sometimes change. Finally, the question "What did you buy yesterday at 4 pm?" may require a dynamic response, as the response often changes. Thus, in preferred embodiments, the control questions can preferably be based on “real-time” information that the issuer is most likely to have. For example, a consumer may be asked a more specific question, such as "Did you eat at a Mexican restaurant last night?" By providing more specific knowledge-based queries to the consumer, consumer authentication is guaranteed.

In one embodiment, the method includes conducting an operation, such as a purchasing operation, using a portable consumer device. A portable consumer device may be a credit card or similar device. The purchase operation may be performed at an accepting firm that has 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 initiate a process. The point of sale terminal can initiate and then generate an authorization request message, which can then be sent to the payment processing network and subsequently to the issuer of the consumer’s portable device. When a message with an authorization request is received either by the payment processing network or by the issuer, it is analyzed. After that, a request message, which may be dynamic or semi-dynamic, is generated and sent to the consumer. The request message can be sent back to the access device or to the portable consumer device (for example, if the portable consumer device is a mobile phone).

Then the consumer provides a response to the request message. The response message to the request is received from the consumer. Then, the response message to the request is checked, and if it is checked, the authorization response message is analyzed to determine whether the operation is subject to authorization (for example, whether there are sufficient funds in the consumer’s financial account or if there is sufficient credit in the consumer’s financial account). If the transaction is authorized, the issuer, as well as the payment processing network, sends a validation response message to the consumer. An authorization response message indicates whether the operation is authorized or not.

In the specific embodiments described above and below, control 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 request messages, which may include security questions. In some embodiments, implementation, as will be described below with further details, request messages may or may not be read by the consumer and may challenge the authenticity of the consumer in direct or indirect ways. Examples of security questions include questions related to a consumer’s portable device (for example, which CVV or card verification value on your card?), The location of the consumer (for example, what is your ZIP code?), The consumer’s mobile or regular telephone (for example what is your mobile phone number?), personal information of the consumer (for example, what is your mother’s maiden name?), etc. Examples of request messages that are not questions that the consumer specifically answers include messages that automatically ask the phone for its location or phone number and cause that information to be retrieved. Another example of a request message may be a message that delivers a code (or other sign of authentication) to the telephone, and using this code in the access device authenticates the consumer.

B. Systems using request messages

7 shows an example system 420 in accordance with an embodiment of the invention. Other systems in accordance with other embodiments of the invention may include more or less components than shown in FIG.

The system 420 shown in FIG. 7 includes an acceptor 422 and a service bank 424 associated with the acceptor 422. In a typical payment transaction, a consumer 430 may purchase goods or services from an acceptor 422 using a consumer portable device 432 . Serving bank 424 may communicate with the issuer 428 through a payment processing network 426.

Consumer 430 may be an individual or organization, such as a merchant, that is capable of acquiring goods or services. In other embodiments, consumer 430 may simply be a person who wants to perform some other type of transaction, such as a money transfer operation. Consumer 430 may, if required, use a cordless telephone 435.

Portable consumer device 432 may take any appropriate form. Suitable portable consumer devices are described above in FIG. 1 (for example, portable consumer device 32).

The payment processing network 426 may be similar or different from the payment processing network 26 shown in FIG. As shown in FIG. 7, the payment processing network 426 may comprise a server 426 (a), which may comprise a security question mechanism 426 (a) -1. The server 426 (a) may also be in communication with the operation history data base 426 (b) and the security question database 426 (c). As will be explained in more detail below, the security question mechanism 426 (a) -1 may simply retrieve the security questions from the security data base 426 (c). Alternatively or additionally, the security questions engine 426 (a) -1 may generate security questions using the information found in the transaction history data base 426 (b).

As will be explained in more detail below, the control questions may be static or dynamic. For example, checklist mechanism 426 (a) -1 may receive an authorization request message, and the authorization request message may include a consumer account number as well as a purchase volume. Then he can look up the consumer’s account number and any consumer information related to that consumer’s account number. After that, he can extract the relevant questions from the base 426 (c) of the data of the security questions or he can generate the relevant security questions himself. For example, in some cases, the 426 (a) -1 security question mechanism may retrieve the question, "What is your mobile phone number?" from the database 426 (c) of the data of control questions after receiving a message requesting authorization. Alternatively, mechanism 426 (a) -1 of security questions can generate a dynamic question, such as "Did you use this credit card at McDonald's last night?" Information related to the particular restaurant where the consumer 420 was on the previous day can be retrieved from the transaction history database 426 (b).

Base 426 (c) of these security questions can be filled with questions of any suitable type. Questions may relate to the past location (e.g., the current home of the consumer, the city that the consumer recently visited) or the current location (e.g., the current location of the store where the consumer is currently located), the type or name of the accepting company, which the consumer is currently visiting or has visited in the past, the name of the consumer or personal data (e.g. name, phone number, social security card number, etc.), etc. Questions in database 426 (c) of these security questions can be generated by mechanism 426 (a) -1 of security questions and subsequently stored in database 426 (c) of these security questions.

Alternatively or additionally, control questions may be generated from an external source and then stored subsequently in the database 426 (c) of these control questions. For example, consumer 430 may use a browser on a personal computer or similar device to provide specific security questions for server 426 (a) through a communication medium (not shown) such as the Internet.

In some embodiments, the consumer may determine the types and / or number of control questions that he or she should be asked. For example, a consumer may determine that he wants to be asked three security questions if the consumer visits the jewelry store, but only one question if he visits the fast food restaurant. The types of questions posed by the consumer can be based on the type of establishment, frequency of purchases, etc. Some concepts related to user-defined validation parameters are described in US Patent Application No. 10/093002, filed March 5, 2002, which is incorporated herein by reference in its entirety for all purposes.

In preferred embodiments, control questions are obtained from past transaction data in a transaction history database 426 (b). Consumer 430 may, for some time, perform many operations with payment processing network 26 (and / or issuer 428). This consumer transaction information may be stored in the transaction history database 426 (b) for some time, and control questions may be generated using the transaction information. Information about past transactions provides a good basis for authenticating consumer 430, as consumer 430 will know about transactions that consumer 430 conducted in the past. For example, a 430 consumer could use his credit card to pay for a hotel room in New York on the previous day, and the next day he might be asked a question such as "Did you stay at a hotel in New York yesterday?" In another example, a consumer 430 may have bought a separate item the day before that had a value in excess of $ 2,000, and the next day he might be asked the question "Did you make a purchase worth more than $ 2,000 yesterday?" The questions / answers that are presented to the consumer 430 may be free and / or may include pre-formatted answers, such as multiple choice or right-wrong answers, from which the consumer can choose.

The acceptor 422 may also have or may receive transmissions from the access device 434, which may interact with the portable consumer device 432. Appropriate types of access devices are described above (for example, access device 34 in FIG. 1).

If the access device 434 is a point of sale terminal, any suitable point of sale terminal may be used, including credit card readers. Credit card readers may include any appropriate contact or non-contact mode of operation. For example, exemplary credit card readers may include RF (radio frequency) antennas, magnetic stripe readers, etc., to interact with portable consumer devices 432.

Issuer 428 may be a bank or other organization that may have a financial account associated with consumer 430. Issuer 426 may manage a server 428 (a), which may have a 428 (a) -1 security question mechanism. The operation history database 426 (b) and the security question database 428 (c) may be connected to the server 428 (a). The issuer's server 428 (a), security questions mechanism 428 (a) -1, transaction history data base 426 (b) and security questions database 428 (c) may work in the same or different way from the payment processing network server 428 (a) , a mechanism 428 (a) -1 for creating security questions, a database 428 (b) of transaction history data and a database 428 (c) for security questions. In the above descriptions, elements 428 (a), 428 (a) -1, 428 (b) and 428 (can be used as elements 426 (a), 426 (a) -1, 426 (b) and 426 (c) c)

Embodiments of the invention are not limited to the embodiments described above. For example, although separate functional blocks are shown for the issuer, the payment processing network, and the servicing bank, some objects perform all or any appropriate combination of these functions and may be included in embodiments of the invention. Additional components may also be included in embodiments of the invention.

C. Methods using request messages

The methods in accordance with embodiments of the invention may be described with reference to FIGS. 7 and 8. In a typical purchasing operation, a consumer 430 purchases a product or service from an acceptor 422 using a consumer portable device 432, such as a credit card. The portable consumer device 432 may interact with an access device 434, such as a POS terminal (point of sale terminal) at the acceptor 422 (step 502). For example, consumer 430 can take a credit card and can draw it through the corresponding slot in the POS terminal. Alternatively, the POS terminal may be a proximity reader, and the portable consumer device 432 may be a proximity device, such as a proximity card.

Then, the first authorization request message is sent to the service bank 424. After the service bank 424 receives the first authorization request message, the first authorization request message is then sent to the payment processing network 426 (step 504). Then, the first authorization request message is received in the payment processing network server 426 (a), and the payment processing network server 426 (a) determines whether the request is necessary.

Various criteria can be used to determine if a query is needed. For example, the payment processing network server 426 (a) may determine that the particular operation is a high-cost operation (for example, more than $ 1000) and that therefore the request is appropriate. In another example, the payment processing network server 426 (a) may determine that there is something suspicious of the operation presented, and then may determine that the request is appropriate. For example, the payment processing network server 426 (a) may determine that the consumer’s portable device 432 is currently being used at a location that is different from the consumer’s home position, and the latest consumer shopping history indicates that the consumer is not moving.

Once it has been determined that the request for the operation is appropriate, then the security question mechanism 426 (a) -1 may cause (locally or remotely) a security question (step 508). In some embodiments, the implementation of the mechanism 426 (a) -1 security questions can retrieve the question from the database 426 (c) of data security questions.

At this stage, instead of sending the first authorization request message to the issuer 426, the payment processing network 426 sends the first authorization response message back to the access device 434 through the acceptor 422 and the service bank 424 (step 510). The first validation response message may contain data representing a security question that was previously received by the security question engine 426 (a) -1. The first validation response message may be characterized as an initial rejection, since it does not indicate approval of the operation.

Once a security question is received at access device 434, consumer 430 provides a response to the request to access device 434. The response to the request may be provided to the access device 434 in any appropriate way (for example, via a keyboard, contactless reader, etc.). As soon as the access device 434 receives the response to the request, the access device 434 sends the response to the request to the payment processing network server 426 (a) through the acceptor company 422 and the service bank 424 and is received by them (step 512). The response message to the request may be part of a second authorization request message.

Then, the payment processing network server 426 (a) approves the response message to the request (step 514). If the response message to the request is not approved, then the payment processing network server 426 (a) may send a response message back to the access device 434 indicating that this operation is not approved. Alternatively or additionally, the payment processing network server 426 (a) may send another security question to the access device 434. On the other hand, if the request is approved, the payment processing network server 426 (a) may send a second authorization request message to the issuer 428 (step 516) along with an indication that the consumer 430 has satisfactorily answered all the requests made by the payment processing network 426.

After the issuer 428 receives the second authorization request, the issuer 428, using the issuer's server 428 (a), determines whether the operation is authorized or not (step 518). The operation may not be authorized because consumer 430 has insufficient funds or credit. If the consumer 430 has sufficient funds or credit, then the issuer 428 may send a second authorization response message indicating that the operation is authorized, back to the access device 434 via the payment processing network 426 serving the bank 424 and the acceptor 422 (step 522).

Finally, the payment processing network 426 may conduct a normal clearing and settlement process. The clearing process is a process of exchanging financial details between a servicing bank and an issuer in order to facilitate sending to a consumer’s financial account and reconciliation of accounts of a consumer’s mutual settlement position. Clearing and settlement can occur simultaneously.

A number of alternative embodiments are also possible. For example, issuer 428 may generate security questions and send them to consumer 430 instead of or in addition to payment processing network 426. Security engine 428 (a) -1, operations history data base 428 (b) and security questions database 426 (c) managed by issuer 428 may be used in the same or different way from the security engine 426 (a) -1 described above issues, database 426 (b) of transaction history data and database 426 (c) of data in doubt, managed by the payment processing network 426.

In the above embodiments, there are two authorization request messages that are sent to the payment processing network 426 (and / or to the issuer 428). This is desirable because existing payment processing systems have “timers” that are set at various points between the access device 434 and the issuer 428 during the payment authorization process. Timers control how long various events should be carried out during the payment authorization process. Timers can be set and implemented as machine code in a service bank 424, a payment processing network 426 and an issuer 428. For example, timers in a service bank 424, a payment processing network 426 and an issuer 428 can be set, respectively, for 3 seconds, 6 seconds and 10 seconds. If the authorization request message is not received during these respective time periods, some event may be triggered. For example, an error message may be sent back to access device 434 requiring the acceptor 422 to resubmit the authorization request message if the authorization request message is not received from issuer 428 within 10 seconds. If a control request is created during the authorization process and before the message with the authorization request reaches the issuer 428, the issuer timer may trigger an event indicating that an error has occurred. The creation of inquiries in doubt and responses during a single authorization process could potentially conflict with previously existing timers in the payment system.

When using at least two Validation Request messages in two separate Validation processes, the timers described above are not favorably affected by this. Timers should not be changed in order to send control questions to consumer 430. This makes it possible to use embodiments of the invention with the existing payment infrastructure, and extensive changes to embodiments of the invention are not required. In comparison, if a security question is searched during the payment authorization process using a single message requesting authorization, this may delay the message requesting authorization and may require changes to timers existing in the payment processing system.

At least two authorization request messages may have information such as BIC (bank identification codes), transaction numbers, account numbers, service codes, etc. They may also contain the same number of operations for the operation to be performed and / or different numbers of operations. For example, the first authorization request message may have an actual number of operations, and the second authorization request message may have a zero number of dollars or another identifier to indicate that this previous authentication request with the number of operations has already been submitted. In some embodiments, an operation code may be used to associate the first and second authorization requests.

The method described with respect to FIG. 8 may be characterized as a “closed channel” process since the access device 434 receives a security question and provides an answer to the security question. However, other embodiments of the invention may utilize open channel solutions whereby a security question may be sent to a device other than the access device that sent the first authorization response message.

Examples of open channel methods in accordance with embodiments of the invention may be described with reference to FIGS. 7 and 9. In a typical purchasing operation, a consumer 430 buys a product or service from an acceptor 422 using a portable consumer device 432, such as a credit card. The portable consumer device 432 may interact with an access device 434, such as a POS terminal (point of sale terminal) at the acceptor 422 (step 602). 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 proximity reader, and the portable consumer device 432 may be a proximity device, such as a proximity card.

Then, the first authorization request message is sent to the serving bank 424. After receiving the first authorization request message, the first authorization request message is then sent to the payment processing network 426 (step 604). The first authorization request message is received at the payment processing network server 26 (a), and the payment processing network server 426 (a) then determines whether the request is needed.

Various criteria can be used to determine if a query is needed. For example, the payment processing network server 426 (a) may determine that the particular operation is a high-cost operation (for example, more than $ 1000) and that therefore the request is appropriate. In another example, the payment processing network server 426 (a) may determine that there is something suspicious of the operation presented, and then may determine that the request is appropriate.

Once it has been determined that the request for the operation is appropriate, the security question mechanism 426 (a) -1 may then raise (locally or remotely) the security question (step 608). In some embodiments, the implementation of the mechanism 426 (a) -1 security questions can retrieve the question from the database 426 (c) of data security questions.

Instead of sending the first authorization request message to the issuer 426 and sending the first authorization response message back to the access device 434, the payment processing network 426 sends the first authorization response message back to the consumer’s mobile phone 435 (step 610) or another type of access device. The first authorization response message may be sent back to the consumer’s mobile phone 435. This can be done directly or through some intermediate object. The first Validation Response message may contain data representing a test request that we previously received using the 426 (a) -1 security question mechanism. The first authorization response message may be characterized as an initial rejection, since it does not indicate authorization of the operation.

As soon as the security question is received on the mobile phone 435, the consumer 430 provides a response to the request to the access device 434 (step 612). Then, the access device 434 forwards the response to the request to the payment processing network server 426 (a) through the accepting company 422 and the service bank 424, and it is received by them (step 614). The response message to the request may be part of a second validation response message.

Note that although the control questions to which the consumer actively answers are described in detail, other types of control requests can be sent to the mobile phone 435. For example, in some cases, control requests may not require a response that is actively provided by the consumer 430. Passive responses may be provided to control requests. For example, in some embodiments, a control request transmitted to mobile phone 435 may be a request for the physical location of mobile phone 435. Mobile phone 435 may have a GPS (Global Positioning System) device or other location device, and this information (or cryptogram etc.) can be transmitted to the payment processing network 426, and the payment processing network 426 can authenticate the consumer 434 using this location information and.

As soon as the payment processing network server 426 (a) receives the response message to the request, the payment processing network server 426 (a) checks the correctness of the response message to the request (step 616). If the response message to the request is not approved, then the payment processing network server 426 (a) may send a response message back to the access device 434 indicating that this operation is not authorized. Alternatively or additionally, the payment processing network server 426 (a) may send another request message to the access device 434 and / or mobile phone 435. On the other hand, if the request is approved, the payment processing network server 426 (a) can then send a second authorization request message to the issuer 428 (step 618) along with an indication that the consumer 430 satisfactorily answered all the requests set forth by the payment processing network 426.

After the issuer 428 accepts the second authorization request, the issuer 428, using the issuer server 428 (a), determines whether the operation is authorized or not authorized (step 620). The operation may not be authorized because consumer 430 has insufficient funds or credit. If the consumer 430 has sufficient funds or credit, then the issuer 428 may send a second authorization response message indicating that the operation is authorized, back to the access device 434 via the payment processing network 426 serving the bank 424 and the acceptor 422 (step 622).

At the end of the day, the payment processing network 426 may conduct a normal clearing and settlement process. The clearing process is a process of exchanging financial details between a servicing bank and an issuer in order to facilitate sending to a consumer’s financial account and reconciliation of accounts of a consumer’s mutual settlement position. Clearing and settlement can occur simultaneously.

A number of alternative embodiments are also possible. For example, issuer 428 may generate security questions and send them to mobile phone 435 instead of or in addition to payment processing network 426. Security mechanism 428 (a) -1, transaction history data base 428 (b) and security questions database 426 (c) managed by issuer 428 may be used in the same or different way from the above security mechanism 426 (a) -1 questions, database 426 (b) of transaction history data and database 426 (c) of data of security questions managed by the payment processing network 426.

In another embodiment, instead of sending a security question to the server 426 (a) of the payment processing network, an electronic coupon may be sent to the consumer’s mobile phone 435. The payment processing network 426 may determine that the request is appropriate and may send an electronic coupon to the telephone 435. When receiving this electronic coupon, the consumer may be prompted to use the coupon in the access device 434. If the consumer 430 uses the coupon in the access device 434, then the access device 434 sends the coupon to the payment processing network 426 and the receipt of the coupon by the payment processing network 426 indicates that the authenticity of the consumer 430 is established. Consumer 430 is assumed to be genuine since an unauthentic consumer cannot own a consumer phone 435.

Further details regarding the embodiments that utilize the requests are described in US Patent Application No. 11/763240 entitled "Consumer Authentication System and Method", filed June 14, 2007 (Attorney Dossier No. 16222U-031600US), which is incorporated herein by reference in its entirety for all purposes.

VII. Other authentication procedures

A. Methods Using Algorithm Identifiers

In embodiments of the invention, a payment processing organization or other entity may support various security technologies offered by various companies. Various security technologies may use the identification tags of a portable consumer device. For example, two magnetic strips on two payment cards can store identical consumer data (for example, account number information), but the magnetic structures of these two magnetic strips can be different. A specific magnetic structure may be an example of an identification tag or “DNA” that is associated with a payment card. If a thief has copied consumer data stored on a magnetic strip onto an unauthorized credit card, the magnetic strip of the unauthorized credit card will have a different magnetic structure or identification mark from the authorized credit card. The processing server, when receiving an authorization request message in response to the use of an unauthorized card, can determine that the unauthorized credit card is not valid because the identification tag is not present in the authorization request message. The two companies that offer this type of technology are Magtek ™ and Semtek ™. Each company uses its own algorithm in the terminal of the outlet to change (for example, encrypt) its own identification tag before sending it to the issuer or other object in the subsequent authentication process.

In embodiments of the invention, the identification tag of the portable consumer device may include any appropriate identification mechanism that provides the ability to identify the portable consumer device, regardless of static consumer data, such as account number or expiration date associated with the portable consumer device. Typically, unlike consumer data, the identification data of a portable consumer device is not known to the consumer. For example, in some embodiments, the identification tag data may relate to the characteristics of the materials of which the portable consumer devices are made. For example, as noted above, the identification tag of a portable consumer device can be embedded inside a specific microstructure of magnetic particles in a magnetic strip in a payment card. In some cases, the two magnetic strips will not have the same identification tag of the portable consumer device.

Identification marks of a portable consumer device may take other forms. For example, another card verification technology comes from QSecure ™. The technology offered by QSecure ™ uses dynamic CVV (card verification value), which can be generated by the chip in the payment card (the chip can be under the magnetic stripe and can record the dynamic CVV or the number associated with the dynamic CVV on the magnetic stripe). In this case, the dynamic CVV may act as an identification mark of a portable consumer device identifying a particular portable consumer device. A dynamic CVV may be sent to a point of sale device during a payment transaction. A particular algorithm in a point-of-sale device may modify (e.g., encrypt) a dynamic CVV before sending it to a payment card issuer for authorization. An issuer, a payment processing organization, or other entity may accept a modified dynamic CVV and may restore it to its original form. Then, the dynamic CVV can be checked by the server of the processing side to see if it matches the obtained dynamic CVV independently, thereby authenticating the portable consumer device. In this example, the dynamic value of CVV can also be considered as an identification mark of a portable consumer device, even though it is dynamic in nature.

Embodiments of the invention take into account many different types of identification tags of portable consumer devices to be used together in a single payment processing system. In embodiments of the invention, a different identifier or ID is allocated for each type of algorithm in each type of POS terminal. For example, a processing party entity, such as an issuer or a payment processing organization, may use algorithm identifiers similar to those presented in the table below.

Algorithm ID Algorithm description 01 Company A Magnetic Stripe Identification Tag Encryption Algorithm 02 Company B magnetic stripe identification tag encryption algorithm 03 Company C Dynamic CVV Encryption Algorithm

As shown in the table, the algorithm ID can take any appropriate form. For example, an algorithm ID may simply be numbers of one, two, or three digits.

When the POS terminal sends an authorization request message to the issuer, the authorization request message may contain a specific algorithm ID associated with the POS terminal and the changed identification tag of the portable consumer device. When the authorization request message is received by the server of the processing side, it can determine which algorithm was used to encrypt the identification tag of the portable consumer device. The server of the processing side can then decrypt the encrypted identification tag of the portable consumer device and can determine whether the identification tag of the portable consumer device matches the identification tag of the portable consumer device, which is stored in the database of the processing side. The identification mark of the portable consumer device may be pre-stored in the database of the processing side along with the corresponding consumer data (for example, account number) as part of the process of releasing the portable consumer device to the consumer who will use it.

Through the use of such algorithm identifiers, embodiments of the invention can efficiently integrate various technologies into a single payment processing system. For example, a consumer can swipe a payment card through a POS terminal (point of sale terminal) to pay $ 5.00 for office supplies. The POS terminal may contain an encryption algorithm produced by company A. The encryption algorithm may encrypt an identification tag that is embedded in the magnetic structure of a magnetic stripe payment card. The POS terminal can then send an authorization request message to the server of the processing side. The authorization request message may include information including the volume of purchases, consumer data, such as the customer account number, an encrypted identification tag, and an algorithm identifier that is specifically associated with the encryption algorithm produced by company A. The server of the processing side may receive an authorization request message from the POS terminal (point of sale terminal). He can then determine which algorithm was used to encrypt the identification tag, and subsequently can decrypt this identification tag. Once the identification tag is determined, the server of the processing side can determine whether the received identification tag matches the stored identification tag. If so, then the authenticity of the payment card is established.

Other details regarding the methods and systems that use the algorithm identifier are provided below.

B. Ways to measure confidence

In some embodiments, the processor of the processing side, or the server of the processing side, may also determine whether the operation meets the desired confidence threshold of possible confidence before determining that the portable consumer device is genuine. If it does not meet the threshold of trust, additional authentication processes may be performed. Such additional authentication processes may include sending one or more security questions and / or notification messages to the consumer.

As an illustration, the server of the processing side may receive an authorization request message from the POS terminal after the consumer tries to pay for office supplies using a payment card. The server of the processing side can determine that one of the three card verification technologies listed in the table is present, and that there were no new suspicious transactions associated with this payment card. The server of the processing side can then determine that the operation is valid (that is, the condition of the confidence threshold has been satisfied) and can continue if the operation is otherwise authorized by the issuer of the payment card. And vice versa, if the old (traditional) card and reader are used for the operation, none of the three card protection technologies from the table (above) is used and there was a new suspicious action related to the payment card, then the server of the processing side determines that the trust threshold condition was not satisfied, and additional authentication processes may be initiated by the server. For example, a dynamic request (question) may be sent to the consumer prior to approval, and / or the consumer may be notified that the operation is being completed.

Operation confidence definitions can also take into account whether one algorithm can be more reliable than another. The server of the processing side can evaluate the algorithm that was used in the data processing device (for example, in the POS terminal), and can determine whether the operation should really continue. For example, the server of the processing side may determine that the algorithm from company A may have a reliability of 90%, and the algorithm from company B may have a reliability of 50%.

There are a number of reasons why different algorithms may have different levels of reliability. For example, depending on the sensitivity of the terminal, depending on the method by which the card is conducted, and depending on the aging of the card, some algorithms may be able to manipulate the data more accurately. In this example, if the server receives an authorization request message indicating that there is an algorithm from company B and there has been a new suspicious activity associated with this payment card, then additional authentication processing may be triggered. On the other hand, if the server receives an authorization request message indicating that there is an algorithm from company A and there has been a new suspicious activity, then the server of the processing side may not initiate an additional authentication process.

As an illustration, McDonalds may be related to company A, and Taco Bell may be related to company B. They can use various algorithms in their outlets. Each delivers two data sets using two different algorithms. When they return to a payment processing organization such as Visa, it can identify the data as arising from the algorithm of company A and / or from the algorithm of company B. A weighting factor can be imposed on the algorithms so that the level of trust can be determined. Then, additional authentication processing may be performed if the condition of the level (or threshold) of trust is not satisfied.

C. Exemplary Systems Using Algorithm Identifier and Trust Rating

10 (a) shows a system 720 that can be used in an embodiment of the invention. System 720 includes a plurality of acceptor firms 722 (a), 722 (b), 722 (c) and a plurality of service banks 724 (a), 724 (b), 724 (c) associated with acceptor firms 722 (a ), 722 (b), 722 (c). In typical payment transactions, consumers 730 (a), 730 (b), 730 (c) can purchase goods or services at accepting firms 722 (a), 722 (b), 722 (c) using their portable devices 732 (a ), 732 (b), 732 (c) of the consumer. Consumers 730 (a), 730 (b), 730 (c) may be individuals or organizations, such as enterprises. Serving banks 724 (a), 724 (b), 724 (c) can communicate with issuers 728 (a), 728 (b), 728 (c) through a payment processing network 726. Issuers 728 (a), 728 (b), 728 (c) can respectively produce portable devices 732 (a), 732 (b), 732 (c) for consumers 730 (a), 730 (b), 730 (c).

For purposes of illustration, access device A 732 (a) may be manufactured by company A, which may be associated with an algorithm with algorithm identifier “01”. Access device B 732 (b) may be manufactured by company B and may be associated with an algorithm with algorithm identifier “02”. Access device C 732 (c) may be associated with company D and may not have any algorithm associated with it.

Portable consumer devices 732 (a), 732 (b), 732 (c) of the consumer may take any appropriate form. For example, suitable portable consumer devices 732 (a), 732 (b), 732 (c) can be pocket-sized and compact so that they can be inserted into a consumer's wallet and / or pocket (e.g., pocket-sized). Suitable portable consumer devices are described above (for example, portable consumer device 32 in FIG. 1).

Acceptor firms 722 (a), 722 (b), 722 (c) may also have or may receive communications from respective access devices 734 (a), 734 (b), 734 (c), which may interact with portable devices 732 (a), 732 (b), 732 (c) of the consumer. Suitable types of access devices are described above (for example, access device 34 in FIG. 1).

If the access device is a point of sale terminal, any appropriate point of sale terminal may be used, including credit card readers. Credit card readers may include any appropriate contact or non-contact mode of operation. For example, exemplary credit card readers may include RF (radio frequency) antennas, magnetic stripe readers, etc., to interact with consumer portable devices 732 (a), 732 (b), 732 (c).

The payment processing network 726 may include any of the characteristics described above (for example, with respect to the payment processing network 26 in FIG. 1). It may include server computer 726 (a).

Server computer 726 (a) may contain any suitable number of software modules, and they may be of any suitable type. As shown in FIG. 10 (b), the server computer 726 (a) may comprise an algorithm identification module 726 (a) -1 and a trust assessment module 726 (a) -2. It may also contain a decryption module 726 (a) -3, as well as a data formatting module 726 (a) -4.

Algorithm identification module 726 (a) -1, together with decryption module 726 (a) -3, can view a received authorization request message including an algorithm ID and a changed identification tag of a portable consumer device. From the received algorithm ID, it can then determine which algorithm was used to change (e.g., encrypt) the identification tag of the portable consumer device. A lookup table or similar means may be used to identify the correspondence between the algorithm ID, the algorithm (s) used to change the identification tag of the portable consumer device, or to restore the changed identification tag of the portable consumer device and consumer data (e.g., account number). (In some cases, the algorithm may be the key in the encryption process.) Then, the server computer 726 (a) can be used to determine (for example, by decryption) the identification mark of the portable consumer device from the changed identification label of the portable consumer device in the authorization request message. Once the identification tag of the portable consumer device is determined, this information can be analyzed to determine whether it matches the stored identification tag associated with the consumer data (e.g., account number) associated with the portable consumer device.

Confidence assessment module 726 (a) -2 may generate a confidence assessment from various pieces of information. Such information may include the type of portable consumer device used (for example, a telephone may be more reliable than a payment card), the type of algorithm used to encrypt the identification tag of a portable consumer device (for example, some encryption algorithms are more reliable than others), etc. Using the trust assessment module 726 (a) -2, the server computer 726 (a) can subsequently determine whether additional authentication processes are required. Such additional authentication processes may include questions in doubt and / or notice to the consumer that the operation is in progress.

Confidence assessment module 726 (a) -2 may “evaluate” an operation based on a number of operation variables. If this estimate exceeds a predetermined threshold, then the operation can be considered valid and additional authentication processing is not required. Conversely, if the rating does not exceed a predetermined threshold, then the operation can be characterized as suspicious and additional authentication processes can be initiated.

Module 726 (a) -4 data formatting can be used to format the data so that they can be used by module 726 (a) -2 confidence assessment. In some cases, the data that comes from different POS terminals from different companies can be decrypted by decryption module 726 (a) -3 and can be in different formats. The data formatter can format any data so that it can be used by the trust assessment module 726 (a) -2.

Embodiments of the invention are not limited to the embodiments described above. For example, although individual functional blocks are shown for the issuer, the payment processing network, and the service bank, some objects perform all of these functions and can be included in embodiments of the invention.

D. Exemplary Use of Identification Marks and Identifiers

Various methods in accordance with embodiments of the invention may be described with reference to FIGS. 10-12. 11, 12 include flowcharts of processes.

Some or all of the steps shown in FIG. 11 may be included in embodiments of the invention. For example, some embodiments of the invention may use algorithm identifiers to determine whether the identifier of the portable consumer device matches the authorization request message to the identifier of the portable consumer device stored in the database of the processing side, and may not perform transaction confidence processing before determining if operation authorized. In other embodiments, an operation confidence process can be performed without using the identification tags of the portable consumer device to authenticate the portable consumer devices. However, in preferred embodiments, the implementation uses algorithm identifiers, identification tags of the portable consumer device, and trust processing operations to authenticate the portable consumer devices and operations in general.

Also, while the process flowcharts of FIGS. 11 and 12 show specific steps performed in a specific order, embodiments of the invention may include methods that include such steps in a different order. This also applies to other process flowcharts or processes described in this invention.

Consider FIGS. 10 (a) and 11, in which consumer A 730 (a) can use consumer portable device A 732 (a) to interact with access device A 734 (a) from acceptor A 732 (a) (step 802). For example, a consumer portable device 732 (a) may be a credit card, access device A 734 (a) may be a point of sale outlet, and acceptor A 732 (a) may be a gas station. Consumer A 730 (a) may wish to purchase gasoline from acceptor A 722 (a) using the consumer’s portable device A 732 (a).

After the portable consumer device A 732 (a) interacts with the access device A 734 (a) at the acceptor A 722 (a), the access device A 734 (a) reads the consumer data and the identification data of the portable consumer device, such as magnetic stripe identification tag data from a portable consumer device A 732 (a) (block 804). Consumer data may include information that the consumer is usually aware of. Examples of customer data include a customer account number, an expiration date, and a service code. As noted above, the identification data of the portable consumer device is data that is not generally known to the consumer, but is used to authenticate the portable consumer device. In this example, the identification tag data of the portable consumer device may be magnetic strip identification tag data. The magnetic stripe identification tag data may also contain data that is embedded in the magnetic structure of the magnetic stripe and can be read using an access device that is manufactured by a particular company.

As soon as the access device A 734 (a) receives the consumer data from the portable consumer device A 734 (a), an authorization request message is generated including the algorithm identifier (step 806). The authorization request message may also include consumer data (e.g., account number), data related to the volume of purchases, and identification data of the portable consumer device. Access device A 734 (a) can modify (eg, encrypt) the received identification tag data using algorithm A, which is stored in memory in access device A 734 (a) before it is embedded in the authorization request message. In some embodiments, the identification tag of the portable consumer device and the algorithm identifier may be stored in an auxiliary data field called Field 55.

Different types and sizes of identification tags may come from different portable consumer devices offered by different manufacturers. These various identification tags can be included in the standard size data field so that the transmission through the payment processing system is uniform, regardless of the particular identification tag being sent. For example, in some cases, it is desirable to supplement the data field with characters, such as zeros, to populate the data field. For example, a data field may be 64 bytes in size. The identification tag from one type of portable consumer device may be 54 bytes, while the identification tag from another type of portable consumer device may be 56 bytes. The 64-byte field may contain additional fill characters along with a two-character algorithm identifier. Fill characters can be placed in the field in a predefined way.

In embodiments of the invention, the previously described algorithm identifier may not only identify the algorithm used to encrypt the identification tag of the portable consumer device; the identified algorithm can also be used to restore the identification tag to its original form so that it can be evaluated. For example, an algorithm identifier can be used to identify an algorithm that can be used to remove any fill characters in order to restore an accepted but changed identification tag to its original form so that it can be evaluated.

An authorization request message is then sent from the access device 734 (a) to the payment processing network 726 through the service bank A 724 (a) associated with the acceptor A 722 (a) (step 808). In other embodiments, the access device 734 (a) may send an authorization request message directly to the payment processing network, instead of sending it through the service bank A 724 (a).

After the authorization request message is received by the payment processing network 726, the server computer 726 (a) in the payment processing network 726 analyzes the authorization request message and then selects an algorithm using the algorithm ID that is in the authorization request message (step 810). The selected algorithm ID and the selected algorithm can be selected from the database 726 (c) of these algorithms. The algorithm data base 726 (c) may comprise a plurality of algorithm IDs and a plurality of algorithms that may be associated with various access devices (e.g., access device A 732 (a) and access device B 734 (b)).

After the algorithm is identified, the identification tag of the portable consumer device is determined by the server computer 726 (a) in the payment processing network 726 (step 812). Then, the selected algorithm is used to restore (for example, decryption) the changed identification mark of the portable consumer device present in the authorization request message.

After that, the server computer 726 (a) determines whether the specific identification tag of the portable consumer device matches the previously stored identification tag in the database (step 814). Server computer 726 (a) may first obtain consumer data, such as a customer account number, from the authorization request message and / or may obtain additional consumer data from the consumer data base 726 (b) after analyzing the authorization request message. Once the consumer data is determined, the server computer 726 (a) can obtain the identification tag of the portable consumer device from the consumer data base 726 (b). Then, the server computer 726 (a) determines whether the identification mark of the portable consumer device in the message with the authorization request matches the identification tag of the portable consumer device in the consumer data base 726 (b).

If the identifier of the consumer’s portable device obtained from the consumer’s database 726 (b) does not match the previously restored identifier of the consumer’s portable device obtained from the authorization request message, additional authentication processes can be performed and / or to consumer A 722 (a ) an authorization response message may be sent back indicating that the operation is rejected (block 822). Additional authentication processing may include sending a notification message about the operation to consumer A 722 (a) (for example, to the consumer’s cell phone or consumer’s computer), notifying the consumer that the operation is being completed. The notification message may request that consumer A 722 (a) confirm that the transaction is genuine. Alternatively or additionally, other types of requests, such as security questions, may be sent to consumer A 722 (a). Requests, such as security questions, are described in more detail in US Patent Application No. 11 / 763,240, entitled "Consumer Authentication System and Method", filed June 14, 2007 (Attorney dossier No. 16222U-031600US), which is incorporated herein by reference in its entirety for all purposes.

In some embodiments, if the identification tag obtained from the authorization request message and the identification tag in the customer data base 726 (b) are the same, the server computer 726 (a) can also, if required, determine whether the operation confidence threshold condition is satisfied ( step 815). If the confidence threshold condition is not satisfied, then additional authorization processing may be performed (block 823). However, if the condition of the confidence threshold is satisfied, then the message with the authorization request can be sent to the issuer A 428 (a) (step 816).

The transaction confidence threshold may take any number of characteristics of the operation in order to evaluate the operation as being genuine or potentially suspicious. Such characteristics of the operation may relate to the access device (for example, does the access device use new or old technology, does the access device use a secure encryption algorithm to encrypt data, etc.), a portable consumer device (for example, is the consumer’s portable device a telephone, a card with a magnetic strip according to the old technology, a card with a magnetic strip according to the new technology, etc.), etc.

As noted above, in a payment processing system, there may be many different combinations of access devices and portable consumer devices interacting together at any given time. These various combinations of access devices and consumer portable devices can trigger operations that may have different levels of potential authenticity. For example, with respect to FIG. 10 (a), on it, access device A 734 (a) can use the encryption algorithm from company A to encrypt data in the authorization request message, access device B 734 (b) can use the encryption algorithm from Company B, and access device C 734 (c) may not use any encryption technology. The encryption algorithm A can be considered as a more reliable encryption algorithm than the encryption algorithm B. Therefore, authorization request messages from access device A 734 (a) may have a higher level of potential authenticity than authorization request messages from access device B 734 (b) or access device C 734 (c). Additional authentication processing may be performed when operations are performed by access devices B and C 734 (b), 734 (c), and not access device A 734 (a). In another example, if all of the portable devices A, B, and C 732 (a), 732 (b), 732 (c) of the consumer are highly secure portable consumer devices, then only authorization request messages coming from device C 734 (c) access may require additional authentication processing, since only the access device C 734 (c) does not contain an encryption algorithm. As illustrated by this example, the threshold for determining whether additional validation processing is really required can be variable and can be set in accordance with predetermined rules.

After the authorization request message is received by issuer A 728 (a), issuer A can determine if the transaction is authorized. If the transaction is not authorized (for example, due to insufficient funds or credit in the financial account of consumer A), then additional authorization processing can be performed and / or consumer A 730 (a) can be sent a validation response message indicating that the operation is rejected ( step 824).

If the transaction is approved by the issuer A 728 (a), an authorization response message can be sent back to consumer A 730 (a) through the payment processing network 726, serving bank A 724 (a), acceptor A 722 (a) and device A 734 (a) access (block 820).

At the end of the day, the payment processing network 726 may conduct a normal clearing and settlement process. The clearing process is a process of exchanging financial details between a servicing bank and an issuer in order to facilitate sending to a consumer’s financial account and reconciliation of accounts of a consumer’s mutual settlement position. Clearing and settlement can occur simultaneously.

Additional details regarding embodiments that utilize the methods and systems described above can be found in US Patent Application No. ___________ entitled "System and Method for Testing a Portable Consumer Device" registered on the same day as this application (Attorney Dossier No. 16222U -031400US), which is incorporated herein by reference in its entirety for all purposes.

It should be understood that the present invention, as described above, can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and ideas provided herein, one skilled in the art should understand and appreciate other ways and / or methods for implementing the present invention using hardware and a combination of hardware and software

Any of the software components or functions described in this invention can be implemented as program code that will be executed by a processor using any suitable computer language, for example, such as Java, C ++ or Perl, using, for example, generally accepted or object-oriented methods. The program code may be stored as a series of instructions or instructions on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), a magnetic medium, such as a hard disk drive or floppy disk, or optical medium, such as a CD-ROM. Any such computer-readable medium may reside on or in a single computing device and may be present on or in various computing devices within a system or network.

The above description is illustrative and not restrictive. After viewing this disclosure, many modifications of the invention to specialists in this field of technology will become apparent. Therefore, the scope of the invention should not be determined in connection with the reference to the above description, but instead should be determined in connection with the attached claims along with its full scope or equivalents.

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

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

Claims (14)

1. An authentication method comprising
performing an authentication process for the consumer, the consumer using the consumer’s portable device to conduct the operation,
performing an authentication process for a portable consumer device, wherein the authentication process for a portable consumer device includes verifying an identification tag or a dynamic verification value associated with a portable consumer device, wherein the identification tag is encrypted by an encryption algorithm, wherein the algorithm ID associated with the encryption algorithm is transmitted with an encrypted identification tag in the message requesting authorized ania
performing an analysis of the degree of risk after authenticating the consumer and authenticating the portable device of the consumer, the analysis of the degree of risk determines whether the operation is indeed subject to authorization, and notifying the consumer that the operation is being completed. 2. The method according to claim 1, in which the identification mark is an identification mark of the magnetic strip. 3. The method according to claim 1, in which the portable consumer device is a telephone. 4. The method of claim 1, wherein the consumer authentication process comprises sending a request message to the consumer. 5. A computer-readable medium comprising a code providing, when executed by a processor, an authentication process for a consumer, the consumer using a portable consumer device to conduct an operation, code providing, when executed by the processor, an authentication process for a portable consumer device, The authentication process for a portable consumer device includes an identity tag or dynamic verification check. the value associated with the portable device of the consumer, the identification tag being encrypted by means of an encryption algorithm, wherein the algorithm ID associated with the encryption algorithm is transmitted with an encrypted identification tag in the authorization request message, a code providing, when executed by the processor, risk analysis after that how the authentication of the consumer and the authentication of the portable device of the consumer were performed, and the analysis of the degree of risk determines the validity on whether the operation is subject to authorization, and
a code that provides, when executed by the processor, a notification to the consumer that the operation is being completed. 6. A server containing a computer-readable medium according to claim 5. 7. An authentication method comprising authenticating a portable consumer device using dynamic data generated by a portable consumer device or an access device in communication with a portable consumer device, the dynamic data being different for each operation and formed from at least one of data of a specific operation and data of a specific consumer, and
consumer authentication, containing sending a request message to the consumer, and receiving a response to the request from the consumer. 8. The method according to claim 7, in which the request message is a security question. 9. A computer-readable medium comprising
a code for authenticating a portable consumer device using dynamic data generated by a portable consumer device or an access device in communication with a portable consumer device, the dynamic data being different for each operation and formed from at least one of the data of the specific operation and data specific consumer, and
a consumer authentication code comprising sending a request message to a consumer and receiving a response to the request from the consumer. 10. A server computer comprising a computer readable medium according to claim 9. 11. An authentication method comprising receiving an authorization request message associated with an operation using a portable consumer device, wherein the portable consumer device contains an identifier for the portable consumer device, and wherein the authorization request message contains a modified identifier for the portable consumer device and an algorithm identifier ,
selecting an algorithm from among a plurality of algorithms using an algorithm identifier,
determining the identification tag of the portable consumer device using the selected algorithm and the modified identification tag of the portable consumer device,
determining whether the identification tag of the portable consumer device matches the stored identification tag of the portable consumer device,
sending a request message to a consumer associated with a portable consumer device, and
sending a validation response message to the consumer in which the validation response message indicates whether the operation is approved or not. 12. The authentication method according to claim 11, further comprising receiving dynamic data and evaluating dynamic data to authenticate a portable consumer device. 13. A computer-readable medium comprising
a code for the processor to receive an authorization request message related to an operation using a portable consumer device, wherein the portable consumer device contains an identification tag of the portable consumer device, and wherein the authorization request message contains a modified identification tag of the portable consumer device and an algorithm identifier,
a code for a processor to select an algorithm from among a plurality of algorithms using an algorithm identifier,
code for the processor to determine the identification tag of the portable consumer device using the selected algorithm and the modified identification tag of the portable consumer device,
code for determining by the processor whether the identifier of the portable consumer device matches the stored identifier of the portable consumer device,
code for the processor to send a request message to a consumer associated with a portable consumer device, and
a code for the processor to send an authorization response message to a consumer in which an authorization response message indicates whether the operation is approved or not. 14. A server computer comprising a computer-readable medium of claim 13.

Images