Skip to main content

Full text of "USPTO Patents Application 10088784"

See other formats


WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) . 



(51) International Patent Classification 6 : 
H04K 1/00 



A2 



(11) International Publication Number: WO 99/05813 

(43) International Publication Date: 4 February 1999 (04.02.99) 



(21) International Application Number: PCT/US98/ 15036 

(22) International Filing Date: 21 July 1998 (21.07.98) 



(30) Priority Data: 
08/899,277 



23 July 1997 (23.07.97) 



US 



(71) Applicant: VISTO CORPORATION [US/US]; 1937 Landings 

Drive, Mountain View, CA 94043 (US). 

(72) Inventor: RIGGINS, Mark, D.; 5818 Moraga Avenue, San 

Jose, CA 95123 (US). 

(74) Agents: SOCKOL, Marc, A. et al.; Graham & James LLP, 600 
Hansen Way, Palo Alto, CA 94304-1043 (US). 



(81) Designated States: CA, CN, IL, JP, SG, Eurasian patent (AM, 
AZ, BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, 
BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, 
MC, NL, PT, SE). 



Published 

Without international search report and to be republished 
upon receipt of that report. 



(54) Title: SYSTEM AND METHOD FOR USING AN AUTHENTICATION APPLET TO IDENTIFY AND AUTHENTICATE A USER 
IN A COMPUTER NETWORK 




(57) Abstract 

The system includes a server coupled via a computer network to a client. Upon receiving a request for access, the server sends 
an authentication applet to the client The authentication applet includes a user identification (ID) module for obtaining a user ID and a 
password module for obtaining a client password. The authentication applet also includes a response generator coupled to the password 
module for using the client password as a variable in an algorithm to compute a client response. The authentication applet further includes 
a communications module coupled to the response generator and to the user ID module for sending the client response and the user ID back 
to the server for verifying the response and authenticating the user. The client uses an applet engine to execute the applet. The server uses 
the user ID to retrieve user information, and uses the user information as a variable in an algorithm to generate a verification response. If 
the verification response is the same as the client response, then the identity of the user is verified and access may be granted. 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


SZ 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Paso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HTJ 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


Bj 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


CI 


Cote d'l voire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






cu 


Cuba 


KZ 


Kazalcstan 


RO 


Romania 






cz 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







WO 99/05813 PCT/US98/15036 
SYSTEM AND METHOD FOR USING AN AUTHENTICATION APPLET TO 
IDENTIFY AND AUTHENTICATE A USER IN A COMPUTER NETWORK 



BACKGROUND OF THE INVENTION 
5 1. Field of the Invention 

This invention relates generally to computer networks, and more particularly to a 
system and method for securing access to services in a computer network. 



2. Description of the Background Art 
10 In its infancy, the Internet provided a research-oriented environment where users 

and hosts were interested in a free and open exchange of information, and where users and 
hosts mutually trusted one another. However, the Internet has grown dramatically, 
currently interconnecting about 100,000 computer networks and several million users. 
Because of its size and openness, the Internet has become a target of data theft, data 
15 alteration and other mischief. 

Virtually everyone on the Internet is vulnerable. Before connecting to the Internet, 
companies balance the rewards of an Internet connection against risks of a security breach. 
Current security techniques help provide client and server authentication, data 
confidentiality, system integrity and system access control. 
20 The most popular of the current security techniques is a firewall, which includes an 

intermediate system positioned between a trusted network and the Internet. The firewall 
represents an outer perimeter of security for preventing unauthorized communication 
between the trusted network and the Internet. A firewall may include screening routers, 
proxy servers and application-layer gateways. 



WO 99/05813 PCT/US98/15036 

For users on the internet to access protected services on the trusted network, they 
may be required to provide their identity to the firewall by some means such as entering a 
password or by computing a response to a challenge using a hardware token. With proper 
authentication, the user is allowed to pass through the firewall into the local network, but 
5 is typically limited to a predetermined set of services such as e-mail, FTP, etc. 

Some local network managers place just outside the firewall a server, often referred 
to as a "sacrificial lamb" for storing non-confidential data which is easily accessible by the 
remote user but providing little security. 

A De-Militarized Zone, or DMZ, sits between two firewalls protecting a trusted 
10 network. The external firewall protects servers in the DMZ from external threats while 
allowing HyperText Transfer Protocol (HTTP) requests. The internal firewall protects the 
trusted network in the event that one of the servers in the DMZ is compromised. Many 
companies use DMZs to maintain their web servers. 

Another security technique for protecting computer networks is the issuance and 
15 use of public key certificates. Public key certificates are issued to a party by a certificate 
authority, which via some method validates the party's identity and issues a certificate 
stating the party's name and public key. As evidence of authenticity, the certificate 
authority digitally signs the party's certificate using the certificate authority's private key. 
Thus, when a user via a client computer connects to a server, the client computer 
20 and server exchange public key certificates. Each party verifies the authenticity of the 
received certificates by using the certificate authority's public key to verify the signature 
of the certificate. Then, by encrypting messages with the server's public key the user can 
send secure communications to the server, and by encrypting messages with the user's 
public key the server can send secure communications to the user. Although any party 



WO 99/05813 PCT/US98/15036 

might present a public key certificate, only the real user and the real host have the 
corresponding private key needed to decrypt the message. Examples of authentication and 
key distribution computer security systems include the Kerberos™ security system 
developed by the Massachusetts Institute of Technology and the NetSP™ security system 
5 developed by the IBM Corporation. 

These security techniques cause problems for the roaming (traveling) user. The 
roaming user must maintain identification and authentication information such as 
passwords, certificates, keys, etc. and carry hardware tokens for responding to system 
challenges. Therefore, a system and method are needed for authenticating a roaming user 
10 easily and securely. 

SUMMARY OF THE INVENTION 
The present invention provides a system and method for authenticating the identity 
of a user in a computer network. The network system includes a server coupled via a 
computer network to a client. Upon receiving a request for access, the server sends an 

15 authentication applet to the client. The authentication applet includes a user identification 
(ID) module for obtaining a user ID and a password module for obtaining a client 
password. The authentication applet also includes a response generator coupled to the 
password module for using the client password as a variable in an algorithm to compute a 
client response. The authentication applet further includes a communications module 

20 coupled to the response generator and to the user ID module for sending the client 
response and the user ID back to the server for user authentication. The client uses an 
applet engine to execute the applet. The server uses the received user ID, the response and 
possibly user information to verify the identity of the user. 



WO 99/05813 PCT/US98/15036 

The method includes the steps of receiving a service request from a client, 
delivering to the client an authentication applet which when executed by the client uses 
client input as a variable in an algorithm to compute a response, receiving the response and 
a user ID from the client, and verifying the response. Verifying the response includes 
using the user ID and the challenge and possibly user information to verify the user. 

It will be appreciated that the system and method of the present invention never 
send the password itself across the computer network and thus never compromise the 
password by transmission across unsecured channels. Further, the user need not maintain 
a hardware token configured to generate a proper response to a challenge. The user need 
only maintain the global server Uniform Resource Locator (URL), a user ID and a 
password needed to effect a proper response to a challenge by the applet. Thus, to access a 
service, the roaming user can use any computer terminal, which is connected to the 
computer network and capable of executing the applet. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating a roaming-user network access system, in 
accordance with the present invention; 

FIG. 2 is a block diagram illustrating details of an example client of FIG. 1; 

FIG. 3 is a block diagram illustrating details of the global server of FIG. 1 ; 

FIG. 4 is a block diagram illustrating details of an example service server of FIG. 

1; 

FIG. 5 is a flowchart illustrating a method for remotely accessing a secure service; 
FIG. 6 is a flowchart illustrating details of the FIG. 5 step of creating a link 
between a client and the global server of; 

FIG. 7 illustrates an example web page; 



WO 99/05813 PCT/US98/15036 

FIG. 8A is a flowchart illustrating details of the FIG. 5 step of accessing a service 
in a first embodiment; 

FIG. 8B is a flowchart illustrating details of the FIG. 5 step of accessing a service 
in a second embodiment; 
5 FIG. 8C is a flowchart illustrating details of the FIG. 5 step of accessing a service 

in a third embodiment; 

FIG. 9 is a block diagram illustrating a roaming-user network access system, in 
accordance with the present invention; 

FIG. 10 is a block diagram illustrating details of the remote terminal of FIG. 9; 
10 FIG. 1 1 A is a block diagram illustrating details of the global server of FIG. 9; 

FIG. 1 IB is a block diagram illustrating details of the authentication applet of FIG. 

9; 

FIG. 12 is a block diagram illustrating details of the network computer of FIG. 9; 
FIG. 13 is a flowchart illustrating a method for remotely accessing a secure 
15 service; 

FIG. 14 is a flowchart illustrating details of the FIG. 13 step of authenticating the 
remote terminal user in a first embodiment; and 

FIG. 15 is a flowchart illustrating details of the FIG. 13 step of authenticating the 
remote terminal user in a second embodiment. 
20 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

FIG. 1 is a block diagram illustrating an exemplary roaming-user network access 
system 100 in accordance with the present invention. System 100 includes an 
interconnected network of computers referred to herein as an "Internet" 102. System 100 
further includes a first company network 1 12, a second company network 1 18, a kiosk 



-5- 



