WO2006010950A2

WO2006010950A2 - A method of storing and playing back digital media content

Info

Publication number: WO2006010950A2
Application number: PCT/GB2005/003000
Authority: WO
Inventors: Andrew Dewhurst
Original assignee: Radioscape Limited
Priority date: 2004-07-29
Filing date: 2005-07-29
Publication date: 2006-02-02
Also published as: WO2006010950A3; GB2416887A; GB0515639D0; EP1779215A2

Abstract

Music tracks are received over wireless digital radio and stored in encrypted form in a digital media player, but only when the player is receiving and playing back advertisements is it possibly to playback stored, encrypted tracks. A user could therefore build up a large library of music tracks over time, stored on the player, knowing that he could listen to any so long as he was prepared also to listen to advertisements. No payment is needed to initially receive and store the tracks; instead, distributors of the content and the content owners can be paid out of the advertising revenue. Further decryption of stored media content, beyond the limited amount decrypted once a decryption key associated with a given advertisement has been received and processed, is possible only so long as subsequent advertisements axe received at and played back by the player.

Description

A METHOD OF STORING AND PLAYING BACK DIGITAL MEDIA CONTENT

FIELD OF THE INVENTION

This invention relates to a method of storing and playing back digital media content; in particular, it relates to a method that enables digital audio or video to be stored and played back on digital media players only if defined access control requirements are met.

DESCRIPTION OF THE PRIOR ART

The music industry is facing a major change to its traditional business model. The sales channel is no longer tied to the handling of the media, as was previously the case with CDs and cassettes. The content (i.e. the song) and the physical media on which it is stored (i.e. the CD) are no longer inextricably Linked. In fact, CD sales are falling dramatically, as the internet, PCs and personal music players (such as the Apple iPod®) become the user equipment of choice and distribution channel for music data.

Digital rights management technologies, such as file level encryption that ties a downloaded music track to a particular PC or personal player, are now commonplace. The basic premise behind these technologies is to prevent a digital copy of content from being stored 'in the clear'; if it were stored in the clear, then mass scale, illegal replication could occur. The aim is to encourage music fans to purchase digital copies of content from legitimate sources, such as the Apple iTunes® web site, over the internet.

Hence, the link between music as data and the internet as the distribution channel relies on a transaction (e-commerce) to buy an album or song through specialist web sites, download the music file, store it, and transfer it to a player of some kind.

^' These functions are converging in equipment Like mobile phones, which can provide web access, a two way Link required for transmitting the purchase information and to receive the music data, and perform the function of the player itself. However, current solutions face three major barriers to broad acceptance as a consumer solution:

i) The internet/PC as a route to purchase, combined with a portable player remains a "techno wizard", cumbersome solution, inappropriate for all but personal style players that can be docked to a PC;

i) The mobile solution requires a "back channel" to perform the purchase transaction, making equipment expensive and reliant on the network service provider. The point-to-point nature of mobile phone networks means that widespread distribution of content will be both slow and require huge bandwidth;

i) The security of purchased music data remains a complex problem. The illegal copying and sharing of files is hard to prevent, and puts the industry at huge risk of piracy.

SUMMARY OF THE PRESENT INVENTION

In the present invention, a method of storing and playing back digital media content comprises the steps of:

a) sending digital media content to a digital media player without an end-user of that player specifically selecting any given item of that content or specifically initiating the delivery of any item of that content;

b) storing that content as a library of multiple items of encrypted content in a memory of the player;

c) sending a decryption key in conjunction with an advertisement to the player, the decryption key enabling the temporary or limited decryption of some of the stored digital media content under the control of the end-user.

Hence, for example, music tracks could be received and stored at a digital media player, but only when the player was receiving and playing advertisements is it possible to playback stored tracks. An end-user could therefore build up a large library of music tracks over time, stored on the player, knowing that he could listen to any so long as he was prepared also to listen to advertisements .

