WO2008009880A1

WO2008009880A1 - Decoding media content

Info

Publication number: WO2008009880A1
Application number: PCT/GB2007/002380
Authority: WO
Inventors: Richard Eric Pittaway; Anthony Rix; Philip Michaelson-Yeates
Original assignee: British Telecommunications Public Limited Company
Priority date: 2006-06-17
Filing date: 2007-06-26
Publication date: 2008-01-24
Also published as: GB0614160D0

Abstract

A wireless receiver (17), in the form of a mobile telephone, comprises a DAB receiver (31) and a GSM/GPRS transceiver (29) which enables bi-directional point-to-point data communications via a service provider (55). The DAB receiver (31) is arranged to receive media data from an over-the-air broadcast channel, the media data primarily representing television and radio streams. In order that the streams can be decoded and decrypted by media playing software (47) on the wireless receiver (17), a provisioning operation is employed to provide NSC header files and DRM licences to users in response to them making content requests. The header files and licenses are sent over a separate data channel and in advance of the broadcast content. The filenames of NSC header files may include information indicative of a time period over which the header files are valid. In response to selection of a particular service, software at the wireless receiver (17) is arranged to identify whether a corresponding NSC file is valid based on the time period encoded within the filename, and where two or more corresponding NSC files are present, to perform memory management to delete redundant NSC files.

Description

DECODING MEDIA CONTENT

FIELD OF THE INVENTION

This invention relates to a method and system for decoding media content at a processing device, particularly, though not exclusively, a wireless processing device arranged to receive media content from an over-the-air broadcast channel. The invention also relates to a memory management method and system.

DESCRIPTION OF THE PRIOR ART It is common for devices such as Personal Computers (PCs) and digital television set top boxes (STBs) to receive and output data representing media content, particularly video and/or audio content.

At the service provider end, the content data will be encoded into a particular format such as AVI, MPEG, or WMV and with particular encoding parameters such as bit-rate and display resolution. At the receiver end, a decoder will require information as to how the data was encoded so that it can be correctly decoded. Where the receiving device may receive data encoded in a number of different formats, this decoding information may be provided in the form of a header file which is associated with the encoded data, e.g. in the form of a content file or stream. The header file will usually indicate the data format, the audio and video bit rates, and the display resolution of its associated content. In the case of Media Player, so-called NetShowContainer (NSC) files provide the header information.

In certain situations, devices already storing one or more header files may receive updated header files. Such updates may be provided to minimise the chance of unauthorised users acquiring copies of the header file thereby enabling them to decode and output content. Updates may also be necessary if the content service provider intends changing some aspect of the encoding such that the existing header files will no longer be suitable for decoding the content.

It is desirable to provide an efficient way of validating decoding files, e.g. header files. This is particularly desirable where, as indicated above, updated decoding files are provided and so it is necessary to identify which header file or files should be used to decode associated content and which should be disregarded. SUMMARY OF THE INVENTION

In a broad sense, the invention relates to a method of processing data at a processing device, the method comprising storing one or more processing control files, the or each control file being associated with a respective set of content data and providing information enabling the processing device to perform one or more processing operations on the data, and in response to receiving a request to perform a processing operation on the data, identifying its associated control file and determining whether said control file is valid by comparing a reference time with a validity period indicated in the filename of said control file, the requested processing operation being performed on the data only if the reference time falls within the validity period.

According to a first aspect of the invention, there is provided a method of decoding media content at a processing device, the method comprising: (a) storing one or more decoding files, the or each decoding file being associated with a respective set of media content and providing information enabling decoding means at the processing device to decode the associated media content; (b) in response to receiving a request to decode a set of media content, identifying its associated decoding file and determining whether said decoding file is valid by comparing a reference time with a validity period indicated in the filename of said decoding file, the requested media content being decoded only if the reference time falls within the validity period.

In this way, decoding is only performed if the decoding file associated with the selected content is determined to be valid on the basis of information contained in the filename. In this sense, the filename means the string of characters which identifies the file, as opposed to the contents of the file or attributes associated with the file, such as the size and creation date of the file. Commonly, the filename will precede a file extension. By indicating a validity period in the filename, determination of validity is straightforward, and it is simply to set or modify by the provider of decoding files using a simple file rename operation.

Media content will generally be data representing audio and/or video content and which can comprise discrete radio and video programme files, e.g. representing individual programmes or groups of programmes, as well as streaming radio and/or video data. The term 'content' is not intended to be restricted to non-live (or archive) audio or video content and, as such, is also intended to cover data representing live or near-live audio or video information, e.g. a data feed representing a live sports event.

A decoding file is intended to be a file containing information relating to one or more encoding processes performed on the associated media content in order that decoding means at the processing device knows how to decode the associated media content. For example, the decoding file may specify the coding algorithm used to encode the file such that the decoding means knows which decoding algorithm to use.

The filename of the or each decoding file may specify a start time and end time and step (b) may comprise identifying whether the reference time falls between the start and end times. The specified start and end times may include a calendar date, e.g. in the form YYYYMMDD, and optionally a time within said calendar date.

The method may further comprise, in response to the request to decode media content, acquiring the requested media content from a remote source together with data specifying, or from which can be derived, the reference time for use in the comparison operation of step (b).

Step (b) may comprise identifying a plurality of valid decoding files associated with the requested media content, in which case the method can further comprise selecting one of the valid decoding files in accordance with a selection algorithm. This step may further comprise deleting one or more of the non-selected valid decoding files associated with the requested media content.

According to a second aspect of the invention, there is provided a method of decoding audio and/or video content at a wireless receiver, the method comprising: (a) storing one or more decoding files, the or each decoding file being associated with an audio and/or video data stream and providing information enabling decoding software at the receiver to decode the associated stream; (b) selecting a data stream for receipt by the wireless receiver; (c) in response to step (b) receiving the selected data stream and a reference time associated with the selected stream, identifying its associated decoding file and determining whether the decoding file is valid by comparing the reference time, or a further reference time derived therefrom, with a validity period indicated in the filename of the decoding file; (d) decoding the received selected data stream only if the decoding file is valid.

Step (b) may comprise selecting one of a plurality of DAB services transmitted in a DAB ensemble, the reference time received in step (c) being a common reference time associated with each of the services in the ensemble. Step (c) may comprise identifying a plurality of valid decoding files associated with the selected data stream, the method further comprising selecting a single one of the plurality in accordance with a selection algorithm.

