Field of the Invention

[0001] The present application relates to the field of media devices that access network services. More particularly, the described embodiments relate to media devices that automatically authenticate information with network services, and automatically invalidate such authentication information on the occurrence of certain triggering events.

Brief Description of the Drawings

[0002] Figure 1 is a schematic diagram of an embodiment of the present invention in communication with a network server.

[0003] Figure 2 is a flow chart showing the general process for the invalidation of authentication information.

[0004] Figure 3 is a flow chart detailing the step of verifying the ability to use stored authentication information.

Detailed Description

[0005] Figure 1 shows one embodiment of a physical media device 100 that communications with a remote media service server 160 over a network 10 such as the Internet 10. The media device 100 is able to access content or services on the media service server 160 for the benefit of users of the media device 100. For example, the remote media service 160 may provide audio and /or video media data for display or performance on the media device 100. If the media device 100 were a television, a network server 160 of the media service could provide streaming video or even feature movies for display on the television 100. If the media device 100 were an audio music player, the remote media service 160 could stream or download music to the device 100. In addition, the network server 160 could alternatively provide non- content services for the device 100. For instance, the server 160 might provide updates, maintenance patches, or other downloads for maintaining or improving the firmware and other programming found on the media device 100.

[0006] In order to communicate over the network 10, the media device 100 shown in Figure 1 includes two different network interfaces, namely a wired network interface 110 (such as a gigabit Ethernet port) and a wireless network interface 112 (such as a Wi-Fi or IEEE 802.11 interface). Note that while the media device 100 includes two network interfaces 110, 112, it is possible to implement an embodiment of the present invention using only a single network interface. In the preferred embodiment, the network interfaces 110, 112 provide a TCP/IP stack in order to access the Internet 10. In other embodiments, the interfaces 110, 112 are any communication interface that allows the media device 100 to communicate with the remote media service server 160 over a network 10. A processor 120 configures the device 100 to use one of the interfaces 110, 112 to access the network server 160 over the network 10. The processor 120 handles the high level functionality of the device 100, and may include one primary CPU or can contain a plurality of processing units specialized to handle particular functions within the device 100. For example, the device 100 could use the Cell processor developed by the STI consortium to handle various functions and image processing tasks within the device 100.

[0007] The media device 100 operates from power provided by component 130. In the preferred embodiment, component 130 is a power supply 130 that converts AC current to DC power, although it would be possible to implement numerous features of the present invention using only a battery power supply as power component 130. The power from component 130 operates the processor 120 and the network interfaces 110, 112. A clock 140 may also draw power from component 130, but in one embodiment the clock 140 is provided power from a separate battery supply (not shown) in order for the clock 140 to operate continuously even when the power supply 130 is unplugged from an AC power source. The clock 140 may be a secure clock, meaning that the clock 140 would not be modifiable except by a secure clock server. Secure clocks are helpful in a variety of digital rights management contexts, particularly when dealing with time limited licenses.

[0008] The processor 120 obtains programming 152 for the operation and user interface (UI) of the device 100 from tangible memory 150. Such memory 150 can be any type of standard, tangible memory, including RAM, ROM, PROMs, flash memory, or one or more hard drives, or some combination of these memories. The memory 150 should be persistent, so that the contents of memory 150 persist in the lack of power from power supply 130. In one embodiment, data is stored on a persistent device, such as flash memory or a hard drive, and then moved during operation to non-persistent yet faster memory, such as RAM.

[0009] Memory 150 also contains authentication information 154, which the media device 100 uses to authenticate the device 100 with the network server 160. Such authentication information 154 may include a username and password chosen by a user when the user subscribed to the service provided by the network server 160. A user can input authentication information 154 into the media device 100 using the user interface programming and an input mechanism (such as a remote control or keyboard) for the device 100. Rather than utilizing a user-defined username, the network server 160 may identify the device 100 using a unique device identifier. Device identifiers are useful in circumstances where access to the network server 160 is limited to a particular device 100 as opposed to a unique individual.