This overcomes several technical problem. First, when a user conventionally wants to store media content for subsequent playback, he would typically either go onto a music web site, find the track/ album he would like, then purchase the track etc and then download it to his player. Alternatively, he might already have a CD and could then simply burn it to his computer drive and subsequently listen to it. But in each case, the user has to go through specific steps that are both time consuming and, for many people, too complex. An implementation of the present invention addresses these technical problems by automaticalyl sending a large library of music tracks to an end-user's media player and causing those tracks to be stored on the media player: the user does not have to individually select a particular track/album to download, nor specifically initiate a download or burning or that track or album. • Hence, this is not copy on demand or a conventional streaming delivery system. Instead, the library is built up automatically and with minimal user intervention; the user might simply need to tune to a particular radio station that he likes anyway — for example his favourite jazz radio station. Then, in background and entirely automatically, a large body of jazz tracks will be automatically broadcast to his media player. The end-user may hence be unaware of the receipt if each track — i.e. the tracks may not be played out by the player during receipt, although it is also possible that the tracks sent to the media player and stored as a library are merely those tracks actually broadcast for receipt by conventional radio receivers.

This address the technical hurdles faced by many users in manually (and laboriously) finding and downloading suitable music by entirely removing those steps. In fact, a very significant number of ordinary users have neither the time, nor musical knowledge, nor computer skills, to build up a large library of music: the present invention enables such people to automatically acquire this kind of library. Although the specific example above has related to digital music, it applies equally to any and all other forms of downloadable media content, such as films, music videos, games, ringtones, wallpapers etc.

In addition, the capacity of the broadcast network can be far more efficiently and effectively managed since it can be the broadcasters themselves that determine when and what to broadcast, rather than responding to specific requests from users. Hence, broadcasters can ensure that data broadcasts makes good use of the available bandwidth.

No payment is needed to initially receive and store the tracks; instead, distributors of the content and the content owners can be paid out of advertising revenue. Further decryption of stored media content, beyond the limited amount decrypted once a decryption key associated with a given advertisement has been received and processed, is possible only so long as subsequent advertisements are received at and played back by the player. The term 'advertisement' should be expansively construed to mean any commercially valuable content, including advertising or promotional messages, logos, sponsorship, brand identifications, hyperlinks, reviews, previews or bulletins — anything that is valuable if it can be seen, heard or read by consumers.

In one implementation, a broadcaster transmits the advertisements and determines for how long or to what extent, in terms of the amount or extent of data or files, a decryption key will decrypt media content stored on the player. This allows the broadcaster control over how decryption operates on players. The stored media content can also be protected by a unique encryption layer that allows a further decryption key to permanently decrypt that content. End-users therefore have the flexibility to purchase content, allowing them to play it back without the need for advertisement interruptions. The user need only purchase the further decryption key and use it.

The digital media content that is sent to the player is labelled so that the player is able to generate and display a UI that enables an end-user to browse the stored encrypted media content and select the media content to be played back.

The kind of media content received by the player can be determined by an end-user selecting a particular channel, broadcast station or internet based stream. Hence, the user wishing to build up a library of jazz music could have the player tune into a jazz music distribution channel. The player could use wireless or wire-based connections (or some combination of the two) to connect to the remote server hosting the jazz tracks. The player could be a digital radio, mobile telephone or internet connected appliance.

The media content received by the player can be encrypted prior to transmission to the player. Alternatively, it is not encrypted prior to transmission to the player but encrypted by the player itself prior to storage so that real-time playback does not require any decryption but subsequent playback of stored media content does require decryption.

Just as the user can select different sources of digital media content from which to receive content, he can also select different sources of advertisements to be received by selecting a particular channel or station. This source of advertisements can correspond to the source of that media content. Hence, the jazz music fan obtains his jazz tracks from a jazz channel that also broadcasts advertisements with decryption keys. The jazz channel may indirectly assess

^' how many listeners it has so that appropriate charges for advertising can be made to advertisers and a proportion of that revenue fed back to content owners; conventional audience monitoring techniques can be used. Or players may have a back channel of some manner that directly informs the channel or some central registry which advertisement is being listened to, enabling advertising revenue to be calculated and a fair proportion fed back to content owners. How that proportion is calculated depends on the player sophistication; if the player is able to report back to the registry what tracks have been downloaded to a player and/or what tracks are being replayed on a player, then there can be a direct path linking the content owner of a track to the advertising revenue that enabled that track to be replayed. For less sophisticated players, then the normal techniques deployed by copyright collection agencies can be used.

The kind of advertisements required by a player to decrypt stored media content can also be determined by characteristics of the stored media content; hence, if the player has stored predominantly classical music, then audience research may indicate that the user would be more interested in advertising for financial products than fashion items; hence targeted advertising is possible.

The advertisements received by the player can be played either when received or temporarily stored on the player and played back subsequently. The subsequent playback can be at a predetermined time in relation to the media content being played, such as at the end of a music track.

