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

Description

[0001]
Priority application
This application is filed on August 18, 2000, entitled “Method and Apparatus for Performing Secure Mastercard Payment over a Computer Network”, US Provisional Application No. 60 / 226,227, and 2000. Claims priority to US Provisional Application No. 60 / 213,063, registered on June 21, named “Improved Law and System for Performing Secure Payments on Computer Networks”. We will include both provisional applications here by citing them in this application. This application is further in itself US patent application serial number 60 / 195,963, registered on April 11, 2000, entitled “Method and System for Performing Secure Payment over a Computer Network”, and April 11, 2001, claiming priority to US Patent Application Serial No. 09 / 809,367, registered March 15, 2001, entitled “Method and System for Secure Payment in Computer Networks”. Claims priority to US Patent Application Serial No. 09 / 833,049, registered, entitled “Improved Method and System for Performing Secure Payment over Computer Networks”. This last patent application is included in this application by reference.
[0002]
(Background of the Invention)
The present invention relates to a method and system for performing secure money transactions over a communications network, and more particularly to securely transmitting payments over a computer network such as the Internet and subtle over public communications channels. The present invention relates to a method and system for reliably transmitting confidential information.
[0003]
Obviously, in the past few years, online business has experienced tremendous growth, but even so, consumers still use personal financial information and such information. For example, I am suffering from transmission of a credit card number or personal identification number through a public communication network such as the Internet, and I am worried about such transmission. As a result, in the past few years, companies have been looking for ways to ensure the security of payments made on computer networks and to reduce the risk of financial information plagiarism and fraudulent use. ing.
[0004]
For example, U.S. Pat. No. 5,883,810 issued to Microsoft under the name "Online Transactions, with Transaction Brokerage Number, Electronic Online Commercial Card" provides a temporary transaction number for each transaction, And directed to a system that associates it with a permanent account number. The transaction number appears to be a real credit card number, and the customer uses this transaction number and passes it 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.
[0005]
In the -810 patent, when the merchant passes the transaction number to the issuing facility, the facility then uses the transaction number as an index to access the customer's true account number, process the approval process, and Return an approval response to the merchant under the number. As a result, the risk is deliberately minimized because the customer not only transmits the transaction number, but the proxy number is only valid for a single purchase. The theft is "just one theft isn't so profitable because it can't be used repeatedly for other shopping and transactions". Second column, lines 60-61.
[0006]
There is a need for improvements over conventional systems. In particular, for each transaction, a method that enables the execution of a reliable money transaction on the Internet, avoiding the need to create and transmit a unique, repetitively generated transaction number instead of transmitting a permanent account number, and There is a demand for the system.
[0007]
According to co-pending application 09 / 809,367, registered on 15 March 2001, which is hereby incorporated by reference, a “pseudo” 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 facility or other institution that a consumer can use to make payments for goods and / or services. For example, the payment account number may be a payment card such as a credit card or debit card, or an account number associated with a payment application such as an electronic cash application stored on a consumer's computer. This pseudo account number appears to the merchant as an actual payment account number. That is, the pseudo account number has the same length as the valid payment account number and starts with a valid specific number (for example, “5” in the case of MasterCard International Incorporated (“master card”)). This pseudo account number is used by the customer in place of the real account number in all of his or her online money transactions.
[0008]
  According to the invention of co-pending application 09 / 809,367, all transactions based on pseudo account numbers are preferably cryptographically authentic, using a unique private key for each account number. Is proved. thisAuthenticationMay be based on a private key in a public key pair ("Public keyAuthentication") Or a private key other than a private key (" secret key "Authentication]). Therefore, even if an unqualified person confirms a fake account number, it is not possible to conduct fraudulent transactions using them.
[0009]
Furthermore, according to the invention of co-pending application 09 / 833,049, a method of performing a transaction using a payment network is provided. In this method, an acquirer code is assigned to the service provider. More specifically, the service provider receives a first approval request for transaction approval with the first payment account number,
(I) the first payment account number is associated with a second payment account number having a BIN code associated with a service provider and having a BIN code associated with the issuer of the second number;
(Ii) the first approval request includes a acquirer code associated with the acquirer; and
(Iii) The first approval request is characterized in that it can be conducted to the service provider based on the BIN code of the first payment account number.
[0010]
In this method, the service provider further includes responding to the first approval request by transmitting a second approval request for approval of the transaction with the second payment account number, wherein the second approval request The bill includes an 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).
[0011]
In addition, a response to the second approval request is accepted by the service provider from the issuer, where the response includes a acquirer code associated with the service provider and can be conducted through the payment network based on the code. . The response to the first approval request is then transmitted to the acquirer by the service provider based on the response to the second approval request, and the response to the first approval request is preferably an acquirer code associated with the acquirer. And can be conducted through the payment network based on the code.
[0012]
  In another preferred embodiment of co-pending application 09 / 833,049, a method is provided for conducting a transaction with a merchant using a first payment course number associated with a second payment account number. Here, the law is based on (a) one or more transaction detailsMessage authentication code(B) for the merchant, at least the first payment account number andMessage authentication code(C) The merchant side requests authorization for the transaction payment using the first payment account number, where the payment is processed at the point-of-sale terminal by a conventional magnetic stripe payment card. Is formatted to beMessage authentication codeIs transmitted in a free-choice data field contained in a track of the type used for the magnetic stripe of a conventional payment card; (d) the second payment account associated with the authorization request for the first payment account number Respond by requesting authorization for payment of the transaction using a number, and (e) a second payment account number andMessage authentication codeAccepting or rejecting the approval response for the first payment account number based on the response to the approval request for the first payment account number.
[0013]
This system can be further improved and further enhances safety and efficiency to protect messages and information transmitted during or in connection with money transactions on public communication lines. It is also possible.
[0014]
  (Summary of Invention)
Thus, according to the present invention, a method is provided for performing an electronic transaction with an account number using a pseudo-expiration date on a public communication network. The preferred method is
  Associated with account numberPer-Card KeyGenerating;
  Per-Card KeyUsing messageAuthenticationGenerating code;
  messageAuthenticationConverting the code to a pseudo-expiration date;
  Generating an approval request for the transaction, wherein the claim has an expiration date field including a pseudo-expiration date; and
  Message based on the expiration dateauthentication codeTheValidationIncluding.
[0015]
The preferred method further includes a payment network including an issuer of an account number having a true expiration date, wherein a second approval request is generated that includes the true expiration date, and the second claim is It is characterized by being forwarded to the issuer for transaction approval.
[0016]
  One more detailed embodiment of the present invention includes a payment account number with an associated pseudo account number and includes the following steps. That is,
  (A) using a payment account number and a pseudo account number to relate to the pseudo account numberPer-Card KeyThat the service provider generates;
  (B) saidPer-Card KeyCreating secure payment applications used for transactions, including
  (C)Per-Card KeyUsing messageAuthenticationGenerating a code ("MAC");
  (D) MAC by secure payment application including pseudo account number and MACValidation requestGenerating;
  (E) MACValidationDoing;
  (F) saidValidationCreating an expected transaction sequence number (ETSN) for the MAC based on
  (G) provide a secure payment application with reference data;
  (H) the expected transaction sequence number andPer-Card KeyUse the second messageAuthenticationCreating a code;
  (I) Second messageAuthenticationConverting the code to a pseudo-expiration date using the reference data;
  (J) generating an approval request with an expiration date field that includes the pseudo expiration date; and
  (K) a second message in response to the approval request and based on a pseudo-expiration dateAuthenticationthe codeValidationIt is to be.
[0017]
  According to another embodiment of the present invention, there is provided a method for performing an electronic transaction over a public communications network, wherein the payment account number has an associated pseudo account number, the method comprising: Including: That is,
  (A)Authentication keySupplying a pseudo account number with a control field indicating the key generation process or processes used for generation;
  (B) using one of a plurality of key generation processes indicated in the control field of the pseudo account number, to associate with the pseudo account number;Authentication keyGenerating;
  (C) saidAuthentication keyA message specific to the transactionAuthenticationGenerating code;
  (D) MessageAuthenticationGenerating an approval request message including a code and a pseudo account number; and
  (E) the indicated key generation process;Authentication keyAnd the messageAuthenticationthe codeValidationIt is to be.
[0018]
  According to yet another embodiment of the present invention, a method for performing an electronic transaction on a communication network by account number comprising:
  Associated with account numberPer-Card KeyGenerating;
  AbovePer-Card KeyUsing messageAuthenticationGenerating code;
  The messageAuthenticationProviding at least two different modes of operation for the code to proceed in different ways with approval requests with different fields, wherein at least one of the modes of operation is a messageAuthenticationThe code is advanced to the expiration date field, and at least one of the operation modes is a messageAuthenticationCode, messageAuthenticationAdvance to the code field. Preferably, the messageAuthenticationCode, messageAuthenticationIf a code field exists, the message is automaticallyAuthenticationTransported to the code field.
