WO2006000029A1

WO2006000029A1 - Content delivery system and player

Info

Publication number: WO2006000029A1
Application number: PCT/AU2005/000911
Authority: WO
Inventors: Stephen Spicer; Timothy Charles Hoad
Original assignee: Telstra Corporation Limited
Priority date: 2004-06-23
Filing date: 2005-06-23
Publication date: 2006-01-05

Abstract

A content delivery system, including a communications interface for connection to a communication network, a delivery control module for processing requests for content items from at least one client device (130) connected to the network (140), an obfuscation module (182), and a packaging module (186) for package a content item and player code for transmission. The obfuscation module (182) includes a seed generator (212) for generating a unique seed, a media adjuster (214) for adjusting a requested content item on the basis of the seed, and a content player compiler (216) for compiling source code of a content player on the basis of the seed to generate the player code for the content item.

Description

CONTENT DELIVERY SYSTEM AND PLAYER

FIELD

The present invention relates to a content player and a content delivery system.

BACKGROUND

Content players for playing digital media, such as Windows Media Player and Apple's QuickTime Player, are designed to allow users to play digital media files of various compression formats. Digital Rights Management (DRJVI) systems have been developed in an attempt to control the use and redistribution of digital media content for the players. For example, rights expression languages, such as XrML, have been developed to allow publishers and content owners to define how a content item might be used and subsequently played on a player. For instance, the delivered content may be able to be played in an unlimited manner for a certain period of time only, and copying of the content may be prohibited. These restrictions need to be supported by the player, and a number of players include DRM components to provide the support and enforce the restrictions.

A problem inherent in the existing content delivery systems and players is that the players can be hacked or reverse engineered to remove the DRM restrictions, or a player without DRM support can be used or developed to play all content files in the standard digital media delivery formats, such as MP3, AAC and MPEG-2. This problem has assisted the wide proliferation of unauthorised and pirated content distributed on the various peer to peer networks of the Internet.

Accordingly, it is desired to address the' above or at least provide a useful alternative. SUMMARY

In accordance with the present invention there is provided a content delivery process, including: generating a unique seed; accessing and adjusting a content item on the basis of the seed; compiling content player code on the basis of the seed; and transmitting the content item and the player code in response to a request for the content item.

The present invention also provides a content delivery system, including: a communications interface for connection to a communication network; a delivery control module for processing requests for content items from at least one client device connected to said network; an obfuscation module including a seed generator for generating a unique seed, a media adjuster for adjusting a requested content item on the basis of said seed, and a content player compiler for compiling source code of a content player on the basis of said seed to generate player code for the content item; and a packaging module for packaging said content item and said player code for transmission.

The present invention also provides a content player, including: a shell for generating a user interface, accessing unique hardware profile data from a client device and transmitting said hardware profile data to a content delivery system; and a media player including a decoder for generating a key to decrypt a content item bound to said media player, using said hardware profile data.

The present invention also provides a content player uniquely bound to a content item.

The present invention also provides a content player compiled using a unique seed so as to read only content delivered using said unique seed.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a content delivery system communicating with a client device; Figure 2 is a block diagram of delivery components of the system; Figure 3 is a block diagram of components of a preferred embodiment of a content player; Figure 4 is a flow diagram of steps performed by the content delivery system; and Figure 5 is a flow diagram of steps performed by the content player.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

A content delivery system 100, as shown in Figure 1, includes a content server 110, with a database server 120, that communicates with a client device 130 using a communications network 140. The server 110 has a communications interface 150 for connection to the network 140, a delivery control module 160, a content preparation module 182, an obfuscation module 102, an encryption module 184 and a packaging module 186. The modules 180 to 186 operate to prepare for delivery a player 190 and a content item 192 bound to the player for the client device 130. The content items include digital media stored in source files held by the database 120, or another database accessible over the network 140 by the server 110. The files represent media or multimedia content, eg text, graphics, audio and/or video.