WO 99/05813 PCTAJS98/15036 

network 138 and an Internet Service Provider (ISP) network 143, each network being 
coupled to the Internet 102. 

Company network 1 12 includes a firewall 116 coupled between the Internet 102 
and a client computer 1 14a. Company network 1 1 8 includes a firewall 120 coupled 
5 between the Internet 102 and an internal network signal bus 126. Company network 118 
further includes a first server 108a for providing a first service 1 10a, a second server 108b 
for providing a second service 1 10b, a first client computer 1 14b storing a program for 
providing a third service 1 10c and a second client computer 1 14c, each being coupled to 
signal bus 126. It will be appreciated that any of the client computers (i.e., client 
10 computers 1 14a, 1 14b, etc.) may be any computer, and any of the servers may be any 

computer coupled to and capable of being polled by any of the client computers. Example 
services for which services 1 10a-l lOd represent include an e-mail service program, an 
address book service program, a calendar service program, a paging service program, a 
company database service program, and any of the like. 
15 The kiosk network 138 includes a first client computer 1 14d and a second client 

computer 1 14e, each being coupled together and to the Internet 102. The ISP network 143 
includes an ISP 148 coupled via a wireless channel 146 to a first client computer 1 14f and 
coupled via modems 152 and 156 and via transmission line 154 to a second client 
computer 114g. 

20 The Internet 102 includes a global server 106, which is protected by a global 

firewall 104 and includes a server 108c for providing a service 1 lOd. Intercommunication 
between client computers 1 14a-l 14g and services 1 10a-l lOd is accomplished via the 
global server 106. If, for example, a user of any one of the client computers 1 14a- 1 14g 
wants to access a service 1 10a-l lOd (which is provided at a location within system 100 



-6- 



WO 99/05813 PCT/US98/15036 

that is unknown to the user), then the user applies a known Uniform Resource Locator 
(URL) to access a web page operated by global server 106. An example web page 700 is 
shown in and described with reference to FIG. 7. The global firewall 104 protects the 
global server 106 from external threats. 
5 Before obtaining access privileges to the functionality provided by the global 

server 106, the user must first obtain authorization from the global server 106. Obtaining 
authorization typically requires user identification and authentication, for example, using 
public-key certificates. Once authenticated, the global server 106 provides the user with 
access to the services 1 10a- 1 lOd. It will be appreciated that varying levels of access to 
10 services 1 10a-l lOd will be granted based on varying strengths of identification and 
authentication and on the privacy of the communications channel. 

To enable user access to and control of the services 1 10a- 1 lOd, the global server 
106 may use conventional applets, servlets or agents in a distributed network environment, 
such as the Java™ distributed environment produced by the Netscape Corporation. The 
15 global server 106 provides the user's client with access to and control of the services 1 10a- 
1 lOd. The global server 106 may redirect the user's client to access the services 1 10a- 
1 lOd itself, the global server 106 may access the services 1 10a- 1 lOd itself and provide I/O 
to the client by proxy, or the global server 106 may provide the services 1 10a-l lOd itself. 
These three different modes of access to the services 1 10a-l lOd are described with 
20 reference to FIGs. 8A-8C. 

The global server 106 maintains the network addresses of all the services 1 10a- 
1 lOd, the user's public and private keys, the user's account numbers, firewall 
authentication information, etc. Firewall authentication information includes the necessary 
identification, passwords and certificates needed to pass firewalls 1 16 and 120. 



-7- 



WO 99/05813 PCT/US98/15036 

Accordingly, the user need only maintain the URL of the global server 106, and 
identification and authentication information such as a password or hardware token for 
obtaining access to the functionality of the global server 106. Thus, the roaming user can 
access computer services 1 10a-l lOd using any computer terminal, which is connected to 
5 the Internet 102. 

FIG. 2 is a block diagram illustrating details of a client computer 1 14, such that 
each of clients 1 14a-l 14d is an instance of the client 114. The client 1 14 includes a 
Central Processing Unit (CPU) 210 such as a Motorola Power PC® microprocessor or an 

10 Intel Pentium® microprocessor. An input device 220 such as a keyboard and mouse, and 
an output device 230 such as a Cathode Ray Tube (CRT) display are coupled via a signal 
bus 240 to CPU 210. A communications interface 250, a data storage device 260 such as 
Read Only Memory (ROM) or a magnetic disk, and a Random-Access Memory (RAM) 
270 are further coupled via signal bus 240 to CPU 210. The communications interface 

15 250 of client computer 1 14 is coupled to the Internet 102 as shown in and described with 
reference to FIG. 1 . 

An operating system 280 includes a program for controlling processing by CPU 
210, and is typically stored in data storage device 260 and loaded into RAM 270 for 
execution. Operating system 280 includes a communication engine 282 for generating and 
20 transferring message packets to and from the internet 106 via the communications 
interface 250. 

Operating system 280 further includes an internet engine such as a web browser 
284, e.g., the Netscape™ web browser produced by the Netscape Corporation or the 
Internet Explorer™ web browser produced by the Microsoft Corporation. The web 



-8- 



WO 99/05813 PCT/US98/15036 

browser 284 includes an encryption engine 285 for encrypting messages using public and 
private keys, and an applet engine 286 for executing applets 288 downloaded from the 
global server 106 to enable the access to computer services 1 10a-l lOd. Downloaded 
applets 288 may include security applets 290 for performing services such as user 
5 identification and authentication, message integrity services, and certificate verification. 
The browser 284 fiirther receives web page data 391 (FIG. 3), configuration data 390 and 
information identifying a set of selectable services 1 10a- 1 lOd, and uses the information to 
display the web page 700 (FIG. 7). The web browser 284 enables a user via the client 

1 14a-l 14g to select one of the services 1 10a-l lOd for execution. 
10 It will be appreciated that a client 1 14a-l 14g such as client 1 14b may include a 

service engine 490 (see FIG. 4) for providing a service 1 10a-l lOd such as service 1 10c. 

Thus, it is possible for a client 1 14b user to request access to service 1 10c via the global 

server 106, without knowing that the service 1 10c is provided by client 1 14b. 

Accordingly, the global server 106 will provide client 1 14 with an applet 288 for 
15 providing user interface I/O of service 1 10c back to client 1 14b. 

FIG. 3 is a block diagram illustrating details of the global server 106, which 
includes a CPU 310 such as a Motorola Power PC® microprocessor or an Intel Pentium® 
microprocessor. An input device 320 such as a keyboard and mouse, and an output device 
20 330 such as a CRT display are coupled via a signal bus 340 to CPU 3 10. A 

communications interface 350, a data storage device 360 such as ROM or a magnetic disk, 
and a RAM 370 are further coupled via signal bus 340 to CPU 310. The communications 
interface 350 is conventionally coupled as part of the Internet 102 to the clients 114. 



-9- 



WO 99/05813 PCT/US98/15036 

Although the global server 106 is described as a skvAc computer, it will be appreciated 
that the global server 106 may include multiple computers networked together. 

Operating system 380 includes a program for controlling processing by CPU 310, 
and is typically stored in data storage device 260 and loaded into RAM 370 for execution. 
5 Operating system 380 includes a communication er.rr.rse 382 for generating and 

transferring message packets to and from client computers 1 14 via the communications 
interface 350. 

Operating system 380 further includes, as psn of global firewall 104, security 
services 384 for opening a communications chanjnd vvinh users. For example, when a 
10 client attempts to access the global server 106, the security services 384 first determines 
whether the global server 106 accepts in-bound ccin^uaications from a particular port 
(not shown) and whether the servlet host engine 3 V described below, is authorized to 
connect to that particular port. If so, the security services 384 allows the communications 
engine 382 to open a communications channel via ±c particular port to the client 1 14a- 
15 1 14g. Otherwise, no channel will be opened. 

