HK1077386B - A method for payment - Google Patents

Description

Payment method

RELATED APPLICATIONS

This application is a continuation of the 09/260384 patent application filed on 2.3.1999, in which the 09/260384 application entitled "Portable electronic accounting and authorization apparatus and method therefor" was a continuation of the 09/067176 application filed on 27.4.1998, in which the 09/067176 application was invented by Ynjiu P.Wang, entitled "Payment systems," and is incorporated herein by reference.

Technical Field

The invention relates to a method and apparatus for conducting electronic transactions. More particularly, the present invention relates to a Portable Electronic Authorization Device (PEAD) that advantageously and substantially eliminates security risks associated with prior art techniques for authenticating transactions between a user and an electronic transaction system.

The invention relates to a method and apparatus for conducting electronic transactions. More particularly, the present invention relates to a Portable Electronic Authorization Device (PEAD) that advantageously and substantially eliminates security risks associated with prior art techniques for authenticating transactions between a user and an electronic transaction system.

Background

Electronic transaction systems are known. An electronic transaction system typically allows a user to electronically conduct a specified transaction, which substantially increases the efficiency and convenience of the user. Examples of electronic transactions include transactions conducted over computer networks, Automated Teller Machines (ATMs), automated point of sale systems, automated library systems, and the like. Transactions conducted over computer networks encompass a wide range of transactions involving the exchange of information and data over a computer network, commonly referred to as the internet, to purchase goods from vendors over the network. ATMs typically enable a user to electronically conduct financial transactions (e.g., withdrawals, transfers, deposits, and the like) with a financial institution. An automatic point-of-sale system may be used by merchants to enable users to purchase products or services using a user's electronic account, while an automatic library system may be used to enable library users to borrow and return library materials. Other examples of electronic trading systems are readily found in the popular literature and are not listed here for brevity.

To enhance the security of a user account, electronic transaction systems typically require that the user provide identification data to prove that he is a user authorized to approve one or more proposed transactions. If the user is unable to provide the required identification data, the proposed transaction or transactions are not authorized and will not be processed. Identification data may be required for each transaction. For example, an automated point of sale system may require a user to approve a purchase transaction and accept the approval message only if the user approving the transaction has provided sufficient identification data to prove himself as the user authorized to perform the approval. The identification data may also be entered by the user at the start of a session to authenticate himself and enable the user to subsequently perform any number of transactions without further authentication.

In the prior art, a user is typically required to manually enter identification data into an electronic transaction system for authentication. Typically, the input of identification data involves entering a password on a numeric keypad or keyboard. The identification data is then compared with data previously stored in the electronic transaction system and when the two match, the authentication is satisfied. As previously mentioned, if there is no match then the proposed transaction or transactions are not allowed to proceed.

While prior art electronic transaction systems provide some protection against unauthorized access and use of user accounts, there are some drawbacks. To illustrate certain disadvantages associated with prior art electronic trading systems, reference is made herein to FIG. 1. Fig. 1 shows an Automated Teller Machine (ATM)100, which represents a requesting device of an electronic transaction system 102. The electronic trading system 102 may include, for example, a central database 104 that contains previously stored identification data and account data for the user 106.

To initiate a typical transaction with the ATM100, the user 106 first inserts a data card 107, such as a bank card or a credit card, into a card reader 109. The data card 107 typically includes a magnetic stripe that contains an account number and other information relating to the user, which information can then be read by a card reader 109. The data stored in the data card 107 enables the electronic transaction system 102 to determine which account in the database 104 the user 106 wishes to conduct a transaction.

The user 106 may then authenticate himself by entering his identification data, e.g., his Personal Identification Number (PIN), through a keypad 108 on the ATM 100. If the entered identification data matches the identification data of the account stored in the database 104 identified by the data card 107, the user is authenticated and allowed access to his account. If not, authentication fails. After authentication, the user 106 can use the combination of the keypad 108 and a screen 110 to withdraw cash from his account, which causes the cash to be withdrawn from the ATM100 and the balance of his account in the database 104 to be reduced accordingly.

Theoretically, the identification data entered into the ATM100 should be secure. Indeed, in prior art authentication techniques, there are many potential security risks to the identification data. Since the identification data is not encrypted prior to input to the ATM100, the unencrypted identification data is readily accessed and obtained without authorization. In the prior art, encryption of identification data is impractical because it is too complicated and/or inconvenient for a user to perform encryption or to remember encrypted identification data. In the prior art, unauthorized acquisition of identification data may occur when the input is inadvertently seen by another party, for example, behind user 106 on screen 110 or more likely on keyboard 108.

Even though in the prior art the identification data is encrypted before being sent from the ATM100 to the database 104, encryption typically occurs within the ATM100, and the user 106 is still required to enter the unencrypted identification data, the identification data will still be present in the ATM100 for some time. Such that unauthorized access to the identification data may occur if an unauthorized party is able to enter the ATM100 and intercept the unencrypted identification data therein via software or hardware implemented in the ATM 100.

Additionally, if a public key is employed within the ATM100, storing the user private key within the ATM100 makes this private key susceptible to theft, further exposing the user account to danger. The stolen password and/or private key may then be used to enable unauthorized users to access the user's account, creating a hazard to the user.

In view of the foregoing, it would be desirable to have an apparatus and method for conducting transactions with an electronic transaction system that substantially eliminates the risk of unauthorized access to user accounts and unauthorized access to user identification data. Such a device should preferably be portable so that the user can perform transactions conveniently and comfortably anywhere.

Disclosure of Invention

A method is disclosed for enabling a user to conduct a billed transaction using a billing terminal of an electronic transaction system, wherein the debit card terminal is configured to interact with a debit card to conduct debit card transactions, providing a merchant card to a merchant (merchant) conducting debit card transactions, comprising accepting the merchant card and a personal identification number or mobile phone number from a user conducting debit card transactions at the debit card terminal of the merchant conducting debit card transactions, detecting merchant card usage in a central processing area, in response to said detecting step, placing a call to the mobile telephone of an authorized person for the debit card transaction using the telephone number or personal identification number, sending a report of the user's debit card transaction to the mobile telephone, and only if approved by the authorizer will an approved authorization for the debit card transaction be returned to the merchant's debit card terminal.

The merchant may also enter an amount to be billed and an identification of the type of transaction to be conducted.

A valid credit card number may be assigned to the merchant card and the step of calling the authorizer's mobile phone may be initiated by detecting the merchant's valid credit card number.

The method may further comprise the steps of: all credit card transactions from the merchant's debit card terminal are filtered by a central processing server and in response to the filtering step, the server does nothing if the card number received from the merchant is not a unique merchant assigned number or looks up information in the payment server's database using the telephone number or personal identification number as an index if the card number is a unique merchant assigned number.

The method may further comprise the payment server using the telephone number or pin number associated with the transaction as an index to a database storing mobile telephone numbers of individuals required to authorise the transaction.