According to a third aspect of the invention, there is provided a memory management method performed at processing apparatus having access to a memory storing one or more decoding files, the or each decoding file being associated with a set of content data and providing information enabling the decoding of said associated content data, the filename of the or each decoding file comprising a first part that identifies the associated content data and a second part comprising validity information, the method comprising: (a) identifying in the memory a plurality of decoding files having a first filename part which identifies a common set of content data; and (b) deleting from the memory a subset of the decoding files identified in step (a) in dependence on the validity information comprised in the second part of their respective filenames.

The second part of the or each filename may indicate a time period.

According to a fourth aspect of the invention, there is provided apparatus for decoding audio and/or video content, the apparatus comprising means arranged to: (a) store one or more decoding files, the or each decoding file being associated with a set of audio and/or video content data and providing information enabling decoding software at the processing device to decode the associated content data; (b) in response to receiving a request to decode a set of audio and/or video content data, to identify its associated decoding file and to identify whether the decoding file is valid by comparing a reference time with a validity period indicated in the filename of the decoding file, the requested content data being decoded only if the reference time falls within the validity period.

According to a fifth aspect of the invention, there is provided a wireless receiver for receiving and decoding audio and/or video content transmitted in an over-the-air broadcast signal, the receiver comprising: a memory storing one or more decoding files, the or each decoding file being associated with an audio and/or video data stream and providing information enabling decoding software at the receiver to decode the associated stream; selection means arranged to select a data stream for receipt by the wireless receiver, a receiver for receiving the selected data stream and a reference time associated with the selected stream; processing means arranged to identify the decoding file associated with the selected data stream and to determine whether the decoding file is valid by comparing the reference time, or a further reference time derived therefrom, with a validity period indicated in the filename of the decoding file; a decoder for decoding the received selected data stream only if the decoding file is valid.

According to a sixth aspect of the invention, there is provided a memory management system arranged to operate on a memory storing one or more decoding files, the or each decoding file being associated with a set of content data and providing information enabling the decoding of said associated content data, the filename of the or each decoding file comprising a first part that identifies its associated content data and a second part comprising validity information, the system comprising: identification means arranged to identify a plurality of decoding files having a first filename part identifying a common set of content data; and means arranged to delete a subset of the decoding files identified in step (a) on the basis of the validity information comprised in the second part of their respective filenames.

There may also be provided a method of provisioning decoding files to enable the decoding of media content at a processing device, the provisioning method comprising generating one or more decoding files, the or each decoding file being associated with a respective set of media content and providing information enabling decoding means at the processing device to decode the associated media content, and setting the filename of the or each decoding file to include a validity period.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described, by way of example, with reference to the accompanying drawings in which:

Figure 1 is a block diagram showing components of a DAB broadcast system suitable for broadcasting media content, and a wireless receiver; Figure 2a is a graphical representation of an electronic programme guide (EPG) stored in an EPG server;

Figure 2b is a graphical representation of an EPG when displayed on a display screen of the wireless receiver;

Figure 3a is a front view of a wireless receiver provided in the form of a wireless telephone;

Figure 3b is a block diagram showing the main functional components of the wireless receiver;

Figure 3c is a schematic diagram indicating a plurality of software applicatipns stored in memory on the wireless receiver;

Figures 3d and 3e are screen shots of menu pages displayable by an operating system of the wireless receiver;

Figure 4 is a flow chart showing navigating steps provided by a TV/Radio application of the wireless receiver;

Figure 5 is a modified version of Figure 1 in that additional service management system (SMS) and service provider (SP) blocks are shown in relation to the DAB broadcast system;

Figure 6 is a partial flow chart showing sub-steps of a scanning step shown in Figure 4;

Figure 7 is a block diagram showing components of Figure 6 together with an indication of interactions that occur during a content provisioning operation;

Figure 8 is a block diagram showing components of the SMS in greater detail and which is further useful for understanding the invention; and Figure 9 is a flow chart showing the main steps performed in a service provisioning operation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring to Figure 1 , respective systems for providing, broadcasting and receiving multimedia content, in this case video and/or audio content, using the known digital audio broadcast (DAB) system are shown.

At the broadcasting end, there is provided a head-end 1 and DAB transmitter 3. The head-end 1 comprises a content repository 3, a media encoder 5, a digital rights management (DRM) system 7, a multicast server 9 and an electronic programme guide

(EPG) server 11. At the receiving end is a wireless handset 17 which includes a DAB receiver and means for outputting multimedia data received from over-the-air broadcast signals transmitted by the DAB transmitter. For ease of explanation, the handset will be referred to hereafter as user equipment (UE) 17.

In the head-end 1 , the media content repository 3 stores, in digital form, video and/or audio content to be transmitted by the DAB transmitter 3. The repository 3 can also receive video and/or audio content from other sources, e.g. other content service providers. Such content may be live or near-live data feeds which may, for example, represent a live or near-live sports event. Whether provided in the form of discrete files or streamed media content, the repository holds details of digital media content that will be made available in a DAB broadcast for users operating UEs, such as the single UE 17 shown in Figure 1.

The media content in the repository may already be encoded in any one of a number of digital formats, for example MP3, AVI, MPEG, H264, or WMV. The content is input to the media encoder 5 which converts the data into one or more video and/or audio formats appropriate for media playing software provided on the UE, that is a format that can be decoded and output by the media playing software having the necessary decoding and/or decryption information. In this case, the proprietary application Microsoft Media Encoder™ 9, hereafter simply 'Media Encoder', is used to convert the content into Windows Media Format (WMV). This application is chosen since the UE 17 uses Microsoft Windows Media Player™, hereafter simply 'MS Media Player', as its media playing application. For the encoded content, Media Encoder 9 also generates header files which provide Media Player with the decoding information necessary for it to understand how the WMV files are to be played. In particular, Media Encoder 9 generates header files known as NetShowContainer (NSC) files. Media Encoder 9 is also arranged to format the files or streams to suit the DAB broadcast bandwidth.

The WMF content is passed to the DRM system 7. As will be appreciated by those skilled in the art, DRM systems are computer-based systems used to enforce predefined policies for controlling access to digital data, such as software, music and video. As will be explained further below, the DRM system 7 operates in conjunction with a Service Management System to control the content to which different users have access. In simple terms, the DRM system 7 is arranged to encrypt WMF data using encryption keys, e.g. with different media programmes or channels being encrypted using different respective keys. In order to output content at the UE 17, it is necessary for the UE to have a corresponding decryption key. The way in which decryption keys are sent to handsets, such as the UE 17, will be described later on in the description.