The operating system 380 further includes a web engine 387 which, based on 
user's identification, the strength of the user's aaihcuikation and the privacy of the 
communications channel, forwards web page data 3 ( ?l and information identifying a set of 
available services 1 10a-l lOd to the client 1 14a-i 14g. An example web page 700 is shown 
20 and described with reference to FIG. 7. The web engine 387 enables a user to select a 
service 1 10a-l lOd from the web page 700. 

The web engine 387 includes a servlet host engine 286, which downloads security 
applets 290 including an authentication applet ( not shown) to the client computer 1 14 and 
accordingly executes an authentication servlet 397 of servlets 398 for performing 

-in- 



WO 99/05813 PCT/US98/15036 

identification and authentication services. The authentication applet 290 prompts the user 
for identification and authentication information, and then communicates the information 
to the authentication servlet 397. The authentication servlet 397 verifies that the 
information is correct. It will be noted that the user's authentication information is not 
necessarily sent to the authentication servlet 397, but rather its existence and correctness is 
proven via a secure means such as a secure hash. The servlet host engine 386 further 
includes a secure communications engine 396, which may use public key certificates to 
negotiate a secure communications channel with the client computer 1 14. 

Upon selection of a service 1 10a-l lOd, the servlet host engine 386 downloads a 
corresponding applet 388, corresponding configuration data 390 and corresponding user 
data 392 and may download corresponding service address information 394 to the client 
computer 114. Configuration data 390 includes information for configuring the user's web 
browser 284, for configuring the downloaded applets 288, and for configuring the selected 
service 1 10a-l lOd. User data 392 may include user-and-service-specific information such 
as stored bookmarks, calendar data, pager numbers, etc. which was specifically stored on 
the global server 106 for easy access. Service address information 394 identifies the 
location of the services 1 10a-l lOd provided in system 100 by the global server 106. The 
client computer 1 14 executes the corresponding downloaded applet 288, which via the 
servlet host engine 386 (possibly using a corresponding servlet 398) enables the user to 
access and to control the corresponding services 1 10a- 1 lOd. The downloadable applets 
388, configuration data 390, user data 392 and service address information 394 may be 
stored on the data storage device 360. 

A keysafe 395 is a data file for storing each user's identification information, each 
user's public and private keys, each firewall's password information, etc. The keysafe 395 



-11- 



WO 99/05813 PCTAJS98/15036 

is organized in a linked list format so that, based on the selected service 1 10a- 1 lOd, the 
global server 106 can retrieve the appropriate firewall's password information, the 
appropriate user's identification information and keys, etc. The keysafe 395 may be stored 
on the data storage device 360. 

5 

FIG. 4 is a block diagram illustrating details of a service server 108, such that 
servers 108a-108c and client 1 14b are instances of server 108. Server 108 includes a CPU 
410 such as a Motorola Power PC® microprocessor or an Intel Pentium® microprocessor. 
An input device 420 such as a keyboard and mouse, and an output device 430 such as a 
10 CRT display are coupled via a signal bus 440 to CPU 410. A communications interface 
450, a data storage device 460 such as ROM or a magnetic disk, and a RAM 470 are 
further coupled via signal bus 440 to CPU 410. The communications interface 450 is 
coupled to the clients 1 14 as shown in and described with reference to FIG. 1 . 

The operating system 480 includes a program for controlling processing by CPU 
15 410, and is typically stored in data storage device 460 and loaded into RAM 470 for 
execution. Operating system 480 also includes a communications engine 482 for 
generating and transferring message packets via the communications interface 450 to and 
from clients 1 14 or to and from global server 106. Operating system 480 further includes 
security services 484 for negotiating a secure channel with users, a secure communications 
20 engine 486 for opening the secure channel with the users, and a service engine 490 for 
providing a service 1 10a-l lOd to the users. 

The service engine 490 includes a service interface 492 for receiving and 
translating messages to and from downloaded applets 288 currently executing on the client 
1 14, and includes a service processor 494 and service data 496 for processing the service 



-12- 



WO 99/05813 PCT/US98/15036 

requests from the user. The service data 496 may include previously generated 
documents, database information, etc. It will be appreciated that the service data 496 is 
similar to the user data 392, such that it includes the same type of information but is 
maintained on the service server 108 instead of on the global server 108. 

5 

FIG. 5 is a flowchart illustrating a method 500 enabling a user to access services 
1 10a-l lOd in computer network system 100. Method 500 begins by the client 1 14 in step 
505 creating a communications link with the global server 106. Step 505 is described in 
greater detail below with reference to FIG. 6. The global server 106 in step 510 confirms 

10 that the user has privileges to access the functionality of the global server 106. 

Confirming user access privileges may include examining a user certificate, obtaining a 
secret password, using digital signature technology, etc. It will be appreciated that the 
security services 384 may cause the servlet host engine 386 to forward a security applet 
389 via the communications channel to the client 1 14 for performing user authentication. 

15 After user access privileges are confirmed, the web page engine 387 of the global 

server 106 in step 515 downloads web page data 391 and configuration data 390 to the 
client 1 14. The browser 284 of the client 1 14 in step 520 uses the web page data 391 and 
the configuration data 390 to display a web page 700 (FIG. 7) on the output device 230 of 
the client 1 14 and to enable access to the services 1 10a-l lOd which are offered by the 

20 global server 106. An example web page 700 is shown and described with reference to 
FIG. 7. 

From the options listed on the web page 700, the user in step 525 via input device 
220 selects a service 1 10a-l lOd. In response, the servlet host engine 386 of the global 
server 106 in step 530 downloads the corresponding applet(s) 388, applet configuration 



-13- 



WO 99/05813 PCT/US98/15036 

data 390, user data 392 and possibly service address information 394 to the client 1 14. 
Applet configuration data 390 preferably includes user-specific preferences, such as user- 
preferred fonts, for configuring the selected service 1 lOa-HOd. User data 392 may 
include user-specific and service-specific information such as stored bookmarks, calendar 
5 data, pager numbers, etc. Service address information 394 identifies the location of the 
selected service 1 10a-l lOd. Alternatively, the corresponding applet(s) 388, applet 
configuration data 390, user data 392 and service address information 394 could have been 
downloaded in step 515 with the web page data 391 and the configuration data 390. 

The applet engine 286 of the client 1 14 in step 535 executes the corresponding 
10 downloaded applet 288. The service server 108 in step 537 initiates the service engine 
490. The global server 106 in step 538 selects one of the three modes of access described 
in FIGs. 8A-8C for enabling the client computer 1 14 to communicate with the 
corresponding service engine 490. For example, if the user selects the service 1 lOd on 
server 108c, which is not protected by a separate firewall, then the global server 106 may 
15 provide the user with direct access. If the user selects service 1 10a provided by server 

108a within company network 1 18, then the global server 106 may access the service 1 10a 
as a proxy for the user. It will be appreciated that each firewall 106 and 120 may store 
policies establishing the proper mode of access the global server 106 should select Other 
factors for selecting mode of access may include user preference, availability and 
20 feasibility. The global server 106 in step 540 provides the client 114 user with access to 
the selected service 1 10a-l lOd. Step 540 is described in greater detail with reference to 
FIGs. 8A, 8B and 8C. 



-14- 



WO 99/05813 PCT/US98/15036 

FIG. 6 is a flowchart illustrating details of step 505 (create link between client and 
global server), which begins by the client 1 14 user in step 605 using a known Uniform 
Resource Locator (URL) to call the global server 106. The global server 106 and the 
client 1 14 in step 607 create a secure communications channel therebetween, possibly by 
5 applying Secure Sockets Layer (SSL) technology. That is, the security services 384 of the 
global server 106 in step 610 determine if in-bound secure communications are permitted 
and, if so, create a communications channel with the client 1 14. The browser 284 of the 
client 1 14 and the security services 384 of the global server 106 in step 615 negotiate 
secure communications channel parameters, possibly using public key certificates. An 
10 example secure communications channel is RSA with RC4 encryption. It will be 

appreciated that the global server 106 may be configured to use one often encryption 
protocols and the client 1 14 may be enabled to use one of five encryption protocols. Step 
615 thus may include selecting one of the encryption protocols, which is common to both 
the global server 106 and the client 114. The encryption engine 285 of the client 1 14 and 
15 secure communications engine 396 of the global server 1 1 4 in step 620 use the secure 
channel parameters to create the secure communications channel. Step 505 then ends. 

FIG. 7 illustrates an example URL-addressable HyperText Markup Language 
(HTML)-based web page 700, as maintained by the servlet host engine 386. The web 
20 page 700 includes a title 7 1 0 "Web Page," a listing of the provided services 7 1 5 and a 
pointer 770 for selecting one of the provided services 715. As illustrated, the provided 
services 715 may include an e-mail service 720, a calendaring service 730, an internet 
access service 740, a paging service 750 and a fax sending service 760. Although not 



-15- 



WO 99/05813 PCT/US98/15036 

shown, other services such as bookmarking, QuickCard™, etc. may be included in the web 
page 700. 

FIG. 8A is a flowchart illustrating details of step 540 (provide access to the service 
5 to the client user) in a first embodiment, referred to as method 540a, wherein the global 
server 1 06 provides the client 114 with a direct connection to the service 1 10a-l lOd. 
Method 540a begins by the downloaded applet 288 in step 805 retrieving the service 
address 394 of the selected service 1 10a-l lOd from data storage device 360 and the 
authentication information for the service 1 10a-l lOd from the keysafe 395. The 
10 communications engine 282 in step 8 1 0 creates a direct and secure connection with the 
communications engine 482 of the service server 108 at the retrieved service address, and 
uses the authentication information to authenticate itself. The applet 288 in step 815 acts 
as the I/O interface with the service engine 490. Method 540a then ends. 

15 FIG. 8B is a flowchart illustrating details of step 540 (provide access to the service 

to the client user) in a second embodiment, referred to as method 540b, wherein the global 
server 106 acts for the client 1 14 as a proxy to the service 1 1 0a-l lOd. Method 540b 
begins with the applet 288 in step 840 retrieving the "service" address, which results in 
directing it to the global server 106. Thus, the applet 288 in step 845 creates a connection 

20 with the global server 106. The servlet host engine 386 of the global server 106 in step 
850 retrieves the service address of the selected service 1 10a-l lOd and the authentication 
information for the selected service 1 10a- 1 lOd from the keysafe 395. The secure 
communications engine 396 of the global server 106 in step 855 negotiate secure channel 



-16- 



WO 99/05813 PCT/US98/15036 

parameters for creating a secure channel with the secure communications engine 486 of 
the service server 108. 

Thereafter, the applet 288 in step 860 acts as the I/O interface (enables the user to 
make requests of the service engine 490) with the secure communications engine 396 of 
5 the global server 106. If the servlet host engine 386 in step 865 determines that it is 
unauthorized to perform a client 1 14 user's request, then the servlet host engine 386 in 
step 870 determines whether the method 540b ends, e.g., whether the user has quit. If so, 
then method 820b ends. Otherwise, method 540b returns to step 860 to obtain another 
request. If the servlet host engine 386 in step 865 determines that it is authorized to 
10 perform the client 1 1 4 user's request, then the servlet host engine 386, possibly using 
servlets 398, acts as the proxy for the client 1 14 to the service engine 490. As proxy, the 
servlet host engine 386 forwards the service request to the service 1 10a-l lOd for the applet 
288 and forwards responses to the requesting applet 288 currently executing on the client 
1 14. Method 540b then returns to step 870. 

15 

FIG. 8C is a flowchart illustrating details of step 540 (provide access to the service 
to the client user) in a third embodiment, referred to as method 540c, wherein the service 
1 10a-l lOd being requested is located on the global server 106. Method 540c begins with 
the applet 288 in step 880 retrieving the service address for the service 1 10a- 1 lOd, which 
20 results in providing the applet 288 with the service address of the service 1 10a-l lOd on the 
global server 106. Thus, the applet 288 in step 882 creates a secure connection with the 
global server 106. No additional step of identification and authentication is needed since 
the client 1 14 has already identified and authenticated itself to the global server 106 in step 
510 of FIG. 5. 



-17- 



WO 99/05813 PCIYUS98/15036 

In step 884, a determination is made whether the service 1 10a-l lOd is currently 
running. If so, then in step 886 a determination is made whether the service 1 10a-l lOd 
can handle multiple users. If not, then the global server 106 in step 890 creates an instance 
for the user, and the applet 288 in step 892 acts as the I/O interface with the service 1 10a- 
5 1 lOd on the global server 106. Otherwise, if the service 1 10a-l lOd in step 886 determines 
that it cannot handle multiple users, then method 540c proceeds to step 892. Further, if in 
step 884 the global server 106 determines that the service 1 10a-l lOd is not currently 
running, then the global server 106 in step 888 initializes the service 1 I0a-1 lOd and 
proceeds to step 886. , 

10 

FIG. 9 is a block diagram illustrating a roaming-user network access system 900 in 
an alternative embodiment in accordance with the present invention. Network access 
system 900 includes a remote terminal 905 coupled via computer network 910 to a Local 
Area Network (LAN) 915 and to a global server 920. The global server 920 is protected 

15 by a global firewall 925, and the LAN 915 is protected by a LAN firewall 930. 

The remote terminal 905 includes a web engine 935 for communicating via 
computer network 910. The web engine 935 includes an applet engine 940 for executing 
applets downloaded from the computer network 910. Examples of web engines 935 
having applet engines 940 include the Netscape™ web browser produced by the Netscape 

20 Corporation and the Internet Explorer™ web browser produced by the Microsoft 
Corporation. 

LAN 915 includes a network computer 990, coupled to the LAN firewall 930 via a 
signal bus 985. The network computer 990 includes a service engine 993 for providing a 
service such as accessing e-mail, maintaining an address book, maintaining a calendar, 



-18- 



WO 99/05813 PCT7US98/15036 

sending and receiving pages, accessing a network database 997, etc. This service that is 
provided by service engine 993 may include one of the services 1 10a-l lOd (FIG. 1) that is 
provided by one of the service servers 108a-108c and 1 14b (FIG. 1). The LAN firewall 
930 protects the LAN 915 from external threats. 
5 The global server 920 includes a web page engine 975 enabling access to the 

network database 997 and to the service engine 993 and for providing an interface. As 
similarly stated above with reference to FIG. 1, intercommunication between the remote 
terminal 905 and the network computer 990 is accomplished via the global server 920. If, 
for example, a remote terminal 905 user wants to access the service engine 993, then the 
10 user applies a known Uniform Resource Locator (URL) to access a web page managed by 
the web page engine 975 which lists the available service provided by service engine 993. 
Further, to provide access and control of a service to a remote terminal 905 user, the global 
server 920 may use conventional applets, servlets or agents in a distributed network 
environment, such as the Java™ distributed environment produced by the Netscape 
15 Corporation. The global server 906 may provide the remote terminal 905 with direct 

access to the service, may access the service itself and provide I/O to the remote terminal 
905 by proxy, or may provide the service itself. Providing access to a service is described 
in greater detail above with reference to FIGs. 1-8C. 

The global server 920 further includes an authentication system 945 for 
20 authenticating a user requesting access, for example, to the web page. The authentication 
system 945 includes an applet host engine 950 for sending an authentication applet 955 
and a challenge 965 to the remote terminal 905. The applet engine 940 on the remote 
terminal 905 executes the applet 955, which implements the corresponding challenge 965. 
The applet 955, in coordination with user input, computes and forwards a proper response 



-19- 



WO 99/05813 PCTYUS98/15036 

to the challenge 965 back to the global server 920. The global server 920 verifies the 
response. For example, the global server 920 may retrieve and use user information 960 
such as the user's password, a hash of the user's password or the user's public key to 
verify the response. It will be appreciated that varying levels of access to services will be 

5 granted based on the user's identification, on the varying strengths of authentication and 
on the privacy of the communications channel The authentication applet 955 is described 
in greater detail with reference to FIG. 1 IB. 

The global server 920 further includes security services 970 for establishing secure 
communications with the remote terminal 905 or with the service engine 993. The 

10 security services 970 are similar to the security services 384 described with reference to 
FIG. 3. It will be appreciated that the security services 970 may generate challenges 965 
for the authentication system 945 to send to the remote terminal 905 with the 
authentication applet 955. 

15 FIG. 1 0 is a block diagram illustrating details of the remote terminal 905, which is 

similar to each of the clients 1 14 described with reference to FIG. 2. The remote terminal 
920 includes a Central Processing Unit (CPU) 1005 such as a Motorola Power PC® 
microprocessor or an Intel Pentium® microprocessor. An input device 1010 such as a 
keyboard and mouse, and an output device 1015 such as a Cathode Ray Tube (CRT) 

20 display are coupled via a signal bus 1020 to CPU 1005. A communications interface 

1025, a data storage device 1030 such as Read Only Memory (ROM) or a magnetic disk, 
and a Random- Access Memory (RAM) 1035 are further coupled via signal bus 1020 to 
CPU 1005. The communications interface 1025 is coupled to the computer network 910 
as shown in and described with reference to FIG. 9. 



-20- 



WO 99/05813 PCT/US98/15036 

An operating system 1040 includes a program for controlling processing by CPU 
1005, and is typically stored in data storage device 1030 and loaded into RAM 1035 (as 
illustrated) for execution. Operating system 1040 includes the web engine 935 for 
generating and transferring message packets via the communications interface 1025 to and 
5 from the computer network 910 possibly using encryption techniques such as public and 
private keys. As stated above with reference to FIG. 9, the web engine 935 includes an 
applet engine 940 for executing applets including the authentication applet 955 
downloaded from the global server 920. Other downloadable applets (388, FIG. 3) to be 
executed by the applet engine 940 may include security applets for performing message 
10 integrity services and certificate verification. 

The web engine 935 further receives web page data (391, FIG. 3), configuration 
data (390, FIG. 3) and data identifying the selectable service offered by the service engine 
993. It will be appreciated that the selectable service may include one of the services 
1 10a-l lOd (FIG. 1) offered by one of the service engines 108a-108c and 1 14b (FIG. 1). 
15 The web engine 953 uses the data to display the web page (e.g., the web page 700, FIG. 7). 
The web engine 935 enables a remote terminal 905 user to select the service for execution. 

FIG. 1 1 A is a block diagram illustrating details of the global server 920, which is 
similar to the global server 106 described with reference to FIG. 3. The global server 920 
20 includes a CPU 1 105 such as a Motorola Power PC® microprocessor or an Intel Pentium® 
microprocessor. An input device 1110 such as a keyboard and mouse, and an output 
device 1115 such as a CRT display are coupled via a signal bus 1 120 to CPU 1 105. A 
communications interface 1 125, a data storage device 1 130 such as ROM or a magnetic 
disk, and a RAM 1 135 are further coupled via signal bus 1 120 to CPU 1 105. The 



-21- 



WO 99/05813 PCTAJS98/15036 

communications interface 1 125 is conventionally coupled to the computer network 910. 
Although the global server 920 is described as a single computer, it will be appreciated 
that the global server 920 may include multiple computers networked together. 

An operating system 1 140 includes a program for controlling processing by CPU 
5 1 105, and is typically stored in data storage device 1 130 and loaded into RAM 1 135 (as 
illustrated) for execution. Operating system 1 140 includes the web page engine 975 for 
generating and transferring message packets via the communications interface 1 125 to and 
from remote terminal 905. The web page engine 975 forwards web page data (391, FIG. 
3), configuration data (390, FIG. 3) and data identifying a set of available services (1 10a- 
10 1 lOd, FIG. 1) to the remote terminal 905. The web page engine 975 is similar to the web 
engine 387 (FIG. 3) of the global server 106. Operating system 1140 further includes the 
security services 970 for opening a secure communications channel with users. 

The operating system 380 further includes the applet host engine 950 which, before 
enabling the web page engine 975 to execute its routines, retrieves and forwards the 
15 authentication applet 955 and a corresponding challenge 965 to the remote terminal 905. 
It will be appreciated that upon a request for server 920 access the security services 970 
may generate the challenge 960 and forward it to the applet host engine 950 to be 
forwarded with the authentication applet 955. As stated above, during execution, the 
authentication applet 955 prompts the user for identification (user ID) and a password, 
20 uses the password to compute a proper response, and forwards the identification and 
response to the authentication system 945. Computing a proper response is described in 
detail with reference to FIGs. 14 and 15. 

The authentication system 945 uses the user ID and the challenge 960 to verify the 
user. For example, the authentication system 945 may use the user ID to retrieve a hash of 



-22- 



WO 99/05813 PCT/US98/15036 

the password from the user information 960, and then uses the hash of the password to 
verify the response. It will be appreciated that using a preferred embodiment of the 
present invention the password is not sent to the applet host engine 950, but rather its 
existence and correctness is proven via a secure means such as a secure hash. It will be 
5 further appreciated that the authentication applet 955 may communicate with an 

authentication servlet 397 (FIG. 3), which when executed by a servlet host engine 386 
(FIG. 3) performs response verification. 



FIG. 1 IB is a block diagram illustrating details of the authentication applet 955. 

10 Authentication applet 955 includes a user ID module 1 1 50 for prompting a user for a user 
ID, and a password module 1 155 for prompting a user for a password. The authentication 
applet 955 further includes a response generator 1 1 60 for generating a response using the 
password input by the user and the challenge 965 sent to the remote terminal 905 with the 
authentication applet 955. Alternatively, the response generator 1 160 may request the 

15 challenge 965 from the global server 920 after the user has input the password. The 

response generator 1 160 generates the response by using the password and the challenge 
965 as variables in an algorithm 1 165. Exemplary algorithms 1 165 are described in detail 
inFIGs. Hand 15. 

The authentication applet 955 further includes a communications module 1 170 for 
20 communicating with the global server 920, e.g., for receiving the challenge 965 from the 
global server 920, for sending the response to the global server 920 for verification and for 
receiving server 920 a verification signal indicating success or failure. The authentication 
applet 955 still further includes an access initiation module 1 175 for enabling a user to 



-23- 



WO 99/05813 PCIYUS98/15036 

access the functionality of the global server 920. The access initiation module 1 175 is 
described in greater detail above with reference to FIGs. 1-8C. 



FIG. 12 is a block diagram illustrating details of the network computer 990, which 
5 is similar to the service server 1 08 (FIG. 4) and may include all the same elements. The 
network computer 990 includes a CPU 1205 such as a Motorola Power PC* 
microprocessor or an Intel Pentium® microprocessor. An input device 1210 such as a 
keyboard and mouse, and an output device 1215 such as a CRT display are coupled via a 
signal bus 1220 to CPU 1205. A communications interface 1225, a data storage device 
10 1230 such as ROM or a magnetic disk, and a RAM 1 235 are further coupled via signal bus 
1220 to CPU 1205. The communications interface 1210 is coupled to computer network 
910 as shown in and described with reference to FIG. 9. 

The operating system 1220 includes a program for controlling processing by CPU 
1205, and is typically stored in data storage device 1230 and loaded into RAM 1235 (as 
15 illustrated) for execution. Operating system 1240 also includes a service engine 993 for 
providing a service to the users. The data storage device 1230 includes a network database 
997 containing workspace data such as documents, e-mails, calendar information, files, 
etc. 

20 FIG. 1 3 is a flowchart illustrating a method 1 300 for enabling a user to access a 

service in computer network system 900. Method 1300 begins by the remote terminal 905 
in step 1305 requesting logon to the global server 920. The global server 920 in step 1310 
forwards an authentication applet 955 and a corresponding challenge 965 to the remote 
terminal 905. The applet engine 935 of the remote terminal 905 in step 1315 initiates 



-24- 



WO 99/05813 PCT/US98/15036 

execution of the authentication applet 955, which in coordination with the global server 
920 in step 1320 identifies and authenticates the user. Step 1320 is described in greater 
detail with reference to FIGs. 14 and 15. After the user is identified and authenticated, the 
global server 920 in step 1325 enables the user to access the functionality offered by the 
5 global server 920, i.e., initiates access to the service provided by the service engine 993. 
Step 1325 is described in greater detail with reference to FIG. 5 (namely, steps 515-540) 
and FIGs. 8A-8C. 

FIG. 14 is a flowchart illustrating a first method 1320a s which exemplifies details 
10 of step 1320 in a first embodiment for authenticating a user. Method 1320a begins with 
the communications module 1 170 of the authentication applet 955 in step 1405 obtaining a 
challenge 965 from the authentication system 945 on the global server 920. It will be 
appreciated that the global server 920 may download the challenge 965 with the 
authentication applet 955 or may wait for the response generator 1 160 to make a request 
15 before downloading the challenge 965 . 

In step 1410, the user ID module 1 150 of the authentication applet 955 prompts the 
user for a user ID and the password module 1 155 of the authentication applet 955 prompts 
the user for a password input. Upon receiving the password and the challenge 965, the 
response generator 1 160 of the authentication applet 955 in step 1415 uses the password 
20 and the challenge 965 as variables in a one-way hash algorithm 1 165 to compute the 
appropriate response. In a preferred embodiment, the response generator 1 160 hashes a 
combination of the challenge 965 and a hash of the user's password to generate the 
response. In another preferred embodiment, the response generator 1 160 hashes a 
combination of the challenge 965, a hash of the user's password and a modification factor 



-25- 



WO 99/05813 PCT/US98/15036 

(commonly referred to as "salt") which protects against "dictionary attacks" to generate 
the response. A dictionary attack is one that uses a dictionary list of words to generate a 
hash-to-password table, which can be used to misappropriate user passwords. The 
response generator 1 160 in step 1420 instructs the communications module 1 170 to send 
5 the user ID and the response via the communications interface 1025 to the authentication 
system 945. For convenience, the response generator 1 160 may also send the challenge 
965 with the response back to the authentication system 945. 

The authentication system 945 in step 1425 uses the user ID and the challenge 965 
to verify the response. For example, the authentication system 945 may use the user ID to 
10 retrieve a registered hash of the user's password from the user information 960. The 
authentication system 945 uses the challenge 965 and the registered hash of the user's 
password to perform the same one-way hash function and generate a verification response. 
Further, if the hash function included salt, then the authentication system 945 would apply 
the same salt when generating the verification response. It will be appreciated that the 
15 algorithm performed by the applet 955 and the algorithm performed by the authentication 
system 945 may not be the same. 

If in step 1430 the authentication system 945 determines that the verification 
response computed by the authentication system 945 is the same as the response received 
from the authentication applet 955, then the user is successfully verified. Accordingly, the 
20 authentication system 945 in step 1435 informs the access initiation module 1 175 of the 
authentication applet 955 of the success. The authentication system 945 in step 1440 
authorizes the user to access the service provided by the service engine 993 during this 
session. It will be appreciated that providing access is described in greater detail with 
reference to FIGs. 1-8C. Method 1320a then ends. If unsuccessful, the authentication 



-26- 



WO 99/05813 PCT/US98/15036 

system 945 in step 1440 informs the access initiation module 1 175 of the failure, and the 
access initiation module 1 175 in step 1445 informs the user. Method 1320a then returns to 
step 1410. 

5 FIG. 1 5 is a flowchart illustrating a second method 1 320b, which exemplifies 

details of step 1320 in a second embodiment for authenticating a user. Method 1320b 
begins with the user ID module 1 1 50 of the authentication applet 955 in step 1501 
prompting the user for a user ID, and in step 1502 instructing the communications module 
1 170 to send the user ID to the authentication system 945 of the global server 920. The 
10 authentication system 945 in step 1 503 uses the user ID to retrieve user information 960 
such as the user's password or the user's public key, and uses the retrieved information to 
encrypt a token. The response generator 1 160 of the authentication applet 955 in step 
1505 obtains the encrypted token from the authentication system 945. 

The password module 1 1 55 of the authentication applet 955 in step 1510 prompts 
15 the user for a password or private key input. The response generator 1 1 60 in step 1515 
uses the password or private key and the predetermined algorithm 1 165 to decrypt the 
encrypted token. The response generator 1 160 in step 1520 uses a predetermined 
modification factor to modify the decrypted result, for example, by adding one to the 
token. The response generator 1 160 in step 1525 uses the user's input or the public key of 
20 the server 920 and the algorithm 1 165 to re-encrypt the modified token and to generate a 
corresponding response. 

The response generator 1 160 in step 1527 instructs the communications module 
1 170 to send the response to the authentication system 945. The authentication system 
945 in step 1530 uses the user information 960 to verify the response. That is, the 



-27- 



WO 99/05813 PCT/US98/15036 

authentication system 945 uses the retrieved user's password, the retrieved user's public 
key or the private key of the server 920 and the predetermined algorithm 1 165 to decrypt 
the response. The authentication system 945 then uses the same predetermined 
modification factor to modify the token and compares the modified token with the 

5 decrypted response. 

If the authentication system 945 in step 1535 determines that the modified token is 
the same as the decrypted response, then the user is successfully verified. Accordingly, 
the authentication system 945 in step 1540 informs the access initiation module 1 175 of 
the authentication applet 955 of the success. The authentication system 945 in step 1555 

10 authorizes the user to access the service provided by the service engine 933. As stated 
above, access to the service is described in greater detail with reference to FIGs. 1-8C. 
and method 1320b then ends. However, if the authentication system 945 in step 1535 
determines that the modified token is different than the decrypted response, then the 
authentication system 945 in step 1545 informs the access initiation module 1 175 of the 

15 verification failure, and the access initiation module 1 175 in step 1 550 informs the user. 
Method 1320b then returns to step 1510. 

The foregoing description of the preferred embodiments of the invention is by way 
of example only, and other variations of the above-described embodiments and methods 
20 are provided by the present invention. Although the system and method have been 

described with reference to applets, other downloadable executables such as Active X™ 
control developed by the Microsoft Corporation can alternatively be used. Further, 
although the authentication applet is being described with reference to a service accessing 
system, the authentication applet will operate with any computer system operating in a 



-28- 



WO 99/05813 PCT/US98/15036 

distributed environment requiring user authentication. Although the system and method 
have been described with reference to challenge/response-based authentication schemes, 
the authentication applet may incorporate any authentication technique. Components of 
this invention may be implemented using a programmed general-purpose digital computer, 
5 using application specific integrated circuits, or using a network of interconnected 
conventional components and circuits. The embodiments described herein have been 
presented for purposes of illustration and are not intended to be exhaustive or limiting. 
Many variations and modifications are possible in light of the foregoing teaching. The 
invention is limited only by the following claims. 



-29- 



WO 99/05813 



PCT/US98/15036 



WHAT IS CLAIMED IS : 
1 . An authentication system, comprising: 

a user ID module for obtaining a user ID; 
a password module for obtaining a password; 

a response generator coupled to the password module for using the password as a 
variable in an algorithm to compute a response; and 

a communications module coupled to the response generator and to the user ID 
module for sending the response and the user ID to a server for verifying the response and 
authenticating the user. 

1 2. The system of claim 1, further comprising a downloadable and executable 

2 authentication applet. 

1 3 . The system of claim 1 , wherein the user ID module obtains the user ID by 

2 prompting for user input. 

1 4. The system of claim 1 , wherein the password module obtains the password by 

2 prompting for user input. 

1 5. The system of claim 1 , wherein the algorithm includes a one-way hash function. 



-30- 



WO 99/05813 PCT/US98/15036 

1 6. The system of claim 5, wherein the response generator receives a random challenge 

2 and uses the one-way hash function to hash the password and the random challenge 

3 together. 

1 7. The system of claim 1 , wherein the response generator obtains an encrypted token 

2 and uses the password and the algorithm to decrypt the encrypted token. 

1 8. The system of claim 7, wherein the response generator uses a modification factor 

2 to modify the decrypted token. 

1 9. The system of claim 8, wherein the response generator uses the password and the 

2 algorithm to re-encrypt the modified token and wherein the response includes the re- 

3 encrypted token. 

1 10. An authentication system, comprising: 

2 first means for obtaining a user ID; 

3 second means for obtaining a password; 

4 third means coupled to the second means for using the password as a variable in an 

5 algorithm to compute a response; and 

6 fourth means coupled to the first means and to the third means for sending the 

7 response and the user ID to a server for verifying the response and authenticating the user. 

1 11. The system of claim 10, further comprising a downloadable and executable 

2 authentication applet. 

-31- 



WO 99/05813 



PCT/US98/15036 



1 12. The system of claim 1 , wherein the first means obtains the user ID by prompting 

2 for user input. 

1 13. The system of claim 1 , wherein the second means obtains the password by 

2 prompting for user input. 

l 1 4. The system of claim 1 , wherein the algorithm includes a one-way hash function. 

1 15. The system of claim 14, wherein the third means receives a random challenge and 

2 uses the one-way hash function to hash the password and the random challenge together. 

1 16. The system of claim 1 , wherein the third means obtains an encrypted token and 

2 uses the password and the algorithm to decrypt the encrypted token. 

1 1 7. The system of claim 1 6, wherein the third means uses a modification factor to 

2 modify the decrypted token. 

1 18. The system of claim 1 7, wherein the third means uses the password and the 

2 algorithm to re-encrypt the modified token and wherein the response includes the re- 

3 encrypted token. 

1 19. A computer-readable storage medium storing program code for causing a computer 

2 to perform the steps of: 



-32- 



WO 99/05813 PCT/US98/15036 

obtaining a user ID; 
obtaining a password; 

using the password as a variable in an algorithm to compute a response; and 
sending the response and the user ID to a server for verifying the response and 
authenticating the user. 

20. A computer-based authentication method, comprising the steps of: 
obtaining a user ID; 

obtaining a corresponding password; 

using the password as a variable in an algorithm to compute a response; and 
sending the response and the user ID to a server for verifying the response and 
authenticating the user. 

21. The method of claim 20, further comprising the step of receiving a downloadable 
and executable authentication applet. 

22. The method of claim 20, wherein the step of obtaining the user ID includes 
prompting for user input. 

23. The method of claim 20, wherein the step of obtaining the password includes 
prompting for user input. 

24. The method of claim 20, wherein the algorithm includes a one-way hash function. 



-33- 



WO 99/05813 PCT/US98/15036 

1 25. The method of claim 24, further comprising the step of receiving a random 

2 challenge and wherein the step of using the password includes using the one-way hash 

3 function to hash the password and the random challenge together. 

1 26. The method of claim 20, further comprising the step of obtaining an encrypted 

2 token and wherein the algorithm includes using the password to decrypt the encrypted 

3 token. 

1 27. The method of claim 26, wherein the algorithm includes using a modification 

2 factor to modify the decrypted token. 

1 28. The method of claim 27, wherein the algorithm uses the password to re-encrypt the 

2 modified token and wherein the response includes the re-encrypted token. 

1 29. A program for causing a computer to perform the steps of: 

2 obtaining a user ID; 

3 obtaining a corresponding password; 

4 using the password as a variable in an algorithm to compute a response; and 

5 sending the response and the user ID to a server for verifying the response and 

6 authenticating the user. 

1 30. The program of claim 29, wherein the program is a downloadable and executable 

2 applet. 



-34- 



WO 99/05813 



PCTAJS98/15036 



1 31. An authentication system, comprising: 

2 an engine for receiving a service request from a client; 

3 a password database storing a first password; and 

4 authentication means coupled to the engine and to the password database for 

5 forwarding to the client an authentication applet which when executed by the client uses a 

6 client password as a variable in an algorithm to compute a client response, for receiving 

7 the client response from the client, and for using the first password to verify the client 

8 response. 

1 32. The system of claim 3 1 , wherein the service request includes a request to access 

2 the contents of a server. 

1 33 . The system of claim 3 1 , wherein the password database further stores a first user 

2 ID corresponding to the first password. 

1 34. The system of claim 33, wherein the authentication applet includes a user ID 

2 module for obtaining and sending a client user ID back to the authentication means. 

1 35. The system of claim 34, wherein the authentication means compares the client user 

2 ID with the first user ID to retrieve the first password from the password database. 

1 36. The system of claim 3 5 , wherein the authentication means uses the first password 

2 as a variable in the algorithm to compute a verification response and compares the 

3 verification response with the client response. 

-35- 



WO 99/05813 



PCT/US98/15036 



1 37. The system of claim 36, wherein the authentication means grants the service 

2 request when the verification response is the same as the client response. 

1 38. The system of claim 31, wherein the algorithm includes a one-way hash function. 

1 39. The system of claim 38, wherein the authentication means forwards a random 

2 challenge to the client and the one-way hash function hashes the client password and the 

3 random challenge together. 

1 40. The system of claim 3 1 , wherein the authentication means uses the first password 

2 to encrypt a token and forwards the encrypted token to the client. 

1 41. The system of claim 40, wherein the authentication applet includes a response 

2 generator for using the client password and the algorithm to decrypt the encrypted token. 

1 42. The system of claim 4 1 , wherein the response generator uses a modification factor 

2 to modify the decrypted token. 

143. The system of claim 42, wherein the response generator uses the client password 

2 and the algorithm to re-encrypt the modified token and wherein the response includes the 

3 re-encrypted token. 

1 44. An authentication system, comprising: 



-36- 



WO 99/05813 PCTYUS98/15036 

first means for receiving a service request from a client; 

second means coupled to the first means for delivering to the client an 
authentication applet, which when executed by the client uses client input as a variable in 
an algorithm to compute a response; 

third means coupled to the second means for receiving the response from the client; 

and 

fourth means coupled to the third means for verifying the response. 



1 45 . A computer-readable storage medium storing program code for causing a computer 

2 to perform the steps of: 

3 receiving a service request from a client; 

4 delivering to the client an authentication applet, which when executed by the client 

5 uses client input as a variable in an algorithm to compute a response; 

6 receiving the response from the client; and 

7 verifying the response. 

1 46. A computer-based method in a server, comprising the steps of: 

2 receiving a service request from a client; 

3 delivering to the client an authentication applet, which when executed by the client 

4 uses client input as a variable in an algorithm to compute a client response; 

5 receiving the client response from the client; and 

6 verifying the client response. 



-37- 



WO 99/05813 PCT/US98/15036 

47. The method of claim 46, wherein the service request includes a request to access 
the contents of a server. 



48. The method of claim 46, further comprising the step of storing a first password in a 
password database 

1 49. The method of claim 48, further comprising the step of storing a first user ID 

2 corresponding the first password in the password database. 

1 50. The method of claim 49, wherein the authentication applet includes a user ID 

2 module for obtaining and sending a client user ID back to the server. 

1 51. The method of claim 50, further comprising the step of comparing the client user 

2 ID with the first user ID to retrieve the first password from the password database. 

1 52. The method of claim 5 1 , further comprising the steps of using the first password as 

2 a variable in the algorithm to compute a verification response and comparing the 

3 verification response with the client response. 

1 53 . The method of claim 52, further comprising the step of granting the service request 

2 when the verification response is the same as the client response. 

1 54. The method of claim 46, wherein the algorithm includes a one-way hash function. 



-38- 



WO 99/05813 PC17US98/15036 

1 55. The method of claim 54, further comprising forwarding a random challenge to the 

2 client and wherein the one-way hash function hashes the password and the random 

3 challenge together. 

1 56. The method of claim 46, further comprising the steps of using the first password to 

2 encrypt a token and forwarding the encrypted token to the client. 

1 57. The method of claim 56, wherein the authentication applet includes a response 

2 generator for using the client password and the algorithm to decrypt the encrypted token. 

1 58. The method of claim 57, wherein the response generator uses a modification factor 

2 to modify the decrypted token. 

1 59. The method of claim 58, wherein the response generator uses the client password 

2 and the algorithm to re-encrypt the modified token and wherein the response includes the 

3 re-encrypted token. 



1 60. A method of authentication, comprising the steps of: 

2 receiving an authentication applet from a server; and 

3 executing the authentication applet, which includes 

4 obtaining a user ID and a password; 

5 using the password as a variable in an algorithm to generate a response; and 

6 sending the user ID and the response to the server for verifying the response 

7 and authenticating the user. 



-39- 



WO 99/05813 



2/18 



PCT/US98/15036 




WO 99/05813 



PCIYUS98/15036 



3/18 




WO 99/05813 



4/18 



PCT/US98/15036 



0) i- 




