Payment system

The related application of the first payment method This application is a follow-up application to the 09/260384 patent application filed on March 2, 1999. The title of the 09/260384 application is "Portable Electronic Accounting and Authorization Equipment and Its Method", which is 1998 A follow-up application to the 09/067176 application filed on April 27, 2005, in which the 09/067176 application was invented by Ynjiun P. Wang, with the title "Payment System" and is incorporated herein as a reference.

TECHNICAL FIELD The present invention relates to methods and devices for conducting electronic transactions. The present invention particularly relates to a portable electronic authorization device (PEAD), which advantageously and fully eliminates the security risks associated with the prior art of verifying transactions between a user and an electronic transaction system.

The present invention relates to a method and device for conducting electronic transactions. The present invention particularly relates to a portable electronic authorization device (PEAD), which advantageously and substantially eliminates the security risks associated with the prior art of verifying transactions between a user and an electronic transaction system.

BACKGROUND Electronic transaction systems are known. An electronic transaction system usually allows a user to conduct a specified transaction electronically, which fully improves the user's efficiency and convenience. Examples of electronic transactions include transactions conducted through computer networks, automated teller machines (ATM), automated point-of-sale systems, automated library systems, and similar systems. Transactions conducted through computer networks include a wide range of transactions, including the exchange of information and data through a computer network generally called the Internet, so as to purchase goods from sellers on the network. ATM usually enables users to conduct financial transactions (such as withdrawals, transfers, deposits, and similar transactions) electronically with a financial institution. Automated point-of-sale systems can be used by merchants to enable users to purchase products or services using their electronic accounts, while automated library systems can be used

02828557.3 Section enables library users to lend and return library materials. Other examples of electronic trading systems are easily found in the popular literature and will not be listed here for the sake of brevity.

In order to enhance the security of user accounts, electronic transaction systems usually require the user to provide identification data to prove that he is a user authorized to conduct one or more transactions proposed. If the user cannot provide the required identification data, the proposed transaction or transactions are not authorized and will not be processed. Identification data may be required for every transaction. For example, an automated point-of-sale system may require users to approve a purchase transaction, and only when the user who approves the transaction has provided sufficient identification data to prove that he is a user authorized to perform the approval, will the approval message be accepted. The identification data can also be entered by the user at the beginning of a session to prove himself, and allows the user to perform any number of transactions subsequently without the need for authentication.

In the prior art, users are usually required to manually input identification data into an electronic transaction system for authentication. Generally, the input of identification data involves typing a password on a numeric keypad or a keyboard. The identification data is then compared with the data previously stored in the electronic transaction system, and when the two match, the authentication is satisfied. As mentioned earlier, if there is a mismatch, one or more of the proposed transactions will not be allowed.

Although the prior art electronic transaction system provides some protection against unauthorized access and use of user accounts, it has some disadvantages. In order to illustrate some of the shortcomings related to the prior art electronic transaction system, reference may be made here to FIG. 10. FIG. 1 shows an automatic teller machine (ATM) 100, which represents a requesting device of the electronic transaction system 102. The electronic transaction system 102 may include, for example, a central database 104 that contains previously stored identification data and account data of the user 106.

In order to initiate a typical transaction with the ATM 100, 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 usually includes a magnetic stripe, which contains information with the user The relevant account number and other information can then be read by the card reader 109. The data stored in the data card 107 allows the electronic transaction system 102 to determine which account in the database 104 the user 106 wants to make a transaction.

Then the user 106 can enter his ID through a keyboard 108 of the ATM 100 _h

02828557.3 The first data, for example, his personal identification number (PIN) to prove himself. If the input identification data matches the identification data of the account identified by the data card 107 stored in the database 104, the user is authenticated and allowed to access his account. If it does not match, the authentication fails. After authentication, the user 106 can use a combination card of the keyboard 108 and a screen 110 to withdraw cash from his account, which causes the cash to be withdrawn from the ATM 100, and the balance of his account in the database 104 is reduced accordingly.

Theoretically, the identification data entered into the ATM 100 should be safe. In fact, in the prior art authentication technology, there are many potential security risks for the identification data. Since the identification data is not encrypted before being input into the ATM 100, the unencrypted identification data is easily accessed and obtained without authorization. In the prior art, the encryption of identification data is unrealistic because it is too complicated and/or inconvenient for users to perform encryption or remember the encrypted identification data. In the prior art, unauthorized acquisition of identification data may occur when being inputted by another party unintentionally, for example, by another person behind the user 106 on the screen 110 or more likely on the keyboard 108.

Even if the identification data is encrypted before being sent from the ATM 100 to the database 104 in the prior art, the encryption usually occurs in the ATM 100, and the user 106 is still required to enter the unencrypted identification data, and the identification data will still be in the ATM 100 Exist for a while. Therefore, if an unauthorized party can enter the ATM 100 and intercept the unencrypted identification data therein through software or hardware implemented in the ATM 100, unauthorized access to the identification data may occur.

In addition, if a public key is used in the ATM 100, storing the user's private key in the ATM 100 makes the private key easy to be stolen, and further exposes the user's account to danger. The stolen password and/or private key can then be used to allow unauthorized users to access the user account, causing harm to the user.

From the foregoing, it is hoped that such a device and method can be used to conduct transactions with an electronic transaction system while fully eliminating the danger of unauthorized access to user accounts and unauthorized acquisition of user identification data. Such equipment should preferably be portable so that users can conveniently and comfortably execute transactions anywhere.

02828557.3 The content of the invention discloses a method for enabling a user to use a billing terminal of an electronic transaction system to perform a billing transaction, wherein the billing card terminal is configured to interact with a billing card for To conduct debit card transactions, provide a merchant card to a merchant that conducts debit card transactions, including accepting the merchant card at the debit card terminal of the merchant who wants to conduct debit card transactions and those from those who conduct debit card transactions. A users personal identification number or mobile phone number is used to detect the use of the merchant card in a central processing area, and in response to the detection step, the phone number or personal identification number is used to send to the mobile phone of the authorized person required for the debit card transaction A call, a report of the user's debit card transaction is sent to the mobile phone, and the authorization for the debit card transaction is returned to the merchant's debit card terminal only when the authorized person approves it.

