4/25/23, 5:19 PM
`
`US6993658B1 - Use of personal communication devices for user authentication - Google Patents
`
`Google Patents
`
`12)
`
`tit B
`
`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 userwith the token. The server sets the password associatedwith the user's userID
`to be the new password. The communication module transmits the token to a personal
`communication device, such as a mobile phone ora pagercarried by the user. The user
`concatenates the secret passcodewith the received tokenin 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: nonsecretinformation knownto the user, such as theuserID; 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)
`
`US6993658B1
`United States
`
`
`
`B Download PDF a Teale SSL
`
`Inventor: Sten-Olov Engberg, Ake Jonsson
`Current Assignee : Dynapass!p Holdings LLC
`
`Worldwide applications
`2000 °-¥S 2001 -AU WO
`
` 2006-01-31 © Publication of US6993658B1
`
`
`Application US09/519,829 events @
`
`2000-03-06 ° Applicationfiled by April System Design AB
`
`2000-03-06 ° Priority to US09/519,829
`
`2006-01-31 © Application granted
`
`<
`
`Classifications
`
`pw H04L63/083 Networkarchitectures or network communication protocols for network security
`for supporting authentication of entities communicating through a packet data network using
`passwords
`View 3 moreclassifications
`
`>
`
`2020-03-06 « Anticipated expiration
`2022-06-17 » US casefiled in Texas Eastern District Court @
`
`Status
`
`e Expired - Lifetime
`
`Showall events v
`
`Info: Patent citations (17), Non-patentcitations(8), Cited by
`(206), Legal events, Similar documents,Priority and Related
`Applications
`Externallinks: USPTO, USPTO PatentCenter, USPTO
`Assignment, Espacenet, Global Dossier, Discuss
`
`Claims(7)
`
`Hide Dependent «
`
`1. Amethod of authenticating a user on a first secure computer network,the user having a user account onsaidfirst secure computer network, the method comprising:
`
`associating the user with a personal communication device possessedbythe user, said personal communication device in communication over a second network, wherein
`said second networkis a cell phone networkdifferent from thefirst 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 on the first secure computer network;
`
`transmitting the token to the personal communication device;
`
`receiving the password from theuservia thefirst secure computer network; and
`
`deactivating accessto the user accountonthefirst secure computer networkwithin 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.
`
`3. The methodof claim 1, wherein the personal communication device is a mobile phone.
`
`4. The methodofclaim 1, wherein the personal communication device is a pager.
`
`5. A user authentication system comprising:
`
`a computer processor;
`
`https://patents.google.com/patent/US6993658B1/
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`Ex. 2001
`
`1/15
`
`Ex. 2001
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`

`

`US6993658B1 - Use of personal communication devices for user authentication - Google Patents
`4/25/23, 5:19 PM
`a user databaseconfigured to associate a user with a personal communication device possessed bythe user, said personal communication device configured to
`communicate overa cell phone network with the user authentication system;
`
`a control module executed on the computer processorconfigured 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 throughthecell 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
`phonenetwork, wherein the user has an account on the secure computer network, wherein the authentication module activates accessto the accountin responseto the
`password and deactivates the account within a predetermined amountof time after activating the account, such that said account is not accessible through any password
`via the secure computer network.
`
`6. The system of claim 5, wherein the communication module is further configured to receive a request from the userfor the token, and wherein the control moduleis
`further configured to create the new passwordin responseto the request.
`
`7. The system of claim 6, wherein the requestis transmitted by the user through the personal communication device.
`
`Description
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`This invention relates generally to the authentication of users of secure systemsand, moreparticularly, the invention relates to a system through which user tokens
`required for user authentication are supplied through personal communication devices such as mobile telephones and pagers.
`
`2. Description of the Related Art
`
`Secure systemshavetraditionally 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 systemsoverthe Internet has weakenedtraditional controls imposedbya user's required physical presence within a
`company's premises and has exposed systemsto additional security threats. External users accessingbydial-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 usedby “hackers” to break into systems. Therefore, many systems impose regulations on password formats that require mixtures of letters of different cases
`and symbols and that no part of a password be a wordin the dictionary. A user's inability to remember complex combinationsofletters, numbers, and symbols often
`results in the password being written down, sometimes on a note stuckto the side of a workstation.
`
`Present systemsface 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 whenusers write downtheir passwords.
`
`The SecurlD product, whichis distributed by RSA Security Inc., solves manyof the aforementioned problemsby requiring a two-factor authentication process.Thefirst
`factor is a user passcodeor personalidentification number. The second factor is 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 uponlogging into a system. The system
`has a corresponding code generatorthat allowsverification of possession of the card.
`
`The SecurlD product, however, requires users to carry an additional item ontheir personin order to access a secure system.It would be advantageousif the benefits of
`the SecurlD system could be achieved using a device that manyusers already carry—a personal communication device such as a mobile phoneora pager.
`
`SUMMARYOFTHE 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 responseto a request for a new passwordfrom 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 by the user. The user concatenates the secret passcodewith the 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 user ID; secret information knownto the user, such as the passcode; and information provided to the user through an object possessedbythe user, such as the
`token.
`
`Oneaspectof the invention is a method for setting passwords. The methodincludes associating a user ID with a phone numberof a personal communication device.
`The methodalso includes generating a new passwordbasedat least upon a token. The methodalso includes 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 anotheraspect, the new passwordis generated based additionally upon the passcode.In
`another aspect, the methodalso includes receiving a requestfor the user token. In another aspect, the personal communication device is a mobile phone.In another
`aspect, the personal communication device is a pager.
`
`An additional aspectof 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 basedat least upon a token. The control moduleis further
`configured to cause a second userdatabaseto associate the passwordwiththe 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 samedatabase.In another aspect, the first user databaseis further configured to associate the userID with a
`passcode,and the control moduleis further configured to create the password based additionally upon the passcode.
`
`https://patents.google.com/patent/US6993658B1/
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`Ex. 2001
`
`2/15
`
`Ex. 2001
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`

`

