(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0093690 A1
`Kemper
`(43) Pub. Date:
`May 15, 2003
`
`US 20030093690A1
`
`(54) COMPUTER SECURITY WITH LOCAL AND
`REMOTE AUTHENTICATION
`(76) Inventor: Stefan Kemper, Boise, ID (US)
`Correspondence Address:
`HEWLETTPACKARD COMPANY
`Intellectual Property Administration
`P.O. BOX 272400
`Fort Collins, CO 80527-2400 (US)
`(21) Appl. No.:
`10/003,138
`(22) Filed:
`Nov. 15, 2001
`
`Publication Classification
`
`(51) Int. Cl." ....................................................... H04L 9/00
`(52) U.S. Cl. .............................................................. 713/201
`(57)
`ABSTRACT
`A Secure computer System including a client having a client
`database for locally-authenticating a user; and a Server, in
`communication with the client, having a Server database for
`remotely-authenticating the user in response to a request
`from the client. The System also provides updating of the
`client database according to results of the local and remote
`authentication.
`
`200
`
`
`
`
`
`
`
`REGUEST USERNAME
`AND PASSWORD
`102
`
`OUERY LOCAL
`DATABASE
`104
`
`LOCAL
`AUTHENTICATION
`
`RECORD
`FOUNDP
`106
`
`PASSWORDS
`MATCHP
`108
`
`GRANT ACCESS
`110
`
`
`
`QUERY REMOTE - 1.
`DATABASE
`114
`YES
`REMOTE
`AUTHENTCAT
`ICATION
`
`
`
`RECORD
`FOUNDP
`116
`
`MO
`
`-—----->
`
`
`
`
`
`
`
`
`
`
`
`|
`|
`:
`
`GRANTICONTINUE
`ACCESS
`128
`
`
`
`
`
`:
`
`y
`DENTERNATE
`120
`
`
`
`PASSWORDS
`MATCHP
`118
`--------- - YES
`w
`----
`y
`ADDRECORD TO LOCAL | DELETE RECORD FROM
`DATABASE
`:
`LOCAL DATABASE
`122
`124
`
`IPR2018-00067
`Unified EX1034 Page 1
`
`

`

`Patent Application Publication May 15, 2003 Sheet 1 of 3
`
`US 2003/0093.690 A1
`
`,
`
`CLIENT
`10
`
`
`
`CLIENT
`DATABASE
`12
`
`SERVER
`20
`
`
`
`SERVER
`DATABASE
`22
`
`L
`
`FIG. 1
`
`IPR2018-00067
`Unified EX1034 Page 2
`
`

`

`Patent Application Publication May 15, 2003 Sheet 2 of 3
`
`US 2003/0093.690 A1
`
`100 Y
`
`
`
`RECQUEST USERNAME
`AND PASSWORD
`102
`
`wo- or roos - - - - -w- ww.
`
`alth is a as or m as
`
`m or aws was a
`
`an
`
`FIG. 2
`
`LOCAL
`
`NO - - - - - - -
`
`OUERY LOCAL
`DATABASE
`104
`
`RECORD
`FOUND?
`106
`
`Ya
`
`PASSWORDS
`MATCH2
`N108
`
`
`
`
`
`
`
`GRANT ACCESS
`110
`
`
`
`QUERY REMOTE
`DATABASE
`114
`
`REMOTE
`AUTHENTCATION
`
`1
`RECORD
`FOUNDP
`116
`
`
`
`
`
`GRANT/CONTINUE
`ACCESS
`128
`
`1 PASSWORDS
`MATCH2
`118
`
`
`
`DENYITERMINATE
`ACCESS
`120
`
`ADD RECORD TO LOCAL
`DATABASE
`122
`
`DELETE RECORD FROM
`LOCAL
`DATABASE
`124
`
`IPR2018-00067
`Unified EX1034 Page 3
`
`

`

`Patent Application Publication May 15, 2003 Sheet 3 of 3
`
`US 2003/0093.690 A1
`
`200
`
`
`
`
`
`
`
`RECQUEST USERNAME
`AND PASSWORD
`102
`
`:
`
`FIG. 3
`
`LOCAL
`AUTHENTICATION
`
`OUERY LOCAL
`DATABASE
`104
`
`
`
`RECORD
`FOUND 2
`106
`
`
`
`M
`
`V YES
`u1
`PASSWORDS
`MATCH7
`108
`
`YES
`
`
`
`GRANT ACCESS
`110
`------------------ |------
`QUERY REMOTE
`SAME AS
`DATABASE
`- Y -
`LAST OUERY
`114
`YES
`112
`t
`REMOTE
`AUTHENTCATION
`RECORDS
`FOUND7
`116
`
`
`
`
`
`- - - - - - -
`
`NO
`
`YES
`
`
`
`
`
`--
`
`
`
`GRANT/CONTINUE
`ACCESS
`128
`
`:
`
`
`
`
`
`PASSWORDS
`MATCH2
`118-1
`YES
`
`
`
`NO
`:
`
`DENYITERMINATE
`ACCESS
`120
`
`ADDRECORD TO LOCAL
`DATABASE
`122
`
`DELETE
`RECORD FROM
`LOCAL DATABASE
`124
`
`IPR2018-00067
`Unified EX1034 Page 4
`
`

`

`US 2003/0093690 A1
`
`May 15, 2003
`
`COMPUTER SECURITY WITH LOCAL AND
`REMOTE AUTHENTICATION
`
`TECHNICAL FIELD
`0001. The subject matter disclosed here generally relates
`to Security Support for electrical computers and digital
`processing Systems, and, more particularly, to an apparatus,
`method, and logic for authentication and authorization of a
`USC.
`
`BACKGROUND
`0002 Authentication and authorization are important
`aspects of any Security System, including computer Security
`systems. “Authentication” refers to the verification of the
`identity of a perSon or proceSS before they perform other
`System actions. In a communication System, authentication
`may involve simply verifying that a message comes from its
`Stated Source. For example, a bank might compare the
`Signature on a hand-written check to a Sample signature on
`file. Like Signatures, however, many other forms of personal
`identification can also be forged. Consequently, So-called
`"strong authentication' uses a combination of items belong
`ing to at least two of the following three categories: 1)
`personal knowledge (such as a password or personal iden
`tification number); 2) personal possessions (such a cardkey
`or other physical token); and 3) personal characteristics
`(Such as a handwriting Sample, voiceprint, fingerprint, or
`retina Scan).
`0003. In general terms, “authorization' is the process of
`enforcing policies for authenticated entities, Such as policies
`for determining what types of activities, resources, or Ser
`vices may be used. Typically, once an entity has been
`authenticated, the authorization process will determine
`whether that entity has the authority to issue certain com
`mands. For example, in the check-writing Scenario described
`above, a bank might confirm the availability of funds in the
`payer's account before following the instruction on the
`check to transfer funds to the payee. Similarly, in an elec
`tronic computer System, the authorization process may auto
`matically provide an authenticated individual (who is logged
`on with the correct username and password) with the author
`ity to issue any command. In fact, “acceSS control” is the
`primary means for enforcing authorization policies by grant
`ing, denying, and/or terminating access to an unauthorized
`proceSS or device.
`0004 Authentication, authorization, and accounting
`(“AAA”) is a term that is sometimes used to describe a
`general framework for intelligently controlling access to
`computer resources, enforcing policies, auditing usage, and
`providing the information necessary to manage those
`resources. Various Requests for Comments (“RFCs) of the
`Internet Engineering Task Force (“IETF) discuss such a
`framework and are incorporated by reference here, including
`RFC 2903 entitled “Generic AAA Architecture,” RFC 2904
`entitled “AAA Authorization Framework,” RFC 2905
`entitled “AAA Authorization Application Examples, and
`RFC 2906 entitled “AAA Authorization Requirements.” In
`general terms, these documents describe a System where an
`“AAA Server' is used to provide authentication, authoriza
`tion, and/or accounting Services in response to a user's
`request. The AAA Server inspects the contents of the request,
`determines what authorization is requested, retrieves policy
`
`rules from a repository, and then either grants the requested
`acceSS or passes along the request to another AAA Server.
`0005 One standard protocol by which many devices and
`applications communicate with an AAA Server is the
`Remote Authentication Dial-In User Service (“RADIUS”)
`described in Request for Comment (“RFC) 2865, and
`others, of the Internet Engineering Task Force (“IETF)
`which is also incorporated by reference here. RADIUS is a
`client/server protocol that enables remote access Servers to
`communicate with a central Server in order to authenticate
`dial-in users and authorize their access to a requested System
`or Service. RADIUS allows an organization to maintain user
`profiles in a central database that all remote Servers can
`share. It thus provides for improved Security by allowing
`computer resource owners to administer their authorization
`policies at a single network point.
`0006 RADIUS and other such security protocols that
`rely on centralized databases for authorization can be quite
`Slow, especially when implemented with low capacity com
`munications networks. For example, in many prior art
`Systems, authentication requires digitally signing the
`request, as well as the eXchange of information called
`“credentials” between the requester and the server. The
`authentication process can therefore impose Significant over
`head on the operation of distributed computer Systems,
`especially when the number of requests transmitted is high.
`0007 U.S. Pat. No. 5,235,642 to Wobber et al. discloses
`an apparatus and method for making Such access control
`Systems more efficient by caching authentication credentials.
`A computer at each node of a distributed System has a trusted
`computing base that includes an authentication agent for
`authenticating requests received from principals at other
`nodes in the System. Requests are transmitted to the Servers
`as messages that include a first identifier (called an Auth ID)
`provided by the requester and a Second identifier provided
`(called the Subchannel value) by the authentication agent of
`the requester node.
`0008 Each server process has an associated local cache
`that identifies requesters whose previous request messages
`have been authenticated. When a request is received, the
`Server checks the request's first and Second identifiers
`against the entries in its local cache. If there is a match, then
`the request is known to be authentic, without having to
`obtain authentication credentials from the requester's node.
`0009 If the identifier in a request message does not
`match any of the entries in the Server's local cache, then the
`Server node's authentication agent is called to obtain authen
`tication credentials from the requester's node to authenticate
`the request message. Upon receiving the required credentials
`from the requester node's authentication agent, the principal
`identifier of the requester and the received credentials are
`Stored in a local cache by the Server node's authentication
`agent. The Server proceSS also stores a record in its local
`cache indicating that request messages from the Specified
`requester are known to be authentic, thereby expediting the
`process of authenticating received requests.
`0010 Although the Wobber et al. server cache may help
`minimize Server loads, it does not address the problem of
`communication load and/or lag times between the client
`requester and the Server.
`
`IPR2018-00067
`Unified EX1034 Page 5
`
`

`

`US 2003/0093690 A1
`
`May 15, 2003
`
`SUMMARY
`These and other drawbacks of conventional
`0.011
`approaches are addressed here by providing a Secure com
`puter device including means for locally-authenticating a
`user of the device; and means for generating an authentica
`tion request to a Server. The disclosure also relates to a
`computer Security method including the Steps of locally
`authenticating a user of a client device, and generating an
`authentication request to a Server. In another embodiment,
`the disclosure relates to a computer readable medium,
`including logic for locally-authenticating a user of a client
`device, and logic for generating an authentication request to
`a Server. In yet another embodiment, the disclosure relates to
`a Secure computer System including a client having a client
`database for locally-authenticating a user; a Server, in com
`munication with the client, having a Server database for
`remotely-authenticating the user in response to a request
`from the client; and means for updating the client database
`according to results of the local and remote authentication.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0012 Various aspects of the invention will now be
`described with reference to the following figures (“FIGS.")
`which are not necessarily drawn to Scale, but use the same
`reference numerals to designate corresponding parts
`throughout each of the FIGS. and
`0013 FIG. 1 is a schematic block diagram an architec
`ture for implementing a an authentication and authorization
`System;
`FIG. 2 is a flow chart illustrating one embodiment
`0.014
`of an authentication and authorization System; and
`0015 FIG. 3 is a flow chart for another embodiment of
`an authentication and authorization System.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`0016 FIGS. 1-3 illustrate various aspect of an authenti
`cation and authorization (AA') system that provides fast
`(but potentially unwarranted) local authentication followed
`by slower (but more accurate) remote authentication. Upon
`a Successful local authentication, immediate access will be
`provided and the remote authentication will be carried out in
`the background. Any unwarranted acceSS based upon a
`Successful local authentication is Subsequently terminated
`by an unsuccessful remote authentication. The local authen
`tication data may also be modified when the results of one
`of the local and remote authentications are different from
`each other.
`0017. The terms “local” and “remote” are used here to
`convey that communication between, and/or processing by,
`various parts of a distributed System. It is not necessary that
`any part of the System be arranged at physically distant
`locations from other parts of the System. However, greater
`communications distances often require more communica
`tion resources and/or longer communications intervals. In
`any event, local authentication will typically occur relatively
`quickly, and/or require leSS resources, than remote authen
`tication.
`Various aspects of the AA system are described
`0.018
`below with respect to the computer architecture shown in
`
`FIG. 1. The computer architecture shown in FIG. 1 is based
`upon a client/server computer network model. However, a
`variety of other distributed configurations, topologies, and/
`or communications Systems may also be used. Non-com
`puterized architectures may also be used including mechani
`cal,
`pneumatic,
`hydraulic,
`chemical,
`biological,
`electromagnetic, and/or electrical System architectures.
`0019 For the computer system 1 illustrated in FIG. 1, the
`client 10 is a local device that sends requests for action to a
`remote server device 20 which then replies to the request.
`The requests and the replies are typically communicated
`over a network 30 according to a variety of protocols
`including, but not limited to, the TCP/IP protocol. However,
`the client 10 and server 20 may communicate via other
`technologies. For example, the client 10 and the server 20
`may be in direct communication, Such as by a cable, without
`the network 30. Additional clients 10 (not shown) may also
`be arranged in communication with one or more Servers 20.
`0020. The client 10 provides for interaction with a “user”
`(not shown) Seeking authorization for certain activities,
`Services, and/or resources available on the System 1. The
`term “user' includes a perSon, process, another computer,
`and or other device Seeking authorization. In the example
`described here, authorization is provided by granting or
`continuing access to Some, or all, of the computer System 1
`via the client 10. However, various other authorization
`policies may also be implemented.
`0021
`For example, the client 10 could be a physical
`control device (such as a door lock), Windows NT work
`Station, automatic teller machine, or a Digital Sender com
`munication device (available from Hewlett-Packard Com
`pany) that receives input directly from a person. Granting or
`continuing access to these users would, respectively, allow
`the user to change control parameters (such as unlocking the
`lock), access network resources, conduct banking transac
`tions, or Send communications. Alternatively, human input
`may be provided indirectly to the client 10 from another
`device (not shown) or process that may have direct interac
`tion with a user, Such as a proximity Sensor. In yet another
`implementation, input to the client device may be received
`from another device or process (or other device) without
`human interaction, Such as by a timing Signal.
`0022 FIGS. 1-3 generally refer to a local client 10 having
`a client database 12 and a remote Server 20 having a Server
`database 22. For the illustrated example, the databases 12
`and 22 contain usernames and passwords. However, either
`or both of the username and password may be other forms
`of identification including, but not limited to, personal
`knowledge, personal possessions or personal characteristics
`as described above with regard to Strong authentication.
`Similarly, any other number of identification items may also
`be requested from the user and/or made available in the
`corresponding databases 12 and 22. Alternatively, the iden
`tification information represented by the databases 12 and 22
`could be the expected result of a calculation, or other
`process, based upon identification inputs provided by a user.
`0023 The server database 20 is typically used as a large,
`central repository for the most current identification data for
`all authorized users. This allows an administrator to main
`tain a Single Server, Such as the AAA Server discussed above,
`that can be used by all clients. The identification data in the
`client database 12 may then be updated an/or Synchronized
`
`IPR2018-00067
`Unified EX1034 Page 6
`
`

`

`US 2003/0093690 A1
`
`May 15, 2003
`
`with current data from the Server database 22 on an as
`needed basis, Such as by adding or deleting records (or
`changing other information) from the client database 10. In
`addition, the client database 10 may be periodically updated
`and/or synchronized with the current data from the server 22
`on a less frequent basis.
`0024 FIGS. 2 and 3 are flow charts illustrating two
`embodiments of authentication and authorization (“AA')
`systems 100 and 200. More specifically, these figures show
`the architecture, functionality, and operation of AA Systems
`100, 200 that may be implemented with the secure computer
`system 1 shown in FIG.1. However, as noted above, the AA
`systems 100, 200 may be implemented in a wide variety of
`electrical, electronic, computer, mechanical, and/or manual
`configurations. Nonetheless, in a preferred embodiment, the
`AA systems 100, 200 are at least partially computerized with
`various aspects of the Synchronization System being imple
`mented by Software, firmware, hardware, or a combination
`thereof. For example, the Software may be a program that is
`executed by the client 10 and/or server 20 including a special
`purpose or general-purpose digital computer, Such as a
`personal computer (PC, IBM-compatible, Apple-compat
`ible, or otherwise), workStation, minicomputer, or main
`frame computer.
`0025. Each block in FIGS. 2 and 3 represents an activity,
`Step, module, Segment, or portion of computer code that will
`typically comprise one or more executable instructions for
`implementing the specified logical function(s). It should also
`be noted that, in various alternative implementations, the
`functions noted in the blocks will occur out of the order
`noted in the figures. For example, multiple functions in
`different blocks may be executed Substantially concurrently,
`in a different order, incompletely, or over an extended period
`of time, depending upon the functionality involved. Various
`StepS may also be completed manually or with the aid of
`other devices and/or processes.
`0.026 Turning now to FIG. 2, the authentication and
`authorization system 100 begins at step 102 with the local
`client device 10 waiting to receive authorization data, Such
`as a user name and password, from a user who wants
`authorization for (i.e. access to) the system 1 shown in FIG.
`1. Once the user name and password (or other authentication
`data) is entered, or otherwise provided, then the client
`database 12 is queried at step 104 in order to determine
`whether records corresponding to that authentication data
`reside in the client database 12.
`0027. The client database 12 is also referred to as a
`“local database, or “cache,” in order to indicate that this
`query takes place relatively quickly, typically without oth
`erwise time-consuming communications. For example, the
`client database 12 will typically include less than all of the
`records that are contained in the Server database 22 and/or
`may be implemented with a fast memory device. Thus, if a
`username, or other record identifier is found in the client
`database 12 at Step 106, along with the appropriate password
`at Step 108, then the user is granted immediate access at Step
`110. This “local authentication” will occur in the foreground
`while the user is waiting for access at Step 110.
`0028. As shown in the figures, the username and pass
`word queries are preferably performed Sequentially. How
`ever, they may also be formed Substantially simultaneously
`and/or in reverse order.
`
`0029) If immediate access (or other authorization) is not
`granted during the local authentication, then more time
`consuming communications are initiated in conjunction with
`through the server 20. This “remote authorization” will
`occur in the background, when the user has already been
`granted access at Step 110. The user may therefore experi
`ence a fast, local authorization, even though access may be
`terminated during the slower, remote authorization. If access
`was not granted at Step 110, the remote authorization will
`occur in the foreground while the user continues to wait for
`CCCSS.
`0030. More specifically, if it is determined that step 106
`that there is no record in the client database 12 having the
`queried username, then the client 10 will formulate and send
`an authentication request to the server 20 at step 114. The
`authentication request may be a complete query, or simply
`contain enough information for the server 20 to formulate a
`query, of the server database 22. If the record is found in the
`Server database 22 at Step 116, and the passwords match at
`step 118, then the client database 12 will be updated by the
`addition of the record at step 122. The process 100 may also
`be Supplemented with procedures for limiting the number of
`times that a particular client database 10 and/or record in
`any, or all, of the client databases 10 will be updated during
`any period of time and/or total number of updates.
`0031) If access has not been previously granted at step
`110, and the remote authentication is Successful, then access
`will be granted at Step 128. Conversely, if acceSS has already
`been granted at Step 110, then a Successful remote authen
`tication will continue that access before returning to Step 102
`where the System 1 continues working on the authorized
`activity. During Such authorized activities, the client 10 may
`wait for a new username and password in order to begin a
`new activity, or the client may simply deny access for any
`new activities until the authorized activity is completed. The
`client 10 may also be configured to receive and/or Store
`identification data from a Subsequent user while the previous
`user's activity is being completed.
`0032. Returning to step 108, if the username has been
`found in the client database 12, but the password entered by
`the user at Step 102 does not match the corresponding
`password in the client database, then acceSS will be denied
`at Step 120. Next, at Step 124, the record corresponding to
`that username will be deleted from the local database at Step
`124. Similarly, if it is determined at step 116 or step 118 that
`the username or password does not match what is Stored in
`the Server database 22, then acceSS will be denied or
`terminated (if previously granted at step 110) at step 120
`before the record is deleted from the local database at step
`124. If access was granted at step 110, then the remote
`authentication can be performed in the background with the
`user unaware, unless the remote authorization is unsuccess
`ful and access is terminated at Step 120.
`0033. The record additions and/or deletions at steps 122
`and 124 may be implemented by an instruction from the
`server 20 or completed locally by the client 10 depending
`upon whether there has been a query of the Server database
`22 at step 114. For example, the server 20 may formulate and
`send a message to the client 10 with sufficient information
`for instructing that the record be deleted. The illustrated
`process 100 may also be modified so that if access was not
`previously granted at step 110, then deletion of the record
`
`IPR2018-00067
`Unified EX1034 Page 7
`
`

`