The stored media content may contain information regarding the source of the media content, permitting the player to select the source of the advertisement containing the decryption key. Hence, all content received and stored originating from a specific broadcaster may require the advertisements to be sourced from that same broadcaster's services.

One advantage of this approach is that the encrypted media content stored on the player can be distributed to another digital media player but decrypted in part by that other player only if a decryption key transmitted over a wireless network in conjunction with a broadcast commercial or advertisement is received and played back by that player. Hence, friends can freely share entire music/video etc. libraries.

The received digital media content can be a digital audio or video stream or file.

In another aspect, there is a digital media player that can receive and play digital media content and advertisements; the player comprising:

a) a communications receiver adapted to receive (i) digital media content without a user of that player specifically selecting any given item of that content or specifically initiating the delivery of any item of that content and (ii) a decryption key that is transmitted in conjunction with an advertisement; b) a memory for storing the digital media content as a library of multiple items of encrypted content;

c) a processor adapted to use the decryption key for temporary or limited decryption of a limited amount of some of the stored digital media content for playback by the player.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described with reference to the accompanying drawings in which:

Figure 1 is a schematic depiction of the 'transmission' side of an implementation of the present invention, called the eScape system;

Figure 2 shows the construction of the UEL (Unique Encryption Layer) used in eScape;

Figure 3 shows the construction of the TEL (Temporary Encryption Layer) used in eScape;

Figure 4 shows the components of the Temporary Decryption Key (TDK)used in eScape;

Figure 5 shows the configuration of a player in the eScape system.

DETAILED DESCRIPTION OF A PREFERRED IMPLEMENTATION

1. Overview

The present invention is implemented in a system called eScape. eScape is a novel digital radio broadcast and reception scheme that provides for secure distribution of media content and flexible end-user access to that media content. Provision is made for encryption and decryption techniques to protect the perpetual 'rights' of the media content, both in the first instance of the media broadcast, and in the further duplication and distribution of the media. The eScape system obviates the requirement for a back-channel, typically required in the commercial protection of electronically distributed media content.

1. Principle of operation

The eScape system will typically operate as follows:

i) a 'broadcaster' is responsible for collating and distributing source media content. The distribution means may be wired (e.g. internet based) or wireless. Broadcasters such as the BBC may use the established digital radio infrastructure (such as DAB) to transmit media content;

i) the media content is encrypted prior to transmission;

i) the media content is received by player devices, comprising receiver and data storage means. Players may be capable of playing audio or video or displaying textual data;

i) the player stores the content in its encrypted format, thus building up a library of media content;

i) users may manipulate the stored media content within their player, such as deleting, indexing, making compilations, copying and transferring to other players;

i) when the user chooses to play back stored media content, the player must obtain an unlocking key to temporarily decrypt the content. The broadcaster may make provision in the encryption scheme such that limited playback is possible prior to receiving an initial decryption key, allowing, for immediate playback of broadcast media content; i) the broadcaster transmits advertisements, in addition to encrypted media content, that contain an embedded key(s) necessary to decrypt stored media content, typically valid for a limited period. The player equipment may incorporate a means to store received keys to allow for scheduling of received media content and decryption keys to allow for uninterrupted play-back;

i) a typical user experience of the system starts therefore with the selection of the stored media content, perhaps using the menu system on his player, and then activating play¬ back. The player then plays the content, interspersed with advertisements which are received from time to time and provide the necessary decryption key(s);

i) play-back is permitted until such time as the advertisements are no longer received or the player equipment is configured to omit the advertisements (which could be in the form of audio, video or data ). At this time, play back will cease in accordance with the limited decryption rights last received, typically a time period of a few minutes;

i) broadcasters may derive revenue through advertising, or other "forced" reception of content such as reviews, previews or bulletins, which may also contain decryption keys.

Typically the broadcaster that provided the source media content will have applied encryption rights to the source such that decryption keys, via advertisements etc, must be sourced from that same broadcaster;

i) it is envisaged that broadcasters may replace traditional radio and TV services with streaming services, intended for storage at the user equipment (prior to play-back), obviating the need for program scheduling, programme announcements and introductions, disc jockey functions etc by the broadcaster, in favour of a scheme broadly conforming to the description above;

i) it is further envisaged that broadcasters and network service providers may organize the distribution of content in such a manner as to provide dedicated media content streams and dedicated advertisement streams. PREFERRED EMBODIMENT

