Recherche Images Maps Play YouTube Actualités Gmail Drive Plus »
Recherche avancée dans les brevets | Images de page | Historique Web | Connexion

Brevets

  
[merged small][graphic]
[graphic]
[graphic]
[graphic]
[graphic]
[graphic]

Login system @ 300 310 360 Client —> Content m <— system E 390 320 350 370 380 330

[graphic]

system ii <— system E
340

[graphic]
[graphic]

FIG. 3

[merged small][merged small][merged small][graphic][graphic][graphic][graphic][merged small][graphic][subsumed][graphic][graphic]
[graphic][merged small][merged small][graphic][graphic][graphic][graphic][graphic][graphic][graphic][graphic][graphic][graphic][merged small][graphic][graphic][merged small]
[merged small][graphic]
[graphic]
[graphic]
[graphic]
[graphic]
[graphic]
[graphic]
[graphic]

Login system @ 620 630 640 > Client <—E55() DD module M E5E5()—> system @ A A 4 670 600 610 680 695 685 Key system —> Permission @ <— $3/Stem E 690

[graphic]
[graphic]

FIG. 6

1 CONTROLLING DOWNLOAD AND PLAYBACK OF MEDIA CONTENT

BACKGROUND

The present invention relates to security for media content and, more specifically, to controlling download and playback of media content.

Many systems exist for transferring and playing media content. If the content is valuable, the content owner will restrict access to the content. For example, a user might be granted access in exchange for payment. Once the user has accessed the content, however, it is relatively easy for the user to copy the content and transfer it to someone else, who can then play it freely. A content owner wants to restrict playback to authorized users without preventing these users from accessing and playing the content.

SUMMARY

The present invention provides various embodiments of methods and systems for controlling download and playback of media content. The system includes a client and a server, which are connected by a network. The client can play content. The server includes a permission system that can determine whether a request from the client to download or play content should be granted. The client-server system is designed so that all purchase, download, and playback requests require permission from the permission system. This requires the client to be connected to the server (via the network) for all such operations. The advantage of this design is that all of the rules used for permission are maintained with the permission system and therefore can be readily updated and changed as needed (e.g., to improve security, install business logic particular to a content owner, or adapt to newlydiscovered fraud tactics). The permission system can thus be updated or revised, and the newly-installed operations and rules are thus applied to all transactions by all clients. Because the permission system is secure, its operations are less subject to attack by malicious parties.

The server also includes a DD module system that transfers a DD module to the client. The DD module includes a content key decryption module, a content decryption module, and a content decompression module. The content key decryption module decrypts an encrypted content key that was received from the server. The decryption uses a unique DD module key that has been hard-coded into the content key decryption module. The content decryption module uses the content key to decrypt encrypted content. The content decompression module decompresses compressed content so that it can be played.

Various levels of encryption, such as applied to the content key and to the content itself, operate to prevent malicious attacks on the client and the content. For example, the content key cannot be extracted without the DD module key. Because of the very large number of possible DD module keys (and the large number of different DD modules), an attack on an encrypted content key is also substantially prevented. Also, even if a particular instance of a DD module is compromised and the DD module key extracted, the DD module key can only be used with that particular DD module and its copies. Because of the very large number of different DD modules, the attacker would have no way of knowing with which other DD modules to use the ill-gotten DD module key, thereby rendering the DD module key essentially useless.

The description in the specification is not all inclusive and, in particular, many additional features will be apparent to one

20

25

30

35

40

45

50

55

60

65

2

of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a client-server architecture for transferring and playing media content, according to one embodiment of the invention.

FIG. 2 is a message diagram illustrating the messages sent between various components of the system shown in FIG. 1 in order to purchase content, according to one embodiment of the invention.

FIG. 3 is a message diagram illustrating the messages sent between various components of the system shown in FIG. 1 in order to initiate downloading content, according to one embodiment of the invention.

FIG. 4 is a message diagram illustrating the messages sent between various components of the system shown in FIG. 1 in order to resume downloading content, according to one embodiment of the invention.

FIG. 5 is a block diagram illustrating a decryption-decompression (DD) module, according to one embodiment of the invention.

FIG. 6 is a message diagram illustrating the messages sent between various components of the system shown in FIG. 1 in order to play content, according to one embodiment of the invention.

One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Described herein are systems and methods for controlling download and playback of media content. Media content, as used herein, refers to video, audio, or still images (or any combination thereof) in any format. A media content file can also include descriptive metadata, either encoded with the file or in a separate but associated file. A common example of media content is a video article including two portions4one video portion and one audio portion. However, the techniques described herein can be used with any number of file portions. 1. System Architecture

In one embodiment, media content is transferred and played in the context of a client-server architecture. FIG. 1 is a block diagram illustrating a client-server architecture for transferring and playing media content, according to one embodiment of the invention. In the illustrated embodiment, the architecture 100 includes a client 110, a server 120, and a network 130. Although only one client 110 is shown for clarity, the architecture 100 can support a large number of concurrent sessions with many clients 110.

The client 110 includes a first component for displaying a user interface that enables a user to specify a media content item (such as a video clip, audio clip, or still image) for transfer from the server 120 to the client 110 via the network 130. In one embodiment, the first component is a web browser software application 140. For example, the web browser 140 displays web pages and receives user input.

« PrécédentContinuer »