PLAYLIST MANAGER

TECHNICAL FIELD

The invention relates to apparatus and methods for content management including, but not limited to, list management and recommendation engines. Embodiments relate to apparatus and methods for making recommendations based on user data with reference to expert data. Further embodiments relate to apparatus and methods for generating a user profile based on analyses of user data and particularly user music data. Further embodiments relate to playlist generators and methods for playlist generation.

BACKGROUND

Known systems for recommendations require a user to register interests so that a computer can automatically alert the user of content related to those interests.

SUMMARY

In one embodiment, a music recommendation apparatus configured to provide personalised content, including music, to remote users is provided. The apparatus comprising: a communication interface configured to receive user music list data from a remote user

terminal and a user music list store arranged to hold said user music list data; an expert music list store arranged to hold a plurality of expert music list data with respect to which the user music list data is processed; and a recommendation module configured to generate a music recommendation output to a remote user terminal in dependence upon processing of the user music list data having regard to at least one expert music list data determined from said plurality of expert music list data.

In another embodiment, a method of operating a music recommendation apparatus configured to provide personalised recommendations to remote users is provided. The method comprising: receiving user music list data from a remote user terminal and storing said user music list data; receiving expert music list data and storing a plurality of expert music list data; generating a music recommendation output to a remote user terminal in dependence upon processing of the user music list data having regard to at least one expert music list data determined from said plurality of expert music list data.

In another embodiment, a content management computer system configured to analyse individual music libraries to build personal profiles at least partially representative of individual users and to control delivery of content to individual user devices based on said personal profiles is provided. The computer system comprising: a music library analyser arranged to receive and process music library data including at least a music list indicating a plurality of tracks associated with an individual user; a track attribute store comprising a plurality of track attribute records each relating to a different track or version of a track, wherein a track attribute record comprises one or more attribute fields indicating a personal trait associated with listeners of the track or version of the track to which the record relates; a user profile store comprising individual user profiles each reflecting at least one personal trait of a relevant user; a processor operable to process a music list associated with an individual user having regard to, a plurality of records in the track attribute store to make a determination of prevailing personal traits of the user and to store results indicative of said prevailing traits in a user profile; and a content delivery system interface configured to allow

a content delivery system to access data of a relevant user profile if to personalise an aspect of content delivery to a device associated with that user.

In another embodiment, a music recommendation apparatus configured to provide personalised content, including music, to remote users is provided. The apparatus comprising: a communication interface configured to receive user music list data from a remote user terminal and a user music list store arranged to hold said user music list data; at least one reference list with respect to which the user music list data is processed; and a recommendation module configured generate a music recommendation output to a remote user terminal in dependence upon processing of that user's music list data having regard to each reference list; and a user profile module operable to build a plurality of user profiles each relating to an individual remote user and including one or more fields representative of the user's consumer behaviour.

In another embodiment, a list recommendation apparatus configured to provide adjustments to a list, including to remote users associated with the list is provided. The apparatus comprising: a communication interface configured to receive user list data from remote user terminals and a user list store arranged to hold said user list data; an expert list store arranged to hold a plurality of experts list data with respect to which individual user list data is processed; and a recommendation module configured to generate a recommendation output to a remote user terminal in dependence upon processing of that user's list data having regard to at least one expert list data determined from said plurality of experts list data.

In another embodiment, a computer system for generating a playlist comprising a plurality of compatible music tracks is provided. The computer system comprising: an expert playlist analyser for analysing a plurality of expert playlists, each expert playlist comprising a plurality of music tracks arranged into a synergistic sequence, to determine a relationship between the music tracks of the expert playlists; a music track storage device for storing a plurality of music tracks; a playlist generator for generating a playlist comprising a first music

track and further music tracks from the music track storage device, the playlist generator applying th.e determined relationships to the first music track and the tracks in the music track storage device to identify the further music tracks and to automatically construct a playlist of compatible tracks.

In another embodiment, a method of operating a computer system for generating a playlist comprising a plurality of compatible music tracks is provided. The method comprising: analysing a plurality of expert playlists, each expert playlist comprising a plurality of music tracks arranged into a synergistic sequence, to determine a relationship between the music tracks of the expert playlists; and generating a playlist comprising a first music track and further music tracks from a plurality of music tracks in the music track storage device by applying the determined relationships to the first music track and the plurality of music tracks to identify the further music tracks and to automatically construct a playlist of compatible tracks.

In another embodiment, a method of operating a recommendation apparatus configured to provide personalised recommendations to remote users is provided. The method comprising: receiving user list data from a remote user terminal and storing said user list data; receiving expert music list data from a plurality of experts and storing said expert list data; and generating a music recommendation output to a remote user terminal in dependence upon processing of the user list data having regard to at least one expert list data determined from said plurality of expert music list data.

In another embodiment, a computer readable medium comprising computer readable code for making recommendations is provided. The computer readable code for performing the steps of: receiving user list data from a remote user terminal and storing said user list data; receiving expert music list data from a plurality of experts and storing said expert list data; and generating a music recommendation output to a remote user terminal in dependence upon processing of the user list data having regard to at least one expert list data determined from said plurality of expert music list data.

In another embodiment, an apparatus for managing lists specific to a user is provided. The apparatus comprising: a processor for analysing the items of the list, said processor being configured to determine expert data which correlates to at least one item of the list, and for providing recommendations to the users based on the expert data for adjusting the list.

In another embodiment, an apparatus for managing music playlists of a user is provided. The apparatus comprising: a processor for analysing the playlist, for determining expert data which correlates to the playlist, and for providing recommendations to the user based on the expert data for adjusting the playlist.

In another embodiment, a computer system for determining playlist rules from expert data lists is provided. The computer system comprising: a processor for analysing the expert data lists in order to determine relationships between items of data within the list, for applying weightings to the determined relationships, and for determining playlist rules based on the relationships and weightings; and a storage device for storing the determined playlist rules.

In another embodiment, an apparatus for generating a list of items from one or more initial seed items is provided. The apparatus comprising: a processor for determining expert recommendations associated with the one or more initial seed items, and create a list of related items based on the expert recommendation.

In another embodiment, an apparatus for managing user lists is provided. The apparatus comprising: means for generating a user interface at a remote terminal for inputting the user list; an internet communications link for transferring the user list from the remote terminal to a list processor, the list processor for analysing the list, for identifying expert data from expert data stored in a storage device which correlates to the user list, and for transferring recommendations for adjusting the list to the user at the remote terminal over the internet communications link based on the expert data.

In another embodiment, an apparatus for managing user lists is provided. The apparatus comprising: means for generating a user interface at a remote terminal for inputting the user list; an internet communications link for transferring the user list from the remote terminal to a list processor, the list processor for analysing the list, for identifying expert data from expert data stored in a storage device which correlates to the user list, and for transferring recommendations.for adjusting the list to the user at the remote terminal over the internet communications link based on the expert data.

In another embodiment, a method for managing lists specific to a user is provided. The method comprising: analysing the list, determining expert data which correlates to the list, and providing recommendations to the users based on the expert data for adjusting the list.

In another embodiment, a method for managing music playlists of a user is provided. The method comprising: analysing the playlist, determining expert data which correlates to the playlist, and providing recommendations to the users based on the expert data for adjusting the playlist.

In another embodiment, a method for applying expert recommendations to personal collections of data is provided. The method comprising: analysing the personal collection of data to determine individual items which from the collection of data and characteristics of the collection of data, correlating the personal collection of data with expert data, and providing expert recommendations based on the expert data.

In another embodiment, a method of operating a computer system for determining playlist rules from expert data lists is provided. The method comprising: analysing the expert data lists in order to determine relationships between items of data within the list, applying a weighting to the determined relationships, and determining playlist rules based on relationships and weightings; and storing the determined playlist rules in a storage device.

In another embodiment, a recommendation computer is provided. The computer comprising: personal list organisation based on matched mentor, where organisation includes: match to mentor and one or more of recommendation of relevant new purchase, sample of existing list item, exploratory new item.

In another embodiment, an event recommendation apparatus configured to provide event recommendations to remote users is provided. The apparatus comprising: a communication interface configured to receive user list data from a remote user terminal and a user list store arranged to hold said user list data; an expert list store arranged to hold a plurality of expert list data with respect to which the user list data is processed; an event data store for holding event data; and a recommendation module configured to generate an event recommendation output to a remote user terminal in dependence upon processing of the user list data having regard to at least one expert list data determined from said plurality of expert list data.

In another embodiment, a method of operating event recommendation apparatus configured to provide event recommendations to remote users is provided. The method comprising: receiving user list data from a remote user terminal and storing said user list data in a user list store; receiving expert list data and storing a plurality of expert list data with respect to which the user list data is processed; and generating an event recommendation output to a remote user terminal in dependence upon processing of the user list data having regard to at least one expert list data determined from said plurality of expert list data.

The above embodiments may have any of the preferred features as set out in the dependent claims below.

BRIEF DESCRIPTION OF DIAGRAMS

For a better understanding of the invention and to show how the same may be carried into effect, reference will be made by way of example to the accompanying drawings:

• Figure 1 illustrates an embodiment of the invention;

• Figure 2 illustrates schematically an overview of relevant processes;

• Figure 3 illustrates schematically a server according to an embodiment;

• Figure 4 illustrates schematically a user application according to an embodiment;

• Figure 5 illustrates schematically a detailed process according to an embodiment;

• Figure 6 illustrates schematically user data;

• Figures 7A to 7C illustrate schematically a process and apparatus for analysing user data;

• Figures 8A to 8C illustrate schematically a process and apparatus for analysing expert data;

• Figure 9 illustrates schematically a recommendation process;

• Figure 10 illustrates schematically a recommendation module;

• Figures HA to HD illustrate schematically music data;

• Figures 12A and 12B illustrate schematically a server having a playlist generator;

• Figure 13A and 13B illustrate schematically a process for generating a playlist;

• Figure 14 illustrates schematically a process for analysing expert data for playlist generation;

• Figure 15 illustrates schematically a server of the invention for recommending events; and

• Figure 16 illustrates schematically radio data.

DETAILED DESCRIPTION

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

The invention relates to a recommendation server for providing a user with recommendations following analysis of the user data and with reference to a plurality of expert data.

An expert is considered to be a person with an extensive knowledge of a given subject who acts in the domain of the subject in some professional capacity. For example, with reference to music the term expert would include a DJ, a music producer, a professional musician, a music journalist or an entity operating commercially.

Figure 1 illustrates an overview of the elements of the invention. As illustrated in Figure 1 the main components are a server 10, at least one user device 20 such as a computer or an IP enabled set-top box, at least one user player 30 such as a MP3 player or MP4 player associated with the user device 20. The user device 20 is in communication with the server 10 via the internet 50. The connection may be either a wired or wireless connection. As illustrated in Figure 1 a media store 40 may also be provided. The media store 40 may be a separate server or may be provided at the server 10. In preferred embodiments, a plurality of media stores are present, and the system can recommend purchases from and/or provide connections to multiple ones of the media stores. In other embodiments, one of the user player 30 or the user device 20 may be present without the other.