An example eScape system is shown in diagrammatic form in Figures 1 through Figures 5.

Figure 1 shows the 'transmission' side of an eScape system:

Item 1.0 of Figμre 1 shows a grouping of the components of the system associated with the owner or provider of the media content. This component comprises:

(i) item 1.1, the previously recorded or compiled media content, for instance CD master tapes;

(i) item 1.2, the Media rights, is a machine readable file containing information about the media content, such as song title, artist name, record label etc, together with specific rights of use. These rights will include a flag to determine if the material has been authorised by the owner for broadcast under the eScape system and any limitations of use, such as to be playable for a specific time period, or a specific number of uses. These rights also include information allowing future purchase of the media content for unencumbered use;

(i) item 1.3, the media key, is a unique encryption key, generated by the owner/provider, used to force a disclosed relationship between owner and broadcaster (typically this will use a public/private keying method such as tripleDES);

(i) item 1.4, the encryption engine, compiles media content and media rights to an encrypted form, thereby creating the Unique Encryption Layer (UEL) content. It is envisaged that the encryption engine is implemented in a software program form, running on computer hardware;

(i) item 1.5, a library of media content comprising UEL content. This could be a in the form of computer files or physical media.

Item 1.16 groups the broadcaster components of the system. Provided that the broadcaster has applied for and received the media decryption key, complementary to item 1.3, he is able to decrypt and make use of the UEL content. The broadcaster is responsible for providing the advertising content, item 1.6, and for defining the broadcaster information file, item 1.7. This file includes information such as the broadcasters name, IP address or radio frequency, together -with the rights of use for each element of media content. These rights may include content classification data used to aid automatic advert selection. These rights are appended to the Media rights, item 1.2.

The broadcaster information file will include information such as the period of time that temporary decryption remains valid for, the maximum number of uses of the media content, content expiry date, the source address(es) for advertisements containing the decryption keys and a placeholder for end user rights. These placeholders may be populated by the player as part of an electronic transaction to purchase the media content, typically storing a permanent decryption key, unique content ID and unique player ID.

Item 1.8, the Embedded Decryption Key (TDK) Engine, combines advertisement content, broadcaster information and rights and media content information (extracted from the ULE content) to produce the appropriate decryption content, which is stored in the advertisement content library, item 1.11. The associated encryption keys, item 1.10, are passed to the Temporary Layer Encryption (TLE) Engine, item 1.9, where encryption of the media content takes place, the output of which is stored in the media content library, item 1.12. This process will be under the control of item 1.13, the schedule controller, which ensures that valid TDKs are available for the media content. This may require the TDK Engine to 'refresh' temporary keys stored in the advertisement content library from time to time. In cases where updated media, 1.5, becomes available, or should the broadcast information be updated, item 1.7, the media content library, item 1.12, may also be 'refreshed' under the control of the schedule controller.

Item 1.13, the schedule controller, and schedule content selectors, item 1.14, interoperate to ensure the media content is broadcast in a timely manner with associated advertisements to ensure the availability of suitable temporary decryption keys at any given instant.

In this example the advertisement content library and media content library are shown distributed over the same channel, item 1.15, though this need not be the case. A typical example of this distribution could be using DAB digital radio transmissions.

Figure 2 shows the construction of the UEL, a sequence of digital information, comprising: (i) item 2.1, the Owner ID, an identification number unique to the content provider;

(i) item 2.2, the broadcaster ID (or other distributor) of the media content. Content providers may appoint multiple broadcasters. Items 2.1 and 2.2 remain unencrypted, whilst the remainder of the UEL is encrypted. Items 2.1 and 2.2 identify the required decryption key. This key would typically only be available to the content provider and the broadcaster. This permits secure distribution of the UEL (from group item T.O to group item 1.16 in Figure 1.);

(i) item 2.3, the Broadcaster Rights, is a code word which includes the rights of the broadcaster to use the content;

(i) item 2.4, the Date Stamp, is a record of the date on which the UEL was created;

(i) item 2.5, the Maximum Use Period, describes the time period (or life) over which the UEL may be exploited by the user. This information is used by the player;

(i) item 2.6, the Maximum Use Number, limits the number of times the user may exploit the content;