In the method, the database may also store a record of whether the authorized person's mobile telephone number has an embedded PEAD. If it is determined that the authorizer's mobile phone has a PEAD, the server sends a transaction message to the authorizer's phone for approval with a PEAD embedded in the phone, and the authorizer approves the transaction by entering a personal identification number on the mobile phone.

If the database lookup indicates that the authorizer's mobile phone is a touch-tone phone, the server will send a message to the authorizer's mobile phone requesting an approved dial tone.

The database server may utilize an interactive voice response system to transmit transaction information to the authorized person's mobile phone.

After the authorizer authorizes/approves the transaction, a clearing of the authorizer's account may be performed using an account selected from the group consisting of a credit card, an ATM, a bank account, or a debit card.

Drawings

To facilitate discussion, FIG. 1 shows a prior art electronic transaction system including an Automated Teller Machine (ATM).

Fig. 2 depicts a Portable Electronic Authorization Device (PEAD) representing a device for securely approving a transaction with an electronic transaction system according to an embodiment of the invention.

FIG. 3A shows a simplified schematic diagram of the PEAD of FIG. 2 in accordance with an embodiment of the present invention.

FIG. 3B illustrates a format of representative transaction approval data, in one embodiment.

FIG. 4 depicts a logical block diagram of a PEAD in accordance with an embodiment of the present invention.

FIG. 5A illustrates a high level hardware implementation of a PEAD in accordance with an embodiment of the present invention.

FIG. 5B illustrates one embodiment of a PEAD in which the PEAD circuitry is implemented in an IC.

Fig. 5C shows an external view of the PEAD of fig. 5B as embedded in a card-like package.

Fig. 6A depicts an external view of a PEAD in accordance with a preferred embodiment of the present invention.

FIG. 6B depicts in a simplified manner hardware implementing the PEAD of FIG. 6A in accordance with an aspect of the present invention.

FIG. 7 is a flow chart describing an approval technique for employing the inventive PEAD in accordance with an aspect of the present invention.

Fig. 8 is a flow chart depicting the steps involved in having a public key encryption technique encrypt transaction approval data in accordance with an aspect of the present invention.

Fig. 9 depicts a simplified block diagram of a portable electronic billing and authorization device (PECAD), according to an aspect of the present invention.

Fig. 10 is a simplified view of a PECAD with an emulation card installed in accordance with an embodiment of the present invention.

Fig. 11 is a simplified flow diagram illustrating how a transaction number may be used in conjunction with a PECAD system to improve transaction security, according to one embodiment.

FIG. 12 is a schematic diagram of the method and apparatus of the present invention.

Detailed Description

The invention further relates to a payment system (EPS) for making payments with a telephone number and for approving the payments using a PEAD or a mobile phone. For integration into existing point-of-sale systems, a valid credit card number is predetermined as an eSignX merchant card number (EMC number). For a user who registers his/her telephone number (preferably his/her mobile telephone number) in the eSignX payment system, payment at the point of sale may be made by providing his/her telephone number to a merchant. The merchant can read the ESignX Merchant Card (EMC) and then enter a customer mobile phone number, the amount to be billed, and other optional information. Since the EMC number is a valid credit card number, the phone number and billing information will go through existing payment resolution facilities, such as Visa or MasterCard, and will be processed by existing data processors, such as the First Data Company (FDC). The present invention requires only one eSignX payment server to be installed in the existing facility in order to obtain a unique EMC number by filtering all debit card numbers that pass through the system. If the card number is not a unique EMC number, no action is taken. If the card number is a unique EMC number, a database in the eSignX payment server is looked up using the phone number as an index. If the lookup indicates that the user's mobile phone has a PEAD embedded therein, such as a WAP phone with a WIM card or SWIM card, or a Java phone with an xDSL software PEAD module, the eSignX payment server will send a transaction message to the user's phone for approval with a PEAD embedded in the phone. If the search result indicates that the user's mobile phone is a touch-tone phone, the eSignX payment server will call the user's mobile phone through an IVR (voice interactive response) system for approval with a dial tone.

An exemplary transaction may be understood by referring to the block diagram of fig. 12, which depicts the basic physical elements of the present embodiment, and the data flow used by the present method and apparatus. In a first step, when a transaction is to be authorized at a merchant, in order for a user of the system to pay at the point-of-sale, the user need only register his telephone number (preferably his or her mobile telephone number) in the eSignX payment system prior to the transaction, and then pay at the point-of-sale by providing the telephone number to the merchant. Of course, it is equally possible to register a personal identification number and provide the personal identification number to the merchant.

In either case, upon receiving the pin number of the mobile phone number, the merchant reads a merchant card issued by eSignX in a standard card reader 1204, where the standard card reader 1204 is of a type that is currently used to read credit cards. After reading the merchant card, the merchant enters the customer's mobile phone number (or personal identification number), the amount to be billed, and other optional information.

Since the EMC number read by the card reader 1204 is a valid credit card number, the telephone number and billing information can pass through existing payment resolution facilities, such as those used by Visa or MasterCard, and be processed by an existing data processor, such as the first data company, which maintains a large-scale data processing center 1210 to which the entered data is directed.

In addition to the data processing already done at this center, the method only requires the installation of a payment server at 1210 or another location for capturing the data entered with the EMC merchant card 1202. This may be accomplished by using a server 1220 that may be incorporated into the host data processing center 1210 before or after data processing, typically at a credit card data processing center. The function of the payment server 1220 in existing facilities is to obtain a unique business identification (EMC) number from the merchant card 1202, preferably by filtering all debit card numbers that pass through the system. If the card number is not a unique EMC number from the EMC card 1202, the merchant card payment server 1220 does nothing.

If the card number is a unique business (EMC) number, the data is immediately transferred to the EMC payment server 1220 to index with the phone number or personal identification number to look up in the database all available information about the person (who may or may not be the issuer) who must authorize the transaction.

The approval can then be from the mobile phone number or the mobile phone 1230 to which the pin number points, simultaneously with the transaction in progress; this may or may not be a mobile telephone held by the person requesting the transaction.

If the lookup at the payment server 1220 indicates that a PEAD is embedded in the user's mobile phone, such as a WAP phone or WIM card, SWIM card, or Java phone with xDSM software PEAD module, the payment server 1220 sends a transaction message to the authorizer's phone 1230 for approval with a PEAD embedded in the phone. After the bearer of the mobile phone with the PEAD receives the message, they may enter an approval code, or ignore the message, or enter a non-approval code.

In an alternative embodiment, if the lookup result indicates that the user's mobile phone is a touch-tone phone, the payment server 1220 sends a message or calls the user's mobile phone through an interactive voice response system to request an approved dialed personal identification number.

In either case, the holder of the mobile phone 1230 associated with the mobile phone number or pin remains in control of the approval of the transaction, whether or not they are present at the transaction location.