The merchant can also enter the amount to be billed and the identification of the type of transaction to be performed.

A valid credit card number can be assigned to the merchant card, and the valid credit card number of the merchant can be detected to initiate the step of calling the authorized person's mobile phone.

The method may further include the following steps: filtering all credit card transactions from the merchants debit card terminal through a central processing server, and in response to the filtering step, if the card number received from the merchant is not a unique number assigned by the merchant, the server Do nothing, or if the card number is a unique number assigned by the merchant, use the phone number or personal identification number as an index to look up the information in the payment server's database.

The method may further include that the payment server uses the phone number or personal identification number associated with the transaction as an index to a database storing the mobile phone numbers of individuals who are required to authorize the transaction.

In this method, the database can also store a record about whether the authorized person's mobile phone number has an embedded PEAD. If it is determined that the authorizers mobile phone has a PEAD, the server sends a transaction message to the authorizers phone to use a PEAD embedded in the phone for approval, and the authorizer enters a personal identification number on the mobile phone for approval transaction.

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

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

After the authorizer authorizes/approves the transaction, an account selected from the group including credit card, ATM, bank account or debit card can be used to clear the authorizers account.

BRIEF DESCRIPTION OF THE DRAWINGS To help the discussion, Figure 1 shows a prior art electronic transaction system, including an automated teller machine (ATM). Figure 2 depicts a portable electronic authorization device (PEAD) according to an embodiment of the present invention. Represents a device used to securely approve transactions with an electronic transaction system.

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

Figure 3B shows a representative transaction approval data format in an embodiment.

Fig. 4 depicts a logical block diagram of PEAD according to an embodiment of the present invention.

Fig. 5A shows a high-level hardware implementation of PEAD according to an embodiment of the present invention.

Figure 5B depicts an embodiment of a PEAD, in which the PEAD circuit is implemented in an IC.

Fig. 5C shows an external view of the PEAD of Fig. 5B when it is embedded in a card-shaped package.

Figure 6A depicts an external view of the PEAD according to a preferred embodiment of the present invention.

Fig. 6B depicts in a simplified manner the hardware implementing the PEAD of Fig. 6A according to one aspect of the present invention.

Figure 7 is a flow chart describing the use of the invention according to one aspect of the invention

02828557.3 The approved technology of PEAD.

Figure 8 is a flow chart describing the steps involved in making a public key encryption technique to encrypt transaction approval data according to one aspect of the present invention.

Figure 9 depicts a simplified block diagram of a portable electronic accounting and authorization device (PECAD) according to one aspect of the present invention.

Fig. 10 is a simplified view of a PECAD according to an embodiment of the present invention, in which a simulation card is installed.

Figure 11 is a simplified flow chart that describes how a transaction number can be used in conjunction with a PECAD system to improve transaction security according to an embodiment.

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

DETAILED DESCRIPTION OF THE INVENTION The present invention further relates to a payment system (EPS) for making payments with a phone number and using a PEAD or a mobile phone to approve the payment. In order to integrate into the existing point-of-sale system, a valid credit card number is reserved as an eSignX merchant card number (EMC number). For a user who registers his/her phone number (preferably his/her mobile phone number) in the eSignX payment system, it is possible to pay at the point of sale by providing his/her phone number to a merchant. Merchants can read the eSignX Merchant Card (EMC), and then enter a customers 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 First Data Corporation ( FDC). The present invention only needs to properly install an eSignX payment server in the existing facility, so as to obtain a unique EMC number by filtering all the debit card numbers passing through the system. If the card number is not the only EMC number, no action is taken. If the card number is the only EMC number, use the phone number as an index to look up the database in the eSignX payment server. If the search result indicates that the users mobile phone is embedded with a PEAD, for example, a A WAP phone with a WIM card or SWIM card, or a Java phone with a PEAD module of xDSM software, the eSignX payment server will

02828557.3 The first users phone sends a transaction message in order to use a PEAD embedded in the phone for approval. 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 in order to use a dial tone for approval.

An exemplary transaction can be understood by referring to the block diagram of Figure 12, which describes the basic physical elements of this embodiment and the data flow used by the method and device. The first step, when a transaction is to be authorized at a merchant, in order for the user of this system to pay at the point of sale, the user only needs to enter his phone number (preferably his or her mobile phone number) before the transaction Register in the eSignX payment system, and then pay at the point of sale by providing the phone number to the merchant. Of course, registering a personal identification number and providing the personal identification number to the merchant is also equivalent.

In either case, after receiving the personal identification 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 currently used for reading The credit card reader is a type. 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 phone 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 For example, the First Data Corporation maintains a large-scale data processing center 1210, and the input data is cited here.

In addition to the data processing already performed in this center, this method only needs to install a payment server at 1210 or another location for capturing the data entered with the EMC merchant card 1202. This can be accomplished by using a server 1220 that can be incorporated into the main data processing center 1210 before or after data processing is usually performed in the credit card data processing center. The function of the payment server 1220 in the existing facility is to obtain a unique commercial identification (EMC) number from the merchant card 1202, preferably by filtering all debit card numbers passing 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.

02828557.3 If the card number is a unique commercial (EMC) number, the data is immediately transferred to the EMC payment server 1220, so that the phone number or personal identification number can be used as an index to find the person in the database who must authorize the transaction (it may be It may not be the publisher) all available information.

The approval can then be concurrent with the ongoing transaction from the mobile phone number or personal identification number pointed to by the mobile phone 1230; this may or may not be a mobile phone held by the individual requesting the transaction.

If the search result at the payment server 1220 indicates that a PEAD is embedded in the users mobile phone, such as a WAP phone or WIM card, SWIM card, or a Java phone with the xDSM software PEAD module, the payment server 1220 sends a message to the authorized persons phone 1230 A transaction message used for approval with a PEAD embedded in the phone. After the holder of the mobile phone with PEAD receives the message, they can enter an approval code, or ignore the message, or enter a non-approval code.