Encrypted WMV content is sent to a multicast server 9 which also receives EPG data from the EPG server 11. The EPG data is used to populate an EPG wireframe at the UE 17 so as to indicate the name and broadcast times of content transmitted in the DAB broadcast. At Media Encoder 9, content is arranged into a number of separate channels, e.g. BBC1 , SkyNews, and each channel contains a number of programmes. In DAB terminology it is common for channels to be referred to as 'services' and so this term will be used hereafter. The EPG data includes, for each programme, a service identity (ServicelD) to indicate the channel or service, the programme name, and at least its start time. Other data may be included, such as a brief description of programme.

The multicast server 9 converts the WMV content into packet data for streaming transmission to the DAB transmitter 2 using respective IP addresses. A stream may represent a discrete programme having a fixed duration, such as a pay-per-view sports event or news report, or, alternatively, the stream may represent a sequence of programmes The EPG data is also sent to the DAB transmitter 2. A suitable multicast server product is Microsoft Windows Media Streaming Server™. Further information on the above-mentioned off-the-shelf Microsoft packages is available from http://www.microsoft.com/windows/windowsmedia/default.mspx. A detailed understanding of each is not necessary for understanding the present invention.

At the DAB transmitter 2, a DAB multiplex 13 receives each of the n multicast streams, e.g. four streams, from the respective IP addresses and broadcasts them in a DAB multiplex, or ensemble, from the transmitter aerial 15. The EPG data is also broadcast in the multiplex and is effectively treated as a separate service. The DAB multiplex 13 individually codes each stream in a channel coder by adding error protection and time interleaving. The services are then multiplexed in a so-called Main Service Channel (MSC) according to a predetermined multiplex configuration. The multiplexer output is combined with multiplex control and service information, including the ServicelDs of each stream, and the information is placed in a so-called Fast Information Channel (FIC) to form the transmission multiplexer. Orthogonal Frequency Division Multiplexing (OFDM) is applied to shape the DAB signal. The signal is then transposed to the appropriate radio frequency band, is amplified and then transmitted over-the-air. Further information on DAB multiplexing and transmission can be viewed at http://www.worlddab.org/eureka.aspx. The number of channels/services that may be encoded in the MSC can vary in number and is generally only limited by its 2.3 Mbit/s capacity. The service provider may wish vary the number of channels to be broadcast depending on the time of day, e.g. by providing only two streams during the night and four during the day.

During broadcast, the DAB multiplex may be scanned by the UE 17, or indeed any number of UEs in range of, the aerial 15, and individual services selectively received provided the necessary decoding and decryption information is present on the UE. At the

UE, selected services are extracted from the DAB multiplex by means of correlating the^'

ServicelD of the selected programme (e.g. from the EPG data) with ServicelDs in the FIC.

Based on this correlation, the multiplex control information for the identified Service ID is used to decode the COFDM-encoded service from the multiplex MSC. All that is then required is decoding by Media Player and, if necessary, decryption using the appropriate decryption key.

Referring to Figure 2a, an example set of EPG data, stored in the EPG server 9, is shown for each of the four above-mentioned streams (C1 , C2, C3 and C4) for the time period 1700hrs to 2300hrs. C1 carries video programmes relating primarily to news and current affairs, C2 carries entertainment-type video programmes, C3 carries video programmes of sporting events and sports-related entertainment and C4 is an audio channel carrying radio programmes. Not shown in Figure 2 is the ServicelD for each stream since this sits in the background. Figure 2b shows the EPG data when viewed on the UE at 1930hrs.

Referring to Figure 3a, the UE 17 is shown in further detail. The UE 17 comprises a GSM wireless telephone having a display screen and keypad. A so-called tv/interaction button 18 is provided on the right-hand side of the telephone casing. Referring to Figure 3b, the main functional components of the UE 17 comprise a microprocessor 27 to which is connected a GSM/GPRS transceiver 29, a DAB receiver 31 , a loudspeaker 33, a display 35, a keypad 37, a general memory 39 and a secure license memory 40. The UE 17 is capable of conventional tri-band GSM (GSM 900, 1800 and 1900) and GPRS operation for voice and data communications. The DAB receiver 31 provides the UE 17 with the capability of receiving, amongst other channels, the four services (C1 , C2, C3, C4) encoded in the multiplex that is broadcast from the transmitter aerial 15. Associated with the DAB receiver 31 is software for COFDM decoding. The UE 17 includes an antenna capable of receiving DAB signals in L-band and band III. Therefore, in addition to its function as a GSM telephone, the UE 17 is capable of receiving, decoding and displaying streaming multimedia content transmitted in over-the-air DAB signals.

The GSM/GPRS transceiver 29 enables bi-directional point-to-point data communications via a service provider (SP) network 19. As will be appreciated by those skilled in the art, GPRS is a mobile data service available to users of GSM mobile telephones, assuming their SP provides GPRS capabilities. GPRS is considered an 'always on' type data link since no dial-up connection is usually required - the link exists from the time the user switches their telephone on until the time the telephone is switched off. Compared with alternative mobile data communications methods, such as WAP, GPRS is favourable in terms of the speeds at which it can operate and provides convenient Internet access. To provide GPRS capabilities, the SP provides a controller at each base station to identify users within the relevant cell and to determine whether they have subscribed to that SP's GPRS service. Packet data switching nodes and gateways are also installed at the basestation to provide access to data networks, such as the Internet 21. The general memory 39 serves to buffer video/audio data as it is COFDM decoded from the DAB receiver 31. The memory 39 also stores a number of software applications which, when executed under the control of the processor 27, provide different services on the UE 17. Referring to Figure 3c, a top-level application is provided in the form of a handset operating system (OS) 41. The OS 41 provides a graphical user interface (GUI) that is output to the display screen 35 when the user first switches the UE 17 on. As well as providing conventional GSM voice call/reception functionality, the OS GUI provides a menu through which a user can view and run other applications. An example of a handset OS is MS Windows Mobile™ 2005. As Figure 3c shows, these further applications include a TV/Radio Application 43, MS Mobile Explorer™ 45 and MS Media Player™ 47, although in the case of the latter, any player that can decrypt and display streaming data can be used. Figures 3d and 3e show example screen shots taken from the OS 41 to indicate how applications can be run from the OS GUI. Figure 3d represents a homepage which is presented on the display screen 35 when the Ul 17 is switched on. At the top part of the screen is presented a number of shortcut icons representing pre-selected ones of the available applications. To execute a particular application, the user uses the keypad 37 to move a curser to the appropriate icon whereafter a selection command is made. In this case, the TV/Radio Application 43 (represented here by a television icon 43') is highlighted. Figure 3e indicates a so-called start sub-menu screen presented by the OS 41 which shows the full range of available applications. Again, selection is made by moving a cursor using the keypad and pressing a selection button.

