JP2003536180A - Improved method and system for making secure payments over a computer network - Google Patents

Abstract

(57) [Summary] Provided is a secure method for conducting electronic transactions on a public communication network using a pseudo expiration date in an expiration date area of an authentication request. One preferred method is to conduct an electronic transaction over a public communication network using an account number, comprising: generating a key for each card associated with the account number; Generating a message authentication code using: converting the message authentication code to a pseudo-expiration date; generating an authentication request for the transaction, wherein the request comprises an expiration date having the pseudo-expiration date. Having a date field and verifying the message authentication code based on the pseudo-expiration date. Another example of the present invention is a method of conducting an electronic transaction over a public network using a number of payment accounts having an associated pseudo account number, the method comprising: (a) generating an authentication key; Providing a control area representing one of a plurality of key generation processes to be used in the pseudo account number; and (b) providing the control area in the control area with the pseudo account number. Generating an authentication key associated with the pseudo account number using one of a key generation process; and (c) generating a transaction-specific message authentication code using the authentication key. (D) generating an authentication request message having the message authentication code and the pseudo account number; and (e) the key generation process and the authentication represented. Using the key, having a method characterized by comprising the step of verifying the message authentication code.

Description

Detailed Description of the Invention

Priority Application This application is filed Aug. 18, 2000, entitled "Method and Apparatus for Making Secure Mastercard Payments on Computer Networks," US Provisional Application No. 60 / 226,227. No. and registered June 21, 2000, name "
Claims priority to U.S. Provisional Application No. 60 / 213,063, "An Improved Method and System for Making Secure Payments Over Computer Networks." I will include both provisional applications in this application by quoting them here. This application is further incorporated by itself on Apr. 11, 2000, entitled "Methods and Systems for Making Secure Payments on Computer Networks," US Patent Application Serial No. 60 / 195,963, and Registered March 15, 2001, claiming priority to US Patent Application Serial No. 09 / 809,367 entitled "Method and System for Secure Payment in Computer Networks", April 11, 2001 Registered, titled "Improved Method and System for Making Secure Payments on Computer Networks," US Patent Application Serial No. 09
/ 833,049 claims priority to. This last patent application is included in this application by reference.

BACKGROUND OF THE INVENTION The present invention relates to methods and systems for performing secure money transactions over communication networks, and more particularly, reliably transmitting payments over computer networks such as the Internet, and , Involved in methods and systems for reliably transmitting sensitive confidential information over public telecommunications channels.

Obviously, in the last few years, online commerce has experienced enormous growth, and even so, consumers still use their personal financial information, and Such information, for example, a credit card number or a personal identification number, is affected by transmitting it through a public communication network such as the Internet, and I am anxious about such transmission. As a result, over the last few years, companies have sought to find the best and best way to ensure the security of payments made over computer networks and reduce the risk of plagiarism or misuse of financial information. ing.

For example, US Pat. No. 5,883,810 issued to Microsoft under the name “Electronic online commercial card for online transactions, with transaction intermediation number” gives a temporary transaction number for each transaction. Directed to a system that supplies and associates it with a permanent account number. The transaction number looks like a true credit card number and the customer uses this transaction number and passes it on to the merchant as a substitute for the customer's account number. In this way, the customer does not have to transmit his or her true credit card number over the public network.

In the '810 patent, a merchant passes a transaction number to an issuing facility, which then uses the transaction number as an index to access the customer's true account number,
Process the authorization work and send the authorization response back to the merchant under the transaction number. As a result, the risk is deliberately minimized not only because the customer only transmits the transaction number, but also because the proxy number is only valid for a single purchase. Theft is said to be "less profitable for a single theft, because it (number) cannot be used repeatedly for other shopping or transactions." Second column, lines 60-61.

There is a need for improvements over conventional systems. In particular, in each transaction, instead of transmitting a permanent account number, a method that enables the execution of a reliable financial transaction on the Internet, avoiding the need to create and transmit a unique, repetitively generated transaction number, and There are demands on the system.

Co-pending Application No. 09 / 809,367 filed March 15, 2001-
According to the inclusion in the application by reference-a "fake" account number is assigned to the customer and this is cryptographically linked to the consumer's payment account number. A payment account number is an account number issued by a financial institution or other institution that allows a consumer to make payments for goods and / or services. For example, the payment account number may be a payment card such as a credit or debit card, or an account number associated with a payment application such as an electronic cash application stored on the consumer's computer. To the merchant, this fake account number looks like an actual payment account number. That is, this pseudo account number is
It has the same length as a valid payment account number and is also a valid specific number (for example, Ma
starCard International Incorporated (
In the case of "Mastercard"), it starts with "5"). This pseudo account number is used by the customer in all of his or her online financial transactions in place of the real account number.

In accordance with the invention of co-pending application 09 / 809,367, all transactions based on pseudo account numbers are preferably cryptographically encrypted using a unique secret key for each account number. The truth is proved. This proof of truth may be based on the private key in the public key pair ("public key truth proof") or on a secret key other than the private key ("secret key truth proof"). It may be. Therefore, even if an unqualified person sometimes confirms a fake account number of some kind, he / she cannot use it to make an illegal transaction.

Furthermore, the invention of co-pending application No. 09 / 833,049 provides a method of performing a transaction using a payment network. In this way, the service provider is assigned an acquirer code. More specifically, the service provider receives a first authorization request asking for transaction approval by the first payment account number, where (i) the first payment account number is a BIN code associated with the service provider. Associated with a second payment account number having a BIN code associated with the issuer of said second number, and (ii) the first authorization request includes an acquirer code associated with the acquirer, and (Iii) The first approval request can be conducted to the service provider based on the BIN code of the first payment account number.

The method further includes the service provider responding to the first authorization request by transmitting a second authorization request for authorization of the transaction with the second paying account number, where: The second authorization request includes the acquirer code associated with the service provider, and can be conducted to the issuer through the payment network based on the issuer's BIN code (ie, the BIN code of the second payment account number). Is.

Further, the response to the second authorization request is accepted by the service provider from the issuer, where the response includes a servicer code associated with the service provider, based on which the communication is conducted through the payment network. It is possible. The response to the first request for approval is then transmitted by the service provider to the acquirer based on the response to the second request for approval, and the response to the first request for approval is preferably the acquirer code associated with the acquirer. , And can be conducted through the payment network based on the code.

In another preferred embodiment of co-pending application No. 09 / 833,049,
A method of conducting a transaction with a merchant is provided using a first payment course number associated with a second payment account number. Here, the law generates (a) a message proof code based on one or more transaction details; (b) transmits at least the first payment account number and the message proof code to the merchant; (c). The merchant requests the first payment account number for authorization to pay the transaction, where the request is formatted as if the payment was processed at a point-of-sale terminal with a conventional magnetic stripe payment card. And the message proof of truth code is transmitted in an optional data field contained in a track of the type used for magnetic stripes on conventional payment cards; (d) for an authorization request for a first payment account number; Responding by requesting authorization for payment of the transaction using the associated secondary payment account number, One involves either based on the response against approved claims against (e) a second payment account number and message truth certification code, or receiving an approval response against first payment account number or decline.

This system can be further improved and is more secure and efficient in order to protect the messages and information transmitted during or in connection with financial transactions conducted over public telecommunication lines. It is also possible to strengthen.

SUMMARY OF THE INVENTION Accordingly, in accordance with the present invention, there is provided a method of performing an electronic transaction with an account number on a public communication network using a fake expiration date. The preferred method is to generate an anti-card key associated with the account number; generate a message proof code using the anti-card key; convert the message proof code to a false expiration date; request authorization for the transaction. Generating a message truth certificate based on the expiration date; and wherein the claim has an expiration date field containing a fake expiration date.

The preferred method further includes a payment network including an issuer of an account number having a true expiration date, wherein a second authorization request including the true expiration date is generated and the second The claim is characterized in that it proceeds to the issuer for approval of the transaction.

One more detailed embodiment of the present invention includes a paying account number with an associated fake account number and includes the following steps: (A) The service provider generates a counter card key associated with the pseudo account number using the payment account number and the pseudo account number; and (b) is used in a transaction including the counter card key. A secure payment application that includes: (c) a message authenticity verification code (“MAC”) using a paired card key; (d) a secure payment application that includes a fake account number and a MAC.
C generating a proof of truth request; (e) proof of truth of the MAC; (f) based on the proof of truth, the expected transaction sequence number (ET) for the MAC.
SN); (g) Providing a secure payment application with reference data; (h) Creating a second message truth proof code using the expected transaction sequence number and paired card key; (i) ) Converting the second message truth certificate code into a pseudo-expiration date using the reference data; (j) generating an approval request with an expiration date field containing the pseudo-expiration date; and (k) ) Responding to the authorization request and proving the second message truth certificate code based on the imitation expiration date.

According to another embodiment of the invention, there is provided a method of conducting an electronic transaction on a public telecommunications network, characterized in that the payment account number has an associated fake account number. The method includes: (A) supplying a pseudo account number having a control field indicating one or more key generation steps used for generating a proof of truth key; (b) in the control field of the pseudo account number. Using one of a plurality of key generation steps shown to generate a truth certificate key associated with the pseudo account number; (c) using the truth certificate key, a transaction specific message. (D) generating an authorization request message containing a message truth certification code and a pseudo account number; and (e) using the key generation process and the truth certification key shown above. To prove the message truth verification code.

According to yet another embodiment of the present invention, a method of performing an electronic transaction on a communication network by an account number, the method comprising: generating an anti-card key associated with the account number; Generating at least two different operating modes for advancing the message attestation code in different ways by means of an authorization request with different fields, where: At least one of the modes of operation advances the message truth verification code to the expiration date field, and at least one of the modes of operation advances the message truth verification code to the message truth verification code field. Preferably, the message truth verification code field is automatically transported to the message truth verification code field, if present.

