WO2004027606A1

WO2004027606A1 - Playlist mechanism for media distribution

Info

Publication number: WO2004027606A1
Application number: PCT/AU2003/001216
Authority: WO
Inventors: Jonathan Robert Burnett
Original assignee: Jonathan Robert Burnett
Priority date: 2002-09-18
Filing date: 2003-09-18
Publication date: 2004-04-01
Also published as: AU2002951485A0

Abstract

Disclosed is a method for reproducing media content. A playlist of plural media elements (301-305) is obtained (501), typically from a remote source (15-19). The playlist is parsed (502) to thereby associate each media element (301-305) with location information (320-324) of a corresponding retrievable media content file (310-314). The media content files (320-324) are retrieved from the corresponding location, and reproduced using a corresponding media player (10-14).

Description

PLAYLIST MECHANISM FOR MEDIA DISTRIBUTION

Field of the Invention

The present invention relates generally to the distribution of electronic information and, in particular, to the distribution of multi-media information over a computer network using a playlist format.

Background In the context of electronic information storage and transmission, the term 'media' is used to cover a range of data formats from simple text files through to specialised formats for high quality reproduction of audio and video information. There are a large number of open and proprietary media formats used for storing, encoding, decoding and transmitting different types of digital information. In general, each type of media format requires a specific computer application, commonly known as a 'player' or 'browser', to enable end users to retrieve and/or reproduce the formatted information. Examples of popular media formats include QUICKTIME, MPEG, AVI, MP3, REAL, WINDOWS MEDIA, H.263 video coding and PALM. Most 'players' use their own dedicated media format, although some have player-independent formats.

In practice, a playlist must be processed directly by the media player, which means that each file referred to in the playlist must also be directly accessible by the media player. There is a growing use and distribution of streaming media on the Internet. In most cases, the entire media content is transmitted from a dedicated server to a receiving device (eg: a computer, mobile telephone handset etc.) which incorporates an appropriate media player. The media player manages the connection with the relevant server and handles any buffering required. Existing streaming content arrangements have been thought to be inefficient, since the entire contents of each multi-media file must be transmitted from the source and received by the media player before the contents can be played. Further, since existing streaming media arrangements require each end user to establish a unique session with the relevant server, the load on the server is directly related to the number of users accessing the information. There is little scope (if any) for reuse of the transmitted material.

Current trends in the distribution of media include increased use of broadband services, including deployment of wireless broadband networks. Specific areas of interest include the development of 'video on demand' services and a quest for new applications that will take advantage of wireless '3G' technology.

It is desired to provide improved mechanisms by which multi-media content can be efficiently distributed. Summary

There is disclosed herein, arrangements which use a playlist format that is independent of both the media format to be managed and the media player required to reproduce those media files. Unlike earlier playlist formats, the playlist provided by this disclosure does not need to be read or accessed by the media player. There is also disclosed an agent program which can process the playlist, locate the required media element and then pass this file to an appropriate player. For example, if a playlist refers to a series of MP3 files, the agent program can locate the required files and launch an MP3 player to actually play the files. Since the files referred to in the playlist do not have to be directly accessible by the media player, there is no requirement for the developers of such media players to 'adopt' or 'support' any particular playlist format. Further, the agent and/or original server can be configured to insert or read signature stamps to each file before allowing the file to be reproduced. This can be advantageous for copyright protection purposes.

There is further disclosed an arrangement which provides the ability to break- down streaming media into distinct units that are each uniquely identifiable using the novel playlist format. This enables optimum use of the distribution infrastructure by minimising the amount of unnecessary transmission and instead incorporating a system of caching.

In accordance with one aspect of the present invention, there is disclosed a method for reproducing media content, the method comprising the steps of: obtaining a playlist of plural media elements, associating each media element with location information of a corresponding retrievable media content file; retrieving the media content files from the corresponding location, and reproducing the media content files.

