HK1132832B - Method for generating a playlist - Google Patents

Description

Method for generating play list

RELATED APPLICATIONS

This application claims priority from U.S. provisional application 60/595,666, filed on 26.7.2005, the specification of which is incorporated herein by reference.

Technical Field

The present invention relates to digital media products. More particularly, the present invention relates to an interface and method for accessing and organizing digital music content and other tracks (tracks).

Background

The range and popularity of digital content has grown dramatically over the past few years. For example, analog sources such as vinyl recordings played back on a rotating disc playback unit have been largely replaced by portable CD ROM players or personal portable players with MP3 (motion picture experts group, audio layer III) and other audio digital file playback capabilities. Personal portable media players have gained increasing popularity recently. More recently, portable media players have provided storage of digital audio files in fixed or removable memory. To expand the content available from the fixed capacity of memory, digital files are often stored in compressed form and played back by the device after decoding.

As the gate length of semiconductor processes decreases, the available storage capacity increases. This in turn enables a greater number of tracks to be stored on the portable device. Although improved navigation techniques have allowed users to quickly access individual songs, many users desire a simplified experience. One technique for freeing the user from a series of selection activities is a playlist. A playlist is a user-defined collection of songs (collection) ordered for playback. Many users prefer to organize tracks according to a playlist to simplify their experience.

These playlists are often created from metadata associated with the tracks. For example, an application running on the host computer may allow the user to select the track attributes to be added to the playlist in the hope that the program selected track will be appropriate for the user. Unfortunately, many tracks placed into a playlist using these automatic playlist generation algorithms are considered undesirable by users. Furthermore, the user's interests may change over time, with the result that tracks that the user originally liked lose appeal to the user over time. Many programs allow a user to access playlists from a host computer and make manual deletions and additions. However, these techniques require user time investment and reflect only the user's view at the time of the last access to the host computer program.

For users who do not wish to spend time generating playlists, the device provides a "random" playback option (often referred to as "shuffle") to mix (mix up) the order of play of the stored tracks. This also leads to undesirable results and a less pleasant experience.

It is therefore desirable to provide a method of providing a list of tracks for playback that tracks the user's preferences in a more dynamic manner and that does not require him to frequently access the host computer to modify the playlist.

Disclosure of Invention

The present invention provides a system and method for performing intelligent shuffling of tracks.

According to a first embodiment, a method is provided for identifying tracks for playback from a playlist or queue of tracks. A plurality of tracks are provided in the playlist. User preference data for each of the plurality of tracks is determined based on the user's behavior as each of the plurality of tracks is accessed for playback. After each track is accessed based on the user preference data, the tracks in the playlist are reordered. Based on the reordered track arrangement, a subset of the playlist is selected as a candidate list for playback. The tracks are then played pseudo-randomly from the subset.

According to another embodiment, tracks from a playlist of tracks are identified for playback. A plurality of tracks are provided in the playlist. User preference data for each of the plurality of tracks is automatically derived based on the user's behavior as each of the plurality of tracks is accessed for playback. The re-ordered list of tracks in the playlist is performed after at least one track is accessed. The reordering is based on user preference data. Further, each track is associated with a track usage attribute that reflects the frequency of access to the track over a predetermined period of time. The method also includes selecting a subset of the playlist as candidates for playback based on the re-ordered list of tracks and the track usage attributes. In a refinement of this embodiment, the track usage attribute reflects at least one of: whether a track has been repeated at least a predetermined number of times over a predetermined time period; whether the track has not been accessed over a predetermined period of time; and whether the track has been skipped over a predetermined period of time. In another alternative aspect of this embodiment, the appropriate matching values for the track usage attributes are selected by the user in a playback format template selected through the user interface. The selected subset may then be further processed in a pseudo-random playback mode by assigning random numbers to the identified tracks, and thus providing some weight to the ordered tracks by providing a number limit to the grouping of tracks associated with different categories of track usage attributes.

In another refinement of the above embodiment, at least two categories corresponding to separate regions in the subset list are specified for the track usage attribute, and the number of tracks that fit into each of the at least two categories is determined by the user prior to selecting the subset.

In another refinement of the first embodiment, the user history of allowing the track to play until completion is considered an approval of the track and the user history of skipping the track is considered an disapproval of the track, thereby setting the user preference data. The attribute identifying the user preference data is a ratio of the number of times the track was successfully played to the number of times the track was accessed for playback.