`US6993658B1 - Use of personal communication devices for user authentication - Google Patents
`4/25/23, 5:19 PM
`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 responseto a requestfor authentication information, wherein the login data is based at least upon the user
`token. The methodalso includes granting access to the secure system based uponthe received login 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 userID and a password.In another aspect, the password comprises a passcode andthetoken. In another aspect, the passwordis a concatenation of the
`passcodeandthetoken. In another aspect, the password is a hashed concatenation of the passcode andthetoken. In another aspect the methodalso includes
`generating the user token. In another aspect the methodalso includes 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.
`
`An additional aspect of the invention is an access control system. The system includes a user token server configuredto transmit a token to a personal communication
`device. The user token serveris further configured to generate a valid password basedatleast upon the token. The system also includes an authentication module
`configured to receive at least a submitted password in responseto a request for authentication of a user. The authentication moduleis further configured to grant access
`to the userif at least the submitted passwordis based at least upon the token and matchesthevalid password. In another aspect, the user token serveris further
`configured to generate the valid password based additionally upon a valid passcodethat is knownto theuser. In another aspect, the user token serveris further
`configured to transmit the token in responseto a requestby the user. In anotheraspect, the user token serveris further configured to associate the valid password with a
`valid userID, the authentication moduleis further configured to receive a submitted userID in responseto the request for authentication, and the authentication module
`is further configured to grant accesstotheuserif, in addition, the submitted user ID matchesthe valid userID.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The presentinvention will be described below in connection with the attached drawingsin which:
`
`FIG. 1 illustrates an overview,including system components,of a user authentication system according to a preferred embodimentof the present invention;
`
`FIGS. 2A-D illustrate login screens that can be usedin conjunction with various embodimentsofthe 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 whichthe usertokenserver provides tokens and administrates user accounts;
`
`FIGS. 6A-Cillustrate three embodiments of a token delivery communicationlink;
`
`FIGS. 7A-B illustrate two embodimentsof a token request communication link; 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 whichthe invention may be practiced. Where possible, the same reference numbers are used throughoutthe 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 present invention,
`however, may be practiced without the specific details or with certain alternative equivalent devices and methodsto those described herein. In other instances,well-
`known methodsand devices have not been describedin detail so as not to unnecessarily obscure aspects of the presentinvention.
`
`|. Overview and System Components
`
`FIG. 1 illustrates an overview, including system components,of a user authentication system 100 according to a preferred embodimentof the presentinvention. FIG. 2A
`illustrates a login screen that can be usedin accordancewiththe preferred embodiment. FIGS. 2B-D illustrate login screens that can be used in accordancewith
`alternative embodiments.
`
`The user authentication system 100 includes 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
`phone having SMS (short messageservice) 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 computerworkstation, 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 ofa building.
`The secure system 110 is preferably connectedto 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 user authentication server 102 preferably includes a program or a 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 whichthe 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 andusedtoidentify the user 108. The passcode 154is preferably secret and only knownto the user 108. The
`token 156is 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 hasalimited lifespan, such as 1 minute or 1 day. Accordingly, the user 108 needs to be in possession of 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 maliciouspartystill 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”witha valid token of “1234” to form a valid password of “abcd1234.” In this manner, a login screen suchasisillustrated in FIG. 2A, which
`is similar or 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,asisillustrated 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 componentof 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
`Ex. 2001
`
`https://patents.google.com/patent/US6993658B1/
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`3/15
`
`Ex. 2001
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`