Other aspects of the invention are also disclosed. Brief Description of the Drawings

One or more embodiments of the present invention will now be described with reference to the drawings, in which: Fig. 1 is a simplified schematic representation of the main functional elements used in one implementation of the present disclosure;

Fig. 2 is a schematic block diagram of a general purpose computer used in conjunction with the arrangement of Fig 1; Fig. 3 is a schematic representation of a playlist data structure;

Fig. 4 is a schematic representation of a playlist element structure used in the playlist data structure of Fig 3;

Fig. 5 is a flow diagram of a method of processing a playlist by an agent program; Fig. 6 is a simplified representation of a playlist editor which can be used in conjunction with the agent program used in the arrangement of Fig 1 ;

Fig. 7 is a flow diagram of a specific user application incorporating the method of Fig 5;

Fig. 8 is a flow diagram of another specific user application using the method of Fig 5; and

Fig 9 is an example playlist that could be associated with the application of Fig. 7 or 8.

Detailed Description including Best Mode Referring to Fig 1, a general purpose computer 101 located with an end user has a plurality of different media players 10-14 installed. Such media players are typically software-based and may include for example products marketed under the tradenames RealPlayer, Windows Media Player, Yahoo Media Player, Quicktime, or HyperStudio. Media players in some instances may be supported by specific hardware components such as digital signal processors or decompression devices. The computer 101 also includes a dedicated playlist 'agent' program 150 operable for communicating with each of the media players 10-14, and for communicating with an external computer network 120 such as the Internet. The agent program 150 functions to process playlists that have been constructed according to the playlist format to be described. In operation, the agent program 150 opens a selected playlist file and parses the file to identify a required media element. If the required media file is not available "locally" (eg: within the computer 101), the agent program 150 arranges for a copy to be obtained externally at a master repository or server 15-19 connected to the Internet 120. Once a copy of the media file is obtained from an appropriate one of the servers 15-19 and stored in the computer 101, the agent program 150 identifies the format in which the media file is formed and launches the appropriate media player 10-14 on the computer 101 and passes the appropriate local filename to the player 10-14. The agent program 150 then identifies the next media element to be played and repeats the process. This may involve additional parsing of the current playlist file or the retrieval of a new playlist file with the description of the next media file. However, there is no need for the agent program 150 to wait until the current player 10-14 has finished reproducing the current file before the agent program 150 commences the retrieval of the next media file.

The nature of the Internet 120 means that the retrieval of media content files from a master repository or server 15-19 generally involves the transfer of the file along a series of intermediate servers (not shown). Because each media element has a unique universal filename, it is possible for these intermediate servers to cache copies of those media files. Subject to various considerations, it is then possible for the intermediate servers to return a cached copy of a file if they receive a request for the same media element. Alternatively, a local cache can be similarly used to store and subsequently retrieve such media files.

In this way, the use of the unique identification scheme for media elements enables the efficient transfer of data, since there is no need for all requests to be relayed all the way to a specific master repository 15.