In another embodiment, a method of identifying tracks for playback from a playlist of tracks is provided. A playlist is provided having a plurality of tracks. A rating for each of the plurality of tracks in the playlist is determined based on a first attribute associated with each of the plurality of tracks. The second attributes associated with at least some of the plurality of tracks are used to identify at least one sub-portion of the plurality of tracks. A region size for the number of tracks in each of the at least one sub-portion is selected. Each sub-portion is populated based on the hierarchical attributes of the qualifying songs that meet the second attribute. In one refinement of the embodiment, the first attribute includes user preference data for the track and the second attribute includes a playback history identifying a play count for the track within a predetermined time frame. In an alternative embodiment, the first attribute comprises user preference data for the tracks, and the second attribute comprises one of a genre or an artist associated with the tracks. In another embodiment, the method further comprises assigning a random number to each track in the subset. Playback occurs according to the assigned random number.

In another embodiment, a playlist is provided having a plurality of tracks. A rating for each of the plurality of tracks in the playlist is determined based on a first attribute associated with each of the plurality of tracks. The second attributes associated with at least some of the plurality of tracks are used to identify at least one sub-portion of the plurality of tracks. User preference data is automatically derived from user behavior of playing or skipping tracks.

These and other features and advantages of the present invention are described below with reference to the accompanying drawings.

Drawings

Fig. 1 is a diagram illustrating a sorted playlist according to one embodiment of the present invention.

Fig. 2 is a functional block diagram illustrating a system and method for biased (bias) track selection according to one embodiment of the present invention.

Fig. 3 is a flow diagram illustrating a method for generating intelligent and random playback in accordance with one embodiment of the present invention.

FIG. 4 is a diagram illustrating the creation of a list subset according to one embodiment of the invention.

Fig. 5 is a diagram illustrating a system for generating a dynamic playlist according to one embodiment of the present invention.

Detailed Description

Reference will now be made in detail to the preferred embodiments of the present invention. Examples of preferred embodiments are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these preferred embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known mechanisms have not been described in detail in order not to unnecessarily obscure the present invention.

It should be noted herein that like reference numerals refer to like parts throughout the various views. The various figures illustrated and described herein are provided to illustrate various features of the invention. Where a particular feature is illustrated in one figure rather than another, it will be appreciated that those features may be adapted for inclusion in embodiments represented in other figures, as if fully illustrated in those figures, except where otherwise indicated or where structure inherently prohibits inclusion of that feature. The drawings are not necessarily to scale unless otherwise indicated. Any dimensions provided on the figures are not intended to limit the scope of the present invention, and these dimensions are merely illustrative. Further to the extent that details relating to methods for forming a product or performing a function are illustrated in the figures, it is understood that such details can be adapted to any such apparatus shown in the figures, which is adapted to perform the function or to the configuration of the result using the method, as those same method details are fully illustrated in the figures that contain the apparatus.

In various embodiments of the present invention, systems and methods are provided for performing intelligent shuffling of tracks. Shuffling is defined as a simple randomization of a list. In conventional media players, a random music playback mode is often provided. Tracks are randomly selected from a queue or playlist. Unfortunately, these random playback modes assume that each track or music file in the list is of equal "interest" to the listener. When the list represents a very large collection (e.g., greater than 10 albums), it is likely that not all tracks share the same preference level (or "weight") for that listener.

The present invention provides a method and system for a more intelligent random selection process that focuses more on tracks that are displayed to more closely fit the user's recent preferences. This method, also referred to herein as "smart shuffle" or "S shuffle", provides an improved listener experience by treating the music list as a dynamic list that is "rearranged" based on the user' S listening patterns.

According to one embodiment, a playlist or current queue of songs for playback is filtered through an intelligent random selection process. In particular, playback of the queue or playlist is biased toward playback of certain tracks by generating an ordered smart shuffle (S shuffle) list from the playlist. Filtering is performed by applying a track selection window to the sorted list, resulting in a subset of the playlist tracks available for playback. The selection window is segregated into definable regions or areas (e.g., repeat, retry, favorites, surprise, etc.) that include playlists or queues. By adjusting the relative sizes of these definable regions in the selection window, a weighting of the user preferences is obtained. Thus, the particular tracks played based on the selection of the smart shuffle mode are derived from the reordering of the smart shuffle list or from the playback history attributes based on user preference metadata.

To create the smart shuffle ordered list, one starts with a defined playlist. And then may be sequentially by 1); 2) randomly; or 3) play the tracks by playing them back according to the existing smart shuffle metadata and create user preference and playback history data. Initially, according to one embodiment, when the S shuffle list is created, the music tracks are inserted into the S shuffle list in a random order. In other refinements of this embodiment, the order in which the smart shuffle list is initially seeded may take into account other track metadata (like user preference scores or billboard ratings). The smart shuffle list is then seeded in advance and the overall selection is improved. Then when the list is "played," the S shuffle list is opened and the music tracks are randomly selected for play. In a preferred embodiment, the "weights" of the playlist or the smart shuffle list are generated from the use of a track selection window that defines a subset of the smart shuffle list.