[0019]
(Detailed description of the invention)
The present invention is directed to a method and system for performing secure payments over a computer network such as the Internet. The present invention replaces the “truth” account number disclosed in co-pending application serial number 09 / 809,367 (ie, the actual card payment account number issued by the issuing facility) with “false” Use "similar" account number.
[0020]
  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 a pseudo account number is stolen, the stolen pseudo account number can perform fraudulent transactions on the Internet under many circumstances.InCannot be used. This is because transactions based on pseudo account numbers are encrypted using a unique secret key for each account number.AuthenticationBecause it is done. This private key is taken up for illustration purposes only within the cardholder's secure payment application ("SPA") and through the service provider facility for purposes of illustration, but MasterCard International Incorporated ("Master Card"). Because it is only inside the highly secure equipment of the facility. Furthermore, the pseudo account number does not disclose the cardholder's true account number, so there is a high possibility that it will be rejected at a normal sales terminal.
[0021]
  Accompanying the drawings are several drawings illustrating exemplary embodiments of the present invention. In this accompanying drawing and the following description, a master card is used to indicate the entity that supplies and processes the pseudo account number. The relevant abbreviations used in this application are as follows:
  BIN-Bank specific number
  DEA-Data Encryption Algorithm
  PC-Consumer PC device
  MACMessage authentication code
  MCI-MasterCard International or Mastercard
  MCWS-Mastercard website
  PIN-personal identification number
  POS-sales floor
  SPA-secure payment application
  SSL-secure socket layer (for Internet security)
  TSN-Transaction serial number
[0022]
According to a preferred embodiment of the present invention, a service provider issues and maintains several components, including a secure payment application ("SPA") of a secure payment system executed in accordance with the techniques of the present invention, and / or Or process.
[0023]
Components of the SPA system
Preferably, the SPA system is transparent to existing payment processing operations (e.g., master cards) and can be transparent to existing merchant, acquirer, and issuer operations. This system preferably utilizes three stand-alone components.
1.1 or more SPA websites
2. SPA wallet for the cardholder's PC (or other Internet access device)
3. SPA approval / cancellation system
[0024]
In brief, the SPA website is used to “register” new cardholders and, in mode 1 (as defined below), send an approval request message to the appropriate SPA approval / release system. It is also used to supply data that must be received before it can be processed.
[0025]
A SPA wallet is software that is downloaded to a PC (or similar) for use in SPA transactions. This is activated by the cardholder clicking on the icon. Once activated, it performs secure Internet payments using a combination of software and data customized to any card.
[0026]
A SPA approval / release system is a physical computing device that processes SPA transactions and converts them into conventional transactions (and in some cases from conventional transactions), and one such device is The above issuer services.
[0027]
The SPA website and / or SPA deauthorization system is also referred to herein as a service provider and / or is associated with one or more service providers.
[0028]
  SPA mode
  Four SPA operating modes are supported by the system. The mode is
  Mode 0:AuthenticationNone
  Mode 1: According to the expiration date fieldAuthentication
  Modes 2 and 3: New field dedicated to SPAAuthentication
[0029]
The advantage of modes 0 and 1 is that no changes are required for existing merchant or buyer operations. Modes 2 and 3 allow the merchant to add a new field to the payment screen (preferably a secret field that is not displayed to the cardholder and is distinguishable by the SPA software on the cardholder PC), and If this field is filled by the PC, the merchant passes this field (unmodified) to the acquirer, which in turn requests it to be passed to the payment system for approval (unmodified). This is the same field used in other systems to transport ICC related data.
[0030]
Mode 2 also indicates that if the merchant has sent a second approval request once as a result of a single transaction with the cardholder, this second (and subsequent) approval request message will be displayed in the expiration date field. It is requested not to have. Such subsequent approval request messages are considered as mail orders / phone orders and are not guaranteed.
[0031]
Mode 3 is the same as Mode 2 except that Mode 3 does not impose the above requirement that the merchant should not send a subsequent approval request message with an expiration date. In mode 3, it does not matter whether such subsequent approval request message has an expiration date or not.
[0032]
Since mode 2 imposes restrictions that mode 3 does not perform, the specifier for the “secret field” for mode 2 is (1) that there is a secret field that can be used as the SPA MAC field, and (2 ) The merchant must carry the fact that it has never sent a subsequent approval request message with an expiration date. The “secret field” that can be used in mode 3 does not have this second restriction, so it has another specifier.
[0033]
A suitable field for mode 3 may be a “generic” field that is accepted by all payment systems for electronic commerce (eg, for ICC used in electronic commerce). On the other hand, mode 2 cannot use such a “generic” field. This is because this mode is only used when the merchant “guarantees” that subsequent expiration request messages will never include an expiration date. Therefore, mode 2 can only be used for merchants who have made special arrangements for accepting SPA transactions, while mode 3 is electronic so that it can be used by all payment systems. Any merchant can be used as long as it has an additional field for commerce.
[0034]
  Mode 2 or 3 is more effective than mode 0 or 1AuthenticationIs preferable in that The SPA preferably operates in mode 0 or 1 unless the merchant has taken the intent to support mode 2 or 3 due to the presence of a “secret field” shown in the merchant payment screen. The SPA in the cardholder's PC always operates in mode 2 or 3 if the merchant supports this mode.
[0035]
Preferably, the cardholder's PC operates in one of three states: “State A”, “State B” or “State C”. In “State A”, the PC operates in mode 1 or 2 (depending on the merchant capabilities), but never in 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 capabilities), but never in Mode 1. The PC is preferably switchable between these states under command from the SPA website.
[0036]
“State A” has the advantage that every transaction has some proof. “State B” reduces the proof provided by Mode 1 to some extent, but has the advantage that a substantially higher proof is obtained for transactions with all merchants that accept the “generic” additional field. “State C” is intended for future use when many large merchants have the “generic” additional field, which significantly reduces the storage requirements imposed on the SPA approval system. For merchants who do not prepare additional fields, there is a cost of no proof. Thus, if more and more merchants are allowed to accept “generic” additional fields, but not the SPA-specific mode 2 additional fields, the issuer can use “state A” from “state A” for the SPA wallet. Transition to “state B” and finally to “state C” is executed. The transition from one state to another is preferably an issuer's choice, so that wallets from different issuers can be in different states.
[0037]
SPA features
As mentioned above, SPA is based on the use of pseudo account numbers rather than the “truth” account numbers that are visible on the cardholder's card. There is a one-to-one correspondence between a pseudo account number and a corresponding “truth” account number. The same pseudo number is used by SPA in all modes. The BIN of the pseudo account number is a “pseudo BIN” that is not stamped on any MasterCard card. Since there is one pseudo-BIN per card issuer, the issuer of a certain pseudo-account number can be identified. The use of a pseudo-BIN specifies an account number of an arbitrary transaction as one pseudo-account number. All merchants and acquirers know the cardholder by a pseudo account number, but the issuer knows the cardholder by a “true” account number. Thus, one of the functions of the SPA system is to “move” between two numbers, as described in co-pending applications.
[0038]
  According to the present invention, another function of the SPA system is associated with each SPA mode 1, mode 2 or mode 3 approval request,Message authentication code("MAC")ValidationIt is to be. For mode 1, in the present invention, the MAC takes the form of a pseudo-expiration date, and the date that is proved is preferably conveyed via the SPA website for each mode 1 transaction. For mode 2 or 3, the MAC becomes part of the “MAC field”, a new SPA field that is added for all mode 2/3 transactions. The date to be verified is also included in this MAC field.