The communications network 140 is a public communications network, such as the Internet, and the client device 130 is hereinafter described as a personal computer (http://www.ibm.com) running an operating system (OS) 194, such as Linux or Windows XP, that allows the establishment of TCP/IP connections over the network 140, and runs a browser 196, such as Internet Explorer or Safari. The server 110 is also described as having a communications interface 150 that includes a web server 150, such as Apache (http://www.apache.org), allowing the server 110 to communicate using TCP/IP based protocols such as HTTP. It will of course be appreciated by those skilled in the art that the server 110 could be a different form of client server, such as a WAP server, and the client device 130 could be a different form of computer device, such as a mobile phone or PDA. The components 160 to 186 can provided by software, in languages such as Java (httφ://www.java.sun.com), Perl (http://www.perl.org), C++ and HTML, and the database server 120 can be provided using software, such as MySQL4 (http://www.mysql.org), which all run on an operating system, such as the Linux OS (http://www.linux.org), on a standard computer 112, such as a PC server (http://www.ibm.com). As will also be understood by those skilled in the art, the software and hardware components of the server 110 can also be placed on a number of distributed computers connected by the communications network 140, and the processes executed by the components 160 to 186 can also be executed at least in part by dedicated hardware circuits, eg ASICs or FPGAs, which may be required to improve the speed of the processes.

The content delivery server 110 performs a content delivery process, as shown generally in Figure 4. The control module 160 includes web pages that can be accessed by the client device 130, and which allow the client 130 to select and submit a request for a particular item of content offered on the pages (step 402). The content may also be offered on other web sites, not hosted by the server 110, and the server 110 can handle HTTP requests for the download of specific content items. For example, the user of the client 130 is able to access the pages of a content distribution web site and select from a number of content titles, the particular content file that is desired. A particular movie may be located, and the user is then able to select download of the file selecting a 'buy' download link on the site and sending the corresponding HTTP request to the server 110. Operation then proceeds to step 404 where an applet of the control module 160 is served by the server 110 to run on the client 130 and determine if a shell 302 of the player 190 has been installed on the client 130. The shell 302, as shown in Figure 3, includes a plugin for the browser 196, a user interface, code for supporting different skins of the interface, code for content management (eg playlists and libraries), and code to collect hardware profile data from the client device 130. The content libraries include code to handle playlists and content management. If the shell 302 is not detected (404), then operation proceeds to step 406, at which the user is presented with a HTML message rendered by the browser 196 advising that the shell must be downloaded in order to access the content. The shell is a small program, about 300k to 800k, that needs to be downloaded and stored on the client device before operation proceeds to step 408. Once the shell has been properly installed, the user must again select the download link so that the shell can be detected at step 404.

At step 408, purchase pages are presented to the user if it is necessary to purchase the content item. The pages allow the entry of credit card details and notification of payment. Once payment has been approved and download of the content item approved, the control module 160 generates a unique user identification data (UID) to identify the user. The UID is stored with information identifying the content item, derived from the download link, in the database 120.

Approval of download of the content also causes the control module 160 to instruct the shell 302 to commence execution (step 502). The shell 302 is transparently informed of the universal resource locator (URL) specifying the content and its location for use by the server 110. The shell 302 of the player 190, as shown in Figure 5, stores the URL and the UID, which is sent to the client device 130 when generated by the content server 110 (502). The shell 302 accesses the URL to request the content and accesses unique hardware profile data of the client device 130 that specifically identifies the device 130. The unique profile data can be selected from one or a combination of microprocessor characteristics, amount of memory, hard disk model, serial number, network card MAC address, OS version, video and sound card type and/or other hardware identification data of the device 130. The profile data may also include data which identifies the user, such as username and email address. The unique hardware profile data is extracted and forwarded to the server 110 (504), for storage in the database 120 against the user's UID, with URL requesting the content (409). The shell 302 then waits for the content to be downloaded (506). On receiving the request (409) and determining that the content has been paid for, again based on the UID, the control module 160 causes access of the respective media file for the content (step 410). The media file for the content item is in a format that needs to prepared and obfuscated for delivery. Alternatively, the media file can be stored in an obfuscated format with a unique customised player ready for delivery.

The preparation module 180, as shown in Figure 2, has a source access module 202 to access source files of uncompressed media from the database 120 or other databases, and compress the selected file or files using a media encoder, such as an MPEG-2, or an MPEG-4 encoder. The accessed media source file may be any unencrypted digital content, such as capture from a digital video camera, scanned prints or documents, and/or an audio recording. The preparation module 180 also has a player source module to access media player source code for the player 190. The media player source code is selected from a library of interchangeable modules to produce an entity that is able to render the selected content. The preparation module also has a rights definition access module 208 to access rights definition data for the selected content item. This rights definition data specifies how the content can be played, such as once only or an unlimited number of times in one week. It is also able to limit the content to a particular client device 130 or may require payment each time the content is accessed by the player 190. The rights definition data is expressed in a rights expression language, such as XrML or ODRL. The rights expression language is combined with DRM source code accessed by a DRM source access module 210 to produce combined DRM source code for the player 190, which is incorporated in the media player code 304.

The compressed media file, the media player source code and the DRM source code are accessed by the obfuscation module 182 which includes a seed generator 212, a media shuffler 214 and the player compiler 216. The seed generator 212 generates seed data, such as that representing a pseudo-random number, so as to provide a seed for use by the media shuffler 214 and a player compiler 216. The player compiler 216 produces a compiled version of the player source code and DRM source code using the seed so as to produce a unique customised media player 304. The media shuffler 214 uses the seed to adjust the compressed media data so as to produce a unique obfuscated media file that can only be played by the unique player 190. The media shuffler 214 rearranges the compressed media file or alters it so that the compressed data remains intact, but the structure or meaning of the data is hidden from standard players. This is achieved by stream structure manipulation, such as altering the field sizes, rearranging fields or modifying start codes. For example, the start code used for a video frame could be made variable, and dependent on, for example, the content of the previous frame. The media can also be shuffled or adjusted by using VLC table substitution and coefficient shuffling. The seed generator 212 may simply generate a pseudo-random number, or can be tied to the form of the content or the particular content file itself that is to be shuffled. For example, the content file may provide a seed to generate the next seed for the media shuffler 214 and the player compiler 216. The compiler 216 is a standard C++ or C# compiler that uses pre¬ processing instructions controlled by the seed to generate the unique player. The player 190 is unique in that the media player code 304 is adjusted so it is able to read, decode and render the obfuscated content 192. Alternatively the compiler 216 can dynamically generate the unique source code, with reference to the seed, using the code provided by the player source code access module 206 as a base, and then pass this dynamic generated code to a standard compiler.

The adjustment process employed by the media shuffler 214 is controlled based on the seed and the code 304 of the player 190 is adjusted by the compiler 216 also based on the same seed, so it is able to decompress and render the obfuscated media file 192, thereby binding the two. Binding the player 190 to one media file 192 in this manner is significant because if the DRM code of the player is cracked and rendered redundant, the player is only useful for playing one media file and cannot be used for generally playing other compressed media files delivered by the system 110. The encryption process implemented by the encryption module 184, as described below, also prevents the unique player 190 and the bound media file 192 being moved between client devices 130 without approval.

The encryption module 184 receives the obfuscated media file and the unique media player, and includes an encryption engine 218 for performing (420) a number of standard encryption algorithms that use relatively strong encryption, eg 128 bit encryption. The encryption module 104 also includes an encryption key generator 220 for generating a number of keys that are used by the algorithms executed by the encryption engine 218. In generating the keys (420), the encryption key generator 220 first generates a random encryption key K which is used to encrypt the obfuscated media file. The key generator 220 then uses the unique hardware profile data stored against the user's UID to generate a first unique hardware identifier (HID), and a second unique hardware identifier (HID₂) using similar but different generation processes. The encryption key generator also receives a hash (PH) of the media player code 304 produced by the player compiler 216. The hash value (PH), together with the encryption key K, the HID and the UID, are used by the key generator 220 to produce a device decryption key (DK). The key DK is produced by applying an XOR to the combined K, PH, HID and UID. The code 304 of the customised media player is encrypted using the HID₂. The two encrypted components 192 and 304 and the device key DK are passed to the packaging module 186. The manner in which the device key is generated makes DK unique to a particular user, and more importantly to a particular device, such that the content can only be played with a specific client device 130, as described below. Also generating DK using the PH means the content can only be decrypted if the PH can be generated from the player code. Accordingly hacking of the player code will prevent decryption of the content.

The packaging module 186 receives the encrypted components, being the media player code and the media file, and uses a packager module 230 to wrap them in a self decrypting executable archive that is sent by the control module 160 to the client device 130 (440). The packager 230 includes in the archive the player code 304 that operates with the shell 302, unpacker code 306 for unpacking the self extracting archive, the device key DK, and the encrypted and obfuscated content 192. The player code 304, as shown in Figure 3, includes a decoder (or codec), to operate with the shell 302, code to calculate the player hash, code to generate the HID, and code to reconstitute the decryption key K using the DK, the generated PH, the generated HID and the UID stored by the shell 302. The unpacker 306 in addition to including the code for unpacking the archive, includes code for generating the HID₂ and using this code to decrypt the player code 304 using the HID₂. The archive file is similar to a ZIP or TAR file, but a different extension is used, eg ".dmp". The media player code 304 and the content 192, together with the unpacker 306, are delivered each time content is delivered, whereas the shell 302 is only delivered once for first time users on a particular device 130.

Once the shell 302 has completed download of the self extracting file with the encrypted content, media player and device key DK (506) a request can be made using the shell 302 to play the content (508). On receiving a request to play the content, the shell 302 determines whether the media player code 304 of the player 190 and the content 192 needs to be unpacked and decrypted (520). If unpacking and decryption is required, the shell 302 launches the unpacker 306 (510). The unpacker 306 accesses the hardware profile data from the client device 130 and generates the HID₂. This is used by the unpacker to decrypt the encrypted media player code 304. If the correct HID₂ is determined, then the player code 304 will be correctly decrypted and is executed so as to generate a player hash PH and generate a HID, again based on the profile data accessed from the client device 130. The media player code 304 accesses the device key and UID, and uses the generated PH and HID to generate a decryption key K. The generated key K is used to decrypt the content file 192 and if successful (512) the content is played for the user on the device 130 (530).

If any of the decryption steps are unsuccessful (512), ie the media player code 304 is not able to run, or the content 192 cannot be properly played or decrypted, the shell 302 generates a notification message (514) for the user accordingly. For example, the user may have copied the media file or the packaged file to another client device, in which case either the downloaded shell 302 looks for absent media player code 304, the incorrect HID₂ is generated or the incorrect decryption key K is generated using the DK for the initial client device. The user is advised (514) that he does not have permission to access the content from the new device and is prompted to obtain permission from the server 110. This involves the shell 302 again requesting the content (504) and sending the hardware profile data for the new device. The server 110 then proceeds through steps 402 to 440 to provide the player code and content for the new device, and this may or may not require an additional purchase. Alternatively, the control module 160 may determine on the basis of the UID provided by the shell 302 that the requested content has already been purchased for another device, and simply causes generation and transmission of another device key DK for the new device (506), on receiving the hardware profile data (504). Based on the hardware profile data a HID₂ is generated for the new device and a new player encrypted by the HID₂ is also downloaded (506).

The primary target for share and trade of content, without authorisation, is compressed media files. Clear uncompressed files are normally too large in size for sharing and download. Clear uncompressed files also normally require re-encoding for play and rendering by media players. Clear analog data is also less attractive because it needs to be recorded in a digital form and encoded for sharing. The compressed media file 192 that the client device 130 receives is encrypted using a key that can only be obtained using data unique to the device 130 itself, and even if decrypted, is still shuffled or adjusted so that it can only be played by a player 190 that is unique and specific to that content. There is no incentive to hack the player to remove DRM restrictions, as it can only be used for uncompressing and rendering one media file. Not only is it difficult to decrypt the content, it is also difficult the readjust and shuffle it so that it can be played by another player. In addition to being difficult to hack, the content item 192 is bound to a player 190 and a device 130.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings. For example, the content may be further bound to the player 190 by compressing the content using a codec specific and unique to the customised player 190 and even shuffling the content file 192 amongst the code 304 for the player 304.

Claims

1. A content delivery process, including: generating a unique seed; accessing and adjusting a content item on the basis of the seed; compiling content player code on the basis of the seed; and transmitting the content item and the player code in response to a request for the content item.

2. A content delivery process as claimed in claim 1, including encrypting the content item and the player code for said transmitting.

3. A content delivery process as claimed in claim 2, including obtaining unique hardware profile data from a client device sending said request, and said encrypting uses at least one encryption key derived from said hardware profile data.

4. A content delivery process as claimed in claim 3, including generating a device key derived from said hardware profile data and an encryption key, and said transmitting including transmitting said device key for use in decrypting the player code or said content item.

5. A content delivery process as claimed in claim 4, wherein said device key is generated using a hash of said player code, said encryption key and identifying data derived from said hardware profile.

6. A content delivery process as claimed in claim 1, wherein said transmitting includes packaging said content item and said player code into a self extracting archive for transmission.

7. A content delivery process as claimed in claim 1, wherein said adjusting includes shuffling said data of said content item on the basis of the seed, and said compiling includes generating control data based on the seed, said control data controlling reading of said content item.

8. A content delivery process as claimed in claim 1, wherein the content item is a compressed digital media file, such as an MP3 or AAC audio file or an MPEG video file.

9. A content delivery process as claimed in claim 8, wherein the content of said compressed file is of any media form, such as text, graphics, audio and/or video.

10. A content delivery system for performing a content delivery process as claimed in any one of the preceding claims.

11. A content delivery system, including: a communications interface for connection to a communication network; a delivery control module for processing requests for content items from at least one client device connected to said network; an obfuscation module including a seed generator for generating a unique seed, a media adjuster for adjusting a requested content item on the basis of said seed, and a content player compiler for compiling source code of a content player on the basis of said seed to generate player code for the content item; and a packaging module for packaging said content item and said player code for transmission.

12. A content delivery system as claimed in claim 11, including an encryption module for encrypting said content item and said player code.

13. A content delivery system as claimed in claim 12, wherein said encryption module includes a key generator for generating at least one encryption key, for said encrypting, on the basis of unique hardware profile data obtained by said delivery control module from said client device requesting said content item.

14. A content delivery system as claimed in claim 13, wherein said key generator generates a device key derived from said hardware profile data and an encryption key, and said packaging module includes said device key for use in decrypting the player code or said content item.

15. A content delivery system as claimed in claim 14, wherein said device key is generated using a hash of said player code, said encryption key and identifying data derived from said hardware profile.

16. A content delivery system as claimed in claim 13, wherein said delivery control module sends to said client device a shell for generating a user interface, accessing said unique hardware profile data from said client device and transmitting said hardware profile data to said content delivery system.

17. A content delivery system as claimed in claim 14, wherein said packaging modules packages said content item, said player code and said device key into a self extracting archive for transmission.

18. A content delivery system as claimed in claim 11, wherein said compiler compiles rights management code for said content item with said player code.

19. A content delivery system as claimed in claim 11, including a preparation module for compressing content of said content item, and source code modules for providing said source code of said player and rights management code for said content item.

20. A content delivery system as claimed in claim 11, wherein the content item is a compressed digital media file, such as an MP3 or AAC audio file or an MPEG video file.

21. A content delivery system as claimed in claim 20, wherein the content of said compressed file is of any media form, such as text, graphics, audio and/or video.

22. A content player, including: a shell for generating a user interface, accessing unique hardware profile data from a client device and transmitting said hardware profile data to a content delivery system; and a media player including a decoder for generating a key to decrypt a content item bound to said media player, using said hardware profile data.

23. A content player as claimed in claim 22, wherein said decoder uses a hash of code for said media player.

24. A content player as claimed in claim 22, including an unpacker for unpacking an archive including the content item encrypted, the media player encrypted using said hardware profile data, and a device key for use in generating said key.

25. A content player as claimed in claim 22, wherein a unique seed is used to produce the player, and said content item is obfuscated based on the unique seed.

26. A content player uniquely bound to a content item.

27. A content player as claimed in claim 26, wherein a unique seed is used to produce the player, and said content item is obfuscated based on the unique seed.

28. A content player as claimed in claim 26, wherein the player and the content item are bound to a client device.

29. A content player as claimed in claim 28, wherein the player and the content item are bound to the client device on the basis of unique hardware profile data obtained from the client device.

30. A content player as claimed in claim 29, wherein code of the player and the content item are encrypted for transmission to the client device, and the hardware profile data is required for decryption.

31. A content player compiled using a unique seed so as to read only content delivered using said unique seed.