g 

LL 



WO 99/05813 



PCT/US98/15036 



5/18 
( St3rt ) 



500 



I 



Create link between client and global server 



If 



r-505 



Confirm user access privileges ~~|J~ 

f 



Download web page data and configuration data 
from global server to client 



510 



515 



Configure client and display web page 



LT 



I 



Client user selects a service 



v 



520 



525 



Download corresponding applet, applet 
configuration data and user data from 
the global server to the client 



530 



Execute the applet 



V 



535 



Initiate the service 



V 



537 



Select a mode of access 



LT 



538 



Provide access to the service to the client user 



IT 



T 

GEO 



540 



FIG. 5 



WO 99/05813 PCTYUS98/15036 

6/18 



( Start ) 

_3_ 



505 



Call global server using known URL 



]j~ 605 / 



Create communications channel J~ 

i 



610 



607 



Negotiate secure chan nel parameters | J~ 



615 



620 



Create secure channel 



FIG. 6 



WO 99/05813 



PCT/US98/15036 



7/18 



700 

t 



Web Page 



1. E-Mail 



2. Calendaring 



3. Internet Access 



4. Paging 




5. Sending Faxes 



770 



(Web Page Screen Shot) 



710 



Li" 

lT 



720"^ 



730 



740 



j- 750 
j- 760 _J 



