WO1999054803A9 - Method and apparatus for session management and user authentication - Google Patents

Method and apparatus for session management and user authentication

Info

Publication number
WO1999054803A9
WO1999054803A9 PCT/US1999/008665 US9908665W WO9954803A9 WO 1999054803 A9 WO1999054803 A9 WO 1999054803A9 US 9908665 W US9908665 W US 9908665W WO 9954803 A9 WO9954803 A9 WO 9954803A9
Authority
WO
WIPO (PCT)
Prior art keywords
user
service
session
network terminal
computer
Prior art date
Application number
PCT/US1999/008665
Other languages
French (fr)
Other versions
WO1999054803A2 (en
WO1999054803A3 (en
Inventor
Gerard A Wall
Alan T Ruberg
James G Hanko
J Duane Northcutt
Lawrence L Butcher
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Priority to AT99918716T priority Critical patent/ATE298960T1/en
Priority to DE69925996T priority patent/DE69925996T2/en
Priority to JP2000545087A priority patent/JP2002512394A/en
Priority to AU36565/99A priority patent/AU748916B2/en
Priority to CA002329034A priority patent/CA2329034A1/en
Priority to EP99918716A priority patent/EP1074136B1/en
Publication of WO1999054803A2 publication Critical patent/WO1999054803A2/en
Publication of WO1999054803A9 publication Critical patent/WO1999054803A9/en
Publication of WO1999054803A3 publication Critical patent/WO1999054803A3/en
Priority to HK01105485A priority patent/HK1035457A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103Challenge-response
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan

Definitions

  • This invention relates computer systems and, more specifically, to user authentication and the location management of user sessions.
  • mainframe computer that was accessed by a plurality of "dumb terminals".
  • the mainframe was a central station that provided computational power and data storage.
  • a dumb terminal was a display device for data provided by the mainframe, and also provided a means to communicate some data to the mainframe.
  • Other system paradigms followed, including the desktop computer, client/server architectures, and recently, the so-called network computer.
  • a desktop computer is a self contained computing system where all applications and data are resident on the desktop computer system itself. Such systems were implemented in personal computers and have spurred the use of computers in homes and offices.
  • a disadvantage of desktop computers is the short lifetime of the hardware used in the system. Desktop computers are microprocessor driven, and as faster and more powerful microprocessors become available, upgrades of existing desktop systems, or purchase of new desktop systems, is required. In many offices, there are personal desktop computers distributed throughout, sometimes numbering in the thousands and tens of thousands.
  • a disadvantage of such large systems is the lack of compatibility of applications and data on individual systems. Some users may have more recent versions of software applications that are not backwards compatible with older versions of the software. The solution to this problem is to maintain consistent software on all systems. However, the cost to upgrade each system and to provide licensed copies of software and software upgrades can be substantial.
  • Client server systems are systems where central stores of data and /or applications are accessed through a network by personal computer clients. This provides some administrative efficiency in maintaining the shared data. However, the clients still have local applications and data that can present the same kinds of problems faced in the desktop systems already described.
  • a network computer is a stripped down version of a personal computer with less storage space, less memory, and often less computational power.
  • the idea is that network computers will access data through the internet, and only those applications that are needed for a particular task will be provided to the network computer. When the applications are no longer being used, they are not stored on the network computer. There has been some criticism of such systems as lacking the power of a full desktop system, yet not being inexpensive enough to justify the reduced capability. And even though the network computer is a subset of a desktop computer, the network computer may still require upgrades of hardware and software to maintain adequate performance levels.
  • RFC 2131 RFCs 1321 and 2104 contain examples of MD5, or message digesting.
  • a point to point challenge host authentication protocol is contained in RFC 1994.
  • Authentication and session management can be used with a system architecture that partitions functionality between a human interface device (HID) and a computational service provider such as a server.
  • An authentication manager executing on a server interacts with the HID to validate the user when the user connects to the system via the HID.
  • a session manager executing on a server manages services running on computers providing computational services (e.g., programs) on behalf of the user. The session manager notifies each service in a session that the user is attached to the system using a given desktop machine.
  • a service can direct display output to the HID while the user is attached to the system.
  • Figure 1 is an example of system architectures used in one or more embodiments of the invention.
  • FIG. 2 illustrates authentication and session management components and their interactions according to an embodiment of the invention.
  • Figure 3 provides a process flow for initializing a network terminal in response to a power up operation according to an embodiment of the invention.
  • Figures 4A-4C provide a process flow according to an embodiment of the invention for initializing network terminal 202 in response to an awaken operation.
  • Figures 5A-AB provide an authentication process flow according to an embodiment of the invention.
  • Figure 6 provides a challenge process flow according to an embodiment of the invention.
  • FIGS 7 and 8 provide examples of system architectures used in one or more embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION
  • authenticating and session management are performed within a system architecture that partitions the computing functionality between a user's HID and a computational service provider such as a server.
  • Figures 1, 7, and 8 provide examples of system architectures used in one or more embodiments of the invention.
  • the present invention can be implemented in standard desktop computer systems such as described in Figure 1, or in any other computer systems, including client - server systems, network computers, or the human interface device system of Figures 7 and 8.
  • Embodiment of Computer Execution Environment (Hardware) is described in Figure 1, or in any other computer systems, including client - server systems, network computers, or the human interface device system of Figures 7 and 8.
  • An embodiment of the invention can be implemented as computer software in the form of computer readable code executed on a general purpose computer such as computer 100 illustrated in Figure 1, or in the form of bytecode class files executable within a JavaTM runtime environment running on such a computer.
  • a keyboard 110 and mouse 111 are coupled to a bi-directional system bus 118. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 113. Other suitable input devices may be used in addition to, or in place of, the mouse 111 and keyboard 110.
  • I/O (input/output) unit 119 coupled to bi-directional system bus 118 represents such I/O elements as a printer, A/V (audio/video) I/O, etc.
  • Computer 100 includes a video memory 114, main memory 115 and mass storage 112, all coupled to bi-directional system bus 118 along with keyboard 110, mouse 111 and processor 113.
  • the mass storage 112 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology.
  • Bus 118 may contain, for example, thirty-two address lines for addressing video memory 114 or main memory 115.
  • the system bus 118 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as processor 113, main memory 115, video memory 114 and mass storage 112. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.
  • the processor 113 is a microprocessor manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, or a SPARCTM microprocessor from Sun MicrosystemsTM, Inc.
  • Main memory 115 is comprised of dynamic random access memory (DRAM).
  • Video memory 114 is a dual-ported video random access memory. One port of the video memory 114 is coupled to video amplifier 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) raster monitor 117.
  • video memory 114 could be used to drive a flat panel or liquid crystal display (LCD), or any other suitable data presentation device.
  • Video amplifier 116 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 114 to a raster signal suitable for use by monitor 117. Monitor 117 is a type of monitor suitable for displaying graphic images.
  • Computer 100 may also include a communication interface 120 coupled to bus 118.
  • Communication interface 120 provides a two-way data communication coupling via a network link 121 to a local network 122.
  • ISDN integrated services digital network
  • communication interface 120 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 121.
  • LAN local area network
  • communication interface 120 provides a data communication connection via network link 121 to a compatible LAN.
  • Wireless links are also possible.
  • communication interface 120 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
  • Network link 121 typically provides data communication through one or more networks to other data devices.
  • network link 121 may provide a connection through local network 122 to local server computer 123 or to data equipment operated by an Internet Service Provider (ISP) 124.
  • ISP 124 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 125.
  • Internet 125 uses electrical, electromagnetic or optical signals which carry digital data streams.
  • the signals through the various networks and the signals on network link 121 and through communication interface 120, which carry the digital data to and from computer 100, are exemplary forms of carrier waves transporting the information.
  • Computer 100 can send messages and receive data, including program code, through the network(s), network link 121, and communication interface 120.
  • remote server computer 126 might transmit a requested code for an application program through Internet 125, ISP 124, local network 122 and communication interface 120.
  • the received code may be executed by processor 113 as it is received, and /or stored in mass storage 112, or other non-volatile storage for later execution. In this manner, computer 100 may obtain application code in the form of a carrier wave.
  • Application code may be embodied in any form of computer program product.
  • a computer program product comprises a medium configured to store or transport computer readable code, or in which computer readable code may be embedded.
  • Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves.
  • the invention also has application to a computer systems where the data to be displayed is provided through a network.
  • the network can be a local area network, a wide area network, the internet, world wide web, or any other suitable network configuration.
  • One embodiment of the invention is used in computer system configuration referred to herein as a human interface device computer system.
  • the functionality of the system is partitioned between a display and input device, and data sources or services.
  • the display and input device is a human interface device (HID).
  • the partitioning of this system is such that state and computation functions have been removed from the HID and reside on data sources or services.
  • one or more services communicate with one or more HIDs through some interconnect fabric, such as a network.
  • FIG 7. An example of such a system is illustrated in Figure 7. Referring to Figure 7, the system consists of computational service providers 700 communicating data through interconnect fabric 701 to HIDs 702.
  • Computational Service Providers In the HID system, the computational power and state maintenance is found in the service providers, or services.
  • the services are not tied to a specific computer, but may be distributed over one or more traditional desktop systems such as described in connection with Figure 1, or with traditional servers.
  • One computer may have one or more services, or a service may be implemented by one or more computers.
  • the service provides computation, state, and data to the HIDs and the service is under the control of a common authority or manager.
  • the services are found on computers 710, 711, 712, 713, and 714.
  • services examples include XI 1 /Unix services, archived video services, Windows NT service, JavaTM program execution service, and others.
  • a service herein is a process that provides output data and responds to user requests and input.
  • the interconnection fabric is any of multiple suitable communication paths for carrying data between the services and the HIDs.
  • the interconnect fabric is a local area network implemented as an Ethernet network. Any other local network may also be utilized.
  • the invention also contemplates the use of wide area networks, the internet, the world wide web, and others.
  • the interconnect fabric may be implemented with a physical medium such as a wire or fiber optic cable, or it may be implemented in a wireless environment.
  • HIDs - The HID is the means by which users access the computational services provided by the services.
  • Figure 7 illustrates HIDs 721, 722, and 723.
  • a HID consists of a display 726, a keyboard 724, mouse 725, and audio speakers 727.
  • the HID includes the electronics need to interface these devices to the interconnection fabric and to transmit to and receive data from the services.
  • a block diagram of the HID is illustrated in Figure 8.
  • the components of the HID are coupled internally to a PCI bus 812.
  • a network control block 802 communicates to the interconnect fabric, such as an ethernet, through line 814.
  • An audio codec 803 receives audio data on interface 816 and is _, consult order for PCT/US99/08665
  • USB data communication is provided on lines 813 to USB controller 801.
  • An embedded processor 804 may be, for example, a Sparc2e ⁇ with coupled flash memory 805 and DRAM 806.
  • the USB controller 801, network controller 802 and embedded processor 804 are all coupled to the PCI bus 812.
  • the video controller 809 may be for example, and ATI RagePro+ frame buffer controller that provides SVGA output on line 815.
  • NTSC data 817 is provided in and out of the video controller through video decoder 810 and video encoder 811 respectively.
  • a smartcard interface 808 may also be coupled to the video controller 809.
  • authentication and session management components are configured to authenticate users and locate and manage sessions.
  • a session is a persistent representation of a related set of one or more services executing on behalf of a user.
  • Embodiments of the invention authenticate a user and relocate a user's session based on the current location of the user without requiring a service within a session to be configured to perform user validation and relocation.
  • Embodiments of the invention authenticate the user once for all of the user's services. Using embodiments of the invention, services are directed to the HID (or other terminal device) that a user is currently using. It is not
  • RECTIFIED SHEET (RULE 91) ISA/EP necessary for the user to login to each service and establish a new connection for a specific HID.
  • authentication is a one-way authentication which improves the manageability and scalability of authentication. There is no need to exchange keys and avoids the need to perform key lookups in a central database.
  • Network terminal 202 is a human interface device (HID) (e.g., HIDs 821, 822 and 823).
  • HID human interface device
  • An HID has, as examples of its functions, the task of displaying output of services to a user and obtaining input to services from the user.
  • Network terminal 202 has the ability to respond to a command (e.g., display command) received from, for example, a software program (e.g., services 230-238, authentication manager 204 and session manager 206) executing on a computational service provider (e.g., computers 710, 711, 712, 713, and 714).
  • the input received from a user is forwarded to, for example, a service that is fulfilling a user request.
  • More than one server can execute the services that comprise a session.
  • service 230 is executing on server 210
  • services 232 and 234 are executing on server 212
  • services 236 and 238 are executing on server 214.
  • a user accesses a system (e.g., a server, a session, a service and a network terminal) by initiating a login.
  • a system e.g., a server, a session, a service and a network terminal
  • the user is validated by authentication manager 204.
  • Various techniques can be used to allow the user to initiate a login. For example, the user can initiate a login by pressing a key on network terminal 202.
  • a user accesses the system by inserting a smart card in a card reader (e.g., card reader 216) attached to network terminal 202.
  • a smart card is a card that is capable of storing information such as in a magnetic strip or memory of the smart card.
  • the smart card can store user information such as a user's identification (i.e., user ID such as a 64-bit number) and a secret code (e.g., a 128-bit random number) that is transmitted to network terminal 202.
  • the secret code is used during authentication.
  • Network terminal 202 is aware of (or can obtain) its interconnection network address and the address of authentication manager 204. When a user initiates the login, network terminal 202 initiates communication with authentication manager 204 to begin authentication.
  • Authentication manager 204 is a program active (e.g., executing) on a computational service provider connected to network terminal 202 via an interconnection network such as a local area network (LAN), for example. It should be apparent, however, that network terminal 202 can be connected to authentication manager 204 using other interconnection network technologies such as a fiber channel loop or point-to-point cables.
  • Network terminal 202 sends a startup request to authentication manager 204 that includes a user identification (userlD).
  • authentication manager 204 responds to the startup request by initiating an authentication to validate the user.
  • Authentication can include any mechanism that verifies the identify of the user to the system. A key or password known only to the user, or biometrics information can be used to authenticate the user.
  • authentication is performed by verifying a personal identification number (PIN) entered by the user at network terminal 202.
  • PIN personal identification number
  • Authentication manager 204 sends a command (i.e., a challenge command) to initiate entry of the user's PIN at network terminal 202.
  • the user entry is packaged by network terminal 202 and transmitted to authentication manager 204 (i.e., a challenge response).
  • Authentication manager 204 verifies the challenge response with user information retained in authentication database 218, information supplied by the user and information that is generated during authentication. When the user is authenticated, the user is given access to a session (e.g., session 208).
  • a session e.g., session 208.
  • authentication manager 204 notifies session manager 206 (via a connect message) that the user has logged into the system on network terminal 202.
  • Session information contained in authentication database 218 is used to identify the server, port and session identifier (ID) for session manager 206.
  • Session manager 206 is a program that is active on a computational service provider and is connected to authentication manager 204 and network terminal 202 via an interconnection network, for example.
  • Authentication manager 204 sends a message to session manager 206 using session manager 206's server and port information contained in authentication database 218.
  • session manager 206 In response to the connect message from authentication manager 204, session manager 206 notifies the services in the user's current session (i.e., the services in session 208) that the user is attached to network terminal 202. That is, session manager 206 sends a connect message to services 230-238 to direct output to network terminal 202. Session manager 206 ensures that services that are considered to be required services of the session are executing. If not, session manager 206 causes them to be initiated. The user can interact with services 230-238 within a session (e.g., session 208).
  • Network terminal 202 is connected to servers 210, 212 and 214 (and services 230-238) via an interconnection network such as a local area network or other interconnection technology. The user can also start new services or terminate existing services.
  • the user can detach from the system by removing the card from card reader 216.
  • Other mechanisms to express a disconnect can also be used with the invention (e.g., a "sign-off button on network terminal 202).
  • Services 230-238 can continue to run even after the user removes the card from card reader 216. That is, a user's associated session(s) and the services that comprise a session can continue in existence during the period that a user is unattached (e.g., logged off ) from the system.
  • network terminal 202 notifies authentication manager 204 (e.g., via a disconnect message) which notifies session manager 206 (e.g., via a disconnect message).
  • Session manager 206 notifies services 230-238 (e.g., via a disconnect message) which terminate their transmission of display commands to network terminal 202.
  • Services 230-238 continue execution, however, during the time that the user is not logged onto a network terminal. The user can log back in using a network terminal such as network terminal 202, connect to session 208 and interact with services 230-238.
  • Figure 2 depicts a single instance of each, it should be apparent that there can be multiple instances of network terminal 202, authentication manager 204, session 208. For example, there can be more than one instance of authentication manager 204 servicing network terminal 202 or multiple instances of network terminal 202.
  • Authentication manager 204 instances can be organized in a hierarchy according to the topology of the network or they can be globally available, for example.
  • Having more than one instance of the authentication manager improves the scalability of the system since it is possible to add (or remove) instances of authentication manager 204 based on the current load (e.g., the number of users). Further, reliability is improved since redundant instances of authentication manager 204 can be deployed.
  • session manager 206 there can be a multiplicity of session manager 206 instances. Like authentication manager 204, multiple instances of session manager 206 can increase the scalability and reliability of the system.
  • Session manager 206 maintains session database 220 that contains mappings between users, sessions, and services. Session manager 206 manages the services that comprise each session managed by session manager 206. For example, session manager 206 maintains session 208 and services 230-238 within session 208.
  • an account is first set up or enabled for a user.
  • the user is given a userlD, a PIN and a smart card that stores the userlD and secret code.
  • a session is created for the user.
  • a session can have none or more required services. It may be necessary to initiate some of the required services when the session is created. Once a service is initiated, it continues to be active regardless of whether the user is connected to the system. The balance of required services can be initiated when the user first logs in.
  • a user is not limited to one session. There can be multiple sessions associated with a user at any given time.
  • Session database 220 contains records that identify the session(s) and service(s) within a session that are associated with a user. An enabled user can be removed from the system. When a user is removed from the system, all of the user's associated sessions are removed from the system and from session database 220. Services associated with the user's sessions are stopped as well.
  • session manager 206 When a user is enabled to use a system, the user can log onto the system via network terminal 202.
  • session manager 206 When session manager 206 is notified by authentication manager 204 that the user is connected to network terminal 202, session manager 206 notifies the user's session (i.e., the services that comprise a session).
  • Session manager 206 consults session database 220 to identify and notify the session's services.
  • session database 220 includes information that identifies session 208 and services 230-238 that are included in session 208.
  • Session database 220 contains permanent session records and dynamic session records that identify sessions and the services associated with a session.
  • Session database 220 can be one or more databases or data stores.
  • permanent session records can be stored in a configuration file while dynamic session records can be stored in memory in a database system.
  • a permanent session record contains configuration information for a user and is typically created for a user at the time the user is enabled to use the system, for example.
  • a dynamic session record identifies those services that are associated with a user.
  • Dynamic session records identify the required services that are associated with a user session in a permanent session record as well as currently active services.
  • the following contains a format for a permanent session record according to an embodiment of the invention: sessionID servicelD serviceHost servicePort isLazy
  • the sessionID field uniquely identifies the session that contains the required service(s).
  • the servicelD field uniquely identifies a service associated with the session identified by sessionID.
  • the serviceHost and servicePort fields identify the server on which a service is running and the port on the server by which a service can receive communications.
  • the isLazy field identifies the manner in which a service is initiated. For example, isLazy can specify that the service is to be started immediately upon the creation of a session, or that the service is to be started when the user first accesses the system. There may be multiple occurrences of the servicelD, serviceHost, servicePort and isLazy fields each occurrence identifying a required service associated with the session identified by sessionID.
  • the dynamic session record identifies the required services for the session and those services that are currently executing in the session.
  • a session's required services are retrieved from the permanent session record, for example.
  • a dynamic session record can identify zero or more services (required or otherwise) that are currently executing on behalf of a user.
  • the fields that are used to store information about a service in a dynamic session record depends on whether the service is a required service or a service.
  • a required service that is currently active is also a current service.
  • the format of a dynamic session record that identifies a session's required services is the same as the permanent session record format. The following identifies the format for a record associated with a currently executing service according to an embodiment of the invention:
  • the sessionLink field identifies the service's session.
  • An open connection, or pipe is established between session manager 206 and a currently executing service in a session.
  • the open connection can be used to notify either session manager 206 or the service that the other has abnormally, or otherwise, terminated.
  • the open connection is a TCP socket connection which is identified by the TCPSocketfd field.
  • any form of reliable connection technology that could provide a notification that a connection is disabled or disappears could be used with embodiments of the invention.
  • the service has an identifier that is stored in the servicelD field.
  • a currently running service can be linked to a required service.
  • a link to a required service is identified by the requiredServiceLink. If there is no link to a required service, the requiredServiceLink is null.
  • the dynamic session record can also be used to store information about a connection to a network terminal (e.g., network terminal 202).
  • a network terminal e.g., network terminal 202
  • the following contains the fields that identify the connection according to an embodiment of the invention:
  • the sessionLink field identifies the session to which the user attached to network terminal 202 is currently linked.
  • the sessionLink can have as its value the sessionID value, for example.
  • the status field identifies the connection status (i.e., connected or disconnected) of network terminal 202 to the session.
  • the IPAddress field contains the interconnection network address of network terminal 202.
  • An IP address is used in one or more embodiments of the invention. However, it should be apparent that alternative interconnection technologies may use alternate addressing schemes. For example, an asynchronous transfer mode (ATM) network might use a thirteen digit switch prefix/end point identifier.
  • ATM asynchronous transfer mode
  • This information can be used by session manager 206 to send a status message to network terminal 202. If network terminal 202 does not respond within a certain period of time, session manager 206 assumes that network terminal 202 is no longer in use by the user and sends a disconnect message to each of the services in the session.
  • session manager 206 Other information of which session manager 206 is aware include a list of the open connections (e.g., services having an open TCPsocketfd) to services and a mapping between open connections and sessions and the services within a session. This information can be compiled from the session records, for example.
  • the open connections e.g., services having an open TCPsocketfd
  • This information can be compiled from the session records, for example.
  • the information available to session manager 206 can be used to locate a session. For example, given a service, it is possible to find a session that contains the service and/or the services that are contained within a session. Further, it is possible to locate a session that is associated with a given user or instance of network terminal 202 whether or not it is currently executing, for example.
  • session manager 206 When session manager 206 receives a message from authentication manager 204 that a user is connected to network terminal 202, session manager 206 initiates those required services that are not currently active. Session manager 206 further notifies the currently active services to direct input/output (I/O) to network terminal 202.
  • I/O can be expressed using a command protocol used to communicate with network terminal 202 and its peripheral devices. (Appendix A contains an example of a command protocol according to an embodiment of the invention.)
  • session manager 206 accesses the server on which the service is to execute to start the service. For example, session manager 206 sends a request to a well-known port on the server and passes the sessionHost, sessionPort and sessionID for session manager 206.
  • the server connects to network terminal 202 that is attached to the service and uses the server's native authentication and permissions to allow the user to access the server. For example, in a UNIX operating environment, a UNIX service could start with a "CDE Login" screen displayed at network terminal 202 to authenticate the user and ensure that the user wishes to connect to the service.
  • session manager 206 For session manager 206 to start a service on a server, it is given the privileges needed to start the service. It may be undesirable to give session manager 206 these privileges. Further, in current networking environments, servers may be running different operating environments. In this case, session manager 206 must be aware of each operating environment's procedures for initiating a service.
  • a session-aware application running on the server can perform the initiation and register the service with session manager 206. In this case, it is not necessary for session manager 206 to have the needed privileges. Further, session manger 206 does not have to implement a centralized model for initiating services on multiple operating environments. The responsibility for initiating services is left to the session-aware applications that are running in the different operating environments.
  • a session-aware server application has knowledge of session manager 206 (e.g., has the sessionID, sessionHost and sessionPort of session manager 206) and its interfaces (e.g., message formats).
  • the session-aware server application can initiate a service in response to a request received from session manager 206.
  • Session manager 206 sends an initiate message to the server application that possesses the permission to start services in the server's operating environment.
  • the server application initiates the service for session manager 206 and responds to session manager 206 with a valid sessionID.
  • the sessionID can be made available in the operating environment. Services such as video windows might start in this manner, for example.
  • the session-aware application can contact a service to obtain its permission in the form of a cryptographically signed authorization.
  • the server application can transmit the sessionID and the signed authorization to session manager 206. If the session-aware application contacts session manger 206 without an authorization but with a description of the service, session manager 206 could request approval from network terminal 202 to ensure that the user authorized the service. If the user responds affirmatively, the service is added to the session.
  • Session manager 206 receives and generates messages to manage the services within a session. Techniques other than those described herein can be used for initiating services. If session manager 206 initiates a service, it sends an initiate message to the server (or session-aware server application). Session manager 206 can generate an initiate message to start required services identified in session database 220, for example. As another example, session manager 206 can send an initiate message to re-activate a required service that it has determined (e.g., via an open TCP connection between session manager 206 and the service) has terminated.
  • Session manager 206 receives a connect message when a user of network terminal 202 successfully attaches to the system. In response to the connect message, session manager 206 verifies that all of the required services are started, and starts those that are not running. Session manager 206 sends a message (e.g., a connect message) to the services in the session to direct I/O to network terminal 206.
  • a message e.g., a connect message
  • session manager 206 When a disconnect message is received, session manager 206 sends a disconnect message to each one of the services in the session directing them to terminate sending I/O to network terminal 202.
  • Session manager 206 can send status messages to network terminal 206 periodically to ensure that network terminal 202 is still connected. For example, session manager 206 can examine session database 220's dynamic session records to identify each session that is currently connected to a network terminal. That is, session manager 206 can examine the status field associated with a network terminal in a dynamic session record in session database 220. Session manager 206 sends a status request (e.g., a "ping") to each network terminal that is connected with a session. If an answer is not received from network terminal 202 within a certain period of time (e.g., 20 seconds) for a particular session, session manager 206 assumes that the session is disabled and it sends a disconnect message to each service in the session instructing them to terminate display functions.
  • a status request e.g., a "ping”
  • Network terminal 202 responds to the status (e.g., ping) request from session manager 206 with either a "Card In” or “Card Out” status. If a "Card Out” status is received from network terminal 202, session manager 206 sends a disconnect message to each of the session's services.
  • the status e.g., ping
  • session manager 206 sends a disconnect message to each of the session's services.
  • network terminal 202 If the "Card In" status is sent in response to a status request, network terminal 202 also indicates the number of insertions of the card in card reader 216, the number of seconds since a card insertion, and the cardlD.
  • the cardID is, for example, the value of sessionID for the user's session.
  • Session manager 206 retains at least the last status information received from network terminal 202 to compare the new status information against the previous status information. If, for example, the number of insertions or the number of seconds for insertion differs from the last status information, session manager 206 considers the session to be disabled. In this case, session manager 206 sends a disconnect message to the session's services.
  • a service connect message is sent to session manager 206. If the service has the proper authorization, session manager 206 adds the service to the list of services for the session and sends a message to the service to direct I/O to network terminal 202.
  • the authentication manager is responsible for ensuring the legitimacy of a user and associating a user with a session(s).
  • an authentication exchange takes place to authenticate the user in one embodiment of the invention.
  • Authentication can be include any mechanism that verifies the identify of the user to the system. For example, a key password can be entered or biometrics data can be collected to authenticate the user.
  • Authentication database 218 contains user and session information that can be accessed by authentication manager 204. In one embodiment of the invention, the format of a record contained in authentication database 218 is as follows:
  • the userlD and secret fields contain the same values as those stored in a user's smart card.
  • the userlD and secret values are typically established when the user is enabled to use the system, for example.
  • the secret field contains a 128-bit value.
  • the PIN field is the personal identification number (PIN) that is known to the user and requested by authentication manager 204 during authentication.
  • PIN personal identification number
  • the userlD, secret and PIN values are used to authenticate a user.
  • Authentication database 218 could contain other information such as a password or biometrics data, if they were used to authenticate a user.
  • the sessionPort field identifies the port for communicating with session manager 206.
  • the sessionID field contains a unique identifier for session manager 206. If authentication is successful, the sessionHost, sessionPort and sessionID fields are used to notify session manager 206 of the user's location at the network terminal 202.
  • a challenge mechanism is used to authenticate a user.
  • Figure 6 provides a challenge process flow according to an embodiment of the invention.
  • Authentication manager 204 sends a challenge to network terminal 202 to verify the authenticity of the user.
  • Network terminal 202 prepares the challenge response, and returns it to authentication manager 204. If the response to the challenge is as expected, the user is verified to authentication manager 204.
  • Figures 5A-AB provide an authentication process flow according to an embodiment of the invention.
  • the authentication process can be repeated more than once until authentication is successful or the number of repetitions, or rounds, exceeds a certain number.
  • an identifier that represents the number of the authentication round is initialized to zero.
  • a random number is generated that is used as the challenge number.
  • authentication manager 204 sends an N_AUTHENTICATE command to network terminal 202 as well as a packet of information for the authentication process.
  • the following information is sent in conjunction with the N_AUTHENTICATE command:
  • the code field identifies the type of information contained in the information packet. For example, a value of "1" indicates that the information packet contains a challenge.
  • the identifier field contains the value (i.e., the round indicator) that was generated at step 502.
  • the length field identifies the length of the information packet.
  • the value field contains the random number, or value of the challenge, generated in step 504.
  • the valueSize identifies the size of the value field (e.g., 128 bits).
  • authentication manager 204 sends rendering commands to network terminal 202 prompting the user for the user's PIN.
  • authentication manager 204 waits for a response from network terminal 202 or a timeout. If a timeout is detected at step 510, processing continues at step 514 to determine whether the maximum number of rounds has been exceeded. If not, processing continues at step 518 to increment the identifier and processing continues at step 504 to begin a new authentication round. If it is determined, at step 514, that the maximum number of rounds has occurred, processing continues at step 516 wherein authentication manager 204 sends rendering commands to network terminal 202 indicating a failure and the authentication process ends.
  • Rendering commands can be, for example, part of a command protocol used to communicate with network terminal 202 and its peripheral devices.
  • a challenge routine includes commands sent by authentication manager 204 to network terminal 202 to capture the PIN entry by the user and generates a response.
  • Network terminal 202 generates a response value that is the output of a hash function (i.e., a hash value or challenge response) from an input including the user's PIN, the value of the identifier, the value of the secret stored in the user's smart card and the value of the challenge (e.g., the random number generated in step 504).
  • a hash function i.e., a hash value or challenge response
  • a hash function can take variable-length input and convert it to a fixed-length output (a hash value).
  • a hash function takes the input and returns a byte consisting of the exclusive-or (XOR) of all the input bytes.
  • XOR exclusive-or
  • hash functions There are many other examples of hash functions that can used with embodiments of the invention.
  • the hmac_md5 function (RFC2104) is one example of a hashing function that is used in an embodiment of the invention to generate a response.
  • the following packet format is used by network terminal 202 to send the response to authentication manager 204 according to one embodiment of the invention:
  • the code field is set to a value of "2" which indicates that the information packet contains a challenge response.
  • the value field contains the challenge response (e.g., the result of a hashing function).
  • the userlD field contains the user's userlD.
  • authentication manager 204 determines (at step 510) that it received a response from network terminal 202, processing continues at step 512 to determine whether the identifier returned by network terminal 202 matches the identifier generated by authentication manager 204. If so, processing continues at step 520 to examine the response returned by network terminal 202.
  • authentication manager 204 determines whether the challenge response matches the response expected by authentication manager 204. For example, authentication manager 204 can generate a hash value using its identifier, PIN, secret and challenge values. If the hash value generated by authentication manager 204 matches the challenge response generated by network terminal 202, authentication is partially successful. Authentication manager also verifies that the interconnection network address of network terminal 202 and the user's userlD are valid. If the challenge response, interconnection network address and userlD are verified, authentication is successful. If not, authentication failed. If authentication is successful, processing continues at step 528 to send an N_AUTHENTICATE command.
  • the format of the command is as follows:
  • the code field contains a value of "3" to indicate that the user was successfully authenticated.
  • Processing continues at step 530 to send rendering commands to network terminal 202 indicating that session manager 206 is connecting the user to one of the user's sessions.
  • authentication manager 204 notifies session manager 206 that the user is connected to the system via network terminal 202.
  • Authentication manager 204 sends the interconnection network address of network terminal 202 and session manager 206's sessionID to the server that is executing session manager 206 (i.e., the server identified in the sessionHost field of the user's authentication database record) at step 532.
  • step 522 If authentication failed, processing continues at step 522 to send an
  • N_ AUTHENTIC ATE command Like a successful authentication, the N_AUTHENTICATE command includes a code field that indicates the status of the authentication process. A code value of "4" is used, for example to indicate that authentication failed. Processing continues at step 524 to send rendering commands to network terminal 202 indicating that the authentication failed and instructing the user to remove the smart card from card reader 216.
  • the authentication process ends at step 526.
  • the process described with reference to Figures 5A-5B is one example of an authentication process. It should be apparent that other authentication techniques can be used with embodiments of the invention.
  • the user is not requested to enter a PIN.
  • the user's card in card reader 216 is enough to authenticate the user.
  • the userlD and secret value can be hashed with the identifier and the challenge received from authentication manager 204 to generate a response to a challenge by authentication manager 204. In this way, a user can attach to the user's services simply by inserting a card containing valid information into card reader 202.
  • a user is connected to a session without first being authenticated by authentication manager 204.
  • the user need only provide an identification (e.g., userlD), for example. If the user provides a valid userid, the user is given access to the session that is associated with the userlD.
  • authentication manager 204 When the user disconnects from network terminal 202, authentication manager 204 is informed and informs session manager 206 of the disconnection. For example, when the user removes the smart card from card reader 216, card reader 216 informs network terminal 202. Network terminal 202 informs authentication manager of the disconnection. Authentication manager 204 informs session manager 206 that the user has disconnected from network terminal 202. Session manager 206 notifies each of the services in the user's session. Challenge Routine
  • the authentication process can include a challenge initiated by authentication manager 204.
  • Figure 6 provides a challenge routine process flow for handling a challenge according to an embodiment of the invention.
  • the challenge routine executes on network terminal 202 in response to a challenge command received from authentication manager 204.
  • the key entry received from the user is read until a return or enter key is pressed.
  • the key entry is translated to ASCII characters at step 604.
  • a hash function is used to generate a hash value, or challenge response, from the concatenation of the identifier, PIN, secret, and challenge values.
  • the challenge response is sent to authentication manager 204 at step 608.
  • network terminal 202 awaits a response from authentication manager 204 or a timeout. If a response or a timeout occurs, the challenge routine ends at step 614.
  • Network terminal 202 performs some initialization when it is first turned on. While a user is not using network terminal 202, network terminal 202 can be in a dormant state if it is powered on. A user can awaken network terminal 202 from its dormant state using one of the techniques described herein, for example. It should be apparent that other techniques can be used to awaken network terminal.
  • Figure 3 provides a process flow for initializing network terminal 202 in response to a power up operation according to an embodiment of the invention.
  • a determination is made whether a power up operation has occurred. If not, processing continues to wait for a power up operation.
  • a request is generated by network terminal 202 to the network to test the network connection.
  • a determination is made whether a response is received. If not, processing continues at step 310 to generate an error and processing continues at step 302 to await a power up operation.
  • step 306 If it is determined, at step 306, that an answer is received, processing continues at step 308 to send an acknowledge (an ACK) message and initialization of network terminal 202 can continue at step 402 of Figure 4A.
  • FIGs 4A-4C provide a process flow according to an embodiment of the invention for initializing network terminal 202 in response to an awaken operation.
  • network terminal 202 waits for notification of the awaken operation.
  • the awaken operation is the insertion of a user's smart card in card reader 216.
  • processing continues at step 404 to send a request to obtain the interconnection network addresses of authentication manager 204 and network terminal 202.
  • a user's smart card can be preprogrammed with the interconnection network addresses.
  • Network terminal 202 can read the interconnection network addresses from the smart card via card reader 216, for example.
  • network terminal 202 awaits a response or a timeout. If a timeout occurs, processing continues at step 412 to determine whether the maximum number of tries has been exceeded. If the maximum number of tries has been exceeded, processing continues at step 410 to generate an error. If the maximum number of tries has not been exceeded, processing continues at step 414 to increment the number of tries and processing continues at step 404 to resend the request for the interconnection network addresses.
  • processing continues at step 408 to send an ACK.
  • processing continues at step 416 of Figure 4B.
  • network terminal 202 sends a startup request to authentication manager 204.
  • a retry time is set in which network terminal 202 waits for a response to the startup request.
  • a variable is set to indicate that network terminal 202 is waiting for a response to the startup request.
  • network terminal 202 waits for a response to the startup request.
  • processing continues at step 424 to determine whether the retry time as been exceeded. If not, processing continues at step 422 to wait for a response. If the retry time has been exceeded, processing continues at step 426 to determine whether the maximum number of tries has been exceeded. If not, processing continues at step 428 to generate an error and return to step 416 to resend the startup request. If not, processing continues at step 430 to increment the number of tries and reset the retry time. At step 432, the startup request is resent and processing continues at step 444 to determine whether the card has been removed from card reader 216.
  • step 434 network terminal 202 examines the variable initially set in step 420 to determine whether it is waiting for a response to the startup request. If so, processing continues at step 436 to determine whether the response is a challenge message. If not, processing continues at step 424 to repeat the startup request if the maximum number of tries has not been exceeded. If it is determined, at step 436, that a challenge message has been received, processing continues at step 438 to set the waiting_for_startup variable is set to no (i.e., "N"). Processing continues at step 440 to process the challenge request at steps 440 and 442.
  • the challenge request can be handled as described above with reference to Figures 5A-5B and 6, for example.
  • step 434 If it is determined, at step 434, that network terminal 202 is not waiting for a response to a startup request, processing continues at steps 440 and 442 to handle the message (e.g., rendering commands to display output generated by service 234).
  • the message e.g., rendering commands to display output generated by service 234.
  • network terminal 202 sends a disconnect message to authentication manager 204 at step 448.
  • Network terminal 202 waits for an acknowledgment (ACK) message from authentication manager 204.
  • ACK acknowledgment
  • network terminal 202 clears the screen, at step 450, and returns to step 402 to wait for another user to insert a smart card in card reader 216.
  • step 444 If it is determined, at step 444, that the user has not removed the card from card reader 216, processing continues at step 446 to determine whether network terminal is waiting for a response to its startup request. If so, processing continues at step 422 to determine whether a response has been received. If network terminal is not waiting for a response from a startup request, processing continues at steps 440 and 442 to process any messages sent to network terminal 202. Message Format
  • a connection to network terminal 202 is established via a user datagram protocol (UDP) port. That is, packets are sent via a UDP connection and received at a destination UDP port. The destination UDP port uniquely identifies the connection. Packet length and checksum information are provided by the UDP header. Buffer size fits in an Ethernet Maximum Transfer Unit (MTU) with IP/UDP headers. Data is sent over the network in network byte order (big-endian).
  • UDP user datagram protocol
  • protocols can be used in place of UDP.
  • protocols such as an ATM AAL5 (AAL or ATM Adaptation Layer) can be used.
  • the first bitmap is the pixel values
  • the secon is the per-pixei mask.
  • the entire command is a ⁇ ⁇ to the next 32-bit boundary.
  • Play Audio 0x31 X, ⁇ , WIDTH, HEIGHT are encoded as follows :
  • WIDTH 4 mixer mode specifies the i of channels to include m the standard mix. Channel numbers above this numoer are sent raw and not combined w th any other channel f the terminal has insuff cent channels to cover tne request.
  • the header is followed by the specified number of samples x r.umoer of channels x I ⁇ bits.
  • the entire command is pacdec to 22 nits .
  • sequence numoer is incremented for eacn command. Sequence numbers may not be ail zero except for a epoch cnangmg flush comman ⁇ , cescri ed below. R.ectangies may not wrap. I.e. x-width ⁇ 0x10000 and y-height ⁇ 0x10000
  • sequence number of a flush command is the same as the sequence number of the previous command, with the exception of epoch changes (see description below) . That is, sequence numbers only increment wnen pixels change or the epoch cnanges .
  • Tnere is one pixel value for each pixel m tne region.
  • the layout is oy rows; i.e. there are "width" pixel values for pixels at ⁇ x, y> through ⁇ x+w ⁇ dth-l, y> followed by pixels at ⁇ x, y+l> through ⁇ x ⁇ w ⁇ dth-l, y+l>, etc. ⁇ 0, 0> describes the upper left corner.
  • Glyph The 32-bit value is placed in the pixel location corresponding with ' each one bit in the bitmap, positions associated with zero bits are unchanged.
  • the bitmap is laid out by rows (y, y+1- ) using MS3 to LSB in each byte.
  • 3 ⁇ level The two 32-c ⁇ t values cO and cl, are placed m the pixel location corresponding with eacn zero and one bit, res ect vely, m tne tit ap
  • the bitmap is lai ⁇ out bv rows (y, y-1, ...), using MS3 to LS3 n eacn byte.
  • ⁇ w ⁇ ctn, h ⁇ gr.t> to the pixel values that follow.
  • the pixel values are packed sucn tnat there are four pixels defined by t.-.ree 32-bit values tnusly: ⁇ bgrn, grog, rrgr> . If width is not a multiple of four, the end is packed the same as aoove witn the remaining values anc padced to the nearest 32-o ⁇ t value.
  • the layout is oy rows; i.e.
  • Tne values cf CHR0MA_S ⁇ 3_X anc CHR0M?._SU3_ ⁇ are encodec as follows :
  • 1 - Y (luma) consists of 4-bit quantized DPCM values (see below) . 2,3 - Undefined/reserved
  • RFU is reserved for future use and must be 0.
  • the RGB image is scaled up as necessary to width by height pixels.
  • the resulting image is put on the display at location ⁇ x, y> .
  • the component order is Y (or CCIR- Ol Y' ) , U (CCIR-601 Cb) , and then V (CCUR- ⁇ Ol Cr) .
  • This command sets the appearance of the local display cursor (moved and reported by Pointer [0]) .
  • the cursor is a maximum of a 64x ⁇ 4 block, but may be any size less than that. If the mask value for a particular pixel is ' 1' , the corresponding cursor pixel is displayed; if the mask is '0', the cursor is transparent at that location. hen the mask is ' 1' , the pixel value is 'c0' when the value is '0', and 'cl' when the value is '1' . If the mask is zero, the pixel value should also be zero. A mask of zero and a pixel value of one is reserved for future expansion.
  • WIDTH and HEIGHT may be zero, indicating not to draw a cursor (equivalent to a mask of all zeros) . Pointer tracking continues to work normally ,
  • X and Y denote the 'hot spot' for the cursor; e.g., on what pixel of the cursor image events are to be reported. This is primarily used for stopping th ⁇ cursor on the edges of the display.
  • X (0, WIDTH), Y (0, HEIGHT).
  • Pointer (0] is usually settabie (mouse or touchscreen) and is the 2-D screen cursor. This command is provided for applications that insist on setting their pointer, or for applications that need relative pointers (e.g. reset the cursor to its previous position) . As such, there are a few restrictions: setting the pointer may not work (e.g. a ]oyst ⁇ ck) at all the pointer value may be clipped arbitrarily to match the pointer device or the screen the user can continue to move the pointer once it is set, but that is reported using a 'Pointer State' status message. the behavior of resetting the pointer for pseu ⁇ c-relativ ⁇ mo ⁇ e could cause different behaviors with different devices; e.g. a touch screen, is only settable when the user is not ' dragging' .
  • setting the pointer may not work (e.g. a ]oyst ⁇ ck) at all the pointer value may be clipped arbitrarily to match the pointer device or the
  • Pointers are allowed to ave up to six dimensions. The numoer of dimensions and the size of the command are set using the DIM bits. All pointer values are signed, 2's compliment.
  • Set Key Locks This command sets the lock values for an ⁇ INDEX>'ed keyboard. Locks generally correspond to lights on the keyboard that are software controllable. If a lock condition is to be indicated, then the bit should be set m the mask, otherwise, the bit should b ⁇ cleared. Since some keyboards may implement locks locally (e.g. mechanically), setting a lock may not have an affect. Keys from the kevwingd should always be interpreted from the state reported by the keyboard. On the other hand, the host s required to issue a Set Key Lock command on reception of a locked keycod ⁇ , if that is what the interface dictates, because both normal keyboards and the terminal do not attempt to handle locking locally. This is because the terminal does not uncerstand the keyboard or d ⁇ sirec user interface semantics.
  • Damage Repair This informs the client that all damage messages for sequence number SEQ in epoch EPOCH and earlier have been processed and repair data sent, (see the Damage back-channel command) .
  • PAD must be 0.
  • X, Y, WIDTH, and HEIGHT must be 0;
  • Play Audio This plays 48kHz audio samples, and may be imbeded in a graphics command stream.
  • An undefined number of streams are received by the terminal on a first-come-first-serve ⁇ basis. Streams are allocated on an as-needed basis and are broken down when buffer starvation occurs (there is no data to play when its time comes — partially received buffers are error concealed and played) . The terminal corrects for timebase drift.
  • sample sequence s split into an interleave size and at most 1+ (sequence size) / (interleave size) samples are emmitted per packet .
  • tnree packets For example, for an interleave of 3 and and sequence size of 8, the following tnree packets could be sent:
  • Samples are 48kHz, 16 bit linear, and may contain up to 16 channels. For example, a 5-channel sample would take 10 consecutive bytes .
  • the standard assignee channels are as follows:
  • the terminal speakers are set up tne same manner
  • the full mixing matrix is available in the full soecification .
  • Flush There may be no commands in the display stream for a period of time following this command; therefore, this s a good point for clients to flush all unfinished rendering to the screen.
  • the epoch field provides 32 additional high order bits for the sequence numbers.
  • FILL consists of 16 bytes set to all OxFF. This command provides an opportunity to re-synchronize data stream after a drop-out.
  • the sequence number of a flush command is normally the same as the last non-flush command. However, when a epoch is exhausted, ( .e. . the sequence number of the last command is OxFFFFFF) , a flush command with a sequence number of zero and a new epoch number (incremented by 1) is sent.
  • the basic status command format is: ⁇ COMMAND:8> ⁇ TIM ⁇ :24> ⁇ Info>
  • the 'Set Key Locks' command may be us ⁇ d to reset these locks, and should be used if a lock key is detected at the host since keyboards generally don' locally handle lock status, and the terminal certainly doesn't either. Bits other than those specified are reserved and should be ignored. On set, they should be set to zero
  • the modifier b ts are from the US3 class definition for boot kevboards as well:
  • Pointer State Reports the state of the ⁇ INDEX>'ed pointer.
  • DIM indicates the number of dimensions reported: 1, 2, 3, or 6.
  • the buttons are from the US3 class definition for boot keyboards, bit zero is the 'primary' button (on the left) , and the numners increase from left-to-right .
  • the reported values are all absolute and are signed, two's compliment.
  • Active Region Indicates the area of the logical fram ⁇ buffer that is retained on the newt. Specifically, this s tne area that tne " " rom" region of Copy rendering commands can be specified successfully.
  • This region may change over t me on a given client, for example, due to a pan-an ⁇ -scan style of interface in a han ⁇ -neld d ⁇ vic ⁇ .
  • different client ⁇ v c ⁇ s may r ⁇ port different active regions.
  • the client will continue to r ⁇ port damag ⁇ until a Damage Repair m ⁇ ssag ⁇ for the affected sequence numoer is received.
  • Onc ⁇ a damage message is sent for a given sequence numoer, no new subsequent damage may be sent for earlier sequence numoers . However, it is permissible to collapse two or more ranges into one in order to save space m later status oackets .
  • Luma data is encoded as follows : for each line last value - 0x80 foreach luma,-value 1 in line diff - 1 - last value q_value - quan (diff] last value - clamp (last value dquant (q_value ] emit q_value end end
  • Clamp is a clamping tanle; clamp [i] is: " 0 if i ⁇ 0;

Abstract

Authentication and session management can be used with a system architecture that partitions functionality between a human interface device (HID) and a computational service provider such as a server. An authentication manager executing on a server interacts with the HID to validate the user when the user connects to the system via the HID. A session manager executing on a server manages services running on computers providing computational services on behalf of the user. The session manager notifies each service in a session that the user is attached to the system using a given HID. A service can direct display output to the HID while the user is attached to the system. When a user detaches from the system, each of the service's executing for the user is notified via the authentication manager and the session manager. Upon notification that the user is detached from the system, a service can continue to execute while stopping its display to the HID.

Description

METHOD AND APPARATUS FOR SESSION MANAGEMENT AND USER AUTHENTICATION
BACKGROUND OF THE INVENTION
1. FIELD OF THE INVENTION
This invention relates computer systems and, more specifically, to user authentication and the location management of user sessions.
2. BACKGROUND ART
The paradigms by which computer systems have been configured have changed over time. In earlier times, a computer consisted of a so called
"mainframe" computer that was accessed by a plurality of "dumb terminals". The mainframe was a central station that provided computational power and data storage. A dumb terminal was a display device for data provided by the mainframe, and also provided a means to communicate some data to the mainframe. Other system paradigms followed, including the desktop computer, client/server architectures, and recently, the so-called network computer.
A desktop computer is a self contained computing system where all applications and data are resident on the desktop computer system itself. Such systems were implemented in personal computers and have spurred the use of computers in homes and offices. A disadvantage of desktop computers is the short lifetime of the hardware used in the system. Desktop computers are microprocessor driven, and as faster and more powerful microprocessors become available, upgrades of existing desktop systems, or purchase of new desktop systems, is required. In many offices, there are personal desktop computers distributed throughout, sometimes numbering in the thousands and tens of thousands. A disadvantage of such large systems is the lack of compatibility of applications and data on individual systems. Some users may have more recent versions of software applications that are not backwards compatible with older versions of the software. The solution to this problem is to maintain consistent software on all systems. However, the cost to upgrade each system and to provide licensed copies of software and software upgrades can be substantial.
Client server systems are systems where central stores of data and /or applications are accessed through a network by personal computer clients. This provides some administrative efficiency in maintaining the shared data. However, the clients still have local applications and data that can present the same kinds of problems faced in the desktop systems already described.
Recently, the rise of the internet has resulted in the proposed use of so- called "network computers". A network computer is a stripped down version of a personal computer with less storage space, less memory, and often less computational power. The idea is that network computers will access data through the internet, and only those applications that are needed for a particular task will be provided to the network computer. When the applications are no longer being used, they are not stored on the network computer. There has been some criticism of such systems as lacking the power of a full desktop system, yet not being inexpensive enough to justify the reduced capability. And even though the network computer is a subset of a desktop computer, the network computer may still require upgrades of hardware and software to maintain adequate performance levels.
An example of a dynamic host configuration protocol is provided in
RFC 2131. RFCs 1321 and 2104 contain examples of MD5, or message digesting. A point to point challenge host authentication protocol is contained in RFC 1994.
SUMMARY OF THE INVENTION
Authentication and session management can be used with a system architecture that partitions functionality between a human interface device (HID) and a computational service provider such as a server. An authentication manager executing on a server interacts with the HID to validate the user when the user connects to the system via the HID. A session manager executing on a server manages services running on computers providing computational services (e.g., programs) on behalf of the user. The session manager notifies each service in a session that the user is attached to the system using a given desktop machine. A service can direct display output to the HID while the user is attached to the system. When a user detaches from the system, each of the service's executing for the user is notified via the authentication manager and the session manager. Upon notification that the user is detached from the system, a service continues to execute while stopping its display to the desktop machine.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is an example of system architectures used in one or more embodiments of the invention.
Figure 2 illustrates authentication and session management components and their interactions according to an embodiment of the invention.
Figure 3 provides a process flow for initializing a network terminal in response to a power up operation according to an embodiment of the invention.
Figures 4A-4C provide a process flow according to an embodiment of the invention for initializing network terminal 202 in response to an awaken operation.
Figures 5A-AB provide an authentication process flow according to an embodiment of the invention.
Figure 6 provides a challenge process flow according to an embodiment of the invention.
Figures 7 and 8 provide examples of system architectures used in one or more embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION
A method and apparatus for session management and user authentication is described. In the following description, numerous specific details are set forth in order to provide a more thorough description of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention.
Overview
Methods and apparatus are described according to one or more embodiments of the invention for authenticating a system user and management services executing in the system on behalf of the user. In one embodiment of the invention, authenticating and session management are performed within a system architecture that partitions the computing functionality between a user's HID and a computational service provider such as a server.
Figures 1, 7, and 8 provide examples of system architectures used in one or more embodiments of the invention. The present invention can be implemented in standard desktop computer systems such as described in Figure 1, or in any other computer systems, including client - server systems, network computers, or the human interface device system of Figures 7 and 8. Embodiment of Computer Execution Environment (Hardware)
An embodiment of the invention can be implemented as computer software in the form of computer readable code executed on a general purpose computer such as computer 100 illustrated in Figure 1, or in the form of bytecode class files executable within a Java™ runtime environment running on such a computer. A keyboard 110 and mouse 111 are coupled to a bi-directional system bus 118. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 113. Other suitable input devices may be used in addition to, or in place of, the mouse 111 and keyboard 110. I/O (input/output) unit 119 coupled to bi-directional system bus 118 represents such I/O elements as a printer, A/V (audio/video) I/O, etc.
Computer 100 includes a video memory 114, main memory 115 and mass storage 112, all coupled to bi-directional system bus 118 along with keyboard 110, mouse 111 and processor 113. The mass storage 112 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology. Bus 118 may contain, for example, thirty-two address lines for addressing video memory 114 or main memory 115. The system bus 118 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as processor 113, main memory 115, video memory 114 and mass storage 112. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.
In one embodiment of the invention, the processor 113 is a microprocessor manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, or a SPARC™ microprocessor from Sun Microsystems™, Inc. However, any other suitable microprocessor or microcomputer may be utilized. Main memory 115 is comprised of dynamic random access memory (DRAM). Video memory 114 is a dual-ported video random access memory. One port of the video memory 114 is coupled to video amplifier 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) raster monitor 117. Alternatively, video memory 114 could be used to drive a flat panel or liquid crystal display (LCD), or any other suitable data presentation device. Video amplifier 116 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 114 to a raster signal suitable for use by monitor 117. Monitor 117 is a type of monitor suitable for displaying graphic images.
Computer 100 may also include a communication interface 120 coupled to bus 118. Communication interface 120 provides a two-way data communication coupling via a network link 121 to a local network 122. For example, if communication interface 120 is an integrated services digital network (ISDN) card or a modem or cable modem, communication interface 120 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 121. If communication interface 120 is a local area network (LAN) card, communication interface 120 provides a data communication connection via network link 121 to a compatible LAN. Wireless links are also possible. In any such implementation, communication interface 120 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
Network link 121 typically provides data communication through one or more networks to other data devices. For example, network link 121 may provide a connection through local network 122 to local server computer 123 or to data equipment operated by an Internet Service Provider (ISP) 124. ISP 124 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 125. Local network 122 and Internet 125 both use electrical, electromagnetic or optical signals which carry digital data streams. The signals through the various networks and the signals on network link 121 and through communication interface 120, which carry the digital data to and from computer 100, are exemplary forms of carrier waves transporting the information.
Computer 100 can send messages and receive data, including program code, through the network(s), network link 121, and communication interface 120. In the Internet example, remote server computer 126 might transmit a requested code for an application program through Internet 125, ISP 124, local network 122 and communication interface 120.
The received code may be executed by processor 113 as it is received, and /or stored in mass storage 112, or other non-volatile storage for later execution. In this manner, computer 100 may obtain application code in the form of a carrier wave.
Application code may be embodied in any form of computer program product. A computer program product comprises a medium configured to store or transport computer readable code, or in which computer readable code may be embedded. Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves. Human Interface Device Computer System
The invention also has application to a computer systems where the data to be displayed is provided through a network. The network can be a local area network, a wide area network, the internet, world wide web, or any other suitable network configuration. One embodiment of the invention is used in computer system configuration referred to herein as a human interface device computer system.
In this system the functionality of the system is partitioned between a display and input device, and data sources or services. The display and input device is a human interface device (HID). The partitioning of this system is such that state and computation functions have been removed from the HID and reside on data sources or services. In one embodiment of the invention, one or more services communicate with one or more HIDs through some interconnect fabric, such as a network. An example of such a system is illustrated in Figure 7. Referring to Figure 7, the system consists of computational service providers 700 communicating data through interconnect fabric 701 to HIDs 702.
Computational Service Providers - In the HID system, the computational power and state maintenance is found in the service providers, or services. The services are not tied to a specific computer, but may be distributed over one or more traditional desktop systems such as described in connection with Figure 1, or with traditional servers. One computer may have one or more services, or a service may be implemented by one or more computers. The service provides computation, state, and data to the HIDs and the service is under the control of a common authority or manager. In Figure 7, the services are found on computers 710, 711, 712, 713, and 714.
Examples of services include XI 1 /Unix services, archived video services, Windows NT service, Java™ program execution service, and others. A service herein is a process that provides output data and responds to user requests and input.
Interconnection Fabric - In the invention, the interconnection fabric is any of multiple suitable communication paths for carrying data between the services and the HIDs. In one embodiment the interconnect fabric is a local area network implemented as an Ethernet network. Any other local network may also be utilized. The invention also contemplates the use of wide area networks, the internet, the world wide web, and others. The interconnect fabric may be implemented with a physical medium such as a wire or fiber optic cable, or it may be implemented in a wireless environment.
HIDs - The HID is the means by which users access the computational services provided by the services. Figure 7 illustrates HIDs 721, 722, and 723. A HID consists of a display 726, a keyboard 724, mouse 725, and audio speakers 727. The HID includes the electronics need to interface these devices to the interconnection fabric and to transmit to and receive data from the services.
A block diagram of the HID is illustrated in Figure 8. The components of the HID are coupled internally to a PCI bus 812. A network control block 802 communicates to the interconnect fabric, such as an ethernet, through line 814. An audio codec 803 receives audio data on interface 816 and is _,„„„ PCT/US99/08665
WO 99/54803
12
coupled to block 802. USB data communication is provided on lines 813 to USB controller 801.
An embedded processor 804 may be, for example, a Sparc2eρ with coupled flash memory 805 and DRAM 806. The USB controller 801, network controller 802 and embedded processor 804 are all coupled to the PCI bus 812. Also coupled to the PCI 812 is the video controller 809. The video controller 809 may be for example, and ATI RagePro+ frame buffer controller that provides SVGA output on line 815. NTSC data 817 is provided in and out of the video controller through video decoder 810 and video encoder 811 respectively. A smartcard interface 808 may also be coupled to the video controller 809.
The computer systems described above are for purposes of example only. An embodiment of the invention may be implemented in any type of computer system or programming or processing environment.
In one or more embodiments of the invention, authentication and session management components are configured to authenticate users and locate and manage sessions. A session is a persistent representation of a related set of one or more services executing on behalf of a user.
Embodiments of the invention authenticate a user and relocate a user's session based on the current location of the user without requiring a service within a session to be configured to perform user validation and relocation. Embodiments of the invention authenticate the user once for all of the user's services. Using embodiments of the invention, services are directed to the HID (or other terminal device) that a user is currently using. It is not
RECTIFIED SHEET (RULE 91) ISA/EP necessary for the user to login to each service and establish a new connection for a specific HID.
According to embodiments of the invention, authentication is a one-way authentication which improves the manageability and scalability of authentication. There is no need to exchange keys and avoids the need to perform key lookups in a central database.
Figure 2 illustrates authentication and session management components and their interactions according to an embodiment of the invention. Network terminal 202 is a human interface device (HID) (e.g., HIDs 821, 822 and 823). An HID has, as examples of its functions, the task of displaying output of services to a user and obtaining input to services from the user. Network terminal 202 has the ability to respond to a command (e.g., display command) received from, for example, a software program (e.g., services 230-238, authentication manager 204 and session manager 206) executing on a computational service provider (e.g., computers 710, 711, 712, 713, and 714). The input received from a user is forwarded to, for example, a service that is fulfilling a user request.
More than one server can execute the services that comprise a session. For example, in session 208, service 230 is executing on server 210, services 232 and 234 are executing on server 212 and services 236 and 238 are executing on server 214.
A user accesses a system (e.g., a server, a session, a service and a network terminal) by initiating a login. During login, the user is validated by authentication manager 204. Various techniques can be used to allow the user to initiate a login. For example, the user can initiate a login by pressing a key on network terminal 202. In one embodiment of the invention, a user accesses the system by inserting a smart card in a card reader (e.g., card reader 216) attached to network terminal 202. A smart card is a card that is capable of storing information such as in a magnetic strip or memory of the smart card. The smart card can store user information such as a user's identification (i.e., user ID such as a 64-bit number) and a secret code (e.g., a 128-bit random number) that is transmitted to network terminal 202. The secret code is used during authentication.
Network terminal 202 is aware of (or can obtain) its interconnection network address and the address of authentication manager 204. When a user initiates the login, network terminal 202 initiates communication with authentication manager 204 to begin authentication. Authentication manager 204 is a program active (e.g., executing) on a computational service provider connected to network terminal 202 via an interconnection network such as a local area network (LAN), for example. It should be apparent, however, that network terminal 202 can be connected to authentication manager 204 using other interconnection network technologies such as a fiber channel loop or point-to-point cables. Network terminal 202 sends a startup request to authentication manager 204 that includes a user identification (userlD).
In one embodiment of the invention, authentication manager 204 responds to the startup request by initiating an authentication to validate the user. Authentication can include any mechanism that verifies the identify of the user to the system. A key or password known only to the user, or biometrics information can be used to authenticate the user. In an embodiment of the invention, authentication is performed by verifying a personal identification number (PIN) entered by the user at network terminal 202. Authentication manager 204 sends a command (i.e., a challenge command) to initiate entry of the user's PIN at network terminal 202. The user entry is packaged by network terminal 202 and transmitted to authentication manager 204 (i.e., a challenge response).
Authentication manager 204 verifies the challenge response with user information retained in authentication database 218, information supplied by the user and information that is generated during authentication. When the user is authenticated, the user is given access to a session (e.g., session 208).
If the expected result is received from the user, authentication manager 204 notifies session manager 206 (via a connect message) that the user has logged into the system on network terminal 202. Session information contained in authentication database 218 is used to identify the server, port and session identifier (ID) for session manager 206. Session manager 206 is a program that is active on a computational service provider and is connected to authentication manager 204 and network terminal 202 via an interconnection network, for example. Authentication manager 204 sends a message to session manager 206 using session manager 206's server and port information contained in authentication database 218.
In response to the connect message from authentication manager 204, session manager 206 notifies the services in the user's current session (i.e., the services in session 208) that the user is attached to network terminal 202. That is, session manager 206 sends a connect message to services 230-238 to direct output to network terminal 202. Session manager 206 ensures that services that are considered to be required services of the session are executing. If not, session manager 206 causes them to be initiated. The user can interact with services 230-238 within a session (e.g., session 208). Network terminal 202 is connected to servers 210, 212 and 214 (and services 230-238) via an interconnection network such as a local area network or other interconnection technology. The user can also start new services or terminate existing services.
The user can detach from the system by removing the card from card reader 216. Other mechanisms to express a disconnect can also be used with the invention (e.g., a "sign-off button on network terminal 202). Services 230-238 can continue to run even after the user removes the card from card reader 216. That is, a user's associated session(s) and the services that comprise a session can continue in existence during the period that a user is unattached (e.g., logged off ) from the system. When the user removes the card from card reader 216, network terminal 202 notifies authentication manager 204 (e.g., via a disconnect message) which notifies session manager 206 (e.g., via a disconnect message). Session manager 206 notifies services 230-238 (e.g., via a disconnect message) which terminate their transmission of display commands to network terminal 202. Services 230-238 continue execution, however, during the time that the user is not logged onto a network terminal. The user can log back in using a network terminal such as network terminal 202, connect to session 208 and interact with services 230-238.
While Figure 2 depicts a single instance of each, it should be apparent that there can be multiple instances of network terminal 202, authentication manager 204, session 208. For example, there can be more than one instance of authentication manager 204 servicing network terminal 202 or multiple instances of network terminal 202. Authentication manager 204 instances can be organized in a hierarchy according to the topology of the network or they can be globally available, for example.
Having more than one instance of the authentication manager improves the scalability of the system since it is possible to add (or remove) instances of authentication manager 204 based on the current load (e.g., the number of users). Further, reliability is improved since redundant instances of authentication manager 204 can be deployed.
Similarly, there can be a multiplicity of session manager 206 instances. Like authentication manager 204, multiple instances of session manager 206 can increase the scalability and reliability of the system.
Session Manager
Session manager 206 maintains session database 220 that contains mappings between users, sessions, and services. Session manager 206 manages the services that comprise each session managed by session manager 206. For example, session manager 206 maintains session 208 and services 230-238 within session 208.
To access a computational service provider, an account is first set up or enabled for a user. For example, to enable a user according to one embodiment of the invention, the user is given a userlD, a PIN and a smart card that stores the userlD and secret code. In addition, a session is created for the user. As described below, a session can have none or more required services. It may be necessary to initiate some of the required services when the session is created. Once a service is initiated, it continues to be active regardless of whether the user is connected to the system. The balance of required services can be initiated when the user first logs in. A user is not limited to one session. There can be multiple sessions associated with a user at any given time. Session database 220 contains records that identify the session(s) and service(s) within a session that are associated with a user. An enabled user can be removed from the system. When a user is removed from the system, all of the user's associated sessions are removed from the system and from session database 220. Services associated with the user's sessions are stopped as well.
Once a user is enabled to use a system, the user can log onto the system via network terminal 202. When session manager 206 is notified by authentication manager 204 that the user is connected to network terminal 202, session manager 206 notifies the user's session (i.e., the services that comprise a session). Session manager 206 consults session database 220 to identify and notify the session's services. For example, session database 220 includes information that identifies session 208 and services 230-238 that are included in session 208.
Session database 220 contains permanent session records and dynamic session records that identify sessions and the services associated with a session. Session database 220 can be one or more databases or data stores. For example, permanent session records can be stored in a configuration file while dynamic session records can be stored in memory in a database system. A permanent session record contains configuration information for a user and is typically created for a user at the time the user is enabled to use the system, for example. A dynamic session record identifies those services that are associated with a user. Dynamic session records identify the required services that are associated with a user session in a permanent session record as well as currently active services. The following contains a format for a permanent session record according to an embodiment of the invention: sessionID servicelD serviceHost servicePort isLazy
The sessionID field uniquely identifies the session that contains the required service(s). The servicelD field uniquely identifies a service associated with the session identified by sessionID. The serviceHost and servicePort fields identify the server on which a service is running and the port on the server by which a service can receive communications. The isLazy field identifies the manner in which a service is initiated. For example, isLazy can specify that the service is to be started immediately upon the creation of a session, or that the service is to be started when the user first accesses the system. There may be multiple occurrences of the servicelD, serviceHost, servicePort and isLazy fields each occurrence identifying a required service associated with the session identified by sessionID.
The dynamic session record identifies the required services for the session and those services that are currently executing in the session. A session's required services are retrieved from the permanent session record, for example. A dynamic session record can identify zero or more services (required or otherwise) that are currently executing on behalf of a user.
The fields that are used to store information about a service in a dynamic session record depends on whether the service is a required service or a service. A required service that is currently active is also a current service. The format of a dynamic session record that identifies a session's required services is the same as the permanent session record format. The following identifies the format for a record associated with a currently executing service according to an embodiment of the invention:
sessionLink TCPSocketfd requiredServiceLink servicelD The sessionLink field identifies the service's session. An open connection, or pipe, is established between session manager 206 and a currently executing service in a session. The open connection can be used to notify either session manager 206 or the service that the other has abnormally, or otherwise, terminated. In one embodiment of the invention, the open connection is a TCP socket connection which is identified by the TCPSocketfd field. However, it should be apparent that any form of reliable connection technology that could provide a notification that a connection is disabled or disappears could be used with embodiments of the invention.
The service has an identifier that is stored in the servicelD field. A currently running service can be linked to a required service. A link to a required service is identified by the requiredServiceLink. If there is no link to a required service, the requiredServiceLink is null.
The dynamic session record can also be used to store information about a connection to a network terminal (e.g., network terminal 202). The following contains the fields that identify the connection according to an embodiment of the invention:
sessionLink Status IPAddress
Multiple sessions can be associated with a user. The sessionLink field identifies the session to which the user attached to network terminal 202 is currently linked. The sessionLink can have as its value the sessionID value, for example. The status field identifies the connection status (i.e., connected or disconnected) of network terminal 202 to the session. The IPAddress field contains the interconnection network address of network terminal 202. An IP address is used in one or more embodiments of the invention. However, it should be apparent that alternative interconnection technologies may use alternate addressing schemes. For example, an asynchronous transfer mode (ATM) network might use a thirteen digit switch prefix/end point identifier.
This information can be used by session manager 206 to send a status message to network terminal 202. If network terminal 202 does not respond within a certain period of time, session manager 206 assumes that network terminal 202 is no longer in use by the user and sends a disconnect message to each of the services in the session.
Other information of which session manager 206 is aware include a list of the open connections (e.g., services having an open TCPsocketfd) to services and a mapping between open connections and sessions and the services within a session. This information can be compiled from the session records, for example.
The information available to session manager 206 can be used to locate a session. For example, given a service, it is possible to find a session that contains the service and/or the services that are contained within a session. Further, it is possible to locate a session that is associated with a given user or instance of network terminal 202 whether or not it is currently executing, for example.
Service Initiation
When session manager 206 receives a message from authentication manager 204 that a user is connected to network terminal 202, session manager 206 initiates those required services that are not currently active. Session manager 206 further notifies the currently active services to direct input/output (I/O) to network terminal 202. I/O can be expressed using a command protocol used to communicate with network terminal 202 and its peripheral devices. (Appendix A contains an example of a command protocol according to an embodiment of the invention.)
To initiate a service, session manager 206 accesses the server on which the service is to execute to start the service. For example, session manager 206 sends a request to a well-known port on the server and passes the sessionHost, sessionPort and sessionID for session manager 206. The server connects to network terminal 202 that is attached to the service and uses the server's native authentication and permissions to allow the user to access the server. For example, in a UNIX operating environment, a UNIX service could start with a "CDE Login" screen displayed at network terminal 202 to authenticate the user and ensure that the user wishes to connect to the service.
For session manager 206 to start a service on a server, it is given the privileges needed to start the service. It may be undesirable to give session manager 206 these privileges. Further, in current networking environments, servers may be running different operating environments. In this case, session manager 206 must be aware of each operating environment's procedures for initiating a service.
Alternatively, a session-aware application running on the server can perform the initiation and register the service with session manager 206. In this case, it is not necessary for session manager 206 to have the needed privileges. Further, session manger 206 does not have to implement a centralized model for initiating services on multiple operating environments. The responsibility for initiating services is left to the session-aware applications that are running in the different operating environments. A session-aware server application has knowledge of session manager 206 (e.g., has the sessionID, sessionHost and sessionPort of session manager 206) and its interfaces (e.g., message formats).
The session-aware server application can initiate a service in response to a request received from session manager 206. Session manager 206 sends an initiate message to the server application that possesses the permission to start services in the server's operating environment. The server application initiates the service for session manager 206 and responds to session manager 206 with a valid sessionID. On the UNIX and NT systems, for example, the sessionID can be made available in the operating environment. Services such as video windows might start in this manner, for example.
Alternatively, the session-aware application can contact a service to obtain its permission in the form of a cryptographically signed authorization. The server application can transmit the sessionID and the signed authorization to session manager 206. If the session-aware application contacts session manger 206 without an authorization but with a description of the service, session manager 206 could request approval from network terminal 202 to ensure that the user authorized the service. If the user responds affirmatively, the service is added to the session.
Session Manager Messages
Session manager 206 receives and generates messages to manage the services within a session. Techniques other than those described herein can be used for initiating services. If session manager 206 initiates a service, it sends an initiate message to the server (or session-aware server application). Session manager 206 can generate an initiate message to start required services identified in session database 220, for example. As another example, session manager 206 can send an initiate message to re-activate a required service that it has determined (e.g., via an open TCP connection between session manager 206 and the service) has terminated.
Session manager 206 receives a connect message when a user of network terminal 202 successfully attaches to the system. In response to the connect message, session manager 206 verifies that all of the required services are started, and starts those that are not running. Session manager 206 sends a message (e.g., a connect message) to the services in the session to direct I/O to network terminal 206.
When a disconnect message is received, session manager 206 sends a disconnect message to each one of the services in the session directing them to terminate sending I/O to network terminal 202.
Session manager 206 can send status messages to network terminal 206 periodically to ensure that network terminal 202 is still connected. For example, session manager 206 can examine session database 220's dynamic session records to identify each session that is currently connected to a network terminal. That is, session manager 206 can examine the status field associated with a network terminal in a dynamic session record in session database 220. Session manager 206 sends a status request (e.g., a "ping") to each network terminal that is connected with a session. If an answer is not received from network terminal 202 within a certain period of time (e.g., 20 seconds) for a particular session, session manager 206 assumes that the session is disabled and it sends a disconnect message to each service in the session instructing them to terminate display functions.
Network terminal 202 responds to the status (e.g., ping) request from session manager 206 with either a "Card In" or "Card Out" status. If a "Card Out" status is received from network terminal 202, session manager 206 sends a disconnect message to each of the session's services.
If the "Card In" status is sent in response to a status request, network terminal 202 also indicates the number of insertions of the card in card reader 216, the number of seconds since a card insertion, and the cardlD. The cardID is, for example, the value of sessionID for the user's session. Session manager 206 retains at least the last status information received from network terminal 202 to compare the new status information against the previous status information. If, for example, the number of insertions or the number of seconds for insertion differs from the last status information, session manager 206 considers the session to be disabled. In this case, session manager 206 sends a disconnect message to the session's services.
When a service is started by, for example, a session-aware server application, a service connect message is sent to session manager 206. If the service has the proper authorization, session manager 206 adds the service to the list of services for the session and sends a message to the service to direct I/O to network terminal 202.
Authentication Manager
The authentication manager is responsible for ensuring the legitimacy of a user and associating a user with a session(s). During the initialization process (which is described in more detail below), an authentication exchange takes place to authenticate the user in one embodiment of the invention. Authentication can be include any mechanism that verifies the identify of the user to the system. For example, a key password can be entered or biometrics data can be collected to authenticate the user. Authentication database 218 contains user and session information that can be accessed by authentication manager 204. In one embodiment of the invention, the format of a record contained in authentication database 218 is as follows:
userlD secret PIN sessionHost sessionPort sessionID
The userlD and secret fields contain the same values as those stored in a user's smart card. The userlD and secret values are typically established when the user is enabled to use the system, for example. In one embodiment of the invention, the secret field contains a 128-bit value. The PIN field is the personal identification number (PIN) that is known to the user and requested by authentication manager 204 during authentication. The userlD, secret and PIN values are used to authenticate a user. Authentication database 218 could contain other information such as a password or biometrics data, if they were used to authenticate a user.
The sessionHost field identifies the computational service provider
(e.g., a server) that is executing session manager 206 that is managing the user's current session. The sessionPort field identifies the port for communicating with session manager 206. The sessionID field contains a unique identifier for session manager 206. If authentication is successful, the sessionHost, sessionPort and sessionID fields are used to notify session manager 206 of the user's location at the network terminal 202.
In an embodiment of the invention, a challenge mechanism is used to authenticate a user. (Figure 6 provides a challenge process flow according to an embodiment of the invention.) Authentication manager 204 sends a challenge to network terminal 202 to verify the authenticity of the user. Network terminal 202 prepares the challenge response, and returns it to authentication manager 204. If the response to the challenge is as expected, the user is verified to authentication manager 204.
Figures 5A-AB provide an authentication process flow according to an embodiment of the invention. The authentication process can be repeated more than once until authentication is successful or the number of repetitions, or rounds, exceeds a certain number. At step 502, an identifier that represents the number of the authentication round is initialized to zero. At step 504, a random number is generated that is used as the challenge number. At step 506, authentication manager 204 sends an N_AUTHENTICATE command to network terminal 202 as well as a packet of information for the authentication process.
In one embodiment of the invention, the following information is sent in conjunction with the N_AUTHENTICATE command:
code identifier length valueSize value
The code field identifies the type of information contained in the information packet. For example, a value of "1" indicates that the information packet contains a challenge. The identifier field contains the value (i.e., the round indicator) that was generated at step 502. The length field identifies the length of the information packet. The value field contains the random number, or value of the challenge, generated in step 504. The valueSize identifies the size of the value field (e.g., 128 bits).
At step 508, authentication manager 204 sends rendering commands to network terminal 202 prompting the user for the user's PIN. At step 510, authentication manager 204 waits for a response from network terminal 202 or a timeout. If a timeout is detected at step 510, processing continues at step 514 to determine whether the maximum number of rounds has been exceeded. If not, processing continues at step 518 to increment the identifier and processing continues at step 504 to begin a new authentication round. If it is determined, at step 514, that the maximum number of rounds has occurred, processing continues at step 516 wherein authentication manager 204 sends rendering commands to network terminal 202 indicating a failure and the authentication process ends. Rendering commands can be, for example, part of a command protocol used to communicate with network terminal 202 and its peripheral devices.
A challenge routine includes commands sent by authentication manager 204 to network terminal 202 to capture the PIN entry by the user and generates a response. Network terminal 202 generates a response value that is the output of a hash function (i.e., a hash value or challenge response) from an input including the user's PIN, the value of the identifier, the value of the secret stored in the user's smart card and the value of the challenge (e.g., the random number generated in step 504).
A hash function can take variable-length input and convert it to a fixed-length output (a hash value). One example of a hash function takes the input and returns a byte consisting of the exclusive-or (XOR) of all the input bytes. There are many other examples of hash functions that can used with embodiments of the invention. The hmac_md5 function (RFC2104) is one example of a hashing function that is used in an embodiment of the invention to generate a response. The following packet format is used by network terminal 202 to send the response to authentication manager 204 according to one embodiment of the invention:
code identifier length valueSize value userlD
The code field is set to a value of "2" which indicates that the information packet contains a challenge response. The value field contains the challenge response (e.g., the result of a hashing function). The userlD field contains the user's userlD.
If authentication manager 204 determines (at step 510) that it received a response from network terminal 202, processing continues at step 512 to determine whether the identifier returned by network terminal 202 matches the identifier generated by authentication manager 204. If so, processing continues at step 520 to examine the response returned by network terminal 202.
At step 520, authentication manager 204 determines whether the challenge response matches the response expected by authentication manager 204. For example, authentication manager 204 can generate a hash value using its identifier, PIN, secret and challenge values. If the hash value generated by authentication manager 204 matches the challenge response generated by network terminal 202, authentication is partially successful. Authentication manager also verifies that the interconnection network address of network terminal 202 and the user's userlD are valid. If the challenge response, interconnection network address and userlD are verified, authentication is successful. If not, authentication failed. If authentication is successful, processing continues at step 528 to send an N_AUTHENTICATE command. The format of the command, according to an embodiment of the invention, is as follows:
code identifier length
The code field contains a value of "3" to indicate that the user was successfully authenticated. Processing continues at step 530 to send rendering commands to network terminal 202 indicating that session manager 206 is connecting the user to one of the user's sessions. At step 532, authentication manager 204 notifies session manager 206 that the user is connected to the system via network terminal 202. Authentication manager 204 sends the interconnection network address of network terminal 202 and session manager 206's sessionID to the server that is executing session manager 206 (i.e., the server identified in the sessionHost field of the user's authentication database record) at step 532.
If authentication failed, processing continues at step 522 to send an
N_ AUTHENTIC ATE command. Like a successful authentication, the N_AUTHENTICATE command includes a code field that indicates the status of the authentication process. A code value of "4" is used, for example to indicate that authentication failed. Processing continues at step 524 to send rendering commands to network terminal 202 indicating that the authentication failed and instructing the user to remove the smart card from card reader 216.
The authentication process ends at step 526.
The process described with reference to Figures 5A-5B is one example of an authentication process. It should be apparent that other authentication techniques can be used with embodiments of the invention. In an alternate embodiment the user is not requested to enter a PIN. The user's card in card reader 216 is enough to authenticate the user. The userlD and secret value can be hashed with the identifier and the challenge received from authentication manager 204 to generate a response to a challenge by authentication manager 204. In this way, a user can attach to the user's services simply by inserting a card containing valid information into card reader 202.
Further, it should be apparent that embodiments of the invention can be used wherein no authentication of a user is performed. For example, in a trusted or secure environment there may be no need to verify the authenticity of a user. Therefore, in one embodiment of the invention, a user is connected to a session without first being authenticated by authentication manager 204. The user need only provide an identification (e.g., userlD), for example. If the user provides a valid userid, the user is given access to the session that is associated with the userlD.
When the user disconnects from network terminal 202, authentication manager 204 is informed and informs session manager 206 of the disconnection. For example, when the user removes the smart card from card reader 216, card reader 216 informs network terminal 202. Network terminal 202 informs authentication manager of the disconnection. Authentication manager 204 informs session manager 206 that the user has disconnected from network terminal 202. Session manager 206 notifies each of the services in the user's session. Challenge Routine
The authentication process can include a challenge initiated by authentication manager 204. Figure 6 provides a challenge routine process flow for handling a challenge according to an embodiment of the invention. The challenge routine executes on network terminal 202 in response to a challenge command received from authentication manager 204.
At step 602, the key entry received from the user is read until a return or enter key is pressed. The key entry is translated to ASCII characters at step 604. At step 606, a hash function is used to generate a hash value, or challenge response, from the concatenation of the identifier, PIN, secret, and challenge values. The challenge response is sent to authentication manager 204 at step 608. At step 610, network terminal 202 awaits a response from authentication manager 204 or a timeout. If a response or a timeout occurs, the challenge routine ends at step 614.
Network Terminal Initialization
Network terminal 202 performs some initialization when it is first turned on. While a user is not using network terminal 202, network terminal 202 can be in a dormant state if it is powered on. A user can awaken network terminal 202 from its dormant state using one of the techniques described herein, for example. It should be apparent that other techniques can be used to awaken network terminal.
Figure 3 provides a process flow for initializing network terminal 202 in response to a power up operation according to an embodiment of the invention. At step 302, a determination is made whether a power up operation has occurred. If not, processing continues to wait for a power up operation. At step 304, a request is generated by network terminal 202 to the network to test the network connection. At step 306, a determination is made whether a response is received. If not, processing continues at step 310 to generate an error and processing continues at step 302 to await a power up operation.
If it is determined, at step 306, that an answer is received, processing continues at step 308 to send an acknowledge (an ACK) message and initialization of network terminal 202 can continue at step 402 of Figure 4A.
Figures 4A-4C provide a process flow according to an embodiment of the invention for initializing network terminal 202 in response to an awaken operation. Referring to Figure 4A, network terminal 202 waits for notification of the awaken operation. In an embodiment of the invention, the awaken operation is the insertion of a user's smart card in card reader 216.
If it is determined that a smart card is inserted in card reader 216, processing continues at step 404 to send a request to obtain the interconnection network addresses of authentication manager 204 and network terminal 202. Alternatively, a user's smart card can be preprogrammed with the interconnection network addresses. Network terminal 202 can read the interconnection network addresses from the smart card via card reader 216, for example.
At step 406, network terminal 202 awaits a response or a timeout. If a timeout occurs, processing continues at step 412 to determine whether the maximum number of tries has been exceeded. If the maximum number of tries has been exceeded, processing continues at step 410 to generate an error. If the maximum number of tries has not been exceeded, processing continues at step 414 to increment the number of tries and processing continues at step 404 to resend the request for the interconnection network addresses.
When a response to the request is received, processing continues at step 408 to send an ACK. Processing continues at step 416 of Figure 4B. At step 416, network terminal 202 sends a startup request to authentication manager 204. At step 418, a retry time is set in which network terminal 202 waits for a response to the startup request. At step 420, a variable is set to indicate that network terminal 202 is waiting for a response to the startup request. At step 422, network terminal 202 waits for a response to the startup request.
If it is determined that a response is not received, processing continues at step 424 to determine whether the retry time as been exceeded. If not, processing continues at step 422 to wait for a response. If the retry time has been exceeded, processing continues at step 426 to determine whether the maximum number of tries has been exceeded. If not, processing continues at step 428 to generate an error and return to step 416 to resend the startup request. If not, processing continues at step 430 to increment the number of tries and reset the retry time. At step 432, the startup request is resent and processing continues at step 444 to determine whether the card has been removed from card reader 216.
If it is determined, at step 422, that a response was received, processing continues at step 434 of Figure 4C. At step 434, network terminal 202 examines the variable initially set in step 420 to determine whether it is waiting for a response to the startup request. If so, processing continues at step 436 to determine whether the response is a challenge message. If not, processing continues at step 424 to repeat the startup request if the maximum number of tries has not been exceeded. If it is determined, at step 436, that a challenge message has been received, processing continues at step 438 to set the waiting_for_startup variable is set to no (i.e., "N"). Processing continues at step 440 to process the challenge request at steps 440 and 442. The challenge request can be handled as described above with reference to Figures 5A-5B and 6, for example.
If it is determined, at step 434, that network terminal 202 is not waiting for a response to a startup request, processing continues at steps 440 and 442 to handle the message (e.g., rendering commands to display output generated by service 234).
At step 444, a determination is made whether the user has removed the smart card from card reader 216. When the user removes the card from card reader 216, network terminal 202 sends a disconnect message to authentication manager 204 at step 448. Network terminal 202 waits for an acknowledgment (ACK) message from authentication manager 204. When the ACK message is received, network terminal 202 clears the screen, at step 450, and returns to step 402 to wait for another user to insert a smart card in card reader 216.
If it is determined, at step 444, that the user has not removed the card from card reader 216, processing continues at step 446 to determine whether network terminal is waiting for a response to its startup request. If so, processing continues at step 422 to determine whether a response has been received. If network terminal is not waiting for a response from a startup request, processing continues at steps 440 and 442 to process any messages sent to network terminal 202. Message Format
In an embodiment of the invention, a connection to network terminal 202 is established via a user datagram protocol (UDP) port. That is, packets are sent via a UDP connection and received at a destination UDP port. The destination UDP port uniquely identifies the connection. Packet length and checksum information are provided by the UDP header. Buffer size fits in an Ethernet Maximum Transfer Unit (MTU) with IP/UDP headers. Data is sent over the network in network byte order (big-endian).
It should be apparent that other protocols can be used in place of UDP. For example, protocols such as an ATM AAL5 (AAL or ATM Adaptation Layer) can be used.
Thus, a method and apparatus for session management and user authentication has been described. Particular embodiments described herein are illustrative only and should not limit the present invention thereby. The invention is defined by the claims and their full scope of equivalents.
APPENDIX A
Command Protocol Example
Rendering Commands
Wire Protocol. Command Formats
All data is sent over the network ir. n twork byte order (big-endian) and bιt-£ιeic.≤ are packed from MS3 to LS3.
The basic rendering cαrmand fo~> s:
<COMMA D:8> <SΞQO~NCΞ : 24> <X:i5> <"::1S> <WIDΪΞ: ic> <H ZIGHT : 16> <Ir.fo>
COMMAND Code <I?.fo> Descriotion
Set OxAI WIDTH'HEIGHT of 32-bit values <X,3,G,R> [ IDTH'HEIGHT <= 512 pixels]
1 ι 0xA2 one 32-bit value <X,3,G,R>
Glvnh 0xλ3 one 32-bit value <X,3,G,R>, (HEIGHT * ceiling (WIDTH/3) ) bytes of bitmap (i.e. each line padded to 8 bits] [WIDTH'HEIGHT <= 2048 pixels]; the entire cc---i.-d is padded to the next 32-bit boundary
Copy 0xA <? 0M_X : 16> <F OM_Y : 16> 3ιlevel 0xA5 t o 32-bit values cO, and ci, <X, Ξ,G,R>, followed by (HΞIGHT - celling (WIDTH/S) ) Dytes of bitmap (i.e. εacn line pacαeά to 8 bits] (WIDTH'KZIGHT <= 2048 pixels]; the entire ccrr-.T nc s padded to the next 32-c ooundary
Set24 0:<Aδ WIDTH-HEIGHT of packed 24-b C values <3,G,R> (WIDTH-HEIGHT <=» 512 pixels] padded to the next 3 -b t boundary
Set ΪUV Image 0xA7 <SOURCΞ_W : Lό> <SOURCE_K : l z>
<RfU:3> <LUMA_ENCOOING:2> <CHR0MA_SU3_X : 3> <CHRCHA_SU3_Ϊ .3> followed by (SOQRCE_w ≤OϋRCΞ_K) pixels ϊ (luma] witn eacn li e padded to a byte boundary, and (ceiling (SOURCΞ_W / x_su sample) ceiling (SOURCΞ_H / y_subsa pie) ) bytes each of 8-bit signed J anc V (chroma] in CCIR-501 value encodings; tne entire ccmmar.G is oadcec to the next 32-oιt boundary; (SOURCΞ_w ' S0ϋRCΞ_H <= 1024 pixels]; (SOϋRCΞ_W <= WIDTH]; *(SOϋRCΞ_H <= HEIGHT]
Set Cursor OxA.9 two 32-bit values cO, and ci,
<X,3,G,R>, followed oy two sets of (HEIGHT - ce ling (WIDTΞ/3 ) ) bytes of bitmap (i.e. each l ne padceα to 8 bits] (WIDTH 5 HEIGHT <= 54 pixels each] . The first bitmap is the pixel values, the secon is the per-pixei mask. The entire command is aάά ά to the next 32-bit boundary.
Set Pointer OxAA <INDΞX:8> <DIM:2> <?AD : δ>
( <Z:Iδ> { <?:I6> <R:Iδ> <H:16> <?ΛD:16> } } 1 <?A :15> note that ail values are signed, 2's compliment. Angular values range from -180 to -180- (1 lsb)=-17S.9S45 (degrees over full range .
WIDTH, HEIGHT are ignored.
Set Kev Locks 0xA3 X, ϊ, WIDTH, HEIGHT ignored.
<i DΞX:8> < OCXS:8> <?AD:Iδ>
Damage Repair OxAC <Ξ?CCH:32> <?AD:8> <SΞQ:24>
Play Audio 0x31 X, ϊ, WIDTH, HEIGHT are encoded as follows :
X:4 audio sequence number X:12 interleave offset ϊ total sequence length-1
WIDTH: 4 mixer mode specifies the i of channels to include m the standard mix. Channel numbers above this numoer are sent raw and not combined w th any other channel f the terminal has insuff cent channels to cover tne request.
WIDTH: 12 packet len in samples max 2000 bytes
HEIGHT 4 number of channeis-I HEIGHT: 12 interleave sι:e-i
The header is followed by the specified number of samples x r.umoer of channels x Iδ bits.
The entire command is pacdec to 22 nits .
The sequence numoer is incremented for eacn command. Sequence numbers may not be ail zero except for a epoch cnangmg flush commanα, cescri ed below. R.ectangies may not wrap. I.e. x-width < 0x10000 and y-height < 0x10000
One acd t cnal informational command is defmec with a different format :
<COMMAND:S> <SΞQUΞNCΞ : 24> <Ξ?OCH:32> <FIL!:16 * 8>
COMMAND Code
r lush OxAF
The sequence number of a flush command is the same as the sequence number of the previous command, with the exception of epoch changes (see description below) . That is, sequence numbers only increment wnen pixels change or the epoch cnanges .
Command Descriptions
Commanα DescriDtion
Set Set the rectangle defined by <x, y> <wιdth, heιght> to tne pixel values that follow. Tnere is one pixel value for each pixel m tne region. The layout is oy rows; i.e. there are "width" pixel values for pixels at <x, y> through <x+wιdth-l, y> followed by pixels at <x, y+l> through <xτwιdth-l, y+l>, etc. <0, 0> describes the upper left corner.
Fill Set ail pixels in the rectangle defined by <x, y> <wιdth, heιght> to the single 32-bit value.
Glyph The 32-bit value is placed in the pixel location corresponding with 'each one bit in the bitmap, positions associated with zero bits are unchanged. The bitmap is laid out by rows (y, y+1- ) using MS3 to LSB in each byte.
Copy Copy the rectangle defined by
<from_x, from_y> <wιdth, heigho to the rectangle defined by <χ, y> <^ dth, heιgnt>. The client must ensure overlapping regions are copied correctly (e g see Solaris ostrmg(3)).
3ιlevel The two 32-cιt values cO and cl, are placed m the pixel location corresponding with eacn zero and one bit, res ect vely, m tne tit ap The bitmap is laiα out bv rows (y, y-1, ...), using MS3 to LS3 n eacn byte.
Set24 Set tne rectangle defined by <x, y>
<wιctn, hειgr.t> to the pixel values that follow. The pixel values are packed sucn tnat there are four pixels defined by t.-.ree 32-bit values tnusly: <bgrn, grog, rrgr> . If width is not a multiple of four, the end is packed the same as aoove witn the remaining values anc padced to the nearest 32-oιt value. There is one pixel value for eacn pixel m tne region. The layout is oy rows; i.e. there are "width" pixel values for pixels at <x, y> througn <x-wιαtn-l, y> m ((3 * viGth T 3) / 4) 32-oιt words followed by pixels at <x, y-l> t.rough <x-wιdth-I, y-l>, etc. <0, > cescri εs the upper left corner.
Set YUV Image Set tne rectangle αefmed by <x, y> <w dtn, neιgnt> to the pixel values provided as follows The image m CCIR/ITU 3T-OC1 Y'CbCr (or YTJV) format of source w oy source h pixels is decoαεd to R.G3 Tne cr.roma elements may oe suosamplec m tne horizontal ar.c/or vertical dimensions as speciflee and must oe up-samplec prior to tne trans formation.
Tne values cf CHR0MA_Sϋ3_X anc CHR0M?._SU3_ϊ (x suosarrole ar.c y_suosample, respectively) are encodec as follows :
0 - No chroma values; monocnrome image .
1 - Subsampie by 1 ( .e. no subsample)
2 - Suosa pie by 2
3 - Subsample by 4
4-7 - Unde med/reservec ϋMA_ENCODING values are.
0 - ϊ (iuma) is specified by 8-bit unsigned data
1 - Y (luma) consists of 4-bit quantized DPCM values (see below) . 2,3 - Undefined/reserved
RFU is reserved for future use and must be 0.
After decoding, the RGB image is scaled up as necessary to width by height pixels. The resulting image is put on the display at location <x, y> .
Note: if both CHROMA_SU3_X and CKR0MA_SU3_Y are zero, the image is monochrome (luma only) and no U or V data is present. It is invalid to have one set to zero and the other non-zero.
The component order is Y (or CCIR- Ol Y' ) , U (CCIR-601 Cb) , and then V (CCUR-δOl Cr) .
Set Cursor This command sets the appearance of the local display cursor (moved and reported by Pointer [0]) . The cursor is a maximum of a 64xδ4 block, but may be any size less than that. If the mask value for a particular pixel is ' 1' , the corresponding cursor pixel is displayed; if the mask is '0', the cursor is transparent at that location. hen the mask is ' 1' , the pixel value is 'c0' when the value is '0', and 'cl' when the value is '1' . If the mask is zero, the pixel value should also be zero. A mask of zero and a pixel value of one is reserved for future expansion.
WIDTH and HEIGHT may be zero, indicating not to draw a cursor (equivalent to a mask of all zeros) . Pointer tracking continues to work normally ,
X and Y denote the 'hot spot' for the cursor; e.g., on what pixel of the cursor image events are to be reported. This is primarily used for stopping thε cursor on the edges of the display. X (0, WIDTH), Y (0, HEIGHT).
Set Pointer Sets the location of a pointer.
Pointer (0] is usually settabie (mouse or touchscreen) and is the 2-D screen cursor. This command is provided for applications that insist on setting their pointer, or for applications that need relative pointers (e.g. reset the cursor to its previous position) . As such, there are a few restrictions: setting the pointer may not work (e.g. a ]oystιck) at all the pointer value may be clipped arbitrarily to match the pointer device or the screen the user can continue to move the pointer once it is set, but that is reported using a 'Pointer State' status message. the behavior of resetting the pointer for pseuαc-relativε moαe could cause different behaviors with different devices; e.g. a touch screen, is only settable when the user is not ' dragging' .
Pointers are allowed to ave up to six dimensions. The numoer of dimensions and the size of the command are set using the DIM bits. All pointer values are signed, 2's compliment.
Set Key Locks This command sets the lock values for an <INDEX>'ed keyboard. Locks generally correspond to lights on the keyboard that are software controllable. If a lock condition is to be indicated, then the bit should be set m the mask, otherwise, the bit should bε cleared. Since some keyboards may implement locks locally (e.g. mechanically), setting a lock may not have an affect. Keys from the kevDoard should always be interpreted from the state reported by the keyboard. On the other hand, the host s required to issue a Set Key Lock command on reception of a locked keycodε, if that is what the interface dictates, because both normal keyboards and the terminal do not attempt to handle locking locally. This is because the terminal does not uncerstand the keyboard or dεsirec user interface semantics.
The key lock bitmap s from the US3 class definition for 3oot Kevboarcs :
0x01 Hum Lock
0x02 Caps Lock
0:<04 Scroll Lock
0x03 Compose
0x10 Kana
All other bits are reserved — ignored on read, zero on set.
Damage Repair This informs the client that all damage messages for sequence number SEQ in epoch EPOCH and earlier have been processed and repair data sent, (see the Damage back-channel command) . PAD must be 0. X, Y, WIDTH, and HEIGHT must be 0;
Play Audio This plays 48kHz audio samples, and may be imbeded in a graphics command stream.
An undefined number of streams are received by the terminal on a first-come-first-serveα basis. Streams are allocated on an as-needed basis and are broken down when buffer starvation occurs (there is no data to play when its time comes — partially received buffers are error concealed and played) . The terminal corrects for timebase drift.
Data is sent in an interleaved manner to aid m network error concealment. A sample sequence s split into an interleave size and at most 1+ (sequence size) / (interleave size) samples are emmitted per packet . The samples are selected as follows: sample sequence [sample_sιze] ; mt seq_numoer = 0; while (1) { get_sampies (sequence, saiiiple_sιze) ; for (ι = 0; i < mterleave_sιze; i÷÷) { interleave_o fset
= random_select (0..mterieavε_size) ; packet=new_packet (seq_number, sa ple_s ze, num_chan, num_chan, inte leave_size, ιnterleave_offset) ; for (j = interleave_of fset; j < sample_size; ] -= interleave_sιze) emit (packet, sequence (]]) ; send_packe (packet) ;
sεq numbεr = (sec nu oer÷l) £16;
} note that the order that the packets are sent can (and probably should) be random.
For example, for an interleave of 3 and and sequence size of 8, the following tnree packets could be sent:
(samples) (0 1 2 3 4 5 6 7) pkt 1, off 1 1 4 7 pkt 2, off 0 0 3 6 pkt 3, off 2 2 5
The sequences are numbered so that the terminal knows when to error conceal 'and emit a sample sequence . Samples are 48kHz, 16 bit linear, and may contain up to 16 channels. For example, a 5-channel sample would take 10 consecutive bytes .
There is no den ition for the number of audio channels supported by the terminal, nor any way to fmd out, but up to 16 channels can be sent at once. Since there may be a different numoer of channels sent than the termina1 supports, the concept of a standard mix is introduced for the first 8 channels . This may oe disabled by setting the "MIX" field tnat guarantees certain indexed channels are not to be mixed togethe: The last 8 cnannels are mixed m tne same scneme as the first 8 so that sound may be heard. If there are sufficient channels, then results are terminal setun denendent .
The standard assignee channels are as follows:
channel -> chan 0 1 2 mono
1 r
1 r sw
1 r rl
1 r rl sw
1 r - JL sw cr τ_ — ri sw cf top
1 r rl s cf cl c:
(l=left, r=πght, r (lr] =rear( left, right } sw=su woofer, cf=center f ll, c(lr]=cεnter (left, right] , top=center-center
For example, if there are two speakers and one cnan el is sent witn tne standard mix enaolεc, the one cnannel will oe sent to botn tnε lεft and rig.it speakers. Conversely, f the same terminal were sent 6 cnannels, channels 0,2,4,5 will be mixed and sent to the left speaker ana channels 1,3,4,5 will be mixed and sent to tne rig t speaker.
The terminal speakers are set up tne same manner
The full mixing matrix is available in the full soecification .
Flush There may be no commands in the display stream for a period of time following this command; therefore, this s a good point for clients to flush all unfinished rendering to the screen. 'The epoch field provides 32 additional high order bits for the sequence numbers. FILL consists of 16 bytes set to all OxFF. This command provides an opportunity to re-synchronize data stream after a drop-out.
The sequence number of a flush command is normally the same as the last non-flush command. However, when a epoch is exhausted, ( .e. . the sequence number of the last command is OxFFFFFF) , a flush command with a sequence number of zero and a new epoch number (incremented by 1) is sent.
Back-channel Commands
Wire Protocol Status Message Formats
The basic status command format is: <COMMAND:8> <TIMΞ:24> <Info>
COMMAND Code <Info> Description
Kεvboard State Oxcl <INDEX:8> <COUNTRY_CODΞ : 8> <LOCXS : 8> <MODIFIERS : 8> <KΞYCODE:8>(8]
Pointer State 0xc2 <INDEX:8> <DIM:2> OUTTONS : 6> <X:16> {<Y:16>
(<Z:15> (<?:16> <R:16> <Ξ : 16> } } } note that all values are signed, 2's compliment. .Angular values range from -180 to +180- (1 lsb)=÷179. 945 (degrees over full range .
DIM Dimensions
0 X
1 X, Y
2 X, Y, Z
3 X, Y, Z, P, R, H (yaw)
Active Region 0xc3 <X:16> <Y:16> <WIDTH: 16> <HEIGHT:16> Damage 0xc4 <EPOCH:32> <PAD0:8> <SEQ_L:24> <PAD1:8> <SEQ H:24> Note: TIME is in microseconds; it wraps after 2**24 (approx 16 seconds) .
Status Message Descriptions
Command Description
Keyboard State Reports tne state of the <INDEX>'ed keyboard. The country code is from tne USB Device Class Definition for HIDs, section 6.2. The locks are from tne US3 class definition for boot keyboards :
0x01 Num Lock
0x02 Caps Lock
0x04 Scroll Lock
0x08 Compose
0x10 Kana
The 'Set Key Locks' command may be usεd to reset these locks, and should be used if a lock key is detected at the host since keyboards generally don' locally handle lock status, and the terminal certainly doesn't either. Bits other than those specified are reserved and should be ignored. On set, they should be set to zero
The modifier b ts are from the US3 class definition for boot kevboards as well:
0x01 Left Control
0x02 Left Shift
0x04 Left Alt
0x08 Left GUI
0x10 Right Control
0x20 Right Shift
0x40 Right Alt
0x80 Right GUI
There s always space for six key scancodes . All keys (tnat are not modifiers) that are pressed are reported, up to six keys. This provides simple roll-over and chording capabilities. The scan codes are from the USB class de inition for boot keyboards .
Of special note is code 0x00 denoting no event in the slot, and 0x01 in ail slots indicates that more than 8 keys have been pressed. Modifiers are still reported in this state. Once less than 9 keys are pressed, normal reports resume. 'Report order is arbitrary and does not reflect order of events .
Pointer State Reports the state of the <INDEX>'ed pointer. DIM indicates the number of dimensions reported: 1, 2, 3, or 6. The buttons are from the US3 class definition for boot keyboards, bit zero is the 'primary' button (on the left) , and the numners increase from left-to-right . The reported values are all absolute and are signed, two's compliment.
Active Region Indicates the area of the logical framεbuffer that is retained on the newt. Specifically, this s tne area that tne "" rom" region of Copy rendering commands can be specified successfully.
This region may change over t me on a given client, for example, due to a pan-anά-scan style of interface in a hanα-neld dεvicε. Also, different client αεv cεs may rεport different active regions.
Damage Indicates that downstream (render) commands from sequence number SΞQ_L through and including sequence numoer SΞQ_H n epoch EPOCH were not received by the client from the server. PADO and PAD1 must be 0.
The client will continue to rεport damagε until a Damage Repair mεssagε for the affected sequence numoer is received.
If SEQ_L is 0, then the full current screen image must be sent.
Oncε a damage message is sent for a given sequence numoer, no new subsequent damage may be sent for earlier sequence numoers . However, it is permissible to collapse two or more ranges into one in order to save space m later status oackets .
DPCM YUV Description:
Further compression o f YUV data is possible with the LUMA_ENC0DING of 1 ,
Luma data is encoded as follows : for each line last value - 0x80 foreach luma,-value 1 in line diff - 1 - last value q_value - quan (diff] last value - clamp (last value dquant (q_value ] emit q_value end end
Luma data is αεcoded as follows:
Figure imgf000050_0001
last_valuε = 0x30 forεacn quantization-value q_value m line last vaiuε = clamp (iast_vaiue - dquant (q_vaiuε', ε t last valuε end end
Clamp is a clamping tanle; clamp [i] is: " 0 if i < 0;
255 if i > 255; i otherwise.
Che quantizεr used s:
Difference code rσuan:
255 to -91 0 -100
-90 to -71 1 -80
-70 to -51 2 -60
-50 to -31 3 -40
-30 to -16 4 -20
-15 to -8 5 -10
-7 to -3 6 — ά
-2 to 0 7 -1
1 to 2 8 I
3 to 7 9 4
8 to 15 10 10
16 to 30 11 20
31 to 50 12 40
51 to 70 13 60
71 to 90 14 80
91 to 255 15 100

Claims

1. In a computer system, a method of managing sessions comprising:
maintaining information for a session associated with a user; initiating at least one service in said session, said at least one service capable of execution while said user is disconnected from said system; notifying said at least one service when said user connects to a human interface device of said computer system and when said user disconnects from said human interface device; said at least one service directing its output to said human interface device while said user is connected to said human interface device.
2. The method of claim 1 wherein said information comprises an identification of said at least one service.
3. The method of claim 2 wherein said information identifies whether said at least one service is active and whether said at least one service is a required service of said session.
4. The method of claim 3 wherein said at least one service is initiated upon user connection to said system when said at least one service is a required service.
5. The method of claim 1 wherein said information comprises a user identification and authentication information.
6. The method of claim 1 further comprising:
said at least one service discontinuing the transmission of output to said human interface device when said user disconnects from said human interface device.
7. The method of claim 1 further comprising:
authenticating said user using said information.
8. A system comprising:
a service executable in a computer system; a network terminal capable of receiving output from and transmitting input to said service; a session manager configured to notify said service when a user is connected to said network terminal and when said user is disconnected from said network terminal; said service configured to send output to said network terminal when said user is connected to said network terminal, and when said user is disconnected from said network terminal, said service configured discontinue sending output to said network terminal during execution.
9. The system of claim 8 further comprising:
an authentication manager configured to validate said user of said network terminal;
10. The system of claim 9 wherein said authentication manager is configured to notify said session manager when a valid user is connected to said network terminal.
11. The system of claim 8 wherein said session manager is configured to send an inquiry to said network terminal to determine whether said user is connected to said network terminal.
12. The system of claim 8 further comprising:
a session associated with said user, said session comprising said service.
13. The system of claim 8 further comprising:
at least one session associated with said user each of which comprising a plurality of services.
14. A computer program product comprising:
a computer usable medium having computer readable program code embodied therein for session management and authentication comprising:
computer readable program code configured to cause a computer to maintain information for a session associated with a user; computer readable program code configured to cause a computer to initiate at least one service in said session, said at least one service capable of execution while said user is disconnected from said system; computer readable program code configured to cause a computer to notify said at least one service when said user connects to a human interface device of said computer system and when said user disconnects from said human interface device; computer readable program code configured to cause a computer to direct output of said service to said human interface device while said user is connected to said human interface device.
15. The computer program product of claim 14 wherein said information comprises an identification of said at least one service.
16. The computer program product of claim 15 wherein said information identifies whether said at least one service is active and whether said at least one service is a required service of said session.
17. The computer program product of claim 16 wherein said at least one service is initiated upon user connection to said system when said at least one service is a required service.
18. The computer program product of claim 14 wherein said information comprises a user identification and authentication information.
19. The computer program product of claim 14 further comprising:
computer readable program code configured to cause said at least one service to discontinue the transmission of output to said human interface device when said user disconnects from said human interface device.
20. The computer program product of claim 14 further comprising:
computer readable program code configured to cause a computer to authenticate said user using said information.
PCT/US1999/008665 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication WO1999054803A2 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
AT99918716T ATE298960T1 (en) 1998-04-20 1999-04-20 METHOD AND APPARATUS FOR SESSION MANAGEMENT AND USER AUTHENTICATION
DE69925996T DE69925996T2 (en) 1998-04-20 1999-04-20 METHOD AND DEVICE FOR SESSION MANAGEMENT AND USER AUTHENTICATION
JP2000545087A JP2002512394A (en) 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication
AU36565/99A AU748916B2 (en) 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication
CA002329034A CA2329034A1 (en) 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication
EP99918716A EP1074136B1 (en) 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication
HK01105485A HK1035457A1 (en) 1998-04-20 2001-08-07 Method and apparatus for session management and user authentication.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/063,339 US6223289B1 (en) 1998-04-20 1998-04-20 Method and apparatus for session management and user authentication
US09/063,339 1998-04-20

Publications (3)

Publication Number Publication Date
WO1999054803A2 WO1999054803A2 (en) 1999-10-28
WO1999054803A9 true WO1999054803A9 (en) 2000-04-13
WO1999054803A3 WO1999054803A3 (en) 2000-06-29

Family

ID=22048533

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/008665 WO1999054803A2 (en) 1998-04-20 1999-04-20 Method and apparatus for session management and user authentication

Country Status (11)

Country Link
US (1) US6223289B1 (en)
EP (1) EP1074136B1 (en)
JP (2) JP2002512394A (en)
KR (1) KR100597085B1 (en)
CN (1) CN1255977C (en)
AT (1) ATE298960T1 (en)
AU (1) AU748916B2 (en)
CA (1) CA2329034A1 (en)
DE (1) DE69925996T2 (en)
HK (1) HK1035457A1 (en)
WO (1) WO1999054803A2 (en)

Families Citing this family (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6484174B1 (en) * 1998-04-20 2002-11-19 Sun Microsystems, Inc. Method and apparatus for session management and user authentication
KR100382851B1 (en) * 1999-03-31 2003-05-09 인터내셔널 비지네스 머신즈 코포레이션 A method and apparatus for managing client computers in a distributed data processing system
US7116310B1 (en) * 1999-04-06 2006-10-03 Microsoft Corporation Application programming interface that maps input device controls to software actions
US6727884B1 (en) 1999-04-06 2004-04-27 Microsoft Corporation System and method for mapping input device controls to software actions
US6965368B1 (en) * 1999-04-06 2005-11-15 Microsoft Corporation Game control device having genre data
US6615264B1 (en) * 1999-04-09 2003-09-02 Sun Microsystems, Inc. Method and apparatus for remotely administered authentication and access control
US6895588B1 (en) * 1999-04-09 2005-05-17 Sun Microsystems, Inc. Remote device access over a network
US6901435B1 (en) * 1999-06-17 2005-05-31 Bmc Software, Inc. GUI interpretation technology for client/server environment
US7934251B2 (en) 1999-12-02 2011-04-26 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US9191443B2 (en) * 1999-12-02 2015-11-17 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US7917628B2 (en) * 1999-12-02 2011-03-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
WO2001040887A1 (en) * 1999-12-02 2001-06-07 Senvid, Inc. Method, system and service model for remote recording of television programs
US7120692B2 (en) 1999-12-02 2006-10-10 Senvid, Inc. Access and control system for network-enabled devices
US7587467B2 (en) * 1999-12-02 2009-09-08 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8793374B2 (en) * 1999-12-02 2014-07-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US8688797B2 (en) * 1999-12-02 2014-04-01 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US6745223B1 (en) * 2000-01-26 2004-06-01 Viaclix, Inc. User terminal for channel-based internet network
US8090856B1 (en) 2000-01-31 2012-01-03 Telecommunication Systems, Inc. Intelligent messaging network server interconnection
US7003571B1 (en) * 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
US20020009293A1 (en) * 2000-02-03 2002-01-24 Aldrich Kipp A. HDTV video server
US6658473B1 (en) * 2000-02-25 2003-12-02 Sun Microsystems, Inc. Method and apparatus for distributing load in a computer environment
AU6867401A (en) * 2000-06-22 2002-01-02 Microsoft Corp Distributed computing services platform
EP1176760A1 (en) * 2000-07-27 2002-01-30 Telefonaktiebolaget Lm Ericsson Method of establishing access from a terminal to a server
GB2369202B (en) * 2000-08-31 2003-03-19 Sun Microsystems Inc Computer system and method of operating a computer system
JP3776706B2 (en) * 2000-10-04 2006-05-17 富士通株式会社 Data communication apparatus, data communication method, and computer-readable recording medium recording data communication program
US7483983B1 (en) 2000-11-13 2009-01-27 Telecommunication Systems, Inc. Method and system for deploying content to wireless devices
US7206819B2 (en) 2001-01-18 2007-04-17 Sun Microsystems, Inc. Method and apparatus for providing virtual namespaces for active computing environments
US7237257B1 (en) * 2001-04-11 2007-06-26 Aol Llc Leveraging a persistent connection to access a secured service
US20020169967A1 (en) * 2001-05-14 2002-11-14 Sangeeta Varma Method and apparatus for multiple token access to thin client architecture session
US7650299B2 (en) * 2001-06-02 2010-01-19 Thermwood Corporation Method of marketing and advertising component products used in the production of composite products
US6954792B2 (en) * 2001-06-29 2005-10-11 Sun Microsystems, Inc. Pluggable authentication and access control for a messaging system
US7571257B2 (en) 2001-07-31 2009-08-04 Guthery Scott B Communications network with smart card
US7191233B2 (en) * 2001-09-17 2007-03-13 Telecommunication Systems, Inc. System for automated, mid-session, user-directed, device-to-device session transfer system
US7373515B2 (en) * 2001-10-09 2008-05-13 Wireless Key Identification Systems, Inc. Multi-factor authentication system
US20030084165A1 (en) * 2001-10-12 2003-05-01 Openwave Systems Inc. User-centric session management for client-server interaction using multiple applications and devices
US20030115154A1 (en) * 2001-12-18 2003-06-19 Anderson Anne H. System and method for facilitating operator authentication
US20030163691A1 (en) * 2002-02-28 2003-08-28 Johnson Ted Christian System and method for authenticating sessions and other transactions
US7363363B2 (en) * 2002-05-17 2008-04-22 Xds, Inc. System and method for provisioning universal stateless digital and computing services
US7356711B1 (en) 2002-05-30 2008-04-08 Microsoft Corporation Secure registration
US8117328B2 (en) * 2002-06-25 2012-02-14 Microsoft Corporation System and method for automatically recovering from failed network connections in streaming media scenarios
US7299033B2 (en) 2002-06-28 2007-11-20 Openwave Systems Inc. Domain-based management of distribution of digital content from multiple suppliers to multiple wireless services subscribers
US7356836B2 (en) * 2002-06-28 2008-04-08 Microsoft Corporation User controls for a computer
US7233790B2 (en) * 2002-06-28 2007-06-19 Openwave Systems, Inc. Device capability based discovery, packaging and provisioning of content for wireless mobile devices
US20040024867A1 (en) * 2002-06-28 2004-02-05 Openwave Systems Inc. Method and apparatus for determination of device capabilities on a network
US7075538B2 (en) * 2002-08-30 2006-07-11 Sun Microsystems, Inc. Methods and apparatus for faster line drawing on remote displays
US7269136B2 (en) * 2002-08-30 2007-09-11 Sun Microsystems, Inc. Methods and apparatus for avoidance of remote display packet buffer overflow
KR100602335B1 (en) * 2002-09-28 2006-07-14 주식회사 케이티 Method for Managing Session in Express Wireless Internet System
US7426535B2 (en) * 2002-10-08 2008-09-16 Telecommunication Systems, Inc. Coordination of data received from one or more sources over one or more channels into a single context
AU2002953335A0 (en) * 2002-12-11 2003-01-09 Click N Learn Pty Ltd Computer screen motion capture
CN1759558A (en) * 2003-03-10 2006-04-12 汤姆森特许公司 An identity mapping mechanism in wlan access control with public authentication servers
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US9100814B2 (en) * 2003-09-17 2015-08-04 Unwired Plant, Llc Federated download of digital content to wireless devices
US20080060052A1 (en) * 2003-09-25 2008-03-06 Jay-Yeob Hwang Method Of Safe Certification Service
WO2005050625A2 (en) * 2003-11-14 2005-06-02 Senvid, Inc. Managed peer-to-peer applications in a secure network
WO2005077066A2 (en) * 2004-02-09 2005-08-25 American Express Travel Related Services Company, Inc. System and method to reduce travel-related transaction fraud
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
JP2008505512A (en) * 2004-04-12 2008-02-21 エックスディエス・インコーポレイテッド System and method for automatically starting and dynamically establishing a secure internet connection between a server having a firewall and a client having a firewall
JP2006031175A (en) * 2004-07-13 2006-02-02 Sony Corp Information processing system, information processor and program
US7961883B2 (en) * 2004-11-24 2011-06-14 Research In Motion Limited System and method for securing a personalized indicium assigned to a mobile communications device
US8346910B2 (en) * 2004-11-30 2013-01-01 American Express Travel Related Services Company, Inc. Method and apparatus for managing an interactive network session
DE102005013639A1 (en) * 2005-03-24 2006-11-16 Dynetic Solutions Gmbh Method and system for outputting data
EP1752937A1 (en) * 2005-07-29 2007-02-14 Research In Motion Limited System and method for encrypted smart card PIN entry
US7818580B2 (en) * 2005-08-09 2010-10-19 International Business Machines Corporation Control of port based authentication protocols and process to support transfer of connection information
JP5249763B2 (en) * 2005-09-09 2013-07-31 スミスズ ディテクション インコーポレイティド Multicast delivery of multimedia content on demand
US7743138B2 (en) * 2005-09-22 2010-06-22 Dot Hill Systems Corporation Method and apparatus for external event notification management over in-band and out-of-band networks in storage system controllers
US7818436B2 (en) * 2005-09-22 2010-10-19 Dot Hill Systems Corporation Method and apparatus for external interface user session management in storage system controllers
US8392963B2 (en) * 2005-11-28 2013-03-05 Imperva, Inc. Techniques for tracking actual users in web application security systems
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8832440B2 (en) * 2006-01-24 2014-09-09 Clevx, Llc Data security system
US20070237145A1 (en) * 2006-03-30 2007-10-11 Avaya Technology Llc Comparison based authentication in RTP
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US20080314977A1 (en) * 2006-06-08 2008-12-25 American Express Travel Related Services Company, Inc. Method, System, and Computer Program Product for Customer-Level Data Verification
US9195985B2 (en) 2006-06-08 2015-11-24 Iii Holdings 1, Llc Method, system, and computer program product for customer-level data verification
US7765587B2 (en) 2006-08-14 2010-07-27 International Business Machines Corporation Glyphword-based security
KR100804831B1 (en) 2006-12-28 2008-02-20 삼성전자주식회사 Method of creating and managing session between wireless universal serial bus host and wireless universal serial device and wireless universal serial bus host and wireless universal serial device
WO2009024006A1 (en) * 2007-08-21 2009-02-26 China Mobile Communications Corporation Local session controller, ip multimedia subsystem and session registration method
US9747598B2 (en) 2007-10-02 2017-08-29 Iii Holdings 1, Llc Dynamic security code push
US8626926B2 (en) * 2008-02-26 2014-01-07 Qualcomm Incorporated Method and apparatus for performing session info query for user plane location
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
WO2012037565A1 (en) 2010-09-17 2012-03-22 Viaclix, Inc. Remote control functionality including information from motion sensors
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
US9633201B1 (en) 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US8650120B2 (en) 2012-03-02 2014-02-11 American Express Travel Related Services Company, Inc. Systems and methods for enhanced authorization fraud mitigation
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
EP2880619A1 (en) 2012-08-02 2015-06-10 The 41st Parameter, Inc. Systems and methods for accessing records via derivative locators
WO2014078569A1 (en) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systems and methods of global identification
US9002982B2 (en) 2013-03-11 2015-04-07 Amazon Technologies, Inc. Automated desktop placement
US9148350B1 (en) 2013-03-11 2015-09-29 Amazon Technologies, Inc. Automated data synchronization
US10142406B2 (en) 2013-03-11 2018-11-27 Amazon Technologies, Inc. Automated data center selection
US10313345B2 (en) 2013-03-11 2019-06-04 Amazon Technologies, Inc. Application marketplace for virtual desktops
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10686646B1 (en) 2013-06-26 2020-06-16 Amazon Technologies, Inc. Management of computing sessions
US10623243B2 (en) * 2013-06-26 2020-04-14 Amazon Technologies, Inc. Management of computing sessions
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
DE112014007170T5 (en) * 2014-11-14 2017-07-27 Mitsubishi Electric Corporation SERVER DEVICE, CLIENT DEVICE, SERVER DEVICE PROGRAM, MEETING ADMINISTRATIVE PROCEDURE, AND CLIENTS SERVICE SYSTEM
US9602468B2 (en) * 2014-11-19 2017-03-21 Facebook, Inc. Techniques to authenticate a client to a proxy through a domain name server intermediary
US10572661B2 (en) * 2016-08-16 2020-02-25 Nec Corporation Automated blackbox inference of external origin user behavior
TWI650731B (en) * 2017-07-03 2019-02-11 國立高雄科技大學 Adaptive self-repair and verification method for digital images, computer program products
US11429745B2 (en) 2017-10-30 2022-08-30 Visa International Service Association Data security hub
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11652813B2 (en) 2019-10-04 2023-05-16 Mastercard International Incorporated Systems and methods for real-time identity verification using a token code
US11449636B2 (en) 2019-10-04 2022-09-20 Mastercard International Incorporated Systems and methods for secure provisioning of data using secure tokens
CN112153103B (en) * 2020-08-10 2022-12-23 招联消费金融有限公司 Session management method, device, computer equipment and storage medium

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694603A (en) 1982-09-28 1997-12-02 Reiffin; Martin G. Computer memory product with preemptive multithreading software
US5027269A (en) * 1989-04-27 1991-06-25 International Business Machines Corporation Method and apparatus for providing continuous availability of applications in a computer network
JPH0658624B2 (en) 1990-03-30 1994-08-03 インターナショナル・ビシネス・マシーンズ・コーポレーション Graphical user interface management device
JPH0756628B2 (en) 1990-10-22 1995-06-14 富士ゼロックス株式会社 Graphical user interface editing device
US5430836A (en) 1991-03-01 1995-07-04 Ast Research, Inc. Application control module for common user access interface
US5577209A (en) * 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network
US5291585A (en) 1991-07-29 1994-03-01 Dell Usa, L.P. Computer system having system feature extension software containing a self-describing feature table for accessing I/O devices according to machine-independent format
US5566330A (en) 1991-08-20 1996-10-15 Powersoft Corporation Method for forming a reusable and modifiable database interface object
US5461710A (en) 1992-03-20 1995-10-24 International Business Machines Corporation Method for providing a readily distinguishable template and means of duplication thereof in a computer system graphical user interface
JPH0683603A (en) 1992-04-03 1994-03-25 Internatl Business Mach Corp <Ibm> Method and system for registering batch of object class
US5347627A (en) 1992-04-07 1994-09-13 International Business Machines Corporation Graphical user interface including dynamic sizing and spacing
US5526517A (en) 1992-05-15 1996-06-11 Lsi Logic Corporation Concurrently operating design tools in an electronic computer aided design system
US5423034A (en) 1992-06-10 1995-06-06 Cohen-Levy; Leon Network file management with user determined hierarchical file structures and means for intercepting application program open and save commands for inputting and displaying user inputted descriptions of the location and content of files
GB2270242A (en) 1992-08-29 1994-03-02 Ibm A method of editing for an object oriented computer system
US5412772A (en) 1992-10-13 1995-05-02 Novell, Inc. System for permitting a view of an object or a user interface to be exchanged between operating system environments
US5345550A (en) 1992-12-23 1994-09-06 International Business Machines Corporation User-modifiable popup menus for object oriented behavior
US5384911A (en) 1992-12-23 1995-01-24 International Business Machines Corporation Method of transferring programs from action oriented GUI paradigm to object oriented GUI paradigm
US5448695A (en) 1992-12-31 1995-09-05 International Business Machines Corporation Method and apparatus for dynamic visual feedback messaging in a graphical user interface of a data processing system
US5436637A (en) 1993-03-05 1995-07-25 Borland International, Inc. Graphical user interface system and methods for improved user feedback
JP2620576B2 (en) 1993-04-15 1997-06-18 インターナショナル・ビジネス・マシーンズ・コーポレイション Method and system for adjusting a graphical user interface according to a font requested by a user
US5559942A (en) 1993-05-10 1996-09-24 Apple Computer, Inc. Method and apparatus for providing a note for an application program
US5590199A (en) 1993-10-12 1996-12-31 The Mitre Corporation Electronic information network user authentication and authorization system
US5422674A (en) 1993-12-22 1995-06-06 Digital Equipment Corporation Remote display of an image by transmitting compressed video frames representing background and overlay portions thereof
US5548702A (en) 1993-12-23 1996-08-20 International Business Machines Corporation Scrolling a target window during a drag and drop operation
US5461399A (en) 1993-12-23 1995-10-24 International Business Machines Method and system for enabling visually impaired computer users to graphically select displayed objects
US5491784A (en) 1993-12-30 1996-02-13 International Business Machines Corporation Method and apparatus for facilitating integration of software objects between workspaces in a data processing system graphical user interface
US5546519A (en) 1994-02-28 1996-08-13 International Business Machines Corporation System and method for visually programming iteration
US5550968A (en) 1994-04-12 1996-08-27 International Business Machines Corporation Method and system for providing access security to controls in a graphical user interface
US5944794A (en) * 1994-09-30 1999-08-31 Kabushiki Kaisha Toshiba User identification data management scheme for networking computer systems using wide area network
US5473745A (en) 1994-12-14 1995-12-05 International Business Machines Corporation Exposing and hiding a title bar behind its window using a visual cue
US5570462A (en) 1995-05-05 1996-10-29 Apple Computer, Inc. System and method for object placement and sizing in a dynamic display environment
US5572643A (en) 1995-10-19 1996-11-05 Judson; David H. Web browser with dynamic display of information objects during linking
US5754830A (en) * 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US5832228A (en) * 1996-07-30 1998-11-03 Itt Industries, Inc. System and method for providing multi-level security in computer devices utilized with non-secure networks
US5935212A (en) * 1997-08-07 1999-08-10 I-Planet, Inc. Connection-oriented session emulation
US5964836A (en) * 1997-09-11 1999-10-12 International Business Machines Corporation Apparatus, methods and computer program products for managing web-page-embedded sessions with a host-based application

Also Published As

Publication number Publication date
KR20010042902A (en) 2001-05-25
KR100597085B1 (en) 2006-07-05
DE69925996T2 (en) 2006-05-04
JP2002512394A (en) 2002-04-23
US6223289B1 (en) 2001-04-24
CN1255977C (en) 2006-05-10
EP1074136A2 (en) 2001-02-07
ATE298960T1 (en) 2005-07-15
CA2329034A1 (en) 1999-10-28
WO1999054803A2 (en) 1999-10-28
JP2006073016A (en) 2006-03-16
AU3656599A (en) 1999-11-08
HK1035457A1 (en) 2001-11-23
AU748916B2 (en) 2002-06-13
JP4018711B2 (en) 2007-12-05
EP1074136B1 (en) 2005-06-29
DE69925996D1 (en) 2005-08-04
WO1999054803A3 (en) 2000-06-29
CN1306716A (en) 2001-08-01

Similar Documents

Publication Publication Date Title
US6223289B1 (en) Method and apparatus for session management and user authentication
EP1330705A2 (en) Method and apparatus for session management and user authentication
US6615264B1 (en) Method and apparatus for remotely administered authentication and access control
US7346689B1 (en) Computer architecture having a stateless human interface device and methods of use
US10750349B2 (en) Device linking
US7613927B2 (en) System for providing secure access to KVM switch and other server management systems
US7450596B2 (en) Scheme for realizing communications through external network from contents processing device connected to local network in home environment
US20020112181A1 (en) Multilevel secure network access system
US6295075B1 (en) Configurable terminal capable of communicating with various remote computers
US20060026100A1 (en) Dynamic downloading of keyboard keycode data to a networked client
AU2005220832A1 (en) Intelligent modular remote server management system
US7401114B1 (en) Method and apparatus for making a computational service highly available
AU2004295966A1 (en) Remote network management system
US7003797B2 (en) Secure personal identification number entry in a distributed network
EP1258127B1 (en) Method and apparatus for making a computational service highly available
KR20030075810A (en) Communication system and its method between Internet protocol network and Private Network
KR20040001347A (en) User information encrypted access method for public wireless LAN service

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99807543.4

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGE 12, DESCRIPTION, REPLACED BY A NEW PAGE 12; PAGES 10/11-11/11, DRAWINGS, REPLACED BY NEW PAGES 10/11-11/11; AFTER RECTIFICATION OF OBVIOUS ERRORS AS AUTHORIZED BY THE INTERNATIONAL SEARCHING AUTHORITY

AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 36565/99

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2329034

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2000 545087

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1020007011688

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 1999918716

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999918716

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1020007011688

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 36565/99

Country of ref document: AU

WWG Wipo information: grant in national office

Ref document number: 1999918716

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1020007011688

Country of ref document: KR