(i) item 2.7, the Withdrawn Flag, indicates if the UEL has been withdrawn from use by the owner. It is envisaged that UEL data would be distributed in the form of a library, and successive releases of such a library would include both new material, withdrawn material, or material no longer for distribution. In these respects items 2.3 allows for content to be omitted from further distribution by the broadcaster, and item 2.7 allows for content stored on players (i.e. previously distributed) to be deleted from players. It is likely that players will be configured in such a manner as to allow stored content to be overwritten by more recent versions, and to allow for broadcast instructions to instigate automatic deletion of content;

(i) Item 2.8, the Content Header, contains information specific to the content, such as song title, artist, duration etc;

(i) Item 2.9, the Data, is a sequence of information containing the media content, typically in an encoded format (such as AAC for audio, JPEG for pictures etc).

Figure 3 shows the Temporary Encryption Layer. Once a broadcaster has received the UEL format media content, he is able to decrypt the data payload (items 2.3 to 2.9 inclusive) with the key provided by the Owner, the key being identifiable according to the unencrypted components of the UEL, items 2.1 and 2.2.

The broadcaster is now able to compile media content ready for distribution to end users. This distributed media content is formatted as Temporary Encryption Layer (TEL) data. Each TEL comprises:

(i) item 3.1, the Content ID, a unique identification number for the media content. This may be assigned by the broadcaster or be extracted from the Content Header (item 2.8) if the Owner has provided one;

(i) item 3.2, the Content Type, is used to categorize the media content. This may be used to assign different decryption keys (Figure 4) and to allow for automated content recording/playing according to users selection of content type;

(i) item 3.3, the Temporary Key ID, is an identifying number, unique amongst distributors (a distributor may also choose to implement multiple keys) that is used by the player to correctly select the correct decryption key for the content. As decryption keys are temporary in nature, and regularly expire, item 3.3 will typically include information regarding the source of keys. E.g. a specific radio channel or a web address, where the keys will be broadcast. There may be multiple sources of keys listed in the Temporary Key ID;

(i) item 3.4, the broadcaster date stamp records the date and time of the TELs distribution;

(i) items 3.5 to 3.7, Broadcaster Maximum Use Period, Broadcaster Maximum Use Number and Broadcaster Withdrawn Flag, correspond in function to items 2.5 to 2.7, but are set at the broadcaster's discretion. The player will arbitrate in favour of the Owners use limitations (2.5-2.7) over those of the broadcaster (3.5-3.7);

(i) Items 3.8 and 3.9 comprise the re-encrypted UEL. Item 3.8 is the unencrypted payload of the original UEL. Item 3.9 is the media content of the UEL, first decrypted to original form, then encrypted by the broadcaster (therefore requiring the temporary decryption key prior to play back). Whilst distributing various media content, in TEL form, the broadcaster must also distribute, at appropriate intervals, the Temporary Decryption Key(s), Figure 4, necessary to decrypt and authorize the use of the stored media content.

These Temporary Decryption Keys will include embedded advertisement broadcast data (Other required content, i.e. content that the broadcaster has a commercial interest in ensuring the user receives and plays the content, could equally carry the embedded key). The player equipment will enforce the use of the embedded content within the TDK. An example of this would be for media content such as MP3 files, distributed over DAB digital radio, to be accompanied by audio adverts embedded in the TDKs, thus ensuring that listeners of stored content from a specific radio station would be forced to also listen to advertisements broadcast by that station.

The components of the Temporary Decryption Key (TDK) (Figure 4) include:

(i) item 4.1, the Temporary Key ID and item 4.2, the Content Type, together allow the player equipment to identify the required key from other stored keys;

(i) item 4.3 is the Temporary Key, the key that will decrypt the media content in the TEL;

(i) item 4.5 is the Temporary Key Period. This is a number representing a period of time for which the user is authorized to use the temporary key. It is assumed that broadcasts will contain time and date information, and together with date stamps in data and keys, and the date and time as per the player, keys can be validated by the player equipment;

(i) item 4.6 is the Temporary Key Number. This defines the maximum number of times that the Temporary Decryption Key may be used to decrypt media content before the key expires.

It is envisaged that the player will have received and stored numerous TDKs from different sources during normal operation, in addition to the media content. Typically keys from the same source, with the same content type will overwrite older stored versions, as will newer versions of content overwrite older ones. There may be instances where the latest valid TDK has expired, or is about to expire. In this case the player may use the Temporary Key ID (items 4.1 or 3.3) to automatically connect to the appropriate source in readiness to receive an updated key. In systems providing a back- channel to the broadcaster, the player may request a new TDK.