715 



FIG. 7 



WO 99/05813 



PCT/US98/15036 



8/18 



( Start ) 

!x 

Applet retrieves service address 
and authentication information 



I 



Client creates direct and secure 
connection with service and 
uses the authentication 
information to authenticate itself 



i 



"XT 

C Ertd ) 



IT 



805 



J" 



810 



Applet acts as I/O interface J~ 
with the service engine 



815 



540a 



i 



(Redirect) 



FIG. 8A 



WO 99/05813 



PCTYUS98/15036 



9/18 

C Start ) 



I 



Applet retrieves service address 
directing it to the global server 



I 



Applet creates a secure connection 
to the global server 



845 



Global server retrieves the service address 
and the authentication information 



IT 



850 



I 



Global server connects to the service 
and uses the authentication information 
to authenticate itself as the user 



IT 



855 



I 



Applet acts as I/O interface 
with global server 



LT 



860 



540b 



IT 840 j 



865 



Global 
server authorized 
to perform the user's 
request 

? 



Yes 



No 



\ r 
End? 
Yes 




870 



( End ) 
(Proxy) 

FIG. 8B 



875 



Global server 
acts as proxy 
to service 



WO 99/05813 



PCT/US98/15036 



10/18 



(" Start ) 



Applet retrieves service address 
directing it to the global server 



I 



Create a direct connection 
to the service 



IT 



882 



No 



I 



Initialize 
the service 



Is 

the service 
currently runnina 
888 \ ? 




884 



Yes 



Create an instance for the user 



IT 



890 



1 



Applet acts as I/O interface J~ 
with service engine 



892 



I 



(Direct to data) 



540c 



-^880 ^ 



FIG. 8C 



WO 99/05813 



PCT/US98/15036 



11/18 



to 



to 

00 
CD 



O 

o 

CD 

E 

CD 
-*—> 
</) 
>> 
V) 