Figure 2 illustrates schematically the process of the invention. A user's domain list 22 is transferred from the user device 20 to the server 10. The server 10 analyses the user domain list 22 with reference to a plurality of domain expert lists 12 stored at the server 10. Following this analysis the server 10 provides the user with a . domain expert recommendation 32. For example, if the domain is music, then the server 10 provides the user with a music mentor recommendation.

In a more specific example the user domain list may include details of a user's music library ("music list 22"). This is analysed with reference to a plurality of music expert music lists 12

and the results of the analysis together with music expert recommendations 32 are provided to the user at the user device 20.

In one example, the music expert results and recommendations 32 may comprise information such as the user's similarities with the expert, i.e. the tracks that the user is currently listening to from their list 12 that a music expert also has in their list 22 (organising data 32A), the hidden gems in their list 12, i.e. the tracks that the user is not listening to from their list 12 that a music expert recommends the user listens to (personalising data 32B), and expert recommendations, i.e. adjustments to the user's music list 22 recommended by the expert (recommending data 32C). An example of recommending data 32C is a recommendation that the user may wish to purchase one or more new music tracks. Accordingly, embodiments of the present invention assist users in organising and adding to their music collections in a manner which is personalised to the user.

Each of the music expert recommendations 32 (32A, 32B, 32C) may be divided up into three, or more, sub-categories such as recommendations that represent a strong match with the user's tastes (probable recommendations Al, Bl, Cl), recommendations that appear to match less strongly but may be taken up by the user (suggested recommendations A2, B2, C2), and recommendations which aim to encourage the user to explore different areas of music beyond their current determined tastes and spheres of interest (exploratory recommendations A3, B3, C3).

Figure 3 illustrates schematically components of the server 10 of the present invention. The server 10 comprises a server communication interface 500 for receiving and transferring communications. The server 10 comprises an expert list data extractor module 530 for extracting expert list data from web pages over the internet such as DJ and radio playlists. The extracted expert list data is then cleansed by an expert list data cleansing module 540 (using data cleansing techniques generally known to a skilled person) and processed in an expert list data processing module 550. Expert list data can also be input directly to the expert list data cleansing module 540 before being processed in the expert list data

processing module 550. Following processing of the expert list data it is stored in an expert list data storage module 560. The expert list data may be processed with reference to enrichment data stored in the domain knowledge storage module 575 of the enrichment engine 570 and/or with reference to other expert list data stored in the expert list data processing module 550. With reference to music, the domain knowledge storage module 575 is a music knowledge storage module 575 and may store data regarding a plurality of music tracks, such as track producer, whether or not the track was a hit, the beats per minute of the track, the composer of the track, etc. (explained in more detail below) and/or music facts/trivia data, etc.

User list data received via the server communication interface 500 from a user device 20 is processed at a user list data processing module 520. In this embodiment, the user list data is processed with reference to enrichment data stored in the storage module 575 of the enrichment engine 570 and with reference to expert list data stored in the storage module 560. Following processing of the user list data it is stored in a user list data storage module 510. User profile data which is determined from the user list data and other data is stored in the user profile module 590.

A library module 595 is associated with the user profile module 590, the user list data module 510 and the enrichment engine 570. The library module provides a suite of presentation and analysis tools using which the user list data and/or user profile data can be viewed and interpreted.

The server 10 also comprises a recommendation module 580. The recommendation module 580 receives inputs from the user list data storage module 510, the user profile module 590 and the expert list data storage module 560. The recommendation module analyses the user data provided from storage modules 510 and 590 with reference to the plurality of expert list data stored in storage module 560 in order to provide the user with relevant recommendations. The recommendations are provided to the user via the server communication interface 500. The recommendations may be provided to the user together

with or separately from fact/trivia data, which may or may not be relevant to the recommendations, from the music knowledge storage module 575 via the server communication interface 500.

Figure 4 illustrates schematically the components of a user application 100. According to this embodiments, the first time the user connects to the server 10 they agree to download the user application 100 to their user device 20. However, the user application 100 may also be provided to the user for application to the user device 20 through other means, such as the user application 100 may be provided on a storage device for transfer to the user device 20. In another embodiment, the user application is provided on a storage medium alongside content for consumption by the user, e.g. on a music CD or DVD or the like.

The user application 100 comprises an interface 180 to the user's device 20. The user application 100 also comprises a list extraction module 120 which is capable of locating user files on the user device 20 and extracting user list data from the user files. The extracted user list data can be stored at storage module 160 prior to transfer to the server 10 via the communication interface 140.

In one example, the user files are music files and the list extraction module 120 extracts user music list data from the user music files. Each music track has its own music file.

The user application 100 may also comprise a user customisation module 110 such that the user can set criteria to customise the recommendation service they receive from the server 10. User customisation data can also be transferred to the server 10 via the communication interface 140.

According to this embodiment, the user application 100 transfers all the user list data from the user files to the server 10 upon first connection to the server 10. However, upon second and subsequent connections to the server 10, this is not generally necessary. It is possible

for only data regarding changes to the user list data to be transferred to the server 10 upon second and subsequent connections.

The storage module 160 may store the entire user music list data which is extracted from the user music files. Then, when the user connects to the server 10, the list extraction module 120 extracts the user music list data from the user device 20, compares the extracted user music list data with the user music list data provided in the storage module 160 and determines whether there have been any changes to the user music list data. Then only the changes to the user music list data are transferred to the server 10.

In another example, the list extraction module 120 may extract the user music list data whenever changes are made to the user's music files, such as addition or deletion of a music file. These changes to the user music files are then stored in the storage module 160 for transfer to the server upon next connection to the server 10.

In this embodiment, it is the user list data which is transferred to the server 10 not the user files. User list data may be any data which enables the user files to be identified. For example, user music list data may be data which enables the music files to be identified in accordance with the format of the file. The user music list data may include, for example; the title of a music file (track), the artist of the track, the album to which the track belongs, and the genre of the track, etc. Therefore, it is not necessary for the whole user file to be transferred.

Since only the user list data is transferred to the server 10, not the user files, transfer of data from the user device 20 to the server 10 is fast when compared to transferring each user file. For example, user music list data regarding 1,000 tracks can be transferred to the server 10 in approximately 1 minute, depending on the connection available. In addition, by only transferring data regarding changes to the user list data upon second and subsequent connections to the server, the transfer of update data from the user device 20 to the server 10 takes less time.

User music data can be retrieved through an API (application programming interface) of music library software, such as: Windows Media Player™, Winamp Media Player™, iTunes™, etc. provided at the user device 20. The music library may also store music files as XML and Binary files so that user music data can be retrieved directly rather than via the API. User music data can also be retrieved directly from the metadata of each music file. Typically metadata will contain information such as; the name of the track, the name of the artist, the title of the album to which the track belongs, the number within the album tracklisting, the genre of the track, the year of the track, the file name, the file size, the duration of the track, the sample rate of the track, the beats per minute of the track and the rating. However, other data may be contained within the metadata and any combination of the above information can be retrieved and transferred to the server 10.

A user may have uploaded music files to their music library from CDs (compact discs). Not all CDs provide metadata for each track. In this instance one or more of track data, metadata for the track, and any desired further track data can be retrieved from a general music database, such as the storage module 575 at the server 10, or from a third party music library, such as provided by iTunes™, based on the CD's identifier.

Below is an example of user list data which can be transferred from the user device 20 to the server 10 upon connection to the server 10. This user list data comprises information regarding six music files, the user data of the six files is assembled together to form the user list data. It is to be appreciated that the data regarding any number of music files can be transferred and the user list data can be transferred in any format as required.

<OPS>

<OP AC= ¹¹ I" KY="8E0368A4763CEC63646461B7ED9A6ECF" AL="Aretha Franklin- Greatest . Hits" AR="Aretha Franklin" TR="Think" SQ="9" GE="R&amp;B" FN="D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\09 Think.mp3" YR= ¹¹ O"

DA="2008-04-27 15:48:09" FS="3332475" DU=" 138" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ I" KY="D8A6A4513096C7719301F8047FAB12F7" AL="Aretha Franklin- Greatest Hits" AR="Aretha Franklin" TR="The House That Jack Built" SQ="8" GE="R&amp;B" FN="D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\08 The House That Jack Built.mp3" YR= ¹¹ O" DA="2008-04-27 15:48:09" FS="3355692" DU="139" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ I" KY="DF00E7C08A9E2B2D78A7621DF2CE498D" AL="Aretha Franklin- Greatest Hits" AR="Aretha Franklin" TR="Save Me" SQ="7" GE="R&amp;B" FN="D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\07 Save Me.mp3" YR= ¹¹ O" DA="2008-04-27 15:48:09" FS="3359436" DU="139" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ I" KY="66D2E60110088DE15E058BD8188CD947" AL="Aretha Franklin- Greatest Hits" AR="Aretha Franklin" TR="Chain Of Fools" SQ="6" GE="R&amp;B" FN="D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\06 Chain Of Fools.mp3" YR= ¹¹ O" DA="2008-04-27 15:48:09" FS="3982620" DU=" 165" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ I" KY="5D9790ECD6765F9E1948D5F21331A7F2" AL="Aretha Franklin- Greatest Hits" AR="Aretha Franklin" TR="You Make Me Feel Like A Natural Woman" SQ="5" GE="R&amp;B" FN="D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\05 You Make Me Feel Like A Natural W.mp3" YR= ¹¹ O" DA="2008-04-27 15:48:09" FS="3871675" DU=" 161" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ I" KY="6D469542ABBC7F09BDA5D06785836390" AL="Aretha Franklin- Greatest Hits" AR="Aretha Franklin" TR= ¹¹ Dr. Feelgood" SQ="4" GE="R&amp;B" FN=" D:\Music\MP3\Aretha Franklin\Aretha Franklin-Greatest Hits\04 Dr. Feelgood. mp3" YR= ¹¹ O" DA=" 2008-04-27 15:48:09" FS="4778830" DU="199" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

</OPS>

Where;

AC = Action; "I" indicates that the music file was inserted into the user's music library, "U" indicates that the music file has been updated, and "D" indicates that the music file has been deleted;

KY = the hash key;

AL = the title of the album to which the music track belongs;

AR = the name of the artist;

TR = the name of the track;

SQ = the number at which the track appears in the album;

GE = genre of the track, for example Rhythm and Blues;

FN = the file name;

YR = the year the track was recorded (if known, if unknown YR = 0);

DA = the date (and, in one embodiment, time) which the music data was uploaded to the music library at the user device 20;

FS = the file size (in this embodiment in bites);

DU = the duration of the track (in this embodiment, in seconds);

SR = the sampling rate (in this embodiment, in Hertz [Hz]);

BP = beats per minute (if known, if unknown BP = 0);

RA = the rating;

PC = the playcount of the track (in this embodiment, since the last transfer of data);

SC = the skip count of the track (in this embodiment, since the last transfer of data) and;

ST = whether the track is streamed from another location, i.e. it is not located on the user's computer (if ST = 0 then the track is not streamed).

Not all this information may be transferred to the server 10, for example, if it is not provided in the music file. In this instance, the server 10 can enrich the data it receives from the user device 20 by reference to the music domain knowledge storage module 575 of the enrichment engine. The storage module 575 is a library comprising extensive amounts of data about a vast number of music tracks. Therefore, when music data regarding a track is transferred to the server 10, the server 10 can retrieve further information about the track, which was not transferred, based on a track identifier.