A typical player will include such components as a data receiver (such as a digital radio tuner), a storage means (such as a hard disc drive or memory card), a user interface (such as an LCD display, touch pad and buttons), a processing means (such as a microprocessor) and a play back means (such as a colour display, loud speaker). The configuration of such a player is shown in Figure 5, and comprises:

(i) item 5.1, a data channel, may be a single or multiple channels feeding in TEL and

TDK format data;

(i) item 5.2, the receiver will select appropriate sources of data from the channels, according to the users (or factory default) selection, which may be input using the human interface (HMI), item 5.3;

(i) item 5.4, the media content library, stores selectively received TEL data;

(i) item 5.5, the decryption key library, stores selectively received TDK data. (The player will compute which source and type of TDKs are necessary in order to use the stored media content, and continually add or update necessary keys);

, (i) item 5.3, The HMI, is also used to select the content for play back. This selection process generates a suitable addressing scheme (using the temporary key ID and content type etc) to extract the media content from the TEL and the appropriate TDK to feed to the decryption engine (item 5.9);

(i) item 5.9, This engine, will perform security checks based on the valid period and maximum number of uses, arbitrating key data, broadcast data and original owner data and date and time data, before decryption of the media content;

(i) item 5.10, the key requirement data, may instruct the receiver, item 5.2, to retrieve a valid TDK if no such key has been previously stored; (i) item 5.11 is the media content codec, typically required to decompress or decode the decrypted content using the appropriate algorithm (eg H.264 for video).

EXTENSIONS TO CORE CONCEPTS

1. Remote (broadcaster) control of the player is possible. For example, broadcast music data could be received and stored at the user's discretion, but before it can be used (viewed, listened to, read, transferred, copied, modified) the player must receive, from time to time, an unlocking instruction broadcast at the broadcasters or content owner's discretion, thus controlling the use of the content. This could be via a digital radio broadcast, over the internet, digital TV, mobile phone.

2. Forced update: It would be possible to apply eScape technology to "forced updates", i.e. rather than rely on receiving broadcast unlocking keys to allow the play back of recorded content, the unlocking event could be associated with an "update" broadcast. For instance a previously received road atlas could update with current traffic "black spots". Viewing the map would require the update to be received before it could be viewed, ensuring accurate data is portrayed.

3. Broadcast raw content, with public encryption keys solely for recording. This means that content can be listened to as it is broadcast by old equipment, and that only should the user choose to record the content is it encrypted, with associated rights (such as life-time, provider etc) to be played back later provided reception of unlocking signal allows same.

4. Targeted commercials: It is envisaged that stored content would contain linking information identifying the source of the unlocking data. This may include the broadcasters' identity, station name, service provider ID, IP addresses, frequency, multiplexer, channel, artist, record company, distributor and may also include profile information that may be used to associate the stored content with the characteristics, preferences, life style, stereotype, statistical data or buying trends that may be used by the player to automatically select a specific type or selection of unlocking data that also contains such profile information or superset thereof, that most closely matches the profile of the content being played. (It is reasonable to assume that some broadcasters may find the majority of their listeners are actually making use of stored content, played according to the listeners' personally programmed play list, and therefore more broadcast time (or bandwidth) may be devoted to commercials. In such a situation, more targeted adverts could be broadcast, containing profile information that ensures listeners hear adverts that are most likely to influence their buying decisions.)

5. Unlocking Key Types: It may also be the case that the future adverts and commercials take multiple forms, depending on the capabilities of players. It is envisaged that the (encrypted) content may be broadcast including information as to the "type" of advert to be played at such time as is required. This principle may be extended to describe the "preferred" priority of unlocking data type. For instance, if the player is equipped with a high resolution display, then select a "video clip" advert, otherwise if there is a multi-line LCD display, then select a "Banner ad" otherwise select an "audio clip". This unlocking "Type" may be determined by the "content" but could equally be a configuration of the player itself.

6. Broadcast technique ideas

(1) Broadcasts with embedded data payload.

(2) Commercials with embedded decryption keys.

(3) Broadcast encrypted data for later use, as and when keys are broadcast.

(4) Broadcast "remote control" over features and capabilities of the player