Fig. 2 depicts a Portable Electronic Authorization Device (PEAD)200, which represents a device for securely approving transactions conducted with an electronic transaction system, in accordance with an embodiment of the present invention. Referring to fig. 2, requesting device 202 may begin a transaction approval process with PEAD200 by sending a transaction request related to the proposed transaction to PEAD200 via port 204. The requesting device 202 may represent, for example, an ATM, a computer terminal in a network, an automated library lending terminal, or similar device for enabling a user to transact with an electronic transaction system. The proposed transaction may be, for example, a sale of a particular item in exchange for an amount of money. The transaction request itself may include, for example, a transaction identifier, a name of the merchant, an identification of the merchant, a time at which the purchase was made, and the like. In one embodiment, the transaction request from the requesting device 202 may be encrypted to enhance security, but this is not required. Data relating to the proposed transaction reaches the PEAD200 via path 206 in FIG. 2.

Port 204 may represent an infrared port to facilitate infrared communication with PEAD 200. Port 204 may also represent a wireless port for facilitating wireless communications. Port 204 may even represent a contact-type connection port, such as a magnetic read/write mechanism, or a plug having electrical contacts for directly inserting PEAD200 into port 204 to facilitate communication. Other techniques for facilitating communication between the requesting device 202 and the PEAD200 are readily understood by those skilled in the art.

The user may then view data relating to the proposed transaction on a screen 208 of the requesting device 202 or, alternatively, on a display screen (not shown in fig. 2) provided by the PEAD 200. If the user approves the transaction, for example, purchasing an item with an amount of money, the user may indicate his approval by activating a switch 210 on the PEAD200, which causes an approval message to be created with the user's identification data, encrypted, and sent back to the requesting device 202 via path 212. If the transaction is not approved, the user, without any action, either lets the transaction request expire after a period of time or activates another switch (not shown in FIG. 1) on PEAD200, which causes an encrypted or unencrypted denial message to be sent back to requesting device 202 via path 212.

The present invention differs from the prior art of figure 1 in that the user must enter his identification data into the electronic transaction system, for example, into the ATM100, to authenticate himself. In contrast, the present invention makes identification data associated with the user always secure within the PEAD. Transaction approval occurs within PEAD200, and data representing such approval is encrypted within PEAD200 before being sent to an electronic transaction system (e.g., requesting device 202 in FIG. 2).

Thus, even if the approval data is intercepted, its encryption will prevent unauthorized users from using the identification data for illicit purposes. If public key encryption is used to encrypt the approval data, the user private key is also always maintained within PEAD 200. Since the user private key is necessary for encryption and is unknown to others (even the electronic transaction system in one embodiment), the encrypted approval data, if intercepted, is not useful to unauthorized third parties, even though the user public key may be used to decrypt the approval data. Furthermore, this is in contrast to prior art authorization techniques where encryption occurs in electronic transaction systems and requires the entry of identification data and/or the reading of a user private key from an identification card, such as an ATM card, a credit card, or the like. As previously mentioned, the fact that prior art electronic transaction systems require this identification data and/or user private keys exposes these data to danger, for example, if the requesting device is not secure or may be intercepted by software or hardware.

Another difference is that the present invention employs circuitry within the Portable Electronic Authorization Device (PEAD) to perform authorization and encryption of transaction authorization data within the PEAD itself. In contrast, prior art data cards are essentially passive devices. For example, prior art ATM cards or credit cards have only one magnetic stripe for storing account information and do not have any means for performing approval and/or encryption of transaction approval data. While the smart cards of IC cards now being developed may include electronic circuits, the current implementation standard still requires a reader associated with the requesting device to read the identification data and/or the user's private key in order for the requesting device to perform any approval and/or encryption. As previously mentioned, sending these data to the requesting device unnecessarily exposes the data, once sent, to the risk of theft and/or unauthorized interception.

It should be kept in mind here that while the present invention is always discussing public key cryptography to facilitate understanding and emphasize one particular aspect of the present invention, the overall invention is not limited to any particular cryptographic algorithm and may be implemented using any conventional cryptographic technique, including public key cryptography such as RSA, Diffie-Hellman, other discrete logarithm systems, elliptic curve systems, and the like. For further information on some different public key encryption techniques, reference may be made to the "ieee p1363/D8 standard specification for public key encryption" on, for example, 10/5 of 1998, which can be taken from the following addresses: 345 th street, new york city, new york, 10017-.

