Patent Application
20080148349
When media content is sold or licensed over the internet, protection mechanisms can be used in order to prevent, or at least discourage, illegitimate use of the media content.
For example, media content can be formatted or encrypted so that only specific types of media players with built-in security features installed on a content user's device are able to play the content. For example, when asked to play a media file, a media player can contact a centralized licensing source that can determine whether a user has authorization to play the media file. The centralized licensing source can authorize each play of the media file, or can issue a limited authorization that allows the media player to play the media file a certain number of time or for a certain period of time, such as a specific number of days. Alternatively, an unlimited authorization can be granted that allows unlimited play of the media file without the need to check back with the centralized licensing source.
Whenever the media player contacts the centralized licensing source, it is desirable that the centralized licensing source be able to identify the media player with a user and determine which media files a particular user is licensed to play or otherwise use. Identification can require user action such as typing in an identity and a password. However, frequently requiring a user to type in information can be burdensome to the user.
Alternatively, identification of a user associated with a media player can be done passively, using identification information stored within the media player or elsewhere on the device. However, a centralized licensing source may not be able to obtain identification information from some types of media players. Identification information stored elsewhere on the device may be stored insecurely and available to be obtained and misused by non-licensees of media files.
It is desirable, therefore to create a secure way of authorizing users to play content in a media player, while maintaining a good user experience.
A rights manager 10 is, for example, a digital rights management licensing system accessible using the internet. Alternatively, rights manager can be any type of entity that can grant authorization to use content. In addition to communication by the internet, rights manager 10 could be accessible using another network or communications technology. For example, rights manager 10 includes a rights server 11 and a content user database 12. Rights server 11 and content user database 12 can, for example, reside in the same or on different computer systems. Within database 12 are various content user records. For example, a content user record 13 includes content rights 14 that indicate what rights a content user has to what content. In addition, content user record 13 includes a separate identification for each device of a content user that is authorized to use content. The separate identification for each device is a client identifier (ID) for each client of the content user that is authorized to use content. For example, in an area 15, content user record 13 stores a client ID A and a client IDB.
A full client 20 is, for example, a device owned by a content user of content. The device can be a desktop computer, a laptop computer, a personal digital assistant, a miniature digital player, a cell phone, or any other device that can include a media player. Full client 20 is called “full” because full client contains a downloading and rights management application 22 in addition to a media player 21. Within a storage area 23 controlled by full client 22 there is stored client ID A. For example, downloading and rights management application 22 stores client ID A in such a way that it is protected from illegitimate copy and use. Full client 20 can use client ID A as an identification to rights manager 10 to identify itself to rights manager 10.
The content user, as a user of full client 20, can obtain content in a number of ways. For example,
When the content user attempts to use the content using media player 21 within full client 20, media player 21 may detect that the content is protected. At this point media player 21 checks to see whether the content user has authorization to use the content on the full client.
For example, media player 21 may store such authorizations internally. If so, once media player 21 determines the content user has authorization to use the content on full client 22, media player 21 uses the content. The authorization may be in the form of a license or some other form of confirmation that the content user is authorized to use the content on full client 22. For example, authorization may be in the form of playback licensing as in Windows Media Digital Rights Management.
Alternatively, downloading and rights management application 22 may store such authorizations. If so, once downloading and rights management application 22 determines the content user has authorization to use the content on full client 22, downloading and rights management application 22 authorizes media player 21 to use the content.
If an authorization to use the content does not already reside in media player 21 or downloading and rights management application 22, downloading and rights management application 22 can contact rights server 11 to see if the content user has authorization to use the content on full client 22. This request is represented in
Upon receiving the request, rights server 11 can access content user database 12 to see what content rights are associated with client ID A. This interaction between rights server 11 and content user database 12 is represented in
The content user can transfer content from full client 20 to a light client 25. This is represented in
When the content user attempts to use the content using media player 26 within light client 25, media player 26 may detect that the content is protected. At this point media player 26 checks to see whether the content user has authorization to use the content on the light client.
For example, media player 26 may store such authorizations internally. If so, once media player 26 determines the content user has authorization to use the content on light client 22, media player 26 plays the content. For example, authorization may be in the form of playback licensing as in Windows Media Digital Rights Management. Alternatively, another application within light client can store authorizations.
If an authorization to use the content does not already reside in media player 26 or in some other application within light client 25, media player 26 or some other entity within light client 25 contacts rights server 11 to see if the content user has authorization to use the content on light client 22. If light client 25 has a client ID, the request to determine authorization can also include the client ID in order to identify light client 25.
For example,
For example, when the new client ID is stored in an internet cookie, the internet cookie can be created like any other cookie is created on the light client. All the usual cookie rules can apply. For example, the creator of the cookie may be required to be from the same domain as its eventual consumer. In this case, when receiving a cookie, a user of light client 25 (i.e., the content user) visits a webpage at some point that is in the same domain as the rights server. Light client 25 is, for example, redirected to this webpage from a secure page that knows the content user accesses the webpage. The webpage requests a username and password for the consumer. There the content user is allowed to give light client 25 a human readable name for reference. This will allow the content user to later disapprove a device for playback of particular content, since the number of devices on which particular content can be used is typically limited. Alternatively, the internet cookie can be created by software residing on the light client that knows how to manipulate the local cookie storage to create an internet cookie.
Upon receiving the request, rights server 11 can access content user database 12 to see what content rights are associated with client ID B. Rights server 11 can then communicate to media player 26 or another entity within light client 25 whether the content user has authorization to use the content on light client 22. This is represented in
In order to help provide protection, rights server 11 forwards a new client ID that is stored by light client 25. This is represented in
While rights server 11 can replace the client ID for each interaction with light client 25, it is not typically necessary to change client ID when there is an interaction with full client ID 20. This is because full client 20 is able to store client ID A in a secure location safe from outside access. However, light client 25 may store client ID B in an unsecured memory location, such as an internet cookie, where client ID B can be accessed by an unauthorized user of the content. Therefore, in one embodiment of the invention rights server 11 replaces client ID B after an interaction with light client 25, but does not replace client ID A after an interaction with full client 20. This allows client ID A to be a permanent, unchanging identification of full client 20.
In a block 41, the content user obtains content on a full client. In a block 42, the content user copies the content to a light client. In a block 43, the content user attempts to use the content, for example, using a media player. In a block 44, the media player attempts to acquire playback authorization. In a block 45, the right server looks for a client ID. In this scenario, there is no client ID on the light client. In a block 45, the content user is presented with a login screen that appears on a display of the light client.
In a block 47, shown in
If the rights server determines that the content user does not have access rights to the content, the light client can be instructed to inform the content user of the lack of rights and invite the content user to purchase the content. This is done, for example, by a screen such as a screen 62 shown in
If the rights server confirms the content user has access rights to the content, in a block 50, shown in
In a block 51, a new client ID and the device name are stored in a content user record for the content user within the content user database associated with the rights server. This allows the right server to identify the light client with the content user. In a block 52, the new client ID is stored on the light client. For example, the new client ID is stored in a cookie, or in some other location on the light client.
In a block 53, a limited authorization is issued to the light client to use the now authorized content. The authorization is limited, for example, by a number of plays of the content, or by a time period. For example, the content user can be informed of the limited authorization. This is done, for example, by a screen such as a screen 64 shown in
In a block 54, shown in
In a block 74, the rights server locates information on the content user and the light client using the client ID. In a block 75, the rights server verifies the content user has authorization to use the content.
In a block 76, the client ID stored in a content user record within the content user database associated with the rights server is changed to a new client ID. In a block 77, the client ID stored in the light client is changed to the new client ID. For example, the new client ID is stored in a cookie, or in some other location within the light client.
In a block 78, a limited authorization is issued to the light client to use the now authorized content. The authorization is limited, for example, by a number of plays of the content, or by a time period. In a block 79, the content user plays the content on the media player within the light client.
In a block 85, the playback authorization within the media player within the light client for the content expires. In a block 86, the content user next attempts to use the content, however, the authorization within the media player is expired. The media player within the light client sends the client ID within the light client to the rights server. However, the client ID is invalid. In a block 87, the light client presents the content user with a login and naming screen such as screen 61 shown in
In a block 90, the light client receives a new client ID. Now, the client ID stored on the light client of the content user is a valid client ID, while the client ID stored on the unauthorized user's device is invalid. In a block 91, the playback authorization within the media player within the unauthorized user's device for the content expires. In a block 92, when the unauthorized user's device next attempts to use the content, the authorization within the media player is expired. The unauthorized user is not able to use the content until the unauthorized user purchases or otherwise obtains authorization.
In a block 105, content A and content B are copied from the full client of content user B to a light client of content user A. In a block 106, content user A attempts to use content A on his light client. In a block 107, the light client receives from a rights server a client ID and authorization is issued that allows content user A to use content A on the light client of content user A.
In a block 108, content user A attempts to use content B on content user A's light client. In a block 109, the light client receives from a rights server an indication that content user A lacks authorization to use content B. In a block 110, content user A purchases authorization to content B. In a block 111, content user A again attempts to use content A on the light client of content user A. In a block 112, the light client sends a request for authorization to use content B. The request for authorization includes the current client ID residing on the light client of content user A. The rights server returns authorization to use content B along with a new client ID, which is stored on the light client of content user A. In a block 113, content user A plays content B on his light client.
The foregoing discussion discloses and describes merely exemplary methods and embodiments of the present invention. As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