DETAILED DESCRIPTION OF THE INVENTION The present invention is directed to methods and systems for performing secure payment over a computer network, such as the Internet. The present invention replaces the "truth" account number (ie, the actual card payment account number issued by the issuing institution) disclosed in co-pending application Serial No. 09 / 809,367 with "false" Use "like" account number.

The present invention, as an advantage, provides enhanced security for the use of payment account numbers on the Internet. According to the present invention, even if the fake account numbers are stolen, the stolen fake account numbers cannot be used to conduct fraudulent transactions over the Internet in many situations. This is because transactions based on pseudo account numbers are cryptographically proved using a unique secret key for each account number. This private key is taken solely by way of example throughout this application, inside the Cardholder's Secure Payment Application (“SPA”) and at the service provider facility, MasterCard In.
This is because it is only inside the highly secure equipment of the International Incorporated (“Master Card”) facility. Furthermore, the pseudo account number is
Since the true account number of the cardholder is not disclosed, there is a high possibility that it will be rejected by a normal sales terminal.

[0021] A number of drawings are provided that illustrate example embodiments of the invention. In this accompanying drawing and the following description, MasterCard is used to indicate the entity that supplies and processes the pseudo account number. The related abbreviations used in this application are as follows. BIN-Bank identification number DEA-Data encryption algorithm PC-Consumer personal computer device MAC-Message authenticity verification code MCI-Mastercard International or Mastercard MCWS-Mastercard website PIN-Personal identification number POS-Point of sale SPA-Safety Payment Application SSL-Secure Socket Layer (for Internet Security) TSN-Transaction Serial Number

In accordance with a preferred embodiment of the present invention, a service provider implements a secure payment application ("SP") of a secure payment system implemented in accordance with the techniques of the present invention.
Some ingredients are issued, maintained and / or processed, including A ″).

Components of the SPA System Preferably, the SPA system may be transparent to existing payment processing operations (eg MasterCard) and transparent to existing merchant, acquirer and issuer operations. Is. The system preferably utilizes three stand-alone components. 1.1 or more SPA websites 2. S for cardholder's PC (or other internet access device)
PA wallet 3. SPA approval / cancellation system

Briefly, the SPA website is used to “register” new cardholders and, in Mode 1 (defined below), to the appropriate SPA approval / deauthorization system. It is also used to supply the data it must have received before processing the billing message.

SPA Wallet is software downloaded to a PC (or similar) for use in SPA transactions. It is activated by the cardholder clicking on the icon. Once activated, it uses a combination of software and custom data for any given card,
Make Internet payments securely.

A SPA authorization / deauthorization system is a physical computing device that processes SPA transactions and transforms them into (and in some cases transforms from) conventional transactions. The device serves the services of one or more publishers.

The SPA website and / or SPA deauthorization system is also referred to as a service provider in this application and / or is associated with one or more service providers.

SPA Modes Four SPA operating modes are supported by the system. The modes are: Mode 0: No proof of truth Mode 1: Proof of truth with expired date field Modes 2 and 3: Proof of truth with new field dedicated to SPA