[0010] Authentication information 154 is stored in persistent memory 150 so that the user does not need to authenticate their identity with the network server 160 upon every access to the server 160.

Instead, the processor 120 uses programming 152 and one of the network interface 110, 112 to establish a connection with the network server 160, and then supplies to the server 160 the authentication information 154 pre-stored in memory 150. This information 154 allows the device 100 to automatically "log into" the server 160 and access its services without requiring user input.

[0011] In one embodiment, authentication information 154 for a plurality of services is stored together in a password-protected vault 155. A vault 155 allows a user to unlock all of their authentication information 154 with a single master password, even if the

authentication information for each service accessed by the user's device 100 has a separate password. These types of vaults 155 are also referred to as password or account managers. As long as the user knows the master password, the vault 155 can be authenticated and all of the authentication information 154 within the vault 155 can be used by the device 100.

[0012] As part of the ability to use the network 10, the device 100 must maintain network configuration information 156. If the network 10 is the Internet, this network configuration data 156 will include the device's IP address, the network's subnet mask, the network address of the router, and the network location for a DNS server. While this information can frequently be obtained on-demand from a router (not shown) that provides access to the network 10, this information 156 is nevertheless stored in memory 150 in order to properly configure and use the network interfaces 110, 112 and to determine whether the device 100 requires user reauthentication.

[0013] The network server 160 also contains a network interface 162, a processor 164, and tangible memory 170. The tangible memory 170 may be composed of the same types of memory as the memory 150 in device 100. In one embodiment, the tangible memory 170 contains programming 172 for the operation of the service, media or other content 174 that may be desired by the device 100, and an authentication database 176.

[0014] The network server 160 receives a request for the media or other content 174 from the media device 100 over the network 10 through network interface 162. The processor 164 receives this request and handles the request in accordance with programming 172. The programming 172 will instruct the processor 164 that it is necessary to authenticate all requests for services to ensure that the requester is authorized to receive the media 174. This authentication is

accomplished by comparing the service authentication information 154 provided by the device 100 against the authentication database 176. If the authentication information 154 matches the data for an authorized user or device in the database 176, the processor 164 is authorized to provide services to the device 100. In one embodiment, the network server 160 then provides the media 174 across the network 10 to the device 100. For example, the user of a network-connected television 100 may use the network server 160 to browse available feature movies 174. Upon selection of a movie 174, the server 160 provides the movie 174 to the television 100 for viewing by the user. The movie 174 may be provided via download, in which case the data containing the entire movie is downloaded by the device 100 through the Internet and stored in its entirety within memory 150. Alternatively, the movie content 174 may be streamed over the network 10, in which case the media device 100 may control the stream by issuing commands to the server 160 over the network 10.

[0015] The ability to store authentication information 154 in persistent memory 150 greatly simplifies the use of the device 100 by a user by eliminating the need for user authentication upon every access of server 160. Unfortunately, this ability is also the source of security vulnerabilities. User accounts on the network server 160 are frequently fee-based, meaning that users pay valuable consideration for the ability to access the services provided by server 160. In addition, server 160 will frequently allow an authenticated user to incur additional charges on their account as they access their accounts on server 160. For example, server 160 may provide unlimited streaming of some videos to a television 100 for a monthly fee, while further requiring users to pay an additional fee for each premium movie that is viewed. When a user's service authentication information 154 is stored on the media device 100, anyone having possession of the media device will be able to access the user's account. This makes the account vulnerable to those who acquire the media device fraudulently, such as through theft. In addition, the account would be vulnerable to use by users who obtained the device legitimately, such as upon resale of the media device in the used market or upon resale of the device by a retailer upon a return or exchange of the device 100.

[0016] To avoid inappropriate access to the service