Fig. 2 shows a computer system 100 incorporating some of the components referred to in relation to Fig 1, including the general-purpose computer or computer module 101. ' The computer system 100 includes the computer module 101, input devices such as a keyboard 102 and mouse 103, output devices including a printer 115, a display device 114 and loudspeakers 117. A Modulator-Demodulator (Modem) transceiver device 116 is used by the computer module 101 for communicating to and from the communications network 120, for example connectable via a telephone line or other functional medium. The modem 116 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and may be incorporated into the computer module 101 in some implementations. The computer module 101 typically includes at least one processor unit 105, and a memory unit 106, for example formed from semiconductor random access memory (RAM) and read only memory (ROM). The module 101 also includes a number of input/output (I/O) interfaces including an audio-video interface 107 that couples to the video display 114 and loudspeakers 117, an I O interface 108 for the keyboard 102 and mouse 103 and optionally a joystick (not illustrated), and an interface 108 for the modem 116 and printer 115. In some implementations, the modem 116 may be incorporated within the computer module 101, for example within the interface 108. A storage device 109 is provided and typically includes a hard disk drive 110 and a floppy disk drive 111. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 112 is typically provided as a non- volatile source of data. The components 105 to 113 of the computer module 101, typically communicate via an interconnected bus 104 and in a manner which results in a conventional mode of operation of the computer system 100 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include LBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom. The described arrangements are also appropriate for hand-held computer systems, such as those developed for the Palm, Windows CE or Symbian operating systems, particularly those with built in wireless modems. Typically, the agent program 150 and media player programs 10-14 are resident on the hard disk drive 110 and read and controlled in their execution by the processor 105. Media reproduced by the player programs 10-14 is typically output via the interface 107 using the display 114 and/or the loudspeakers 117. Intermediate storage of the program/s and any data fetched from the network 120 can be accomplished using the semiconductor memory 106, possibly in concert with the hard disk drive 110. In some instances, the application program/s may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 112 or 111, or alternatively may be read by the user from the network 120 via the modem device 116. Still further, the software can also be loaded into the computer system 100 from other computer readable media. The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 100 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 101.

Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

Fig. 3 illustrates a schematic representation of a playlist structure, in which media elements are sequenced using a linked list of playlist elements 301-305, each defined using Extensible Markup Language ("XML"). The playlist is therefore a set of XML elements that can be stored in either a single file or a set of distinct files. Each

XML playlist element 301-305 is associated with a specific description 320-324 and specific media file 310-314, respectively.

The attributes that need to be stored for each playlist element must provide sufficient information to uniquely identify a media element, determine the corresponding data format and to sequence the media elements. A benefit of using XML instead of a simple list of filenames within a text file is that additional attributes can be stored without affecting the ability of different programs to parse the playlist.

An example of the key attributes using a set of Uniform Resource Locators

(URLs) to identify the media to be played and adjacent elements of the playlist as shown in Fig. 4, is as follows:

(a) Next URL 401 , for next playlist element;

(b) Previous URL 402, for previous playlist element; and

(c) Source URL 403, for media content.

This naming format provides a full context that identifies a server from which a copy of the required media can be obtained. A set of widely recognised filename suffixes are also used to identify specific data formats.

Although the file naming system used above is derived from the World Wide Web "URL" schema, it is noted that other file naming systems can be used.

There are three main ways in which playlist elements can be linked together to form a playlist:

(1) Finite: A finite playlist has a start and end. In this case, the 'previous' field for the 'first' element in the list and the 'next' field for the 'last' element in the list are both 'blank'; (2) Closed: A closed playlist forms a continuous loop, with no actual start or finish. In this case, the 'previous' field for the 'first' element in the list points to the 'last' element in the list and the 'next' field for the 'last' element in the list points to the 'first' element in the list; (3) Open: An open playlist has no predetermined end. In this case, the

'previous' field for the 'first' element in the list may be blank, but the 'next' field for the 'last' element in the list points to the 'first' element in a continuation of the list.

Although a separate file can be used to store each playlist element, in some situations, it may be desirable to store multiple playlist elements (or the entire playlist) in a single file. In these situations it is necessary to refer to sections within the playlist file to identify a specific playlist element. Further, the playlist elements can include instructions for managing the transitions between the playing of different media elements.

Referring back to Fig 4, additional optional attributes which can provide a more- complete description of the media, are shown in phantom. These attributes are specific to the type of media involved and include for example:

(d) Author/Artist 404;

(e) Creation date 405;

(f) Copyright owner 406;

(g) Title 407; and (h) Genre 408.

Referring now to Fig 5, an example of a method 500 for processing a playlist performed by the playlist agent program 150 is described.

In a first step 501, a playlist file is received and opened by the playlist agent program 150. Thereafter at step 502, a first playlist element is parsed to determine URL information for each of: (a) the Media Resource element, (b) the Next playlist element, and (c) the Previous playlist element.