As stated above upon subsequent connection to the server 10 it is only necessary to transfer changes to the user data which are stored at the user device 20. Below is an example of user list data which is transferred upon subsequent connection to the server 10 and comprises only data regarding changes to the user's files. This string of data comprises information regarding six music files, two insertions (AC = "I"), two updates (AC = "U") which may be a changes in the playcount (PC) or the skip count (SC) and two deletions (AC = "D"). However, it is to be appreciated that data regarding any number of changes can be transferred.

<OPS>

<OP AC= ¹¹ I" KY="F6F361921C5BlB2F964D963496E5DB00" AL="Hearts &amp; Bones" AR="Paul Simon" TR="Allergies" SQ= ¹¹ I" GE="" FN="D:\Music\MP3\Paul Simon\Hearts &amp; Bones\01 Allergies.mp3" YR= ¹¹ O" FS="6712917" DU="279" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST= ¹¹ O ¹¹ A

<OP AC= ¹¹ I" KY="A353303D0FC7A5F2ED30CDF72DAACE51" AL="Hearts &amp; Bones" AR="Paul Simon" TR="Hearts &amp; Bones" SQ="2" GE="" FN="D:\Music\MP3\Paul Simon\Hearts &amp; Bones\02 Hearts Samp; Bones.mp3" YR= ¹¹ O" FS="8136073" DU="338" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ U" KY="9FDF1855EA6276CA5D0CCB04A3CA4761" AL="The Man Who Sold The World" AR="David Bowie" TR="Saviour Machine" SQ="6" GE="Rock" FN="D:\Music\MP3\David Bowie\The Man Who Sold The World\06 Saviour Machine.mp3" YR="1972" FS="5383415" DU="269" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ I" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ U" KY="2AF2CA066378F3CB19BCFA7E368BF7F6" AL="Blue Valentine" AR="Tom Waits" TR="Kentucky Avenue" SQ="8" GE="Alternative &amp; Punk" FN="D:\Music\MP3\Tom Waits\Blue Valentine\Kentucky Avenue.mp3" YR="1978" FS="6953062" DU="289" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ I" SC= ¹¹ O" ST="0"/>

<OP AC= ¹¹ D" KY="4A13C4757EE6843E3939397E761F00ED" AL="Pin Ups" AR="David Bowie" TR="Everything's Alright" SQ="5" GE="Rock" FN="D:\Music\MP3\David Bowie\Pin

Ups\05 Everything's Alright.mp3" YR="1973" FS="3560064" DU="148" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ I" SC= ¹¹ O" ST="07>

<OP AC= ¹¹ D" KY="02FF94C22E70067AB93F7A0F02E85601" AL="Blue Valentine" AR="Tom Waits" TR= ¹¹ A Sweet Bullet From A Pretty Blue Gun" SQ="9" GE="Alternative &amp; Punk" FN="D:\Music\MP3\Tom Waits\Blue Valentine\A Sweet Bullet From A Prett.mp3" YR="1978" FS="8085335" DU="336" SR="44100" BP= ¹¹ O" RA= ¹¹ O" PC= ¹¹ O" SC= ¹¹ O" ST="O"/>

</OPS>

Data enrichment using the most up to date music domain knowledge available to the enrichment engine 570 can also happen periodically for all or some of the track list data.

In one embodiment, the server 10 is able to identify the user based on one or more of; hardware device ID, serial number of the user device 20 or user player 30, user log-on ID (for a computer), or Mac address. In this instance the user may not be required to directly input registration data. The user identity is transferred to the server 10 together with the user list data and the server creates a user profile record. Alternatively, as illustrated in Figure 5 the user may be required to provide registration data, such as the user's name, contact details, date of birth, etc., in order to register with the server 10 (step S200). The registration data is transferred to the server 10 which creates a user profile (step S210).

The user identifier can be any form of a unique number/letter combination which is associated with the user such that all data received from the same user device 20 or user player 30 (or from the same sub-library in the user device 20 or user player 30) is reconciled with the same user records at the server 10. The user identifier is typically transferred to the server io at the beginning or the end of each data stream.

The user application 100 locates the user's music files (step S220), extracts the user music list data from the user music files (step S230) and transfers the user music list data (step S240) to the server 10. The user music list data is received at the server 10 and processed

(step S250). Following processing of the user music list data the server 10 extracts user profile data from the user music list data (step S260) and determines an appropriate mentor(s) for the user (step S270). Finally, the server provides the user with results and recommendations (for example, organising data 32A, personalising data 32B and recommending data 32C) following analysis of the user data with reference to expert data (step S280). The process then returns to step S230 at which point changes to the user music data (if any have been made) are extracted and transferred to the server 10.

Figure 6 illustrates schematically the user data which is transferred from the user application 100 to the server 10. The user data in its simplest form comprises a user ID and the user list data. User music list data comprises a list of track identifiers together with additional track data (if available). The additional track data may be, for example; the date the user last listened to the track, the time of day the track was listened to, whether the user skipped a track, etc. This type of data can point for example, to evolving music consumption tastes and behaviour of the user, which in turn reveals much about the user's likes, dislikes and lifestyle.

Figure 7A illustrates schematically the method of processing of the user list data and figure 7C illustrates schematically the apparatus for processing of the user list data. At step SlOO the user files are located and the user list data extracted from the user files. The user list data is then transferred to the server 10 at step SIlO. If the user has specified customisation criteria then this customisation data is also transferred to the server at step S120.

The user list data processing module 520 processes the user list data. The user list data processing module 520 can enrich the user list data (if required) using data from the enrichment engine 570. For example, data stored in the storage module 575 can be used to file gaps in the track data, i.e. based on the track ID further data about the track such as the producer of the track, the year the track was released, the sampling rate of the track etc. can be associated with the track ID to complete the user list data (if available).

The user list data is analysed to determine user preference data (step S130), user patterns data (step S140) and user context data (step S150).

The term 'user preference data' relates to data regarding the user's likes and dislikes which can be inferred following analyses of the user's music data. For example, whether the user likes Jazz, Blues and/or Rhythm and Blues (RnB) music, etc., the user's favourite artist, the user's favourite track, etc. In one example, the user's favourite artist is determined by the number of tracks the user has by each particular artist in their list and/or the playcount of tracks by each particular artist.

The term user pattern data means data about the user's listening patterns, such as how many times has each track been played, together with when it was played (date and time), the percentage of the user's music collection as been listened to, the percentage of artists in the user music collection which have been listened to, the total number of artists, tracks and albums, the average number of times a track has been played per day, week etc., the average number of tracks played per day, week etc.

The term 'user context data' relates to data regarding context in which the user listens to the tracks. For example, if fast beat tracks are played together between 1.00 p.m. and 2.00 p.m. on a weekday it may be inferred that these tracks indicate "gym music" - the context, whereas if fast beat tracks are played together between 10.00 p.m. and 1.00 a.m. on a weekend may suggest that these tracks indicate ""going out music" - the context, or if slow beat tracks are played together between 8.00 p.m. and 10.00 p.m. may suggest that these tracks indicate "dinner party music" - the context.

The user preference data, user patterns data and user context data can be derived directly from the user list data although typically the user list data is first enriched using data from the storage module 575.

In order to determine the user preference data, user patterns data and user context data, a preference processing module 522 analyses the user's list data to determine the user's preference data, a pattern processing module 524 analyses the user's list data to determine the user's pattern data and a context processing module 526 analyses the user's list data to determine the user's context data.

Processing of the user list data enables the user data to be expanded to include additional information about the user which has been derived from the user's data, as illustrated schematically in figure 7B. The user data now comprises the user ID, the user list data and analysed user data. Any or all of this information can be replicated into the relevant user profile record.

As well as inferring the user's favourite artist, the user preference processing module 522 can also determine weightings to be applied to each artist in the user list data based on the user playcount for each artist (which can be the playcount since the last connection to the server 10, the playcount for the last week, month or year, etc.). At its simplest, a score of the artist's relevance could be generated by adding up the number of tracks a user has in their user list data of a particular artist plus the number of times the user has played tracks belonging to that artist. This is illustrated in Table 1 below.

Table 1

However, other variables could be used to provide a score of each artist's relevance to the user. The score provides a measure of the relevance of each artist to the user; the higher

scoring artists are determined to be of more relevance to the user than the lower scoring artists.

One exemplary way to make the score more globally significant would be to factor ubiquity rating. A globally significant score can then be expressed to determine the overall importance of a given artist (or given track) to the user. When a ubiquity rating is applied to the scores expressed in Table 1, it is possible to identify slightly more obscure and potentially more significant artists which can then be used to more clearly characterise a user. In this way popular artists or tracks, which tend to appear in the user list data of a wide number of users, are de-emphasised in recognition of the fact that the appearance of such artists or tracks tends to reflect less about the user as an individual. This is contrary to known internet principles based on which competitive recommendation engines may function, such as the known collaborative filtering technique which tends to regard the most popularly consumed tracks as having the best recommendation potential.

Accordingly, in one example, the user list data processing module 520 may apply a ubiquity rating to artists in order to emphasize more obscure artists and to de-emphasise more popular artists. For example, well known artists such as Michael Jackson and Madonna are given a lower ubiquity rating since they are very popular artists and consequently are likely to appear in a high proportion of user's list data. Therefore, the fact that these artists appear in the user list data may not provide, in certain cases, much information about the user's overall tastes. However more obscure/specialist artists such as Seasick Steve, are given a higher ubiquity rating since fewer users may have them in their user list data. Thus, more obscure/specialist artists can provide more information about the user's overall tastes.

The number of tracks by each artist in a user's list data is combined with the playcount of those artists so that it can be determined whether the artist is actually significant to the user. For example, if a user has Seasick Steve tracks in their user list data, but never actually listens to tracks by Seasick Steve, then it is determined that Seasick Steve may not be as significant to the user, as if his playcount was high.

In addition, a ubiquity rating could be calculated with reference to the expert list data stored in the expert list data storage module 570 and/or with reference to user data of a plurality of other users. A calculation as to an artist's ubiquity rating is made across all the expert lists. However, the variance is then limited to within a defined range (e.g. 0.7 to 1.0) depending on the context. This is detailed in Table 2.

Table 2

Therefore, applying a ubiquity rating to the artists of Table 1, has increased the significance of the least well know artist (Seasick Steve) in Table 2. The new score is then applied to the user data in order to determine the importance of each artist to that particular user.

As well as (for example), enriching the data with reference to the enrichment engine 570 and determining the user's preferences, patterns and contexts data, the user list data processing module 520 further analyses the user list data with reference to expert list data stored in the expert list data storage module 560. Below is an example of a scoring system applied to a user music data in order to determine the types or genres of music that a user likes to listen to (e.g. Reggae, Blues, Jazz, etc.).

1) An expert creates a play list for each genre, the list includes key tracks that provide a good indication whether the user likes the genre of music (the expert lists are stored in the expert data storage module 560). Table 3 below is an exemplary Reggae expert list detailing 100 tracks. In this embodiment, there is at least one expert list for each genre. In addition there may be several expert lists for each genre, the lists having been prepared by different