After playback, each track is placed near the top of the smart shuffle list. If the user skips a track, the track is instead placed near or at the bottom of the list. In this manner, a "played" list is created with the heaviest weighted tracks at the top (favorites) and the lightest weighted tracks at the bottom (least favorites). In this manner, the user preference score is determined automatically and based on the user activity of skipping a track (e.g., before the track completes its playback) being a vote (i.e., a negative comment) on an disapproved track. In contrast, allowing a track to complete its playback is considered an acceptance score for the track.

The user can select the parameter values in the set that directly affect the track selection window. In a preferred embodiment, the user selects the values of four parameters to control the smart shuffle effect. According to this embodiment, the 4 parameters include: (1) the percentage of tracks that are repeated or played multiple times; (2) the percentage of tracks given a retry after being skipped by the user; (3) the percentage of tracks that are rarely played (i.e., the surprise factor); and (4) the percentage of tracks used for selection when selecting a new track. These parameters identify the number of tracks in the track selection window that roughly correspond to the defined area in the smart shuffle list. It should be appreciated that the smart shuffle list as used herein is preferably a logical list having the tracks in the playlist ordered according to a first attribute (e.g., user preference data), and preferably having additional metadata associated with the tracks in the list to further allow the tracks to be selected or grouped for a track selection window. In this embodiment, the additional metadata includes playback history data. By applying different sizes to different categories of playback histories, the user applies customized weights to the track selection window.

FIG. 1A is a diagram illustrating sorting of playlists and resulting filtered windows, according to one embodiment of the present invention. As illustrated in fig. 1A, the initial playlist 100 includes a plurality of tracks associated with the list. It should be appreciated that the creation of a playlist, queue or smart shuffle list may be independent of the actual physical storage of the tracks in memory. In practice, a playlist is typically a file that identifies paths to the various tracks in the playlist. Even if the tracks are stored in the memory in an unordered manner or segments of the tracks are stored in non-contiguous portions of the memory, lists and playlists may be created for organizational purposes such that it appears that the tracks are ordered consecutively in physical memory. Thus, the listing illustrated in fig. 1 is intended to show a logical or virtual arrangement, and does not necessarily reflect the physical structure of the memory in which the tracks are stored.

The tracks 106 associated with the playlist 100 preferably include an identifier 102 associated with the track and additional metadata or attributes 104 associated with the track. For example, as illustrated in more detail in FIG. 1B, the track metadata may include an identifier (e.g., title) 122, a successful play percentage 124, and other metadata 126, the other metadata 126 including, for example, the time and number of times the track was played in a predetermined time period, and the artist name (and other product metadata). As used herein, a successful play percentage is a metric that indicates user preference data over a selected time period. For example, the percentage of successful play may be determined manually from input by one or more users in the process of giving "ok" or "no-ok" votes to a music track. More preferably, the percentage of successful play may be automatically determined by the user's actions when accessing the track for playback. For example, if the user allows the track to play to completion when it is accessed for playback, this is interpreted by the program as an approved vote for the track. In contrast, if a track is skipped (by the user pressing the "skip" button), for example, when accessed and displayed on the screen of the portable media player or interrupted during the course of playback, the action is interpreted as an disapproval of the track. Alternatively, this may be determined from several or more users on a collaborative basis. Preferably, the user preference data is accumulated and associated with each track. That is, the accumulated user preference data associated with each track allows for the ranking of the tracks. Thus, when examining the respective metadata of the tracks in the list, the tracks may be ranked from those at the top of the list having the highest "successful play percentage" and those at the bottom of the ranked list having the lowest "successful play percentage". It should be appreciated that the description herein of a hierarchical list is not intended to necessarily imply the creation of a physical hierarchical list in the memory of a portable media player or other playback device. But rather is intended to illustrate the generated logical association and thus include the generated temporary file. Thus, a logical smart shuffle list may be created that orders the tracks in the initial playlist 100 according to the attributes associated with the tracks.