Following on at step 503, the local cache is checked to see if a copy of the required media resource element is already stored. If the required media content file is already held in the local cache, then the method proceeds to step 505. Otherwise, the method moves on to step 504. -

At step 504, a copy of the required media content file is externally obtained from the World Wide Web. Such a media file copy is derived and retrieved using a full filename of the media element. After obtaining and storing the media content file, the method 500 proceeds to step 505, where the media content file type is identified to determine the appropriate media player to be opened. The media content file type is usually determined from the filename suffix. Accordingly, the appropriate media player is located (if already running) or launched, and passed to the local filename of the requested media resource.

At step 506, the playlist file is again read to determine if the description for the next playlist element is present. If yes, then step 510 is proceeded to, in which the current media content file is closed, the next playlist file is opened and step 502 is proceed to. Otherwise, step 507 is proceeded to in which details of the next playlist element are located.

Following next at step 508, the local cache is checked for whether a copy of the media content file for the next playlist element is already stored. If there is a local copy, then step 506 is returned to. Otherwise, the method 500 proceeds to step 509. At step 509, the request file containing the next playlist element is obtained from the World Wide Web (WWW) and stored in local cache. hi the method 500, there is no need for the agent 150 to wait until the current media player has finished reproducing the current media file before the agent 150 commences the retrieval of the next playlist file and the next media resource. However, the agent 150 will need to wait until the player finishes before it launches a new player and/or passes on the next media resource.

By using unique filenames for both playlist files and media resource files, each can be efficiently cached by any Internet server they pass through. This can be done by existing Web caching systems, but may be handled by a dedicated server process that is aware of the file types involved.

Fig. 6 is a schematic block diagram of a playlist editor 600 associated with the agent 150, and used to create playlists. The playlist editor 600 of Fig 6 includes a basic file browser 610 and a simple interface 620 for rearranging the order of the media elements. A more sophisticated playlist editor is represented in phantom in Fig 6, which incorporates a playlist viewer 640. The viewer 640 enables a user to browse a playlist to review the contents or to locate specific elements. The viewer 640 may include various controls, such as 'play', 'stop', 'next', 'previous', 'start', 'finish', and 'information'. The viewer 640 may also incorporate features that enable the playlist to be reviewed, filtered and sorted in order to rearrange the order in which media elements are played.

An alternative method of creating a playlist is to use a search facility that locates media resources according to specific attributes. Such a search facility may be integrated into general purpose Web search facilities (such as Yahoo!, Google or Looksmart) or specialised Web based search facilities dedicated to a particular type of content (such as Yellow Pages, music websites, real estate websites, or automotive websites). The results of a search are retrieved as a playlist in XML format, rather than (or as well as) in the conventional HTML format required for viewing using a standard Web browser. The benefit of retrieving the results in playlist format is that the results can then be reviewed using a playlist viewer to further refine or reorganise the search list. For example, a summary containing the basic information about a property for sale (address, inspection times, etc) may be created from a real estate site. This list of properties for inspection could be sorted by viewing time or suburb. Additional information, such as the pictures of the house or a map showing its location, may be downloaded later if required.

Another method of creating a playlist is to use a transcript editor that is optimised to capture a sequence of media elements as they are broadcast or when they are published. This may include identification and incorporation of third party media elements (such as songs), prerecorded elements (such as advertisements) and live content. For example, a detailed summary of news items from a news service website (such as a broadcaster or newspaper publisher) could be prepared in playlist format. This summary may contain the news headlines broken down by category and possibly a brief extract that could be reviewed using the playlist viewer. The full article and/or associated images could be retrieved from the Internet if desired. Referring now to Fig 7, a flow diagram of an application to emulate a streaming methodology to approximate a full streaming media service is disclosed. This is achieved by combining blocks of streaming media, such as video or audio files.