experts. The expert lists may be amalgamated to create a master expert genre list for each genre. Alternatively, or in addition, expert lists may be ranked according to the extent they are representative of a particular genre;

2) User music data metrics are then determined with reference to each genre expert list to create a set of user metrics. The following are examples of user music data metrics;

2.1) the absolute track match count (i.e. a simple count of the total number of matching tracks between the user's music list data and each of the genre expert lists);

2.2) the total playcount (i.e. how many times a user has played any of the tracks within each list - for example, a user may have listened to any of the Reggae tracks detailed in Table 3 a total of 57 times);

2.3) the absolute artist match count (i.e. how many tracks in the user's music data belong to artists that appear in each of the genre expert lists);

2.4) the artist playcount (i.e. how many times a user has played any of the tracks belonging to one of the artists within each of the genre expert lists);

2.5) the artist-track match as a percentage of the total user music list data - for example, if the user owns 250 tracks from artists within a genre expert list and the user has 1000 tracks in total, then the user has as 25% artist track-match with that genre expert list);

2.6) the artist playcount against a total library playcount expressed as a percentage - for example, if the user has listened to tracks belonging to any artist within an genre expert list 300 times and the user has total playcount for their whole user music list data of 1000, then the user has a 30% playcount value against that genre expert list).

Table 3

Table 4 details results of a scoring system applied to user music list data comprising 1424 tracks and matched against three genre expert lists:

Table 4

In the disclosed embodiment, the user's tendency toward different genres is assessed and recorded in the user's profile, for example by ranking the user's top 5 or 10 genres. From the results illustrated in Table 4, it can be inferred that the user is a big Rap fan, quite likes Reggae and owns but does not listen to much Blues music.

Following processing of the user list data the user list data is stored in the user data storage module 510. The user data can be processed and expanded such that the user data comprises, as in illustrated in Figure 9, user ID, the user track list including associated data,

analysed user data (such as user preference data, user pattern data, user context data and enriched user data) and inferred user data (such as user's genre, user's age, newspaper read by the user, etc).

User profile data is extracted from the results of the processing of the user list data and stored in the user profile data module 590. Figure 7C illustrates schematically an example of user profile data. The user profile data may comprise any one or more of the following categories of data: User ID; Registration Data; Declared Data; Analysed Data; Inferred Data; and Customisation Data.

The User ID may be, as stated above, the user's hardware device ID, the serial number of the user device 20 or user player 30; the user log-on ID (for a computer), or the user's MAC address. In addition, the user ID may be an identifier assigned by the server 10.

The category Registration Data may only exist if the user is required to enter data upon registration with the server 10. In some embodiments, the user may not be required to enter registration data, in which case the user profile will not contain a Registration Data category. The Registration Data category comprises any information provided by the user upon registration, such as their name, address, email address, telephone number etc. Since the user has provided this data, it is assumed to be correct i.e. known data. In addition, the Registration Data may contain information such as, how the user arrived at the server 10. For example, if the newspaper the Mail on Sunday™ was providing a free CD of Robbie Williams' tracks and upon use of the CD in the user's computer, the user is directed to the server 10, the Registration Data may comprise the partner data (i.e. Mail on Sunday™) and the Campaign data (i.e. Robbie Williams™). In this instance, the user may not be required to provide any registration data, but the User Profile may still contain a Registration Data category detailing the Partner and Campaign through which the user arrived at the server 10. The Registration Data may also contain the date the user initially connected to the recommendation server 10.

The category Declared Data may comprise any data which has been declared by the user, and thus can be assumed to be correct. The server 10 may request information from the user periodically, such as 'How old where you when John Lennon was shot?', 'what is your favourite driving track?', etc. The user's responses to these questions are then stored in the Declared Data category.

The categories Analysed Data and Inferred Data both comprise information deduced following analyses of the user's data. However, the Inferred Data is considered to be less trustworthy than the Analysed Data, thus the Inferred Data has an associated likelihood. One example of Analysed Data may be the user's current favourite track (or top 5 ranked tracks), which can be deduced following analyses of the user's playcount. The track with the highest playcount may be regarded as the user's current favourite (with the ranking determined based on the decreasing playcounts). This type of data is considered to be reliable and does not have an associated likelihood. Another example of Analysed Data may be the user's current favourite artists (or top 5 ranked artists) which can be determined following analyses of all the artists in the user's list data and the user's current playcount. It may also be possible to determine the user's all time favourite track following analyses of the user's playcount history.

An example of Inferred Data, may be the user's age (if not declared upon registration), which is deduced following analyses of the user's data. For example, in its simplest form, if 80% of the user's music was released in the 1980s, it may be deduced that the user was a young adult in the 1980s and thus is in the range of 30-36 years old today. Since this inference is less reliable than directly deduced from the user's playcount, etc., it is provided in the Inferred Data category along with an associated likelihood score, which may be provided as a percentage. The likelihood score indicates how reliable the inference is considered to be. Then over time, as more information is obtained about the user, a more detailed profile of the user may be constructed and the likelihood increased. Another example of Inferred Data may be user's activities data. For example, following analysis of the user's list data it may be inferred that the user has a certain amount of "gym" music and thus is into sports, or has a

certain amount of dance music so likes clubbing. In another simplistic example, the user list data may comprise tracks which they obtained from a cover mount of The Sunday Times newspaper. From this it can be inferred that user is a reader of The Sunday Times newspaper. In another example, the user list data may comprise tracks by the Teletubbies™ or Postman Pat™ from which it can be inferred that the user has young children, etc. If the children's tracks have been added or played recently, it is possible to also infer the child's age range.

Data can also move within the categories, for example, it may be deduced that the user is 33 year old following analyses of the user's list data. At a later date, the user may confirm their age in response to questions etc. by the server 10. The user's age is the removed from the Inferred Data category and stored in the Declared Data category, as it is now considered to be correct.

The Customisation Data contains any information provided by the user to customise the recommendations or playlists (as described in further detail below). For example, the user can specify that they do not wish to receive recommendations for a particular artist(s), and/or genre(s) and/or era(s), etc.

The user data may be stored in any one of the User Profile categories depending on how it is obtained, i.e. whether is it declared, analysed or inferred.

Examples of user profile data fields include, without limitation: user name, user date of birth, user age, user address, user's favourite artist (and/or ranked artists), user's favourite track (and/or ranked tracks), user's favourite genre (and/or ranked genres), user's listening patterns, mood indications, activity indications, customisation data provided by the user, Touch Points or an indication of how the user came to the system (such as The Sunday Times, and The Mail on Sunday BMW Campaign), Likely Age of the User (+/- 3 Years, if not declared), Likelihood Of Likely Age (given as a rating out of 10, where 10 indicates very likely), Gender of User, Likelihood of Gender of User (given as a rating out of 10 where 10

indicates very likely), Primary Typology of User (such as Thrill Seeker), Secondary Typology of user (such as Trendsetter), Similar Users (which is an indication of the total number of users within a 5% margin of deviation who have similar traits), mapping of the or each user typecast to conventionalism, Likely Occupation of User, Likelihood Of Likely Occupation (given as a rating out of 10, where 10 indicates very likely), Likely Income Bracket of User, Likelihood Of Likely Income Bracket (given as a rating out of 10, where 10 indicates very likely), etc.

The User Profile may also use information obtained form the user's avatar, if one exists. An avatar is a user's computer representation of himself/herself and may be a three- dimensional model used in computer games or a two-dimensional picture used on internet forums and other communities. It may also be automatically generated by the User Profile (if required) and/or then manipulated by the user. Prompting for user responses to avatar features is one way of verifying inferred data in the user's profile. Such an example would be the generation of a MySpace 'style' profile whereby the user is able to influence and control his profile according to his interests and requirements.

The Primary and Secondary Typology of User classifications (or further typologies) are assigned based on the analyses of the user's music. For example, if the user's music tends to have early music that highly correlates to later success, the user may be classified as a "Trendsetter". However, as no two users are likely to have the same taste and invariably users tend to have several different types of music, the user classifications are constantly changing as a result of constant analyses of their music and other user's music. A user is assigned a Primary and Secondary Typology, as no one user is likely to fall exactly within one classification. The Primary and Secondary Typology are used to try to understand the user's taste and to make more acceptable recommendations.

In one embodiment, the user data storage module 510 stores data regarding multiple users. The user data storage module 510 may comprise library tables which store full information about the user's music. For example, the user data storage module 510 may comprise