The advantage of modes 0 and 1 is that no changes are required to existing merchant or acquirer operations. Modes 2 and 3 allow merchants to add new fields to their payment screens (preferably secret fields that are not visible to the cardholder, but visible to the SPA software on the cardholder's PC).
, And if this field is filled by a PC, the merchant will pass this field (unchanged) to the acquirer, which in turn requests the buyer to pass it (unmodified) to the payment system To do. This is the same field used to transport ICC related data in other systems.

Mode 2 also illustrates that if the merchant has sent at least one second authorization request as a result of one transaction with the cardholder, this second (and subsequent) authorization request message will: Requires that you do not have an expiration date field. Such subsequent approval request messages are considered as mail orders / telephone orders and are not guaranteed.

Mode 3 is the same as Mode 2 except that Mode 3 does not impose the above requirement that the merchant not send a subsequent authorization request message with an expiration date. In Mode 3, it does not matter whether such subsequent approval request messages have an expiration date or not.

Since mode 2 imposes restrictions that mode 3 does not, the specifier of “secret field” for mode 2 is (1) that there is a secret field that can be used as a SPA MAC field, and (2) The merchant must carry the fact that the merchant has never sent an expiry date, subsequent approval request message. The "secret field" available in mode 3 does not have this second restriction, so it has a separate specifier.

Fields suitable for Mode 3 may be “universal” fields accepted by all payment systems for electronic commerce (eg, for ICCs used in electronic commerce). On the other hand, mode 2 cannot use such "universal" fields. This mode is only used if the merchant "guarantees" that the subsequent authorization request message will never include an expiration date. Therefore, while mode 2 can only be used by merchants who have made special arrangements to accept SPA transactions, mode 3 can be used electronically by all payment systems. It can be used by any merchant as long as the merchant has additional fields in the transaction.

Modes 2 or 3 are preferable in that the former gives a more effective proof of truth than modes 0 or 1. The SPA preferably operates in mode 0 or 1 unless the merchant has the intention to support mode 2 or 3 due to the presence of a "secret field" shown in the merchant's payment screen. The SPA in the cardholder's PC always works in modes 2 or 3 if the merchant supports this mode.

Preferably, the cardholder's PC operates in one of three states, “state A”, “state B” or “state C”. In "state A", the PC is in mode 1
Or 2 (depending on the merchant's abilities), but never Mode 0 or Mode 3. In "State B", the PC operates in Mode 1, Mode 2, or Mode 3 (again depending on the merchant's ability), but never in Mode 0. In "State C", the PC operates in Mode 0, Mode 2 or Mode 3 (depending on the merchant's ability), but never in Mode 1. P
The C is preferably switchable between these states under the direction of the SPA website.

“State A” has the advantage that all transactions have some proof of truth.
"State B" reduces the truth proof provided by Mode 1 to some extent, but "general purpose"
It has the advantage that a substantially higher degree of proof of truth is obtained for transactions with all merchants that accept the additional fields. "State C" is intended for future use when many large merchants have a "generic" additional field, which significantly reduces the storage requirements imposed on the SPA approval system, but this "generic" There is no proof of truth for merchants who do not prepare additional fields. Thus, while more and more merchants will be able to accept the "universal" add field, if they cannot accept the SPA's unique mode 2 add field, the issuer will be able to use "state A" to " The transition to the "state B" and finally to the "state C" is executed. The transition from one state to another is preferably the issuer's choice, so wallets from different issuers can be in different states.

SPA Features As mentioned above, SPA is based on the use of fake account numbers rather than the “truth” account numbers visible on the cardholder's card. There is a one-to-one correspondence between a fake account number and the corresponding "truth" account number. The same pseudo number is used by SPA in all modes. The fake account number BIN is a “fake BIN” that is not stamped on any MasterCard card. Since there is one pseudo-bin per card issuer, the issuer of a pseudo-account number can be identified. False BIN
Identifies the account number of any given transaction as one pseudo-account number.
Merchants and acquirers all know the cardholder by a fake account number, while the issuer knows the cardholder by a "true" account number. Therefore, SP
One of the functions of the A system is to "move" between two numbers, as described in the co-pending application.

According to the present invention, another function of the SPA system is to prove a message truth certification code (“MAC”) associated with each SPA mode 1, mode 2 or mode 3 authorization request. Is. In the case of mode 1, in the present invention, MA
C takes the form of a pseudo-expired date, and the date to be proved is preferably carried via the SPA website for each mode 1 transaction. For modes 2 or 3, the MAC becomes part of the "MAC field", a new SPA field added to all Mode 2/3 transactions. The date to be proved is also included in this MAC field.

The same SPA can have copies on different PCs. Any PC can have a SPA wallet for several different cards. In that case, the wallet can be controlled and used by different card holders.

SPA Website Operation-Card Registration At a cardholder, if a cardholder wants to register any card for SPA, he / she contacts the SPA website using a PC browser. (Web access devices that are not PCs also work in the same manner as described in this application.) SSL encryption is used for all data transmitted between the PC and SPA websites. When a website senses that it is being accessed by a browser rather than an already loaded SPA application, it preferably operates as follows.

The website sends the initial screen to the PC. This screen asks for either a "truth" account number, or a fake account number if the cardholder has already registered the card with some (other) PC. Once the SPA website receives the information, it looks up the BIN. Since the website keeps a list of all the fake BINs issued, it first determines if the BIN for the given account number is on the list. If so, it is a fake account number, otherwise it is a "truth" account number.

If the BIN represents a “true” BIN, the SPA website will determine if the issuer is participating in SPA. The website does this work
Do this by keeping a second table that associates "truth" BINs with pseudo-bins, and if you find in this table a statement corresponding to the "truth" BIN in question, then this issuer joins the SPA. I understand that I am doing. In either of these two situations, the SPA website acknowledges that SPA Wallet can be issued for this card. If the issuer is not participating in SPA, the SPA website preferably sends a message to the cardholder, informing him / her that this time SPA Wallet is not available.

If the SPA website determines that the card issuer supports SPA, the SPA website sends a second screen. This screen preferably claims: 1. Card expiration date 2. Cardholder name, address and phone number 3. 3. Whether the cardholder is in front of the owning / controlling PC 4. If a "truth" account number, rather than a fake account number, was provided on the first leg, whether the cardholder previously registered the card for SPA. If the card has previously been registered with SPA (indicated by "yes" to the previous section or by the use of a fake account number), the cardholder will use the password chosen at the time of registration. Whether you remember, 6. If the card has previously been registered for SPA and the cardholder remembers its password (if the cardholder was asked question number 4 and answered "yes"), then the Selected password.

Question 5 is always included when the cardholder enters a fake account number on the first screen, but Question 4 is not asked. Otherwise, question number 4 is asked, and if the cardholder replies "yes" to that question, question number 5 is added. If question 5 is asked and the answer is "yes", then item 6 is added.

If this is the first registration for this account number, or if the cardholder does not remember the password from the previous registration, the SPA website will issue the issuer-unique proof of truth question. Send the third screen to the PC and request the following information. (1) "SPA registration code" that the cardholder received by email,
(2) CVC2 printed on the back of the card, (3) Social insurance number of cardholder (
Or a part of the number), (4) First name and surname of the mother of the cardholder before marriage. The content of this third screen is preferably fixed by the issuer and presents a claim for the proof of truth information selected by this issuer. This third screen also provides a place where the cardholder must enter a password. This means that when the cardholder activates SPA in the future, or in the future, the issuance of the currently billed SPA wallet will be approved by the card issuer for another PC. This is because it must be used when requesting a copy. Note that if a SPA already exists for this account number, the new SP
This password must replace the previous password in order to initiate the A copy. It should be further noted that, for example, if a couple shares the same account number, the couple will share the same fake account number, and thus the same to launch a new SPA copy on another PC. You have to use a password. (However, if the husband / wife does not know this password, he may launch the new SPA copy on another PC by answering the proof-of-concept question.)

Upon receipt of this information from the cardholder, the SPA website determines from the BIN of the presented account number the address of the SPA authorization system which will process the authorization request for this pseudo-BIN. To do this, the SPA website maintains an address table that is accessed by the pseudo-BIN and supplies the corresponding SPA authorization system address (es). After making this decision,
The SPA website uses information obtained from cardholders as a safeguard (eg,
(Under SSL encryption) to this SPA authorization system. The website does not have to keep a copy of this data. Because the data is SPA
This is because the authorization system returns you to the website.

The method of communication between the SPA website and the SPA authorization system is preferably via the Internet under a dial-up telephone background. In this case, the address supplied by the address table is the Internet address of the SPA authorization system and also its telephone number. Another possibility is via a payment network like Mastercard Banknet, in which case
The "address" is simply the pseudo BIN itself.

Once the SPA authorization system accepts the registration request, it verifies that it is the proper facility for the BIN shown. Otherwise, reject the registration request and notify the SPA website accordingly. When the website receives the response, it sends a message to the website operator and the cardholder's P
Send a "please wait" message to C. If the operator cannot resolve the problem promptly (eg 5 minutes), the SPA website informs the PC that it cannot supply SPA Wallet for this card now.

If the SPA approval system successfully completes the registration, the security measures
Send a message to the SPA website, preferably consisting of: That is, 1. Cardholder's name, address and phone number 2. False account number 3. Card expiration date 4. The last 4 digits of the “truth” account number 5. Irreversibly transformed password 6. Encrypted password for card key 7. 7. Number of SPA copies or number of single sessions Number of SPA versions 9. SPA single session indicator 10. SPA status 11. Fake BIN key indicator 12. Card product name (eg, “Mastercard”, “Maestro”, “Mastercard Cash” 13. “Truth” account number 14. 1st SPA flag (1 = new fake account number just confirmed))

The SPA authorization system also returns whatever information the SPA website requires to route the answer to the cardholder PC.

Upon receiving this message, the SPA website will put the above items 1 to 12 in the SPA wallet, along with the software corresponding to the SPA version number. The wallet also contains mode 1 and mode 2/3 transaction serial numbers, and an initial value of zero for the password failure counter. The SPA website then transmits this SPA data to the cardholder PC,
The data is stored in C.

SPA supplies a menu of cards that can be used on that PC with SPA. The SPA preferably provides the following information for each card in a row on the PC screen. 1. Fake account number of card 2. Number of SPA copies (if this is not a single session SPA) 2. The last 4 digits of the “truth” account number on the card 4. Card expiration date 5. Name of cardholder 6. Card product name (eg "Mastercard", "Maestro", "Mastercard Cash")

Each time a new SPA wallet is added to the PC's SPA, the new card must be added to this menu list. The cards are listed in the order in which they were registered for SPA, with the first registration as the first rank. This list is used by the cardholder to select a card for the current transaction. As mentioned above, each card is associated with a particular software set (although two cards with the same version number use the same software). It should be noted that in most cases another SPA will never be installed on this PC, so there is only a single card in this list.

[0054]   The cardholder can now carry out the SPA transaction.

SPA Authorization / Deauthorization System As briefly mentioned above, all card issuers participating in the SPA are serviced by one “primary” SPA authorization / deauthorization system. In this case, if necessary,
The system is capable of serving multiple issuers. For a fully operational SPA system, there is at least one "backup" SPA approval / deauthorization system, which is always used when the primary system is unavailable (eg failure). Good. "Backup" S
Using the PA approval / deauthorization system completes the SPA transaction but (temporarily) reduces the quality of the security.

Each of the SPA authorization / deauthorization systems that serve multiple issuers is preferably via MasterCard's Bank via one or more dedicated servers.
It is connected to a payment system such as net. This system is Banknet
Accept approval request messages and cancellation messages through, and also Banknet
Contact the publisher through. Such a system preferably operates in a completely transparent manner to its supporting publishers.

A single issuer version of the SPA approval / deauthorization system is also available. Such versions directly contact the publisher's processing system. This version requires some reprogramming on the issuer side. The fix recognizes SPA transactions by its pseudo-bin (s) and passes those transactions to a SPA authorization / de-authorization system (eg, service provider), thereby eliminating the pseudo-account number. Convert to "truth" account number and MA
C. It must be able to perform proof of truth (only the approval request message).

Another version of the single issuer SPA approval / deactivation system is the issuer M
It may be installed between the IP and the user's processing unit. This system
It is possible that it is transparent to the issuer, but all traffic to and from the MIP must pass through this SPA system.

Finally, the approval and cancellation functions for an issuer do not have to be performed by the same physical box. The issuer causes the SPA approval system that contacts the approval request message to contact the issuer via Banknet,
Alternatively, the release message may be processed by a single issuer SPA release system that connects directly to the member's processing system.

Initially, there may be only a relatively small number of SPA approval / deauthorization systems. As more and more issuers, or groups of issuers, choose to have their own SPA approval / deauthorization system, appropriate data from the original system (serving many issuers), Provision must be made to transfer to the new system (one or at least serving fewer issuers than the original). The fake account number, whatever it is, preferably receives service from only one SPA authorization system. Therefore, the transfer must be viable with minimal disruption to any transaction in progress at the time of the transfer.

Pseudo Account Number For a single "truth" payment account number, the pseudo account number associated with it is
The length is preferably 16 digits. This 16 digit pseudo account number starts with a 6 digit BIN dedicated to this account number. The BIN may be unique to any bank or any member of the service provider federation, and within the member,
It may be unique to any product (eg, gold card, combination card, etc.).

The two numbers immediately after BIN (or one number if necessary) may be reserved as a “control field”. This field indicates the algorithm etc. used with this pseudo account number.

Since the check digit is appropriate for a fake account number, this leaves about 7 digits, or 8 digits if required, and thus each BIN can have a maximum of 1000 digits for each control field value. It is possible to represent one million (or 100 million) account numbers.

With this pseudo account number structure, the issuer can be uniquely identified by the BIN. Therefore, the issuer can (1) identify the “foreground” transaction and (2) identify himself / herself. It will be possible to identify other issuers that have a two-way agreement with. As will be described later, issuers who are willing to modify the program or obtain an appropriate safety module will be able to carry out their own proof of truth, so there are also "foreign" transactions. It will also be possible for transactions at other facilities of the species to be carried out at the facility itself.
This eliminates the need to send the transaction to the service provider (or MasterCard SPA facility).

Preferably, the right 7 (or 8) digit excluding the check digit of the pseudo account number is an index that identifies a specific account within the facility identified by the left 6 digit. Initially (if indicated by the control field value) this reading may be common to all facilities. A large number of 7-digit (or 8-digit) digit readings per BIN are made available by using different numbers in the control field. These account number readings are preferably assigned by the service provider, in this case MasterCard. The numbers may be assigned sequentially (for each facility) or randomly. Alternatively, they may be assigned sequentially and then encrypted (7 or 8 decimal digits with randomness) and included as a fake account number.

The advantage of randomly assigning account number readings, or assigning them in order, and then encrypting them into a fake account number, is that enemies (eg, people who plan fraudulent activity) can use legitimate Making it more difficult to "guess" similar account numbers. If the account number readings are assigned in sequence, the enemy will have available fake account numbers, ie fewer fake account numbers than they have been assigned, or a little higher. This makes it very easy to "guess". Relatively few of the numbers possible for a facility (eg <10%
), By using randomly assigned or encrypted account number readings when the
The chance of being "guessed" is only about 1 in 10. This makes it more difficult for an adversary to discover a fake account number that could be used fraudulently.

If the issuer wants to carry out his own processing for transactions with pseudo account numbers, the service provider will correspond to each “truth” account number with all pseudo account numbers arranged in numerical order. You may be given a list of things to do. If this fake account number contains an actual reading, the service provider need only give the issuer a "truth" account number, arranged in the order shown. If the fake account number contains an encrypted account number indicator, the service provider will give the issuer a (depositor-unique) decryption key, and then display the "truth" account number, if necessary. It is also possible to give them in order. Perhaps the service provider asks the issuer to look up a reverse table (similar to what the issuer needs to store a pseudonym account number for each transaction that performs a pseudonym to "truth" account number translation). You don't have to give. However, if it is necessary to provide the issuer with a retrograde table, the table should list each “true” account number for each issued pseudonym account number, followed by the corresponding pseudonym account number in numerical order. become.

In any case, the service provider facility maintains a table that provides the ability to convert fake account numbers into "true" account numbers and "true" account numbers into false account numbers.

Card Truth Proof Key Operation The card's unique truth proof key is based on the encryption process of the fake account number and the corresponding "truth" account number. A process in which an intermediate BIN unique key is generated is desirable. It is prepared for use by the National SPA Facility and by card issuers who wish to perform proof of their own SPA transactions. In this way, even a nationwide facility need only be given one key per pseudonym account number BIN, and the issuer performing the proof of truth himself (for example)
You only need one key for every 10 million pseudo account numbers. If one national SPA
If the facility key is at stake, the security of other countries is not jeopardized.
The risk of one issuer's key being in jeopardy does not jeopardize the security of the other issuer.

The key generation process used with any pseudo-account number may be indicated by the control field of that pseudo-account number. A possible key generation process for carrying out the above purpose is as follows. That is, only the central SPA facility
Holds a secret triple-length DEA key called the "authentication key induction key". This central SP is used to create a counter card key for any pseudo-account number.
The preferred steps performed by the safety module of an A facility (eg, MasterCard SPA facility) are as follows. 1. In a 64-bit field, among the six pseudo-code decimal digits (BIN), each of which is 4 bits, the left 6 digits are left aligned and the right 0 is aligned. DEA encrypt these 64 bits using the 8 bytes to the left of the 24 byte proof of truth key derivation key as the encryption key. 2. DEA decrypt the result of step 1 using the central 8 bytes of the 24 byte truth proof key derivation key as the decryption key. 3. DEA encrypt the result of step 2 using the right 8 bytes of the 24 byte truth proof key derivation key as the encryption key. 4. Use the result of step 3 as the unique 16 bytes to the left 8 bytes of the BIN key. 5. In a 64-bit field, among the pseudo-account numbers (BIN) considered to be 6 binary coded decimal digits of 4 bits each, the left 6 digits are aligned to the left, and
Place a binary 1 on the right. DEA encrypt these 64 bits using the 8 bytes to the left of the 24 byte proof of truth key derivation key as the encryption key. 6. DEA decrypt the result of step 5 using the central 8 bytes of the 24 byte truth proof key derivation key as the decryption key. 7. DEA encrypt the result of step 2 using the right 8 bytes of the 24 byte truth proof key derivation key as the encryption key. 8. Use the result of step 7 as the unique 16 bytes versus the right 8 bytes of the BIN key. 9. 16-digit "truth" (not fake) account number (decimal binary code, right-justified and, if less than 16 digits, binary zeros on the left (Possible) using the result of step 4 (8 bytes to the left of the BIN key) as the DEA encryption key. 10. Decrypt the result of step 9 using the result of step 8 (8 bytes to the right of the BIN key) as a key. 11. Encrypt the result of step 10 using the result of step 4 (8 bytes to the left of the BIN key) as the DEA key. 12. Use the result of step 11 as the left 8 bytes of the card key. 13. Binary to the right of the "truth" account number (decimal digit of binary code, right-aligned, and if less than 16 digits, binary zeros are arranged on the left) Pattern 0101010. ． ． Lined up, then step 4 as the DEA key
Encrypt using the result (8 bytes to the left of the BIN key). 14. Decrypt the result of step 13 using the result of step 8 (8 bytes to the right of the BIN key) as the DEA key. 15. Encrypt the result of step 14 using the result of step 4 (8 bytes to the left of the BIN key) as the DEA key. 16. Use the result of step 15 as the right 8 bytes of the card key.

When a central SPA facility creates an SPA for a cardholder's PC, it includes a card key (from steps 12 and 16) in its application in a manner that is not disclosed during normal operation of that application. Let

When a pseudo account number is received in a transaction with a message truth certification code, SP
Facility A establishes its "truth" account number and then performs the 16 steps to create the key needed to prove the MAC.

If the SPA facility needs to create a key to be kept in the national SPA facility or in the issuer's security module, for each BIN unique to that country, or for that issuer's BIN Steps 1 to 8 are executed. These keys are then securely delivered to the National SPA Facility's or Issuer's Security Modules, each of which has a pseudo-account number BIN (and control field) used to create it. ) Associated with. This security module, in turn, has a fake account number, a "truth" account number, a MAC,
And for each transaction received with the designated control field, first select the key indicated by the pseudo-account number BIN and then use this key as the anti-BIN key to perform steps 9 through 16 above. And create a key to prove the MAC.

SPA Activation Next, the specific SPA activation will be described with reference to the drawings. FIG. 1 initially depicts a cardholder holding a financial transaction card obtaining a secure payment application from an SPA website or service provider over the Internet according to an embodiment of the present invention. First, in order to utilize and enjoy the benefits of the present invention, a physical card is not required, only the account number that identifies the user or participant and ties him / her to the account for performing financial transactions. , Understand that it is issued to the holder (in this case the cardholder). The cardholder may contact a website associated with the service provider using any suitable device capable of communicating over the Internet, such as a computer, cell phone or electronic secretary (PDA). For simplicity, the discussion below assumes that the cardholder uses a computer to communicate on the Internet.

As shown in FIG. 1, a service provider, such as MasterCard In
international Incorporated (ie, MasterCard's agent) is under the control of one or more physically secure modules 12, which provide physical protection for the information stored within the module. . Each of these security modules includes one or more "induction keys," which are provided within a secure payment application, as described below.
Used to create and recreate account unique secret encryption keys (against card keys).

First, according to the preferred embodiment of the present invention, the cardholder must obtain the SPA from the service provider. Secure payment application (S
The preferred steps to download and launch PA) are: The cardholder contacts the service provider's website over the Internet (directly or from another website, eg, the issuer's website via a hyperlink to that website). 2. The cardholder supplies (a) the payment card account number, (b) the card expiration date, and (c) the card proof information under SSL encryption commonly known to the parties. The card proof information may include, for example, the CVC value of the card, i.e., three to four numbers printed next to the signature panel of some cards, as described above. This number is generated by the issuing bank using a secret encryption key, but it can be verified using that same key. 3. The service provider may verify the legality of the card account number and the card expiration date by obtaining a zero amount authorization from the cardholder's payment card issuer. For example, MasterCard can obtain such authorization via the Banknet communication network. 4. If the issuer of the cardholder's payment card provides the service provider with the cryptographic key (s) for certifying the CVC2 number, the service provider may certify the CVC2 value. Good. 5. The service provider may certify other card certification information by sending that information to the issuer for certification. To facilitate this, the service provider's website, or MCWS
You may maintain a list of items to ask the consumer at the time of registration. A list of such items is Item No. Item Description 01 CVC2 02 PIN 03 Mother's pre-marital surname 04 Last billed amount in this account 05 City name on bill 06 Last four digits of social insurance number

The issuer can specify which data the consumer wants the service provider to supply when the consumer registers the account number issued by the issuer with the service provider. When the issuer wants to handle another BIN different from a certain BIN (product), the issuer may specify different data items for each BIN. The service provider's website selects the question and prompts the consumer for a response.
The results will be provided to the issuer as part of a zero amount approval request.

6. The service provider (“SP”) creates or selects a fake account number and private key after verifying the legality of the cardholder-supplied data and places these data elements into the secure payment software application. Incorporate. This application runs on the Internet, preferably under SSL encryption,
It is made available for download to his / her PC by the cardholder.

The pseudo account number is a special BI reserved for the pseudo account number as its BIN.
Have N. The remainder of the fake account number is a number that can be translated by the service provider through a table lookup process into a "true" account number and its associated expiration date. The check digit is correct in the pseudo account number.

Preferably, the assigned special service provider BIN may be selected from a set of many such special BINs, in which each BIN is a particular bank or a particular bank. It may correspond to a country or region, or to a particular product within a country or region.

The secret counter-card key, which the service provider preferably embeds in the SPA, is unique for each card account number and is preferably derived within the security module using the card account number and derivation key. (This process is described in more detail below). The derived key itself may also be derived from the same or another security module using a higher level derived key.

The cardholder may provide the password to the service provider prior to downloading the secure payment application, or may choose the password when the secure payment application is installed on the cardholder's computer. Good. When the password is provided or selected, the cardholder is required to enter the password in order to launch the secure payment application on his or her PC.

As will be appreciated by those skilled in the art, the service provider may update the SPA on a regular basis and may make the SPA downloadable as part of the digital wallet application. In addition to SPA, a digital wallet may also store one or more of the following: That is, the cardholder's personal information; the purse application, the debt application; the consumer-to-consumer application; and other applications,
These are all guaranteed under SPA.

SPA Wallet Operation-First Session Launch SPA is the SP that the cardholder displays on his / her PC screen.
It is activated by clicking the A icon. When first booted (after initial installation or after being closed before), the first task performed by the SPA is for the cardholder to have a SPA card (for which a SPA wallet was previously obtained). Card) and prompt the cardholder to choose the card he / she wants to use in the immediate transaction.

It should be noted that multiple cardholders may share one common PC. Thus, the cardholder name becomes part of the display information for each SPA card, and each card has its own SPA password for cardholder selection.

If the cardholder selects a card from this common list, the SPA
Preferably checks the password failure counter for this card. If this counter exceeds the SPA internal threshold, it informs the cardholder that this SPA card has had too many unsuccessful password entry attempts and must be re-registered. The SPA will then display two options, "Re-register" or "Cancel". If the cardholder selects the former, SP
A contacts the SPA website, interrupts and replaces the browser. If the cardholder chooses the latter, SPA simply suspends.

If the SPA determines that the password failure counter for the selected card has not exceeded the specified threshold, the cardholder is prompted to enter the password for that card. This is the password he / she chose when SPA was first applied to this card. When the cardholder completes the password entry, SPA irreversibly transforms this password and compares it to the SPA stored value. If no exact match is found, the SPA advances the password failure counter for this card (which has been saved by the SPA and therefore may have a non-zero value when the SPA is invoked),
Prompt for password re-entry. Until the password is entered correctly,
Or it is repeated until the password failure counter reaches the specified value. In the latter case, SPA saves the current value of the password failure counter and suspends after giving the cardholder the "re-register" or "cancel" option described above. If the cardholder does not succeed in entering the correct password and deactivates the SPA, the SPA also saves the current value of the password failure counter.

If there is a strict match between the irreversibly transformed cardholder entered password and the number stored inside the SPA, the SPA resets the password failure counter, preferably this proof. The just-received password is used as an encryption key to decrypt the card-to-card key. The SPA then displays the cardholder's address and phone number, asks "Did your address and phone number change?"
And supply a "no" button. Click "Yes"
A window is displayed that allows you to correct the address and / or phone number.

SPA Next, check the expiration date of the card just selected and determine if the card has already expired (based on the clock of the PC) or will expire within the next 30 days. If so, the SPA asks the cardholder if he / she has received a new copy of this card, and if so, key in the expiration date of the new card. (Cardholders have the option to say "no.") SPA is now ready to process transactions on the card just selected.

SPA Operation As mentioned above, the secure payment application (“SPA”) may have different modes of operation for payment transactions, including: That is, 1. Proof of truth using only the expired date field 1. Proof of truth with additional fields

Mode 2 is used when the merchant can accept the additional fields in the transaction and is referred to as the "MAC field" in this application. This gives a higher degree of truth proof than Mode 1, so it is used whenever feasible. The merchant must indicate to the SPA in the PC that the SPA is Mode 2 compliant by including the MAC field in the data fields that may be filled in by the PC. (This may be a secret field, in which case it will not be displayed to the cardholder.) Whenever the PC is SPA capable, all of the above merchants pass this MAC field to the acquirer, and therefore It must be possible to supply the field.

If the PC cannot find the MAC field on the merchant screen, the PC operates according to mode 1.

The following description describes the preferred operating states of SPA in these two modes, by way of example.

The registration process by which the cardholder's PC (or other device) obtains SPA through it is as follows. The SPA software accepted by the cardholder's PC supports both modes of operation. A separate transaction serial number is used for each mode. That is, one is used for mode 1 and the other is used for mode 2. Both are initialized to "0" and proceed separately for each Mode 1 and Mode 2 transaction.

Mode 1-Proof of Truth Using Only Expiration Date Field In Mode 1, the expiration date field of the authorization request message is used to carry some form of MAC. This "fake" expiration date, like all expiration dates, is formatted as MMYY. Preferably, the fake expiration date must fall within the next 48 months to work with the current processing systems of many or all merchants in today's market.

The Mode 1 transaction serial number consists of 20 binary bits and is advanced for each Mode 1 transaction. Therefore, not all 1 to all zero cycles until 2 ²⁰ = 1 million Mode 1 transactions occur. To the left of this field is a 4-bit
There is a "version number". This is each PC where SPA for any given account number stays
It is a unique number.

As mentioned above, the SPA wallet examines the currently displayed screen for a "secret field" in which it can place the MAC field. If it finds such a field, it proceeds to mode 2 or mode 3 as described below.

If SPA cannot find the field, it uses the same language that it used for the previous transaction, that is the field it can "understand", ie, "name",
Look for "address", "phone number", "card number" and "card expiration date". If many of these fields are not found, the SPA will charge the cardholder to select the screen language. The language chosen by the cardholder is
If the SPA is different from the one previously used, the SPA repeats the trial.
If the SPA can identify no or few fields,
Ask to see if the merchant payment screen really exists. (Because the cardholder's SPA may start up too quickly.) If the cardholder says "no" (no merchant payment screen is displayed), the SPA suspends and takes control. Switch back to the previously running program (probably a browser).

If the cardholder indicates “yes” (the payment screen is displayed), or if the SPA can identify many or all of the merchant payment fields,
SPA automatically fills in its identifiable fields (all if any). The SPA then prepares a message to send to the SPA website. All communications between the PC and SPA website (in either direction) must be protected using SSL encryption. This message may consist of: That is, 1. False account number (as 16 decimal digits) 1. Fake BIN key indicator (8 bits) 3. SPA status indicator (1 bit: 0 = "status A", 1 = "status B"
"{" State C "has no mode 1 transaction}) 4. SPA version number (as 15 bits). This field is for SPA
The type (credit, debit, prepaid) and the revision number of this type are shown. In the case of a credit card SPA, the revision 0 and the SPA version number are hex 0000. 5. Single session SPA indicator (1 bit: 0 = normal SPA, 1
= Single session SPA) 6. 6. SPA copy number or single session number (as 10 bits) 7. Last used Mode 1 transaction order number (as 20 bits) 8. Card expiration date (4 binary coded decimal numbers or 16 bits) 9. A MAC, which preferably consists of 16 to 32 binary bits, is preferably carried in data elements 3 to 8 (preferably in this order) and is generated using an anti-card key.

The SPA wallet then contacts the SPA website via the Internet and transmits the data element. Wallet then waits for a response (while the SPA website is contacting the appropriate SPA authorization system). After a few seconds, the SPA wallet will display "Please wait" to the cardholder. Other text is then displayed, stating to the cardholder that the SPA is in contact with the MasterCard in preparation for the desired transaction, and that this may take some time. The display preferably changes once every few seconds, so that the cardholder knows "something is happening now."

If excessive time has passed, the SPA Wallet will again contact the SPA website and repeat the claim. If the SPA cannot contact the SPA website that it normally can contact, it will contact the backup SPA website. If, after a specified time and number of such attempts, SPA fails to get a response from the SPA website, SPA will ask the cardholder, "This transaction could not be completed. ", And then suspend. The cardholder must now try another SPA card, another payment instrument (eg, manually enter the MasterCard account number), or later again.

The response that SPA finally accepts from the SPA website is a “cannot proceed”, “can proceed”, or “change state” display.

If the response is a "cannot proceed" indication, the SPA will further indicate a "reason"
Give the code. There are preferably three reasons. 1. This SPA copy number is no longer valid (because of the more recent SP
A copy has the same "n" bits at the end). (A finite number of SPA copies, eg 16, may be used simultaneously for the same pseudo account number)
. 2. This is a single session SPA that has expired. 3. The MAC was not proved true, the transaction serial number is not valid, or "...
． "Invalid until" -the indicator holds a future date, or "
The "invalid copy" flag is set.

If the “cannot proceed” indication is for the first reason, the cardholder is preferably notified that: That is, MC-Internet. You must contact us to re-register this card for this PC. You first registered this card with this PC and then you have at least 16 (or another number) of this same card on other PCs
Registered once. Therefore, your original registration on this PC is no longer valid.

If the “procedural inability” indication is for the second reason, the cardholder is provided with the following information. This card on this PC was only usable for 4 hours (or any other time).
This time has expired. To continue, contact MC-internet.com,
You will need to re-register this card for this PC.

In any of the above situations, two buttons are presented on the card holder, one of which is called "re-register" and the other is called "cancel". By activating the first one, the SPA of the PC contacts the SPA website and then suspends. By booting the second one, the SPA of the PC is immediately interrupted.

If the "procedural inability" indication is for the third reason, the attempt is a possible fraud and the cardholder is provided with the following information. Procedure not possible. Please contact the issuer. SPA will be stopped after this message is displayed.

If the response is a "changed" indication, the new state identity is included in the response. The SPA of the PC changes the state and stores this pseudo account number for this new state. This may or may not start another Mode-1.

If the response represents “procedural”, this response is made by the following data (not displayed on the cardholder): 1. Reference date described later (2-byte formatted YYMM as a binary coded decimal number) 2. Month indicator (2 bytes as a 4-digit binary coded decimal number)

In this case, SPA preferably proceeds as follows. 1. Increment the Mode-1 transaction sequence number. 2. The transaction sequence number and Per-Card Key are used to form a 64-bit binary MAC. 3. This 64-bit binary MAC is converted to a pseudo-expiration date using the base date and months indicator immediately after receipt from the SPA website. 4. This pseudo expiration date is placed in the "Expiration Date" area of the customer's payment screen if SPA can indicate it. 5. Place the pseudo account number in the "Account Number" area of the customer's payment screen if SPA can show it. 6. If there are any items on the customer's payment screen that the SPA cannot show or occupy, display a "drag and drop" menu listing the unoccupied (remaining) items. 7. Display a message on the cardholder with basic data for the customer and then interrupt (some SPAs are unknown, such as a cardholder customer number that has this customer that needs to be manually entered by the cardholder). Data can be present, which causes the PC browser to send this fill screen to the customer).

The data in the “Drag and Drop” menu has any of the following items that SPA could not show on the customer's payment screen. 1. The card holder name that is displayed as the actual name (John R. Jones). 2. Actual address (111 First Street, Ely. NV99
Address of card holder displayed as 999). 3. The phone number of the card holder displayed as the actual phone number (650-111-2222). 4. A card account number displayed as the word "card account number" (because the cardholder does not know or recognize the pseudo account number). 5. The card expiration date displayed as the word "card expiration date" (because it is a pseudo expiration date and meaningless to the cardholder). There is also a "Cancel" button if the screen does not need all of these items. If the "cancel button" is hit before the pseudo account number and pseudo expiration date is shown on the customer's payment screen, the following message is preferably displayed to the cardholder: Do you want to cancel it? Cancellation will not allow payment. A "Yes, cancel" button and a "No, continue" button follow.

If the “Yes” button is selected, SPA is interrupted and control returns to the browser (whichever program was previously run). If you select No,
The "Cancel" window is removed and the SPA continues with the "Drag and Drop" procedure.

If the SPA completes successfully and is interrupted as a result, control is returned to the browser, and it is assumed that the cardholder uses the browser to send the customer's currently filled payment screen. There is no need to re-start SPA until the cardholder prepares for another purchase.

Specific Processing of Mode-1 SPA Requests [0114] Mode-1 SPA is preferably initiated during each transaction prior to making SPA-based payments. As shown in FIG. 2, the SPA is (for example) 16 to the website or server (preferably the master card service provider).
A request consisting of a digit pseudo-account number, a 4-digit decimal date of the actual account number, a 4-bit SPA version number, the current value of the 20-bit Mode-1 Transaction Sequence Number (TSN), followed by 3 A 16-bit MAC based on the digit value. Preferably, the MAC uses triple DEA encryption with a SPA-specific 16-byte per-card key and a 4-bit SPA version number concatenated with a 20-bit Mode-1 transaction sequence number (from left to right). ) Connected (binary 10
A 16-bit expiration date (as a decimal number), a left-justification of the 64-bit area and padding for validity using a binary 1 and the leftmost left of the resulting cipher character. 16-bit selection.

FIG. 3 shows the sequence of steps involved in SPA initiation and transaction payment preparation in Mode 1. As already explained, the SPA first sends out a start request to the service provider in step 20. When the MasterCard website receives this information, it uses a SPA system with a special security module, preferably MAC / SPA based on expiration date, in step 22.
Check the version number and transaction sequence number. If the MAC is valid, then in step 24 the system increments the transaction sequence number to form the "expected transaction sequence number" and processes the SPA authorization request for the displayed pseudo account number BIN. Update the "expected transaction sequence number" for the relevant pseudo account number and SPA version number for the SPA authorization system. However, in step 26, the SPA authorization system determines if the number of "predicted transaction sequence numbers" below the highest number of "predicted transaction sequence numbers" previously received for this pseudo account number and SPA version number is: Reject the "predicted transaction sequence number" received immediately before. The SPA authorization system updates, in step 28, the expiration date associated with this pseudo-account number if the expiration date received immediately before is given and is later than the currently recorded expiration date.

This particular SPA system uses the following two reference data values: 1) a four digit decimal number with the format MMYY (actually for the current month or the next month) and 2) (10
An 8-bit binary number having a maximum value of less than 256, referred to as the "months indicator", is transmitted to the MasterCard website and then step 3
At 0, it is transmitted to the SPA of the PC of the card holder. This data is the appropriate S
Included in the information sent to the PA authorization system.

Generation of Pseudo Expiration Date First, for actual Mode-1 transactions, the number of Mode-1 transaction sequences is incremented. The resulting 20-bit number with a 4-bit SPA version number on the left is then left-aligned in an 8-byte area and padded and doubled using binary zeros. Performs triple DEA encryption using a key for each card with long SPA. The result is a 64-bit binary MAC.

At step 32, the pseudo expiration date region of the transaction is obtained from the 64-bit binary MAC as follows. 1. Select the leftmost "1" bit of the "Month indicator" (binary number), and set the number of bit positions from this bit position to the rightmost bit (the leftmost "1" bit). (Including the bit positions of). This number is called "N". For example, when the “month indicator” is 01010100 (decimal 84), the value “N” is 7. Having determined "N", considering a 64-bit binary MAC as each group of "N" bits, we ignore the left ones beyond the rightmost bits. Starting with the leftmost group, select the first group encountered below the "months indicator". If no such group is found, select the leftmost group from this group minus 2 ^N and use this result (> 0 and <months indicator) as the selection value. 2. The result of step 1 is divided by the binary number 1100 (12 in decimal) to generate the quotient and the remainder. These quotient and remainder are converted into decimal numbers. The decimal remainder (having a value in the range of 00 to 11) is the leftmost two digits of the decimal "base date" (
MM). If the result is greater than 12, then subtract 12 from the result, regardless of whether the result is greater than 12 or not, resulting in the leftmost two digit MM result of the pseudo expiration date for the current transaction. If we get the result where 12 subtraction is required, we increment the quotient (to 1). 3. mod-100, add the rightmost two digits (YY) of the "reference date" to the two digit decimal quotient from step 2 that may also increment as shown in step 2 mod-100. Use the rightmost two digits YY of the pseudo expiration date for the current transaction as the result.

Communication Between Cardholder and Customer Once the SPA is installed on the cardholder's computer, the cardholder preferably uses the SPA for Internet payments, and the SPA is responsible for all Internet Provides a pseudo-cardholder account count for transactions. In SPA Mode 1, it is clear to the customer that this is a SPA transaction. The account number is actually a pseudo account number,
Even though the expiration date is actually an indication of the MAC, the customer is unaware that this transaction is different from any other Internet SSL it receives.

Authorization Request Acquirer Processing FIG. 4 illustrates communication between an acquirer 34, a service provider (master card) 20, an issuer 36, and a purchaser 38 according to an embodiment of the invention.

When the acquirer 34 receives the permission request message from the Internet customer 38, it looks up the issuer BIN in the BIN table. In the case of a pseudo account number transaction, the "issuer" corresponds to the processing facility authorized by the service provider or MasterCard.

In one embodiment of the present invention, some countries may have a facility with a special security module that handles their own transactions. Each such facility sets up only with the approval of the central service provider and holds only the cryptographic keys and account number conversion data for the country in which the transaction is processed.
In a country with such a home SPA facility, all transactions are sent to this facility so that transactions in the same country do not have to exclude that country. This can be done for individual banks in the country if desired.

A domestic SPA facility for processing domestic transactions is more useful than having all transactions performed by a central processing facility.

Service Provider Processing of Permission Request First, it is determined from the issuer BIN whether or not the account number is actually a pseudo account number, and if it is a pseudo account number, a transaction is made for processing. Send to a specific system. This system stores the tables needed to translate a pseudo account number into the corresponding "real" account number. This system receives 2 for the SPA version number and the pseudo account number.
It also stores a record of the maximum number of 0-bit "expected transaction sequence number", which is accompanied by an indication of whether the MAC has been verified for this transaction sequence number. In addition, the system stores any "predicted transaction sequence number" received within the last 48 hours for which the MAC has not yet been confirmed. In association with each such predicted trading sequence number, the system also stores an indication of a "base date" and a "months indicator" that applies to each predicted trading sequence number.

The “reference date” is a date value representing the latest allowable expiration date in the permission request message. From the background, some customers request batch authorization requests instead of requesting authorization immediately. Therefore, this date is typically 1 or 2 on the trading start date.
It is a day ago.

The “months indicator” represents the number of months beyond the current date corresponding to the final expiration date for which a payment card is accepted. This number is typically 48 months. The system also has a security module that has the function of determining a unique and secret 16-byte encryption key located in the SPA of the cardholder's PC when registration occurs. The processing performed by this system is as follows. 1. The "actual" account number is determined from the pseudo account number using the stored conversion table. 2. The security module is used to determine the encryption key specific to this SPA using the pseudo account number (as described above) and the "real" account number. 3. The first 20 received within the last 48 hours with no confirmed MAC
Select the "expected transaction sequence number" for the bit. Calculate the 20-bit transaction sequence number and associated SPA version number as previously defined for the PC SPA. The "base date" and "months indicator" for the associated "predicted transaction sequence number" are used to determine the expiration date from this MAC using the method previously defined for SPA for PCs. If this expiration date is equal to the current expiration date, then the MAC is verified. The entry for this "predicted transaction sequence number" that is the MAC verification is "verified MAC sequence number" if it is the highest number of "predicted transaction sequence numbers" for the associated SPA version number.
, And is deleted if it is not the highest number of “expected transaction sequence numbers” for the relevant SPA version number. The entry for "expected transaction sequence number" marked as "verified MAC" and with any lower number associated with the same SPA version number is deleted. 4. If the MAC is verified in step 3 (or step 5) and it is not known that the customer of this transaction will never send a second authorization request message for this same transaction, then the "history" for this pseudo account number Make an entry in "Data" (Some customers send more than one authorization request message for the same transaction if they cannot deliver all of the goods within a given time after the transaction. There is a risk.). This history data has all of the data already described plus the identity of the customer and the acquirer and the "expiration date" for this entry. The entry expiration date is set to a specific time in the future (for example, 6 months). 5. If the MAC does not verify in step 3, for all other "predicted transaction sequence numbers" received in the last 48 hours that are not associated with a MAC that has already been verified, from the oldest to the newest. Repeat the procedure specified in step 3. For any of these attempts, the MAC is considered validated if the resulting data matches that of the current transaction.
The 20-digit "predicted transaction sequence number" that is the MAC verification is the "verified MAC" if it is the highest "predicted transaction sequence number" for the relevant SPA version number. Marked and deleted if not the highest "predicted trading sequence number" for the relevant SPA version number. If the MAC is verified at this step, then step 4 is also performed. 6. If the MAC does not verify in step 3 or step 5, "history data" for the pseudo account number is accessed. Same expiration date M
If there is an entry in this data for the same customer and acquirer generating the AC and this entry does not expire, allow the MAC (assuming this is another authorization request message for an already authorized transaction). Be done.). If MAC is allowed for this entry, the entry expiration date should be approximately 2 months into the future if less than 2 months. The reason is that this could be a "repayment" and could be another authentication request message for the same transaction in another month. 7. If the MAC does not verify in step 3, step 5 or step 6,
The transaction is rejected. In this case, a "decline" response is sent to the acquirer. Once the MAC is verified, MasterCard formats an authorization request message to the issuer. The authorization request message has a “correct” account number (rather than a pseudo account number) and a “correct” expiration date (rather than a MAC). However, the MasterCard SPA authorization system needs to keep a record of account number fields and expiration date fields as received from an incomer in anticipation of receipt of an authorization response from an issuer.

In the authorization response message sent to the issuer, the authorization response is the acquirer BIN.
When sent through a payment network based on M.P., MasterCard replaces the acquirer BIN of the transaction message with one of the specific BINs of MasterCard that serves as the "pseudo" acquirer BIN. The acquirer BIN is replaced so that the issuer responds to MasterCard on behalf of the acquirer. It is not necessary to perform this step if the payment network keeps a record that the location of the authorization request message and the location of the authorization response message are the same.

In order to accurately calculate the exchange fee for the acquirer and the issuer, the pseudo acquirer B
If IN is used, the pseudo acquirer BIN needs to correspond to the country in which the acquirer is located or, as a result, another country or territory which gives the same exchange fee.
If each country has a specific BIN associated with it, MasterCard replaces the acquirer BIN with the specific BIN associated with the acquirer's country. If the acquirer's country does not have a particular BIN associated with it, a particular BIN associated with another country may be selected for the same exchange rate.

When the pseudo acquirer BIN is used, the master card stores the acquirer reference data (hereinafter, referred to as “original acquirer reference data”) received in the permission request from the income earner in the database. . In formatting the authorization message to the issuer, MasterCard will use the original acquirer reference data to find the pseudo acquirer BIN, the appropriate transaction type indicator and the original acquirer reference data. With the index value used by
Replace with "pseudo" acquirer reference data.

When a national SPA facility handles pseudo account number transactions, the facility operates as follows. However, this national SPA facility only handles transactions for domestic issuers and therefore requires only the cryptographic keys and account number translation table entries that apply to that country.

The SPA authorization system calculates and stores the expiration date of the MAC indication when receiving a new “predicted transaction sequence number” as opposed to waiting until the actual authorization request is received. Is effective. In this case, upon receipt of the authorization request, the expiration date in the authorization request message is compared with the expiration date previously calculated and stored within the last 48 hours that does not yet match the expiration date in any previous authorization request message. There is a need to.

Issuer Handling of Permission Requests FIG. 5 illustrates issuer 36, master card (service provider) 10 after the issuer has received it from, for example, Master Card or an authorized domestic SPA facility.
Shows communication between an acquirer 34 and a customer 38 according to one embodiment of the invention.

The issuer authorizes the transaction like any other transaction. The return of the authorization response is a “pseudo” acquirer, that is, the same master card SP that converts the pseudo account number into a “correct” account number and verifies the expiration date of the MAC display.
A Returned to the authorization system.

As already mentioned, the system is able to maintain a (temporary) record of transactions, ie the account number field and expiration date field are returned to the values received from the acquirer. The authorization response with these fields replaced with the values received from the acquirer is sent to the acquirer, as in the case of a regular MasterCard transaction,
It is sent from the acquirer to the customer.

If the SPA authorization system is actually a domestic SPA facility, this facility performs the functions indicated in the previous description.

Clearing and Settlement The acquirer clears the transaction in the usual way. Acquirer is IN of Master Card
Go to the ET (Clearing and Clearing) system, which translates the pseudo account number into the "correct" account number (there is no expiration date field in such exchange message).

Once INET translates a transaction into a "correct" account number, that number, like any other transaction, is sent to the issuer for clearing and clearing.

Exception Handling If there is a future chargeback, copy request, or any other exception handling related to this transaction initiated by the issuer, it is INET (or SPA).
Exception handling system), in which case the conversion is done from the "correct" account number to the pseudo account number. This conversion can be based on a table as the facility does not have to keep a record of individual transactions. The in-transaction data causes it to be sent from the issuer to the appropriate MasterCard facility.

