`
`August 21, 2023
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`RECORDS OF THIS OFFICE OF THE FILE WRAPPER AND CONTENTS
`OF:
`
`APPLICATION NUMBER: 09/519,829
`FILING DATE: March 06, 2000
`PATENT NUMBER: 6993658
`ISSUE DATE: January 31, 2006
`
`EXPERIAN EXHIBIT 1002
`IPR2023-01406
`
`Page 1 of 429
`
`
`
`vy
`eo
`i
`
`annem eS
`ol
`ant un
`Se :
`i
`0
`
`eA _ OF7_Oe
`
`f
`
`:
`
`PATENT
`
`Attorney Docket No. APRILS.OO1A
`Date: March 6, 2000
`Page 1
`mo) s
`
`ASSISTANT COMMISSIONER FOR PATENTS
`2 S$
`SS
`.
`RSS Soe
`WASHINGTON, D.C. 20231
`SS
`& ° Se
`⇂∘≗↘⋛∖
`a
`So
`a
`S$ Q
`Ss
`
`ATTENTION: BOX PATENT APPLICATION
`⋅
`Sir:
`
`Transmitted herewith for filing is the patent application of
`
`Inventors: Sten-Olov Engberg and Ake Jonsson
`
`For: USE OF PERSONAL COMMUNICATION DEVICES FOR USER AUTHENTICATION
`
`Enclosed are:
`
`(X)
`
`A Specification in 21 pages
`
`(X)
`
`11 sheets of drawing.
`
`(X)
`
`An Information Disclosure Statement.
`
`(X)
`
`A PTO Form 1449 with three (3) references.
`
`(X)
`
`A return prepaid postcard.
`
`
`CLAIMS AS FILED
`
`
`FOR
`NUMBER
`NUMBER
`RATE
`FEE
`FILED
`EXTRA
`
`
`Basic Fee
`$690
`$690.00
`
`
`Total Claims
`27
`~20=
`7
`x
`$18
`$126.00
`
`
`Independent Claims
`4
`-3=
`1
`x
`$78
`$78.00
`
`
`If application contains any multiple dependent claims(s), then add
`$260
`$0
`
`
`FILING FEE TO BE PAID
`$894.00
`AT A LATER DATE
`
`(X)
`
`Please use Customer No. 20,995 for the correspondence address.
`
`
`
`istration No. 31,567
`
`mney of Record
`
`JTS-4508.DOC:ke
`20000306
`
`
`
`KNOBBE, MARTENS, OLSON & BEAR, LLP
`620 NEWPORT CENTER DR
`16TH FLOOR
`NEWPORT BEACH, CA 92660
`(949)
`760-0404
`FAX ($49) 760-9502
`
`
`
`
`
`Page 2 of 429
`
`
`
`INTELLECTUAL PROPERTY LAW
`
`PATENT, TRADEMARK AND COPYRIGHT CAUSES
`
`620 NEWPORT CENTER DRIVE
`
`SIXTEENTH FLOOR
`
`NEWPORT BEACH,
`
`€949) 760-0404
`
`FAX (949) 760-9502
`
`INTERNET:
`
`LOUIS J. KNOBBE"
`DON
`W. MARTENS"
`GORDON H. OLSON*
`JAMES 8. BEAR
`DARRELL L. OLSON*
`WILLIAM 8. BUNKER
`WILLIAM H. NIEMAN
`ARTHUR S, ROSE
`JAMES F. LESNIAK
`NED A. ISRAELSEN
`DREW S. HAMILTON
`JERRY T. SEWELL
`JOHN B. SGANGA, JR
`EDWARD A. SCHLATTER
`GERARD VON HOFFMANN
`JOSEPH R,
`RE
`CATHERINE J. HOLLAND
`JOHN M. CARSON
`KAREN VOGEL WEIL
`ANDREW H. SIMPSON
`JEFFREY L. VAN HOOSEAR
`DANIEL E. ALTMAN
`MARGUERITE L
`GUNN
`STEPHEN C. JENSEN
`VITO A. CANUSO ill
`WILLIAM H. SHREVE
`LYNDA J. ZADRA-SYMESt
`STEVEN J. NATAUPSKY
`PAUL A. STEWART
`JOSEPH F. JENNINGS
`CRAIG S. SUMMERS
`ANNEMARIE KAISER
`BRENTON R. BABCOCK
`
`SMEGAL, JR
`THOMAS F
`TRENHOLM
`MICHAEL H
`DIANE M
`REED
`JONATHAN A
`BARNEY
`RONALD J SCHOENBAUM
`JOHN R-
`KING
`FREDERICK S. BERRETTA
`NANCY WAYS VENSKO
`JOHN P
`GIEZENTANNER
`ADEEL S
`AKHTAR
`GINGER R
`DREGER
`THOMAS R
`ARNO
`DAVID N
`WEISS
`DANIEL HART, PHD
`DOUGLAS G. MUEHLHAUSER
`LORI
`LEE YAMATO
`MICHAEL K
`FRIEDLAND
`STEPHEN M_
`LOBBIN
`STACEY R
`HALPERN
`OALE C. HUNT, PHD
`LEE W
`HENDERSON, PH D
`DEBORAH S
`SHEPHERD
`RICHARD E
`CAMPBELL
`MARK M
`A8UMERI
`JON W
`GURKA
`ERIC M
`NELSON
`ALEXANDER C
`CHEN
`MARK R
`BENEDICT, PHD
`PAUL N
`CONOVER
`ROBERT uy
`ROBY
`SABING H
`LEE
`KAROLINE A. DELANEY
`JOHN W
`HOLCOMB
`
`KNOBBE, MARTENS, OLSON & BEAR
`A LIMITED LIABILITY PARTNERSHIP INCLUDING
`PROFESSIONAL CORPORATIONS
`
`MULLEN, IH, PHD
`JAMES J
`CIANFRANI
`JOSEPH S
`REISMAN, PHD
`JOSEPH M
`ZIMMERMAN
`WILLIAM Ro
`GLEN L. NUTTALL
`ERIC
`S
`FURMAN, PHD
`DO
`TE
`KiM
`TIRZAH ABE LOWE
`GEOFFREY Y. IDA
`ALEXANDER S FRANCO
`SANJIVPAL S)
`GILL
`SUSAN M
`MOSS
`JAMES W.
`HILL, MD
`ROSE M
`THIESSEN, PHD
`MICHAEL L
`FULLER
`MICHAEL A
`GUILIANA
`MARK J
`KERTZ
`RABINDER N
`NARULA
`BRUCE S
`!TCHKAWITZ, PHD
`PETER M
`MIDGLEY
`THOMAS S
`MCCLENAHAN
`MICHAEL S$, OKAMOTO
`JOHN M
`GROVER
`MALLARY K MCCARTHY
`IRFAN A
`LATEEF
`AMY C
`CHRISTENSEN
`SHARON S
`NG
`MARK J
`GALLAGHER, PHD
`DAVID G. JANKOWSKI, PHD
`BRIAN C
`HORNE
`PAYSON J
`LEMEILLEUR
`
`OF COUNSEL
`JERRY R
`SEILER
`
`JAPANESE PATENT ATTY
`KATSUHIRO ARAI*™
`
`EUROPEAN PATENT ATTY
`MARTIN HELLEBRANDT
`
`KOREAN PATENT ATTY
`MINCHEOL KIM
`
`SCIENTISTS & ENGINEERS
`(NON-LAWYERS)
`
`*
`
`SALENIEKS*"
`RAIMOND J
`NEIL S, BARTFELD, PHD **
`DANIEL E
`JOHNSON, PHD *
`JEFFERY KOEPKE, PH OD
`KHURRAM RAHMAN, PHD
`JENNIFER A
`HAYNES, PHD
`BRENDAN P
`O NEILL, PHD
`THOMAS Y
`NAGATA
`ALAN C
`GORDON
`LINDA H
`LIU
`MICHAEL J
`HOLIHAN
`YASHWANT VAISHNAV, PH.D
`MEGUMI TANAKA
`
`* A PROFESSIONAL CORPORATION
`7 ALSO BARRISTER AT LAW (UK >
`*“* U,S, PATENT AGENT
`
`Assistant Commissioner for Patents
`Washington, D.C. 20231
`
`CERTIFICATE OF MAILING BY "EXPRESS MAIL"
`
`Attorney Docket No.
`
`Applicant(s)
`
`For
`
`Attorney
`
`"Express Mail"
`Mailing Label No.
`
`Date of Deposit
`
`:
`
`:
`
`:
`
`:
`
`APRILS.001A
`
`Sten-Olov Engberg, et al.
`
`USE OF PERSONAL COMMUNICATION
`DEVICE FOR USER AUTHENTICATION
`
`Jerry T. Sewell
`
`EL 103 698 371 US
`
`March 6, 2000
`
`I hereby certify that the accompanying
`
`sheets of drawings;
`11
`21 pages;
`Transmittal in Duplicate; Specification in
`Information Disclosure Statement, PTO Form 1449 with three (3) references;
`Return Prepaid Postcard
`
`are being deposited with the United States Postal Service "Express Mail Post Office to
`Addressee" service under 37 CFR 1.10 on the date indicated above and-are addressed-to the
`Assistant Commissioner for Patents, Washington, D, Cc: 20231.
`4 /
`
`JTS-4507.DOC:ke
`
`201 29000306. STREET
`SUITE 1150
`SAN FRANCISCO, CALIFORNIA 94111
`(415) 954-4114
`FAX (415) 954-4111
`
`
`
`
`
`
`
` ee
`~ Deriald King~
`a
`
`301 WEST BROADWAY
`SUITE 1400
`SAN DIEGO, CALIFORNIA 92101
`(619) 235-8550
`FAX (619) 235-0176
`
`a
`
`3801 UNIVERSITY AVENUE
`SUITE 710
`RIVERSIDE, CALIFORNIA 92501
`(909) 781-9231
`FAX (909) 781-4507
`
`1875 CENTURY PARK EAST
`SUITE 600
`LOS ANGELES, CALIFORNIA
`(310) 407-5484
`FAX (310) 407-5485
`
`90067
`
`
`
`Page 3 of 429
`
`
`
`APRILS.O01A
`
`PATENT
`
`USE OF PERSONAL COMMUNICATION DEVICES FOR USER
`
`AUTHENTICATION
`
`Background of the Invention
`
`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 communication devices
`
`10
`
`such as mobile telephones and pages.
`
`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
`
`15
`
`networks of workstations 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 systems over the Internet has
`
`weakened traditional controls imposed by a user’s required physical presence within a
`
`20
`
`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
`
`25
`
`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 letters, numbers, and symbols often results in the
`
`password being written down, sometimes on a note stuck to the side of a workstation.
`
`30
`
`Present systems face several problems: users dread frequent password changes,
`
`frequent password changes with hard-to-remember passwords inevitably result in users
`
`-l-
`
`
`
`Page 4 of 429
`
`
`
`surreptitiously writing down passwords, and security is compromised when users write
`
`down their passwords.
`
`The SecurID product, which is distributed by RSA Security Inc., solves many of
`
`the aforementioned problems by requiring a two-factor authentication process. The first
`
`factor is
`
`a user passcode or personal identification number.
`
`The second factor is
`
`a
`
`SecurID card that is possessed by the user.
`
`The SecurID 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 SecurID 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 SecurID system could be achieved using a device that many users already carry -
`
`a personal communication device such as a mobile phone or a pager.
`
`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.
`
`The user token server generates a random token in
`
`10
`
`15
`
`20
`
`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
`
`25
`
`30
`
`-2.
`
`
`
`Page 5 of 429
`
`
`
`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 password.
`
`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 additionally 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 communication device is a pager.
`
`10
`
`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.
`
`15
`
`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
`
`20
`
`control module is further configured 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
`
`25
`
`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
`
`30
`
`ID and a password.
`
`In another aspect, the password comprises a passcode and the
`
`token. In another aspect, the password is a concatenation of the passcode and the token.
`
`-3-
`
`
`
`Page 6 of 429
`
`
`
`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.
`
`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 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
`
`10
`
`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
`
`15
`
`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 authentication, and the authentication module is further configured to grant access to
`
`20
`
`the user if, in addition, the submitted user ID matches the valid user ID.
`
`Brief Description of the Drawings
`
`
`
`The present invention will be described below in connection with the attached
`
`drawings in which:
`
`25
`
`Figure 1
`
`illustrates
`
`an overview, including system components, of a user
`
`authentication system according to a preferred embodiment of the present invention;
`
`Figures 2A-D illustrate login screens that can be used in conjunction with
`
`various embodiments of the invention;
`
`Figure 3 illustrates a preferred process performed by the system to authenticate
`
`30
`
`users;
`
`Figure 4 illustrates a preferred embodiment of a user token server;
`
`-4-
`
`
`
`Page 7 of 429
`
`
`
`Figure 5 illustrates a preferred process by which the user token server provides
`
`tokens and administrates user accounts;
`
`Figures 6A-C illustrate three embodiments of a token delivery communication
`
`link;
`
`Figures 7A-B illustrate two embodiments of a token request communication
`
`link; and
`
`Figure 8 illustrates an embodiment of a combined token request and delivery
`
`communication link.
`
`10
`
`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
`
`15
`
`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
`
`20
`
`obscure aspects of the present invention.
`
`I.
`
`Overview and System Components
`
`Figure 1
`
`illustrates
`
`an overview, including system components, of a user
`
`authentication system
`
`100 according to
`
`a preferred embodiment of the present
`
`invention.
`
`Figure 2A illustrates login screen that can be used in accordance with the
`
`25
`
`preferred embodiment.
`
`Figures 2B-D illustrate a login screens that can be used in
`
`accordance with 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.
`
`30
`
`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
`
`5.
`
`
`
`Page 8 of 429
`
`
`
`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
`
`10
`
`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.
`
`15
`
`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
`
`20
`
`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 | day. Accordingly, 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
`
`25
`
`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
`
`“abcd1234.” In this manner, a login screen such as is illustrated in Figure 2A, which is
`
`30
`
`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
`
`-6-
`
`
`
`Page 9 of 429
`
`
`
`submitted separately, as
`passcode 154 is null in which case the token 156 alone is used as the password 158.
`
`is illustrated in Figure 2B.
`
`In another embodiment, the
`
`In
`
`still another embodiment, the token 156 can be requested through the secure system 110
`
`as is illustrated in Figures 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 Windows NT that authenticates users upon login.
`
`In
`
`10
`
`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 responds to an authentication
`
`request transmitted over the computer network 103 by supplying an authentication
`
`15
`
`confirmation 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
`
`20
`
`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
`
`25
`
`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 communication 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
`
`30
`
`communication 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
`
`-7-
`
`
`
`
`
`Page 10 of 429
`
`
`
`available Ericsson T-28.
`authentication server 102 via a presently available serial port cable that makes the phone
`user
`Accordingly, the
`
`a manner similar to
`
`a computer modem.
`
`accessible in
`authentication server 102 can send tokens 156 via the server’s mobile phone 118 to the
`In this case, the server’s mobile phone 118
`
`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
`The mobile phone 118 is preferably connected to the user
`
`user’s mobile phone 106 using SMS.
`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 configured to receive requests
`The user preferably transmits a request for tokens 160 over a request
`107 may be the same
`
`The request communication link
`
`for tokens 160.
`
`107.
`communication link
`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 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
`The token request 160 may also be in the form of a phone call, in which
`token 156.
`case the user token server 116 may use a caller ID feature to identify the calling phone
`The user token server
`number as a valid user’s personal communication device 106.
`Alternatively, the user token server 116
`
`116 can then respond with a new token 156.
`may allow a calling user 108 to enter the phone number of his personal communication
`device 106 using the mobile phone keypad once a connection has been established.
`
`-8-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`Page 11 of 429
`
`
`
`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
`The ISDN card 118 preferably transmits new tokens directly to the text
`connection.
`messaging service provider 104 for forwarding to the user’s personal communication
`The ISDN card 118 may also be configured to be accessible at a phone
`
`device 106.
`
`number to receive calls for requests for tokens 160.
`Figure 3 illustrates a preferred process 300 performed by the system 100 to
`At a step 302, the user 108 requests a token from the user token
`
`authenticate users.
`
`107.
`
`In the preferred
`
`server 116 through the token request communication link
`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
`The user token
`sending mobile phone is automatically sent along with the message.
`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
`the
`to
`106
`108 makes a phone call with his personal communication device
`The user token server 116 identifies the user’s personal
`communication module 118.
`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
`As another
`156 through the secure system 110 itself as illustrated in Figures 2C-D.
`In this case, the user token server
`
`alternative, the step 302 may be omitted altogether.
`116 can automatically send tokens 156 to the user 108 at predetermined 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.
`may be generated by any of a number of methods that preferably produces a random or
`The token 156 is preferably long
`
`The token 156
`
`pseudo-random sequence of numbers and/or digits.
`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.
`server 116 preferably creates the new password 158 by combining the user’s passcode
`
`The token
`
`-9-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`Page 12 of 429
`
`
`
`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
`In the case that the user’s account in the user database 114 is inactive or
`
`158.
`
`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 hash of the password 158 in the user database 114 rather than storing
`The hash is typically performed using a one-way hashing
`the password 158 itself.
`algorithm where the same password always produces the same hash, but where the
`In typical systems, passwords 158 are
`password cannot be determined from the hash.
`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
`The authentication
`algorithm before transmission to the authentication module 112.
`module 112 then compares hashes of passwords rather than the passwords themselves to
`In this manner, passwords 158 need not be transmitted over
`authenticate the user 108.
`It will be apparent to one
`any communication links or computer networks as clear text.
`skilled in the art that the present invention can be implemented with or without the
`not
`does
`of passwords
`hashing
`incorporating
`
`and
`
`that
`
`hashing
`
`of passwords
`
`substantively affect the scope or spirit of the invention.
`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
`a
`of an unhashed or hashed password, and a comparison of passwords may be
`
`So as not to unnecessarily
`
`comparison of unhashed or hashed passwords.
`At a step 310, the token server 116 transmits the token 156 to the user’s personal
`In the
`communication device 106 via the token delivery communication link 105.
`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
`At
`message including the token 156 to the user’s personal communication module 106.
`a step 312, the user 108 receives the token through his personal communication device
`
`106.
`
`-10-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`Page 13 of 429
`
`
`
`Ata
`
`step 314, the user 108 logs into the secure system 110 using the user ID 152
`In the preferred embodiment, the user 108 combines the
`and the password 158.
`In an
`passcode 154 and the token 156 by concatenation to form the password 158.
`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 password
`158 that the secure system 110 creates in order to avoid sending the password 158 over
`the computer network 103 in clear text. Alternatively, the login data 159 may include a
`As another alternative, the password 158,
`hash of the passcode 154 and the token 156.
`
`or the passcode 154 and token 156 are not hashed.
`At astep 318, the user authentication server 102 authenticates the user 108 based
`upon the login 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.
`At a step 320, the user authentication server 102 transmits an authentication
`confirmation 162 to the secure system 110. Ata step 322, the secure system 110 allows
`the user 108 access based upon the authentication confirmation 162.
`
`I.
`
`408.
`
`The
`
`in
`
`The user
`
`10
`
`15
`
`20
`
`25
`
`
`
`The User Token Server
`Figure 4 illustrates a preferred embodiment of the user token server 116.
`user token server 116 preferably includes a process or program running on or
`The user token server 116 may,
`conjunction with the user authentication server 102.
`however, include a computer upon which the process or program executes.
`a supplemental user
`116 preferably includes a control module 402,
`token server
`database 404, a communication module interface 406, and a token generation module
`The various modules and components of the user token server 116 are described
`The various functional components may,
`herein from a functional perspective.
`or more executable programs, data
`however, be seamlessly integrated into
`
`one
`
`30
`
`structures, and/or physical component