In an alternative embodiment, if the search 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 dial-up personal identification. number.

In either case, the holder of the mobile phone 1230 associated with the mobile phone number or personal identification number maintains control over the approval of the transaction, regardless of whether they are present at the transaction location.

Figure 2 depicts a portable electronic authorization device (PEAD) 200 according to an embodiment of the present invention, which represents a device for securely approving transactions with an electronic transaction system. Referring to FIG. 2, the requesting device 202 can start a transaction approval process with the PEAD 200 by sending a transaction request related to the proposed transaction to the PEAD 200 through the port 204. The requesting device 202 may represent, for example, an ATM machine, a computer terminal in a network, an automatic library lending terminal, or a similar device for enabling users to conduct transactions with an electronic transaction system. The proposed transaction may be, for example, the sale of a specific item in exchange for a certain amount of money. The transaction request itself may include, for example, the transaction identifier, the name of the merchant, the identifier of the merchant, the time when the purchase is made, and so on. In one embodiment, the transaction request from the requesting device 202 may

02828557.3 is encrypted to enhance security, but this is not required. Data related to the proposed transaction reaches PEAD 200 via path 206 in Figure 2.

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

The user can then view data related to the proposed transaction on a screen 208 of the requesting device 202 or, optionally, a display screen (not shown in FIG. 2) provided by the PEAD 200. If the user approves the transaction, for example, buying an item with a certain amount of money, the user can indicate his approval by activating a switch 210 of PEAD 200_h, which allows an approval message to be created, encrypted, and passed through the path with the users identification data 212 is sent back to the requesting device 202_oIf the transaction is not approved, as long as the user does nothing, let the transaction request expire after a period of time or activate another switch of PEAD 200 _h (not shown in Figure 1), which allows an encrypted or unencrypted rejection message to pass Path 212 is sent back to requesting device 202_o The present invention is different from the prior art of FIG. 1 in that in the prior art, the user must input his identification data into the electronic transaction system, for example, into the ATM 100 to authenticate himself. On the contrary, the present invention makes the identification data related to the user always safe in PEAD. The transaction approval takes place in the PEAD 200, and the data representing this approval is encrypted in the PEAD 200 before being sent to the electronic transaction system (for example, the requesting device 202 in FIG. 2).

Therefore, even if the approved data is intercepted, its encryption will prevent unauthorized users from using the identification data for illegal purposes. If public key encryption is used to encrypt the approved data, the user's private key is always kept in PEAD 200. Since the user's private key is necessary for encryption and is not known to others (even the electronic transaction system in one embodiment), if the encrypted approval data is intercepted, it is useless for unauthorized third parties, even if The user public key can be used to decrypt the approved data. In addition, this is different from the authorization technology of the prior art. In the prior art, encryption is issued in the electronic transaction system.

02828557.3 is born, and requires the input of identification data and/or read the user's private key from an identification card such as an ATM card, a credit card, etc. As mentioned earlier, the prior art electronic transaction system requires this identification data and/or the fact that the user-to-person key exposes these data to danger, for example, if the equipment is improperly requested or may be through software or hardware. Interception.

Another difference is that the present invention uses the circuit in the portable electronic authorization device (PEAD) to perform the approval and encryption of the transaction approval data in the PEAD itself. In contrast, data cards in the prior art are basically passive devices. For example, an ATM card or a credit card in the prior art has only one magnetic strip for storing account information, and does not have any device for performing the approval and/or encryption of the transaction approval data. The smart card of the IC card currently being developed may include electronic circuits. The current implementation standards still require a card reader associated with the requesting device to read the identification data and/or the user's private key in order to request the device to perform any approval and / Or encryption. As mentioned earlier, sending these data to the requesting device unnecessarily puts the data at risk of being exposed to theft and/or unauthorized interception once sent.

It should be remembered here that although the present invention has been discussing public key encryption to help understand and emphasize a specific aspect of the present invention, the entire invention is not limited to any specific encryption algorithm, and can be implemented using any conventional encryption technology, including such RSA public key encryption technology, Diffie-Hellman, other discrete logarithmic systems, elliptic curve systems, etc. For other information on some different public key encryption technologies, please refer to the "IEEE P1363/D8 Standard Specification for Public Key Encryption" on October 5, 1998, which can be obtained from the following address: New York State IEEE Standards Department, 345 East, Seventh Street, New York City, 10017-2349 ο As already mentioned, transaction approval in the prior art occurs in an electronic transaction system. In contrast, the present invention allows transaction approval to occur within PEAD 200. The fact that transaction approval occurs entirely within PEAD 200 provides many advantages. For example, this function eliminates the need to have identification data and/or user private keys in the requesting device in one embodiment. The fact that transaction approval takes place entirely within PEAD 200 (using user identification data and/or user private encryption keys that are always kept secure in PEAD 200) fully enhances the confidentiality of user identification data and user private keys. And the end of the transaction approval process

02828557.3 The first integrity.

Since the transaction takes place entirely within the PEAD 200, the user identification data used to authenticate the transaction can be more complex and detailed to ensure higher security. For example, user identification data can be more detailed than a simple password, and can include any of the following items: user name, date of birth, social security number, or other unique biometric or unique identification data, such as fingerprints, DNA code strands, voiceprints Wait. In contrast, the existing authentication technology limits user identification data to simple forms that are easy to remember by users, such as a simple password of several characters, because more detailed identification data may be too difficult to remember or too long to be manually input. In addition, even if the complex identification data can be stored in the data card of the prior art, it still needs to be read into the requesting device of the electronic transaction system. Once the data is read, it will be exposed to intercepted or stolen data again. In danger.

Other security measures that will be discussed in detail here will also be provided to prevent access (whether electronically or through a physical device) to the user identification data and/or user private key within the PEAD 200. Since identification data and/or user private keys are never exposed, the security risks of these data are sufficiently minimized.