library tables associated with each user such as a Library Track table which can store tens of thousands of rows per user (i.e. the user's track list). This Library Track table can be heavily normalised to reduce storage space by storing identifies of common items like artists and tracks. For example, instead of storing the full text "Rolling Stones" against the user's library, an identifier (such as 8712) would be stored pointing to an artist's table that contains the full text "Rolling Stones".

The user data storage module 510 may also comprise library tables, such as a Library Playcount table and a Library Skipcount table which provides a historical picture over time of what tracks the user is playing or skipping. The Library Playcount table and the Library Skipcount table are useful in inferring a user's tastes, including how their tastes change over time and in particular what they are listening to and what they are avoiding right now and what they were listening to and what they were avoiding previously.

The user music data storage module 510 may also store metrics tables which contain analysis of each user's libraries (for example the results of the preference, patterns and context analysis). A Library List Metrics table may have one row per library per artist and store information for each artist in the user's library, such as the number of tracks in the user's list by that artist or the playcount for that artist. The Library Track Metrics may have one row per library per track and store track level information.

The user list data storage module 510 may also store data regarding recommendations which have been sent to the user so as to avoid the recommendation module 580 recommending previously recommended tracks to the same user.

Figures 8A illustrates schematically a method for processing the expert track list data and figure 8C illustrates schematically apparatus for processing the expert list data. Expert list data, for example Pete Tong's playlist for the last 15 years, is extracted from web pages over ,the internet by the extractor module 530 (step S300). The extractor module 530 extracts as much additional information as possible when extracting the expert list data. For example,

for DJ playlists and radio set lists the extractor module 530 identifies where possible the version or mix of the track, the label that the track came out on, who played it, when they played it and what special feature it was part of, if any (e.g. No. 1 dance track that week).

The expert list data is then cleansed at the cleansing module 540 (step S310). In order to cleanse the expert data, the cleansing module 540 tidies up artist and track names to avoid duplicates where possible. The expert list data can also be input directly to the cleansing module 540 such as expert lists prepared directly by the expert for use in the server 10.

The cleansed expert list data is then passed to the expert list data processing module 550 for analysis (step S320). In order to analyse the expert list data the processing module 550 uses data from the enrichment engine 570. For example, the processing module 550 attempts to fill any gaps in the track data with data from the music domain knowledge store 575. As discussed above with reference to the user list data, this storage module 575 comprises a vast amount of track data about a plurality of tracks.

The expert data has thus been processed to provide further and enhanced information. Figure 8B illustrates the expert data, which comprises an expert ID, an expert track list and the analysed expert data.

The expert list data is preferably also processed and analysed with reference to expert list data held in the expert list data storage module 560 i.e. other expert list data. This may be expert list data provided by the same expert in a different list or by different experts in different lists.

Expert list data can also be provided directly to the cleansing module 540. An example of such expert list data may also be an expert's own music library.

The expert data can be scored relative to other expert data, inversely proportional to the frequency of individual entries occurring in the expert list. For example, Table 5 below

details four experts (mentor lists) that can be used to match a user to a mentor, or as part of a more sophisticated matching process.

Table 5

Because the most frequent artist (The Smiths) occurs three times in the four expert lists, it has the lowest artist score (1), whereas the artists that occurs just once in the four expert lists has a score of 3. The latter tends to indicate more about the expert. A similar inverse scoring system applies to tracks. The results of the expert data analysis by the processing module 550 are stored in the storage module 560. However, the scoring applied is flexible

and can change and evolve with expert and/or user's behaviour influencing ratings individually.

Following processing of the expert list data, the expert data comprises, with reference to Figure 9 an expert ID, an expert track list including associated data, the analysed expert data which can incorporate enriched expert data and inferred expert data including the results of the analysis of the expert list data with reference to other expert list data. Inferred expert data may be associated with a likelihood store.

An expert may have more than one expert track list. For example, an expert may have prepared a Blues track list, a Jazz track list, a RnB track list, a 1980s track list, a top 100 favourite songs track list, a Chillout track list, etc. Each of these different expert track lists would have a unique ID, although in preferred embodiments it is still associated with the creating expert ID.

Figure 9 illustrates schematically the recommendation module 580. In order to make recommendations to a user, the user's list data which has been processed by the user list data processing module 520 is input to the recommendation module 580 together with expert data (of a plurality of experts) which has been processed by the expert list data processing module 550. In addition, the user profile data from the user profile module 590 is input to the recommendation module. Following analysis of the input data, the recommendation module 580 can provide the user with music expert recommendations.

The recommendation module 580 compares the processed user data and user profile data with the plurality of processed expert data to identify correlations. The recommendation module 580 then identifies an expert based on the or each relevant correlation. Note that since both the user and expert list data has been processed to include analysed and inferred data, the correlation may not simply amount to determining a straight forward count based match between the artists and tracks in the user and expert list data. For example, as stated above, the playcount, skipcount and weightings applied to the user list data determine

which artists and tracks are most relevant to the user and this determined data can be used together with the list data determines the most relevant expert for the user. Having indicated the various fields in the user data and the expert data which are available for this expert identification process, a skilled reader will appreciate that precisely which correlations are applied to identify an expert as a user's mentor is a configurable aspect of the system.

The expert data processing module 550 may also analyses the expert data in order to generate an Expert Profile. The Expert Profile may be determined using all the playlists provided by a particular expert, or a separate Expert Profile could be generated for each expert playlist. The Expert Profiles are similar to the User Profile illustrated in figure 7C. The Expert Profiles may comprise the following categories of data; Expert ID (or Expert Playlist ID if appropriate), Expert Declared Data, Expert Analysed Data and Expert Inferred Data. The Expert Declared, Analysed and Inferred Data may deduce in a similar way to the user Declared, Analysed and Inferred Data described above.

A correlation between a user profile and an Expert Profile can also be used in order to determine mentor(s) for the user. For example, the User's Profile Data may indicate the deduced user's top 10 tracks, which could be compared with all the experts' deduced top 10 tracks to determine the most relevant Mentor(s).

The recommendation module 580 can then provide the user with a selection of mentors, based on the results of the analyses. The mentor may be a music expert and/or a celebrity, and is likely to be of personal interest to the user. For example, the user may have a 90% match with Annie Lennox, an 85% match with David Bowie and a 70% match with Pete Tong. Accordingly, the recommendation module 580 can provide the user with a choice between the three experts and the user selects which they would prefer as their mentor.

The system can be configured to cycle through mentor options likely to be personally interesting to the user. Further, the system may be configured to cycle through different

correlation mechanisms to generate mentor options likely to be of interest for different reasons.

Since the user list data is constantly being updated (whenever changes to the user music are transferred to the server 10), the results of the recommendation module 580 may change over time. Therefore, the recommendation module 580 can provide the user with new choices for mentor at intervals, such as weekly, monthly, each time the user connects to the server 10, etc. In addition, the user can experiment with each different mentor.

The recommendation module 580 can provide the user with information such as "the following songs in your music list, which you have listened to recently are also in the Mentors list" (similarity with expert 32A), "the following songs in your music list, which you have not listened to recently are recommended by the Mentor" (experts hidden gems 32B), and "the Mentor recommends that you listen to the following songs, which are not in your music list" (recommended adjustments 32C). Together with the recommended adjustments 32C the recommendation module 580 can be configured to direct the user to a media store from which the tracks can be purchased. The media store 40 could be provided at the server 10 or remote from the server 10.

For each of the three types of recommendations 32A, 32B, 32C the recommendation module 580 can provide the user with recommendations which, based on the analysis of the user's list data and the user's profile data, it is inferred that (i) the user is most likely to adopt (most relevant recommendations Al, Bl, Cl), (ii) the user might adopt (suggested recommendations A2, B2, C2) and (iii) recommendations which may result in the user expanding their music tastes if adopted (exploratory recommendations A3, B3, C3). The recommendations may or may not be accompanied by facts/trivia from the storage module 575 and may or may not be taken up by the user without necessarily restricting functionality of the services.

Figure 10 illustrates schematically the recommendation module 580. The recommendation module 580 comprises a configurable bias module 582 and a recommendation rules module 584. The expert list data, user list data and user profile data are input to the recommendation rules module 584 which outputs the recommendations to the user. The configurable bias module 582 can provide a bias to the recommendation rules 584 in accordance with inputs directly to the server 10. For example, the configurable bias module 582 can bias the recommendations so that the recommendation module 580 only recommends songs according to any attribute of the track, for example, from a particular era or from a particular genre such as dance, or form a particular category of expert. Alternatively, certain recommendations or types of recommendations can be set to a particular statistical bias.

The recommendations may also be adjusted in accordance with data from the user profile module 590 such as information regarding recommendations that have already been made to the user (so as to prevent the same tracks being recojnmended repeatedly), the inferred user's likes and dislikes, and the user customization data, or how the user has responded to previous recommendations, i.e. whether they have listened to, purchased or ignored them. Thus recommendations can take account of user's tastes, context, facts, social acceptance considerations and the like.

The server 10 also comprises a library module 595. The library module 595 enables an administrator with access to the server 10 various views of data stored in the user list data storage module 510 and the user profile module 590 in order to gather data about the user and their preferences, whether actual or inferred. This data may be used for reporting functions and/or market research if the user's permission is granted. In some cases the user data may be used anonymously.

Figures HA, HB and HC illustrate an exemplary table of data stored in the music domain knowledge storage module 575 and examples of how applying that knowledge across user

list data and/or expert list data can lead to indications and inferences about the user, for inclusion in the user profile. Figure HD is a key for Figures HA to HC.

The tables are used on a per a song basis to track a user's tastes and produce a chain of inference that leads to unique profiling both on an individual and group basis - be it niche or mainstream by many different measures, i.e. by genre, by mood, by activity, etc.

The first table in figure HA has the following headings; unique \υ ^assigned to each track), Artist (the name of the artist), Song (the title of the track), Facts, which are subdivided into several categories, such as; Album (the album title), Metadata Year (the Year the album was released), Year (the year that the track was originally released), Hit (whether the track was a hit - could be country or genre specific), Chart Position (the highest chart position the track achieved - can be country or genre specific), Primary Penetration (awareness of the hit) and Signifier.

For example, the album "Best of the 50s" was released in 2003 so would have a "Metadata Year" of 2003. However, each track in the album would have being originally released in the 1950s so would have a "Year" the track was originally released, for example, Reet Petite by Jackie Wilson was originally released in 1957, so the "Year" for this track would be 1957.

There may be a separate Unique ID database matching each track to a Unique ID for the track, in which case the columns "Artist" and "Song" may not be required in table HA. The Unique ID table may be stored at the storage module 575, such that track data received from users and experts can be referenced using the Unique ID database in order to assign the unique ID to each track. The Artist, Song, Album and Metadata Year can be obtained from the list data, in some instances this data can be retrieved from metadata encoded in the file name. As explained above, if for example, the Artist, Song, Album and/or Metadata Year are not available from the list data, and then it can be retrieved (if available) from the storage module 575. The storage module 575 may comprise a plurality of tables/database

each associating data, such as the Metadata Year/Year/Hit etc. with the appropriate unique ID.

The Year of the track may also be available from the list data. If not, it can be retrieved from a Year table/database at the storage module 575 associating the Year with the appropriate unique ID. The Year and Metadata Year data of the entire user list data can be used to infer the user's peak interest and infer information. For example, if.75% of the user's music comprises songs which were released in the 1980s (i.e. the Year within the 1980s) then it can be inferred that the user was a teenager/young adult in the 1980s etc.

The Metadata Year and Year provide a snapshot of the peak interest of the user, by week, by month, by year or all-time, which is aggregated over the user's entire music collection.

Whether the track was a Hit is signified with y = yes or n = no and can be determined with reference to a Hit tables/database stored at the storage module 575. The Hit table comprises a plurality of predefined results, Hit = y or n, which have been determined with reference to the highest chart position of the track as compared with a threshold. For example, if the threshold is set as a chart position of 10, then a track which reached a chart positioned equal to or lower than 10 (1-10) is considered to be a Hit = y, whilst any track which has a chart position greater than 10 (11 or more) is not considered to be a Hit = n. The storage module 575 may also comprise a Chart Position table/database, which associates the chart position of the track with the Unique ID. As stated above, the Chart Position can be country or genre specific. For example, a song may be a Hit in the US, but may not have been a Hit in the UK or vice versa, or a song may have been a Hit on the RnB chart, but not on the Pop chart, etc.

The Primary Penetration is an indication of the relative popularity of the track and is provided as a normalized score (out of 1000). It is periodically calculated and changes over time. The Primary Penetration may be calculated by determining the number of users who have a specific track in their list data. The track which appears in the highest number of

user's list data is scored 1000 and the score of all the other tracks are determined based on how many users have each track on a sliding scale from the most popular track which scored 1000.

The Hit, Chart Position and Primary Penetration data of the entire user list data can be used to infer the user's hit/rarity ratio for each user which indicates the user's preferences. For example, by examining the user Hit, Chart Position and Primary Penetration data, it can be determined whether the user predominantly listens to "popular" music or prefers more specialist music etc. It is also possible to infer information about the user's tastes and the spread of their tastes.

The storage module 575 may also comprise a Signifier table/database, which associates data about the track, such as whether the track is a sound bed, was used in a TV advert or a TV theme tunes, with the Unique ID. If the track does not have a Signifier, then the table is marked n. The Signifier data of the entire user list data can be used to provide special significance to tracks that are exceptionally indicative of for example a user behaviour/tastes/age/viewing habits/newspaper/media purchasing behaviour and the like.

The Facts about each track may be populated using data from the expert list data or with data provided directly to the server.

In this embodiment, the table in figure HB has the following headings: unique ID (as discussed with reference to figure HA); Action Time Vision, which in this example is subdivided into Primary ATV, Secondary ATV and Typicality of Primary, Primary Mentor and Activity.

The Primary and Secondary ATV indicator indicates a general listener mood or listener activity associated with the track, for example, whether the track is considered to be Angry, Gym, Optimistic, Chill, Dinner Party, Walking the Dog, etc. The storage module 575 may comprise an ATV table/database, which associates data about a track with the Unique ID. The Primary

