USOO6993658B1
`
`(12) United States Patent
`Engberg et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,993,658 B1
`Jan. 31, 2006
`
`(54) USE OF PERSONAL COMMUNICATION
`DEVICES FOR USER AUTHENTICATION
`
`(75) Inventors: Sten-Olov Engberg, Storvreta (SE);
`Ake Jonsson, Fagersta (SE)
`(73) Assignee: April System Design AB, Solna (SE)
`
`6,161,182. A 12/2000 Nadooshan
`6,173,400 B1
`1/2001 Perlman et al.
`6,226,364 B1* 5/2001 O’Neil .................... 379/1142
`6,795,852 B1* 9/2004 Kleinrock et al. .......... 709/220
`FOREIGN PATENT DOCUMENTS
`A-63545/98
`5/1998
`
`AU
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`(21) Appl. No.: 09/519,829
`
`(Continued)
`OTHER PUBLICATIONS
`Menezes, “Handbook of Applied Cryptography,” 1997, p.
`390.*
`
`Mar. 6, 2000
`
`(Continued)
`Primary Examiner-Gilberto Barro?, Jr.
`Assistant Examiner-Matthew Heneghan
`(74) Attorney, Agent, or Firm-Knobbe, Martens, Olson &
`Bear LLP
`(57)
`
`ABSTRACT
`
`(56)
`
`:
`
`:
`
`:
`
`:
`
`:
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,153919
`5,265,155
`5,323,146
`5,497.411
`5,590,198
`5,749,075
`5,875,394
`5,923,763
`5,949.882
`5,956,633
`6,049,877
`6,075.860
`6,078,908
`
`(22) Filed:
`(51) Int. Cl.
`(2006.01)
`G07F 7/10
`(2006.01)
`H04L 9/32
`(2006.01)
`H04L 12/14
`(2006.01)
`H04M I5/00
`(52) U.S. Cl. ................... 713/185.379/1142; 709/219;
`713/183; 713/201; 713/202
`(58) Field of Classification Search - - - - - - - - - - - - - - - - 3802, A password Setting System for a Secure System includes a
`380/249; 455.411; 13,202, 12, 183,185;
`user token Server and a communication module. The user
`705/74; 235/382.5; 379/ 1142: 709/219
`token Server generates a random token in response to a
`See application file for complete Search history.
`request for a new password from a user. The Server creates
`a new password by concatenating a secret passcode that is
`known to 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 phone
`or a pager carried by the user. The user concatenates the
`Secret passcode with 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 known to the user, Such as the
`user ID, Secret information known to the user, Such as the
`passcode; and information provided to the user through an
`object possessed by the user, Such as the token.
`
`10/1992 Reeds et al. .................. 380/44
`11/1993 Castro .........
`... 379/1142
`6/1994 Glaschick ................... 713/202
`3/1996 Pellerin ...................... 455/411
`12/1996 Lee et al.
`5/1998 Toader et al. ................. 705/14
`2/1999 Daly et al. .................. 455/411
`7/1999 Walker et al.
`9/1999 Angelo ....................... 713/185
`9/1999 Janhila ....................... 455/410
`4/2000 White
`6/2000 Ketcham .................... 713/185
`6/2000 Schmitz ...
`705/50
`
`7 Claims, 11 Drawing Sheets
`
`2
`
`\a
`wfa
`
`SECURE
`SYSTEM
`
`o
`
`is
`-/32
`user - 5
`co-
`PASSWORD - EP
`
`f
`N
`LGN DAA. --
`
`AUTHENTCATION
`CONFIRMATION
`
`Na
`
`N
`
`USER AUTHENTCATON
`SERVER
`
`
`
`
`
`
`
`USER D &
`PASSWORD
`
`TOKEN/
`PASSWORD
`
`a.
`
`a
`
`Aaf
`
`7a
`
`N
`is
`TOKEN REQUEST
`--------------
`( (c.
`Ioke-/se
`
`TOKEN
`REQUEST
`
`USER WITH PERSONAL
`COMMUNCATION
`DEWIC
`
`TEXT
`MESSAGNS
`SERVICE
`PROWER
`
`
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 1 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`US 6,993,658 B1
`Page 2
`
`FOREIGN PATENT DOCUMENTS
`
`AU
`EP
`
`98.63545 A * 11/1998
`O 875 871 A2 11/1998
`
`OTHER PUBLICATIONS
`Security Dynamics-Securild Tokens DataSheet, http://www.
`computerterps.com/internet/security/Secdyn/tokens.html.,
`last modified Jul. 31, 1998.
`ACE/Server, http://www.computerps.com/internet/security/
`secclyn/aceserv.html, last modified Jul. 15, 1998.
`
`RSA Security Inc.-RSA Securil) Two-Factor Authenication
`System,
`http://www.Securid.com/products/Securid/index.
`html., printed on Mar. 3, 2000.
`24-hour cellphone cyberwatch-Internet-printed on May
`19, 2000.
`Monkey as authentication Software-Internet-2 pages,
`printed on May 19, 2000.
`Monkey (mobile network key)-Internet-6 pages, printed
`on May 19, 2000.
`International Search Report for PCT/US01/07058 (3-pages).
`* cited by examiner
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 2 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 1 of 11
`
`US 6,993,658 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`~~
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 3 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 2 of 11
`
`US 6,993,658 B1
`
`Logon To Network:
`
`Note: Your password is your passcode followed by a valid token
`
`A7C2 24
`
`Logon To Network:
`
`A762. 2A
`
`Please enter a user ID to request a Token
`Token will be instantly transmitted to your registered Personal
`Communication Device and will be valid for one minute
`
`
`
`
`
`A762. 2C
`
`
`
`Logon To Network;
`
`A762
`
`2/2
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 4 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 3 of 11
`
`US 6,993,658 B1
`
`377
`
`\
`
`USER REQUESTS TOKEN
`FROM TOKEN SERVER
`
`TOKEN SERVER
`GENERATES TOKEN
`
`322
`
`3O2
`
`376
`
`TOKEN SERVER GENERATES PASSWORD
`BASED UPON PASSCODE AND TOKEN
`
`TOKEN SERVER UPDATES PASSWORD AND
`ACTIVATES USER ACCOUNT IN USER DATABASE
`
`3O-5
`
`57.7
`
`TOKEN SERVER TRANSMTS TOKEN TO USER'S
`PERSONAL COMMUNICATION DEVICE
`
`USER RECEIVES TOKEN
`
`37.2
`
`57-2
`
`USER LOGS INTO SECURE SYSTEM
`USING USER D AND PASSWORD
`
`576
`
`SECURE SYSTEM TRANSMTS LOGN DATA
`TO USER AUTHENTICATION SERVER
`
`USER AUTHENTCATION SERVER
`AUTHENTCATES USER BASED UPON LOGIN DATA
`
`USER AUTHENTCATION SERVER TRANSMITS
`AUTHENTICATION CONFIRMATION TO
`SECURE SYSTEM
`
`
`
`322
`
`A62 3.
`
`CCESS
`USER A
`
`376
`
`32O
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 5 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 4 of 11
`
`US 6,993,658 B1
`
`
`
`USER TOKEN SERVER
`
`4622
`
`CONTROL MODULE
`
`ADMNSTRATOR
`USER INTERFACE
`
`SUPPLEMENTAL
`USER DATABASE
`
`COMMUNICATION MODULE
`INTERFACE
`
`4O4.
`
`2O6
`
`TOKEN GENERATION
`MODULE
`
`265
`
`A7C2 4
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 6 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 5 of 11
`
`US 6,993,658 B1
`
`57.7 Ya
`
`ASSOCATE USER D WITH PASSCODE AND PHONE
`NUMBER OF USER'S PERSONAL COMMUNICATION
`DEVICE
`
`a22
`
`RECEIVE TOKEN REQUEST
`
`ASSOCATE TOKEN REQUEST
`WITH USER ID
`
`3O42
`
`5Oas
`
`GENERATE TOKEN
`
`as
`
`57O
`
`GENERATE PASSWORD BASED UPON
`PASSCODE AND TOKEN
`
`SET PASSWORD IN USER DATABASE
`AND ACTIVATE USER ID
`
`
`
`as 72
`
`574
`
`5
`76
`
`
`
`TRANSMT TOKEN TO USERS PERSONAL
`COMMUNICATION DEVICE BASED UPON PHONE
`NUMBER ASSOCATED WITH USER D
`
`USER CAN ACCESS SECURE SYSTEM BY
`LOGGING IN USING TOKEN
`
`TOKEN EXPRES
`
`67a;
`
`32O
`
`DEACTIVATE USER ACCOUNT
`IN USER DATABASE
`
`AC as
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 7 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 6 of 11
`
`US 6,993,658 B1
`
`
`
`
`
`962/
`~
`
`ºs,
`
`
`
`?– NEMOI?— NEXIOL
`
`(((((((((((((((((((<(((((((((((((((((((
`
`
`
`30\/SSEW SWSE0\/SSIE W SWS
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 8 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`US 6,993,658 B1
`
`
`
`
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 9 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`US 6,993,658 B1
`
`
`
`
`
`92,9
`
`
`
`TITIVO ENOHC;
`
`•,,
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 10 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`UNIFIED PATENTS EXHIBIT 1001
`Page 11 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`Jan. 31, 2006
`
`Sheet 10 of 11
`
`US 6,993,658 B1
`
`&
`
`s
`
`
`
`s
`
`
`
`
`
`&
`
`
`
`-S
`
`Š
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 12 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`U.S. Patent
`
`US 6,993,658 B1
`
`
`
`
`
`
`
`3,29
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 13 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`US 6,993,658 B1
`
`1
`USE OF PERSONAL COMMUNICATION
`DEVICES FOR USER AUTHENTICATION
`
`BACKGROUND OF THE INVENTION
`
`15
`
`25
`
`1. Field of the Invention
`This invention relates generally to the authentication of
`users of Secure Systems and, more particularly, the invention
`relates to a System through which user tokens required for
`user authentication are Supplied through personal commu
`nication devices Such as mobile telephones and pagers.
`2. Description of the Related Art
`Secure systems have traditionally utilized a user ID and
`password pair to identify and authenticate System users.
`Operating Systems that control local area networks of work
`stations within a business or institution Such as Novell
`NetWare, Microsoft NT, Windows 2000, and UNIX/Linux
`typically require Submission of a user ID and password
`combination before allowing access to a WorkStation.
`The incorporation of remote connectivity to Secure SyS
`tems over the Internet has weakened traditional controls
`imposed by a user's required physical presence within a
`company's premises and has exposed Systems to additional
`Security threats. External users accessing by dial-in or over
`the Internet, complicated by frequent perSonnel turnover,
`require frequent changes in password lists.
`Passwords created by users are often combinations of
`words and names, which are easy to remember but also
`easily guessed. Guessing passwords is a frequent technique
`used by “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 word in the dictionary. A
`user's inability to remember complex combinations of let
`35
`ters, numbers, and Symbols often results in the password
`being written down, Sometimes on a note Stuck to the Side
`of a WorkStation.
`Present Systems face Several problems: users dread fre
`quent password changes, frequent password changes with
`40
`hard-to-remember passwords inevitably result in users Sur
`reptitiously writing down passwords, and Security is com
`promised when users write down their passwords.
`The SecurD product, which is distributed by RSA Secu
`rity Inc., Solves many of the aforementioned problems by
`requiring a two-factor authentication process. The first fac
`tor is a user passcode or personal identification number. The
`Second factor is a SecurD card that is possessed by the user.
`The SecurD 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
`generator that allows verification of possession of the card.
`The SecurD product, however, requires users to carry an
`additional item on their perSon in order to access a Secure
`system. It would be advantageous if the benefits of the
`SecurD System could be achieved using a device that many
`users already carry-a personal communication device Such
`as a mobile phone or a pager.
`
`45
`
`50
`
`55
`
`SUMMARY OF THE INVENTION
`
`A preferred embodiment of the present invention is a
`password Setting System for Setting user passwords for 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.
`
`60
`
`65
`
`2
`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 passcode
`that is known to 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 phone
`or a pager carried by the user. The user concatenates the
`Secret passcode with 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 known to the user, Such as the
`user ID, Secret information known to the user, Such as the
`passcode; and information provided to the user through an
`object possessed by the user, Such as the token.
`One aspect of the invention is a method for Setting
`passwords. The method includes associating a user ID with
`a phone number of a personal communication device. The
`method also includes generating a new password based at
`least upon a token. The method also includes Setting a
`password associated with the user ID to be the new pass
`word. The method also includes transmitting the token to the
`personal communication device using the phone number
`asSociated with the user ID. In another aspect, the method
`also includes associating the user ID with a passcode. In
`another aspect, the new password is generated based addi
`tionally upon the passcode. In another aspect, the method
`also includes receiving a request for the user token. In
`another aspect, the personal communication device is a
`mobile phone. In another aspect, the personal communica
`tion device is a pager.
`An additional aspect of the invention is a password setting
`System. The System includes a first user database configured
`to associate a user ID with a phone number of a personal
`communication device. The System also includes a control
`module configured to create a password based at least upon
`a token. The control module is further configured to cause a
`Second user database to associate the password with the user
`ID. 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 number associated with the user ID. 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 module is further config
`ured to create the password based additionally upon the
`passcode.
`An additional aspect of the invention is a method of
`regulating access to a Secure System. The method includes
`transmitting a user token to a personal communication
`device. The method also includes receiving login data in
`response to a request for authentication information,
`wherein the login data is based at least upon the user token.
`The method also includes granting access to the Secure
`System based upon the received login data. In another
`aspect, the login data is additionally based upon a user ID.
`In another aspect, the login data comprises a user ID. 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 com
`prises a passcode and the token. In another aspect, the
`password is a concatenation of the passcode and the token.
`In another aspect, the password is a hashed concatenation of
`the passcode and the token. In another aspect the method
`also includes generating the user token. In another aspect the
`method also includes receiving a request for the user token.
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 14 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`3
`In another aspect, the personal communication device is a
`mobile phone. In another aspect, the personal communica
`tion device is a pager.
`An additional aspect of the invention is an access control
`System. The System includes a user token Server configured
`to transmit a token to a personal communication device. The
`user token Server is further configured to generate a valid
`password based at least upon the token. The System also
`includes an authentication module configured to receive at
`least a Submitted password in response to a request for
`authentication of a user. The authentication module is further
`configured to grant access to the user if at least the Submitted
`password is based at least upon the token and matches the
`valid password. In another aspect, the user token Server is
`further configured to generate the valid password based
`additionally upon a valid passcode that is known to the user.
`In another aspect, the user token Server is further configured
`to transmit the token in response to a request by the user. In
`another aspect, the user token Server is further configured to
`associate the valid password with a valid user ID, the
`authentication module is further configured to receive a
`Submitted user ID in response to the request for authentica
`tion, and the authentication module is further configured to
`grant access to the user if, in addition, the Submitted userID
`matches the valid user ID.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present invention will be described below in connec
`tion with the attached drawings in which:
`FIG. 1 illustrates an Overview, including System compo
`nents, of a user authentication System according to a pre
`ferred embodiment of the present invention;
`FIGS. 2A-D illustrate login screens that can be used in
`conjunction with various embodiments of the invention;
`FIG. 3 illustrates a preferred process performed by the
`System to authenticate users,
`FIG. 4 illustrates a preferred embodiment of a user token
`Server,
`FIG. 5 illustrates a preferred process by which the user
`token Server provides tokens and administrates user
`acCOuntS,
`FIGS. 6A-C illustrate three embodiments of a token
`delivery communication link,
`FIGS. 7A-B illustrate two embodiments of a token
`request communication link, and
`FIG. 8 illustrates an embodiment of a combined token
`request and delivery communication link.
`
`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 way of illustration, Specific embodiments or
`processes in which the invention may be practiced. Where
`possible, the same reference numbers are used throughout
`the drawings to refer to the same or like components. In
`Some instances, numerous specific 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 methods to those described herein. In
`other instances, well-known methods and devices have not
`been described in detail So as not to unnecessarily obscure
`aspects of the present invention.
`
`US 6,993,658 B1
`
`4
`I. Overview and System Components
`FIG. 1 illustrates an Overview, including System compo
`nents, of a user authentication System 100 according to a
`preferred embodiment of the present invention. FIG. 2A
`illustrates a login Screen that can be used in accordance with
`the preferred embodiment. FIGS. 2B-D illustrate login
`Screens that can be used in accordance with alternative
`embodiments.
`The user authentication system 100 includes an authen
`tication 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 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 which it is desired to limit
`access to authenticated users. The Secure System 110 may be,
`for example, a user account on a network of computer
`WorkStations, a user account on a web site, 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 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 may also include the computer
`System and hardware upon which the programs run. 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 may be publicly known and used to
`identify the user 108. The passcode 154 is preferably secret
`and only known to 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 needed basis. The token 156 preferably
`has a limited lifespan, Such as 1 minute or 1 day. Accord
`ingly, the user 108 needs to be in possession of his personal
`communication device 106 in order to gain access to the
`secure system 110. Therefore, if the user's user ID 152 and
`passcode 154 are compromised, a malicious party Still
`cannot access the Secure System without possession of the
`personal communication device 106.
`In the preferred embodiment, the user 108 combines the
`token 156 with the passcode 154 to form a password 158.
`For example, the user 108 can combine a valid, memorized
`passcode of “abcd” with a valid token of “1234" to form a
`valid password of “abcd 1234.” In this manner, a login screen
`Such as is illustrated 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,
`as is illustrated in FIG. 2B. In another embodiment, the
`passcode 154 is null in which case the token 156 alone is
`used as the password 158. In still another embodiment, the
`token 156 can be requested through the secure system 110 as
`is illustrated 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
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 15 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`S
`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 Windows NT that authenticates users upon login. In
`alternative embodiments, the authentication module 112
`may be any code, device, or module capable of authenticat
`ing 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
`responds to an authentication request transmitted over the
`computer network 103 by Supplying an authentication con
`firmation 162 over the network 103. If the user 108 has been
`authenticated, the confirmation 162 instructs the Secure
`system 110 to allow access to 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 Windows NT. In alternative
`embodiments, the user database 114 can be any database
`capable of Storing user ID and password data.
`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
`passwords in the user database 114 based upon generated
`tokens and passcode data. The user authentication Server 102
`preferably transmits the tokens 156 over a token delivery
`communication link 105 to the user's personal communica
`tion device 106.
`The user authentication server 102 preferably also
`includes a communication module 118, which is also part of
`the token delivery communication link 105. The communi
`cation module 118 forwards tokens 156 to a text messaging
`service provider 104, which may be a pager or mobile phone
`Service 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 phone is the presently
`available Ericsson T-28. The mobile phone 118 is preferably
`connected to the user authentication Server 102 via a pres
`ently available Serial port cable that makes the phone
`accessible in a manner Similar 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 message including the token
`156 to the user's personal communication device 106 using
`the phone number of the user's personal communication
`device 106. During the transmission, the message is relayed
`by the mobile phone service provider 104 to its final
`destination.
`Preferably, the communication module 118 is also con
`figured to receive requests for tokens 160. The user prefer
`ably 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 105 or it may be a different link. Various
`embodiments of the token delivery communication link 105
`and the token request communication link 107 will be
`discussed in Section III below.
`In the preferred embodiment, the communication module
`118 is a mobile phone that also has SMS text messaging
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,993,658 B1
`
`6
`receive capability. The communication module 118 receives
`an SMS message from the user's mobile SMS send enabled
`mobile phone 106, and the token server 116 preferably
`processes the message as a token request 160. The incoming
`SMS message is tagged with the Sending phone's phone
`number, which the user token server 116 can use to identify
`the requesting user and respond with a new token 156. The
`token request 160 may also be in the form of a phone call,
`in which case the user token server 116 may use a caller ID
`feature to identify the calling phone number as a 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 may allow a calling user 108 to
`enter the phone number of his personal communication
`device 106 using the mobile phone keypad once a connec
`tion has been established.
`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 tokens directly to
`the text messaging Service provider 104 for forwarding to
`the user's personal communication device 106. The ISDN
`card 118 may also be configured to be accessible at a phone
`number to 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 SMS send
`capability and the user Sends an SMS message to the
`communication module 118 requesting a new token 156.
`The SMS message need not contain any data in its body
`Since the phone number of 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 number with which the SMS message
`is tagged. In an alternative embodiment, the user 108 makes
`a phone call 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 upon a caller ID feature. Alternatively, the
`user 108 may call from any phone and enter in the phone
`number of his personal communication device 106. As
`another alternative, the user 108 may request the token 156
`through the secure system 110 itself as illustrated in FIGS.
`2C-D. As another alternative, 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 predeter
`mined intervals, Such as once per day where the tokens have
`a lifespan of one day.
`At a step 304 the user token server 116 generates a token
`156. The token 156 may be generated by any of a number of
`methods that preferably produces a random or pseudo
`random sequence of numbers and/or digits. The token 156 is
`preferably long enough Such that it cannot be guessed, but
`Short enough Such that it is relatively easy to enter, Such as
`Six 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,
`which is 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 account in the user database 114 is inactive or
`deactivated, the token server 116 activates the user's
`acCOunt.
`
`UNIFIED PATENTS EXHIBIT 1001
`Page 16 of 20
`
`JPMORGAN EXHIBIT 1001
`
`

`

`7
`In the preferred embodiment, the token Server creates a
`hash of the password 158 and stores the hash of the
`password 158 in the user database 114 rather than storing the
`password 158 itself. The hash is typically performed using
`a one-way hashing algorithm where the same password
`always produces the same hash, but where the password
`cannot be determined from the hash. In typical Systems,
`passwords 158 are stored as hashes rather than as plain 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 hashing algorithm before transmission to the authenti
`cation module 112. The authentication module 112 then
`compares hashes of passwords rather than the passwords
`themselves to authenticate the user 108. In this manner,
`passwords 158 need not be transmitted over any communi
`cation links or computer networks as clear text. It will be
`apparent to one skilled in the art that the present invention
`can be implemented with or without the hashing of pass
`words and that incorporating hashing of passwords does not
`substantively affect the scope or 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 com
`parison 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 communication link 105. In the preferred
`embodiment, the communication module 118 is a mobile
`phone, and the user token server 116 uses the SMS send
`capability of the phone 118 to send an SMS message
`including the token 156 to the user's personal communica
`tion 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.
`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 passw