Similarly, any response from the customer and acquirer to the issuer will be sent to the appropriate MasterCard facility, where the “correct” account number will be associated with the response.

Another Example for Mode 1 FIG. 6 shows another example for Mode 1. Each "X" in FIG. 6 represents a digit. In this example, the MAC is generated based on the transaction sequence, and the MAC becomes the pseudo expiration date described above. Further, one or more lower digits of the transaction sequence number used to generate the MAC (represented by 40, 42) are replaced with a pseudo account number 44. The digit is replaced between the cardholder number and the check digit as shown.

In this example, SPA is not required to communicate with the MasterCard website or server during the transaction. The SPA facility maintains a counter of transaction sequence numbers for each registered SPA. Upon receiving the authorization request, the SPA facility generates a MAC based on the upper digit of the transaction sequence number count that it maintains with the lower digit of the transaction sequence number of the pseudo account number.
The SPA facility then translates this MAC into a pseudo expiration date and compares this expiration date with the expiration date in the authorization request message. The SPA facility also verifies that the transaction sequence number is not a repeating number from the previous transaction.

Modes 2 and 3: Authentication SPA wallet using other areas is valid (if the cardholder follows the proper direction) until the customer's payment screen is displayed on the PC. It needs to be prevented. Thus, when SPA prepares to process a transaction, it examines the currently displayed screen and attempts to understand what it sees. First, SPA
Looks for the "hidden" area, which is the SPA MAC area.