As already mentioned, transaction approval in the prior art occurs within electronic transaction systems. Rather, the present invention enables transaction approval to occur within the PEAD 200. The fact that transaction approval occurs entirely within the PEAD200 provides a number of advantages. For example, this functionality eliminates the need to have identification data and/or a user private key in the requesting device in one embodiment. The fact that transaction approval occurs entirely within PEAD200 (using user identification data and/or the user's private encryption key that remains secure throughout PEAD200) substantially enhances the confidentiality of the user's identification data and the user's private key, as well as the integrity of the transaction approval process.

Since the transaction occurs entirely within PEAD200, the user identification data used to authenticate the transaction may be more complex and detailed to ensure greater security. For example, the user identification data may be more detailed than a simple password, and may include any of the following items: a user name, its date of birth, its social security number or other unique biometric or unique identification data, such as a fingerprint, a DNA code chain, a voiceprint, etc. In contrast, existing authentication techniques limit user identification data to simple forms that are easy to remember for the user, such as a simple password of a few characters, because more detailed identification data may be too difficult to remember or too lengthy to manually enter. Furthermore, even if complex identification data can be stored in prior art data cards, it still needs to be read into the requesting device of the electronic transaction system, once this data is read, it is again exposed to the danger of interception or theft.

Other security measures, discussed in detail herein, will also be provided to prevent access (whether electronically or by physical means) to the user identification data and/or user private key within the PEAD 200. Since the identification data and/or the user private key are never exposed, the security risk of these data is substantially minimized.

Fig. 3A shows a simplified schematic diagram of the PEAD200 of fig. 2, including the switch 210, in an embodiment of the invention. Data path 206 is provided to receive transaction requests from the electronic transaction system, while data path 212 is provided to send transaction approval data back to the electronic transaction system. It should be kept in mind that while the two data paths and the other data paths herein may represent logical data paths in one embodiment, they may be implemented via a single physical data connection. Also, the various ports herein may represent logical data ports in one embodiment to facilitate understanding that a single physical port may actually be used for implementation.

When a transaction request, such as a $ 200.00 transaction from an ATM, is sent to PEAD200 via data path 206, the transaction is received by encryption logic 300. Here, the user may view the proposed transaction through a display screen hosted by the electronic transaction system and/or PEAD200, and may choose to approve or disapprove the proposed transaction. If the user approves the transaction, he may, in one embodiment, activate a switch 210, which causes transaction approval data to be generated and encrypted by the encryption logic 300 before being sent back to the electronic transaction system via path 212.

Note that the user identification data block 302 employed in the transaction approval process is not directly connected to the paths 206 and 212. In other words, the portion of memory storing the user identification data is intentionally disconnected from the input and output ports of PEAD200 to prevent direct access thereto.

If access to the user identification data 302 is required, for example, to approve a transaction, access can only be accomplished by the encryption logic block 300. Also, it is not possible to directly access the memory portion 304 storing the user private key. If access to the user private key 304 is required, for example, to encrypt the transaction approval data, access can only be accomplished by the encryption logic block 300. It should be kept in mind that while user identification 302 and user private key 304 are shown as being stored in different memory portions, this depiction is made for ease of understanding, in one embodiment, both may actually be stored at different addresses on the same memory module.

In some cases, the transaction approval data needs to include a particular piece of identification data 302. For example, a transaction in a transaction request from an electronic transaction system may be appended with data representing an "electronic signature" before being encrypted and retransmitted back to the electronic transaction system. FIG. 3B shows a format of representative transaction approval data 350 in one embodiment. Referring to fig. 3B, transaction data 352 representing a portion or the entire transaction request received from the electronic transaction system is appended with specific user identification data 354 and, optionally, a timestamp 356. The generation of transaction approval data 350 only occurs after the transaction request has been approved by the user. Once appended, the transaction approval data 350 is encrypted before being re-sent back to the electronic transaction system.

In some cases, it may be desirable to encrypt the transaction request before sending it to the PEAD to further enhance security. For example, a particular transaction partner, such as a vendor or other user on a computer network, may wish to keep information within a transaction request secret and may wish to encrypt the transaction request before it is provided to the PEAD. Data encryption is also required when, for example, user identification data and a user private key are first written to an empty PEAD to configure a PEAD that is unique to a particular user. The configuration data associated with the user identification data and the user private key, although written to the PEAD200 only once by the user of the PEAD200, is preferably encrypted so that it is not easily stolen. The issuer of the PEAD200 may represent, for example, a credit card user, a government, or any other entity with which the user maintains an account.

FIG. 4 depicts a schematic diagram of the PEAD200 of FIG. 2, according to an embodiment of the present invention. PEAD200 of FIG. 4 further employs decryption logic for receiving encrypted configuration data and, optionally, an encrypted transaction request. In fig. 4, encryption logic 300, user private key 304, and data paths 206 and 212 are placed and function as discussed in connection with fig. 3A.

The transaction requests are typically unencrypted, i.e., they are received and accessed in the manner discussed in connection with FIG. 3A. However, for highly sensitive transactions, the transaction request may be encrypted and sent to PEAD200 via data path 206 and input into decryption logic 402 to be decrypted. If a public key encryption is used, the encrypted transaction request may be decrypted using a transaction partner's public key 404.

Once decrypted, the transaction request is displayed to the user for approval. If approved, for example, in response to activation of switch 210, the transaction approval data may be provided to encryption logic 300 via path 406 to be encrypted. If a public key encryption technique is used, the encryption is preferably performed using the user's private key, and the encrypted transaction approval data is then sent back to the electronic transaction system via data path 212.

Since configuration data typically includes sensitive user identification data and user private keys, it is typically encrypted before it is sent to PEAD200 via data path 408. The encrypted configuration data is received by decryption logic 402 and decrypted therein before being written to user identification data block 410 and user private key block 304. If public key encryption is used, the encrypted configuration data may be encrypted by the user's private key in the electronic transaction system prior to transmission and decryption once received by the PEAD200 with an issuer public key 412.

Note that once the configuration data is decrypted and written to user identification data block 410 and user private key block 304, the user identification data and user private key can only be subsequently accessed by encryption logic 300. It is also noted that there is no direct connection from any I/O data path, e.g., data path 206, 212, or 408, to user identification data block 410 and to user private key block 304. Advantageously, the sensitive user identification data and user private key therein are not readily accessible from the outside once written to the respective blocks 410 and 304 (which may represent only memory blocks in the memory of the PEAD200 in one embodiment).

Furthermore, the user identification data and the user private key cannot be updated by a private key person who does not have an issuer. As shown in fig. 4, data can only be written to user private key block 304 and user identification block 410 after being decrypted by decryption logic 402 having issuer public key 412. Thus, the updated configuration data is not decrypted and written to the respective blocks 304 and 410 unless the configuration data has been encrypted by the issuer's private key (which is assumed to be highly secure). Of course, if the configuration data in blocks 304 and 410 cannot be physically updated, e.g., they are stored with write-once-only memory such as PROM (programmable read Only memory), WORM (write Once read many), etc., security factors associated with unauthorized changes to the configuration data are substantially eliminated.

If a higher level of security is desired, the user private key may optionally be scrambled or randomized by optional scrambler/descrambler logic 412 before being written to user private key block 304. In one embodiment, the scrambler/descrambler logic 413 may receive a user private key provided by the entity that issued the PEAD200 to the user and scramble and/or randomize it to generate another user private key and a corresponding user public key. This scrambled/randomized user private key is then stored in the user's private key block 304, which is now unknown to even the issuer of the PEAD200, while the corresponding user public key may be known to the issuer and/or transaction partner to facilitate the transaction. Advantageously, there are no other copies of the user's private key that have been scrambled/randomized elsewhere than the user private key block 304.

In an alternative embodiment, an optional key generation logic 414 may be employed that independently generates the user private key and the user public key in response to a request from the issuer, i.e., without first receiving a user's private key from the issuer and randomizing it. The generated user private key is then stored in the private key block 304 and the public key is known by the issuer and/or transaction partners to facilitate the transaction. In this way, the user private key, whether randomized or not, is not present outside the PEAD itself. As those skilled in the art will appreciate, the use of key generation logic 414 further enhances the confidentiality of the user private key.

FIG. 5A illustrates a high-level hardware implementation of the PEAD200, according to one embodiment of the present invention. As shown in fig. 5A, PEAD200 includes logic circuitry 502, which may represent a central processing unit, such as a microprocessor or a microcontroller, discrete logic, programmable logic, an Application Specific Integrated Circuit (ASIC), etc., for implementing encryption logic 300 of fig. 2 and optionally decryption logic 402 of fig. 4.

Program/data memory 504 stores, among other things, the code for operating PEAD200, as well as user identification data and a user private key. The program/data memory 504 is preferably implemented using some form of non-volatile memory (NVM), such as flash memory, electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or the like. The scratch pad 506, which is used as a temporary register for computing purposes and for temporary storage of data, may be implemented using some form of Random Access Memory (RAM), such as static RAM or dynamic RAM, as is known in the art. Alternatively, any of optical, magnetic, or other types of memory may be used to implement the program/data memory 504 and/or the scratch pad 506.

A bus 508 couples the program/data memory 504 and registers 506 to the logic 502. Communication port 510 represents a communication gateway between PEAD200 and an electronic transaction system and may be implemented using infrared technology wireless RF technology, a magnetic read/write head, a contact-type plug for facilitating serial or parallel data transfer, or the like. In one embodiment, the communications port may also represent a PC card port (commonly referred to by those skilled in the art as a PCMCIA card). Data path 206 inputs transaction requests into logic 502, while data path 212 outputs transaction approval data from logic 502 to the electronic transaction system. The optional data path 408, which has been illustrated in fig. 4, inputs configuration data into the PEAD200 to write user identification data and the user's private key to the program/data storage 504 to uniquely configure the PEAD200 to a particular user.

It is again noted that access to the program/data memory 504 and the data therein (e.g., user identification data and user private key) can only be accomplished by the logic 502. For example, user identification data and a user private key may only be written to program/data storage 504 if this data has been properly encrypted by the issuer's private key. Access to these memory blocks for writing thereto may also be limited by the logic circuitry 502 under appropriate software and/or hardware control.

Likewise, reading the user identification data and accessing the user private key can only be accomplished through the encryption logic of logic circuitry 502. The advantages of this aspect to security have been discussed in relation to fig. 3A and 4, the most important being that the sensitive user identification data and user private key are preferably not directly accessible from the outside. Thus, the inventive design significantly enhances the confidentiality and security of these data items.

Some type of power source, such as a battery, may also be provided. The PEAD200 is implemented as a single chip design, i.e., almost all of the elements shown in fig. 5A are fabricated on a single chip, then the power supply is external to the chip itself. If contact-type communications are employed, for example, if the PEAD200 must be plugged into an electronic transaction system to conduct a transaction, a power source external to the PEAD may be employed for transaction approval upon plugging, thus eliminating the size, weight, and cost penalties associated with having a battery on a portable transaction device.

In one embodiment, the PEAD200 may be implemented by a general purpose portable computing device, such as any small portable computer or personal data assistant (currently popular PDAs, such as Apple Newton ®, may be used to implement the PEAD 200).

FIG. 5B depicts one embodiment of a PEAD in which the circuitry is implemented on an IC. In fig. 5B, elements having the same reference numerals as in fig. 5A have the same functions. Data paths 408, 406, and 212, which have been described in connection with FIG. 5A, are connected to a serial I/O circuit 520, which serial I/O circuit 520 facilitates the transmission and reception of data in a serial manner over a data path 522 between PEAD200 and the electronic transaction system. Also shown are Vcc pin 524 and ground pin 526 that provide power to the PEAD200 of fig. 5B.

FIG. 5C shows an external view of the PEAD of FIG. 5B, wherein the PEAD has been embedded in a card-like package for ease of carrying and plugging into a serial I/O port of an electronic transaction system. In one embodiment, the card 550, in which the integrated circuit implementing the inventive PEAD is embedded, includes four external contacts. Also shown are Vcc contact 524 and external ground contact 526, which provide power to the PEAD, as discussed in connection with fig. 5A. When the card 550 is inserted into an electronic transaction system, it is powered through the external contacts 524 and 526, thereby enabling the PEAD circuit therein to receive transaction requests through the serial contacts 552 and 554, to approve the requests within the PEAD if appropriate, to encrypt transaction approval data within the PEAD circuit, and to serially communicate the encrypted transaction approval data to the electronic transaction system through the external serial contacts 552 and 554.

Figure 6A shows an external view of a PEAD in accordance with a preferred embodiment of the present invention. The PEAD200 of FIG. 6A is preferably implemented as a small, stand-alone package sufficient for everyday field use. The PEAD200 of FIG. 6A is preferably small enough to be carried by a user at any time, for example, as a key fob or a small package that can be easily loaded into a purse or wallet. The physical packaging of the PEAD200 is preferably designed such that its contents are protected from improper operation (i.e., if it is opened in an unauthorized manner, the user private key and/or user identification data will be compromised, or the PEAD will no longer be able to approve the transaction). For example, the package may be designed such that if it is opened, there is a change in current in the circuit path, e.g., either the existing current is interrupted or a free current path begins to flow. A change in current can then force RE.

An infrared communication port 602 is shown for receiving and transmitting data with an electronic transaction system. A small on/off switch 604 enables the user to turn off the PEAD to save power when not in use. An approval button 606 enables the user to indicate approval of a proposed transaction. An optional skip button 608 allows the user to indicate rejection of a particular transaction. The skip button 608 may be omitted because in certain embodiments, a transaction request may be understood as not being approved if the approve button 606 is not activated for a given period of time after the request is received.

The optional display 610 may be implemented by any type of display technology, such as liquid crystal technology. The display 610 displays, among other things, proposed transactions for approval. Display 610 may be omitted if desired, in which case the transaction may be viewed on a display associated with the electronic transaction system itself. Optional user authentication mechanism 612 enables the PEAD not to be used to approve a transaction unless the user is able to identify himself to PEAD200 as a legitimate and authorized user. Before the PEAD200 can be activated and used to approve a transaction, the optional user authentication mechanism 612 may require the user to enter a password, provide a fingerprint or a voiceprint, or other biometric and/or identification characteristic specific to the authorized user.

FIG. 6B depicts, in a simplified manner, hardware for implementing the PEAD200 of FIG. 6A in accordance with an aspect of the present invention. The battery 652 supplies power to the circuitry of the PEAD 200. A microcontroller 654 executes code stored in flash memory 656, and is implemented using random access memory 658. In one embodiment, microcontroller 654, flash memory 656, and even random access memory 658 may be implemented in a single chip, for example, the NC68HC05SCXX family from Motorola corporation of Schaumburg, Illinois, e.g., NC68HC05SC 28. An approval button 606 and an optional skip button 608 are connected to the microcontroller 654 to enable a user to indicate approval or denial of a particular transaction as displayed by the display circuit 660. Communication with the electronic transaction system is accomplished via an infrared transceiver 662 under the control of microcontroller 654. The power switch 664 enables a user to turn off power to the PEAD200 when not in use to conserve power and prevent accidental approval.

FIG. 7 is a flow chart describing an approval technique for employing the inventive PEAD in accordance with an aspect of the present invention. In step 702, the PEAD receives a transaction request from a requesting device associated with an electronic transaction system. In step 704, the user may choose to approve or disapprove the proposed transaction. If the request is not acknowledged by activating the skip button of the PEAD or simply by making the request expire, no action is taken.

On the other hand, if the user approves the proposed transaction, the user may activate an approval button to generate transaction approval data. The transaction approval data is then encrypted within the PEAD in step 708. In step 710, the encrypted transaction approval data is transmitted to the requesting device of the electronic transaction system after being encrypted.

FIG. 8 is a flow chart describing the steps involved in encrypting transaction approval data using public key encryption in accordance with an aspect of the present invention. In step 802, a transaction approval data package is generated. As previously discussed in connection with fig. 3B, the transaction approval data may be generated by appending any necessary user identification data to a portion or all of the transaction request. Optionally, a timestamp may be attached thereto. In step 804, the transaction approval data is encrypted using the user private key, wherein the user private key is preferably kept secure throughout the PEAD. Thereafter, the encrypted transaction approval data is sent back to the electronic transaction system.

According to one aspect of the invention, it is recognised that even if encrypted transaction authorisation data is intercepted and decrypted by a third party for analysis, it is not possible to bypass the security features of the invention as long as the user private password or user identification data is secure. As previously mentioned, since the user identification data is not externally accessible, it remains secure throughout the PEAD. This is in contrast to the prior art where a user needs to enter identification data, such as a password, at an electronic transaction system risking exposure to this sensitive data.

Even if the user identification data is compromised, transaction approval cannot be made unless the user private key is in possession. Intercepting the encrypted transaction approval data is also useless, even if it can be decrypted using the user's public key, because the transaction partner, e.g. the merchant requesting approval of the transaction, does not accept any transaction approval data that is not encrypted with the user's private key. Furthermore, since the private key is not externally accessible, it remains secure throughout the PEAD. This aspect of the invention is of great advantage in performing online transactions because the user private key no longer needs to be stored in a vulnerable computer file on a workstation, it may be accessible to other parties, and it may be difficult to conveniently retrieve for other authentication tasks.

The fact that the PEAD is now in a small portable package enables the user to conveniently and comfortably hold the PEAD in his or her belongings at any time. An alternative user authentication mechanism, such as user authentication mechanism 612 of fig. 6A, provides an additional level of protection even if the PEAD is physically stolen, and renders the PEAD useless to anyone other than the correct authenticated user. Of course, if the PEAD is stolen or lost, the user may always notify the issuer of the PEAD, which may notify the transaction partner to reject any transaction approval data encrypted using the user's private key of the stolen PEAD.

The fact that the transaction approval data includes a timestamp, a merchant name, an amount of approval, and any other pertinent data also enhances the security of the approval process. If the merchant inadvertently or intentionally submits multiple transaction approvals to the issuer, the issuer can recognize from these data items that the submission was repeated and ignore any duplicate transaction approval data. For example, an issuer may recognize that a user is unlikely to purchase multiple identical dinner meals at the same restaurant at a particular time and date.

The inventors herein have recognized that while the PEAD and PEAD enabled point-of-sale terminals provide a highly secure system for approving transactions, there exists a well established and widely available debit card facility that includes millions of existing debit card point-of-sale terminals (e.g., debit card readers or ATM terminals) that are used throughout the world. It is further recognized that even without a PEAD enabled point-of-sale terminal, certain PEAD functionality may provide enhanced transaction security with existing debit card facilities.

According to another aspect of the present invention, there is provided a portable electronic accounting/approval device (PECAD) which not only provides the aforementioned PEAD functionality to enable a user to approve a transaction with a PEAD enabled point of sale terminal, but also enables the user to conduct transactions with existing debit card facilities. In particular, the overall PECAD system includes a PECAD and an associated emulation card that conforms to current debit card standards in view of its interface with existing debit card readers. The emulation card can be flexibly configured by PECAD to look like a normal billing card reader. The PECAD and the emulation card together form a secure system for conducting transactions with existing debit card facilities.

Note that as the term is used in the context of this embodiment, accounting cards include magnetic stripe cards and electronic smart cards. The debit card itself may represent an information card (e.g., Visa or MasterCards), an ATM card, a royal card, a rebate card, and any other type of card that a user may use with a point-of-sale terminal to obtain cash, goods, and/or services.

The memory of the PECAD has billing card data associated with one or more billing cards of the user prior to conducting a transaction. To perform the PEAD function, the memory may also include other data items discussed with respect to the PEAD. The debit card data may be entered in advance from the actual debit card itself using the appropriate read/write mechanism of PECAD.

Since PECAD includes the PEAD functionality, it can of course be used to approve a transaction with a PEAD enabled point of sale terminal in the manner discussed in relation to PEAD. However, in the absence of a PEAD enabled point-of-sale terminal, the emulation card is employed to conduct transactions with existing debit card facilities.

To conduct a transaction with the emulation card, the user first requests PECAD to write the associated debit card data for a selected debit card to the emulation card. The selected debit card may be selected by the user prior to writing. Since a single emulation card can emulate any number of debit cards, the single emulation card can advantageously replace multiple debit cards that must now be carried by one user. Preferably, the user is properly authenticated using an appropriate authentication mechanism associated with PECAD before the user is allowed to write the debit card data to the emulation card using PECAD.

After the emulation card is written with the billing card data associated with the user-selected billing card, the user may use the emulation card as a billing card to complete the transaction. That is, since the emulation card complies with the I/O requirements of existing debit card and debit card readers, it can be read by an existing debit card reader like an debit card.

Once the transaction is completed, the user may choose to erase the debit card data from the emulation card using PECAD, thereby rendering the emulation card unusable for further transactions until the correctly authenticated user again authorizes PECAD to write the debit card data to the emulation card. If the emulation card emulates an electronic smart card, the emulation card can be made unusable for further transactions by, for example, appropriately configuring registers or flags in the emulation card. Thus, even if the emulation card is stolen, it is not useful for an unauthorized user. Furthermore, even if the emulation card and the PECAD are stolen together, the emulation card itself cannot be written with the accounting card data unless the user is correctly authenticated. This is in sharp contrast to existing situations where, for example, the magnetic strip of a stolen credit card still contains all the necessary information to conduct a transaction. For further security, the emulation card itself may be physically signed by the properly authorized user, and may contain a photograph of the authorized user, so that the merchant can visually determine whether the person conducting the transaction is in fact the legitimate owner of the emulation card.

In a preferred embodiment, each emulation card is matched to a specific PECAD in a sufficiently unique manner to further enhance security. In this case, a given PECAD can only write accounting card information into its uniquely associated emulation card. For example, an emulation card may be given appropriate optically encrypted marks (e.g., holograms), magnetically encrypted marks (e.g., magnetically stored bits), or mechanically encrypted marks (e.g., randomly distributed holes) so that it can only be written by one specific PECAD.

Preferably, each emulation card is matched to a unique single PECAD. It should be noted, however, that this unique matching aspect need not be a mathematical absolute (although this is preferred). Those skilled in the art will recognize that some overlap may occur given a sufficient number of issued emulation cards and pecans, such that it is possible (albeit unlikely in real life) that a given emulation card may be identified by a number of pecans. In practice, the issuer or manufacturer may have a master PECAD that is capable of identifying multiple issued emulation cards. Thus, the meaning of an association between an emulation card and a PECAD being sufficiently unique is as if a door key were sufficiently unique for each door lock, not excluding the slight possibility that a manufacturer might choose to make an emulation card absolutely unique for a given PECAD, or that a given key might be able to open multiple door locks in the millions of door locks manufactured. Preferably the encrypted marks and geographical distribution pattern of the emulation card/PECAD (e.g. within the same city or state) may be arranged such that the likelihood of said minor is minimised.

Since each emulation is a sufficiently unique match to a particular PECAD, even if a PECAD is stolen and the authentication mechanism is successfully bypassed by a fraudulent individual, the stolen PECAD cannot be used to write accounting card data to any arbitrary blank emulation card for fraudulent transactions. As a further advantage, a given PECAD can only (after proper authentication) be written to the emulation card with which it is substantially uniquely associated, thereby substantially eliminating the situation where the PECAD accidentally overwrites an existing debit card.

Fig. 9 depicts a simplified block diagram of a PECAD902, according to an aspect of the invention. In fig. 9, a memory 904 is preferably non-volatile, prevents incorrect operation of the memory, and functions the same as the memory circuit in the PEAD, except that the memory 904 may also be used to store encrypted debit card data associated with one or more debit cards of the user. The encryption logic 906 performs the same encryption/decryption/security functions as the encryption logic discussed in connection with the PEAD. That is, accessing data stored in memory 904, including user private keys, user personal data, and debit card data, is preferably accomplished only with the aid of encryption logic 906.

Authentication mechanism 908 performs the same functions as the user authentication mechanism discussed in connection with the PEAD. I/O circuitry 910 represents circuitry that enables PECAD to communicate with a PEAD-enabled point-of-sale terminal if it is available to approve a transaction. Transaction approval aspects have been previously discussed in connection with PEAD and are not discussed in detail herein. If certain PECAD models are expected not to communicate with a PEAD point-of-sale terminal, but only to configure the emulation card for transactions with existing debit card facilities, I/O circuitry 910 may be omitted on these PECAD models.

Card read/write mechanism 912 represents a mechanism for writing selected debit card data to the emulation card and erasing the emulation card after the transaction is completed. If the debit card data is obtained by reading an existing debit card, the card read/write mechanism 912 also includes the ability to read the existing debit card to store the debit card data to the memory 904 (via the encryption logic 906). Note that data read by card read/write mechanism 912 is encrypted by encryption logic 906 before being stored in memory 904. Similarly, data stored in memory 904 (e.g., debit card data) is decrypted by encryption logic 906 before being written to an emulated card by card read/write mechanism 912.

Fig. 10 is a simplified diagram of a PECAD1002 in which an emulation card 1004 is placed. The emulation card 1004 can be removed from the slot 1006 to complete a transaction with an existing billing card reader. In the example of FIG. 10, the emulation card 1004 includes a magnetic stripe 1008 to emulate a magnetic stripe debit card. As previously mentioned, however, the emulation card 1004 can be configured to emulate any type of debit card interface, including IC contacts. The outline of a card read/write mechanism 1010 is shown in its outline form to indicate that it is part of the PECAD 1002. Data may be read from an existing debit card or written to an emulation card via the card read/write mechanism 1010. Keyboard 1015 may be used as an authentication mechanism as illustrated in 612 and 908. The user may enter a password or personal identification number to activate PECAD to write debit card data to the emulation card 1004.

Approval button 1012, which is substantially the same as approval button 606 of fig. 6A, may be used to approve a transaction through a PEAD enabled point of sale terminal. The card button 1014, on the other hand, indicates the user's desire to complete the transaction via the emulation card. Card selector buttons 1016(a) - (d) are exemplary options that may be selected by a user to select a particular debit card that may be used to conduct a transaction. A display 1018 may be used to display the debit card data for the selected debit card, such as the debit card number, expiration date, card holder name, etc., so that the merchant can copy the information to complete the transaction if necessary.

According to another aspect of the invention, transaction security is further enhanced by using PECAD to write an encrypted transaction number or other encrypted data to the emulation card that has been encrypted with the user's private key (stored in the PECAD's secure non-volatile memory). FIG. 11 illustrates this aspect of the invention, according to one embodiment of the invention. In step 1102, a unique transaction number is generated for each transaction and encrypted with the user's private key. In step 1104, the encrypted transaction number is written from PECAD to the emulation card. For example, if the emulation card emulates a magnetic stripe card, the encrypted transaction number may be written to an existing but unused track or to a reserved track, e.g., track 3 on the magnetic stripe. In step 1106, the software in the billing card reader may instruct the billing card reader to receive the encrypted transaction number and then authenticate the transaction number with a user public key that has been obtained from a trusted third party (step 1108); alternatively, in step 1106, the billing Card reader reads the encrypted transaction number, which is then sent to a credit clearing house, such as a Master Card or Visa Card, and the credit clearing house can authenticate the user with a user public key that has been obtained from a trusted third party (step 1108). Often some form of user identification may be sent to a trusted third party to assist in obtaining the public key. For example, the subscriber identity or public key identity may be read by the accounting card reader and sent to a trusted third party to obtain the public key. The public key identification may be represented, for example, as a unique pattern of public key bits (e.g., the lowest 32 bits or 64 bits) that may be transmitted to a receiving site for public key searching and decryption. If authenticated, the transaction is approved, enabling the merchant to release the goods/services to the user (step 1110).