authentication info 154 and consequently to the services provided by the server 160 on a user's account, the present invention will require reauthentication by the user upon the occurrence of a triggering event. Information that is used to determine whether a triggering event has occurred is stored in memory 150 as reauthentication status info 158.

[0017] The process 200 of requiring reauthentication is shown in the flow chart of Figure 2. The first step 210 is for the device 100 to receive a request to access the service provided by service server 160. Next, at step 300, the device 100 verifies whether the service

authentication information 154 may be used to access the server 160. Step 300 may be implemented in a variety of ways, which are described in more detail below in connection with Figure 3. In the preferred embodiment, the process 300 for verifying the ability to use the stored authentication information 154 is based upon historical information about past operations of the media device 100. This historical information is shown generally in Figure 1 as reauthentication status information 158.

[0018] If the test or tests evaluated at step 300 verify the ability to use information 154, the device 100 uses the service

authentication information 154 at step 230 to access the server 160. The details surrounding this access are used to update the reauthentication status information 158 at step 240. For instance, step 240 might store the following information in the reauthentication status information 158: the service server 160 that was accessed, the time of the access, the network interface used for the access, and the IP address of the device. After this information 158 is updated, the process 200 then ends.

[0019] If information 154 cannot be used to access the server 160, process 200 requires the user of the device 100 to reauthenticate themselves to the device. Assuming that a vault 155 is being used to secure authentication information 154, the user will be requested to enter the master password for the vault 155 at step 250. If step 260 determines that the master password entered by the user is the correct password for the vault 155, the user is considered reauthenticated. This means that the stored service authentication info 154 for the desired service will be utilized at step 230 to access the service server 160, and the reauthentication status information 158 will be updated at step 240.

[0020] If the user is unable to enter the correct password as determined by step 260, then the device 100 will allow the user to create a new authentication vault 155 at step 270. This new vault 155 will have a new master password selected by the user. When creating a new vault 155, the device 100 may erase the old vault 155. This would have the effect of removing all authentication information 154 stored within that vault 155. While this might inconvenience users who temporarily forget their password, such a system would ensure that that the

authentication information 154 input by one user would not remain on the device 100 after the device 100 has been transferred to a new user.

[0021] Alternatively, the device 100 may allows multiple vaults 155 to be stored in memory 150 at one time. This would allow multiple users of the device 100 to each have their own authentication information 154 stored on the device 100 simultaneously. Programming 152 would allow users to select their vault of authentication information when using the device 100. When switching between vaults, the device 100 preferably requires that the user enter the master password for that vault. While the embodiment that allows multiple vaults 155 of authentication information 154 to coexist in memory 150 would be useful in the context of multiple users accesses different service accounts, the security of the device 100 is lessened when the device does not automatically delete the existing vault when the user cannot enter the correct master password at step 250.

[0022] After the creation of a new vault 155, the user will enter new authentication information 154 for the service server 160 at step 290. This new information is stored in the vault 155 for later use by the device 100. At this point, the stored authentication information 154 is used to access the service server at step 230, and the reauthentication status information 158 is updated at step 240.

[0023] In some embodiments, the device 100 does not use a vault 155 having a master password to manage the authentication information 154 for multiple accounts. Instead, the authentication information 154 for each service is separately stored in memory 150. In this case, if step 220 determines that information 154 can no longer be used to access the server 160, the device 100 would require the user to enter (or reenter) their authentication information 154 for the service server 160. This newly entered authentication information 154 would then be stored in the memory 150 and be used to access the network server 160.

[0024] As shown in Figure 3, process 300 utilizes one or more tests 310-340 to determine the useability of the stored authorization information 154. In the first test 310, the reauthentication status info 158 contains the time of the last access made by the device 100 to the remote server 160. The time of last access (either to this particular service server 160 or to any service server 160) is compared by the processor 120 against the current time of clock 140. If this difference is greater than some predetermined period (such as seven days), the verification steps 210-220 fail and the user will need to reauthenticate at step 250.