For Mode-2 transactions, the identifier of this area needs to be a specific value. For Mode-3 transactions, the identifiers in this area need to have different values. SPA has one with a Mode-2 identifier and the other with Mod
If it finds two hidden regions with an e-3 identifier, the SPA will always
Select the -2 area and consider this a Mode-2 transaction.

If the SPA can find this “hidden” area, this is the “Mode”.
-2 "or" Mode-3 "transactions. In such transactions, the SPA
You can also find the "Card number" area, the "Expiration date" area, and the area that specifies the name, address and telephone number of the card holder. The reason is that for SPA-compliant customers, all of these areas are identified by standardized methods. In this case, the SPA occupies the entire payment screen.

In the event of the Mode-2 or Mode-3 transaction, the SPA performs the following processing. 1. Occupy an entry on the customer's payment screen for the cardholder's name, cardholder's address and cardholder's phone number. 2. Occupy the "account number" area of the customer's payment screen with a pseudo account number. 3. Occupy the "Expiration Date" area of the customer's payment screen with the expiration date stored in the SPA for this card (with card holder reciprocally updated). 4. Increment (and store permanently) the Mode-2 transaction sequence number. 5. Form the MAC. 6. MA as defined below (with MAC generated as above)
Form C region. 7. Place the MAC area in the "hidden" area of the customer payment screen. 8. Provide the cardholder with information that the customer's payment screen is occupied and can be sent. 9. Suspend, resulting in control returning to the PC browser. It is expected that the cardholder will use the normal browser function to send the screen occupied by the SPA so as to occupy the appropriate areas with each other.