As can be appreciated from the foregoing, the present invention requires substantially no hardware modifications to existing billing card readers and existing billing card facilities. The modification involves only a software modification that instructs the existing billing card reader to read the encrypted transaction number and authenticate the encrypted transaction number using a user public key obtained from a trusted third party.

Furthermore, there may not be any changes in the accounting card reader. But the credit clearing house software will be informed to authenticate the encrypted transaction number using the user's public key obtained from a trusted third party. The debit card reader simply reads all data from the debit or emulation card and sends all information word by word to the credit settlement center for approval. In this way, this embodiment minimizes the need for changes to existing debit card facilities (i.e., changes need only be made at one location of the credit settlement center, rather than at the millions of debit card readers that are present).

If additional security is required, the user may enter the transaction amount and/or transaction time at PECAD. These data segments will also be encrypted with the user's private key and written to the emulation card for receipt by the accounting card reader and decrypted at the credit clearing centre with the user's public key, which is also obtained from a trusted third party. In this case, transaction approval is given only if the transaction is the amount indicated in the encrypted and received transaction amount and/or the transaction occurs within a predetermined time period of the encrypted and received transaction time (before they were written from PECAD to the emulation card). Thus, even if the emulation card is stolen, subsequent other transactions are useless, even if the emulation card erasure or reconfiguration actually occurred.