FIG. 3A shows a simplified schematic diagram of the PEAD 200 of FIG. 2 in an embodiment of the present invention, including a switch 210. The data path 206 is provided to receive transaction requests from the electronic transaction system, and the data path 212 is provided to send transaction approval data back to the electronic transaction system. It should be remembered that although the two data paths and other data paths here may represent logical data paths in one embodiment, they may be implemented by a single physical data connection. Similarly, the different ports here may represent logical data ports in one embodiment, so as to facilitate understanding, and may actually be implemented using a single physical port.

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

02828557.3 Note that the user identification data block 302 used in the transaction approval process is not directly connected to the paths 206 and 212. In other words, the part of the memory storing the user identification data is deliberately disconnected from the input and output ports of the PEAD 200 to prevent direct access to it.

If access to the user identification data 302 is required, for example, to approve a transaction, the access can only be completed by the encryption logic block 300. Likewise, it is impossible to directly access the memory portion 304 storing the user's private key. If it is necessary to access the user's private key 304, for example, to authorize data in an encrypted transaction, the access can only be completed by the encryption logic block 300. It should be remembered that although the user ID 302 and the user private key 304 are shown to be stored in different memory sections, this description is made for ease of understanding. In one embodiment, both may actually be stored in the same storage. At different addresses on the module.

In some cases, the transaction approval data needs to include a specific segment of the 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 resent back to the electronic transaction system. FIG. 3B shows the format of representative transaction approval data 350 in one embodiment. Referring to FIG. 3B, the transaction data 352 representing a part or the entire transaction request received from the electronic transaction system is appended with specific user identification data 354, and optionally, a time stamp 356. The generation of the transaction approval data 350 only occurs after the transaction request has been approved by the user. Once attached, the transaction approval data 350 is encrypted before being re-sent back to the electronic transaction system.

In some cases, it may be necessary to encrypt the transaction request before sending it to PEAD to further enhance security. For example, a particular trading partner, such as a vendor or other user on a computer network, may wish to keep the information in a transaction request confidential and may wish to encrypt the transaction request before it is provided to PEAD. When, for example, user identification data and user private key are written into an empty PEAD for the first time to configure a PEAD that is unique to a specific user, data encryption is also required. Although the configuration data related to the user identification data and the user's private key need only be written into the PEAD 200 once by the user of the PEAD 200, it is better to encrypt it so that it is not easy to be stolen. The issuer of PEAD 200 can represent, for example, a credit card user, the government, or any other institution with which the user maintains an account.

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

Transaction requests are usually unencrypted, that is, they are received and accessed in the manner discussed in connection with Figure 3A. However, for highly sensitive transactions, the transaction request can be encrypted, sent to the PEAD 200 through the data path 206, and input to the decryption logic 402 to be decrypted. If a public key is used for encryption, the encrypted transaction request can be decrypted with a public key 404 of a transaction partner.

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

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

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

02828557.3 In addition, user identification data and user private keys cannot be updated by those who do not have the issuer's private key. As shown in FIG. 4, data can be written into the user private key block 304 and the user identification block 410 only after being decrypted by the decryption logic 402 having the issuer's public key 412. Therefore, unless the configuration data has been encrypted with the issuer's private key (which is assumed to be highly secure), the updated configuration data will not be decrypted and written to the respective blocks 304 and 410. Of course, if the configuration data in blocks 304 and 410 cannot be physically updated, for example, they are stored in a memory that can only be written once, such as PROM (Programmable Read Only Memory), WORM (Write Once Read Many Times), etc. This fully eliminates the security factors associated with unauthorized changes to the configuration data.

If a higher level of security is required, the user private key can be optionally scrambled or randomized by optional scrambler/descrambler logic 412 before being written to the user private key block 304. In one embodiment, the scrambler/descrambler logic 413 may receive the user private key provided by the organization that issued the PEAD 200 to the user, and scramble and/or randomize it to generate another user private key And a corresponding user public key. Then this scrambled/randomized user private key is stored in the user's private key block 304, and now it is unknown even to the issuer of PEAD 200, and the corresponding user public key allows the issuer and / Or the trading partner knows to facilitate the transaction. Advantageously, except for the user private key block 304, there are no other copies of the user's private key after being scrambled/randomized.

In an alternative embodiment, an optional key generation logic 414 may be used, which responds to a request from the issuing organization to independently generate the user's private key and the user's public key, that is, it is not required to receive it from the issuing organization first. A users private key and randomize it. The generated user private key is then stored in the private key block 304, and the public key is known by the issuing organization and/or transaction partner to facilitate the transaction. In this way, the user's private key does not exist outside the PEAD itself, whether it is randomized or not. As those skilled in the art can realize, the use of the key generation logic 414 further enhances the confidentiality of the user's private key.

Fig. 5A shows a high-level hardware implementation of PEAD 200 according to an embodiment of the present invention. As shown in Figure 5A, PEAD 200 includes a logic circuit 502, which can show

02828557.3 first shows a central processing unit, such as a microprocessor or a microcontroller, discrete logic, programmable logic, an application specific integrated circuit (ASIC), etc., used to implement the encryption logic 300 of Figure 2 and optionally the implementation diagram 4 decryption logic 402. In addition to storing other content, the program/data memory 504 also stores codes for operating the PEAD 200, user identification data, and user private keys. The program/data memory 504 is preferably implemented by some form of non-volatile memory (NVM), such as flash memory, electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), and so on. The temporary memory 506 is used as a temporary register for calculation purposes and temporary storage of data. It can be implemented with some form of random access memory (RAM), such as static RAM or dynamic RAM, which are all in the prior art known. Alternatively, any of optical storage, magnetic storage, or other types of storage may also be used to implement the program/data storage 504 and/or the temporary storage 506.

A bus 508 connects the program/data memory 504 and the register 506 with the logic circuit 502. The communication port 510 represents a communication gateway between the PEAD 200 and the electronic transaction system, and can be implemented with infrared technology wireless RF technology, a magnetic read/write head, a contact plug for facilitating serial or parallel data transmission, and the like. In one embodiment, the communication port can also represent a PC card port (generally referred to as a PCMCIA card by those skilled in the art). The data path 206 inputs the transaction request to the logic circuit 502, and the data path 212 outputs the transaction approval data from the logic circuit 502 to the electronic transaction system. The optional data path 408 described in FIG. 4 inputs configuration data into the PEAD 200 to write the user identification data and the user's private key into the program/data storage 504 so as to uniquely configure the PEAD 200 to a specific user.