A first step 700, involves the end user obtaining a copy of selected media content files, for example, from a compact disc issued by a radio station / broadcaster. Each media content file is able to be referenced by playlist elements written in accordance with the principles relating to the structure described in relation to Figs. 3 and 4. The compact disc includes for example, media content files for song tracks 1 to 5 as referred to in Fig. 9. The end user installs these media content files on their own personal computer. Fig. 9 in this regard is an example of a sequence of media files that could be associated with a commercial music radio station.

Step 710 is carried out when the end user wishes to listen to the radio station "broadcast". The agent program 150 resident on the end user's computer is opened and a playlist is downloaded from a website associated with the radio station.

Next at step 720, the method 500 of Fig. 5 is executed to emulate a streaming methodology to approximate a full streaming media service. Referring to the above example, it will be realised that song tracks 1 to 5 have been locally cached. However, when the playlist file refers to elements corresponding to commercial A, commercial B, news, or song track 6, as seen in Fig. 9, the respective media content files will be obtained externally.

The arrangements described above provide that close to "real time" distribution of media can be achieved using the method of Fig. 7, although in a more efficient way than existing streaming media technologies can provide. In the arrangement of Fig. 7, the "cached" media is that originally contained on the compact disc. Typically however, the media would be initially sought from a stream source such as the radio station or a corresponding music supplier. In this regard, the arrangements disclosed herein have particular applicability to commercial broadcast radio station which, as a matter of course, creates "program lists" that identify the particular order of content to be broadcast over a period of time.

Such a program list may commence, for example, on the hour with a five minute news segment followed by a musical piece, followed by an advertisement and then the disc jockey talking. Many alternatives and combinations are possible. In many commercial radio stations, such are typically created by program directors, producers and advertising sales persons. With a traditional "free-to-air" broadcast radio station, such a program list may be used to generate the "playlist" of the arrangements described above and dynamically placed upon the website of the radio station at regular intervals throughout the course of the broadcasting day. For example, a single day of radio programming may be formed into a master playlist containing breakfast, morning, lunch, drive time and evening content items. Each of those items may in turn reference a corresponding playlist for that period. Those periods may be further broken into playlists of, say, one hour duration. Accordingly, such an arrangement provides for nested playlists. With such an arrangement, a person who failed to hear a particular free-to-air broadcast but who wishes to hear the radio show or segment may, at a subsequent time, access the playlist from the radio station website and reproduce the show, or selected items therefrom, from the playlist. Significantly, items such as news items and speech by the disc jockey for example may be content sourced from recordings directly from the website of the radio station. Advertisements may be sourced from the website of the radio station or alternatively from the website of an advertising house who produced the advertisement. Similarly, music broadcast may be sourced from the music publisher or from the radio station. In each instance, and particularly in relation to items that may be repeated over various "listening" sessions, such as advertisements and musical content, once streamed to the user's location, such may be cached at the user's location for subsequent use.

Accordingly, on the next occasion when the user desires to reproduce a playlist, if for example the same song to be reproduced was contained in a playlist of a previous occasion, that song may retrieved from the user's own cache, rather than retrieved by streaming from that of the music publisher. The same can also apply for advertisements and other repeated items. As a consequence, when reproducing a playlist containing content items that may be repeated over a period of time, the user's local cache may be used to accelerate the "streaming" nature of the overall broadcast. Referring to Fig. 8, the techniques described herein can be used to more efficiently manage enquiries from consumers of free-to-air media broadcasts relating to earlier broadcasts. For example, a radio station listener may wish to seek details of a phone number broadcast earlier, the details of which were not obtained by the listener at the time, h this situation, the listener can point their Internet browser to the website of the radio station at step 800 to commence the enquiry.

Next, at step 810, the relevant playlist is searched from within a database containing time referable playlists. Once the required playlist is located by the listener, the method 500 of Fig. 5 can be executed, with the incorporation of use of the playlist viewer 640. This facility can minimise the time that radio station staff need to otherwise attend to such enquiries by telephone, as is referenced with respect to Figs. 7 and 8.