According to this embodiment, a track selection window 110, i.e., a subset or sub-list of the initial playlist 100, is generated, preferably as a function of the successful play percentage and other metadata. In a preferred embodiment, the selection of tracks to be included in the sub-list (i.e., the filtered track selection window) is further based on other metadata including, but not limited to, the playback history of the respective tracks (i.e., the playback history over the selected time period). One example of such playback history metadata is a play count within a given time frame, such as the number of times a track was played in a predetermined time period (e.g., the last week or month). Alternatively or additionally, the metadata may include a determination of when the song was last played. It is desirable that the user preference data extends to all types, whether derived automatically or manually, including, for example, explicit preference scores for the user. The scope of the present invention is intended to extend to the evaluation of any other metadata associated with a track to include, for example, any of the ID3 tag (metadata) fields available from a Compact Disc Database (CDDB) server and typically stored with mp3 tracks. That is, the filtering method may be further applied with category metadata such as genre, artist, album, and the like. Still alternatively, the filtering method may include other types of metadata as a basis for identifying the tracks for playback, such as audio loudness level, tempo, and so forth.

In a preferred embodiment, the playback history metadata enables a determination of whether a particular track satisfies a music format template (mix template) selected by the user. The music format template allows a user to express a customized music playback format by applying different weights to different playback formats. Preferably, these playback formats are relative repetitions of the tracks in the sequence in which the tracks are played over time. For example, one commonly recognized music playback or playback format is "top 40". This generally refers to frequent repetitions of the most popular tracks. Another example of a playback format is "fresh" music. These typically include songs that are rarely heard.

In the embodiment illustrated in FIG. 1A, the user selects format templates that provide different weights to the playback formats. In this illustration, the repeat category may be considered similar to the top 40 format, while the surprise category may be considered similar to the "fresh" music format.

By filtering the playlist 100, a filtered window 110 is provided that reflects the "weights" selected by the user. More specifically and preferably, the user does not directly set each weight, but selects a "format template" having an actual weight value. Thus, the selection of the format template preferably results in a plurality of weights to be applied to the filtered window by providing respective values for at least two parameters. These values may be selected by selecting a format template from a plurality of templates provided by the manufacturer of the portable device or by any conventional means of inputting parameter values. These customizable parameters may provide, for example, a focus between the number of repeated tracks (i.e., the most recently played track), a percentage retry (giving another acceptance attempt), and an entry from surprise (an entry that is not played too much (a small number of play times)). The user may dynamically change playback by configuring the user interface to allow the user to select from a predetermined format template. That is, the user can dynamically adjust the "weights" applied to different categories or tracks, thereby affecting playback selections without changing the tracks in the playlist.

Tracks are still randomly selected from the playlist, but only those tracks that meet the criteria of the filtered window (i.e., the selection window) are played. Thus, only a certain percentage of the playlist 100 gets into this subset 110 of the playlist. By changing the parameters to make the subset larger, i.e., a greater percentage of the playlist or queue 100, a more random experience is obtained that approximates the traditional shuffle experience. In the case where the sub-list 110 is made smaller compared to the queue, then the impact of the user's customized weights (selected format templates) is greater.

As further illustrated in fig. 1A, tracks that meet appropriate attribute criteria (e.g., in selected metadata fields associated with each track) are placed in the repeat 112, favorites 114, surprise 116, and retry 118 regions of the filtered window 110, respectively. The repeat region 112 corresponds to the percentage of tracks that are repeated or played multiple times; the retry area 118 corresponds to the percentage of tracks that are given retries after being skipped by the user; the surprise region 116 corresponds to the percentage of tracks that are rarely played (i.e., the surprise factor) and the favorites region 114 corresponds to the percentage of tracks for selection when a new track is selected.

FIG. 1C illustrates in more detail the sample composition of the filtered window 110 for generation from the initial list 100 illustrated in FIG. 1A. By appropriately selecting the playback history (playback history) parameters, random playback in the smart shuffle mode can be focused on a subset of the initial playlist 100, where the subset better reflects the music content that the user currently likes. For illustrative purposes, the initial list of 100 tracks may be filtered to provide a selection window list of 30 tracks by controlling the parameters corresponding to the regions to individually size the regions. In the illustrative example, a weight factor of 20% is applied to set the size of the repeat and surprise regions (i.e., the number of tracks), a weight factor of 50% is applied to the favorites region and a weight factor of 10% is applied to the retry region. This results in the filtered window (subset) 110 representing the initial list 100 (containing 100 tracks) being 30 tracks as shown in window 110 in fig. 1A and 1C. A parameter specifying the size of the selection window 110 may be separately set.

Fig. 2 is a functional block diagram illustrating a system and method for filtering playlists in accordance with one embodiment of the present invention. The filtering process (i.e., creation of the smart shuffle list and selection window) operates on the playlist 202, applies a format template to the tracks in block 208, identifies a smart shuffle subset of the playlist based on the user preference data and the track usage data in blocks 209 and 210, randomly selects tracks from the subset in block 211, and plays (render) the selected track(s) in block 212. The reconfiguration of the smart shuffle list, represented by blocks 208, 209 and 210, is preferably performed in the processor of the portable media player.