Note again that accessing the program/data storage 504 and the data in it (for example, user identification data and user private key) can only be completed by the logic circuit 502. For example, the user identification data and the user private key can only be written into the program/data storage 504 if this data has been correctly encrypted by the issuer's private key. Access to these memory blocks in order to write to them may also be restricted by the logic circuit 502 under appropriate software and/or hardware control.

Similarly, reading user identification data and accessing the users private key can only be done through logic

02828557.3 The encryption logic of No. 502 is completed. The advantages of this aspect of security have been discussed in connection with Figures 3A and 4. The most important point is that it is best not to directly access sensitive user identification data and user private keys from the outside. Therefore, the invented design significantly enhances the confidentiality and security of these data items.

It is also possible to provide some type of power source, such as a battery. The PEAD 200 is implemented as a single chip design, that is, almost all the components shown in FIG. 5A are manufactured on a single chip, and the power supply is outside the chip itself. If contact communication is used, for example, if the PEAD 200 must be inserted into the electronic transaction system for transactions, the external power supply of PEAD can be used for transaction approval when plugged in, thus eliminating the need to carry a battery on the portable transaction device Related size, weight, and cost penalties.

In one embodiment, the PEAD 200 can 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®, can be used to implement the PEAD 200).

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

Fig. 5C shows an external view of the PEAD of Fig. 5B, in which the PEAD has been embedded in a card-like package for easy carrying and insertion into a serial I/O port of an electronic transaction system. In one embodiment, the card 550 embedded with an integrated circuit implementing the invented PEAD includes four external melting points. Also shown are the Vcc contact 524 and the external ground contact 526 that 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 energized through the external contacts 524 and 526, so that the PEAD circuit therein can receive transaction requests through the serial contacts 552 and 554, and if appropriate, in the PEAD Approval request, encrypt the transaction approval data in the PEAD circuit, and pass the encrypted transaction approval data through the external serial contacts 552 and 554

02828557.3 The serial communication to the electronic trading system.

'Figure 6A shows an external view of the PEAD according to a preferred embodiment of the present invention. The PEAD 200 of Figure 6A is best implemented as a small independent package sufficient for daily on-site use. The PEAD 200 of FIG. 6A is preferably small enough to be carried by the user at any time, for example, as a key chain pendant or a small package that can be easily installed in a purse or wallet. The physical package of PEAD 200 is best designed to prevent incorrect operation of its content (that is, if it is opened in an unauthorized manner, the user private key and/or user identification data will be damaged, or PEAD will Can no longer approve transactions). For example, the package can be designed such that if it is opened, the current in the circuit path changes, for example, or an existing current is interrupted, or an idle current path starts to flow. Then the change in current can force RE.

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

The optional display 610 may be implemented by any type of display technology, such as liquid crystal technology. In addition to displaying other content, the display 610 also displays the proposed transaction to be approved. The display 610 can be omitted if necessary, in which case the transaction can be viewed on a display associated with the electronic transaction system itself. The optional user authentication mechanism 612 prevents PEAD from being used to approve transactions unless the user can identify to the PEAD 200 that he is a legitimate and authorized user. Before the PEAD 200 can be activated and used to approve the transaction, the optional user authentication mechanism 612 may require the user to enter a password, provide a fingerprint or a voiceprint, or other biometrics and/or identification unique to the authorized user characteristic.

FIG. 6B describes in a simplified manner the hardware that implements the PEAD 200 of FIG. 6A according to one aspect of the present invention. The battery 652 supplies power to the circuit of the PEAD 200. A micro

02828557.3 The first controller 654 executes the code stored in the flash memory 656, and uses the random access memory 658 to execute it. In one embodiment, the microcontroller 654, the flash anvil 6 and even the random access memory 658 can be implemented in a single chip, such as the NC68HC05SCXX family from Motorola, Schaumburg, Illinois, such as NC68HC05SC28. The approval button 606 and optional skip button 608 are connected to the microcontroller 654 so that the user can indicate the approval or rejection of a particular transaction displayed by the display circuit 660. The communication with the electronic transaction system is accomplished through an infrared transceiver 662 under the control of the microcontroller 654. The power switch 664 allows the user to turn off the power of the PEAD 200 when not in use to save power and prevent accidental approval.

Figure 7 is a flow chart describing the use of the PEAD authentication technology invented according to one aspect of the present invention. In step 702, the PEAD receives a transaction request from the requesting device related to the electronic transaction system. In step 704, the user can choose to approve or disapprove the proposed transaction. If the skip button of PEAD is activated or the request expires without approval, no operation is performed.

On the other hand, if the user approves the proposed transaction, the user can activate the approve button to generate transaction approval data. Then in step 708, the transaction approval data is encrypted in PEAD. In step 710, the encrypted transaction approval data is sent to the requesting device of the electronic transaction system after being encrypted.

Figure 8 is a flow chart describing the steps involved in encrypting transaction approval data using public key encryption according to one 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 can be generated by appending any necessary user identification data to part or all of the transaction request. Optionally, a time stamp can also be attached to it. In step 804, the transaction approval data is encrypted by using the user's private key, where the user's private key is preferably kept safe in the PEAD at all times. Thereafter, the encrypted transaction approval data is sent back to the electronic transaction system.

According to one aspect of the present invention, it is recognized that even if the encrypted transaction approval data is intercepted and decrypted by a third party for analysis, as long as the user's private password or user identification data is secure, it is impossible to bypass the security of the present invention. Sexual characteristics. As mentioned earlier,

02828557.3 First, since the user identification data cannot be accessed from the outside, it is always kept safe within PEAD. This is different from the prior art. In the prior art, the user needs to enter identification data, such as a password, at the electronic transaction system, at the risk of exposing this sensitive data.