In alternative implementations, the identification of playlist files and media resources can be uniquely identified using full pathnames within a local area network, instead of URL's. This has no impact on the overall methodology, provided that all resources can be located within the network. In these situations there is no specific need to cache local copies. In some cases, it would even be possible to use relative path names based on a current working directory. This would be similar to many of the currently available playlist organisers. If playlists are to be shared by multiple users then it is preferable for each playlist file to be identified by a URL and to use a specific filename suffix, such as IPF (Independent Playlist Format).

Another implementation provides a playlist agent that is designed to support a full home theatre system, incorporating a wide range of features and optimised for retrieving files (such as videos) from a broadband network. In yet a further alternative implementation, the semi-streaming methodology to approximate a full streaming media service can be applied to static images, rather than video or audio files, h this arrangement, the playlist is used to create a video session from the component still images. Alternatively, the playlist can be used to manage sequences of static images to produce slide shows, product catalogues and brochures. The semi-streaming methods can be used to manage playlists for various forms of media, such as text files, graphic files, audio files and video files to produce slide shows, product catalogues, brochures, electronic magazines and customised sequences of audio and video clips. hi yet a further alternative implementation, the agent 150 can be configured to perform further activities including:

(a) Managing the purchase of fee-for-access content

(b) Copyright management

(c) Data decompression

(d) Data decryption (e) Authentication

(f) Playlist filtering

(g) Off-peak downloads

(h) Locating preferred formats.

The ability to undertake these activities within an agent that is independent of the actual media players, frees media player developers of the requirement to include these capabilities into their own products.

In particular, copyright management can be advantageously facilitated whereby the agent program and/or the remote server inserts a "signature stamp" with each media content file, before passing the file to the associated player. The contents of each such signature stamp could include for example fields related to: a) expiry date; b) inability to cache; c) inability to share; d) share sample only; e) play with this player only. hi the simplest scenario of cache "management, the playlist agent 150 and any

to determine how long (if at all) files are held in the cache, including: (a)\^ Expiry time stamps

(b) Copyright control

(c) Purchased content control (d) Version control.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, the media player/s can be provided on a target device instead of a general purpose computer 101. Such a target devices may include mobile telephones using for example, 3G wireless protocol sourcing and retrieving MP3 files.

Industrial Applicability

It is apparent from the above that the arrangements described are applicable to the electronic media delivery industries. The present disclosure provides a basis for solving some of problems currently experienced with the delivery of media content using the

Internet, including issues such as charging a fee for accessing content, copyright management, and efficient distribution of large amounts of data.

A key feature of the playlist mechanism is that it enables a detailed summary of media content to be maintained separately from the actual content. This summary can be used as a description or preview of content that can be subsequently purchased. For example, a news service may allow news headlines to be retrieved in playlist format for no charge, with a small fee for access to the full article. The use of a playlist mechanism also allows intermediaries, such as media-brokers or media agents, to be involved in the retrieval of data from a master repository or server. These intermediaries can accept requests for media content from an agent program (including verification of user details if required), retrieve the required file and deliver it to the user. As part of this process the intermediaries can record any payments due for the content requested. These brokers may therefore effectively become 'retailers' for the media content, enabling payment for data from a wide range of 'media wholesalers' to be incorporated onto a single account for later payment. The brokers may also cache content to improve the efficiency of data distribution by reducing the demand on the master repositories.

Improved management of copyright protected media could be achieved through the use of public key infrastructure (PKI) mechanisms in association with the playlist mechanism. For example, the agent program 150 can include a user's public key with the request for a specific media element. The server for the master repository would use this public key to encrypt the content before returning it to the user. The content could then only be read by the agent 150 with the private key counterpart for the original key, thereby enabling reproduction of the content which is otherwise indecipherable to any other user. The playlist agent that processes the encrypted data is distinct from the media player required to read or view the actual content. Therefore the use of a playlist with PKI encryption as a copyright protection mechanism can be implemented without the need for modification or support from the actual media players.