7. Service provider linking: Along with content being broadcast, add "rights" data that can include play and record control but also Links the source with the identity of the provider in such a way that during use of the content (recorded, live or otherwise) the "player" must adhere to the "rights", for instance displaying banner adverts on a display, tuning in to adverts, instructing the player to go to another source (recorder, internet, another channel etc) to recover other material, such as an advert or web page, or other material. A possible use here is in advertising — i.e. when playing a recorded track the radio knows the identity of the broadcaster and can retrieve data from that broadcaster whilst playing, so that adverts, pictures, sound clips, text, etc can be interleaved with the playing process) 8. Player ideas

(1) User record list creation (set up player to search for specific "content")

(2) Expired content deletion

(3) Graphic display of content status (Eg. Free ware, expired, purchased)

(4) Automatic tuning of player to radio channel that provided the selected "content" enabling unlocking commercials to be "tuned in" without user intervention.

9. Implementation ideas

(1) Time stamped decryption technique

(2) Encrypted "content" header information, allowing players to automatically tune to the station that sourced the "content". '

(3) Re-Key encryption updates

(4) If a file is already downloaded then some keys (UELs) may expire or be part-expired. In this case if the content is re-broadcast the system can simply intercept the revised key, rather than the whole content. This could be useful in reducing the decoding payload.

(5) Key updates could also be broadcast separately. This would require far less bandwidth to transmit than new content.

Claims

1. A method of storing and playing back digital media content, the method comprising the steps of:

b) storing that content as a library of multiple items encrypted content in a memory of the player;

c) sending a decryption key in conjunction with an advertisement to the player, the decryption key enabling the temporary or limited decryption some of the stored digital media content under the control of the end-user.

2. The method of Claim 1 in which the advertisement is any kind of commercially valuable content, including advertising or promotional messages, logos, sponsorship, brand identification, links, reviews, previews or bulletins.

3. The method of Claim 1 in which a broadcaster transmits the advertisements and determines for how long or to what extent, in terms of the amount or extent of data or files, a decryption key will decrypt media content stored on the player.

4. The method of Claim 1 in which the stored media content is also protected by a unique encryption layer that allows a further decryption key to permanently decrypt that content.

5. The method of Claim 1 in which the digital media content that is sent to the player is labelled so that the player is able to generate and display a UI that enables an end-user to browse the stored encrypted media content and select the media content to be played back.

6. The method of Claim 1 in which further decryption of stored media content, beyond the limited amount decrypted once a decryption key associated with a given advertisement has been received and processed, is possible only so long as subsequent advertisements are received at and played back by the player.

7. The method of Claim 1 in which the kind of media content received by the player is determined by an end-user selecting a particular channel or station.

8. The method of Claim 1 in which the media content received by the player is encrypted prior to transmission to the player.

9. The method of Claim 1 in which the media content received by the player is not encrypted prior to transmission to the player but encrypted by the player itself prior to storage so that real-time playback does not require any decryption but subsequent playback of stored media content does require decryption.

10. The method of Claim 1 in which a source of advertisements received by the player is determined by an end-user selecting a particular channel or station.

11. The method of Claim 1 in which a source of advertisements needed to decrypt a given item of encrypted media content corresponds to the source of that media content.

12. The method of Claim 1 in which the kind of advertisements required by a player to decrypt stored media content is determined by characteristics of the stored media content.

13. The method of Claim 1 in which advertisements received by the player are played either when received or temporarily stored on the player and played back subsequently.

14. The method of Claim 13 in which subsequent playback is at a predetermined time in relation to the media content being played.

15. The method of Claim 14 in which the predetermined time relation is at the end of a music track.

16. The method of Claim 1 in which the encrypted media content stored on the player can be distributed to another digital media player but decrypted in part by that other player only if a decryption key transmitted over a communications network in conjunction with a broadcast commercial or advertisement is received and played back by that other player.

17. The method of Claim 1 in which the received digital media content is a digital audio stream or file.

18. The method of Claim 1 in which the received digital media content is a digital video stream or file.

19. The method of Claim 1 in which the player is a digital radio player and the digital media content and advertisement is broadcast over a digital radio network.

20. The method of Claim 1 in which the player is a mobile telephone.

21. A digital media player that can receive and play digital media content and advertisements; the player comprising:

a) a communications receiver adapted to receive (i) digital media content without a user of that player specifically selecting any given item of that content or specifically initiating the delivery of any item of that content and (ii) a decryption key that is transmitted in conjunction with an advertisement;

b) a memory for storing the digital media content as a library of multiple items of encrypted content;