[0039]
The same SPA can have copies on different PCs. Any PC can have SPA wallets for several different cards. In that case, the wallet can be controlled and used by different cardholders.
[0040]
SPA website operation-card registration
If the cardholder on the PC 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 operate in the same manner as described in this application.) SSL encryption is used for all data transmitted between the PC and the SPA website. When a website senses that it has been accessed by a browser rather than an already loaded SPA application, it preferably operates as follows.
[0041]
The website sends an initial screen to the PC. This screen asks for either a “truth” account number or a pseudo account number if the cardholder has already registered the card with some (other) PC. Once the SPA website accepts the information, it looks up the BIN. Since the website maintains a list of all issued pseudo-BINs, it first determines whether the BIN for the given account number is on the list. If so, it is a pseudo account number, otherwise it is a “true” account number.
[0042]
If the BIN represents a “true” BIN, the SPA website determines whether the issuer is participating in the SPA. If the website does this by maintaining a second table that associates the “truth” BIN with the pseudo-BIN and finds in this table a description corresponding to the “truth” BIN in question. I understand that this issuer is participating in SPA. In either of these two situations, the SPA website acknowledges that the SPA wallet can be paid for this card. If the issuer is not participating in the SPA, the SPA website preferably sends a message to the cardholder notifying him / her that the SPA wallet is not available at this time.
[0043]
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. Whether the cardholder is in front of the owning / controlling PC
4). If a “truth” account number was supplied in the first pass, rather than a fake account number, whether the cardholder previously registered the card for SPA,
5). If the card has been registered for SPA before (if indicated by “yes” for the preceding paragraph or by using a pseudo account number), the cardholder will provide the password selected at the time of registration. Whether you remember,
6). If the card has been previously registered with SPA and the cardholder remembers the password (if the cardholder asks question number 4 and answers “yes”) The selected password.
[0044]
Question No. 5 is always included when the cardholder enters a pseudo account number on the first screen, but Question No. 4 is not asked. In other cases, question number 4 is asked, and if the cardholder answers “yes” to that question, question number 5 is added. If question number 5 is asked and “yes” is answered, item number 6 is added.
[0045]
If this is the first registration for this account number, or if the cardholder does not remember the password at the time of the previous registration, the SPA website will include the issuer's unique proof-of-confirmation question. Send three screens to the PC and request the following information. (1) "SPA registration code" received by the cardholder via email, (2) CVC2 printed on the back of the card, (3) Social security number of the cardholder (or part of the number), ( 4) First name and last name before marriage of the cardholder's mother. The content of this third screen is preferably confirmed by the issuer and presents a request for the proof information selected by the issuer. This third screen also provides a place for the cardholder to enter a password. This is because when a cardholder activates the SPA in the future, or in the future, the issuance of the currently billed SPA wallet will be approved by the card issuer, It must be used when requesting a copy. Note that if a SPA already exists for this account number, this password must replace the previous password in order to begin a new SPA copy. It should also be noted that, for example, if a couple share the same account number, the couple will share the same pseudo account number, and therefore the same to launch a new SPA copy on another PC. The password must be used. (However, if the husband / wife does not know this password, a new SPA copy may be activated on another PC by answering the proof question.)
[0046]
Upon receipt of this information from the cardholder, the SPA website determines the address of the SPA authorization system that processes the authorization request for this pseudo-BIN from the presented account number BIN. To do this, the SPA website maintains an address table that is accessed by a pseudo-BIN and supplies the corresponding SPA approved system address (es). After making this determination, the SPA website transmits the information obtained from the cardholder to the SPA authorization system by secure means (eg, under SSL encryption). Websites do not need to keep a copy of this data. This is because the data is returned from the SPA approval system to the website.
[0047]
The communication method 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 approved system and also its telephone number. Another possibility is via a payment network such as MasterCard Banknet, where the “address” is simply a pseudo-BIN itself.
[0048]
Once the SPA authorization system accepts the registration request, it verifies that it is a proper facility for the indicated BIN. If not, 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 a "Please wait" message to the cardholder's PC. If the operator is unable to resolve the problem promptly (eg, 5 minutes), the SPA website will notify the PC that it is currently unable to supply the SPA wallet for this card.
[0049]
If the SPA authorization system successfully completes registration, it sends a message, preferably consisting of: to the SPA website, preferably by: That is,
1. Cardholder's name, address and phone number
2. Fake account number
3. Card expiration date
4). The last 4 digits of the “truth” account number
5). Irreversibly transformed password
6). Card key encryption password
7). SPA copy count or single session count
8). SPA version number
9. SPA single session indicator
10. SPA status
11. Pseudo BIN key indicator
12 Card product name (for example, “Master Card”, “Maestro”, “Master Card Cash”)
13. "Truth" account number
14 1st SPA flag (1 = new fake account number just confirmed)
[0050]
The SPA authorization system also returns all the information required by the SPA website to route the answer to the cardholder PC.
[0051]
Upon receipt of this message, the SPA website places items 1 through 12 above in the SPA wallet, along with software corresponding to that SPA version number. The wallet further includes a mode 1 and mode 2/3 transaction serial number and an initial value of zero for the password failure counter. The SPA website then transmits this SPA data to the cardholder PC, which stores the data.
[0052]
The SPA provides a menu of cards that can be used on the PC with the SPA installed. The SPA preferably provides the following information for each card in a row of PC screens.
1. Card counter account number
2. SPA copy count (if this is not a single session SPA)
3. The last 4 digits of the “truth” account number on the card
4). Card expiration date
5). Cardholder name
6). Card product name (for example, “Master Card”, “Maestro”, “Master Card Cash”)
[0053]
Each time a new SPA wallet is added to the PC SPA, the new card must be added to this menu list. Cards are listed with the first registration as the first order in the order of registration for the SPA. This list is used by the cardholder to select a card for the current transaction. As described above, each card is associated with a specific software set (however, two cards having the same version number use the same software). It should be noted that in many cases, another SPA is never installed on this PC, so there is only a single card in this list.
[0054]
The cardholder can now execute the SPA transaction.
[0055]
SPA approval / cancellation system
As briefly mentioned above, all card issuers participating in the SPA are served by a single “primary” SPA approval / cancellation system. In this case, if necessary, the system can provide services to a plurality of issuers. In the case of a fully operational SPA system, there is at least one “backup” SPA approval / removal system that can be used whenever the primary system is not available (eg, a failure). Good. Using a “backup” SPA approval / release system, SPA transactions are completed, but the quality of safety is reduced (temporarily).
[0056]
Each SPA authorization / cancellation system that serves multiple issuers is preferably connected to a payment system, such as MasterCard's Banknet, via one or more dedicated servers. This system accepts approval request messages and release messages through Banknet, and contacts the issuer through Banknet. Such a system preferably operates in a manner that is completely transparent to its supporting publisher.
[0057]
A single issuer version of the SPA approval / release system is also available. Such a version directly contacts the issuer's processing system. This version requires some re-modification on the issuer's side. The fix recognizes SPA transactions by their pseudo-BIN (s) and passes those transactions to SPA authorization / cancellation systems (eg, service providers), thereby removing the pseudo account number. Conversion to a “truth” account number and MAC proof (approval request message only) must be performed.
[0058]
Another version of the single issuer SPA approval / release system may be installed between the issuer's MIP and the user's processing device. Although this system can be transparent to the issuer, all traffic to and from the MIP must pass through this SPA system.
[0059]
Finally, the approval and release functions for an issuer need not be performed by the same physical box. The issuer causes the issuer's approval request message to be processed by a SPA approval system that contacts the issuer via a Banknet, while the release message connects directly to the member's processing system. It may be processed by a person SPA cancellation system.
[0060]
Initially, there may be only a relatively small number of SPA approval / cancellation systems. As more and more publishers or groups of publishers choose to have their own SPA approval / release system, the appropriate data from the original system (serving many publishers), Provisions must be made to transfer to a new system (serving only one or at least a few issuers than the original). The pseudo account number, whatever it is, preferably receives services from only one SPA authorization system. Therefore, this transfer must be feasible for any transaction in progress at the time of the transfer with minimal disruption to it.
[0061]
Fake account number
For one “truth” payment account number, the associated pseudo account number is preferably a 16 digit number in length. This 16-digit pseudo account number starts with a 6-digit BIN dedicated to this account number. The BIN may be unique for any member of any bank or service provider federation, and may be unique for any product (eg, a gold card, association card, etc.) within the member. Good.
[0062]
Two numbers (or one number if necessary) immediately after BIN may be reserved as a “control field”. This field indicates an algorithm or the like used with this pseudo account number.
[0063]
Since the check digit is appropriate for the pseudo account number, this will leave about 7 digits, or if necessary, 8 digits, so each BIN can have a maximum of 10 million (or more) for each control field value. 100 million) account numbers can be represented.
[0064]
This pseudo account number structure allows the issuer to be uniquely identified by BIN, so that the issuer (1) identifies the “foreign” transaction, and (2) bi-directionally with him It is possible to identify other issuers with an agreement. As described below, issuers who are willing to modify programs and obtain appropriate safety modules will be able to perform their own proofs, so there are also “front-end” transactions. Transactions of other facilities of a species can be executed together with the facility itself. This eliminates the need to send the transaction to a service provider (or master card SPA facility).
[0065]
Preferably, the right seven (or eight) digit number, excluding the check number of the pseudo account number, is an indication identifying a particular account within the facility identified by the left six digit number. Initially (if indicated by the control field value) this reading may be common to all facilities. A number of 7-digit (or 8-digit) readings per BIN are 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 numerical values may be assigned sequentially (for each facility) or randomly. Alternatively, it may be assigned in order and then encrypted (to a random 7 or 8 digit decimal number) and included as a pseudo account number.
[0066]
The advantage of assigning account number readings randomly or assigning them in order and then encrypting them to be included in the pseudo account number is that the enemy (for example, people who cheat) is legitimate. Is to make it more difficult to "guess". If account number readings are assigned in order, the fake account number available to the enemy, i.e., a fake account number that is less than the assigned fake account number, or a little larger This is because it is very easy to “guess”. By using a randomly assigned or encrypted account number reading at a time when only a relatively small number (eg <10%) of the number possible for a facility is assigned, There is only about 1 out of 10 chances to “guess” the correct account number reading. This makes it more difficult for an adversary to find a pseudo account number that allows unauthorized use.
[0067]
If the issuer wishes to perform his / her transaction on a transaction with a pseudo account number, the service provider will list all pseudo account numbers in numerical order, corresponding to each “truth” account number. May be given. If this pseudo account number includes an actual reading, the service provider need only give the issuer a “truth” account number arranged in the display order. If the pseudo account number includes an encrypted account number reading, the service provider will give the issuer a unique key (unique to the issuer) and then display the “truth” account number if necessary. It is also possible to give them in order. Perhaps the service provider tells the issuer a retrograde table (similar to what the issuer needs to store the pseudo account number for each transaction that performs an account number translation from pseudo to “truth”). There is no need to give However, if it is necessary to provide the issuer with a retrograde table, the table should list each “truth” account number for the issued pseudo account number, followed by the corresponding pseudo account number in numerical order. become.
[0068]
In any case, the service provider facility maintains a table that grants the ability to convert pseudo account numbers to "truth" account numbers and to convert "truth" account numbers to pseudo account numbers.
[0069]
Card authentication key calculation
  Unique to cardAuthenticationThe key is based on an encryption process of the pseudo account number and the corresponding “truth” account number. A process in which an intermediate BIN unique key is generated is desirable. This is because it is prepared for use by national SPA facilities and by card issuers who wish to perform proof of SPA transactions themselves. In this way, even a nationwide facility only needs to be given one key per pseudo account number BIN.AuthenticationThe issuer who executes the transaction only has to get one key per 10 million pseudo account numbers (for example). Even if the key of one national SPA facility is in danger, the security of other countries will not be jeopardized. Even if one issuer's key is in danger, the security of other issuers is not jeopardized.