In an internet transaction, a user may approve the transaction using the PEAD or PECAD by encrypting the approved amount with their own private key stored in the PEAD or PECAD. Thereafter, he may copy the encrypted information displayed on the PEAD display 610 or the PECAD display 1002, preferably in human readable form, such as an alphanumeric string, so that the user can easily read and manually enter (e.g., by typing or by voice command) into a computer connected via the Internet to conduct an Internet transaction. The information card number and transaction information may also be encrypted, if necessary, in a secure internet transaction using a PEAD or PECAD. Of course, the manual entry/keying technique required for backward compatibility could equally be replaced by other forms of data entry, such as wireless or infrared communication through appropriate ports in the computing and PECAD (or PEAD) to enable data transmission over the internet.

As previously mentioned, the authentication of the user's identity is preferably determined using a user public key maintained by a trusted third party. A trusted third party may represent, for example, any entity for which the public has a relatively high level of trust, such as an organization known to have a reputation of trustworthiness in its own right. Examples include government organizations, banks, large corporations, etc.

A trusted party maintains a PECAD public key directory service that associates public keys provided by manufacturers with users. When a user first acquires a PECAD (e.g., by purchasing or an issuer's publication), the user may register his or her ownership of the PECAD with a trusted third party. Depending on the security of the registration process, the user is assigned a level of confirmation which indicates the confidence that the person who completed the registration is actually who he said.

For example, a user may provide personal information such as social security number, home address, and home phone number, as well as the PECAD serial number and public key signature (which is a unique sequence of numbers assigned by the manufacturer to a particular PECAD that can be read from the PECAD by pressing the keys of the specified sequence) by email, phone, or letter alone. The PECAD public key directory center may then use the PECAD serial number provided by the user as a unique search identifier to search the database for the public key, which once it finds the public key, it will verify with the public key in the database using the public key signature provided by the user. If the authentication is successful, the user may be registered, otherwise the user will be rejected. The public key is preferably unique.

A more secure way of registering ownership of a user may be as follows (this process usually takes place at the point of purchase of PECAD/PEAD or at the issuer, e.g. a bank). The issuer first activates the PEAD/PECAD using the password provided by the manufacturer. Thereafter, the PEAD/PECAD user may override the manufacturer-provided password with the user's password or other authentication mechanism. The user may then instruct the PEAD/PECAD to generate a new pair of private/public keys (referred to as a user private key and a user public key) inside the PEAD/PECAD. The user may also instruct the PEAD/PECAD to encrypt personal information (e.g., social security information, home address, etc.) and the new user public key with a manufacturer-provided private key pre-stored in the PEAD/PECAD to generate a user registration message. This manufacturer-supplied private/public key pair may be generated by the PEAD/PECAD at the time the PEAD/PECAD is manufactured.

The issuer may then encrypt the PEAD/PECAD serial number and the user registration message using the public key of the public key directory service center to generate a registration message, and send the registration message to the public key directory service center. Upon receiving the registration message, the public key directory server core may then decrypt the registration message using its own private key. Thereafter, the public key directory service center may use the PEAD/PECAD serial number to search for the manufacturer-provided key found in the database. If the decryption is successful, the manufacturer-supplied public key is updated with the new user public key in the directory services database and the personal information in the directory services database is updated and the public key identification is generated with the lowest 32 bits (or 64 bits) of the personal name + phone number or public key for future reference. On the other hand, if the decryption is unsuccessful, the user may be rejected.

This registration process generally conforms to a low level of confirmation, as others than the user may fraudulently obtain personal information of the user for registering ownership (and, once registration is complete and PECAD is activated, the user is made responsible for subsequent fraudulent billing).

A medium level of acknowledgement may be obtained by: in addition to providing information for obtaining a low level of confirmation, providing information that gives a higher degree of confidence that the person providing the information is really the person he said to be. For example, the additional information may be derived from a photograph, signature, notary seal, or a combination thereof. A high level of confirmation may give even higher confidence by providing information that the person providing the information is really the person he said to be. For example, the registrant may personally appear at the PECAD public key directory center to present a photograph, a signature, a biometric sample (e.g., a fingerprint, retinal scan, DNA print, etc.), or a combination thereof.

Once registration is complete, the credit clearing house or merchant may consult the trusted third party's directory of PECAD public keys in order to authenticate the user and approve the transaction.

The PECAD public key directory may also be enhanced by establishing an insurance policy that protects the merchant or credit clearing house from financial loss due to fraud from a defective registration process. Coverage provided by an insurance policy may be measured in terms of a level of validation, with a higher level of validation being consistent with a higher amount of coverage.

While this invention has been described in terms of several preferred embodiments, there are alterations, permutations, and equivalents, which fall within the scope of this invention. It should be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. For example, while the discussion herein focuses on transaction approval, it will be apparent to those skilled in the art that the PEAD may be used to conduct any type of transaction in the face of an electronic transaction system whenever a secure data transfer is desired from a user to the electronic transaction system. For example, the PEAD may be used to log into a highly sensitive computer system or facility. When so implemented, a computer terminal in communication with the PEAD may be provided with an infrared port, a magnetic card reader port, or a contact type plug for communicating with the PEAD. The user may then perform any type of authentication task online using the PEAD.

As another example, a PEAD may be used to "sign" any computer file for authentication (e.g., authentication date or user). The transaction approval data may then be saved with the document to be authenticated for future reference. Note that the transaction authentication data is also protected from incorrect operation, so any transaction authentication data that is not encrypted with the user's private key will not be considered a trusted acceptance. Furthermore, it is apparent that if the PEAD is used only for a confirmable transaction, the transaction data may be pre-stored within the PEAD and need not be received externally by the PEAD. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.

Claims (10)

1. A method for allowing a user to conduct a debit card transaction using a debit card terminal of an electronic transaction system, said debit card terminal configured to interface with a debit card to conduct the debit card transaction, providing a merchant card to a merchant conducting said debit card transaction, the method comprising

Accepting the merchant card and a personal identification number or mobile phone number from a user conducting the debit card transaction at a debit card terminal of the merchant conducting the debit card transaction,

detecting use of the merchant card at a central processing area,

the payment server uses the telephone number or personal identification number associated with the transaction as an index into a database storing the personal mobile telephone number required to authorize the transaction;

the database also stores records as to whether the authorizer's mobile phone has an embedded Portable Electronic Authorization Device (PEAD);

in response to said detecting step, placing a call to a mobile telephone of an authorizer for said debit card transaction using said telephone number or pin number, sending a report of said user debit card transaction to said mobile telephone, and returning an approval of the debit card transaction to the debit card terminal of the merchant only if approved by the authorizer;

the authorizer approves the transaction by entering a personal identification number into the portable electronic authorization device at the mobile phone.

2. A method as claimed in claim 1, wherein after the merchant card is accepted, the merchant further enters an amount to be traded.

3. A method as claimed in claim 1, wherein after the merchant card is accepted, the merchant further enters an identification of the type of transaction carried out.

4. A method as claimed in claim 1, wherein the merchant card is assigned a valid credit card number, the valid credit card number of the merchant being detected to initiate the step of calling the authorizer's mobile telephone.

5. The method as claimed in claim 1 further comprising the steps of: filtering, by a central processing server, all credit card transactions from the merchant's debit card terminal after the merchant card is accepted, and in response to the filtering step,

if the merchant card number received from the merchant is not a unique merchant assigned number, the server does not perform any operation;

or if the merchant card number is a unique merchant assigned number, using the telephone number or pin number as an index to look up information in a database in the payment server.

6. A method as claimed in claim 1, wherein after determining that the authorizer's mobile telephone has a portable electronic authorization device, the server sends a transaction message to the authorizer's telephone for approval using a portable electronic authorization device embedded in the telephone, the authorizer approving the transaction by entering a personal identification number at the mobile telephone.

7. The method as claimed in claim 1, wherein if the database lookup indicates that the authorizer's mobile phone is a touch-tone phone, the server will send a message to the authorizer's mobile phone requesting a dial-tone personal identifier for approval.

8. A method as claimed in claim 7, wherein the database server uses an interactive voice response system to transmit the transaction information to the authorizer's mobile telephone.

9. A method as claimed in claim 7 or claim 8, wherein after the transaction is authorised/authorised by the authorised person, a settlement is made to the authorised person's account using an account selected from the group comprising a credit card, an Automated Teller Machine (ATM), a bank account or a debit card.

10. A method as claimed in claim 1 or claim 5, wherein the party controlling the payment server is the issuer of the merchant card.