The Mode-2 / 3 MAC field preferably consists of the following data elements: 1. Pseudo BIN key indicator (of 8 bits) 1. 2. SPA mode indicator (1 bit: 0 = Mode-2, 1 = Mode-3). SPA version number (15 bits). This area represents the SPA type (credit, debit, prepayment) and the number of versions for this type. For credit card SPA, revision 0 and SPA versions, the numbers will be all zero. 4. Single session SPA indicator (1 bit: 0 = normal SPA, 1 = single session SPA). 5. 5. (10-bit) SPA copy number and single session number 6. Mode-2 / 3 transaction sequence number incremented just before (20 bits) 7. Card expiration date (4 digit binary coded decimal or 16 bits) 8. Binary evolution 3 of data elements # 2- # 7 generated sequentially using the key for each card
2-bit MAC

Mode-2 and Mode-3 use the same set of transaction sequence numbers. Therefore, from the SPA of the same card holder of the same PC for the same pseudo account number, there is never a Mode-2 transaction with the same transaction sequence number as the Mode-3 transaction.

When SPA is re-enabled (non-suspended), it displays a list of all SPA cards and asks the cardholder to select one. However, if the SPA is interrupted but not closed, and if the cardholder selects the last used card, the SPA will ask the cardholder if the address, telephone number or card expiration date has changed ( Do not ask again). Also, SP
A does not require the password to be re-entered. Instead, SPA uses (
In other situations it is encrypted by using a password as the key) and holds the key with a clear text card. This clear text key is erased when the SPA is closed or another card is selected.