[0070]
  The key generation process used with any pseudo account number may be indicated by the control field of the pseudo account number. A possible key generation process for performing the purpose is as follows. That is, only the central SPA facilityAuthentication keyHolds a top-notch triple-length DEA key, called a “guide key”. For any given pseudo account numberPer-Card KeyThe preferred process performed by the safety module of this central SPA facility (e.g., MasterCard SPA facility) is as follows.
  1. In a 64-bit field, out of 6 pseudocodes (BINs), which are considered to be 6 binary code decimal numbers, align the left 6-digit numbers to the left and arrange zeros on the right. 24 bytesAuthentication keyUse the 8 bytes on the left side of the guide key as the encryption key to DEA encrypt these 64 bits.
  2. 24 bytesAuthentication keyUse the middle 8 bytes of the guide key as the decryption key to DEA decrypt the result of step 1.
  3. 24 bytesAuthentication keyDEA encrypt the result of step 2 using the right 8 bytes of the induction key as the encryption key.
  4). Use the result of step 3 as the unique 16 bytes versus the left 8 bytes of the BIN key.
  5. In a 64-bit field, each 4 bits of 6 binary code decimal digits (BIN) considered to be decimal digits, the left 6 digits are aligned to the left and the right is binary Line 1 up. 24 bytesAuthentication keyUse the 8 bytes on the left side of the guide key as the encryption key to DEA encrypt these 64 bits.
  6). 24 bytesAuthentication keyUse the middle 8 bytes of the guide key as the decryption key to DEA decrypt the result of step 5.
  7). 24 bytesAuthentication keyDEA encrypt the result of step 2 using the right 8 bytes of the induction 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. A 16-digit "truth" (not pseudo) account number (binary code decimal digits, right-justified, with binary zeros on the left if fewer than 16 digits) Can be encrypted 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 The result of step 11Per-Card KeyUse it as the left 8 bytes.
  13. Binary to the 16 digits to the right of the “truth” account number (decimal digits in binary code, right justified and, if less than 16 digits, binary zeros on the left) Pattern 0101010. . . Next, encrypt using the result of step 4 (8 bytes to the left of the BIN key) as the DEA 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. The result of step 15Per-Card KeyUse 8 bytes on the right side of.
[0071]
  When a central SPA facility creates an SPA for a cardholder's PC,Per-Card Key(From steps 12 and 16) are included in a manner not disclosed during normal operation of the application.
[0072]
  Message authentication codeUpon receipt of the pseudo account number in the transaction, the SPA facility establishes the “truth” account number, then the MACValidationIn order to create a key necessary for the above, the 16 steps are executed.
[0073]
If the SPA facility needs to create a key to be retained in the national SPA facility or issuer's safety module, for each BIN unique to that country, or for the issuer's BIN, Perform steps 1-8. These keys are then securely delivered to the national SPA facility's or issuer's safety module, so that each key has a pseudo account number BIN (and control field) used to create it. ). The safety module then starts with the key indicated by the pseudo account number BIN for each transaction it receives with a pseudo account number, a “truth” account number, a MAC, and a designated control field. Then, the above steps 9 to 16 are executed using this key as a BIN key to create a key for certifying the MAC.
[0074]
SPA start
Next, specific SPA activation will be described with reference to the drawings. FIG. 1 first depicts how a cardholder carrying a money transaction card obtains a secure payment application from an SPA website or service provider over the Internet, in accordance with an embodiment of the present invention. Initially, to use and enjoy the benefits of the present invention, a physical card is not required, only an account number that identifies a user or participant and connects him / her to an account for performing a financial transaction. It must be understood that it is issued to the holder (in this case the card holder). The cardholder may contact a website associated with the service provider using a suitable device capable of communicating over the Internet, such as a computer, mobile phone or electronic secretary (PDA). In the following discussion, for simplicity, it is assumed that the cardholder uses a computer to communicate over the Internet.
[0075]
  As shown in FIG. 1, service providers, such as MasterCard International Incorporated (ie, MasterCard Agents), are under the control of one or more physically secure modules 12, which are located within the module. Provides physical protection for information stored in Each of these secure modules includes one or more “guide keys”, which are account unique secret keys (provided inside the secure payment application, as described below).Per-Card Key) Is used to create and recreate.
[0076]
  First, according to a preferred embodiment of the present invention, the cardholder must obtain an SPA from a service provider. The preferred process for downloading and launching the secure payment application (SPA) is:
  1. The cardholder contacts the service provider's website via the Internet (directly or from another website, eg, the issuer's website to the website through a hyperlink).
  2. The cardholder may use (a) a payment card account number, (b) a card expiration date, and (c) a card under SSL encryption generally known to the parties.AuthenticationSupply information. cardAuthenticationThe information may include, for example, the CVC value of the card, i.e. three to four numbers printed next to the signature panel of certain cards, as described above. This number is generated by the issuing bank using a secret encryption key, but using that same keyValidationIs possible.
  3. The service provider may confirm the legality of the card account number and the card expiration date by obtaining a zero value authorization from the cardholder's payment card issuer. For example, the master card can obtain such authorization via the Banknet communication network.
  4). The service provider issues the CVC2 value to the service provider from the cardholder's payment card issuer.ValidationWhen the encryption key (single or plural) is provided, the CVC2 value may be proved.
  5). The service provider may prove other card certification information by sending that information to the issuer for certification. To facilitate this, the service provider's website, or for example MCWS, may maintain a list of items to ask consumers when registering for SPA. For a list of such items,
Item number Item description
01 CVC2
02 PIN
03 First and last name of mother before marriage
04 Final charge in this account
05 Name of the city addressed to the invoice
06 Last 4 digits of social insurance number
[0077]
The issuer can specify what data the service provider wants 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 designate different data items for each BIN. The service provider's website chooses a question and prompts the consumer to respond. The result is supplied to the issuer as part of a zero value approval request.
[0078]
6). After verifying the legitimacy of the data provided by the cardholder, the service provider ("SP") creates or selects a pseudo account number and a private key and places these data elements in the secure payment software application. Include. This application is made available for download to his / her PC by the cardholder on the Internet, preferably under SSL encryption.
[0079]
The pseudo account number has as its BIN a special BIN reserved for the pseudo account number. The remainder of the pseudo account number is a numeric value 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 number is correct in the pseudo account number.
[0080]
Preferably, the assigned special service provider BIN may be selected from a set of many such special BINs, in which each BIN is a specific bank or a specific country or It may correspond to a region or a specific product within a country or region.
[0081]
  A secret that is preferably embedded in the SPA by the service providerPer-Card KeyIs unique for each card account number, and is preferably derived within the safety module using the card account number and a lead key. (This process is further detailed below). The derived key itself may also be derived from the same or another safety module using a higher level derived key.
[0082]
The cardholder may supply the password to the service provider before downloading the secure payment application, or may select the password when the secure payment application is installed on the cardholder's computer. Once a password is supplied or selected, the cardholder is required to enter that password in order to launch the secure payment application on his or her PC.
[0083]
As will be appreciated by those skilled in the art, the service provider may periodically update the SPA and make the SPA downloadable as part of the digital wallet application. In addition to SPA, a digital wallet may store one or more of the following: A cardholder's personal information; a parsing application; a debt application; a consumer-to-consumer application; and other applications, all of which are secured under SPA.
[0084]
SPA wallet operation-first session launch
The SPA in the PC is activated when the cardholder clicks on the SPA icon displayed on his / her PC screen. When activated for the first time (after initial installation or after being closed before), the first task performed by SPA is for the cardholder, the SPA card (previously SPA wallet has been obtained for it) Card list) and prompt the cardholder to select the card he / she wants to use for the current transaction.
[0085]
Note that multiple cardholders may share a common PC. Thus, the cardholder name becomes part of the display information for each SPA card, and each card has its own SPA password of cardholder selection.
[0086]
If the cardholder selects a card from this common list, SPA preferably checks the password failure counter for this card. If this counter exceeds the SPA internal threshold, the SPA card notifies the cardholder that an excessive number of unsuccessful password entry attempts have been made and must be re-registered. The SPA then displays two choices, “re-register” or “cancel”. If the cardholder selects the former, the SPA contacts the SPA website, suspends and replaces the browser. If the cardholder chooses the latter, the SPA simply breaks.
[0087]
If the SPA determines that the password failure counter for the selected card does not exceed a specified threshold, the cardholder is prompted to enter a 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, the SPA irreversibly transforms this password and compares it with the SPA stored value. If no exact match is found, the SPA advances the password failure counter for this card (this has been saved by the SPA and may therefore have a non-zero value when the SPA is triggered), Prompt for password re-entry. This process is repeated until the password is entered properly or until the password failure counter reaches a specified value. In this later case, the SPA saves the current value of the password failure counter and suspends after giving the cardholder the aforementioned “re-registration” or “cancel” option. If the cardholder does not succeed in entering the proper password and deactivates the SPA, the SPA also saves the current value of the password failure counter.
[0088]
  If a strict match occurs between the irreversibly converted cardholder-entered password and the number stored inside the SPA, the SPA resets the password failure counter, preferably this just-proven Using password as encryption keyPer-Card KeyIs decrypted. The SPA then displays the cardholder's address and phone number, asks "Did your address and phone number change?", And provides "yes" and "no" buttons. Clicking on “yes” displays a window that allows the cardholder to correct the address and / or phone number.