The above-described menu selection steps have drawbacks in that the user is required to navigate using the keypad 37, usually by means of a cursor control or joypad, which can be small and awkward to use. Selection usually requires a number of inputs, such as directional controls and the selection command. Depending on how the menu system is set up, it may be necessary to go through a number of menu levels to access the desired application. To provide improved operation, the OS 41 enables one-click selection of a particular application by means of the tv/interaction button 18. At the software level, this is achieved by assigning one of the available applications to said tv/interaction button 18 and saving the assignment to memory 39. Thereafter, one-click actuation of the tv/interaction button 18 in any menu level of the OS 41 causes the assigned application to be executed on the Ul 17. In the present embodiment, the TV/Radio Application 43 is assigned to the tv/interaction button 18. Pressing said button 18 in any menu of the OS 41 , or even during execution of any other application (other than the TV/Radio Application 43 itself) causes the TV/Radio Application to be executed by the UE processor 27. Actuating the tv/interaction button whilst running the TV/Radio Application 43 causes an interactive service to operate within said application.

TV/Radio Application 43 Overview

The operation of the TV/Radio Application 43 will now be explained in further detail with reference to Figure 4 which shows the basic navigation tree of the application. As indicated by reference numerals 4.1 to 4.3, the TV/Radio Application 43 can be executed by one of three methods, namely by keypad navigation to the start menu (Figure 3e) or homepage menu (Figure 3d) or by single-click actuation of the tv/interaction button 18. In step 4.4 the user is initially presented with a 'splash screen' which is a pre-stored image in the UE memory 39 which has two main purposes. First, the splash screen acts as a holding screen which is displayed whilst any obsolete data is removed from the memory 39. The time the image is displayed will depend on the amount of processing necessary to clear the obsolete data. Secondly, the splash screen provides brand, version and copyright information. In step 4.5 it is determined whether the application 43 is being run for the first time, in which case a scan of available services is performed in step 4.6. Following this, or if it is not the first time of operation, EPG data is displayed in step 4.7. Thereafter, the user may select a channel by moving a cursor to the desired audio or video programme and pressing a select key (steps 4.8 and 4.9). If the selected channel is a free-to-air channel requiring no decryption, the control application will decode the appropriate stream from the DAB broadcast for output on Media Player 47. If the selected channel is a channel requiring decryption, the application 43 will check that a suitable licence is stored in the license memory 40 of the UE before extracting the decryption key from the licence and decrypting the selected DAB signal for display on Media Player 47 together with programme details, if available (step 4.10). This is ordinarily acquired during a licence provisioning operation as will be described later on in the specification. If no such license is stored in the license memory 40, the control application will prompt the user with the option to acquire a license or licenses. This may involve the user making a one-off payment, e.g. for a pay-per-view event or a short term subscription, or a recurring payment for a longer-term subscription. Any number of business/payment models can be used by service providers. If the user proceeds with payment, the appropriate license or licenses are sent to the handset for storage on the secure license memory 40 wherafter a DRM component of Media Player 47 may extract the decryption key or keys from the license or licenses to enable subsequent decryption of content in the DAB broadcast.

Decoding

The method by which received DAB services are decoded by the UE 17 will now be briefly described. Decoding in this case refers not to OFDM decoding by the DAB receiver but to decoding WMV streams by Media Player using header files.

As background, the usual way of accessing and decoding streaming data from a remote content provider is by means of a one-to-one IP link between the provider's streaming server and a receiver, usually a PC. The user operating the PC is able to browse and select streams and, because the user has a bi-directional IP connection to the source server, its media playing software has direct access to a 'header file' particular to the selected stream. The header file supplies information necessary for the media playing software, e.g. Media Player, to decode the streaming data. These particulars may include, for example, whether the stream represents audio or video data, the format in which the stream is encoded, the data rate at which the stream is to be played, and the display resolution of the programme.

As mentioned previously, Media Player requires access to a header file commonly known as a NSC file. A NSC file contains, amongst other information, a format block defining the format of the data, WMV in this case, as well as the display resolution (in the case of video) and the bit rates at which video and/or audio data should be played by Media Player. As will be described later, where content is encrypted, the NSC file for that content can be used to index the license stored in the secure license memory.

In the present system, content is broadcast from the transmitter 15 in an over-the-air unidirectional broadcast channel. Accordingly, there is no one-to-one link between the multicast server 9 and the Media Player software on the UE. It is therefore necessary to provide individual UEs with the header file(s) necessary to allow decoding of particular content in advance of the broadcast time of said content. In practice, it is convenient to provide a batch of header files corresponding to respective services or programmes in a single provisioning step. Accordingly, there must also be some mechanism at the UE 17 by which stored header files can be matched to their corresponding services. This matching will be briefly described below with the provisioning step being described later on in greater detail.

As mentioned previously, in the FIC of the DAB multiplex each service in the MSC is identified by a unique service ID. ServicelD's are regulated and assigned by the World Forum for DAB. A list of ID assignments for individual countries can be obtained via http://www.wohnort.demon.co.uk/DAB. By accessing the page for UK (national and regional) multiplexes, it is seen that the so-called Digital 1 (D1) multiplex includes a number of services, each of which has a unique servicelD. For example, Classic FM has the service ID C2A1 , while talkSPORT has the servicelD COCO. In the embodiment shown in Figure 1 , each stream output by the multicast server 9 is assigned a unique servicelD. For example, the first channel C1 may be assigned the servicelD e1c00097. Other channels are likewise assigned different servicelDs. Once provisioned to the UE, header files are stored in memory 39. Each header file includes information enabling correlation of the NSC file to the servicelD of the stream with which it is associated, i.e. the content stream from which the NSC file was generated by Media Encoder 5 in the head-end 1. User-selection of a service on the UE 17 causes the TV/Radio Application 43 to identify a stored NSC file that corresponds to the selected ServicelD. Media Player 47 therefore has access to both the WMV stream from the DAB receiver and the NSC file containing the decoding information to enable the WMV to be streamed. In this embodiment, correlation between NSC files and ServicelDs is achieved by arranging for the NSC file name to include the service ID of its associated stream. So, the header file corresponding to the first channel C1 may be named e1c00097.nsc or at least include the ServicelD in the name: selection of C1 on the EPG causes the TV/Radio Application 43 to locate a stored header file which includes in its filename 'e1c00097\

Service Provisioning