ATV is considered to be more relevant that the Secondary ATV. These listener mood and/or activity indicators may be pre-determined by experts.

The Typicality of Primary is an indicator out of 10 as to the strength of the determined ATV indicator. For example, the strength may be considered to be poor if the ATV is obtained from an unreliable source, and may be considered to be high (8 or 9) if the source of the ATV is reliable, 10 being the most reliable.

The Action Time Vision data of the entire user list data can be used (together with other data) to infer the user's strongest instances of musical listening by action, time and vision. For example, following analysis of the user's music it may be inferred that the user primarily listens to music whilst at the gym, since the majority of the music which they have listened to is provided in the Primary ATV as gym music.

The Primary Mentor column indicates a mentor associated with a track. The Mentor may be assigned to a track by an expert or may be assigned as a result of the track appearing in the Mentors (experts) list data. The storage module 575 may comprise a Mentor table/database, which associates one or more Mentors with each track.

In one embodiment, potential user Mentors may be determined by summing the Mentors, associated with each of the user's tracks. For example, the three most commonly appearing mentors may be provided to the user as potential Mentor, the user being able to select which of the options they would like to be their Mentor.

The storage module 575 may comprise an Artist event table/database, which associates data about the artist, such as whether the artist is touring, whether the artist has won any awards, whether the artist has a new album out, whether the artist is appearing on TV, etc. with the Unique ID.

The Artist event data of the entire user list data can be used to infer the influence of current activities in the market place. For example, whether a song has recently appeared in a lot of radio programs, has been purchased by users and if so, by how many users and which "types" of users.

The table in figure HC has the following headings in this embodiment: unique ID (as discussed with reference to figure HA); Media, which is subdivided into Radio, Printed Media and TV, each of which is further sub-divided in Overall, Mainstream and Niche, and Media Profile and Level of Hit. Overall, Mainstream and Niche refers to the media, for example was the track played on a mainstream radio station or a niche radio station, etc.

The Media categories indicate what media the tracks has appeared in. For example, a Radio program or station that played the tracks (e.g. Radio 2), a Newspaper that prints an article about the track/artist/album (e.g. The Guardian) and a TV program on which the track/artist appeared (e.g. Later with Jools Holland). This data may be stored in a Media table/database at the storage module 575.

The Media data of the entire user list data can be used to infer overall, mainstream and niche profiling within different media, by different weightings according to the purpose and desired analysis. For example, a user with Seasick Steve in his collection may score highly as a niche user, as both a Later with Jools Holland and Late Review viewer, a Mojo magazine and Sunday Times reader and a 6Music listener. This would be an example of a valuable chain of inference for profiling and research purposes on both an individual and group basis.

The Media Profile suggests that the user may be most likely to read The Guardian as a top rated (inferred) media source for that user.

The Level of Hit indicates whether the track was a universal hit or whether it was a hit in its genre or within a specialist field. Again, this data can be stored in a Level of Hit table at the storage module 575.

The tables illustrated in figures HA to HC can form one table. In addition, the tables may comprise additional or different information or different combinations of information. In another embodiment, the information in these tables is held across a number of stores within the system. The information in the tables of figures 11 A to HC are provided for illustrative purposes only and are not limiting.

Referring back to figure 10, following recommendations to the user, the user's response to the recommendations can be monitored and transferred back to the recommendation module 580. The user's responses can then be used to update the user profile module 590. For example, if the recommendation module 580 recommends that the user purchase a track and the user does purchase the track then this information is transferred back to the recommendation module to update the user's profile. In addition, if the user does not purchase the track, this information is also transferred back to the recommendation module. If the user explores a recommendation but elects not to purchase in the end, the user's interest in the track may be noted. The above principle may apply to any user response to the system. The recommendation module 580 can also provide the user with questions, responses of which can be transferred back to the recommendation module and stored in the user profile module.

As stated above, after an initial download of the user list data upon first connection to the server 10, updates to the user list data are transferred to the server upon each subsequent connection. The constant monitoring and updating of the user list data as well as recording of the user's history, enables a more accurate user profile to be formed in the user profile module 690 to more clearly identify the user's preferences as well as tracking evolution of the user's changing user profile attributes over time.

Figure 16 illustrates a table of data which may also be stored in the storage device 575. The exemplary table illustrated in figure 16 can be used in order to determination the most appropriate medium to advertise to certain types of user. For example, the table of figure

16 comprises the following headings; Radio Station (may also contain other information, such as Video Channel etc.), Name, User, Typical Tastes, Track Match, Typology, How Often (which represents the number of hours pre week the user listens for), When (which represents when the user listens, for example weekdays 6.30-9.00, or Saturday morning), Who (which represents who the user listens to), What (which represents what radio station the user always listens to) and What Other (which represents what other radio stations the user listens to).

The Typologies may be, for example; T26 - Meat and 2 veg'er, T31 - Noticer, T36 - Professor, T50

- Watercooler, T52 - Wool-dyer. These Typologies may have the following definitions;

T26 - tends not to be bothered about what is dictated to them yet without being so staid that there is no room for something that has proof that it fits in with their tastes. Will give a very limited window of opportunity to something that is 'supposed to be good'.

T31 - tends to observe early what is likely to happen.

T36 - tends to picks up indicators and apply the talking points and background narrative to go with and expand a trend. Good at repeating media stories that bear retelling.

T50 - tends to enjoy experiences that can be shared, prefers mass media events that can generate talking points and commonality rather than demonstrating a particular streak of personality and preference themselves.

T52 - tends to know what they like and like what they know, resistant to change and is best marketed to via the selling back of their memories.

These typologies are provided for reference only and are not limiting.

PLAYUST GENERATOR

Figure 12A illustrates the server of Figure 3 further comprising a playlist generator module 585. Similar to the recommendation module 580, the playlist generator module 585 receives inputs from the user profile module 590, the user list data storage module 510 and the expert list data storage module 560. The playlist generator module 585 can generate playlists for the user based on statistical analysis of expert list data. For example, by determining relationships such as which tracks are played together in various circumstances.

The tracks in the constructed playlist can be tracks in the user list data storage module 510 and/or tracks which are not in the user list data storage module 510 (tracks that the user may wish to purchase). The playlist generator module 585 uses processed expert list data in the expert list data storage module 560 in order to generate the playlist. The playlist can be generated based on a specific music track (item seed) selected by the user, or the server, such as the start song, a user's favourite song or a specific topic, such as Mexican dinner party, angry, driving or similar.

The playlist generator 585 arranges the tracks into a sequence which enables the music to be played to an optimum, such as tracks that work well together. The sequence may be similar to for example, the order in which a DJ would play a plurality of tracks for optimum effect, or the order in which tracks are organised in an (compilation) album. For example, systems of the prior art can generate playlists by performing a random shuffle of tracks that are stored in the user's music data. However, such shuffles do not consider the music of each track and therefore may not play the tracks to their optimum. For example, if a user has several different types of music in their music library, which is normally the case, these tracks may not go together when played one after the other as a result of a random shuffle. For example, a fast beat (gym) track may not be optimised when followed by a classical (relaxation) track. Other prior art lists tracks which frequently appear together in the same library.

Figure 13A illustrates the generation of a user playlist (a sequence of music tracks) based on one or more seed item (seed track). At step S500 the user or server selects one or more seed items, (e.g. by directly selecting a track or by selecting a theme which maps onto a seed track). Optionally, an instruction for the sequence to begin, contain or end with the one or more seed items can be provided at step S510. The length of the user playlist (in time or number of tracks) is set at step S520. The length can either be selected by the user, or can be a default length which is predefined. Optionally, excluded items can be identified, such as songs/artists that the user would prefer not to be part of the playlist at step S530. In

addition, a measure of randomness can be provided to offer guidance as to the acceptable deviation from the optimum sequence can optionally be provided at step S530.

Once these parameters have been set, the server 10 generates a user playlist (sequence of tracks) based on the one or more initial seed item. In order to generate the user playlist the list of seed items is expanded to a meaningful set of highly related item-sets at step S540. This step may not be necessary if the initial list of seed items is of a significant enough proportion relative to the desired sequence length. If it were required then the set of highly related item-sets would normally need to be expanded to a total item length of approx 30- 40% of the final required total. Next the excluded items are omitted unless there are no other meaningful options available. The degree of randomness has a relatively low effect during this step.

During this and the next step (step S550) other items are automatically excluded and/or given a lower relative weighting. Typical reasons for this are to provide a significant degree of variety by excluding overly similar items by e.g. the same artist or tracks on the same album. In addition, tracks which have been recently included in playlists are de-emphasised and then over time the de-emphasis is weakened as the period since the track was recommended is increased. This de-emphasis prevents the recommendation of the same tracks multiple times to a user.

The list of seed items is then expanded further at step S560 to include a list of n items related to the expanded list of seed items, influenced by the requested degree of randomness and excluded items in the exclusion list. The number (n) of items in the list is expanded, is a function of the degree of randomness required and the final desired length of the playlist. The purpose is to provide a significant set of items and item-sets from which to build a final sequence.

The final step (step S570) in this process is to generate the final user playlist from the expanded seed list. The emphasis at this point is to produce an optimum sequence of items

from the list. Depending on the length and quality of the seed list at this step a number of different approaches can be taken.

Ultimately the approach taken to generate the sequence is determined by the time available to generate the sequence. Given enough time generic algorithms can be employed although in reality this can take longer than is generally acceptable for the generation of sequences of items. Therefore the favoured approach is to initially generate item-sets (sequences) of as a great a length as possible and then to connect those item-sets in the most optimum sequence in the time.

In preferred embodiments, the playlist generation is based on aggregated and weighted sets of expert list data that is used to define and weight the relationships that artists have to each other and the relationships tracks have to each other.

Expert playlist generation lists that are aggregated for playlist generation are predefined by experts. The expert playlist generation lists identify tracks that are considered by the expert to be highly consistent i.e. they contain tracks that are assessed to always play well together as opposed to lists we identify as purely being "High Quality" for serving. In this way, the system achieves automatic generation of playlists including songs consistently assessed to be highly compatible and/or appropriate to certain themes or moods. This applies irrespective of the tempo or persuasive properties of the tracks on which it would also be possible to rely in principle.

A simple example of an expert playlist is set out in Table 6, whereas a list that would be considered High Quality for serving on its own but not Consistent for playlist generation is set out in Table 7. The expert playlist generation lists which are created by experts and used for generating the playlists are stored in the playlist storage module 565. These playlists can be input straight to the server 10. In addition, expert playlist generation lists can be identified and retrieved over the internet for storage in the expert data storage module 545, for example, playlists obtained from compilation albums or DJ radio playlists.

Table 6 - Ben Boilerhouse Presents Favourite Moments in Roots, Rock, Reggae

Table 7 - Ben Boilerhouse's "50 Songs I Love That Cleared the Dancefloor".

The expert list data processing module 550 analyses the expert playlists and assigns scores to each track by counting the number of times tracks appear in the expert playlists together. For example, track A appears in three different expert playlists with track B. The relationship between track A and track B is a first level relationship.