[0089]
SPA Next checks the expiration date of the card just selected and determines if the card has already expired (based on the PC clock) 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, asks the key to enter the expiration date of the new card. (The cardholder has the option of saying “no”.) The SPA is now ready to process the transaction for this newly selected card.
[0090]
SPA operation
  As described above, a secure payment application (“SPA”) may have different modes of operation for payment transactions, including: That is,
  1. Use only the expiration date fieldAuthentication
  2. Use additional fieldsAuthentication
[0091]
Mode 2 is used when the merchant can accept additional fields in the transaction and is referred to as “MAC field” in this application. This gives a higher level of proof than mode 1 and is used whenever possible. The merchant must indicate that the SPA is mode 2 compatible by including the MAC field in the data field that may be filled by the PC, relative to the SPA in 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, the merchant will pass this MAC field to the acquirer, so that It must be possible to supply a field.
[0092]
If the PC cannot find the MAC field on the merchant screen, the PC operates according to mode 1.
[0093]
The following description describes the preferred operating state of the SPA in these two modes by example.
[0094]
The registration process through which the cardholder's PC (or other device) obtains the SPA is as follows. SPA software accepted by the cardholder's PC supports both modes of operation. A separate transaction sequence 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.
[0095]
Mode 1-Proof of Use Only Expiration Date Field
In mode 1, the expiration date field of the approval request message is used to carry some form of MAC. This “pseudo” expiration date, like all expiration dates, is formatted as MMYY. Preferably, the pseudo-expiration date must fall within the next 48 months to work with many or all merchant current processing systems in the market today.
[0096]
The mode 1 transaction sequence number consists of 20 binary bits and is advanced for each mode 1 transaction. Therefore, 2²⁰= Not all 1s to all zeros until 1 million Mode 1 transactions occur. To the left of this field is a “version number” consisting of 4 bits. This is a unique number for each PC where a SPA for any given account number stays.
[0097]
As mentioned above, the SPA wallet looks at the currently displayed screen for a “secret field” where it can place the MAC field. If such a field is found, it proceeds to mode 2 or mode 3 as described below.
[0098]
If the SPA cannot find the field, it uses the same language that was used for the previous transaction, and it can be "understood" in the fields: "name", "address", "phone number" Look for "Card Number" and "Card Expiration Date". If many of these fields are not found, the SPA will prompt the cardholder to select the screen language. If the language selected by the cardholder is different from what the SPA was using previously, the SPA repeats the trial. If the SPA can identify no or very few fields, the cardholder is asked to verify that the merchant payment screen really exists. (Because the cardholder's SPA can be activated too quickly.) If the cardholder indicates “no” (the merchant payment screen is not displayed), the SPA will be interrupted and control Revert to a previously running program (perhaps a browser).
[0099]
  If the cardholder indicates “yes” (payment screen is displayed), or if the SPA can identify many or all of the merchant payment fields, the SPA will automatically identify it. Fill the field (or any if any). The SPA then prepares a message to send to the SPA website. All communications between the PC and the SPA website (in either direction) must be protected using SSL encryption. This message may consist of: That is,
  1. Pseudo account number (as 16 decimal digits)
  2. Pseudo BIN key indicator (8 bits)
  3. SPA state indicator (1 bit: 0 = “state A”, 1 = “state B” {“state C” has no mode 1 transaction})
  4). SPA version number (as 15 bits). This field indicates the SPA type (credit, debit, prepaid) and the revision number of this type. In the case of a credit card SPA, revision 0, SPA version number is hex 0000.
  5). Single session SPA indicator (1 bit: 0 = normal SPA, 1 = single session SPA)
  6). SPA copy count or single session count (as 10 bits)
  7). Last used mode 1 trading order number (as 20 bits)
  8). Card expiration date (4 binary code decimal or 16 bits)
  9. MAC, preferably consisting of 16 to 32 binary bits, preferably carried in data elements 3 to 8 (preferably in this order),Per-Card KeyMAC generated using.
[0100]
The SPA wallet then contacts the SPA website via the Internet and transmits the data element. The wallet then waits for a response (while the SPA website contacts the appropriate SPA approval system). After a few seconds, the SPA wallet displays "Please wait" for the cardholder. Other text is then displayed, describing to the cardholder that the SPA is in contact with the master card in preparation for the desired transaction, and therefore takes some time. The display preferably changes once every few seconds so that the cardholder knows that something is happening now.
[0101]
If too much time passes, the SPA wallet will contact the SPA website again and repeat the claim. If the SPA is unable to contact a SPA website that is normally accessible, it will contact a backup SPA website. If, after a specified time and number of such attempts, the SPA fails to get a response from the SPA website, the SPA will indicate to the cardholder, “This transaction could not be completed at this time. ”And stop. This time, the cardholder must retry another SPA card, another payment instrument (eg, manually entering a master card account number), or later.
[0102]
The response that SPA will ultimately accept from the SPA website is a “Cannot proceed” display, a “Can proceed” display, or a “Change status” display.
[0103]
If the response is a “Cannot proceed” indication, SPA will also give a “reason” code. There are preferably three reasons.
1. This SPA copy number is no longer valid (because relatively recent SPA copies have the same “n” bit 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. MAC was not proved, transaction serial number is not valid, or "invalid until ..."-indicator has future date or "invalid copy" flag is set .
[0104]
If the “cannot proceed” display is for the first reason, the cardholder is preferably notified of the following: That is,
MC-Internet. com, you must re-register this card for this PC. Since you first registered this card on this PC, you registered this same card on another PC a total of at least 16 (or another number) times. As a result, your original registration on this PC is no longer valid.
[0105]
If the “Procedure impossible” indication is for the second reason, the following information is provided to the card holder.
This card on this PC was only usable for 4 hours (or other time). This time has expired. To continue, you must contact MC-internet.com and re-register this card for this PC.
[0106]
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, the SPA on the PC contacts the SPA website and then interrupts. By activating the second one, the SPA of the PC is immediately interrupted.
[0107]
If the “Procedure Not Available” indication is for a third reason, the attempt is a possible fraud and the cardholder is provided with the following information:
Inability to proceed. Please contact the issuer.
After this message is displayed, SPA will be suspended.
[0108]
If the response is “changed” display, the identity of the new state 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 initiate another Mode-1.
[0109]
If the response represents "procedure available", this response is made with the following data (not displayed on the card holder):
1. Base date to be described later (2-byte formatted YYMM as a binary-coded decimal number)
2. Month number indicator (2 bytes as a 4-digit binary-coded decimal number)
[0110]
In this case, the SPA preferably proceeds as follows.
1. Increment the Mode-1 transaction sequence number.
2. This transaction sequence number and Per-Card Key are used to form a 64-bit binary MAC.
3. This 64-bit binary MAC is converted immediately after receipt from the SPA website using the reference date and the number of months indicator to the pseudo expiration date.
4). This pseudo-expiration date is placed in the “expiration date” area of the customer's payment screen if the SPA can indicate it.
5). The pseudo account number is placed in the “account number” area of the customer's payment screen if the SPA can indicate it.
6). If there are any items on the customer's payment screen that the SPA cannot show or occupy, a “drag and drop” menu is displayed that lists the items that are not yet occupied (remaining).
7). Display a message on a cardholder with basic data for the customer and then interrupt (SPA is unknown and some such as a cardholder customer number with this customer that has to be entered manually by the cardholder There can be data, which causes the browser on the PC to send this filling screen to the customer.)
[0111]
The data in the “drag and drop” menu includes any of the following items that the SPA was unable to show on the customer payment screen.
1. Cardholder name displayed as the actual name (John R. Jones).
2. The address of the card holder displayed as the actual address (111 First Street, Ely. NV99999).
3. The phone number of the card holder displayed as the actual phone number (650-111-2222).
4). The card account number displayed as the word “card account number” (because the cardholder is unknown or does not recognize the pseudo account number).
5). Card expiration date displayed as the word “card expiration date” (because it is a pseudo expiration date and is meaningless to the card holder).
There is also a “Cancel” button when the screen does not require all of these items. If the “cancel button” is hit before the pseudo account number and pseudo expiration date are displayed on the customer payment screen, the following message is preferably displayed to the card holder.
Do you want to cancel? You cannot accept payment by cancellation. A "Yes, Cancel" button and a "No, Continue" button follow.
[0112]
If the “yes” button is selected, the SPA is interrupted and control returns to the browser (no matter what program was previously executed). If "No" is selected, the "Cancel" window is removed and SPA continues the "Drag and Drop" procedure.
[0113]
If the SPA completes successfully and is interrupted as a result, it is assumed that control returns to the browser and that the cardholder uses the browser to send the customer's currently filled payment screen to the customer. There is no need to activate SPA again until the cardholder prepares for another purchase.
[0114]
Specific handling of Mode-1 SPA requests
Preferably, a Mode-1 SPA is initiated during each transaction before making a payment based on SPA. As shown in FIG. 2, the SPA can request a website or server (preferably a master card service provider) to consist of (for example) a 16-digit pseudo account number and an actual account number of 4 digits. Send out a decimal date, a 4-bit SPA version number, a current value of a 20-bit Mode-1 transaction sequence number (TSN), and a 16-bit MAC based on the last three digits. 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). ) Concatenated 16-bit expiry date (as a binary decimal number), left-aligned 64-bit region and padding for validity using binary ones, resulting in Formed by the selection of the leftmost 16 bits of the encrypted character to be generated.
[0115]
  FIG. 3 shows the sequence of steps involved in SPA initiation and transaction payment preparation in Mode1. As already explained, the SPA first sends a start request to the service provider in step 20. When the MasterCard website receives this information, it willPreferably, Using SPA system with special security module, FullFinishedDay,SPA version number and transaction sequence numberBased on MACCheck. If the MAC is valid, the system increments the transaction sequence number to form a “predicted transaction sequence number” in step 24 and processes the SPA authorization request for the BIN of the displayed pseudo account number. Update the associated pseudo account number for the SPA authorization system and the “forecast transaction sequence number” for the SPA version number. However, in step 26, the SPA authorization system will have a “predicted transaction sequence number” that is less than or equal to the highest number of “predicted transaction sequence numbers” previously received for this pseudo account number and SPA version number, Reject the "predicted transaction sequence number" just received. In step 28, the SPA authorization system is given the expiration date received immediately before and updates the expiration date associated with this pseudo account number if it is after the currently recorded expiration date.