The UE 17 is arranged so as to be capable of receiving and outputting free-to-air services, typically radio services provided by third party terrestrial broadcasters such as the BBC. In order to receive services for which access is restricted to a sub-group of users, e.g. subscribing users, decryption information needs to be provided to individual UEs. This decryption information is provided in the form of a DRM license from which a key can be extracted to decrypt content that was encrypted at the DRM system in the head-end 1. The following description relates to methods and systems by which such licenses are provided to UEs in response to content requests. As will become clear, a similar mechanism is used to provide the above-mentioned header files to UEs.

Referring to Figure 5, the system of Figure 1 is shown in further detail to include components relevant to the provisioning process. The head-end 1 and DAB transmitter 2 are arranged as before with n service streams being supplied to the DAB multiplex 13. In addition, the head-end 1 comprises a Service Management System (SMS) 50 which handles management tasks including service provisioning as well as other functions such as the maintenance of user profiles, billing and so on. The head-end 1 is operated by a content provider (CSP) whose role is to provide multimedia content through the content repository 3, the EPG data through the EPG server 11 and the decoding and decrypting information. The CSP does not received orders directly from users but, rather, from one or more Service Providers (SP) 55 with whom the CSP has a commercial relationship. The SP 55 is responsible for offering services according to whichever set of commercial rules they wish to apply. Where the CSP deals with two or more SPs, it follows that the SPs may compete in terms of the service packages they offer and the pricing structure. The CSP is effectively a wholesale provider of multimedia content whereas the SPs represent retail providers. However, this arrangement is by no means essential and the provisioning concept can be applied to arrangements where users communicate directly with the CSP.

Referring back to Figure 4, it will be recalled that when the TV/Radio Application 43 is invoked for the first time, said Application is configured automatically to scan for channels in order to populate the EPG of the UE 17 (step 4.6). Following this first use, manual selection of a scan option is required to update channel listings. Referring now to Figure 6 it will be seen that step 4.6 actually involves a two-stage scan comprising (a) a basic scan 4.6.1 and (b) a service-related scan 4.6.2. The purpose of the basic scan 4.6.1 is to locate free-to-air DAB services that the UE 17 is able to tune to, e.g. BBC terrestrial radio services. The purpose of the service-related scan 4.6.2 is to locate services specific to the SP with which the particular UE 17 is associated. To achieve this, the TV/Radio Application 43 invokes a GPRS call to a web portal associated with the SP 55. The GPRS call includes a scan request which the SP 55 passes on to the SMS 50 of the CSP for provision of a so-called general fulfilment file. The general fulfilment file is a file made available by the CSP to the SP 55 through its SMS 50 and is not user-specific in the sense that the same file is made available to all UEs that make scan requests through the SP's web portal. The general fulfilment file conforms to various ETSI-based standards and uses the binary service information EPG format following [TS102371] with MIME type used in a standards-complaint way to signal URLs. A human-readable equivalent based on an XML format defined in TS102818 is given below, although in relation to a user- specific fulfilment file rather than a general one. A message comprising a URL hyperlink to the general fulfilment file is sent by the WAP Push Protocol (sometimes referred to as the Push Application Protocol or WAP-164) to the UE 17 which automatically accesses the link over a bidirectional GPRS link to download the general fulfillment file from the SP 55. The general fulfilment file is sent back from the SP portal to the UE 17 over the GPRS link.

Since the general fulfilment file follows the binary service EPG format, receipt at the UE 17 results in the EPG being automatically updated to include up-to-date service information on services available to the user from the SP 55. The general fulfilment file is also used to provide certain NSC header files, in this case for services requiring no subscription or payment, e.g. free-to-air services or other 'taster services' corresponding to movie trailers. Rather than transmitting the or each NSC file, the general fulfilment file contains respective hyperlinks to remote URLs which correspond the address of a physical server where the NSC file or files is/are stored. The remote server is likely to be provided by the CSP since the NSC files are generated by the Media Encoder 5 when content is encoded in the head-end 1. The hyperlinks follow the MIME type in order that the UE 17 will automatically call the hyperlinks once the general fulfilment file is received. This sets up a GPRS link to the or each hyperlink URL so that the or each NSC file is downloaded whereafter it is stored in the UE's memory 39. No consideration is made as to payment or subscription at this time since the purpose of this initial scan is to present all channels being made available to the user by the SP 55.

A human-readable example of a general fulfilment file sent to the UE 17 in the service- related scan 4.6.2 is shown below.

<epg: shortName>Dl</epg: shortName> <epg :mediumName>DigitalOne</epg :mediumName> <frequency type="primary" kHz="222064"/> <frequency type="alternative" kHz="223936"/> <service format="proprietary">

<service format="proprietary" > . . . entries for second service on same ensemble

</service> </ensemble> </serviceinformation>

The second line indicates the ensemble or multiplex ID, while the third to sixth lines give the name and frequency information for the ensemble. The remaining lines define each service being made available by the SP and, for those requiring no subscription, a hyperlink may be provided to the service's header file. Here, only one service is defined in full, namely the Sky News service having a service ID of e1c00097.0 and a header file e1c00097.nsc which is accessed via the specified URL.

Upon selection of a service from the EPG, the TV/Radio Application 43 will only output or play the service if it is free-to-air (unencrypted) or, if encrypted by the DRM system 7, if the UE 17 has access to a decryption key for that service. Such decryption keys are contained in a special type of file referred to as a license, the term DRM license being used here since encryption takes place in the DRM system 7. The concept of encryption keys is well known and a detailed discussion is not considered necessary. All that need be understood is that media content, be it an individual programme such as a pay-per- view sports event, a series of programmes, a complete channel and/or a batch of channels can be encrypted at the DRM system 7 using a different key which 'locks' the content in advance of transmission. The locked content can only be decoded and output if it is first unlocked or decrypted at the UE 17 using the corresponding decryption key. The DRM license not only contains a key but also a set of rights or privileges which determine the circumstances in which the key can be used, e.g. specifying that the key is only valid for one month after which it is deleted and a new key obtained. As with the above-mentioned provision of NSC files, the provision of licenses is also handled by the SMS 50 at the head-end 1.

Referring to Figure 7, an overview of the components in a provisioning arrangement are shown, the components being the UE 17, the SP 55 (or rather the SP web portal), the SMS 50, the head-end 1 and a transaction and billing platform 51.

The SP 55, via its web portal, provides a user interface by means of which users may log- in and be presented with details of services to which they are currently entitled and those to which they are not currently entitled. The individual services are, of course, listed in the content repository 3 of the CSP but, in this arrangement at least, it is down to the SP 55 to decide which services, or bundles of services, they wish to provide to their customers based on their commercial arrangement with the CSP. The service options may comprise, for example, a list of pay-per-view events available over the coming month, a list of individual channels, or bundles of channels with appropriate pricing schemes. The options may further specify the time period over which the subscription lasts, e.g. one or more months. In a first step, therefore, the user accesses the SP web portal, most probably using a GPRS connection to the URL of the portal, although selection could be made from a static PC so long as the user can provide their UE identity, e.g. their telephone number. The user selects their service options and provides payment credentials to the SP web portal.