Even if the integrity of the user identification data is compromised, the transaction cannot be approved unless the user's private key is possessed. It is also useless to intercept the encrypted transaction approval data, even if it can be decrypted with the user's public key, because transaction partners, such as merchants requesting approval of the transaction, will not accept any transaction approval data that is not encrypted with the user's private key. In addition, since the private key cannot be accessed from the outside, it is always kept secure within PEAD. This aspect of the invention has great advantages in performing online transactions, because the users private key no longer needs to be stored in a vulnerable computer file on a workstation, it may be accessed by other parties, and it may be difficult to It is easily taken out for other authentication tasks.

The fact that the PEAD is now in a small portable package allows the user to conveniently and comfortably keep the PEAD in its belongings at any time. Even if the PEAD is physically stolen, the optional user authentication mechanism, for example, the user authentication mechanism 612 of Figure 6A will provide an additional level of protection and make PEAD available to anyone other than the correct authenticated user. All useless. Of course, if the PEAD is stolen or lost, the user can always notify the issuer of the PEAD, and the issuer can notify the transaction partner to refuse any transaction approval data encrypted with the user's private key of the stolen PEAD.

The fact that the transaction approval data includes timestamps, business names, approved amounts, and any other relevant data also enhances the security of the approval process. If the merchant unintentionally or intentionally submits multiple transaction approvals to the issuer, the issuer can recognize from these data items that the submission is repeated, and ignore any duplicate transaction approval data. For example, the publisher may realize that a user is unlikely to purchase multiple copies of the same dinner at the same restaurant at a specific time and date.

The inventor here recognizes that although PEAD and PEAD-enabled point-of-sale terminals provide a highly secure system for approving transactions, there is a well-established and widely available debit card facility that includes hundreds of Thousands of existing debit card point-of-sale terminals (such as debit card readers or ATM terminals) used all over the world.

02828557.3 The first further realizes that even without PEAD-enabled point-of-sale terminals, specific PEAD functions can provide enhanced transaction security with existing debit card facilities.

According to another aspect of the present invention, a portable electronic billing/approval device (PECAD) is provided, which not only provides the aforementioned PEAD function so that the user can approve a transaction with a PEAD-enabled point-of-sale terminal, but also enables the user Ability to conduct transactions with existing debit card facilities. In particular, the entire PECAD system includes a PECAD and a related simulation card. As far as the interface between the simulation card and the existing debit card reader is concerned, it follows the current debit card standard. The simulation card can be flexibly configured by PECAD to make it look like an ordinary debit card reader. Together, PECAD and the simulation card form a security system for transactions with existing debit card facilities.

Note that as a term used in the context of this embodiment, the debit card includes a magnetic stripe card and an electronic smart card. The debit card itself can mean information cards (such as Visa or Master Cards). ATM cards, royal cards, discount cards, and any other type of card that users can use at a point of sale terminal to obtain cash, goods, and/or services.

Before conducting a transaction, the storage of PECAD has debit card data related to one or more debit cards of the user. In order to perform the PEAD function, the memory may also include other data items discussed in relation to the PEAD. The debit card data can be input in advance from the actual debit card itself using PECAD's appropriate read/write mechanism.

Since PECAD includes PEAD functionality, it can of course be used to approve transactions with a PEAD-enabled point-of-sale terminal in the manner discussed with respect to PEAD. However, in the absence of PEAD-enabled point-of-sale terminals, simulated cards are used to conduct transactions with existing debit card facilities.

In order to conduct a transaction with the simulated card, the user first requests PECAD to write the relevant debit card data of a selected debit card to the simulated card. The selected debit card can be selected by the user before writing. Since a single simulation card can simulate any number of debit cards, this single simulation card can advantageously replace multiple debit cards that a user must carry. It is best to use an appropriate authentication mechanism related to PECAD to correctly authenticate the user before allowing the user to use PECAD to write the debit card data to the simulation card.

After the simulated card is written into the debit card data related to the debit card selected by the user, the user

02828557.3 The simulation card can be used as a debit card to complete the transaction. That is, since the simulation card complies with the I/O requirements of existing debit cards and debit card readers, it can be read by an existing debit card reader like a debit card.

Once the transaction is completed, the user can choose to use PECAD to erase the debit card data from the emulation card, so that the emulation card can no longer be used for other transactions, until the correctly authenticated user authorizes PECAD to write the debit card data to the emulation again Card on. If the emulation card emulates an electronic smart card, the emulation card can no longer be used for further transactions by, for example, appropriately configuring the registers or flags in the emulation card. Thus, even if the emulation card is stolen, it is useless to an unauthorized user. In addition, even if the simulation card and PECAD are stolen, unless the user is correctly authenticated, the simulation card itself cannot be written into the debit card data. This is in sharp contrast to the existing situation, where, for example, the magnetic strip of a stolen credit card still contains all the necessary information for a transaction. For further security, the simulation card itself can be physically signed by a correctly authorized user, and can contain a photo of the authorized user, so that the merchant can visually determine whether the person conducting the transaction is actually the legality of the simulation card owner.

In a preferred embodiment, each simulation 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 the debit card information into its uniquely related simulation card. For example, a simulated card may be given appropriate optically encrypted marks (such as holograms), magnetically encrypted marks (such as magnetic storage bits), or mechanically encrypted marks (such as randomly distributed holes) so that it can only be used by one Specific PECAD writing.

It is best to match each simulation card with a unique single PECAD. However, it should be noted that this unique matching aspect does not have to be a mathematical absolute (although this one is preferred). Those skilled in the art will recognize that given enough issued simulation cards and PECAD, some overlap may occur, making it possible (although the possibility in real life is very small) for a given simulation The card may be recognized by multiple PECADs. In fact, the issuer or manufacturer may have a master PECAD, which can identify multiple issued simulation cards. Therefore, the association between a simulation card and a PECAD is sufficiently unique. This means that a door key is sufficiently unique for each door lock, and it does not rule out that a manufacturer may choose