[0116]
This special SPA system has the following two reference data values: 1) a 4 digit decimal number with the format MMYY (actually this month or the next month) and 2) a maximum of less than 256 (decimal number) A data value, called an 8-bit binary “month indicator” with a value, is sent to the master card website and then sent to the SPA of the cardholder PC in step 30. This data is included in the information sent to the appropriate SPA authorization system.
[0117]
Pseudo expiration date
First, the number of Mode-1 transaction sequences is incremented with respect to the actual Mode-1 transaction. Then, the resulting 20-bit number having a 4-bit SPA version number on the left side is aligned to the left side in the 8-byte area and padded and doubled for validity using binary zeros. Triple DEA encryption using a key for each long SPA card is performed. The result is a 64-bit binary MAC.
[0118]
In step 32, the pseudo-expiration date field of the transaction is obtained from the 64-bit binary MAC as follows.
1. Select the leftmost “1” bit in the “month indicator” (binary number) and set the number of bit positions from this bit position to the rightmost bit (the leftmost “1” bit) Counting (including the bit position). This number is referred to as “N”. For example, when the “month number indicator” is 01010100 (84 decimal), the value “N” is 7. Having determined “N”, considering a 64-bit binary MAC as each group of “N” bits, ignore the left one beyond the rightmost bit. Starting from the leftmost group, select the first group encountered below the “months indicator”. If no such group is found, 2 from this group^NThe leftmost group is selected from the subtracted and this result (> 0 and <months indicator) is used as the selection value.
2. The result of step 1 is divided by the binary number 1100 (12 in decimal) to generate a quotient and a remainder. These quotients and remainders are converted into decimal numbers. The remainder of the decimal number (with a value in the range of 00 to 11) is added to the leftmost two digits (MM) of the decimal “base date”. If the result is greater than 12, subtract 12 from the result, resulting in the leftmost two-digit MM result for the pseudo expiration date for the current transaction, regardless of whether the result is greater than 12. To obtain a result requiring subtraction of 12, increment the quotient (1).
3. mod-100, add the rightmost two digits (YY) of the “reference date” to the two-digit decimal quotient from step 2, which may be incremented as shown in step 2. The rightmost two digits YY of the pseudo expiration date for the current transaction are used as a result.
[0119]
Communication between card holder and customer
Once the SPA is installed on the cardholder computer, the cardholder preferably uses the SPA for internet payments, and the SPA uses a pseudo account number for the cardholder for all internet transactions. I will provide a. In SPA Mode 1, it is clear to the customer that this is a SPA transaction. Even though the account number is actually a pseudo account number and the expiration date is actually an indication of MAC, the customer is unaware that the transaction is different from any other Internet SSL they receive.
[0120]
Processing of requester of authorization request
FIG. 4 illustrates communication between an acquirer 34, a service provider (master card) 20, an issuer 36, and a buyer 38 according to an embodiment of the present invention.
[0121]
When the acquirer 34 receives the permission request message from the Internet customer 38, the acquirer 34 looks up the issuer BIN in the BIN table. In the case of a pseudo account number transaction, the “issuer” corresponds to a processing facility authorized by the service provider or master card.
[0122]
In one embodiment of the present invention, some countries may have special safety module equipment facilities to process their own transactions. Each such facility is set up with the approval of a central service provider only and holds only the country-specific encryption key and account number conversion data to be processed in the transaction. In a country with such a SPA facility, all transactions are sent to this facility, so that transactions in the same country need not exclude that country. This can be done for individual domestic banks if desired.
[0123]
A domestic SPA facility for processing home transactions is more useful than having all transactions performed by a central processing facility.
[0124]
Service provider processing of authorization requests
First, it is determined from the issuer BIN whether the account number is actually a pseudo account number, and if it is a pseudo account number, the transaction is sent to a specific system for processing. This system stores the tables necessary to convert pseudo account numbers into corresponding “real” account numbers. The system also stores a record of the “predicted transaction sequence number” of the maximum number of 20 bits received for the SPA version number and the pseudo account number, which means that the MAC It is also accompanied by an indication of whether it has been confirmed. 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 transaction sequence number, the system also stores an indication of “base date” and “month indicator” that applies to each of the predicted transaction sequence numbers.
[0125]
The “reference date” is a date value representing the latest expiration date that can be accepted in the permission request message. From the background, some customers do not request permission immediately, but request batch permission. Therefore, this date is typically one or two days before the transaction start date.
[0126]
The “months indicator” represents the number of months beyond the current date corresponding to the last expiration date on which the payment card is allowed. Typically this number is 48 months.
The system also has a safety module that has the function of determining a unique and secret 16-byte encryption key located in the cardholder PC SPA when registration occurs. The processing executed by this system is as follows.
1. Using the stored conversion table, the “actual” account number is determined from the pseudo account number.
2. The security module is used to determine the encryption key specific to this SPA using a pseudo account number (as described above) and a “real” account number.
3. Select the 20-bit “predicted transaction sequence number” first received within the last 48 hours for which the MAC has not yet been confirmed. The related SPA version number as defined for the 20-bit transaction sequence number and the PC SPA is calculated. Using the “reference date” and “months indicator” for the associated “predicted transaction sequence number”, an expiration date is determined from this MAC using the method already defined for the SPA for the PC. If this expiration date is equal to the current expiration date, the MAC is verified. The entry for this “predicted transaction sequence number” that will be the MAC verification is marked as “verified MAC” if it is the highest number of “predicted transaction sequence numbers” for the associated SPA version number, If it is not the highest “predicted transaction sequence number” for the associated SPA version number, it is deleted. Entries for “expected transaction sequence number” marked as “validated MAC” and with any low number associated with the same SPA version number are deleted.
4). When the MAC is verified in step 3 (or step 5), if it is not known that the customer of this transaction will never send a second authorization request message for this same transaction, the "history" for this pseudo account number Form an entry in "data" (some customers send more than one authorization request message for the same transaction if they cannot carry all of the goods within a given time after the transaction There is a risk.) This history data includes the identity of the customer and the acquirer and the “expiration date” for this entry, in addition to all the data already described. This entry expiration date is assumed to be 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” from the oldest to the newest received during the last 48 hours not related to the already verified MAC, Repeat the procedure specified in step 3. For any of these attempts, if the resulting data matches that of the current transaction, the MAC is considered verified. If the 20-digit “predicted transaction sequence number” that is the MAC verification is the highest “predicted transaction sequence number” for the relevant SPA version number, then “verified MAC” If it is marked and not the highest “predicted transaction sequence number” for that associated SPA version number, it is deleted. If the MAC is verified in this step, step 4 is also executed.
6). If the MAC does not verify in step 3 or step 5, “history data” for the number of pseudo accounts is accessed. If an entry exists in this data for the same customer and acquirer that generates the same expiry date MAC, and this entry has not expired, then allow the MAC (this is another authentication request message for an already authenticated transaction Is assumed.) If MAC is allowed for this entry, the entry expiration date should be about 2 months for the future if it is less than 2 months. The reason is that this may be a “repayment” and may be another authentication request message for the same transaction in other months.
7). If the MAC does not verify at step 3, step 5 or step 6, the transaction is rejected. In this case, a “decline” response is sent to the acquirer.
When the MAC is verified, the master card formats an authorization request message for the issuer. The authorization request message has a “correct” account number (not a pseudo account number) and a “correct” expiration date (not MAC). However, the master card SPA authorization system needs to keep a record of the account number area and the expiration date area as received from the income earner when predicting receipt of an authorization response from the issuer.
[0127]
In the authorization response message sent to the issuer, if the authorization response is sent through a payment network based on the acquirer BIN, the master card serves as the “pseudo” acquirer BIN for the acquirer BIN of the transaction message. Is replaced with one of the specific BINs of the master card. The acquirer BIN is replaced so that the issuer responds to the master card on behalf of the acquirer. This step need not be performed if the payment network maintains a record that the place where the authorization request message comes from and the place where the authorization response message is returned.
[0128]
If a pseudo-acquirer BIN is used to accurately calculate an exchange fee for the acquirer and issuer, the pseudo-acquirer BIN is the same as the country where the acquirer is located or, consequently, the same exchange fee It is necessary to correspond to other countries or territories that grant If each country has a specific BIN associated with it, the master card replaces the acquirer BIN with a specific BIN associated with the acquirer's country. If the acquirer's country does not have a specific BIN associated with it, a specific BIN associated with another country can be selected for the same exchange fee.
[0129]
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 for the issuer, the master card will use the master card to find the original acquirer reference data, the pseudo acquirer BIN, the appropriate transaction type indicator, and the original acquirer criteria data. Is replaced with “pseudo” acquirer reference data having an index value to use.
[0130]
If a national SPA facility processes a pseudo account number transaction, the facility operates as follows. However, this domestic SPA facility only handles transactions for domestic issuers and therefore only requires encryption keys and account number translation table entries that apply to that country.
[0131]
In SPA authorization systems, it is more effective to calculate and store the expiration date of the MAC display when receiving a new “predicted transaction sequence number” than waiting to receive an actual authorization request. is there. In this case, when an authorization request is received, the expiration date in the authorization request message is compared with the expiration date pre-calculated and stored within the past 48 hours that do not yet match the expiration date in any previous authorization request message. There is a need to.
[0132]
Authorization request issuer handling
FIG. 5 illustrates the issuer 36, master card (service provider) 10, acquirer 34, and customer 38 according to one embodiment of the present invention after the issuer has received, for example, a master card or an authorized national SPA facility. Shows communication between.
[0133]
The issuer authorizes the transaction like any other transaction. The authorization response is returned to the “pseudo” acquirer, ie, the same master card SPA authorization system that converted the pseudo account number to a “correct” account number and verified the expiration date of the MAC display.
[0134]
As already explained, the system maintains a (temporary) record of the transaction, i.e. the account number field and the expiration date field can be returned to the values received from the acquirer. An authorization response with these areas replaced with values received from the acquirer is sent to the acquirer and sent from the acquirer to the customer, as in the case of a normal master card transaction.
[0135]
If the SPA authorization system is actually a national SPA facility, this facility performs the functions shown in the previous description.
[0136]
Clearing and clearing (Settlement)
The acquirer settles the transaction in the usual way. The acquirer goes to the master card's INET (clearing and clearing) system, which converts the pseudo account number to a “correct” account number (there is no expiration date field in such exchange messages) .)
[0137]
Once the INET has converted the transaction into a “correct” account number, that number is sent to the issuer, cleared and cleared like any other transaction.
[0138]
Exception handling
If there is a future chargeback, copy request, or any other exception handling related to this transaction initiated by the issuer, it must be sent to the INET (or SPA exception handling system) In this case, the conversion is performed from a “correct” account number to a pseudo account number. Since this facility does not need to keep a record of individual transactions, this transformation can be based on a table. Depending on the data being traded, it is sent from the issuer to the appropriate master card facility.
[0139]
Similarly, any response from the customer and the acquirer to the issuer is sent to the appropriate master card facility, in which case the “correct” account number is associated with the response.
[0140]
Other examples 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 already described. In addition, 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.
[0141]
In this example, the SPA is not required to communicate with the master card website or server during the transaction. The SPA facility maintains a transaction sequence number counter for each registered SPA. When the SPA facility receives an authorization request, it generates a MAC based on the upper digits of the transaction sequence number count that it maintains along with the lower digits of the pseudo account number's transaction sequence number. The SPA facility then converts this MAC to 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 repeat of the number from the previous transaction.
[0142]
Modes 2 and 3: Authentication using other areas
The SPA wallet should not be valid until the customer payment screen is displayed on the PC (if the cardholder follows the proper orientation). Therefore, when SPA prepares to process a transaction, it will examine the currently displayed screen and attempt to understand what is visible. First, the SPA looks for a “hidden” area that is the SPA MAC area.
[0143]
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 be different from each other. If the SPA finds two hidden regions, one with a Mode-2 identifier and the other with a Mode-3 identifier, the SPA always chooses a Mode-2 region and considers this a Mode-2 transaction.
[0144]
If the SPA can find this “hidden” area, this is a “Mode-2” or “Mode-3” transaction. For such transactions, SPA can also find a “card number” field, an “expiration date” field, and a field that specifies the name, address and phone number of the cardholder. The reason is that for customers following SPA, all of these areas are identified by a standardized method. In this case, the SPA occupies the entire payment screen.
[0145]
In the event of Mode-2 or Mode-3 transaction, SPA performs the following processing.
1. Occupies a customer payment screen entry for the cardholder name, cardholder address and cardholder phone number.
2. Occupies the "account number" area of the customer payment screen with a fake account number.
3. Occupies the "expiration date" area of the customer payment screen with the expiration date stored in the SPA for this card (cardholders have been mutually updated).
4). Increment (and store permanently) the Mode-2 transaction sequence number.
5). Form the MAC.
6). A MAC area (having the MAC generated as described above) as defined below is formed.
7). Place the MAC area in the “hidden” area of the customer payment screen.
8). Information is provided to the cardholder that the customer's payment screen is occupied and can be transmitted.
9. As a result, control is returned to the browser on the PC.
The cardholder is expected to use a normal browser function that transmits the screen occupied by the SPA so as to occupy the appropriate area with each other.
[0146]
The Mode-2 / 3 MAC area preferably consists of the following data elements:
1. (8-bit) pseudo BIN key indicator
2. SPA mode indicator (1 bit: 0 = Mode-2, 1 = Mode-3)
3. SPA version number (15 bits). This area represents the SPA type (credit, debit, prepay) and the version number for this type. For credit card SPA, revision 0 and SPA version, the numbers are all zero.
4). Single session SPA indicator (1 bit: 0 = normal SPA, 1 = single session SPA).
5). SPA copy count (10 bits) and single session count
6). Mode-2 / 3 transaction sequence number incremented immediately before (20 bits)
7). Expiration date of the card (4 digit binary coded decimal or 16 bits)
8). A binary 32-bit MAC of data elements # 2- # 7 generated sequentially using a key for each card
[0147]
Mode-2 and Mode-3 use the same set of transaction sequence numbers. Thus, there is never a Mode-2 transaction with the same transaction sequence number as a Mode-3 transaction from the same cardholder SPA on the same PC for the same pseudo account number.
[0148]
When SPA is re-enabled (uninterrupted), it displays a list of all SPA cards and asks the cardholder to select one of them. However, if the SPA is interrupted but cannot be closed, and if the cardholder selects the card used immediately before, the SPA will indicate to the cardholder whether the address, phone number or card expiration date has changed ( Again) Don't ask. Also, SPA does not require you to re-enter your password. Instead, the SPA keeps a clear text post-card key (encrypted by using a password as the key in another situation). This clear text key is erased when the SPA is closed or another card is selected.
[0149]
Specific handling of Mode 2 requests
In this mode, (for example) a 13-digit decimal individual MAC field is included in the transaction as a SPA-specific field. These 13 digits are as follows:
1. “SPA” indicator: 1 digit. This region typically has a value of 1. However, if the cardholder has more than one copy of the SPA for the same “correct” account number (eg on a desktop or laptop computer), other versions of the SPA will have each other in the SPA indicator field. (SPA transaction sequence number is unique for each such version of SPA.)
2. SPA transaction sequence number for this version of SPA: 6 digits. This field increments for this special computer-initiated SPA transaction (each computer will have its own version of SPA and therefore will have 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.
[0150]
The proposed MAC-generation process is as follows.
1. Displays the SPA digit number 7 digits (to 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 using legitimate zero bits.
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). The resulting 64 bits of step 4 are considered as 4-bit hexadecimal numbers. Scan the hexadecimal number (from left to right) and select the first 6 digits that have a value less than 9 in hexadecimal. If no such 6 digits are found, the remaining digits are found by rescanning the digits and selecting only those digits greater than 9 in hexadecimal and subtracting hexadecimal A from each of them.
6). The result of step 5 is used as a 6-digit binary MAC for this transaction.
The MAC is generated by the SPA of the cardholder PC and verified by the appropriate master card SPA facility. When generated, 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 the 6 resulting from step 6 for the rightmost 6 digits of the received MAC field. Compare with digits. An exact match represents an authenticated transaction. Inconsistency represents a transaction that needs to be rejected.
[0151]
Communication between card holder 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 MAC and data based on it are part of the transaction in the MAC area. To place.
[0152]
In response to receiving the cardholder transaction message, the customer formats a normal authentication request for the acquirer. This authentication request has a MAC area as provided by the consumer's PC.
[0153]
When a customer initiates multiple authentication / clearing transactions for a cardholder transaction, only the first of these transactions has a MAC domain and expiration date. The next transaction has only a pseudo account number and is considered a mail order and telephone order transaction generated by the customer. This also applies to all payments that occur again and partial payments with multiple clearing.
[0154]
Service provider handling of authentication requests
When the service provider receives the transaction, the service provider determines from the issuer BIN whether the account number is a pseudo account number, and if so, the service provider identifies the transaction for processing by a specific SPA authentication system. Send to. This system can be a domestic SPA facility as already described. The system automatically notes that it is a Mode-2 transaction because of 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 substantially the same procedure used on the PC to form the MAC (as described above). B) determine the key for each card and use this key to verify the MAC. The system also checks the transaction sequence number and therefore maintains transaction sequence number information for each version number of the pseudo account number that the system processes.
[0155]
1. The transaction sequence number is less than (or equal to) the maximum transaction sequence number for this version of this SPA received at least 48 hours ago, or
2. If the transaction sequence number matches any transaction sequence number already received for this version of this SPA (this is constrained to transaction sequence numbers received within the last 48 hours).
The system rejects the transaction.
[0156]
If the MAC or transaction sequence number fails to validate, the facility will cause the transaction to be refused. If both the MAC and the transaction sequence number validate, this facility sends a transaction with a “correct” account number (and a “correct” expiration date inserted into the transaction by the cardholder PC) to the issuer. .
[0157]
Certificate request issuer handling
The issuer authenticates the transaction like any other transaction. The authentication response converts 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.
[0158]
The system restores the “correct” account number to a pseudo account number and restores the data that was in the original transaction (in Mode 2, the expiration data held in the transaction from the start is “correct” expiration) Data, so there is no need to restore this area.) The resulting message is sent to the “right” 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 is the case for any other transaction.
[0159]
When a transaction is sent to a domestic SPA facility, this facility performs the functions described above.
[0160]
Clearing and clearing
The SPA clearing message is sent to the master card INET (clearing and clearing) like all clearing messages. Since the SPA transaction has a recognizable BIN, the INET replaces the pseudo account number with a “correct” account number. If there is next any exception handling for this transaction, other changes are made to the message so that the exception handling message is sent to an SPA facility that can convert the "correct" account number to a pseudo account number. . Clearing messages with such changes are sent to the card issuer who processes the transaction in the usual way. If the acquirer also becomes the issuer, the master card returns the cleared transaction to the acquirer / issuer who performs the displayed changes and appropriate fee calculations.
[0161]
Exception handling
If a message about a transaction needs to be returned from the issuer to the acquirer or customer, the message is processed by the issuer as if any transaction message was processed. The data in the transaction record sends a message to the master card facility, which returns the “correct” account number to a pseudo account number. The exception handling message is then sent to the acquirer who processes it like any other such message.
[0162]
Also, any documentation on transactions that are sent between the acquirer and issuer has been changed by MCI, the acquirer receives a pseudo account number and the issuer receives a “correct” account number. To do. If such data is electronic and identifiable, the data is changed internally. If such documentation is not entirely electronic, other forms reflecting the correct account number and the pseudo account number can be formed. An issuer who sends such documentation directly to the acquirer can be requested to provide both numbers.
[0163]
Issuing plastic cards for identification
In some situations, a cardholder purchases a ticket over the Internet and, in the event of an event that allows the ticket to enter, generates a card that will be used for the transaction and authenticates the legitimate processing of the ticket. Request.
[0164]
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”.
[0165]
The customer who needs to legitimately authenticate the cardholder with a pseudo account number then registers with the master card (by providing appropriate identification and authentication information to the master card) and the customer A key is provided and authentication is performed as an encryption proof of registration. Then, such customers will provide a copy of pseudo account number transaction details under cryptographic authentication that authenticates both transaction data and customer rights to obtain a “correct” account number , You can get the "correct" account number from the master card facility. The master card sends an encrypted form of the “correct” account number to the customer so that the cardholder is identified with the card corresponding to the “correct” account number.
[0166]
SPA wallet operation: Mode-0 transaction processing
Mode-0 is used only with the wallet for the pseudo account number in “state C”. It is used under the situation where Mode-1 is used 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 PC SPA 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 bank of the customer payment screen as described for Mode-1.
The present invention is not limited to the above-described embodiment, and many changes and modifications can be made.
[Brief description of the drawings]
FIG. 1 is a block diagram of several 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 charge in one embodiment of the present invention.
FIG. 3 is a flow diagram depicting a process performed to obtain an expiration date field value in accordance with one embodiment of the present invention.
FIG. 4 is a flow diagram depicting the flow of communication between a merchant, acquirer, service provider, and issuer, according to one embodiment of the present invention.
FIG. 5 is a flow diagram depicting the flow of information among issuers, service providers, acquirers and merchants according to one embodiment of the invention.
FIG. 6 is an illustration of an alternative method of sending a message in accordance with one embodiment of the present invention.