Filtering may be performed on any grouping of tracks without departing from the spirit and scope of the present invention. For example, the filtering scheme may be performed on a single playlist, on multiple playlists from the same user, on a queue of tracks selected for playback (temporarily stored in system memory but not stored in a more permanent manner), or even on multiple playlists from different users. In the case of multiple playlists, such as playlists 202 and 203 shown in fig. 2, accessing both playlists identifies the aggregate collection of tracks from the playlists as candidate tracks, and then "ranks" the aggregate list based on one or more criteria. Preferably, the criteria include metadata associated with each track, and the metadata includes at least user preference data and track playback history data.

Playlists are typically separate files stored in non-volatile memory of the playback device or host computer, and the preferred embodiment uses playlists in this format. However, the scope of the invention is not so limited, but is intended to cover any form of playlist, regardless of how it is stored or generated.

Playlist 1 and playlist 2 are shown as being accessed by processor 200 from memory interface 216. The playlist is shown as a separate file from tracks 205 that are also stored in the device memory. This represents a typical configuration where the playlist itself does not contain files but rather provides a table of contents or a path for locating the tracks identified in the playlist. Unless otherwise indicated herein, the description of a playlist will be treated as a logical list, i.e., a particular track is included in a playlist without giving details of the physical arrangement between the playlist and the pre-associated tracks. For example, in several embodiments, while structural arrangement details may have associated metadata with individual tracks and playlists that merely serve as tables for grouping and locating content lists for tracks specified by a playlist, the tracks will be treated such that metadata (e.g., user preference data and playback history data) will be associated with the playlist. The basic details of methods for generating, storing, and accessing playlists are known in the relevant art, and therefore those details will not be provided here.

The processor 200 is preferably configured to perform a number of functions on the playlist 202 to play the tracks in a particular order. The user input to the processor includes a button, switch, or any other type of input device suitable for providing user-selected input to the processor. The user input 207 is important for identifying the particular format template 208b to be applied to the playlist 202, and of course is also important for selecting playlists, tracks, and the like. In a preferred embodiment, the manufacture of the portable media player may provide the user with a selection of a "mix" or format template for selection. These templates will preferably apply different weights to different regions of the playlist 202 to give the user a choice of playback format. For example, the "format template" 208B of the chart showing relative weights (see fig. 1C for an example of regions of the playlist and corresponding letter designations for the regions) reflects a heavier weight for the favorites category (B) relative to the repeat (a), surprise (or fresh) (C), and retry (D) regions. In contrast, a format template that focuses more on the top 40 tunes (tune) will have more weight in the a category.

The processor 200 is configured to apply the selected format template (208), examine the accumulated user preference data and playback history data (209), and generate a sublist of tracks (210) (i.e., a filtered window) that meet criteria selected by the user. These functions collectively enable the generation of a filtered window from the playlist 202. The processor 200 also preferably selects tracks from the subset in a random manner (211) and sends the selections to the track rendering module 212. As is known to those skilled in the art, many audio and video tracks are stored in a compressed state and therefore need to be decoded before the digital tracks can be played. Although in the detailed embodiment the tracks are identified largely as audio tracks, it will be appreciated that the scope of the invention is intended to extend to any type of track or media file, including but not limited to video files.

Fig. 2 illustrates the performance module separated from the processor. In many devices, the performance, including among others decoding, is performed by a processor. It is intended that the scope of the present invention includes all variations of the performance configuration whether implemented within a processor, on-chip, off-chip, or even in an external device.

A further function preferably provided by the processor 200 is dynamic modification of user preferences and playback history data (214). In one embodiment, the update of the track metadata is performed automatically after the track is played. Preferably, the processor is configured to automatically determine whether a track has been "skipped" by the user before playback is complete. In this manner, the system automatically detects any (by allowing it to play to completion) or non-approval of the track by the user, interrupting playback before beginning or during playback. In one embodiment, the automatic scoring is supplemented during the use of a "Boost" control for increasing the weight. For example, additional input buttons may be included to assist in the learning of user preferences by the smart shuffle. This information is then associated with the track and stored. Alternatively, the user preference data may be manually entered. Preferably, the user preference data reflects an average, i.e., the percentage of the number of times the track has been allowed to play until completion divided by the number of times the track has been accessed. This "successful play percentage" is then used to rank the tracks within the playlist or queue. As will be described in more detail with reference to fig. 4, the ranking enables selection decisions to be made regarding the placement of tracks within the "region" of the filtered window.