CD 

O 3 

S e 



O 



L. 


Q) 
V) 


o 


CO 




_o 
eg 


Ne 


ro 
Q 



o 



21 i — 

-i UL > 



\ 



o 

CM to o to o to 

cr> t m m (0 (O 

/ 0)0)0)0)0) 




CD 



o 



<D 

2: 

CD 
CO 

15 













CD 






ine 


CL 


c 






o 




O) 


< 


*-»— » 


CO 


c 




CO 


d) 




C 

o 


e 

i 


CO 

a 


plet Host 


thenticati 


User Infoi 


Challei 


Q- 


•D 






< 


< 







o m 
cr> CD 



If) 


<D 


CD 


c 


O 


O) 


erv 


En 


CO 


<D 




CD 
TO 


*i_ 


CL 


u 


_Q 


CD 


0) 


CO 





WO 99/05813 



PCT/US98/15036 




WO 99/05813 



PCT/US98/15036 




WO 99/05813 



PCT/US98/15036 



14/18 



955 



User ID Module 


j-1150 




j-1155 


Password Module 




p1 160 


Response Generator 


Algorythm - — ^ 


— -1165 


Communications Module 


j-1170 


Access Initiation Module 


j-1175 



FIG. 11B 



WO 99/05813 



PO7US98/15036 