`

`US6993658B1 - Use of personal communication devices for user authentication - Google Patents
`4/25/23, 5:19 PM
`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 password data (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 passworddata.
`
`The user authentication 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 overa 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 pageror mobile phoneservice provider. The text messaging
`service provider 104 then forwards the token 156 preferably in the form of a secure text messageto 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 connected to 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 104toits final destination.
`
`Preferably, the communication module 118 is also configured to receive requests for tokens 160. The userpreferably transmits a request for tokens 160 over a request
`communication link 107. The request communication link 107 may be the same communication link as the delivery communication link 105orit may be a differentlink.
`Various embodimentsof the token delivery communicationlink 105 and the token request communicationlink 107will be discussed in SectionIII 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, whichthe user token server 116 can useto identify the requesting user and respond
`with a new token 156. The token request 160 mayalsobein the form of a phonecall, in which case the user token server 116 mayuseacaller 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 forwarding to the user's personal communication
`device 106. The ISDN card 118 mayalso be configured to be accessible at a phone numberto receivecalls for requests for tokens 160.
`
`FIG. 3 illustrates a preferred process 300 performedby 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 communicationlink 107. In the preferred embodiment, the user's mobile phone 106 has SMS send 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 phoneis 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 phoneand 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 156to the user 108 at predeterminedintervals, such as onceper day wherethe tokenshavea lifespan of oneday.
`
`At a step 304 the user token server 116 generates a token 156. The token 156 maybe generated by any of a numberof methodsthat preferably produces a random or
`pseudo-random sequenceof numbers and/ordigits. The token 156is preferably long enough suchthatit cannot be guessed, but short enoughsuchthatit is relatively
`easyto 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 casethatthe 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 andstores the hash of the password 158in the user database 114 rather than storing
`the password 158itself. The hashis typically performed using a one-way hashing algorithm where the same password always produces the same hash,but where the
`password cannotbe determined from the hash. In typical systems, passwords 158are stored as hashesratherthanasplain 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-wayhashing algorithm before transmission to the authentication
`module 112. The authentication module 112 then compares hashesof passwordsrather than the passwords themselvesto authenticate the user 108.In this manner,
`passwords 158 need not be transmitted over any communicationlinks or computer networksasclear text. It will be apparent to one skilled in the art that the present
`invention can be implemented with or without the hashing of passwordsandthatincorporating hashing of passwords doesnot substantively affect the scopeorspirit of
`the invention. So as not to unnecessarily obscure aspectsof the present invention, a passwordasreferred to herein may be an unhashedor a hashed password. For
`example, a receipt of a password maybe 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 156 to 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
`messageincluding the token 156to 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 108 logs 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.
`
`https://patents.google.com/patent/US6993658B1/
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`Ex. 2001
`
`4/15
`
`Ex. 2001
`Unified Patents, LLC v. Dynapass IP Holdings LLC, IPR2023-00425
`
`

`

`US6993658B1 - Use of personal communication devices for user authentication - Google Patents
`4/25/23, 5:19 PM
`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 hash of the password 158 that the secure system 110 creates in order to avoid sending the password 158
`over the computer network 103in cleartext. 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 156are not hashed.
`
`At a step 318, the user authentication server 102 authenticates the user 108 based uponthe login data 159. In orderto authenticate the user 108, the authentication
`server 102 preferably comparesthe 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.
`
`At a 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 processor program running onorin conjunction
`with the user authentication server 102. The user token server 116 may, however, include a computer upon whichthe processor program executes. The user token server
`116 preferably includes a control module 402, a supplemental user database 404, a communication module interface 406, and a token generation module 408. The
`various modules and componentsof the 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 tasksor 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, whichpreferably stores associations of user IDs with passcodes, phone numbersofusers’ personal communication devices, and any other supplemental
`user data. The other supplemental user data mayinclude one or moreof: 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 user interface 403 allows administration of userprivileges by adding, modifying and