02828557.3 The first choice makes a simulation card absolutely unique for a given PECAD, or in the millions of door locks manufactured, there is a small possibility that a given key can open multiple door locks. Preferably, the encrypted marking and geographic distribution pattern of the simulated card/PECAD (for example in the same city or state) can be arranged so that the tiny possibility is minimized.

Since each simulation is fully and uniquely matched to a specific PECAD, even if a PECAD is stolen and the authentication mechanism is successfully bypassed by an individual who wants to deceive, the stolen PECAD still cannot be used to transfer the debit card data Write any arbitrary blank emulation card to conduct fraudulent transactions. As a further advantage, a given PECAD can only (after correct authentication) write to the simulation card that is fully and uniquely associated with it, thereby fully eliminating the situation that PECAD accidentally overwrites an existing debit card.

Figure 9 depicts a simplified block diagram of PECAD 902 in accordance with one aspect of the present invention. In Figure 9, a memory 904 is preferably non-volatile to prevent incorrect operation of the memory, and play the same function as the memory circuit in PEAD, except that the memory 904 can also be used to store one or the user's Encrypted debit card data related to multiple debit cards. The encryption logic 906 performs the same encryption/decryption/security functions as the encryption logic discussed in contact with PEAD. That is, access to the data stored in the memory 904, including the user's private key, the user's personal data, and the debit card data, is preferably only completed with the help of the encryption logic 906.

The authentication mechanism 908 performs the same function as the user authentication mechanism discussed in contact with PEAD. I/O circuit 910 represents a circuit that enables PECAD to communicate with a PEAD-enabled point-of-sale terminal, if it can be used to approve transactions. I have previously contacted PEAD to discuss transaction approval, so I wont discuss it in detail here. If it is expected that certain PECAD models do not communicate with a PEAD point-of-sale terminal and are only used to configure the emulation card for transactions with existing debit card facilities, the I/O circuit 910 can be omitted on these PECAD models.

The card read/write mechanism 912 represents a mechanism for writing the selected debit card data to the simulated card and erasing the simulated 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 in order to store the debit card data in the memory 904 (via encryption logic 906) . Note that the data read through the card read/write mechanism 912 is encrypted before being stored in the memory 904 by the logic 906

02828557.3 The first encryption. Similarly, the data stored in the memory 904 (for example, debit card data) is decrypted by the encryption logic 906 before being written to an emulation card through the card read/write mechanism 912.

Figure 10 is a simplified diagram of PECAD1002, in which a simulation card 1004« is placed, and the simulation card 1004 can be taken out of the slot 1006 in order to complete the transaction with an existing debit card reader. In the example of FIG. 10, the simulation card 1004 includes a magnetic stripe 1008 to simulate a magnetic stripe debit card. But as mentioned earlier, the emulation card 1004 can be configured to emulate any type of billing card interface, including IC contacts. The outline of a card read/write mechanism 1010 is displayed to indicate that it is part of PECAD 1002. Through the card read/write mechanism 1010, data can be read from an existing debit card or written to a simulated card. The keyboard 1015 can be used as an authentication mechanism as explained in 612 and 908. The user can enter a password or personal identification number to activate PECAD, so that the debit card data can be written to the simulation card 1004«, The approval button 1012 is substantially the same as the approval button 606 of FIG. 6A, and it can be used to approve a transaction through a PEAD-enabled point-of-sale terminal. On the other hand, the card button 1014 indicates the user's desire to complete the transaction through the simulated card. Card selector buttons 1016(a)-(d) are exemplary options that can be selected by the user to select a specific debit card that can be used to conduct transactions. A display 1018 can be used to display the debit card data of the selected debit card, such as the debit card number, expiration date, card holder's name, etc., so that the merchant can copy the information to complete the transaction if necessary.

According to another aspect of the present invention, by using PECAD to write an encrypted transaction number or other encrypted data encrypted with the user's private key (stored in PECAD's secure non-volatile memory) to the emulation card, it is further enhanced Improve transaction security. Figure 11 depicts this aspect of the invention according to an 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 simulation card. For example, if the emulation card emulates a magnetic stripe card, the encrypted transaction number can be written on an existing but unused magnetic track or a reserved magnetic track, for example, the magnetic track on the magnetic stripe

3. In step 1106, the software in the debit card reader can instruct the debit card reader to receive the encrypted transaction number, and then use a user that has been obtained from a trusted third party

02828557.3 The first public key authenticates the transaction number (step 1108); or in step 1106, the debit card reader reads the encrypted transaction number, and then the transaction number is sent to a credit settlement center, such as Master Card or Visa Card, and the credit settlement center can authenticate the user through a user public key that has been obtained from a trusted third party (step 1108). Usually some form of user identification can be sent to a trusted third party to help obtain Public key. For example, the user identification or public key identification can be read by a debit card reader and sent to a trusted third party to obtain the public key. The public key identification may be expressed as, for example, a unique pattern of public key bits (for example, the lowest 32 bits or 64 bits) that can be sent to a receiving location for public key search and decryption. If it is authenticated, the transaction is approved so that the merchant can issue goods/services to the user (step 1110).

As can be appreciated from the foregoing, the present invention basically does not require hardware changes to existing debit card readers and existing debit card facilities. The change only involves software changes. It instructs the existing debit card reader to read the encrypted transaction number and use a user public key obtained from a trusted third party to authenticate the encrypted transaction number.

In addition, there may not be any changes in the debit card reader. Instead, the credit settlement center software will be notified to use the user's public key obtained from a trusted third party to authenticate the encrypted transaction number. The debit card reader only needs to read all the data from the debit card or simulation card, and send all the information verbatim to the credit settlement center for approval. In this way, this implementation minimizes the need to make changes to existing debit card facilities (that is, changes only need to be made at one location in the credit settlement center, instead of reading the millions of debit cards in existence. At the card reader).

If additional security is required, the user can enter the transaction volume 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 to be received by the debit card reader, and decrypted with the user's public key in the credit settlement center, where the user's public key is also from a Obtained by a trusted third party. In this case, only when the transaction is the amount indicated in the encrypted and received transaction volume and/or the transaction occurs within a predetermined time period of the encrypted and received transaction time (before they The transaction approval is given only when it is written from PECAD to the simulation card). Therefore, even if the simulation card is stolen, other subsequent transactions are useless, even if the simulation actually occurs.