Although the user preference and playback history data may be updated after each track is played or skipped, in one embodiment, the generation of a new customized "smart shuffle list" is performed less frequently. The processor may be configured to cause reordering of the smart shuffle list and generation of the sub-list in response to a selected user input. For example, any of selecting a new format template, adding or deleting tracks from a playlist, playback of a predetermined number of tracks, or a set period of time from when the smart shuffle list was first generated will be sufficient to cause a new filtered window to be generated based on updated data associated with the tracks. That is, any of these events may cause a new filtered window to be generated from the reordered playlist. This initiating event example is illustrative and is not intended to be limiting. It is intended that the scope of the present invention include all forms of initiating events including, but not limited to, adding additional track metadata during playback, adding additional tracks, and selecting different format templates.

Fig. 3 is a flow diagram illustrating a method for generating intelligent and random playback in accordance with one embodiment of the present invention. The flow diagram generally illustrates a process for generating a custom list (i.e., a filtered window) from one or more playlists. Processing begins with operation 300. First, a playlist is defined in operation 302. The playlist may be a single playlist or a temporary queue identifying the playlist selected by the user for current playback. Also, the playlist may be a plurality of playlists selected for a single user, or at least one playlist selected for each of a plurality of users. The playlist identifies a list of tracks to be further filtered. The playlist may be pre-seeded or may correspond to the order in the original playlist, such as the order in which the tracks are added or listed in the playlist. Next, at operation 304, a window size is selected. This parameter defines the amount of concentration that will be achieved by the smart mix process. For example, limiting the window size parameter to 100% would make all tracks in the playlist available for shuffling. In other words, setting this parameter to 100% closes the filtration. In contrast, setting this parameter to a lower percentage results in a small window and a highly focused smart shuffle sublist. Note that this parameter may be set independently, or alternatively may be derived from other parameters that identify the respective sizes of the regions in the filtered window.

At operation 306, the user selects a format template. This enables the distribution of weights between the various regions of the smart shuffle list. As described with reference to fig. 1C, changing the weights to multiple parameters can significantly change the user listening experience. For example, setting a higher weight to the repeat region (a) parameter will result in a listening experience closer to the top 40 programming. Top 40 is both a frequently repeated record chart based on songs from a continuously updated list of forty best selling singles and a radio format based thereon. Thus, setting a higher weight for the region will result in more tracks being selected from the region of the source playlist, and thus a higher percentage of the filtered window including the top 40 tunes.

Next, at operation 308, a subset of the playlist (i.e., the filtered window) corresponding to the selected parameters is generated. It should be understood that the scope of the present invention is intended to cover all variations of creating or identifying subsets corresponding to filtering. That is, in some cases, an entire file may be created and stored to identify a filtered window. In other cases, only a temporary file may be created that identifies specific tracks that meet the criteria and form a sublist. It is intended that the scope of the invention include any and all of these variations.

Next, at operation 310, random numbers are assigned to the tracks in the filtered window. Conventional methods for generating random numbers and applying them to entries in a list are known in the art, and therefore further details will not be provided here. Next, in operation 312, based on the random number generation step, a track is selected for playing and playback. For example, as a result of the filtering, the method illustrated in fig. 1 reduces the playlist of 100 tracks to 30 tracks. A number is randomly generated for each track and the tracks are played back according to the random number and optionally further metadata values. Next, at operation 314, metadata related to the tracks is updated. This metadata will depend, in the preferred embodiment, on whether the track is played until completed (i.e., user approved) or skipped (i.e., user disapproved). Also, the processor is preferably configured to recalculate the successful play percentage of the track. Next, at operation 316, an optional reordering of the track list is performed. In an alternative embodiment, the device may be configured to reorder the tracks after each access to the tracks. However, preferably, the reordering of tracks based on metadata will occur less frequently, i.e. only if a device-defined event is initiated. Specific examples of initiating events have been described above.

Next, a determination is made as to whether there are other tracks in the filtered window in operation 318. If so, flow proceeds to step 312 to play those tracks. If not, the system proceeds to determine if further user input is received in operation 318. If so, in a preferred embodiment, the playlist is reordered (322) based on the updated metadata provided since the last reordering of the list. Depending on the input type, the process flow may be redirected in operations 302, 304, or 306. That is, if the user is adding to the playlist, the flow proceeds to operation 302. If the user is selecting another format template, process flow advances to operation 306. If no further input is received, the process ends at step 324.

Fig. 4 shows the generation of the sub-list 110 based on the playback history (function of time) and the user preference data. More specifically, the figure illustrates the generation of a subset of the list by filtering the smart shuffle list 100 a. In a preferred embodiment, the user may adjust the values of 4 or more parameters to control the smart shuffle process. These 4 parameters include: the percentage of tracks that are repeated or played multiple times; the percentage of tracks given a retry after being skipped by the user; the percentage of tracks that are rarely played (i.e., the surprise factor); and the percentage of tracks to use for selection when selecting a new track. By utilizing these parameters to control the relative size of the regions of the filtered window 110, the playlist 100a may be filtered to provide a more customized listening experience to the listener.