[0025] In the second test 320, the reauthentication status info 158 contains not only the time of the last access made to server 160, but also that last time the device 100 went through a complete power cycle such as by power supply 130 being removed from an AC power source (i.e., the device was unplugged). This test 320 takes advantage of the fact that a change in possession of the device 100 will most frequently require that the device 100 be unplugged from a power source before being moved to a new location. The processor 120 is able to track power cycles by storing the time on clock 140 in memory 150 during every start-up of device 100. If the time of the last power up is after the time of the last service access time, this test 320 has failed and

reauthentication will be required. Alternatively, this test 320 can be implemented by having the processer 120 set a flag in the

reauthentication status info 158 upon every restart. If this flag is encountered at test 320, the test fails and reauthentication 250 is required. The processor 120 would then clear this flag as part of step 240 to ensure that the flag will not be set the next time process 200 operates unless another complete power cycle has occurred.

[0026] The third test 330 requires that the IP address or other network settings 156 of the device 100 not have changed since the last service server access time. In order to detect this condition, the processor 120 stores the IP address of the device 100 at step 240 during each access of the network server 160. In this way, differences between the last stored IP address and the current IP address are noted at the next access of a server 160. Alternatively, the processor 120 can set a flag in status info 158 every time the network configuration changes. If such a network configuration change flag is detected, test 326 can invalidate the service authentication info 154 and then reset the flag upon updating the authentication info 154 at step 240.

[0027] The fourth test 340 requires that the network interface 110, 112 used to access the network 10 not change between each access of the network server 160. For instance, if the wired network interface 110 were used the previous time a network server 160 was access, the service authentication information 154 would be validated only if the same wired network interface 110 were used to access server 160 the next time. If the wireless interface 112 were used, the fourth test 340 would invalidate the stored authentication info 154 and require the user to reauthenticate in step 260. Of course, it is possible to have multiple network interfaces 110, 112 of the same type, such as a plurality of wired network interfaces 110. The fourth test 340 could invalidate info 154 on any change of the network interface 110, even a change from one wired interface to another. As discussed for the previous tests, this test 340 could be implemented either by comparing the previous network interface 110, 112 (as indicated in status info 158) against the current interface 110, 112, or by setting a flag in status info 158 upon every change in the network interface 110, 112 used to access the network 10.

[0028] Line 350 on the flow chart of Figure 4 is labeled as optional, and indicates that two or more of these tests 310-340 can be run in series. For instance, one embodiment may require that no power cycles be noted in test 320, and that the network interface not have change as noted in test 340. This embodiment would not use test 310 and 330. As would be clear to one skilled in the art, any combination of one to four of the tests 310-340 could be implemented using standard programming techniques. The choice of tests 310-340 may be based on the preference of the manufacturer of the device 100, or upon the characteristics of the device 100. For example, test 310 may not be useful in a media device 100 that does not contain a trusted or secure clock 140. If the clock 140 could be altered by a user, test 310 could be circumvented by a knowledgeable user and access to the remote service 160 could be obtained under the account of the device's previous owner.

[0029] In another embodiment, the device 100 is capable of accessing a variety of remote network services, each requiring separate authentication information. These various services could be operated on a single server 160, or each could exist on separate servers found at separate network addresses on network 10. The method 160 may operate independently for each service, such that the device 100 maintains and analyzes the reauthentication status info 158 separately for each service. Alternatively, the method 160 could be operated so that all service authentication info 154 is treated as a whole, which can either pass or fail method 160 as a group. [0030] The many features and advantages of the invention are apparent from the above description. Numerous modifications and variations will readily occur to those skilled in the art. For example, Figure 1 shows the device 100 accessing a network service that is operating on a single network server 160. This configuration was presented for ease of explanation, as it is well known that such services typically operate on a plurality of physical computers operating in conjunction to provide a single network service. Since such

modifications are possible, the invention is not to be limited to the exact construction and operation illustrated and described. Rather, the present invention should be limited only by the following claims.