02828557.3 The first card is erased or reconfigured.

In Internet transactions, a user can use PEAD or PECAD to approve the transaction by encrypting the approved amount with his own private key stored in PEAD or PECAD. Thereafter, he may copy the displayed significant PEAD encrypted information shown on the display 610 or PECAD 1002, this information is preferably a human readable form, for example, an alphanumeric string, so that the user can easily read and entered manually (For example, by typing or by voice commands) to a computer connected via the Internet to conduct Internet transactions. If necessary, using PEAD or PECAD for secure Internet transactions can also encrypt information card numbers and transaction information. Of course, the manual input/key-in technology required for backward compatibility can also be replaced by other forms of data input, such as wireless or infrared communication through calculation and an appropriate port in PECAD (or PEAD). Make data transfer on the Internet.

As mentioned earlier, it is best to use the user's public key held by a trusted third party to determine the authentication of the user's identity. A trusted third party can represent, for example, any entity to which the public has a fairly high level of trust, such as an organization that is known to have its own interests and a credible reputation. Examples include government organizations, banks, large companies, etc.

The trusted party maintains a PECAD public key directory service, which connects the public key provided by the manufacturer with the user. When a user acquires a PECAD for the first time (for example, through purchase or an issuer's issue), the user can register his ownership of PECAD with a trusted third party. According to the security of the registration process, the user is assigned a confirmation level, which represents the credibility that the person who completed the registration is truly who he said.

For example, users can only provide personal information such as social security number, home address and home phone number, as well as PECAD serial number and public key signature (it is assigned by the manufacturer to a specific PECAD It can be read from PECAD by pressing the key of the specified sequence). Then the PECAD public key catalog center can use the PECAD serial number provided by the user as a unique search identifier to search for the public key in the database. Once it finds the public key, it will use the public key provided by the user to sign To enter with the public key in the database

02828557.3 Verification on line. If the verification is successful, the user can be registered, otherwise the user will be rejected. The public key should preferably be unique.

A safer way to register the ownership of a user can be as follows (this process usually occurs at the purchase of PECAD/PEAD or at the issuer, such as a bank). The issuer first activates PEAD/PECAD using the password provided by the manufacturer. After that, PEAD/PECAD users can use the user's password or other authentication mechanism to overwrite the password provided by the manufacturer. Then the user can instruct PEAD/PECAD to generate a new pair of private/public keys (called user private key and user public key) within PEAD/PECAD. The user can also instruct PEAD/PECAD to use the private key provided by the manufacturer pre-stored in PEAD/PECAD to encrypt personal information (such as social security information, home address, etc.) and a new user public key to generate a user registration message . The private/public key pair provided by this manufacturer can be generated by PEAD/PECAD when PEAD/PECAD is manufactured.

The issuer can then use the public key of the public key directory service center to encrypt the PEAD/PECAD serial number and user registration message to generate a registration message, and send the registration message to the public key directory service center. After receiving the registration message, the public key directory server can use its own private key to decrypt the registration message. Thereafter, the public key catalog service center can use the PEAD/PECAD serial number to search for the key provided by the manufacturer found in the database. If the decryption is successful, use the new user public key in the directory service database to update the public key provided by the manufacturer, and update the personal information in the directory service database, and use the minimum of personal name + phone number or public key A 32-bit (or 64-bit) public key ID is generated for future reference. On the other hand, if the decryption is unsuccessful, the user can be rejected.

This registration process generally conforms to a low level of confirmation, because someone other than the user may fraudulently obtain the users personal information for registration ownership (and once the registration is completed and PECAD is activated, the user will be Responsible for fraudulent accounting).

A medium level of confirmation can be obtained in the following ways: In addition to providing information for a low level of confirmation, providing information that provides a higher degree of trust that the person who provided the information is really the person he said. For example, the additional information can be from a photo,

02828557.3 The signature, the notary's seal or a combination of the above. A high level of confirmation can give even higher confidence in the information that the person who provided the information is really who he is talking about. For example, the registrant can personally appear in the PECAD public key catalog center to show a photo, a signature, a biometric sample (such as fingerprints, retina scans, DNA prints, etc.) or a combination of the above items.

Once the registration is completed, the credit settlement center or the merchant can consult the PECAD public key directory of a trusted third party in order to authenticate the user and approve the transaction.

The PECAD public key catalog can also be enhanced by establishing an insurance policy that protects merchants or credit settlement centers from financial losses due to fraud from a defective registration process. The coverage provided by the insurance policy can be measured according to the level of confirmation, with a higher level of confirmation corresponding to a higher amount of coverage.

Although the present invention has been described based on several preferred embodiments, there are modifications, substitutions, and equivalents that are within the scope of the present invention. It should be noted that there are many alternative methods for implementing the method and device of the present invention. For example, although the discussion here focuses on transaction approval, for those skilled in the art, it is obvious that PEAD can be used to conduct any type of transaction facing an electronic transaction system whenever a secure data transmission from a user to an electronic transaction system is desired. For example, PEAD can be used to log into highly sensitive computer systems or facilities. When implemented in this way, the computer terminal communicating with the PEAD can be equipped with an infrared port, a magnetic card reader port or a contact type plug for communicating with the PEAD. Then the user can use PEAD to perform any type of authentication task online.

Another example is that PEAD can be used to "sign" any computer file for authentication (for example, authentication date or user). The transaction approval data can then be saved with the file to be authenticated for future reference. Note that the transaction authentication data is also to prevent incorrect operation, so any transaction authentication data that is not encrypted with the user's private key will not be accepted as credible. In addition, it is obvious that if PEAD is only used to approve scheduled transactions, the transaction data can be stored in PEAD in advance, and it does not need to be received by PEAD from outside. Therefore, the following appended claims are intended to be understood as including all modifications, substitutions and equivalents within the true spirit and scope of the present invention.

02828557.3