`US 2003/0093690 A1
`
`May 15, 2003
`
`from the local database at step 124 is skipped before the
`client 10 returned to the waiting state at step 102. Similarly,
`addition of records at StepS 122 could also be skipped if
`access at Step 110 was previously granted.
`0034 FIG. 3 illustrates another embodiment of an
`authentication and authorization system 200 including all of
`the steps shown in FIG. 2 and an additional step 112. This
`added Step operates So that, if there is a username match at
`step 106 and no password match at step 108, then a
`determination is made at Step 112 as to whether the same
`password has been entered for consecutive authentication
`queries by the same user. If the password is the Same as the
`last query at Step 104, then the remote database is queried at
`Step 114. If the consecutive passwords were not the same,
`then access is denied at Step 120 (without sending a request
`to the server).
`0035. This additional feature prevents an old password in
`the client database 12 from “hiding a newer password on
`the Server. For example, passwords in the Server database 22
`may be set to automatically expire after a certain period of
`time. Under these circumstances, a new password would
`then be entered for an authorized user in the database 22
`while an old password may still exist in the database 10.
`0.036 The first time that the user enters the new password
`at step 102 in FIG. 3, there will not be a match at step 108
`and access will be denied at Step 120 without attempting
`remote authorization. The Second time that the user enters
`new password, it will be the same as the last query at Step
`112 and a Successful remote authorization will be initiated at
`step 114, resulting in the new password being added to the
`local database at Step 122.
`0037. As noted above, the AA systems shown in FIGS. 2
`and 3 are preferably implemented by Software stored in
`memory and containing instructions that are executed by a
`processor, typically in connection with a Suitable operating
`system, arranged with the client 10 and/or server 20. The
`memory may have volatile memory elements (e.g., random
`access memory, or “RAM.” Such as DRAM, SRAM, etc.),
`nonvolatile memory elements (e.g., hard drive, tape, read
`only memory, or “ROM,” CDROM, etc.), or any combina
`tion thereof. The memory may also incorporate electronic,
`magnetic, optical, and/or other types of Storage devices. A
`distributed memory architecture, where various memory
`components are situated remote from one another, may also
`be used.
`0038. The processor(s) is preferably a hardware device
`for implementing Software that is Stored in the memory. The
`processor can be any custommade or commercially available
`processor, including Semiconductor-based microprocessors
`(in the form of a microchip) and/or macroprocessors. The
`processor may be a central processing unit (“CPU”) or an
`auxiliary processor among Several processors associated
`with the client 10 and/or server 20. Examples of suitable
`commercially-available microprocessors include, but are not
`limited to, the PA-RISC series of microprocessors from
`Hewlett-Packard Company, U.S.A., the 80x86 and Pentium
`Series of microprocessors from Intel Corporation, U.S.A.,
`PowerPC microprocessors from IBM, U.S.A., Sparc micro
`processors from Sun MicroSystems, Inc, and the 68XXX
`Series of microprocessors from Motorola Corporation,
`U.S.A.
`0039. As noted above, the memory stores the Software in
`the form of instructions and/or data for use by the processor
`
`in connection with a Suitable operating System that may also
`be stored in the memory. The instructions will generally
`include one or more Separate programs, each of which
`comprises an ordered listing of executable instructions for
`implementing one or more logical functions. The operating
`System implements the execution of these computer pro
`grams and may also provide various Scheduling, input
`output control, file and data management, memory manage
`ment, communication control, and other related Services.
`Various commercially-available operating Systems may be
`used, including, but not limited to, the Windows operating
`system from Microsoft Corporation, U.S.A., the Netware
`operating System from Novell, Inc., U.S.A., and various
`UNIX operating systems available from vendors such as
`Hewlett-Packard Company, U.S.A., Sun Microsystems, Inc.,
`U.S.A., and AT&T Corporation, U.S.A.
`0040. The program(s) stored in memory may include a
`Source program (or "Source code’), executable program
`(“object code’), Script, or any other entity comprising a set
`of instructions to be performed as described in more detail
`below. In order to work with a particular operating System,
`any Such Source code will typically be translated into object
`code Via a conventional compiler, assembler, interpreter, or
`the like, which may (or may not) be included within the
`memory. The programs may be written using an object
`oriented programming language having classes of data and
`methods, and/or a procedure programming language, having
`routines, Subroutines, and/or functions. For example, Suit
`able programming languages include, but are not limited to,
`C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada.
`0041 When any portion of the AA system is imple
`mented in Software, it can be stored on any computer
`readable medium for use by, or in connection with, any
`computer-related System or method. In the context of this
`document, a “computer readable medium' includes any
`electronic, magnetic, optical, or other physical device or
`means that can contain or Store a computer program for use
`by, or in connection with, a computer-related System or
`method. The computer-related System may be any instruc
`tion execution System, apparatus, or device, Such as a
`computer-based System, processor-containing System, or
`other System that can fetch the instructions from the instruc
`tion execution System, apparatus, or device and then execute
`those instructions. Therefore, in the context of this docu
`ment, a computer-readable medium can be any means that
`will Store, communicate, propagate, or transport the program
`for use by, or in connection with, the instruction execution
`System, apparatus, or device.
`0042. For example, the computer readable medium may
`take a variety of forms including, but is not limited to, an
`electronic, magnetic, optical, electromagnetic, infrared, or
`Semiconductor System, apparatus, device, or propagation
`medium. More specific examples of a computer-readable
`medium include, but are not limited to, an electrical con
`nection (electronic) having one or more wires, a portable
`computer diskette (magnetic), a random access memory
`(“RAM”) (electronic), a read-only memory (“ROM") (elec
`tronic), an erasable programmable read-only memory
`(“EPROM,”“EEPROM,” or Flash memory) (electronic), an
`optical fiber (optical), and a portable compact disc read-only
`memory (“CDROM") (optical). The computer readable
`medium could even be paper or another Suitable medium
`upon which the program is printed, as the program can be
`
`IPR2018-00067
`Unified EX1034 Page 8
`
`