Specific Handling of Mode 2 Requests In this mode, (for example) a 13-digit decimal MAC field is S
It is included in the transaction as a PA-specific area. These 13 digits are as follows. 1. "SPA" indicator: 1 digit. This region usually has the value one. However, if the cardholder has more than one copy of SPA for the same "correct" account number (eg on a desktop computer or laptop computer), other versions of SPA will see each other in the SPA indicator field. Have different numbers (SPA transaction sequence number is SP
Unique to each such version of A. ). 2. SPA transaction sequence number for this version of SPA: 6 digits. This field is incremented for SPA transactions initiated on this particular computer (each computer will have its own version of SPA, and therefore its own set of sequence numbers). 3. MAC itself: 6 digits. As will be described later, the actual MAC is calculated in the above two areas.

The proposed MAC-generated process is as follows. 1. It displays the 7 digits of the SPA version number (on the left) and the SPA transaction sequence number (for this computer) in binary coded decimal to produce 28 bits. In the 64-bit area, these 28 bits are aligned to the left, and padding is performed by using zero bits to determine whether they are valid. 2. DEA encryption of the result of step 1 using the leftmost 8 bytes of the key for each card as the encryption key. 3. DEA encryption of the result of step 2 using the leftmost 8 bytes of the key for each card as the encryption key. 4. DEA encryption of the result of step 3 using the leftmost 8 bytes of the key for each card as the encryption key. 5. Consider the resulting 64 bits of step 4 as a hexadecimal number of 4 bits each. Scan the hexadecimal number (from left to right) and select the first 6 digits that have a hexadecimal value less than 9. If no such six digits are found, find the remaining digits required by rescanning the digits and selecting only the hexadecimal digits greater than 9 and subtracting the hexadecimal digit A from each of them. 6. Use the result of step 5 as a 6 digit binary MAC for this transaction. The MAC is generated by the SPA of the cardholder's PC and verified by the appropriate MasterCard SPA facility. Upon occurrence, the 6 digit decimal number resulting from step 6 is inserted into the MAC field as the actual MAC. Upon verification, the SPA facility performs the above 6 steps using the leftmost 7 digits of the MAC field, and then 6 for the rightmost 6 digits of the received MAC field. Compare with digit. An exact match represents an authenticated transaction. Inconsistencies represent transactions that need to be rejected.

Communication between Cardholder and Customer Whenever the MAC field is supported by the customer, the SPA uses the embedded secret key to form the MAC associated with the transaction, and this M
Place the AC and the data based on it in the MAC area that will be part of the transaction.

In response to receiving the cardholder's transaction message, the customer formats a normal authorization request for the acquirer. This authentication request has a MAC area as provided by the consumer's PC.

When a customer initiates multiple authentication / clearing transactions for a cardholder transaction, only the first of these transactions has the MAC domain and expiration date.
The next transaction, having only a pseudo account number, is considered a customer-generated mail order and telephone order transaction. This also applies to all reoccurring payments and partial payments with multiple clearings.

Upon receiving the transaction, the service provider handling request for the authentication request determines from the issuer BIN whether the account number is a pseudo account number. Sends the transaction to a particular SPA authentication system for. The system can be a domestic SPA facility as described above. The system automatically marks it as a Mode-2 transaction due to the presence of the MAC field. After converting the account number from the pseudo account number to the corresponding "correct" account number, the system uses the substantially identical procedure used by the PC to form the MAC (as described above. 2) Determine the key for each card and use this key to verify the MAC. the system,
The transaction sequence number is also checked, and so the transaction sequence number information is maintained for each version number of the pseudo account number the system handles.