15/18 




CM 
LL 



WO 99/05813 



PCT/US98/15036 



16/18 



C Start ) 

_3_ 



Request logon to the global 
server by the remote terminal 



1305 



Forward authentication applet to the 
remote terminal by the global server 



I 



-1310 



Initiate authentication applet 
by the remote terminal 



I 



S 



1315 



Identify and authenticate the user 




f 


Provide user with access to global server 
functionality by the global server 




r 



IT 



1320 



Lf 



1325 



1300 



i 



FIG. 13 



WO 99/05813 PCTAJS98/15036 



17/18 



1320 



( Start ) 

_5_ 



Obtain challenge from the server 



Prompt for user ID and password input 



Inform user 
of failure by 
the applet 



f 



1445 



I 



Com pute response 



1405 



1410 



1415 



| Send user ID and response to the server 



Inform 
applet of 
failure by 
the global 

server 



1440 



I 



Verify response by the server 




if 



1420 



1425 



1435 



Inform applet of success 



Authorize service by the server 



if 



1440 



FIG. 14 



WO 99/05813 



PCT/US98/15036 



18/18 



1320b 



Prompt for user ID input 

— i 



Send user ID to the server 



if 



Compute encrypt ed token 



Obtain en crypted token from the server ^ 

1 J 



Inform user 
of failure by 
the applet 



if 



1550 



Prompt for passwor d input 

I 



Decrypt the token using password 



if 



Modify result 

i 



Inform 
applet of 
failure by 
the global 

server 



if 



Reencrypt modified result using password 
1 545™" j 



Send the response to the server 



I 



Verify response by the server 



1501 
1502 
1503 
1505 

1510 
1515 
1520 
1525 



1530 




1535 



Inform applet of success 



if 



1540 



Authorize service b y the server 





if 



1555 



FIG. 15 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification: 

H04L 9/00 


A3 


(11) International Publication Number: WO 99/05813 
(43) International Publication Date: 04 February 1999 (04.02.1999) 


(21) International Application Number: PCT/US98/1 5036 

(22) International Filing Date: 21 July 1 998 (21 .07.1 998) 

(30) Priority Data: 

08/899,277 23 July 1997 (23.07.1997) US 

(60) Parent Application or Grant 

VISTO CORPORATION [/]; (). RIGGINS, Mark, D. [/]; 
(). SOCKOL, Marc, A. ; (). 


Published 



(54) Title: USER AUTHENTICATION APPLET IN A COMPUTER NETWORK 

(54) Titre: SYSTEME ET PROCEDE ^UTILISATION D'UNE MINI-APPLICATION D'AUTHENTIFICATION POUR 
IDENTIFIER ET AUTHENTIFIER UN UTILISATEUR DANS UN RESEAU IN FORMATIQU E 