Claims

CLAIMS:

1. A method for reproducing media content, said method comprising the steps of: obtaining a playlist of plural media elements, associating each said media element with location information of a corresponding retrievable media content file; retrieving said media content files from the corresponding location, and reproducing said media content files.

2. A method according to claim 1, wherein said method is performed at a reproduction location of said content, and at least one said media content file is located at a local cache.

3. A method according to claim 2, wherein at least one further one of said media content file is retrieved from a source remote from said reproduction location.

4. A method according to claim 3, wherein said source comprises a cache formed at a location intermediate a master repository of said media content file and said reproduction location.

5. A method according to claim 3, wherein said step of retrieving further comprises the step of identifying a type of said media content file and passing said file to a type- compatible media player arranged at said reproduction location.

6. A method according to any one of the preceding claims, wherein said step of retrieving further includes a step of inserting a unique identification stamp upon one or more of said media content files.

7. A method according to any one of claims 2 to 6 wherein said method is performed by computer apparatus arranged at said reproduction location and said playlist is obtained from a location remote said reproduction location.

8. A method according to claim 3 wherein said retrieving further comprises storing a copy of said media content file in said local cache.

9. A computer readable medium, having a program recorded thereon, where the program is configured to make a computer device execute a procedure to reproduce media content, said program comprising: code for obtaining a playlist of plural media elements, code for associating each said media element with location information of a corresponding retrievable media content file; code for retrieving said media content files from the corresponding location, and code for reproducing said media content files.

10. A computer readable medium according to claim 9, wherein said medium forms part of said computer device and at least one said media content file is located at a local cache of said device and at least one further one of said media content file is retrieved from a source remote from said computer device.

11. A computer readable medium according to claim 9 wherein said code for retrieving further comprises code for identifying a type of said media content file and for passing said file to a type-compatible media player arranged in said computer device as said code for reproducing.

12. A computer readable medium according to any one of claim 9 wherein said code for retrieving further includes code for inserting a unique identification stamp upon one or more of said media content files, said stamp being related to at least one of said computer device or said code for reproducing thereby limiting reproduction of said media content files to said computer device or the particular instance of said code for reproducing.

13. Computer apparatus for reproducing media content, said computer apparatus comprising: means for obtaining a playlist of plural media elements from a location remote from said apparatus; means for associating each said media element with location information of a corresponding retrievable media content file; means for retrieving said media content files from the corresponding location, and a media player component for reproducing said media content files.

14. Computer apparatus according to claim 13, wherein said media content files are sourced from locations selected from the group consisting of a local cache formed within said computer apparatus and a location remote from said computer apparatus

15. Computer apparatus according to claim 14 wherein said means for retrieving comprises means for identifying a type of said media content file to thereby pass said file to a type-compatible media player selected from a group of media player components arranged in said computer apparatus.

16. Computer apparatus according to claim 13, wherein said means for retrieving further operates to associate a unique identification stamp upon one or more of said media content files to thereby restrict reproduction of said media content files to said computer apparatus.

17. Computer apparatus according to claim 16 wherein said means for retrieving associates a public key of said computer apparatus with a request for said media content files thereby enabling a remote server from which said files are sourced to encrypt said files with said public key prior to supply of said encrypted files to said computer apparatus to thereby limit reproduction of said files to said computer apparatus.

18. Computer apparatus according to claim 14 wherein said means for retrieving stores a copy of said media content file in said local cache.

19. A method of reproducing media content substantially as described herein with reference to any one of the embodiments as that embodiment is illustrated in the drawings.

20. Apparatus for reproducing media content substantially as described herein with reference to any one of the embodiments as that embodiment is illustrated in the drawings.

21. A computer program configured to perform a method according to claims 19.