The method involves a learning or playback experience. The list 100a may be accessed initially in a random manner, by manually selecting tracks, or even by sequentially playing the tracks in the playlist in the order of the tracks in the playlist 100 a. As discussed previously, the user preference data reflects how the user likes the tracks during the playback history. The user's approval and disapproval is recorded as track metadata. More specifically, in one embodiment, the user preference data is rewritten to indicate a higher successful play percentage resulting from the most recent playback and a reordering of the playlist based on the successful play percentage 424. These dynamic changes to the track metadata will generally cause a successfully played track to be placed towards the top of the smart shuffle list 100 a. In contrast, if the user skips tracks, a change in the percentage of successful play will cause the tracks to be placed near or at the bottom of the list 100 a. In this manner, a "played" list is created with the heaviest weighted tracks at the top (favorites) and the lightest weighted tracks at the bottom (least favorites). It will be appreciated that at the beginning of the training experience the track will have little or no associated user preference data and therefore, for example, if successful playback is followed by skipping of the track, the positioning of the track in the playlist hierarchy will be characterized by a wider swing. If no effort is made to pre-order the list based on other track metadata, the changes will typically be more incremental as the playback history grows, and dynamic rewriting of the metadata will cause more movement of the tracks either toward the top or toward the bottom of the smart shuffle list 100 a.

The smart shuffle list 100a illustrated in fig. 4 is ranked according to the user preference metadata column 424 and has also associated each track with recent playback history metadata 426. For example, track 2 has associated it with a successful play percentage of 1.00 and an "RP" (recently played) indication. This metadata would likely cause the track to be in the "repeat" area of the filtered window 110. According to a preferred embodiment, the smart shuffle selection algorithm identifies those tracks as recently played and fills the available slots with those tracks having the highest ranking (according to the successful play percentage metadata 424). For example, as illustrated in fig. 4, tracks 2, 3, and 5 would be among candidates for the "repeat" region of the filtered window 110. In a similar manner, the favorites will include the highest ranked tracks from the playlist 100 that have not been placed in the repeat region. Thus, once a successfully played track that has recently been repeated (e.g., a top forty type selection) is rejected once or worded, the track will begin to move from the "repeat" region to the favorites region.

Directional key heads 410, 412 and 414 show examples of movement. That is, after its first rejection, the high ranked track may be moved from the 2 nd position to the 5 th position on the list, imaginarily and according to this embodiment, as indicated by the transition arrow 410. Further rejection (skipping) of the track may cause a transition 412 to approximately the 10 th rating on the list (coupled with metadata 426 indicating that it is not meeting the Recently Played (RP) criteria) and cause the rating to drop further if further skipping or other tracks move up in the playlist 100. It will be appreciated that the effect of the dynamic re-evaluation of the metadata will generate a corresponding shift of the track in the filtered window list 110, i.e., from the repeat region to the favorites region. It should be noted that a "repeat" or "favorites" region is shown for the smart shuffle list 100 a. It should be appreciated that, in general, these regions correspond to the same ordering of regions in the filtered window 110. However, their boundaries in the sorted playlist (smart shuffle list 100a) are less clear. Preferably, after determining whether the tracks in the playlist have associated metadata fields that each match the selected criteria, a determination is made as to whether the tracks meet the criteria of the filtered window.

When a track is skipped, a somewhat similar movement occurs in the smart shuffle list 100a and the filtered window list 110. In this embodiment, the track is relocated to the end of the smart shuffle list and inserted into a "retry" area. The track may be replayed at a later date or not provided for playback again based on the user preferences of the particular group used.

In general, due to the smaller size of the filtered window list, the dynamic reordering of the smart shuffle list 100a will have a more significant impact on the filtered window list 110, such as causing tracks moving from the repeat region to the favorites region to move outside of the filtered window 110. The random selection algorithm available with the traditional playlist playback mode is still used, but the random selection is a function of the applied weights.

Fig. 5 is a diagram illustrating a system for generating a dynamic playlist according to one embodiment of the present invention. In particular, FIG. 5A illustrates a portable media player 501 connected to a host computer 550 for downloading tracks and/or playlists and/or related metadata. The devices are connected to each other for transmission of digital data by any conventional means, including, for example, a USB cable 540. One skilled in the relevant art will appreciate that playlists may be created on a host computer. Typical applications generate a library of tracks on a host computer and often allow for the creation of playlists that group selected library tracks. The playlist is then downloaded to the portable media player 501 along with the tracks. Alternatively, the playlist may be generated entirely on the portable media player.

