A Typical Log-in Scenario 
A typical log-in scenario involves a client 1 requesting access to the WebTV service by transmitting an embedded silicon id that uniquely identifies the WebTV box 10 to the log-in service 515. Therefore, the WebTV box 10 itself serves as one level of physical security. A user's account cannot be accessed without at least his/her WebTV box 10 or SmartCard 9. A SmartCard 9 log-in scenario is discussed below. 
In any event, upon receiving the silicon id, the log-in service 515 consults the customer database 540 to determine if access to the server 5 by this particular WebTV box 10 is authorized. Assuming access is authorized, the log-in service 515 determines the user(s) associated with the WebTV box 10 and transmits a log-in screen which is presented to the user by the WebTV box 10 via the display device 12. The log-in screen displays the usernames of the authorized users of the WebTV box 10. When the user selects one of the displayed usernames and enters an optional password associated with his/her account, a log-on request is transmitted to the log-in service 515. In response to the log-on request by the WebTV box 10, the log-in service 515 consults the customer database 540 to verify the user password. 
Ticket Generation 
Assuming the correct password has been entered by the user, the log-in service 515 proceeds to retrieve information pertaining to the particular user from the customer database 540. The log-in service 515 then generates a "ticket" 560, which is an information packet including the retrieved information. The ticket 560 is then provided to the WebTV box 10 that requested access. The ticket 560 includes information identifying the access privileges of a particular user with respect to services provided by the server 5. For example, the ticket 560 may include the username of the user operating the client 1, the real name of the user, the customer id associated with the user, and any filtering requested by the user with respect to viewing Web sites. As will be discussed further below, when the user makes a service request (e.g., a request to access to one of the services), the client 1 may submit a copy of the ticket 560 to that service. 
An Exemplary Customer Database Record 
FIG. 6A illustrates an exemplary customer database record according to one embodiment of the present invention. In this example, each record in the customer database 540 includes a silicon ID 605, a collection of subscriber information 610, a customer ID 615, a username 620, a password 625, a SmartCard ID 630, and a SmartCard password 635. As discussed above, the silicon ID 605 is an identifier such as a serial number that uniquely identifies a particular WebTV box 10. Because multiple users may share a WebTV box 10, in this embodiment, there is a one-to-many relationship between the silicon ID 605 and the fields associated with a particular user. The subscriber information 610 may include such information as administrative and billing data for a particular user including the user's real name, a credit card number, the user's address and phone number, etc. The customer ID 615 is an identifier such as a serial number that uniquely identifies a particular user of the WebTV service. The username 626 is a name the user has chosen to associate with his/her account. The username 626 may serve as the user's e-mail identifier within a particular domain. For example, a user having the username "merlin" might have an e-mail address of merlin@ webtv.net. The password 625 is optional, if a user chooses to assign a password to his/her account, then the WebTV service will require its entry upon log-in and perform appropriate validation before generating the ticket 560. The SmartCard ID 630 is also optional. Preferably, a separate SmartCard password 635 is associated with the SmartCard ID 630. However, the password 625 may be used for both the user password and the SmartCard password 635. 
In any event, if a user has associated a SmartCard 9 with his/her account, then identification information stored on the SmartCard 9 such as an identification number for uniquely identifying the SmartCard 9 may be stored in a field in the customer record associated with that user such as the SmartCard ID 630. In this manner, a translation may be performed from a particular SmartCard ID 630 to a customer ID 615, thereby allowing the WebTV service to identify a particular user at log-in and produce a ticket 560 without reference to the silicon ID 605 of the user's WebTV box 10. Therefore, as will be discussed further below, one advantage of associating a SmartCard 9 with a given user customer record in the customer database 540, is that the user can log-in to the WebTV service from any available client 1 such as one that might be provided by a hotel in each of its rooms for the benefit of its patrons. Thus, the user is not limited to logging in to the WebTV service from his/her WebTV box 10. Additionally, as will be explained further below, the user will automatically have access to his/her preferences such as those stored in the setup database 530 and his/her environment such as favorites and e-mail upon establishing a user session with a SmartCard 9. 
An Exemplary Favorites Database Record 
FIG. 6B illustrates an exemplary favorites database record according to one embodiment of the present invention. In this example, each record in the favorites database 545 includes the customer ID 615, a list of favorite uniform resource locators (URLs) 645, a list of favorite titles 650 each title corresponding to a URL in a list of favorite URLs 645, and a list of favorite thumbnails 655 each thumbnail corresponding to a particular URL in the list of favorite URLs 645. The list of favorite URLs 645 is a list including one or more URLs the user has designated as a "favorite." When the user designates a Web page as a favorite site, the URL of the Web page is stored in the list of favorite URLs 645 associated with the customer id 615 of the user. In this embodiment, a title of the Web page is also stored in the list of favorite titles 650. Further, a thumbnail image of the Web page may be stored in the list of favorite thumbnails 655. In this manner, when the user requests his/her favorite URLs, they may be graphically depicted with thumbnail images and titles. To jump to a favorite Web page, the user may select a thumbnail image corresponding to the Web page he/she desires. The server 5 may then request the URL associated with the thumbnail image selected. 
Smartcard Log-in 
In the log-in scenario discussed above, a silicon id associated with the user's WebTV box 10 was used to access the customer database 540 to generate the ticket 560. However, insertion of the SmartCard 9 inhibits the normal log-in processing sequence that involves the WebTV box 10 transmitting its silicon id to the log-in service 515, thereby allowing a user session to be initiated by someone other than the users associated with the particular the WebTV box 10. Rather, when a user logs into the WebTV service using a SmartCard 9, identification information stored on the SmartCard 9 is used to initially access the customer database 540 rather than the silicon id of the particular WebTV box 10 employed. The log-in service 515 may search the customer database for a SmartCard ID 630 matching the identification information provided during log-in. Upon finding the appropriate customer record, the log-in service 515 can retrieve the customer ID 615 corresponding to the identification information. Once the log-in service 515 has determined the customer ID 615 associated with the SmartCard 9, ticket generation may proceed as discussed above. 
FIG. 7 is a flow diagram illustrating the establishment of an online user session according to one embodiment of the present invention. At step 705, the WebTV box 10 detects the presence of a SmartCard 9 that has been inserted into the SmartCard slot 8. For example, SmartCard interface 31 may detect the presence of the SmartCard 9 and generate an input event. 
At step 710, input processing is performed. In this embodiment, the WebTV box 10 may be in one of two high level states: powered down or powered up. When the WebTV box 10 is powered up, it may be sleeping or awake. In the powered up state, the WebTV box 10 may additionally be either disconnected or connected. In the powered down state, power may be limited to the particular circuitry of the WebTV box 10 necessary to detect input events such as those indicating the power button has been depressed or indicating the insertion of a SmartCard 9. In the sleeping state, a screen-saver may be active to prevent damage to the display device 12. In the disconnected state, the WebTV box is not in communication with the WebTV Service. In the connected state, the WebTV box 10 is in communication with the WebTV Service and may additionally have a ticket 560 stored in RAM 23. The input processing may include transitioning from the current state to a new state. For example, if the WebTV box 10 is in the powered down state when the SmartCard 9 is detected the WebTV box 10 may transition to the powered up state. Moreover, when the SmartCard 9 is detected, the sleeping state may give way to the awake state (e.g., the screen-saver may be deactivated). 
At step 715, the identification information is read from the SmartCard 9. Subsequently, at step 720, the identification information is transmitted to a server 5 such as a server providing the log-in service 515. 
At step 725, the log-in service 515, with reference to the customer database 540, determines if the identification information is associated with an authorized user of the WebTV Service. If the identification information is not found, processing continues with step 730. Otherwise, if the identification information is found, processing continues with step 735.