In a second step, the SP 55 constructs a request message identifying the user, the selected service or services and any duration preferences. User identification may be by means of a unique user ID that is referenced at the SMS 50 to identify the handset, or alternatively/additionally, by means of the UE identity, e.g. the telephone number of the UE 17.

In a third step, the transaction and billing platform 51 receives a payment request from the SMS 50 identifying the user and the amount to be billed for the selected services. The transaction and billing platform 51 thereafter handles the payment process and, provided the funds are transferred appropriately, in a fourth step an authorisation message is sent back to the SMS 50. In response to the authorisation message, the SMS 50 generates a fulfilment file that provides access to the NSC header files and DRM licences required to decode and decrypt the or each service requested by the user in the first step. As with the general fulfilment file, this user-specific fulfilment file comprises hyperlinks to the header files and licences. The SMS 50 receives the NSC header files from the Media Encoder 5 in the head-end 1. Licenses are generated in a secure licence server (not shown in Figure 7) forming part of the SMS 50 on the basis of encryption keys used to lock the content at the DRM system 7 in the head-end 1. A license will include a key suitable for decrypting individual packages for a specified amount of time. For example, a single key may be associated with a single pay-per-view football match for its 2 hour duration, or with a single channel for a one-month period, or with a batch of channels for a longer duration. The licence rules specify how the key is to be used, e.g. the duration for which the key is valid. The licences so generated will be user or UE -specific in that they can only be accessed by the UE 17 of the requesting user. The or each license hyperlink in the fulfilment file is referred to as a voucher and operates as a one-off token.

In a sixth step, the above-mentioned fulfilment file is forwarded to the SP 55 which sends, via WAP Push, a message containing a URL hyperlink to the fulfilment file's location on the SP's server. As with the general fulfilment file, in a seventh step, the UE recognises the MIME type and automatically calls the hyperlink to set up a GPRS link to the URL so that the fulfilment file is downloaded. Other wireless point-to-point transmission mechanisms can be used to download the fulfilment file, such as WAP Push. The fulfilment file is, of course, user specific in that it comprises hyperlinks indexing URLs from where NSC files and licences can be downloaded to the specified UE 17. Once the fulfilment file is received at the UE 17, the or each NSC file is automatically downloaded from either the SP web portal (or directly from the SMS) by calling the header file hyperlinks. Similarly, the or each DRM license is automatically downloaded by calling the voucher hyperlink, this call resulting in the licence(s) stored in the licence server of the SMS 50 ng downloaded and stored in the secure memory 40 of the UE 17.

As before, the NSC header files and DRM licences are downloaded over a GPRS link from the URLs.

Having obtained NSC header files and licenses, the UE 17 is able to receive and output the requested content at its future broadcast time. This involves matching the ServicelD of the selected content stream with a stored NSC file that contains the same ServicelD in its filename. Identification of the correct DRM license may be performed in a number of ways but here the NSC header file also contains an index number identifying the DRM license in the secure memory 40. At the time of being generated, the DRM license is assigned a random number which is stored in the NSC file for the corresponding content. When Media Player™ matches the NSC file to the selected ServicelD, the presence of the index number identifies that a DRM license is to be retrieved from the secure memory 40 and its index number.

The TV/Radio Application 43 preferably performs a check prior to downloading the fulfilment file and/or NSC files. Although files may be compressed, e.g. using WinZip™, the memory 30 of the UE 17 is nevertheless limited and may not contain sufficient space to hold additional files.

Referring now to Figure 8, the service provisioning system is shown with components of the SMS 50, particularly the fulfilment file, voucher and license servers, 63, 65, 67 shown in greater detail. The SMS 50 includes a controller 53 that is connected, via respective IP channels, to the SP 55, a SP web portal 59 and a fulfilment file server 63. The fulfilment file server 63 is connected to a voucher server 65 which is in turn connected to a license server 67. Operation of each module will now be described in conjunction with Figure 9 which shows the main operating steps.

The SP 55 is arranged to receive service provisioning requests from end users, here indicated by reference numeral 57. An end user 57 will use their UE 17 to browse services made available by the SP 55. As mentioned previously, these services are presented on an EPG that is populated during the scan step 4.6. In this scan step 4.6, particularly the service scan step 4.6.2, a general fulfilment file is accessed from the SP Portal 59 using a GPRS call. The URL of the SP Portal 59 is stored in the memory 39 of the UE 17. This general fulfilment file does not contain any license information but simply indicates which services are made available by that SP. In response to the service scan 4.6.2 the general fulfilment file is sent to the UE 17 that made the request. Upon selection of a service from the EPG (step 1 1.1) the TV/Radio Application 43 on the UE 17 checks an internal license directory to determine whether the appropriate DRM license exists (step 11.2). If no such DRM license exists, a message is displayed on the UE display 35 indicating that subscription, or a one-off payment, is required to receive the service. The user 57 may decline and select a different service or proceed with the provisioning process. If the user 57 selects the 'proceed' option, the TV/Radio Application 43 automatically sets up a GPRS connection with the SP portal 59 which presents one or more purchase options to the user, for example to purchase the selected service on a one-off basis (e.g. for a pay-per-view sports event), to subscribe to the selected service for a period of time, or even to subscribe to a bundle of services of which the selected service forms part (step 11.7). Once selected (step 11.8) a request message containing the identity of the user/UE 17 and the selected service or services is sent to the SP server where the details are logged. The SP server 55 constructs an order message containing the user's identity and the service or services required and forwards this to the SMS controller 53 (step 11.9).

Provided the order is authorised, confirmation of receipt is sent back to the SP server 55. The SMS 53 then sends a web service request to the fulfilment file server 63, in response to which the fulfilment file server 63 is arranged create the user-specific fulfilment file, i.e. a fulfilment file specific to the user or UE 17 (step 11.10). The fulfilment file server 63 requests a single-use voucher for each requested service from the voucher server 65. The voucher returned by the voucher server 65 is embedded in the fulfilment file whilst details of the voucher are also sent on to the license server 67. An example of a human readable (XML) fulfilment file which includes such a voucher is given below.

< servicelnf ormation vers ion=" l" > <Ensemble id=" el . cl81" >

<epg : shσrtName>Dl</epg : shortName> <epg : mediumName>DigitalOne</epg : mediumName>

</service> < service format="proprietary" > . . . entries for second service on same ensemble