1. 1. If the transaction sequence number is less than (or equal to) the highest transaction sequence number for this version of this SPA that was received at least 48 hours ago, or 1. If the transaction sequence number matches any transaction sequence number already received for this version of this SPA (this is constrained by the transaction sequence number received within the last 48 hours), the system rejects the transaction. .

If the MAC or transaction sequence number fails to validate, this facility will cause the transaction to be declined. This facility allows the "correct" account number (and the cardholder's PC if both the MAC and transaction sequence number are verified)
Sends the transaction with the "correct" expiration date) inserted in the transaction by the issuer.

Issuer Handling of Authentication Requests The issuer authenticates the transaction like any other transaction. The authentication response translates the pseudo account number into a "correct" account number and returns to the same SPA authentication system that authenticated the MAC. If the payment network sending the authentication response is based on the acquirer BIN in the response message, the pseudo acquirer BIN can be used as already described.

This system restores the “correct” account number to the pseudo account number and restores the data that was in the original transaction (in the case of Mode 2, the expiry data held in the transaction from the start is “ It is the "correct" expiry data, so there is no need to restore this area.) The resulting message is sent to the "correct" acquirer, who processes the transaction as usual and sends the authentication response to the customer in the usual way. The customer responds to the authentication response as it would for any other transaction.

When a transaction is submitted to a domestic SPA facility, this facility will perform the functions described above.

Clearing and Clearing SPA clearing messages, like all clearing messages, are sent to master card INET (clearing and clearing). Since SPA transactions have a recognizable BIN, INET replaces the fake account number with the "correct" account number. If there is any exception handling for this transaction then other changes are made to the message so that an exception handling message is sent to the SPA facility that can translate the "correct" account number into a pseudo account number. . The clearing message with such changes is sent to the card issuer who processes the transaction in the usual way. If the acquirer is also the issuer, MasterCard returns the cleared transaction to the acquirer / issuer making the displayed changes and appropriate pricing.

When a message about an exception handling transaction needs to be returned from the issuer to the acquirer or customer, the message is processed by the issuer as it would handle any transaction message. The data in the transaction record sends a message to the Master Card Facility, which returns the "correct" account number to the pseudo account number. The exception handling message is then dispatched to the acquirer who handles it like any other such message.

Also, modify any documentation about transactions sent between the acquirer and the issuer by MCI so that the acquirer receives a pseudo account number and the issuer has a “correct” account. Make sure you receive the number. If such data is electronic and identifiable, the data is modified internally. If such documentation is not entirely electronic, then other forms can be created that reflect the correct account number and the pseudo account number. Issuers who send such documentation directly to the acquirer may be required to provide both numbers.

Issuing Plastic Cards for Identification In some situations, a cardholder may purchase a ticket over the Internet and generate a card to be used for transactions at the advent of an event that allows the ticket to enter. Requires authentication of legitimate processing of tickets.

At the start of the SPA program, the cardholder issues an actual plastic card that shows a pseudo account number, such as a card that clearly indicates "for identification purposes only".

The customer, who then needs to legally authenticate the cardholder with the pseudo account number, enrolls in MasterCard (by providing Mastercard with the appropriate identification and authentication information), and Is provided with a private key and authenticates as a cryptographic proof of registration. Thereafter, such a customer may provide a copy of the pseudo account number transaction details under cryptographic authentication that authenticates both the transaction data and the customer's rights to obtain the "correct" account number. , You can get a "correct" account number from the MasterCard facility. The MasterCard delivers the "correct" account number in encrypted form to the customer so that the cardholder is identified with the card corresponding to the "correct" account number.

SPA Wallet Operation: Mode-0 Transaction Processing Mode-0 is used only with wallets for "state C" pseudo account numbers. It is used under the circumstances of using Mode-1 in "state A" or "state B" (SPA cannot find an identifier for a "hidden" region that can be used as a SPA MAC region). When operating in Mode-0, the SPA of the PC simply replaces the pseudo account number in the "Payment Number" area of the customer's payment screen and the actual expiration date in the "Expiration Date" area of this screen. It fills the other banks of the customer's payment screen as described for Mode-1. The present invention is not limited to the above-mentioned embodiment, but various modifications and variations are possible.

[Brief description of drawings]

FIG. 1 is a block diagram of some processing components included in a trading method according to one embodiment of the present invention.

FIG. 2 is a display of information provided within a secure payment application initial billing, in one embodiment of the invention.

FIG. 3 is a flow diagram illustrating a process performed to obtain an expired date field value, according to one embodiment of the invention.

FIG. 4 is a flow diagram depicting the flow of communication between a merchant, an acquirer, a service provider and an issuer, according to one embodiment of the invention.

FIG. 5 illustrates an issuer, a service provider, according to one embodiment of the present invention.
4 is a flow diagram depicting the flow of information between an acquirer and a merchant.

FIG. 6 illustrates an alternative method of sending a message according to one embodiment of the invention.

─────────────────────────────────────────────────── ─── Continued front page    (31) Priority claim number 09 / 809,367 (32) Priority date March 15, 2001 (March 15, 2001) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 833,049 (32) Priority date April 11, 2001 (April 11, 2001) (33) Priority claiming countries United States (US) (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CO, CR, CU, CZ, DE , DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, I N, IS, JP, KE, KG, KP, KR, KZ, LC , LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, P L, PT, RO, RU, SD, SE, SG, SI, SK , SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Karl M Campbell             United States Pennsylvania             19073 New Toe Square Marine             Road 809 F-term (reference) 5B085 AE02 AE03 AE12 AE23                 5J104 AA08 PA07 PA10 [Continued summary] To generate an authentication key related to a large number of accounts And (c) using the authentication key, a message unique to the transaction. Generating a message authentication code, (d) said Message authentication code and the number of pseudo accounts Generating an authentication request message having (E) The represented key generation process and the authentication key And verifying the message authentication code with The method comprises:

Claims (14)

[Claims] 1. A method of conducting electronic transactions on a public communication network using an account number, comprising: generating a key for each card associated with the account number; and using the key for each card. Generating a message authentication code, converting the message authentication code into a pseudo expiration date, generating an authentication request for the transaction, the request including an expiration date region having the pseudo expiration date. And a step of verifying the message authentication code based on the pseudo expiration date. 2. The electronic transaction is carried out on a public network and a payment network having an issuer of the account number, the account number having a correct expiration date, and the second having the correct expiration date. The method of claim 1, further comprising the steps of generating an authentication request and submitting the second request of the issuer for approval of the transaction. 3. A method for conducting electronic transactions on a public network using a payment account number having a related pseudo account number, comprising: (a) providing the payment number and the pseudo account number. Using a per-card key associated with the pseudo account number generated by a service provider, and (b) forming a secure payment application upon use of the transaction with the per-card key. And (c) a message authentication code (“MAC”) using the key for each card.
(D) generating a MAC verification request by the secure payment application having the pseudo account number and the MAC; (e) verifying the MAC; (f) Forming a predicted transaction sequence number (ETSN) for the MAC based on the verification; (g) providing reference data to the secure payment application; (h) the predicted transaction sequence number. And forming a second message verification code using the key for each card, and (i) converting the second message authentication code using the reference data to a pseudo expiration date. (J) generating an authentication request having an expiration date region with the pseudo expiration date And (k) verifying the second message authentication code based on the pseudo expiration date in response to the authentication request. 4. The method of claim 3 wherein the per card key is generated using a per BIN key. 5. The MAC verification request further comprises values for the expiration date, version number and transaction sequence number of the payment account number, and the step of verifying the MAC includes the expiration date, the version number and the transaction. Method according to claim 2, characterized in that it is based on the value of the sequence number. 6. The method of claim 5, wherein the step of forming the second message authentication code uses the version number. 7. The method of claim 3, wherein the reference data comprises a base date and months indicator. 8. The step of verifying the second message authentication code, the step of determining the number of paying accounts using the pseudo account number and the stored conversion table; Determining a per-card key associated with the pseudo account number using the pseudo account number; and selecting a second expected transaction sequence number for which the associated message verification code was not verified. Converting the third message authentication code to a second pseudo expiration date using the second reference data identified for the second predicted transaction sequence number; Comparing the second pseudo expiration date and the pseudo expiration date; and based on the comparison, the second message. Verifying the sage authentication code. 9. The method of claim 8, further comprising verifying the second message authentication code if the second pseudo expiration date matches the pseudo expiration date. 10. A method of conducting an electronic transaction on a public telecommunications network using a number of paying accounts having a pseudo number of associated accounts, the method comprising: (a) generating an authentication key. Providing a control area representing one of a plurality of key generation processes in the pseudo account number, and (b) generating the plurality of keys represented in the control area having the pseudo account number. Using one of the processes to generate an authentication key associated with the pseudo account number; and (c) using the authentication key to generate a message authentication code specific to the transaction. (D) generating an authentication request message having the message authentication code and the pseudo account number; and (e) the key generation process and the authorization shown. Using the key, method characterized by comprising the step of verifying the message authentication code. 11. The method according to claim 10, wherein the authentication key is also generated by using an authentication key acquisition key on the pseudo account number. 12. The method according to claim 11, wherein the authentication key is also generated by using a key for each BIN. 13. A method of conducting electronic transactions on a communication network using the number of accounts, the step of generating a key for each card related to the number of accounts, and a message using the key for each card. Providing at least two different operating modes for sending the message authentication code with an authentication request having different areas in different ways, and at least one of the operating modes. And sending at least one of the operation modes in the expiration date area and sending at least one of the operation modes in the message authentication code area. How to characterize. 14. The method of claim 13, wherein the message authentication code is automatically carried in the message authentication code area if the message authentication code is present.