Portable electronic authorization devices and methods therefor

A portable electronic authorization device for approving a transaction request originated from an electronic transaction system. The portable electronic authorization device includes first logic circuit configured to receive first digital data representative of the transaction request. There is further included second logic circuit configured to form second digital data responsive to the transaction request received by the first logic circuit if the transaction request is approved by a user of the portable electronic transaction device. The second digital data represents encrypted data signifying an approval by the user of the transaction request. Additionally, the portable electronic authorization device includes transmission circuitry coupled to the second logic circuit. The transmission circuitry is configured to transmit the second digital data from the portable electronic authorization apparatus to the electronic transaction system if the user approves the transaction request.

BACKGROUND OF THE INVENTION 
The present invention relates to methods and apparatus for conducting 
electronic transactions. More particularly, the present invention relates 
to portable electronic authorization devices (PEADs) which advantageously 
and substantially eliminate the security risks associated with prior art 
techniques of approving transactions between a user and an electronic 
transaction system. 
Electronic transaction systems are known. An electronic transaction system 
typically permits a user to conduct designated transactions 
electronically, which substantially improves efficiency and convenience to 
the user. Examples of electronic transactions include transactions 
conducted via computer networks, automated teller machines (ATM's), 
automated point-of-sale systems, automated library systems, and the like. 
Transactions conducted via computer networks may encompass a wide range of 
transactions, including exchanging information and data via a computer 
network popularly known as the Internet, e.g., to make a purchase from a 
vendor on the network. ATM's typically permit users to conduct financial 
transactions (such as withdrawals, transfers, deposits, and the like) 
vis-a-vis a financial institution in an electronic manner. Automated 
point-of-sale systems may be employed by merchants to permit users to 
purchase products or services using the users' electronic account, and 
automated library systems may be employed to permit library users to check 
out and return library materials. Other examples of electronic transaction 
systems are readily available in popular literature and are not enumerated 
herein for brevity sake. 
To enhance security to the user's account, electronic transaction systems 
typically request the user to provide identification data to authenticate 
himself as the user authorized to approve the proposed transaction or 
transactions. If the user fails to provide the requested identification 
data, the proposed transaction or transactions are not authorized and will 
not be processed. The identification data may be required with each 
transaction. By way of example, an automated point-of-sale system may 
require the user to approve a purchase transaction and will accept an 
approval message only if it is satisfied that the person approving the 
transaction has furnished adequate identifying data authenticating himself 
as the person authorized to perform the approval. Alternatively, the 
identification data may be entered by the user at the start of a session 
to authenticate himself and enable that user to subsequently perform any 
number of transactions without further authentication. 
In the prior art, users are typically required to manually enter the 
identification data into the electronic transaction system for 
authentication. Typically, the entry of identification data involves 
typing in a password on a numeric keypad or on a keyboard. The 
identification data is then compared with data previously stored within 
the electronic transaction system, and authentication is satisfied when 
there is a match. As mentioned previously, the transaction or transactions 
proposed will not be allowed to proceed if there is no match. 
Although prior art electronic transaction systems provide some protection 
from unauthorized access and use of the user's account, there are 
disadvantages. To illustrate certain disadvantages associated with prior 
art electronic transaction systems, reference may be made to FIG. 1 
herein. FIG. 1 shows an automated teller machine (ATM) 100, representing 
the requesting device of an electronic transaction system 102. Electronic 
transaction system 102 may include, for example, a central database 104 
which contains previously-stored identification data and account data of 
user 106. 
To initiate a typical transaction with ATM 100, user 106 first inserts a 
data card 107, such as a bank card or a credit card, into a card reader 
109. Data card 107 typically includes a magnetic stripe that contains the 
account number and other information related to the user, which may then 
be read by card reader 109. The data stored in data card 107 enables 
electronic transaction system 102 to ascertain which account in database 
104 user 106 wishes to transact business. 
Via a keypad 108 on ATM 100, user 106 may then be able to enter his 
identification data, e.g., his personal identification number (PIN), to 
authenticate himself. If the entered identification data matches the 
identification data stored with the account in database 104 that is 
identified by data card 107, the user is authenticated and granted access 
to his account. If there is no match, authentication fails. After 
authentication, user 106 may be able to, for example, employ a combination 
of keypad 108 and a screen 110 to withdraw cash from his account, which 
results in cash being dispensed from ATM 100 and the balance in his 
account within database 104 correspondingly reduced. 
Theoretically, the identification data entered into ATM 100 should be 
secure. In reality, there are many potential security risks to the 
identification data in prior art authentication techniques. Since the 
identification data is not encrypted before being entered into ATM 100, 
the non-encrypted identification data is vulnerable to unauthorized access 
and procurement. Encryption of the identification data is not practical in 
the prior art since it would have been too complicated and/or inconvenient 
for the user to perform encryption or memorize the encrypted 
identification data. Unauthorized procurement of the identification data 
in the prior art may occur, for example, upon entry if it is inadvertently 
seen by another party, e.g., by another person behind user 106, either on 
screen 110 or more likely at keypad 108. 
Even if encryption is employed on the identification data in the prior art, 
e.g., prior to transmission from ATM 100 to database 104, the encryption 
typically occurs within ATM 100 and still requires the entry of 
non-encrypted identification data from user 106 and the existence of the 
identification data for some duration of time in ATM 100. Unauthorized 
access to the identification data may then occur if an unauthorized party 
is able to gain entry into ATM 100 and intercepts, e.g., via software or 
hardware implemented in ATM 100, the non-encrypted identification data 
therein. 
Furthermore, if public key cryptography is employed within ATM 100, the 
storage of the user's private key within ATM 100 renders this private key 
vulnerable to theft, further exposing the user's account to risk. The 
stolen password and/or private key may then be employed to allow 
unauthorized persons to access the user's account to the user's detriment. 
In view of the foregoing, there are desired apparatus and methods for 
conducting transactions with the electronic transaction system while 
substantially eliminate the risk of unauthorized access to the user's 
account and unauthorized procurement of the user identification data. 
Preferably, such an apparatus should be easily portable to permit the user 
to conveniently and comfortably perform transaction authentication 
anywhere. 
SUMMARY OF THE INVENTION 
The present invention relates, in one embodiment, to a method in a portable 
electronic authorization device for approving a transaction request 
originated from an electronic transaction system. The method includes 
receiving at the portable electronic authorization device first digital 
data, the first digital data representing the transaction request. The 
method further includes transmitting a second digital data to the 
electronic transaction system if the transaction request is approved by a 
user of the portable electronic authorization device. The second digital 
data is encrypted by circuitries within the portable electronic 
authorization device and signifies the user's approval of the transaction 
request. 
In another embodiment, the invention relates to a portable electronic 
authorization device for approving a transaction request originated from 
an electronic transaction system. The inventive portable electronic 
authorization device includes first logic circuit configured to receive 
first digital data representative of the transaction request. There is 
further included second logic circuit configured to form second digital 
data responsive to the transaction request received by the first logic 
circuit if the transaction request is approved by a user of the portable 
electronic transaction device. The second digital data represents 
encrypted data signifying an approval by the user of the transaction 
request. Additionally, the inventive portable electronic authorization 
device includes transmission circuitry coupled to the second logic 
circuit. The transmission circuitry is configured to transmit the second 
digital data from the portable electronic authorization apparatus to the 
electronic transaction system if the user approves the transaction 
request. 
These and other advantages of the present invention will become apparent 
upon reading the following detailed descriptions and studying the various 
figures of the drawings.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
FIG. 2 illustrates, in accordance with one embodiment of the present 
invention, a portable electronic authorization device (PEAD) 200, 
representing the apparatus for securely approving transactions conducted 
vis-a-vis an electronic transaction system. With reference to FIG. 2, 
requesting device 202 may initiate a transaction approval process with 
PEAD 200 by transmitting to PEAD 200, via communication port 204, a 
transaction request pertaining to a proposed transaction. Requesting 
device 202 may represent, for example, an ATM machine, a computer terminal 
in a network, an automated library check-out terminal, or similar devices 
for permitting the user to transact business with the electronic 
transaction system. The proposed transaction may be, for example, a sale 
transaction of a particular item for a certain amount of money. The 
transaction request itself may include, for example, the transaction ID, 
the merchant's name, the merchant's ID, the time of the proposed purchase, 
and the like. In one embodiment, the transaction request from requesting 
device 202 may be encrypted for enhanced security but this is not 
required. Data pertaining to the proposed transaction reaches PEAD 200 via 
path 206 in FIG. 2. 
Port 204 may represent an infrared port to facilitate infrared 
communication with PEAD 200. Alternatively, port 204 may represent a 
wireless port for facilitating wireless communication. 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 plugging PEAD 
200 into port 204 to facilitate communication. Other techniques to 
facilitate communication between requesting device 202 and PEAD 200 are 
readily appreciable to those skilled. 
The data pertaining to proposed transaction(s) may then be reviewed by the 
user, either on a screen 208 of requesting device 202 or optionally on a 
display screen provided with PEAD 200 (not shown in FIG. 2). If the user 
approves the transaction, e.g., a purchase of an item for a given amount 
of money, the user may then signify his approval by activating a switch 
210 on PEAD 200, which causes an approval message to be created with the 
user's identification data, encrypted and transmitted back to requesting 
device 202 via path 212. If the transaction is not approved, the user may 
simply do nothing and let the transaction request times out after an 
elapsed time or may activate another switch on PEAD 200 (not shown in FIG. 
1), which causes a reject message, either encrypted or non-encrypted, to 
be transmitted back to the requesting device 202 via path 212. 
The present invention is different from the prior art technique of FIG. 1 
in that the user is required in the prior art to enter his identification 
data into the electronic transaction system, e.g., into ATM 100, to 
authenticate himself. In contrast, the present invention keeps the 
identification data related to the user secure within PEAD 200 at all 
times. Transaction approval occurs within PEAD 200, and the data 
representing such approval is encrypted, again within PEAD 200, prior to 
being transmitted to the electronic transaction system, e.g., to 
requesting device 202 in FIG. 2. 
Accordingly, even if the approval data is intercepted, its encryption would 
prevent unauthorized users from employing the identification data for 
illicit purposes. If public key cryptography is employed to encrypt the 
approval data, the user's private key is also always kept within PEAD 200. 
Since the user's private key is required for encryption and is unknown to 
others, even to the electronic transaction system in one embodiment, the 
encrypted approval data, if intercepted, would be useless to unauthorized 
third parties even if the approval data can be deciphered using the user's 
public key. Again, this is different from prior art authentication 
techniques wherein encryption takes place within the electronic 
transaction system and requires the entry of the identification data 
and/or reading the user's private key from the ID card such as an ATM 
card, a credit card, and the like. As mentioned earlier, the fact that the 
prior art electronic transaction system requires this identification data 
and/or user's private key exposes these data to risks, e.g., if the 
requesting device is not secure or open to data interception via software 
or hardware. 
As another difference, the present invention employs the circuitries within 
the portable electronic authorization device (PEAD) to perform the 
approval and encryption of the transaction approval data with in the PEAD 
itself. In contrast, prior art data cards are essentially passive devices. 
For example, prior art ATM cards or credit cards only has a magnetic 
stripe for storing account information and do not have any facility to 
perform approval and/or encryption of the transaction approval data. While 
smart cards or IC cards, which are currently being developed, may contain 
electronic circuitries, current standards for their implementation still 
requires a reader associated with the requesting device to read out the 
identification data and/or user's private key in order for the requesting 
device to perform any approval and/or encryption. A s mentioned earlier, 
the transmission of these data to the requesting device unnecessarily 
exposes these data to risks of theft and/or unauthorized interception once 
transmitted. 
It should be borne in mind at this point that although public key 
cryptography is discussed throughout this disclosure to facilitate ease of 
understanding and to highlight a particular aspect of the invention, the 
overall invention is not limited to any particular cryptography algorithm 
and may be implemented using any conventional cryptography technique, 
including public key cryptography algorithms such as RSA, Diffie-Hellman, 
other discrete logarithm systems, elliptic curve systems, or the like. For 
additional information on some of the different public key cryptography 
techniques, reference may be made to, for example, the IEEE P1363 Working 
Draft dated Aug. 22, 1996, available from IEEE Standards Dept. 345 East 
7th Street, New York, N.Y. 10017-2349. 
As mentioned, transaction approval in the prior art occurs within the 
electronic transaction system. In contrast, the present invention allows 
transaction approvals to occur within PEAD 200. The fact that transaction 
approvals occur entirely within PEAD 200 provides many advantages. By way 
of example, this feature eliminates the need to have, in one embodiment, 
the identification data and/or the user's private key in the requesting 
device. The fact that transaction approvals occur entirely within PEAD 200 
(using the user identification data and/or the user's private encryption 
key that are always kept secure within PEAD 200) substantially enhances 
the confidentiality of the user identification data and the user's private 
key, as well as the integrity of the transaction approval process. 
Since approval occurs entirely within PEAD 200, the user identification 
data that is employed to authenticate transactions may be more complicated 
and elaborate to ensure greater security. By way of example, the user 
identification data may be more elaborate than a simple password and may 
include any of the user's name, his birth date, his social security 
number, or other unique biometrics or unique identifying data such as 
fingerprint, DNA coding sequence, voice print, or the like. In contrast, 
prior art authentication techniques limit the user identification data to 
simple patterns, e.g., simple password of few characters, that are easily 
memorized by the user since more elaborate identification data may be too 
difficult to remember or too cumbersome to manually enter. Furthermore, 
even if the complicated ID data may be stored in the prior art data card, 
it is still required to be read into the requesting device of the 
electronic transaction system, again exposing this data to interception or 
theft once read. 
Additional safeguards, which will be described in detail herein, may also 
be provided to prevent access, whether electronically or by physical 
means, to the user identification data and/or the user's private key 
within PEAD 200. Since the identification data and/or the user's private 
key are never exposed, security risks to the these data are substantially 
minimized. 
FIG. 3A shows, in one embodiment of the present invention, a simplified 
schematic of PEAD 200 of FIG. 2, including switch 210. Data path 206 is 
provided for receiving transaction requests from the electronic 
transaction system, and data path 212 is provided for transmitting 
transaction approval data back to the electronic transaction system. It 
should be borne in mind that although two data paths are discussed herein 
for ease of understanding, these data paths and other data paths herein 
may, in one embodiment, represent logical data paths and may be 
implemented via a single physical data connection. Likewise, the different 
ports herein may represent, in one embodiment, logical data ports for ease 
of understanding and may in fact be implemented using a single physical 
port. 
When a transaction request, e.g., a withdrawal transaction from an ATM 
machine in the amount of $200.00, is transmitted via data path 206 to PEAD 
200, this transaction is received by encryption logic 300. At this point, 
the user may review the proposed transaction, e.g., via the display screen 
provided with the electronic transaction system and/or PEAD 200, and has a 
choice to either approve or disapprove the proposed transaction. If the 
user approves the transaction, he may, in one embodiment, activate a 
switch 210, which causes the transaction approval data to be created and 
then encrypted by encryption logic 300 prior to being transmitted back to 
the electronic transaction system via path 212. 
Note that the user identification data block 302, which is employed in the 
transaction approval process, is not directly coupled to paths 206 and 
212. In other words, the memory portion storing the user identification 
data is intentionally decoupled from the input and output ports of PEAD 
200 to prevent direct access thereto. 
If access to user identification data 302 is desired, e.g., to approve a 
transaction, the access can only be made by encryption logic block 300. 
Likewise, it is not possible to directly access the memory portion 304, 
which stores the user's private key. If access to user's private key 304 
is desired, e.g., to encrypt the transaction approval data, the access can 
only be made by encryption logic block 300. It should be borne in mind 
that although user identification 302 and user's private key 304 are shown 
stored in different memory portions, such illustration is made for ease of 
understanding and both of these may in fact be stored, in one embodiment, 
at different addresses on the same memory module. 
In some cases, the transaction approval data requires the inclusion of 
certain pieces of identification data 302. For example, a transaction 
embodied in the transaction request from the electronic transaction system 
may be appended with data representative of an "electronic signature" 
prior to being encrypted and retransmitted back to the electronic 
transaction system. FIG. 3B shows, in one embodiment, the format of 
representative transaction approval data 350. With reference to FIG. 3B, 
transaction data 352, representing a portion of or the entire transaction 
request received from the electronic transaction system, is appended with 
certain user identification data 354 and optionally a time stamp 356. The 
formation of transaction approval data 350 only occurs if the transaction 
request has already been approved by the user. Once appended, transaction 
approval data 350 is then encrypted prior to being retransmitted back to 
the electronic transaction system. 
In some cases, it may be desirable to encrypt the transaction request prior 
to transmission to the PEAD to further enhance security. For example, 
certain transaction partners, e.g., vendors or other users on the computer 
network, may wish to keep the information within a transaction request 
confidential and may prefer to encrypt the transaction request before 
furnishing it to the PEAD. Data encryption is also desirable when, for 
example, the user identification data and the user's private key is 
written into a blank PEAD for the first time to configure a PEAD that is 
unique to a given user. The configuration data pertaining the user 
identification data and the user's private key, while must be written only 
once into PEAD 200 by the issuer of PEAD 200, is preferably encrypted to 
render them less vulnerable to theft. Issuers of PEAD 200 may represent, 
for example, credit card issuers, the government, or any other institution 
with whom the user maintains an account. 
FIG. 4 illustrates, in accordance with one embodiment of the present 
invention, a schematic of PEAD 200 of FIG. 2. The PEAD 200 of FIG. 4 
further employs decryption logic for receiving the encrypted configuration 
data and optionally the encrypted transaction requests. In FIG. 4, 
encryption logic 300, user's private key 304, and data paths 206 and 212 
are arranged and function substantially as discussed in connection with 
FIG. 3A. 
Transaction requests are normally non-encrypted, i.e., they are received 
and processed in the manner discussed in connection with FIG. 3A. For 
highly sensitive transactions, however, the transaction requests may be 
encrypted and transmitted to PEAD 200 via data path 206 and input into 
decryption logic 402 to be decrypted. If a public key cryptography is 
employed, the encrypted transaction requests may be decrypted with a 
transaction partner public key 404. 
Once decrypted, the transaction request is then displayed to the user for 
approval. The transaction approval data may be furnished to encryption 
logic 300 via path 406 to be encrypted if approved, e.g., responsive to 
the activation of switch 210. The encryption is preferably performed with 
the user's private key 304 if a public key cryptography technique is 
employed, and the encrypted transaction approval data is then transmitted 
back to the electronic transaction system via data path 212. 
As configuration data typically includes sensitive user identification data 
and user's private key, it is often encrypted prior to being transmitted 
to PEAD 200 via data path 408. The encrypted configuration data is 
received by decryption logic 402 and decrypted therein prior to being 
written into user identification data block 410 and user's private key 
block 304. If public key cryptography is employed, the encrypted 
configuration data may be encrypted by the issuer's private key in the 
electronic transaction system prior to transmission and decrypted once 
received by PEAD 200 with an issuer public key 412. 
Note that once the configuration data is decrypted and written into user 
identification data block 410 and user's private key block 304, the user 
identification data and user's private key can only be accessed 
subsequently by encryption logic 300. Also note that there is no direct 
connection from any of the I/O data paths, e.g., data path 206, 212, or 
408, to user identification data block 410 as well to user's private key 
block 304. Advantageously, the sensitive user identification data and 
user's private key therein are not susceptible to access from outside once 
written into respective blocks 410 and 304 (which may, in one 
implementation, simply represent memory blocks in PEAD 200's memory). 
Additionally, the user identification data and the user's private key 
cannot be updated by those not having the issuer's private key. As 
represented in FIG. 4, data can only be written into user's private key 
block 304 and user identification block 410 after it is decrypted via 
decryption logic 402 with issuer public key 412. Accordingly, unless the 
updated configuration data has been encrypted using the issuer's private 
key (which is presumably highly secure), the updated configuration data 
will not be decrypted and written into respective blocks 304 and 410. Of 
course if the configuration data within blocks 304 and 410 cannot be 
updated physically, e.g., they are stored using memory that can be written 
only once such as PROM (programmable read-only memory), WORM (write once, 
read many), or the like, the security consideration associated with 
unauthorized alteration of configuration data is substantially eliminated. 
If a greater level of security is desired, the user's private key may be 
optionally be scrambled or randomized prior to being written into user's 
private key block 304 by optional scrambler/descrambler logic 413. 
Scrambler/descrambler logic 413 may, in one embodiment, receive the user's 
private key, which is furnished by the institution that issues PEAD 200 to 
the user, and scrambles and/or randomizes it to generate yet another 
user's private key and a corresponding user's public key. This 
scrambled/randomized user's private key is then stored in user's private 
key block 304, which is now unknown even to the issuer of PEAD 200, and 
the corresponding user's public key may be made known to the issuer and/or 
the transaction partners to facilitate transactions. Advantageously, there 
is no other copy of the scrambled/randomized user's private key anywhere 
else beside within user's private key block 304. 
In an alternative embodiment, there may be employed an optional key 
generation logic 414 which, responsive to a request from the issuing 
institution, generates the user's private key and the user's public key on 
its own, i.e., without first requiring the receipt of a user's private key 
from the issuing institution and randomizing it. The generated user's 
private key is then stored in private key block 304 and the public key is 
made known to the issuing institution and/or the transaction partners to 
facilitate transactions. In this manner, no version of the user's private 
key, whether randomized or not, exists outside the PEAD itself. As can be 
appreciated by those skilled in the art, the use of key generation logic 
414 further enhances the confidentiality of the user's private key. 
FIG. 5A represents, in accordance with one embodiment of the present 
invention, a high level hardware implementation of PEAD 200. As shown in 
FIG. 5A, PEAD 200 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), or the like, for implementing encryption logic 300 of FIG. 
2 and optionally decryption logic 402 of FIG. 4. 
Program/data memory 504 stores, among others, the codes which operate PEAD 
200 as well as the user identification data and the user's private key. 
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. Temporary memory 506 serves as a scratch pad 
for calculation purposes and for temporary storage of data, and may be 
implemented using some form of random access memory (RAM) such as static 
RAM or dynamic RAM, which are known in the art. Alternatively, either 
optical memory, magnetic memory, or other types of memory may be employed 
to implement program/data memory 504 and/or temporary memory 506. 
A bus 508 couples program/data memory 504 and temporary memory 506 with 
logic circuitry 502. Communication port 510 represents the communication 
gateway between PEAD 200 and the 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 transmission, or the like. Communication port may also represent, in 
one embodiment, a PC card port (popularly known to those skilled as a 
PCMCIA card). Data path 206 inputs transaction requests into logic 
circuitry 502 while data path 212 outputs transaction approval data from 
logic circuitry 502 to the electronic transaction system. Optional data 
path 408, which has been described in FIG. 4, inputs configuration data 
into PEAD 200 to write the user identification data and the user's private 
key into program/data memory 504 to uniquely configure PEAD 200 to a 
particular user. 
Again, note that access to program/data memory 504 and the data therein 
(e.g., the user identification data and the user's private key) can only 
be made by logic circuitry 502. For example, the user identification data 
and the user's private key can only be written into program/data memory 
504 if this data has been properly encrypted with the issuer's private 
key. Access to these memory blocks for writing thereto may also be 
restricted by logic circuitry 502 under appropriate software and/or 
firmware control. 
Similarly, reading the user identification data and accessing the user's 
private key can only be accomplished via the encryption logic of logic 
circuitry 502. The advantages to security of this aspect has been 
discussed in connection with FIGS. 3A and 4, the most important point 
being there is preferably no direct access to the sensitive user 
identification data and user's private key from the outside. Consequently, 
the confidentiality and security of these data items are greatly enhanced 
with the inventive design. 
Some type of power source, such as a battery, may be provided as well. If 
PEAD 200 is implemented as a single-chip design, i.e., substantially all 
components shown in FIG. 5A are fabricated on a single die, then power is 
external to the die itself. If contact-type communication is employed, 
e.g., if PEAD 200 must be plugged into the electronic transaction system 
to conduct transactions, power external to the entire PEAD may be employed 
for transaction approvals when plugged in, thereby eliminating the size, 
weight, and cost penalties associated with having a battery onboard the 
portable transaction apparatus. 
In one embodiment, PEAD 200 may be implemented using a general purpose 
portable computing device, such as any of the miniaturized portable 
computers or personal digital assistants (PDA's) that are currently 
popular. A PDA such as the Apple Newton.RTM., for example, may be employed 
to implement PEAD 200. 
FIG. 5B illustrates one implementation of a PEAD wherein the circuitries 
are implemented on an IC. In FIG. 5B, components having like reference 
numbers to components in FIG. 5A have similar functions. Data paths 408, 
206, and 212, which have been described in connection with FIG. 5A, is 
coupled to a serial I/O circuit 520, which facilitates data transmission 
and receipt in a serial manner on data path 522 between PEAD 200 and the 
electronic transaction system. Vcc pin 524 and ground pin 526, which 
provide power to PEAD 200 of FIG. 5B, are also shown. 
FIG. 5C represents an external view of the PEAD of FIG. 5B after being 
embedded in a card-like package for ease of carrying and insertion into a 
serial I/O port of the electronic transaction system. Card 550, which 
embeds the integrated circuit implementing the inventive PEAD, includes, 
in one embodiment, four external contacts. External serial contacts 552 
and 554 carry data and ground respectively to facilitate serial 
communication with a serial device of an electronic transaction system. 
External Vcc contact 524 and external ground contact 526, which supply 
power to the PEAD as discussed in connection with FIG. 5A, are also shown. 
When card 550 is inserted into an electronic transaction system, it is 
powered through external contacts 524 and 526, thereby enabling the PEAD 
circuitries therein to receive transaction requests via external serial 
contacts 552 and 554, approve the requests within the PEAD if appropriate, 
encrypt transaction approval data within the PEAD circuitries, and 
serially communicate the encrypted transaction approval data to the 
electronic transaction system via external serial contacts 552 and 554. 
FIG. 6A represents an external view of a PEAD in accordance with a 
preferred embodiment of the present invention. PEAD 200 of FIG. 6A is 
preferably implemented as a small, self-containing package that is 
sufficiently ruggedized for daily use in the field. Preferably, PEAD 200 
of FIG. 6A is small enough to be comfortably carried with the user at all 
times, e.g., as a key chain attachment or a small package that can easily 
fit inside a purse or a wallet. The physical enclosure of PEAD 200 is 
preferably arranged such that the content will be tamper-proof (i.e., if 
it is opened in an unauthorized manner then the user's private key and/or 
the user identification data will be destroyed or the PEAD will no longer 
be able to approve transactions). By way of example, the enclosure may be 
arranged such that if it is opened, there is a change in the flow of 
current in a current path, e.g., either the existing current flow is 
interrupted or a current path that has been idle starts to flow. The 
change in the flow of current may then force RESET. 
There is shown an infrared communication port 602 for receiving and 
transmitting data vis-a-vis the electronic transaction system. A small 
on/off switch 604 permits the user to turn off the PEAD to conserve power 
when not in use. Approve button 606 permits the user to signify approval 
of a proposed transaction. Optional skip button 608 permits the user to 
indicate rejection of a particular transaction. Skip button 608 may be 
omitted since a transaction request may be understood, in some embodiment, 
as not being approved if approve button 606 is not activated within a 
given period of time after receiving the request. 
Optional display 610 may be implemented using any type of display 
technology such as liquid crystal technology. Displays 610 displays, among 
others, the transaction being proposed for approval. Display 610 may be 
omitted if desired, in which case the transaction may be viewed, for 
example, at a display associated with the electronic transaction system 
itself. Optional user authentication mechanism 612 prevents PEAD 200 from 
being used for approving transactions unless the user is able to identify 
himself to PEAD 200 as the rightful and authorized user. Optional user 
authentication mechanism 612 may require the user to enter a password, to 
furnish a fingerprint or a voice print, or other biometrics and/or 
identifying characteristics specific to the authorized user before PEAD 
200 can be activated and employed for approving transactions. 
FIG. 6B illustrates, in a simplified manner and in accordance with one 
aspect of the present invention, the hardware for implementing PEAD 200 of 
FIG. 6A. Battery 652 provides power to the circuitry of PEAD 200. A 
microcontroller 654 executes codes stored in flash memory 656 and employs 
random access memory 658 for the execution. In one embodiment, 
microcontroller 654, flash memory 656, and even random access memory 658 
may be implemented on a single chip, e.g., a NC68HC05SCXX family chip from 
Motorola Inc. of Schaumburg, Ill. such as the NC68HC05SC28. Approve button 
606 and optional skip button 608 are coupled to microcontroller 654 to 
permit the user to indicate approval or rejection of a particular 
transaction displayed using display circuitry 660. Communication to and 
from the electronic transaction system is accomplished under control of 
microcontroller 654 via an infrared transceiver 662. Power switch 664 
permits the user to power off PEAD 200 when not in use to conserve power 
and to prevent accidental approval. 
FIG. 7 is a flowchart illustrating, in accordance with one aspect of the 
present invention, the approval technique employing the inventive PEAD. In 
step 702, a transaction request is received at the PEAD from the 
requesting device associated with the electronic transaction system. In 
step 704, the user has the option whether to approve or disapprove the 
transaction proposed. If not approved, e.g., either by activating the skip 
button of the PEAD or simply allowing the request to time out, nothing 
will be done. 
On the other hand, if the user approves the proposed transaction, the user 
may activate the approve button to create transaction approval data. The 
transaction approval data is then encrypted in step 708 within the PEAD. 
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 flowchart illustrating, in accordance with one aspect of the 
present invention, the steps involved in encrypting transaction approval 
data using public key cryptography. In step 802, the transaction approval 
data package is created. As discussed earlier in connection with FIG. 3B, 
the transaction approval data may be created by appending any necessary 
user identification data to a portion of or the entire transaction 
request. Optionally, a time stamp may also be appended thereto. In step 
804, the transaction approval data is encrypted using the user's private 
key, which is preferably kept secured at all times within the PEAD. 
Thereafter, the encrypted transaction approval data is transmitted back to 
the electronic transaction system. 
In accordance with one aspect of the present invention, it is recognized 
that even if the encrypted transaction approval data is intercepted and 
decrypted for analysis by a third party, it is not possible to bypass the 
security features of the invention as long as the user's private key or 
the user identification data is secure. As mentioned earlier, since the 
user identification data is not accessible externally, it is always secure 
within the PEAD. This is unlike the prior art wherein the user is required 
to enter the identification data, e.g., password, at the electronic 
transaction system and risks exposure of this sensitive data. 
Even if the user identification data is compromised, transaction approval 
still cannot take place unless there is possession of the user's private 
key. It would be useless to intercept the encrypted transaction approval 
data even if one can decrypt it using the user's public key since the 
transaction partner, e.g., the merchant requesting approval of the 
transaction, will not accept any transaction approval data not encrypted 
using the user's private key. Again, since the private key is not 
accessible externally, it is always secure within the PEAD. This aspect of 
the invention has great advantages in performing on-line transactions 
since the user's private key no longer has to be stored in a vulnerable 
computer file in a workstation, which may be accessible by other parties 
and may be difficult to conveniently tote along for other authentication 
tasks. 
The fact that the PEAD is implemented in a small, portable package makes it 
convenient and comfortable for the user to maintain the PEAD within his 
possession at all times. Even if the PEAD is physically stolen, however, 
the optional user authentication mechanism, e.g., user authentication 
mechanism 612 of FIG. 6A, provides an additional level of protection and 
renders the PEAD useless to all but the properly authenticated user. Of 
course the user can always notify the issuer of the PEAD if the PEAD is 
stolen or lost, and the issuer can inform transaction partners 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 the time stamp, the 
merchant's name, the amount approved, and other relevant data also 
enhances the integrity of the transaction approval process. If the 
merchant inadvertently or intentionally submits multiple transaction 
approvals to the issuer, the issuer may be able to recognize from these 
data items that the submissions are duplicates and ignore any duplicate 
transaction approval data. For example, the issuer may recognize that is 
it unlikely for a user to purchase multiple identical dinners at the same 
restaurant at a given time and date. 
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 also be noted that 
there are many alternative ways of implementing the methods and 
apparatuses of the present invention. By way of example, while the 
discussion herein has focused on transaction approvals, it should be 
apparent to those skilled that the PEAD may be employed to conduct any 
kind of transaction vis-a-vis an electronic transaction system any time 
secured data transmission from the user to the electronic transaction 
system is preferred. For example, the PEAD may be employed for logging 
into highly sensitive computer systems or facilities. When so implemented, 
the computer terminal with which the PEAD communicates may be equipped 
with an infrared port, a magnetic reader port, or a contact-type plug for 
communication with the PEAD. The user may then employ the PEAD to perform 
any type of authentication tasks online. 
As a further example, the PEAD may be employed to "sign" any computer file 
for authentication purposes (e.g., to authenticate the date or the user). 
The transaction approval data may then be saved along with the file to be 
authenticated for future reference. Note that the transaction 
authentication data is again tamper-proof since any transaction 
authentication data not encrypted using the user's private key will not be 
accepted as authentic. Also, it should be apparent that if the PEAD is 
employed to approve only predefined transactions, the transaction data may 
be stored in advance within the PEAD and do not need to be received from 
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.