Relationships are then inferred between the tracks in each expert playlist. For example if track A appears in one expert playlist with track B and track B appears in another expert playlist with track C then a (weaker) second level relationship is determined between tracks A and C. A count is also made of the number of these second level relationships.

The relative importance of the first level relationships to the second level relationships is defined, typically as a proportion of 10:1. An absolute score is then assigned to the relationships between tracks. An absolute score is made up of: (Count of the first level relationships * 10) + (Count of the Second level relationships)

For example, if track A has a first level relationship count to track B of 20 and a second level relationship count of 47 then the absolute score assigned to the score between the two tracks is: (20 * 10) + 47 = 247

The relative relationships of tracks to each other is then determined. For example, the track with the highest score will receive a relative score of 100 and each other related track will receive a proportional score.

A ubiquity rating (a count of the number of times a track appears in the plurality of expert playlists) can be assigned to each track so the recommendations can be adjusted based on the overall frequency of a track in the plurality of expert playlists. For example, if a track D only appears a few times in the expert playlists but is almost always related to the seed track (track A) then this track D is considered to be more significant than a track E that appears

thousands of times in the plurality of expert playlists but has the same overall score as track D. The ubiquity rating can be used to adjust the popularity of tracks recommend by the playlist generator module 585.

Table 8 illustrates an example of data that may result from an analysis of tracks that are related to track A in the expert playlist generation lists. The results of the analysis performed by the expert list data processing module 550 are stored in the expert list data storage module 560.

Table 8

Table 9 illustrates the top 20 tracks that are related to Aretha Franklin - Respect.

Table 9

In order to generate user playlists the following information is required;

1) A track or a list of tracks from which the user wishes to 'seed' the playlist

2) The user's source (or sources) for which the playlist is to be generated (if any)

3) The number of tracks the user requires in the playlist (N)

4) The degree of 'randomness' the user wants to apply in the selection of tracks typically this will be a factor - say 1 to 5 (S).

Although the user can select the above options, the server 10 may provide default options, for N and S etc. In addition, the user can select whether the playlist is to be generated from the tracks in their music library or whether the playlist can also be generated based on tracks which the user does not own (that the user may wish to purchase tracks in the playlist at a later date). The playlist generator can generate a playlist using any tracks detailed in the storage module 575, the tracks used are not limited to those available form any particular music store 40. If the user wishes to purchase (any of the) tracks in the playlist at a later date, then the server 10 can direct the user to a music store 40 from which the track can be purchased. If there is a plurality of tracks the user wishes to purchase these may be available from different stores 40.

The playlist generator module 585 looks up the top N * S number of artists most closely related to the seed track(s) by way of the pre-analyzed score held in the expert list data storage module 560. The 'Artist' score is obtained by aggregating the track scores.

The playlist generator module 585 then adds the track which is most closely related to the seed track(s) and that belongs to one of the artists identified in the previous step. The playlist generator module 585 then continues to add tracks to the user playlist until the user playlist is complete. The added tracks are selected based on the aggregate scored relationships between all the tracks currently in the playlist and all the other tracks.

If required, the Ubiquity rating can be adjusted. For example, looking at the top 20 tracks that are related to Aretha Franklin - Respect in Table 9, the relative scores can be adjusted based on the ubiquity rating in order to promote rarer or more unusual tracks such as the tracks King Curtis, Memphis Soul Stew and Arthur Conley or Sweet Soul Music. These rarer tracks are mid table but have very low ubiquity rating. Therefore, by adjusting ubiquity rating their scores can be boosted such that they are more likely to be recommended and produce less 'obvious' playlists.

In addition, in order to reduce the likelihood of the same track being recommended frequently, the tracks score can be reduced in proportion to how recently it's previously been recommended in a playlist.

These weightings and scores are then used "on the fly", by the playlist generator module 585, in order to generate the playlists. The generation of playlists provides an enhanced musical experience based on the synergetic effect of combining tracks into an integrated audition. Not only does the playlist generator module 585 select a predetermined number of tracks that have synergy for use in the generated playlist, but also selects the order in which the tracks are arranged within the playlist, such that when the playlist is listened to there is even greater harmony between the tracks of the playlist.

Figure 12B illustrates a server 10 that is capable of providing user playlists but does not comprise an expert recommendation module.

The user can request a playlist, that is close to a specific genre or artist and the apparatus can select from many possible recommendations those that are closest to the user's specified influence.

