`
`6993658
`
`1D
`
`1]Tit
`
`Use of personal communication devices for user authentication
`
`Abstract
`
`A password setting system for a secure system includes a user token server and a communication
`module. The user token server generates a random tokenin responseto a request for a new
`password from a user. The server creates a new password by concatenating a secret passcodethat
`is knownto the user with the token. The server sets the password associated with the user's user ID
`to be the new password. The communication module transmits the token to a personal
`communication device, such as a mobile phoneor a pagercarried by the user. The user
`concatenates the secret passcodewith the received tokenin orderto form a valid password, which
`the user submits to gain access to the secure system. Accordingly, access to the system is based
`upon: nonsecret information knownto the user, suchas the userID; secret information knownto the
`user, such as the passcode; and information provided to the user through an object possessed by
`the user, such as the token.
`
`Images (12)
`
`Inventor: Sten-Olov Engberg, Ake Jonsson
`
`Current Assignee : DynapassIp Holdings LLC
`
`Worldwide applications
`
`2000 YS 2001 WOAU
`
`Application US09/519,829 events ©
`
`US casefiled in Texas Eastern District Court ®
`
`2000-03-06 Application filed by April System Design AB
`
`2000-03-06
`
`Priority to US09/519,829
`
`2006-01-31
`
`Application granted
`
`
`
`
`
`2006-01-31=Publication of US6993658B1
`
`Classifications
`
`w» H04L63/083 Networkarchitectures or network communication protocols for network security
`for authentication of entities using passwords
`View 3 moreclassifications
`
`Landscapes
`
`Engineering & Computer Science
`
`Computer Security & Cryptography
`
`Show more
`
`2020-03-06 Anticipated expiration
`
`Expired - Lifetime
`Status
`Showall events v
`
`Info: Patentcitations (17), Non-patentcitations (8), Cited by
`(221), Legal events, Similar documents,Priority and Related
`Applications
`
`External links: USPTO, USPTO PatentCenter, USPTO
`Assignment, Espacenet, Global Dossier, Discuss
`
`Claims(7)
`
`Hide Dependent ~
`
`1. A method of authenticating a user on a first secure computer network, the user having a user accounton saidfirst secure computer network, the method comprising:
`
`associating the user with a personal communication device possessed bytheuser, said personal communication device in communication over a second network, wherein
`said second networkis a cell phone networkdifferent from the first secure computer network;
`
`receiving a request from the userfor a token via the personal communication device, over the second network;
`
`generating a new passwordforsaid first secure computer network basedat least upon the token and a passcode, wherein the token is not knownto the user and wherein the
`passcodeis knownto the user;
`
`setting a password associated with the user to be the new password;
`
`activating access the user account onthefirst secure computer network;
`
`transmitting the token to the personal communication device;
`
`receiving the password from the uservia thefirst secure computer network; and
`
`deactivating access to the user account onthe first secure computer network within a predetermined amountoftime after said activating, such that said user accountis not
`accessible through any password,via said first secure computer network.
`
`2. The methodof claim 1, wherein the new password is generated by concatenating the token and the passcode.
`
`Ex. 2005, p. 1
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`Ex. 2005, p. 1
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`
`
`3. The methodof claim 1, wherein the personal communication device is a mobile phone.
`
`4, The methodof claim 1, wherein the personal communication device is a pager.
`
`5. Auser authentication system comprising:
`
`a computer processor;
`
`a user database configured to associate a user with a personal communication device possessed by the user, said personal communication device configured to
`communicate over a cell phone network with the user authentication system;
`
`a control module executed on the computer processor configured to create a new password basedat least upon a token and a passcode, wherein the token is not known to
`the user and wherein the passcodeis knowntothe user, the control module further configured to set a password associated with the user to be the new password;
`
`a communication module configured to transmit the token to the personal communication device through the cell phone network; and
`
`an authentication module configured to receive the password from the user through a secure computer network, said secure computer network being different from the cell
`phone network, wherein the user has an account on the secure computer network, wherein the authentication module activates access to the account in responseto the
`password and deactivates the accountwithin a predetermined amountof time after activating the account, such that said accountis not accessible through any password
`via the secure computer network.
`
`6. The system of claim 5, wherein the communication moduleis further configured to receive a request from the userfor the token, and wherein the control module is
`further configured to create the new passwordin responseto the request.
`
`7. The system of claim 6, wherein the request is transmitted by the user through the personal communication device.
`
`Description
`
`BACKGROUNDOFTHEINVENTION
`
`1. Field of the Invention
`
`This invention relates generally to the authentication of users of secure systems and, moreparticularly, the invention relates to a system through which usertokens
`required for user authentication are supplied through personal communication devices such as mobile telephones and pagers.
`
`2. Description of the Related Art
`
`Secure systems havetraditionally utilized a user ID and passwordpair to identify and authenticate system users. Operating systemsthat control local area networks of
`workstations within a businessorinstitution such as Novell NetWare, Microsoft NT, Windows 2000, and UNIX/Linuxtypically require submission of a user ID and
`password combination before allowing accessto a workstation.
`
`The incorporation of remote connectivity to secure systems overthe Internet has weakenedtraditional controls imposed by a user's required physical presence within a
`company’s premises and has exposed systemsto additional security threats. External users accessing by dial-in or over the Internet, complicated by frequent personnel
`turnover, require frequent changesin passwordlists.
`
`Passwordscreated by users are often combinations of words and names, which are easy to rememberbut also easily guessed. Guessing passwordsis a frequent
`technique used by “hackers”to break into systems. Therefore, many systems impose regulations on password formats that require mixturesofletters of different cases
`and symbols and that no part of a password be a wordin the dictionary. A user's inability to remember complex combinationsof letters, numbers, and symbols often
`results in the password being written down, sometimes on a note stucktothe side of a workstation.
`
`Present systems face several problems: users dread frequent password changes, frequent password changeswith hard-to-remember passwordsinevitably result in
`users surreptitiously writing down passwords, and security is compromised when users write downtheir passwords.
`
`The SecurlD product, whichis distributed by RSA Security Inc., solves many of the aforementioned problems by requiring a two-factor authentication process. Thefirst
`factor is a user passcode or personal identification number. The second factoris a SecurlD card that is possessed by the user. The SecurlD card generates and displays
`unpredictable, one-time-only access codes that automatically change every 60 seconds. The user supplies the displayed code upon logging into a system. The system
`has a corresponding code generatorthat allowsverification of possession ofthe card.
`
`The SecurlD product, however, requires users to carry an additional item on their person in order to access a secure system. It would be advantageousif the benefits of
`the SecurlD system could be achieved using a device that many users already carry—a personal communication device such as a mobile phoneor a pager.
`
`SUMMARYOF THE INVENTION
`
`A preferred embodimentof the presentinvention is a password setting system for setting user passwordsfor a secure system, such as a computer system or a secure
`area of a building. The password setting system preferably includes a user token server and a communication module. The user token server generates a random token
`in response to a request for a new password from a user. The server creates a new password by concatenating a secret passcodethat is knownto the userwith the
`token. The server sets the password associated with the user's user ID to be the new password. The communication module transmits the token to a personal
`communication device, such as a mobile phone or a pagercarried bythe user. The user concatenates the secret passcodewiththe received token in order to form a valid
`password, which the user submits to gain access to the secure system. Accordingly, access to the system is based upon: nonsecret information knownto the user, such
`as the userID; secret information knownto the user, such as the passcode; and information provided to the user through an object possessed by the user, such as the
`token.
`
`Oneaspect ofthe invention is a method for setting passwords. The method includes associating a user ID with a phone numberof a personal communication device.
`The methodalsoincludes generating a new password basedat least upon a token. The method alsoincludes setting a password associated with the userID to be the
`new password. The methodalso includes transmitting the token to the personal communication device using the phone numberassociated with the userID. In another
`aspect, the methodalso includes associating the user ID with a passcode.In another aspect, the new passwordis generated based additionally upon the passcode.In
`another aspect, the methodalsoincludes receiving a request for the user token. In another aspect, the personal communication device is a mobile phone.In another
`aspect, the personal communication device is a pager.
`
`Ex. 2005,p. 2
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`Ex. 2005, p. 2
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`
`
`An additional aspect of the invention is a password setting system. The system includesa first user database configured to associate a user ID with a phone numberof a
`personal communication device. The system also includes a control module configured to create a password basedatleast upon a token. The control moduleis further
`configured to cause a second user databaseto associate the password with the userID. The system also includes a communication module interface configured to
`cause a communication module to transmit the token to the personal communication device using the phone numberassociated with the userID. In another aspect, the
`first user database and the second user database are the same database. In another aspect, the first user database is further configured to associate the user ID with a
`passcode, and the control moduleis further configured to create the password based additionally upon the passcode.
`
`An additional aspectof the invention is a method of regulating access to a secure system. The methodincludes transmitting a user token to a personal communication
`device. The methodalsoincludesreceiving login data in response to a request for authentication information, wherein the login data is based at least upon the user
`token. The methodalso includes granting accessto the secure system based uponthe receivedlogin data. In another aspect, the login data is additionally based upon a
`userID. In another aspect, the login data comprises a userID. In another aspect,the login data is additionally based upon a passcode.In another aspect, the login data
`comprises a user ID and a password.In another aspect, the password comprises a passcode and the token.In another aspect, the passwordis a concatenation of the
`passcodeandthetoken.In another aspect, the password is a hashed concatenation of the passcodeandthe token.In another aspect the methodalso includes
`generating the user token. In another aspect the method also includes receiving a request for the user token. In another aspect, the personal communication deviceis a
`mobile phone. In another aspect, the personal communication device is a pager.
`
`An additional aspect of the invention is an access control system. The system includesa user token server configured to transmit a token to a personal communication
`device. The user token serveris further configured to generate a valid password basedat least upon the token. The system also includes an authentication module
`configuredto receive at least a submitted password in responseto a request for authentication of a user. The authentication module is further configured to grant access
`to the userif at least the submitted password is based at least upon the token and matchesthe valid password.In anotheraspect, the user token serveris further
`configured to generate the valid password based additionally upon a valid passcodethat is knownto the user. In another aspect, the user token serveris further
`configured to transmit the token in responseto a request bytheuser. In another aspect, the user token serveris further configured to associate the valid password with a
`valid userID, the authentication module is further configured to receive a submitted user ID in responseto the request for authentication, and the authentication module
`is further configured to grant accesstothe userif, in addition, the submitted user ID matchesthevalid userID.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present inventionwill be described below in connection with the attached drawings in which:
`
`FIG.1 illustrates an overview, including system components, of a user authentication system according to a preferred embodimentofthe presentinvention;
`
`FIGS, 2A-Dillustrate login screens that can be used in conjunction with various embodiments ofthe invention;
`
`FIG.3 illustrates a preferred process performed by the system to authenticate users;
`
`FIG.4 illustrates a preferred embodimentof a user token server;
`
`FIG.5 illustrates a preferred process by which the user token server provides tokens and administrates user accounts;
`
`FIGS. 6A-Cillustrate three embodiments of a token delivery communicationlink;
`
`FIGS. 7A-Billustrate two embodiments of a token request communicationlink; and
`
`FIG.8 illustrates an embodiment of a combined token request and delivery communicationlink.
`DETAILED DESCRIPTION OF THE EMBODIMENTS
`
`In the following description, reference is made to the accompanying drawings,which form a part hereof, and which show, by wayofillustration, specific embodiments or
`processesin which the invention may be practiced. Where possible, the same reference numbers are used throughout the drawingsto refer to the sameorlike
`components.In someinstances, numerousspecific details are set forth in order to provide a thorough understanding of the present invention. The presentinvention,
`however, may be practiced without the specific details or with certain alternative equivalent devices and methods to those described herein. In other instances, well-
`known methods and devices have not been describedin detail so as not to unnecessarily obscure aspects of the present invention.
`
`|. Overview and System Components
`
`FIG.1 illustrates an overview, including system components, of a user authentication system 100 according to a preferred embodimentofthe presentinvention. FIG. 2A
`illustrates a login screen that can be usedin accordancewith the preferred embodiment. FIGS. 2B-Dillustrate login screens that can be used in accordance with
`alternative embodiments.
`
`The userauthentication system 100includes an authentication server 102, a text messaging service provider 104, a personal communication device 106 carried by a
`user 108, and a secure system 110 to which the authentication system 100 regulates access. The personal communication device 106 is preferably a pager or a mobile
`phonehaving SMS(short message service) receive capability. SMS is a secure text messaging capability that is incorporated into most digital mobile phones. The secure
`system 110 is preferably a Windows NT computer workstation, but may be any system, device, account, or area to whichit is desired to limit access to authenticated
`users. The secure system 110 maybe, for example, a user account on a network of computer workstations, a user account on a website, or a secure area of a building.
`The secure system 110 is preferably connected to the user authentication server 102 by a computer network 103. In one embodiment, the user authentication server 102
`is integrated into the secure system 110.
`
`The userauthentication server 102 preferably includes a program ora suite of programs running on a computer system to perform user authentication services. The user
`authentication server 102 mayalso include the computer system and hardware upon which the programsrun. The user authentication server 102 is preferably configured
`to require that the user 108 supply authentication information through the secure system 110 in order to gain access to the secure system 110.
`
`The authentication information preferably includes a user ID 152, a passcode 154 and a user token 156. The user 108 preferably commits to memory the user ID 152 and
`passcode 154. The user ID 152 maybe publicly known and usedtoidentify the user 108. The passcode 154is preferably secret and only knownto the user 108. The
`token 156 is preferably provided only to the user 108 by the user authentication server 102 through the user's personal communication device 106 on an as neededbasis.
`The token 156 preferably hasa limitedlifespan, such as 1 minute or 1 day. Accordingly, the user 108 needsto be in possessionof his personal communication device
`106in orderto gain accessto the secure system 110. Therefore, if the user's user ID 152 and passcode 154 are compromised, a maliciousparty still cannot access the
`secure system without possession of the personal communication device 106.
`
`In the preferred embodiment, the user 108 combinesthe token 156 with the passcode 154 to form a password 158. For example, the user 108 can combinea valid,
`memorized passcodeof “abcd” with a valid token of “1234” to formavalid password of “abed1234.” In this manner, a login screen suchasisillustrated in FIG. 2A, which
`Ex. 2005,p. 3
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`Ex. 2005, p. 3
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`
`
`is similaror identical to standard login screens that require a user ID 152 and a password 158, can be used.In an alternative embodiment, the passcode 154 and the
`token 156 are submitted separately, asis illustrated in FIG. 2B. In another embodiment, the passcode 154is null in which case the token 156 aloneis used as the
`password 158.In still another embodiment, the token 156 can be requested through the secure system 110 asisillustrated in FIGS. 2C—D.
`
`The user authentication server 102 is preferably a secure system itself and may be a part or component of the secure system 110. The user authentication server 102
`preferably includes an authentication module 112 and a user database 114. The authentication module 112 is preferably identical to the code or software provided with
`operating systems such as WindowsNTthat authenticates users uponlogin.In alternative embodiments, the authentication module 112 may be any code,device, or
`module capable of authenticating a user based upon a supplied user ID 152 supplemented by a supplied password 158 or a passcode 154 and a token 156 combination.
`The authentication module 112 preferably respondsto an authentication request transmitted over the computer network 103 by supplying an authentication confirmation
`162 over the network 103.If the user 108 has been authenticated, the confirmation 162 instructs the secure system 110 to allow accessto the user 108. The user
`database 114 is preferably similar or identical to the database accessed by the authentication module 112 that stores user ID and passworddata (or passcode and token
`data) in operating systems such as WindowsNT.In alternative embodiments, the user database 114 can be any database capable ofstoring user ID and password data.
`
`The userauthentication server 102 preferably also includes a user token server 116 that responds to requests for tokens 160 by generating a token 156 and transmitting
`the token 156 to the user's personal communication device 106. The user authentication server 102 preferably also resets passwordsin the user database 114 based
`upon generated tokens and passcodedata. The user authentication server 102 preferably transmits the tokens 156 over a token delivery communicationlink 105 to the
`user's personal communication device 106.
`
`The user authentication server 102 preferably also includes a communication module 118, whichis also part of the token delivery communicationlink 105. The
`communication module 118 forwards tokens 156 to a text messaging service provider 104, which may be a pager or mobile phoneservice provider. The text messaging
`service provider 104 then forwards the token 156 preferably in the form of a secure text message to the personal communication device 106.
`
`In the preferred embodiment, the communication module 118 is a mobile phone with SMS text messaging send capability. One applicable mobile phoneis the presently
`available Ericsson T-28. The mobile phone 118 is preferably connectedto the user authentication server 102 via a presently available serial port cable that makes the
`phoneaccessible in a mannersimilar to a computer modem. Accordingly, the user authentication server 102 can send tokens 156 via the server's mobile phone 118 to
`the user's mobile phone 106 using SMS.In this case, the server's mobile phone 118 transmits a messageincluding the token 156to the user's personal communication
`device 106 using the phone numberofthe user's personal communication device 106. During the transmission, the messageis relayed by the mobile phone service
`provider 104 toits final destination.
`
`Preferably, the communication module 118 is also configured to receive requests for tokens 160. The user preferably transmits a request for tokens 160 over a request
`communicationlink 107. The request communicationlink 107 may be the same communicationlink as the delivery communicationlink 105 orit may be a differentlink.
`Various embodiments of the token delivery communication link 105 and the token request communication link 107will be discussed in SectionIll below.
`
`In the preferred embodiment, the communication module 118 is a mobile phonethat also has SMS text messaging receive capability. The communication module 118
`receives an SMS messagefrom the user's mobile SMS send enabled mobile phone 106, and the token server 116 preferably processes the messageas a token request
`160. The incoming SMS messageis tagged with the sending phone's phone number, which the user token server 116 canuseto identify the requesting user and respond
`with a new token 156. The token request 160 mayalso bein the form of a phonecall, in which case the user token server 116 mayusea caller ID feature to identify the
`calling phone numberasa valid user's personal communication device 106. The user token server 116 can then respond with a new token 156.Alternatively, the user
`token server 116 mayallow a calling user 108 to enter the phone numberof his personal communication device 106 using the mobile phone keypad once a connection
`has beenestablished.
`
`In an alternative embodiment, the communication module 118 is an ISDN card that is connected to the text messaging service provider 104 preferably via an X.25
`connection. The ISDN card 118 preferably transmits new tokensdirectly to the text messaging service provider 104 for forwardingto the user's personal communication
`device 106. The ISDN card 118 mayalso be configured to be accessible at a phone numberto receive calls for requests for tokens 160.
`
`FIG.3 illustrates a preferred process 300 performed by the system 100 to authenticate users. At a step 302, the user 108 requests a token from the user token server 116
`through the token request communication link 107. In the preferred embodiment, the user's mobile phone 106 has SMSsend capability and the user sends an SMS
`message to the communication module 118 requesting a new token 156. The SMS messageneednot contain any data in its body since the phone numberof the
`sending mobile phone is automatically sent along with the message. The user token server 116 preferably identifies the user's mobile phone 106 based upon the phone
`numberwith which the SMS messageis tagged.In an alternative embodiment, the user 108 makesa phonecall with his personal communication device 106 to the
`communication module 118. The user token server 116 identifies the user's personal communication device 106 preferably based upona caller ID feature. Alternatively,
`the user 108 maycall from any phone and enterin the phone numberof his personal communication device 106. As anotheralternative, the user 108 may request the
`token 156 through the secure system 110 itself asillustrated in FIGS. 2C—D. As anotheralternative, the step 302 may be omitted altogether. In this case, the user token
`server 116 can automatically send tokens 156 to the user 108 at predeterminedintervals, such as once per day where the tokens havea lifespan of one day.
`
`Ata step 304 the user token server 116 generates a token 156. The token 156 may be generated by any of a numberof methodsthat preferably produces a random or
`pseudo-random sequence of numbers and/or digits. The token 156 is preferably long enough suchthat it cannot be guessed, but short enough suchthatit is relatively
`easy to enter, such assix to eight characters.
`
`At a step 306,the token server 116 generates a new password 158. The token server 116 preferably creates the new password 158 by combining the user's passcode
`154, whichis stored by the user token server 116, with the newly generated token 156. At a step 308,the token server updates the user database 114 with the new
`password 158.In the case that the user's accountin the user database 114 is inactive or deactivated, the token server 116 activates the user's account.
`
`In the preferred embodiment, the token server creates a hash of the password 158 and stores the hashof the password 158in the user database 114 ratherthan storing
`the password 158itself. The hashis typically performed using a one-way hashing algorithm where the same password always produces the samehash, but where the
`password cannot be determined from the hash.In typical systems, passwords 158are stored as hashesratherthan asplain text in order to prevent system
`administrators and others from being able to determine users' passwords by examining the user database 114. Also, when a user 108 submits a password 158 upon
`login to a secure system 110, the submitted password 158 is immediately hashed using the same one-way hashingalgorithm before transmission to the authentication
`module 112. The authentication module 112 then compares hashes of passwordsrather than the passwords themselvesto authenticate the user 108.In this manner,
`passwords 158 need not be transmitted over any communicationlinks or computer networksas cleartext.It will be apparent to one skilled in the art that the present
`invention can be implemented with or without the hashing of passwords andthat incorporating hashing of passwords does not substantively affect the scopeor spirit of
`the invention. So as not to unnecessarily obscure aspects of the present invention, a password as referred to herein may be an unhashed or a hashed password. For
`example,a receipt of a password may be a receipt of an unhashed or hashed password, and a comparison of passwords may be a comparison of unhashed or hashed
`passwords.
`
`At a step 310, the token server 116 transmits the token 156to the user's personal communication device 106 via the token delivery communicationlink 105.In the
`preferred embodiment, the communication module 118 is a mobile phone,and the user token server 116 uses the SMSsend capability of the phone 118 to send an SMS
`Ex. 2005,p. 4
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`Ex. 2005, p. 4
`Amazon.com, Inc. v. Dynapass IP Holdings LLC, IPR2024-00283
`
`
`
`messageincluding the token 156 to the user's personal communication module 106. At a step 312, the user 108 receives the token through his personal communication
`device 106.
`
`At a step 314,the user 108logs into the secure system 110 using the user ID 152 and the password 158.In the preferred embodiment, the user 108 combines the
`passcode 154 and the token 156 by concatenation to form the password 158.In an alternative embodiment, the passcode 154 and the token 156 are submitted
`separately.
`
`At a step 316, the secure system 110 transmits login data 159 to the user authentication server 102 over the computer network 103 for authentication of the user 108.
`The login data 159 preferably includes the user ID 152 and a hashof the password 158 that the secure system 110 creates in order to avoid sending the password 158
`over the computer network 103in clear text. Alternatively, the login data 159 mayinclude a hash of the passcode 154 and the token 156. As anotheralternative, the
`password 158, or the passcode 154 and token 156 are not hashed.
`
`At a step 318, the user authentication server 102 authenticates the user 108 based uponthelogin data 159. In order to authenticate the user 108,the authentication
`server 102 preferably compares the login data to the password 158 (hashed or unhashed)or the passcode 154 and token 156 (hashed or unhashed) corresponding to
`the user ID 152 stored in the user database 114.
`
`Ata step 320,the user authentication server 102 transmits an authentication confirmation 162 to the secure system 110. At a step 322, the secure system 110 allows
`the user 108 access based uponthe authentication confirmation 162.
`
`Il. The User Token Server
`
`FIG.4 illustrates a preferred embodimentof the user token server 116. The user token server 116 preferably includes a process or program running on orin conjunction
`with the user authentication server 102. The user token server 116 may, however, include a computer upon whichthe process or program executes. The user token server
`116 preferably includes a control module 402, a supplemental user database 404, a communication moduleinterface 406, and a token generation module 408. The
`various modules and componentsofthe user token server 116 are described herein from a functional perspective. The various functional components may, however, be
`seamlessly integrated into one or more executable programs,data structures, and/or physical components.
`
`The control module 402 preferably serves as the top level componentof the user token server 116. The control module 402 preferably handles any tasks or functions not
`handled by the other modulesof the token server 116,in addition to controlling the other modules. The control module 402 preferably maintains a supplemental user
`database 404, which preferably stores associations of user IDs with passcodes, phone numbersof users’ personal communication devices, and any other supplemental
`user data. The other supplemental user data may include one or more of: whether an accountis active, the expiration time of passwords, and the frequency with which
`tokens may be automatically distributed. The supplemental user database 404is preferably accessed and modified through an administrator user interface 403 provided
`by the control module 402. The administrator userinterface 403 allows administration of user privileges by adding, modifying and removing userIDs, passcodes, and
`phone numbers from the supplemental user database 404.
`
`In the preferred embodiment, the supplemental user database 404 is maintained separately from the user database 114 of the user authentication server 102.In this
`configuration, the user database 114 supplied with an OEM system need not be modified or reconfigured. The user token server 116 can be addedto existing secure
`systemsin order to provide additional security functionality. In an alternative embodiment, the supplemental user database 404 maybeintegrated into the user database
`114.In this case, user authentication module 102is preferably configured and supplied as a single integrated component.
`
`FIG.5 illustrates a preferr