22. The digital media player of Claim 21 in which the stored media content is protected by a temporary encryption layer" that allows a decryption key to temporarily decrypt the content or decrypt a predefined, limited amount of content.

23. The digital media player of Claim 21 in which a broadcaster transmits the advertisements and determines for how long or to what extent, in terms of data quantity or files, the decryption key will decrypt the media content stored on the player.

24. The digital media player of Claim 21 in which the stored media content is also protected by a unique encryption layer that allows a further decryption key to permanently decrypt that content.

25. The digital media player of Claim 21 which generates and displays a UI that enables an end-user to browse the stored encrypted media content and select the media content to be played back.

26. The digital media player of Claim 21 which is programmed to enable an end-user to manipulate the stored media content by deleting, indexing or making compilations of the stored media content.

27. The digital media player of Claim 21 which is programmed such that further decryption of stored digital media, beyond the limited amount decrypted once a decryption key associated with a given advertisement has been received and processed, is possible only so long as subsequent advertisements are received at and played back by the player.

28. The digital media player of Claim 21 which is programmed to receive and store the digital media content as a background process even when not playing back decrypted digital media content.

29. The digital media player of Claim 21 which is programmed such that the kind of media content ^"received by the player is determined by an end-user selecting a particular channel or station.

30. The digital media player of Claim 21 for which the media content received by the player is encrypted prior to transmission to the player.

31. The digital media player of Claim 21 for which the media content received by the player is not encrypted prior to transmission to the player but encrypted by the player itself prior to storage, so that real-time playback does not require any decryption but subsequent playback of stored media content does require decryption.

32. The digital media player of Claim 21 which is programmed such that the source of advertisements received by the player is determined by an end-user selecting a particular channel or station.

33. The digital media player of Claim 21 in which the source of advertisements needed to decrypt a given item of encrypted media content corresponds to the source of that media content.

34. The digital media player of Claim 21 in which the kind of advertisements required by a player to decrypt stored media content is determined by characteristics of the stored media content.

35. The digital media player of Claim 21 for which advertisements received by the player are played either when received or temporarily stored on the player and played back subsequently.

36. The digital media player of Claim 35 in which subsequent playback is at a predetermined time in relation to the media content being played.

37. The digital media player of Claim 36 for which the predetermined time is at the end of a music track.

38. The digital media player of Claim 21 for which the encrypted media content stored on the player can be distributed to another player but decrypted in part by that other player only if a decryption key transmitted over a wireless network in conjunction with a broadcast commercial or advertisement is received and played back by that player.

39. The digital media player of Claim 21 in which the digital media content is a digital audio stream or file.

40. The digital media player of Claim 21 in which the digital media content is a digital video stream or file.

41. The digital media player of Claim 21 for which the digital media content and advertisement is broadcast over a digital radio network.

42. The digital media player of Claim 21, further operable as a mobile telephone.

43. The method of Claim 1 or the digital media player of Claim 21 in which the source of the decryption key is derived from the stored media content.

44. The digital media player of Claim 43 where the source of the media content and/or the advertisements is a digital radio station or internet site or mobile phone network or combination thereof.

45. The digital media player of Claim 43 adapted to systematically retrieve and store further advertisements from the sources of the stored and periodically received media content.

46. The method of Claim 1 or digital media player of Claim 21 adapted to periodically insert an advertisement or other similarly commercially valuable content into the played back content at least as regularly as defined in previously received key content or other default period.

47. The method of Claim 1 or digital media player of Claim 21 adapted to periodically update or replace stored advertisements, similarly commercially valuable content or media content as it is received.

48. The digital media player of Claim 47 adapted to automatically update or replace stored advertisements or other key content or media content as it is received based on the stored media content.

49. The method of Claim 1 or digital media player of Claim 21 adapted to automatically receive and store further media content and corresponding decryption key data based on characteristics of previously stored media content.

50. The method of Claim 1 or digital media player of Claim 21 adapted to automatically receive and store further media content and corresponding decryption key data, based on user input of media content characteristics, including title, artist name, performer name, content type or other classification, source, channel, address, frequency or phone number.

51. The digital media player of Claim 46 including a means to omit the play-back of advertisements or other key data if the current media content has been made available for unencumbered use, such as through subscription or other agreement.

52. The method of Claim 1 or digital media player of Claim 21 adapted in such a manner as to allow media content to incorporate limited terms of use, including such information as required for a media player to be configured to allow limited use of the media content in the temporary absence of a decryption key.