In one embodiment, the user can request that a playlist is generated using only tracks which are in their music library (the user's music data is stored in the user data storage module 510). In another embodiment, the user can specify that tracks from outside the user's own music library can be used to generate a playlist. In this embodiment, the apparatus of the invention identifies tracks which the user does not own (information on which is stored in the storage module 575) and can provide the user with an opportunity to purchase the tracks or recommend that the tracks be purchased. In another embodiment, all tracks in the generated playlist are determined to be outside the user's current music library.

In addition, users often embrace the music preferences of their favourite artist(s) and/or their expert(s)/mentor(s). The apparatus and method of the invention can provide a

collection of music libraries (stored in the expert data storage module 560) associated with top artists, which the user can then specify as an input for the customization of their playlists and/or as the basis of the expert recommendations. In other words, the recommendation module 580 can recommend tracks and/or the playlist generator module 585 can recommend tracks, which are close to the user's music collection and also in their mentor's library. In such a case, the mentor may be for example the user's favourite artist.

Furthermore, the embodiments of the invention enable the user and/or administrator to fine tune tracks in playlists in many ways, e.g., by time period, level of popularity or by enlisting the influence of reference collections provided by the server 10. The server 10 provides representative collections of tracks grouped by style or genre, which users will then be able to explore and to use to influence the recommendations they receive.

In addition, as explained above, the user has the option to specify the length of the playlists, which are being provided by the recommendation service and the extent to which the playlist should include new tracks, which are not available in the user's library, via the customisation module 110 provide on the user application 100 at the user's device 20/player 30. At its extremes, the playlist can be based exclusively on tracks already present in the user's collection or, alternatively, on entirely new tracks. The user has the option to explore the new tracks and to purchase them from a media store 40, either provided at the server 10 or separate from the server 10.

The user can purchase tracks, via the server 10. For example, the user sends a request to purchase a track (or album) to the server 10. The server transfers the request to the media store 40 (illustrated in figure 1), which then transfers the requested media to the user's device 20, via the internet 50. In one embodiment, the media store 40 may be provided at the server 10.

In order to generate synergetic playlists, embodiments of the invention performs analysis on expert playlist generation lists that are available, such as high-quality sequenced sets of

related media items, e.g. DJ playlists, radio or TV tracking data, known expert information, rated user data, journalistic preferences, etc.

Figure 14 illustrates an examplary process for analysing the expert playlists in particular for playlist generation functions. As illustrated in figure 14, the first step is to identify preexisting related data (playlists) (step S400), such as DJ playlists, compilation albums, etc. The related data is then cleansed (step S410) before being analysed in order to insure the accuracy of the results (optionally by using the editor's input tool). In order to cleanse the data, it is analysed and the artist and track names are tidied up to ensure duplicates are avoided where possible. Additional information about each track is also extracted, for example, if the expert data is a radio set list then information such as the version or mix of the track, the label that the track came out on, who played it, when they played it and what special feature it was part of (if any, e.g. No. 1 dance track that week) is retrieved. Finally, the expert playlist data is then stored in the expert list data storage module 560 and associated with relevant identifiers and metadata attributes. The relative quality of the source of the related data may be quantified and stored in the storage module 560.

The expert playlist data that is identified and downloaded from the internet may require cleansing. In addition, the expert playlists, which are provided by the experts, may also be provided to the expert list data cleansing module 540.

The data is then analyzed (step S420). The first stage in the process is to analyze the individual sequences within each playlist (step S422) and assign a weighting to all relevant item-set to item-set relationships that exist within the sequence (step S424). The expert list data processing module 550 performs the analysis. The known quality of the source set can influence the resulting score and the weighting may be affected by criteria predetermined by the size and type of the items. The definition of an 'item-set' is also based on the type of media, the source of the data and the relative distance within the source data of the individual items. For example, when analysing radio tracking data, the size of sets may be influenced by the distance in track plays and the grouping of back to back tracks into small

sets of 2 or 3 tracks that occur as a result of commercial breaks. In contrast to this, a DJ club night playlist may be 2 or 3 hours of unbroken tracks that need to be broken up into meaningful overlapping sequences.

The nth level item-set to item-set relationships that are known to exist through the accumulated information generated in steps S422 and S424 are then derived (step S426). By iterating through the results of steps S422 and S424 it is possible to determine for example that if Item-SetA is related to Item-SetB and Item-SetB is related to Item-SetC then we can derive a relationship between Item-SetA and Item-SetC. The strength of the derived relationship is based upon many factors including the strength and importance of the source relationships, the type of media and the size of the source sets. This process is iterative to n levels depending on the degree to which the levels remain useful.

Finally, the process aggregates the results of step S426 and derives a weighting and a relative importance measure of the relationship between item-sets (step S428). The measures used to define the weighting and the relative importance of that weighting are again dependant of the types, size and quality of items and sequences being analyzed.

The results of the analysis, i.e. the relationships and weighting applied to the weightings are then stored in the expert list data storage module 565 for use by the playlist generator module 585.

Embodiments of the invention therefore provide an embeddable service and can become part of a larger media delivery site. In this instance, the editor of the media delivery site can adjust the pre-determinate set of criteria to bring it in line with the sites aims, so as to integrate the recommendations with the content of the site.

To provide the editors of such sites with the desired control over playlist recommendations, the apparatus and method of the invention offers a tool site through which host site editors can adjust the recommendation to suit their intended content delivery strategy. In this

context, one important concept that the apparatus and method of the invention supports is the editorial-oriented recommendation. This concept reflects the policy of media sites to run periodic editorials which cover topics of high interest to their audience and to align and configure the recommendation process to concur with the editorial in several important ways;

• The editor can introduce rules controlling the categories of the tracks, which can be present on playlists delivered to the user. Furthermore, the editor can impose his own- expertise on the recommendation process by specifying restrictions on the track, c which can co-exist on a playlist.

• The editor can provide seeds for the playlists, which are relevant for the running topic. The seed or the initial track on a playlist influence the entire configuration of a playlist, given that subsequent tracks are chosen to closely "match" with the seed track. Through the seeding mechanism, editors have a powerful option in controlling the contents of the recommendation process.

• The editor can set global influences to customize all recommendations offered in conjunction with a given context or topic. For example, the editor can choose a reference music library held in the apparatus collection to influence all recommended playlists in order to indirectly super-impose the influence of a genre or a style over the set of preferences expressed by the user.

• The editor has the option to decide on the knowledge and data sources, which embodiments use in the recommendation process. This choice can again bias the recommendation process on a global level, since the same preferences are answered in different ways, depending on the background information used.

• The editor has the choice to customise the music-related contents, which is offered, to the user in conjunction with the recommendations. This option is particularly important when host sites try to align and integrate their entire contents to the site around a given topic.

Embodiments of the invention thus operate as a highly customisable music organisation, personalisation and recommendations service, both from the user's perspective as well as

the perspective of its host. Whereas the user is allowed to express preferences, the editor is allowed to apply expertise and editorial judgment in adapting the recommendations and playlist offering to the purposes and contents of the host site.

As previously mentioned, embodiments of the invention can enhance the user experience by providing music-related content in addition to the actual recommendations. The apparatus and methods may also provide samples of the recommended music together with the recommendations, for example, an excerpt for a track lasting 15 seconds. This enables the user to identify, and test a multitude of musical styles before purchasing the recommended music, and to orient the recommendation process towards new styles, genres and artists.

Information regarding any recommendations which have been made by the server 10 to the user is stored at the server 10, associated with the user's ID. In one example, information identifying a song that was recommended by the server 10 and then subsequently purchased/added to the user's music library is stored at the server 10 in the user data storage module 510. In another example, information identifying a song that was recommended by the server 10 and then not purchased/added to the user's music library is stored at the server 10 in the user data storage module 510. Therefore, as a result of the constant analysis of the user's music data and also their responses to the recommendations, the recommendations can be fine tuned to be more relevant to the user's tastes. The server 10 is able to substantially prevent re-recommending music which has previously been recommended and which the user is not responding to.

The server may also recommend songs which are already in the user's library, but which, for example has not been listened to for a period of time. In this embodiment, the server 10 will inform the user that the recommended song is already in their library.

Embodiments, typically benefit from the following features:

• The use of a continuously evolving collection of expert musical knowledge to guide the recommendation process.

• Its highly embeddable character within the host sites.

• The delivery of recommendations which are sensitive to the user's music listening habits as reflected through his/her music library and statistics.

• The transparency of the engine-user interaction in terms of preferences elicitation.

• The highly intuitive model which allows the user to express interests using examples.

• The possibility to configure the engine to offer targeted recommendations, aligned with a given topic.

• The delivery of context-sensitive music-related contents, intended to create an extended music exploration experience for the user.

• The overall scalability of the approach, which not only allows embodiments to serve a large user base, but which also makes it deployable in a variety of contexts and settings, and which allows it to be easily re-deployed and integrated for diverse target audiences.

In another embodiment an independent middle tier communication layer is provided between the server and the multiple user devices.

In order to improve the scalability of the system, load-balancing is implemented across multiple web servers. Therefore no session-level state information is stored on the web servers. Each server stores and serves a subset of the users, stored in its own databases. This works using Data-Dependent Routing. In addition, the databases of each server are read-only and are scaled-out as Scalable Shared Databases to up to eight servers. Each group of servers will have its own read-only copy of the databases.

Preferably, each server knows the identity of every user and to which server each user is assigned. Only the assigned server stores the user's data, including their music library. However, in preferred embodiments the servers share the expert data.

A middle-tier communication layer can be provided between the server and the multiple user devices. This middle-tier can use any database server to validate a user and determine

to which server they are assigned. From then on the middle-tier routes all traffic for that user to the correct database server. In order to scale-out all that is required is to add another pair of database servers and then to move and re-allocate users.

In another embodiment the servers are paired, and if one server in the pair fails then the other can seamlessly take on its workload until the failed server is restored.

Preferably, each server has two instances of SqI Server (or similar software) running. One is the workhorse instance; the other instance uses the database file-store of its paired server and is set up as the fail-over. If a server should fail then the fail-over instance on the paired server instantly and automatically takes over until the failed server has been restored to operation

Although the above description refers to music and in particular songs, embodiments of the invention could equally be used in relation to security portfolios (e.g. Shares), recipes, movies, music video inventories, personalised TV lists, books or any other elements which require list management with option to refer to expert list(s) and can be cross referenced.

Festival Recommendations

The server 10 may also recommend events (such as festivals, concerts, gigs, or other (music) events, sports events, comedy events, etc.) which the server 10 determines that the user may be interested in attending, based on the user's music data and/or the user profile. The events recommendation may also be based on user information, for example, geographical area in which the user lives, although this may only be limited by country, or user's age if the user is below/above an age restriction for attendees (which is inferred in the user profile).

The initial analysis of the user's music data is the same as that used for determining a relevant music expert (mentor) described above.

The server 10 retrieves information regarding events from several sources, such as from the internet via the server communication interface 500 (provided via the event data extractor module 505, event data cleansing module 515 and the event data storage module 525), from expert recommendations, and from event data input specifically to the server 10. The event data is identified by an event data extractor module 505. The event data is analysed by an event data cleansing module 515 at the server 10 in order to sort the events into categories, such as festivals, concerts, gigs, conferences, sports events, comedy events, etc. and into sub-categorises such as the style of music, the duration of the event, the number of artist performing, type of sports event, i.e. football, cricket, horse racing events, etc. The server 10 also identifies the artists at each event and a weighting is applied to each artist. For example, if an artist is playing at a substantial number of the festivals, then a lower weighting is applied to that artist. However, if an artist is only playing at a few or just one event in a calendar year, then a higher weighting is applied to that artist. The event data can then be stored in an event data storage module 525 at the server 10.

An event can then be recommended to a user by the recommendation module 580, based in an analysis of the artists in the user's music data (stored at the user data storage module 510). For example, if an artist appears many times in a user's music library it is determined that the user may be interested in seeing that artist at an event, and the event is recommended. In contrast, if an artist only appears once or twice in the user's music data, or has not been listened to for a predetermined period of time, or has a low weighting in the user's music data (for example, as a result of the artist being a very popular artist), then it may be determined that the user is less likely to want to see the artist at an event, and the event is not recommended. Consequently, the event recommendations are determined based on the analysis of the user music data and the event weightings.

In addition, an event may be recommended based on the user's profile, for example, in its simplest form, if it has been deduced that the user is likely to be male, between 30 and 35 years old, is likely to live in London and has Diamond Lights by Glenn Hoddle and Chris Waddle in their music list data, then it may be inferred that the user is a Tottenham Hotspur

soccer fan. The recommendation engine 580 may then recommend a Tottenham Hotspur event to the user.

The events recommendations can be combined with the expert recommendation, such that an expert recommends certain events and users who are assigned the expert (mentor) are recommended the expert recommended events. Alternatively, or in addition, events may be recommended based solely on the results of the analysis of the user music data.

The recommendations are sent to the user's device 20/user player 30 from the server 10 and are displayed at a user interface. Alternatively, the recommendations may be transferred to the user as an email or SMS message, if contact details for the user are known.

An event recommendation may include information such as the name of the event, the event identifier (if applicable), the date of the event, the location of the event, the duration of the event, the cost of the event, etc. The event recommendation may also include details of how the user can purchase tickets for the event. These details may include a link directing the user to a website where tickets can be purchased or may detail a telephone number and/or address where tickets can be purchased.

Thus, the user profile data, which is populated from the known and inferred information about the user following analyses of the user's data, can be used as a basis for content management relating to offers, products or services other than music.

For example, in a simplistic form, if the user has a lot of South American music in their user list data, it may be recommended that the user considers a holiday to South America. In addition, for example, if it has been deduced that the user is a Sunday Times™ reader, aged between 50 and 55, is likely to be male and is in a higher income bracket, then the user may be provided with advertising for a new model of Mercedes™ or Jeremy Clarkson may be suggested as the user's Mentor and if accepted by the user, he may recommend that the user try the new Mercedes™. In another example, if it has been deduced that the user is a

Heat™ magazine reader, aged between 20 and 25, and is likely to be female, then the user may be provided with advertising for ASOS™ clothing or Cheryl Cole may be suggested as the user's Mentor and if accepted by the user, she may recommend that the user try shopping at ASOS™. As an example, a user may suggest a particular preference of Mentor based around his enjoyment of a particular wine (such an expert may be chef Mark Hix, who with expert view may suggest an accompanying meal to that particular wine). The user may as another example, choose to holiday in France, which with profiling infers the user to be a Sunday Times reader with small children. A holiday expert such as Amanda Lamb may also recommend accordingly.

Hence, although the expert recommendation service has been described above with reference to music, the apparatus and method can be applied to other areas such as Film/TV/Documentaries, books, wine, stocks and shares, betting, holiday destinations/bookings, car purchases, fashion, jobs, dieting and meal planning, property, benefits, dating, current affairs, journalism, etc.

In addition, or alternatively, the user list data could include a list of items relating to the content being managed. Such lists can be obtained from the user (either in the form of a list or built over time). Such lists may also be obtained from an external provider, such as a loyalty card scheme provider, or from an internet site from whom the user has purchased items. With regards to Dieting and Meal Planning, an expert could recommend recipes based on items purchased by the user, or could recommend additional items which complement purchased items, for example, an expert may recommend a specific wine to accompany a food item (for example, beef, salmon, chocolate torte, etc.) brought by the user.

The various different recommendations can be made based on the analysed data, which may include user music data, user film data, user online purchases data, user's television viewing data (provided by television broadcast providers), etc., all of which can be cross referenced against each other and combined to form a more detailed user profile. For example, if a

user has a song from a movie soundtrack in their music data, the recommendation engine may recommend that the user view the movie and may additionally advise that the movie is going to be shown on x channel at y time, or if a user has a song in their music data, the recommendation engine may recommend magazine x that is running an article on the band. Or ₇ if the user has purchased a fillet of steak, the recommendation engine may provide wine recommendations from wine expert Oz Clarke or may provide a Jamie Oliver (chef and food expert) recipe for the steak.

The following example is an investment portfolio in which user list data would relate to the user's historic and current securities holdings and expert data list would include securities holdings of professional fund managers and the like. The invention has been described with particular illustrative embodiments. It is to be understood that the invention is not limited to the above-described embodiments and that various changes and modifications may be made by those of ordinary skill in the art without departing from the scope of the invention.

For example, the apparatus and method of the present invention can be applied to other scenarios which are not music such as a user's securities portfolio. If the apparatus and method of the present invention is applied to an investment portfolio, the preferences processing module 150 and patterns processing module 130 analyses the user's share portfolio and determines, for example the identities of individual securities, the total value of all securities held, the total volume of all securities held, the average value of securities held, and the average volumes and values of securities traded and held per day, week, month and year, etc.

In addition, the server 10 could communicate with the user's share broker(s) via an, online API to retrieve or maintain an up-to-date list of the user's share portfolio. Updates could be received either by subscribing to electronic notifications that notify the Service of Changes or by polling the API at regular intervals (e.g. every 15 minutes) and make for example, recommendations accordingly.

Figure 15 illustrates the server of 12A further comprising an event data extractor module 505, an event data,cleansing module 515 and an event data storage module 525. The server of Figure 15 is used in order to provide a user with event recommendations based on the data in the user list data storage module 510 and the user pro forma module 590.

In addition, the server 10 could communicate with the user's share broker(s) via an online API to retrieve or maintain an up-to-date list of the user's share portfolio. Updates could be received either by subscribing to electronic notifications that notify the Service of Changes or by polling the API at regular intervals (e.g. every 15 minutes).

In an embodiment, the user player 30 may not be required; the user may be able to listen to music, etc. directly using the user device 20. In addition, the system also works without the user device 20, the user player 30 communicating directly with the server 10. In this arrangement, the user application 100 is provided at the user player 30.

The invention has been described with particular illustrative embodiments. It is to be understood that the invention is not limited to the above-described embodiments and that various changes and modifications may be made by those of ordinary skill in the art without departing from the scope of the invention. For example, the databases could be provided as a single database or a different arrangement of databases.