Claims (14)

A method of conducting an electronic transaction on a public communication network using an account number,
The cardholder computer device accepting an input of an account number from the cardholder;
A service provider server generates a Per-Card Key in association with the account number;
The device storing the Per-Card Key ;
In performing electronic transactions, the device generates a message authentication code using the stored Per-Card Key ;
The device converts the message authentication code to a pseudo expiration date using a reference date and a number of months indicator;
The device generates an authentication request for the transaction, the request having an expiration date field for storing the pseudo expiration date;
Said server comprising: verifying said message authentication code based on said pseudo expiration date , SPA version number or transaction sequence number .   A second authentication wherein the device conducts the electronic transaction on a public network and a payment network having an issuer of the account number, wherein the account number has a correct expiration date and the correct expiration date; The method of claim 1, further comprising: generating a request; and the device submits the issuer's second request for approval of the transaction. A method of conducting electronic transactions over a public network using a payment account number having an associated pseudo account number,
(A) the cardholder computer device accepting input of a payment account number from the cardholder;
(B) a service provider server generates a pseudo account number and a Per-Card Key in association with the payment account number;
(C) the device stores the pseudo account number and the Per-Card Key ;
(D) in conducting an electronic transaction, the device generates a message authentication code (“MAC”) using the stored Per-Card Key ;
And step (e) said apparatus, to the secure payment application, to generate an M AC verification request that having a said pseudo account number and the MAC,
(F) the server verifies the MAC using the pseudo account number ;
(G) the server forms a predicted transaction sequence number (ETSN) for the MAC based on the validation;
(H) the device provides reference data to the secure payment application;
(I) the device forms a second message authentication code using the predicted transaction sequence number and the Per-Card Key ;
(J) the device converts the second message authentication code using the reference data into a pseudo expiration date;
(K) the device generates an authentication request having an expiration date field having the pseudo expiration date;
(L) the server responding to the authentication request and verifying the second message authentication code based on the pseudo expiration date. 4. The method of claim 3, wherein the Per-Card Key is generated using a key for each BIN.   The MAC verification request further includes an expiration date, version number and transaction sequence number values of the payment account number, and the step of verifying the MAC includes the expiration date, the version number and the transaction sequence number values. 4. A method according to claim 3, characterized in that it is based.   6. The method of claim 5, wherein the step of forming the second message authentication code uses the version number.   4. The method of claim 3, wherein the reference data includes a base date and a number of months indicator. Verifying the second message authentication code comprises:
Determining the payment account number using the pseudo account number and a stored conversion table;
A step of the payment account number and using said pseudo account number, to determine the Per-Card Key Canada associated with said pseudo account number,
Selecting a second predicted transaction sequence number for which the associated message authentication code was not verified;
And converting using a second reference data specified with respect to the second predicted transaction sequence number, the second message authentication code to the second pseudo-expiration date,
Comparing the second pseudo expiration date and the pseudo expiration date;
4. The method of claim 3, comprising: verifying the second message authentication code based on the comparison.   9. The method of claim 8, wherein if the second pseudo expiration date matches the pseudo expiration date, the second message authentication code is verified. A method of conducting electronic transactions over a public network using a payment account number having an associated pseudo account number,
(A) providing a control area in the pseudo account number that represents one of a plurality of authentication key generation processes used by a service provider server to generate an authentication key;
(B) the cardholder computer device uses the one of the processes for generating the plurality of authentication keys represented in the control area of the pseudo account number to generate the pseudo account number; Generating an associated authentication key;
(C) the device generates a message authentication code specific to the transaction using the authentication key;
(D) the device generates an authentication request message having the message authentication code and the pseudo account number;
(E) the server comprising using the represented authentication key generation process and the authentication key represented to the pseudo account number to verify a message authentication code. . 11. The method of claim 10, wherein the authentication key is generated using an authentication key guide key on the pseudo account number.   12. The method of claim 11, wherein the authentication key is also generated using a key for each BIN. A method for performing electronic transactions on a communication network using an account number,
A service provider server generates a Per-Card Key associated with the account number;
A cardholder computer device generates a message authentication code using the Per-Card Key ;
The apparatus provides at least two different operating modes for sending the message authentication codes having authentication requests having different areas in different ways, wherein at least one of the operating modes is an expiration date area; A mode for sending the message authentication code, and at least one of the operation modes is a mode for sending the message authentication code to a message authentication code area.   14. The method of claim 13, wherein if the message authentication code is present, the message authentication code is automatically conveyed in the message authentication code area.

Images