</service>

056728129" mimeValue="application/vnd. ttp. licenceconfirm"/> <link url=http://www /failure/102938418219240391831924

056728129" mimeValue="application/vnd. ttp. licencefailure"/> <link url="000112345678"

Mimevalue="application/vnd. ttp. licenceusid/>

</ensemble> </serviceinformation>

It will be seen that this user-specific fulfilment file is similar to the general fulfilment file sent in the service-related scan 4.6.2 but now includes a license user ID, a voucher specifying a link from where the required license can be retrieved, as well as links to pages from where success and failure notifications can be retrieved. The user-specific fulfilment file is sent by the SMS controller 53 to the SP portal 59 where it is stored (step 11.11).

A link to the storage location of the fulfilment file is sent to the requesting UE 17 by means of WAP Push (step 11.12). Upon receiving the WAP Push, the TV/Radio Application 43 on the UE 17 is arranged automatically to activate the embedded link and a GPRS session is set up with the SP portal 59 (step 11.13). The fulfilment file is downloaded from the address specified by the link, as are updated NSC header files and the voucher from the embedded links in the fulfilment file. The TV/Radio Application 43 will then initiate a connection to the Licence Server 67 specified in the voucher, and using Microsoft proprietary DRM protocols which form part of said application, send across the voucher that has been signed by a digital certificate. The licence server 67 is arranged to process the voucher, and on the basis of the key used to encrypt the relevant content at the headend, to deliver a licence to the UE 17 which contains the corresponding decryption key. Depending on whether or not the final licence is successfully received, the TV/Radio Application 43 will call the appropriate URL specified in the fulfilment file to indicate that the licence has/has not been loaded.

Assuming the requested licence is successfully delivered to the EU 17, Media Player will be able to decode and decrypt the WMF content streams subsequently received from the over-the-air broadcast (steps 11.2 to 11.6).

The above description relates to methods and systems for delivering decoding and/or decryption information to or at a wireless receiver, particularly a handheld mobile telephone that includes a DAB receiver. The receiver is therefore capable of receiving digital media content, such a radio or television streams or files, from the DAB channel and successfully outputting the content data to a display or through a loudspeaker so long as the required decoding and decryption rights are stored on the receiver. Such decoding/decryption information is provided in advance and via a point-to-point channel which is independent of the broadcast channel.

Although the detailed description relates to a DAB broadcasting environment, the service provisioning method and system may be applied to any over-the-air broadcasting environment where decoding and/or decryption information is required to decode and/or decrypt digital media content, such as digital video or audio.

Header File Naming Convention

As mentioned previously, the header files (NSC files in this embodiment) are assigned file names which include the servicelD of the content data stream they are arranged to decode. In this way, the receiver can correlate the appropriate header file to a selected service stream to enable decoding and output using MS Media Player.

For certain security purposes, as well as to support the ability to switch or update header files, the filename of header files may indicate a time period, for example in terms of a start date and time and an end date and time. At the receiver, this time period may be extracted from the filename and interpreted as the period during which that header file is valid, that is the time range over which the header file can be used to decode a corresponding service stream. Outside of this time range, the header file is considered invalid and another, valid, header file will be required to decode corresponding content. To facilitate this, the TV/Radio Application 43 is arranged to interpret the filename of received header files according to a predetermined naming convention to be explained below. An internal calendar and clock is held within the UE 17 which acts as a reference time for comparison with the time period information contained in the header file filenames.

The following naming conventions may be used for the NSC header files when they are generated

nsc_<Eid>.nsc nsc_<Eld>_<StartTime>_<EndTime>.nsc nsc_<Eld>_<Sid>.nsc nsc_<Eld>_<Sid>_<StartTime>_<EndTime>.nsc

<Eld> is the ensemble, or multiplex, identity and <Sld> is the service identity, both usually being specified in hexadecimal format and using padding characters to ensure a consistent string length that can be interpreted at the UE 17. <StartTime> is the start time from when the NSC file is valid and is provided in canonical form. Similarly, <EndTime> is the time at which the NSC file becomes invalid and is provided in canonical form. A zero character can be given for <EndTime> to indicate that the NSC file is valid until further notice.

As indicated above, the StartTime and EndTlme are interpreted at the UE 17 with reference to a reference time, hereafter referred to as the DAB time. In this regard, a reference time is periodically transmitted with the DAB multiplex data and is associated with each service within that multiplex. This reference time is received at the UE 17 to update an internal reference clock. Between updates, an internal clock of the UE 17 is used to provide offset time from the last update to maintain an accurate indication of DAB time.

When a header file is received at the UE 17, its filename may be updated to place it in a consistent format. Where neither the StartTime or EndTlme are given, the UE 17 implicitly assumes the EndTime is 0 and that the StartTime is the last-modified time, or if this is not available, the time from the internal reference clock when the header file was downloaded. The header file is then saved in the memory with an updated filename which can be interpreted according to these assumptions. Examples are given below:

nsc_c111_e12c3456d.nsc with last-modified time 2006-04-24T14:38:00 is interpreted as nsc_d 11_e12c3456d.nsc_20060424143800_0.nsc;

nsc_c111_e12c3456d.nsc_20060501000000_200606010000.nsc means that the header file is valid for the whole of May 2006; and

nsc_c111_e12c3456d.nsc_20060625180000_20060625200000.nsc means that the header file is valid for a two hour period, between 1800hrs and 2000hrs, on 25/06/2006, e.g. for a pay-per-view event.

For memory management purposes, the TV/Radio Application 43 is arranged automatically to purge or delete header files once it is determined they are no longer valid. In this respect, the amount of memory present on the UE 17 will be limited and over time the memory may approach its maximum capacity unless some deletion strategy is employed. Furthermore, where two or more header files associated with a common service are identified, i.e. header files having a first filename part identifying a common servicelD, a selection strategy is required to identify which one of the plurality of header files to use and which to ignore and/or delete. The following is an outline of an example header file selection strategy performed in response to user-selection of a particular service (having a ServicelD) to be received and played using MS Media Player. A general deletion strategy is also described.

1. NSC files having the selected EId and SId and a non-zero EndTime are checked. The NSC file with the shortest duration, calculated using EndTime minus StartTime, and that is valid according to the current DAB time will be used, if one exists. If this NSC file includes a version timestamp (which can be used to force NSC file updates) then all other NSC files for this SId having an earlier StartTime than the timestamp are deleted at this point.

2. NSC files having the selected EId and SId and a zero EngTime are checked. The NSC file with the latest StartTime on or before the current DAB time will be used, if one exists. If this NSC file includes a version timestamp then all other NSC files for this SId having an earlier StartTime than the timestamp are deleted at this point.