(57) Abstract 

The system includes a server coupled via a computer network to a client. Upon receiving a request for access, the server sends 
an authentication applet to the client. The authentication applet includes a user identification (ID) module for obtaining a user 
ID and a password module for obtaining a client password. The authentication applet also includes a response generator coupled to 
the password module for using the client password as a variable in an algorithm to compute a client response. The authentication 
applet further includes a communications module coupled to the response generator and to the user ID module for sending the 
client response and the user ID back to the server for verifying the response and authenticating the user. The client uses an 
applet engine to execute the applet. The server uses the user ID to retrieve user information, and uses the user information as a 
variable in an algorithm to generate a verification response. If the verification response is the same as the client response, 
then the identity of the user is verified and access may be granted. 

(57) Abrege 

Ce systeme comprend un serveur couple par un reseau informatique a un client. Lors de la reception d'une demande d'acces, le 
serveur envoie au client une mini-application d'authentification. Cette mini-application d'authentification contient un module 
d'identification (ID) d'utilisateur permettant d'obtenir ndentification (ID) de I'utilisateur et un module mot de passe 
permettant d'obtenir le mot de passe du client. La mini-application d'authentification renferme egalement un generateur de 
reponse couple au module mot de passe pour pouvoir utiliser le mot de passe du client comme variable dans un algorithme 
permettant de calculer la reponse du client. Cette mini-application d'authentification contient en outre un module de 
communications couple au generateur de reponse et au module d'identification de I'utilisateur pour renvoyer au serveur la reponse 
du client et ('identification de I'utilisateur, afin de verifier la reponse et authentifier I'utilisateur. Le client utilise un 
moteur de mini-application pour executer la mini-application. Le serveur utilise I'identification de I'utilisateur pour rapatrier 
des informations d'utilisateur et il utilise ces informations d'utilisateur comme variable dans un algorithme permettant de 
generer une reponse de verification. Si la reponse de verification est la meme que la reponse du client, alors I'identite de 
i'utilisateur est verifiee et I'acces peut etre accorde. 



PCT 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 



INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 
H04L9/00 


A3 


(11) International Publication Number: WO 99/05813 
(43) International Publication Date: 4 February 1999 (04.02.99) 


(21) International Application Number: PCT/US98/ 15036 

(22) International FOing Date: 21 July 1998 (21.07.98) 

(30) Priority Data: 

08/899,277 23 July 1997 (23.07.97) US 

(71) Applicant: VISTO CORPORATION [US/US]; 1937 Landings 

Drive, Mountain View, CA 94043 (US). 

(72) Inventor: RIGG1NS, Mark, 5818 Moraga Avenue. San 

Jose, CA 95123 (US). 


(81) Designated States: CA, CN, IL, JP, SG f Eurasian patent (AM, 
AZ, BY, KG, KZ, MD, RU, TJ. TM), European patent (AT, 
BE, CH, CY, DE, DK, ES, FI, FR. GB, GR, IE, IT, LU. 
MC, NL. FT, SE). 

Published 

With international search report. 

Before the expiration of the time limit for amending the claims 
and to be republished in the event of the receipt of amendments. 

(88) Date of publication of the international search report: 

20 January 2000 (20.0 1 .00) 



(74) Agents: SOCKOL, Marc. A. et al.; Graham & James LLP, 600 
Hansen Way, Palo Alto, CA 94304-1043 (US). 



(54) Title: USER AUTHENTICATION APPLET IN A COMPUTER NETWORK 




(57) Abstract 

The system includes a server coupled via a computer network to a cUent. Upon receiving a request for access, the server sends 
an authentication applet to the client The authentication applet includes a user identification (ID) module for obtaining a user ID and a 
password module for obtaining a client password. The authentication applet also includes a response generator coupled to the password 
module for using the client password as a variable in an algorithm to compute a client response. The authentication applet further includes 
a communications module coupled to the response generator and to the user ID module for sending the client response and the user ID back 
to the server for verifying the response and authenticating the user. The client uses an applet engine to execute the applet. The server uses 
the user ID to retrieve user information, and uses the user information as a variable in an algorithm to generate a verification response. If 
the verification response is the same as the client response, then the identity of the user Is verified and access may be granted. 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


AM 


Armenia 


El 


Finland 


LT 


AT 


Austria 


FR 




LU 


AU 


Australia 


GA 


Gabon 


LV 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


BB 


Barbados 


GH 


Ghana 


MG 


Bit 


Belgium 


GN 


Guinea 


MK 


BF 


Burkina Faso 


GR 


Greece 




BG 


Bulgnia 


HU 


Hungary 


ML 


BJ 


Benin 


IE 


Ireland 


MN 


BR 


Brazil 


IL 


Israel 


MR 


BY 


Belarus 


IS 


Iceland 


MW 


CA 


Canada 


IT 


hah/ 


MX 


CF 


Central African Republic 


JP 


Japan 


NE 


CG 


Congo 


KB 


Kenya 


NL 


at 


Switzerland 


KG 


Kyrgyzstan 


NO 


CI 


Cote d'l voire 


KP 


Democratic People's 


NZ 


CM 


Cameroon 




Republic of Korea 


PL 


CN 


China 


KR 


Republic of Korea 


PT 


CU 


Cuba 


KZ 


Kazakstan 


RO 


cz 


Czech Republic 


LC 


Saint Lucia 


RU 


DE 


Germany 


U 


Liechtenstein 


SD 


DK 


Denmark 


LK 


Sri Lanka 


SE 


EE 


Estonia 


LR 


Liberia 


SG 



Latvia 
Monaco 

Republic of Moldova 



The former Yugoslav 
Republic of Macedonia 
Mali 

Mongolia 

Mauritania 

Malawi 

Mexico 

Niger 

Netherlands 

Norway 

New Zealand 

Poland 

Portugal 

Romania 

Russian Federation 
Sudan 
Sweden 
Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


SZ 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Taplostan 


TM 


Turkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UG 


Uganda 


US 


United Slates of America 


UZ 


Uzbekistan 


VN 


Viet Nam 


vu 


Yugoslavia 


zw 


Zimbabwe 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US9SV 15036 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(6) HO4L9/00 

US CL 380725. 49: 395/ 1 87.01 , 1 88.01 . 200.59 

According to International Patent Classification (IPC) or lo both national classification and IPC 

B. FIELDS SEARCHED 

Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 380/25, 49; 395/187.01. 188.01. 200.59. 186. 200.32. 200.33 



Documentation searched other than minimum documentation to the extent that such documents arc included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practicable, search terms used) 
APS terms: applet, global server, authentication 


r nOCI JMENTS CONSIDERED TO BE RELEVANT 


Category * 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 
Y 

A 
X 

Y 
A 


US 5.434.918 A (KUNG et ah) 18 July 1995 (18.07.95) Abstract and Figure 2 

US 5,544.322 A (CHENG ct ah) 06 August 19% (06.08.96) Entire Document 

US 5,491.752 A (KAUFMAN et al.) 13 February 1996 (13.02.96) Abstract and Figures 5-7 

If 

US 5.706, J27 A (TABUKI) 06 January 1998 (06.01.98) Entire Document 


1.3. 4,7-10. 12. 13. 
16-20, 22, 23. 26-30. 
40-44. 56-59 


2, 11. 31-37. 45-53, 60 
1-60 

1.5.6, 10. 14. 15, 19, 
20. 24, 25. 29, 38, 39. 
54. 5S 


2. 11.31-37. 45-53.60 
1-60 


| | Furihct 


documents are listed in the continuation of Box C. Q See patent family annex. 


Soceiat categories of cited document!: T iarer docuincra oubl nficd alter Uic uacnoitonai Wlnf date or priority 
* and not m conflict with the application but cilcd to under stand the 
-A" document defining «hc rencrat state of the on which rs not considered to be pruictpk or theory underlying the invenuor. 
of oanicular relevance 

*^ - x - (Jocumcr* of particular relevance: the claimed invention cannot be 
- E- earlier application or patent published on or after the inirrmiitinil filing date cortsidaed novel or cannot be considered to uurolve an inventive step 

when the document is taken atone 

*L" document wfticb may throw doubts on priority claimts) or which is cited to - . , u k.^i^^t, 

establish the publicaiton date uf another ciuiion or other special reason (as -V document of particular relevance; the rdsrmcd rweneon cannot be 
inerified) considered to involve an in»entive step when the document ti 
1 combined with one or inure odter such documents, such combination 

-O" dnarmcnt referr ire u> an oral disclosure, use. eshibtticn or other mean* beinj obvious to a person skilled in the art 

- P - document published prior to the uiirmaiional filing dair out later dun the '&.' document mctuber of the same patent family 
priority date claimed 


Date of the actual completion of the international search 
28 October 1999 (28.10.1999) 


Date of mailing of the international search report 

29 NOV iqqo 


Name and mailing address or the ISA/US 
Cnmmiwioner of Pj tents and Tfadematks 
Ro« PCT 

Washineicm. D C. 20231 
Facsimile No. (703)305-3210 


Aui^rizedothcer^^^ £ju^ 
Kenneth A Wieder 
Telephone No. 703-305-3900 



Form PCr/ISA/210 (second sheet) (July 1998)