The host computer 550 also often includes a media player application in which playlists and individual tracks can be played back using the resources of the host computer for audio tracks using the host computer's sound card and attached speakers or headphones. The methods described herein for filtering playlists to generate smart shuffle playlists and weighted selection windows are preferably applied to portable media players such as portable media player 501. However, it is intended that the scope of the present invention extend to the filtering of playlists of any device configured to generate a smart shuffle list for playback on an attached portable media player using a playlist (e.g., including playback on the host computer 550) or even using a combination of track metadata on the host computer or other networked computer.

In a preferred embodiment, the portable media player 501 is configured to receive user preference data, for example, through a button or switch 503 located on the player 501. Fig. 5B illustrates further details of the portable media player 501, the portable media player 501 being connected to a host computer 550 and configured to perform the smart shuffle filtering method described. Preferably, the processor 535 is configured to receive user input from the buttons/switches 503. The user interface will rely on both the display 518 for displaying playlists, format templates and other options to the user and the button switches for allowing user input among the displayed options. The processor is further configured to access non-volatile memory 520 (flash memory) or 525 (hard drive) for storing tracks, playlist files, and related metadata, such as user preference data and playback history data. In one embodiment, the portable device 501 is further configured to access non-local files, such as network-based files. These may be accessed, for example, through the device's connection 540 to a host computer, which in turn is connected to a server 555 connected in a network 560. The server may, for example, contain archived media files that are available to the public or only subscribers (subscribers), or some combination thereof. Alternatively, the portable device 501 may connect directly to a network-based file, for example, through a wireless interface 539.

The processor 535 is also preferably configured to play the tracks in the non-volatile memory for playback. The tracks are then converted using digital to analog converter 530 and fed to headphones 534. It will be apparent to those skilled in the relevant art that an appropriate interface is required between the processor 535 and the display, user input device, and memory. These include, for example, an LCD control interface 511, a control interface 512, a flash interface 513, an IDE interface 514, and an SDRAM interface 517. The transfer of data to and from the host computer 550 is accomplished using the USB interface 516. Further details will not be provided herein, as details regarding suitable interfaces are known to those skilled in the relevant art.

Customized and random playlists can be generated by providing dynamic reordering of playlists as a function of approval or disapproval actions by the user. Since dynamic reordering occurs as a result of normal user reactions, i.e., allowing tracks to play until completion or skipping tracks, the user's evolving experience is reflected in the smart shuffle playlist.

According to another embodiment the processor is adapted to change the smart playlist format template during playback. That is, the weights are updated based on user approval or disapproval, and when the currently played track is completed, the next track is selected based on the new updated weights.

The above specification describes several embodiments for filtering playlists to generate more customized playlists of tracks. Although these embodiments describe details of a portable media player, the invention is not so limited. It is intended that the scope of the present invention extend to all media players that have access to a playlist or current queue of tracks.

Although the invention has been shown in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (10)

1. A method for generating a playlist from a plurality of tracks having an ordering associated with the tracks, the method comprising:

automatically deriving a user preference attribute for each of the plurality of tracks;

reordering the tracks based on the automatically derived user preference attribute; and

selecting a subset of the reordered tracks by applying at least one region of a selection window to the reordered tracks using a second attribute associated with at least some of the plurality of tracks, the size of each of the regions of the selection window determining the number of tracks in the region of the respective selection window and corresponding to the weight applied by the user to the category represented by the second attribute.

2. The method of claim 1 wherein the second attribute comprises a playback history identifying a play count for the track within a predetermined time frame.

3. The method of claim 1 wherein the second attribute comprises one of a genre or an artist associated with the track.

4. The method of claim 2 further comprising assigning a random number to each track in the subset, and wherein playback occurs according to the assigned random number.

5. The method of claim 2 wherein the user preference data is automatically derived from user behavior of playing or skipping tracks.

6. The method of claim 2, wherein the user preference data is derived or modified by a user providing input on a selection device.

7. The method of claim 2, wherein the size of each of the respective regions of the selection window is selected by a user selecting a format template that defines the relative size of each region.

8. The method of claim 2, wherein the size of each of the respective regions of the selection window is selected by a user manually entering a value.

9. The method of claim 1 wherein the reordering associated with the user preference attributes is automatically updated after the user preference data is updated for at least one track.

10. The method of claim 1, wherein the reordering associated with the user preference attribute is updated after one of the following occurs: the user changes the format template, the track is played back until completed, the track is skipped, the track is played back, and a track is added to or deleted from the playlist.