`

`US 2003/0093690 A1
`
`May 15, 2003
`
`electronically captured, for instance via optical Sensing or
`Scanning of the paper, and then compiled, interpreted or
`otherwise processed in a Suitable manner before being Stored
`in a the memory.
`0043. Where any portion of the AA system is at least
`partially implemented in hardware, the System may be
`implemented using a variety of technologies including, but
`not limited to, discrete logic circuit(s) having logic gates for
`implementing logic functions upon data Signals, application
`Specific integrated circuit(s) ("ASIC) having appropriate
`combinational logic gates, programmable gate array(s)
`(“PGA'), and/or field programmable gate array(s)
`(“FPGA).
`0044) It should be emphasized that the embodiments
`described above, and particularly any “preferred” embodi
`ments, are merely examples of various implementations that
`have been Set forth here to provide a clear understanding of
`various aspects of the invention. One of ordinary skill will
`be able to alter many of these embodiments without Sub
`Stantially departing from Scope of protection defined Solely
`by the proper construction of the following claims.
`1. A Secure computer device, comprising:
`means for locally-authenticating a user of the device; and
`means for generating a remote authentication request after
`a Successful local authentication of the user.
`2. The device recited in claim 1 further comprising means
`for authorizing the user in response to the Successful local
`authentication.
`3. The