3. NSC files having the selected EId but with no SId and a non-zero EndTime are checked. The file with the shortest duration that is valid for the current DAB time will be used, if one exists. If this NSC file includes a version timestamp then all other NSC files having an earlier StartTime are assumed to be invalid, although are not deleted since they may be valid for other Slds within the current EId.

4. NSC files having the selected EId but with no SId and a zero EndTime are checked. The file with the latest StartTime on or before the current DAB time will be used, if one exists. If this NSC file includes a version timestamp then all other NSC files having an earlier StartTime are assumed to be invalid, although are not deleted since they may be valid for other Slds within the current EId.

5. If no valid NSC file is identified from the procedure above, the TV/Radio Application 43 will monitor the point-to-point channel for a suitable NSC file for the selected service for up to ten seconds. If one is detected, the TV/Radio Application 43 will notify the user that the subscription is being loaded.

6. If no valid NSC file is identified at this point, the user is notified that there is no subscription available. The user may be prompted to acquire a suitable NSC file by means of the subscription/provisioning steps described previously.

NSC files for a given multiplex are deleted according to the following strategy, which is applied when any new NSC file is received for a given multiplex.

1. All files for the multiplex with an EndTime earlier than the DAB time will be deleted.

2. For each SId on the multiplex, including the case of no SId, for files with zero EndTime, the file with the latest StartTime earlier than the DAB time, and all files with StartTime later than the DAB time, will be retained and all earlier files deleted. By arranging for header file names to encode time period information, it is possible to provide updates to header files, for example to cater for an existing service stream being encoded using a different encoding format (e.g. with a different bit rate and/or resolution) at some future time. For security purposes, it is common for header files to be updated on a regular basis to prevent copying and distribution of header files which would otherwise enable unauthorised reception of service streams broadcast from the head-end. In conjunction with a suitable memory management facility, the encoded header files can be updated in an efficient and straightforward manner simply by interpreting data contained in the filename of the header file.

Claims

1. A method of decoding media content at a processing device, the method comprising: (a) storing one or more decoding files, the or each decoding file being associated with a respective set of media content and providing information enabling decoding software at the processing device to decode the associated media content;

(b) in response to receiving a request to decode media content, identifying its associated decoding file and determining whether said decoding file is valid by comparing a reference time with a validity period indicated in the filename of said decoding file, the requested media content being decoded only if the reference time falls within the validity period.

2. A method according to claim 1 , wherein the filename of the or each decoding file specifies a start time and end time and step (b) comprises identifying whether the reference time falls between the start and end times.

3. A method according to claim 2, wherein the specified start and end times include a calendar date and a time within said calendar date.

4. A method according to any preceding claim, further comprising, in response to the request to decode media content, acquiring the requested media content from a remote source together with data specifying, or from which can be derived, the reference time for use in the comparison operation of step (b).

5. A method according to any preceding claim, wherein step (b) comprises identifying a plurality of valid decoding files associated with the requested media content, the method further comprising selecting a single one of the valid decoding files in accordance with a selection algorithm.

6-. A method according to claim 5, further comprising deleting one or more of the non-selected valid decoding files associated with the requested media content.

7. A method of decoding audio and/or video content at a wireless receiver, the method comprising: (a) storing one or more decoding files, the or each decoding file being associated with an audio and/or video data stream and providing information enabling decoding software at the receiver to decode the associated stream;

(b) selecting a data stream for receipt by the wireless receiver; (c) in response to step (b) receiving the selected data stream and a reference time associated with the selected stream, identifying its associated decoding file and determining whether the decoding file is valid by comparing the reference time, or a further reference time derived therefrom, with a validity period indicated in the filename of the decoding file; (d) decoding the received selected data stream only if the decoding file is valid.

8. A method according to claim 7, wherein step (b) comprises selecting one of a plurality of DAB services transmitted in a DAB ensemble, the reference time received in step (c) being a common reference time associated with each of the services in the ensemble.

9. A method according to claim 7 or claim 8, wherein step (c) comprises identifying a plurality of valid decoding files associated with the selected data stream, the method further comprising selecting a single one of the plurality in accordance with a selection algorithm.

10. A memory management method performed at processing apparatus having access to a memory storing one or more decoding files, the or each decoding file being associated with a set of content data and providing information enabling the decoding of said associated content data, the filename of the or each decoding file comprising a first part that identifies the associated content data and a second part comprising validity information, the method comprising:

(a) identifying in the memory a plurality of decoding files having a first filename part which identifies a common set of content data; and (b) deleting from the memory a subset of the decoding files identified in step (a) in dependence on the validity information comprised in the second part of their respective filenames.

11. A method according to claim 10, wherein the second part of the or each filename indicates a time period.

12. A computer program stored on a computer-readable medium, the program comprising computer-readable instructions for performing the steps of a method according to any preceding claim.

13. Apparatus comprising a processing device arranged to operate under the control of the computer program as claimed in claim 12.

14. Apparatus for decoding audio and/or video content, the apparatus comprising means arranged to:

(a) store one or more decoding files, the or each decoding file being associated with a set of audio and/or video content data and providing information enabling decoding software at the processing device to decode the associated content data;

(b) in response to receiving a request to decode a set of audio and/or video content data, to identify its associated decoding file and to identify whether the decoding file is valid by comparing a reference time with a validity period indicated in the filename of the decoding file, the requested content data being decoded only if the reference time falls within the validity period.

15. A wireless receiver for receiving and decoding audio and/or video content transmitted in an over-the-air broadcast signal, the receiver comprising: a memory storing one or more decoding files, the or each decoding file being associated with an audio and/or video data stream and providing information enabling decoding software at the receiver to decode the associated stream; selection means arranged to select a data stream for receipt by the wireless receiver, a receiver for receiving the selected data stream and a reference time associated with the selected stream; processing means arranged to identify the decoding file associated with the selected data stream and to determine whether the decoding file is valid by comparing the reference time, or a further reference time derived therefrom, with a validity period indicated in the filename of the decoding file; a decoder for decoding the received selected data stream only if the decoding file is valid.

16. A memory management system arranged to operate on a memory storing one or more decoding files, the or each decoding file being associated with a set of content data and providing information enabling the decoding of said associated content data, the filename of the or each decoding file comprising a first part that identifies its associated content data and a second part comprising validity information, the system comprising: identification means arranged to identify a plurality of decoding files having a first filename part identifying a common set of content data; and means arranged to delete a subset of the decoding files identified in step (a) on the basis of the validity information comprised in the second part of their respective filenames.