Method for sharing and searching playlists

- Yahoo

The present disclosure provides a method for making a playlist available to the public. In another embodiment, the present disclosure provides a method for creating a playlist comprising user-defined descriptor information. In another embodiment, the present disclosure provides a method for searching for such public playlists.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application Ser. No. 60/657,222, filed Feb. 28, 2005, entitled A SYSTEM AND METHOD FOR DELIVERING MEDIA OVER A NETWORK, and U.S. Provisional Application Ser. No. 60/678,718, filed May 5, 2005, entitled A SYSTEM AND METHOD FOR DELIVERING MEDIA OVER A NETWORK, both of which are hereby incorporated herein by reference.

BACKGROUND

The expansion of the Internet and the World Wide Web (“web”) has given computer users the enhanced ability to listen to and to watch various different forms of media through their computers. This media can be in the form of audio music, music videos, television programs, sporting events or any other form of audio or video media that a user wishes to watch or listen to. As time evolved, users were able to take the music that was on that compact disc store it on their computers and listen to it locally. More recently, web systems were developed which allowed a user log on to a network such as the Internet and, using a media player, either listen to specific media chosen from a group of media that a particular service has to offer or listen to an array of media offerings such as a radio station wherein different songs or other forms of media are combined to allow a user to listen to a group of songs in sequence, whether chosen by the user or by the operators of the network service. For example such a service is Yahoo!™ Music. Many media players, services and other software tools enable media to be organized by a user or a service into playlists, which, as the name connotes, are groups or lists of media files or file identifiers that can be used to effect playback by a user in a sequence or other selected or random order. Further, once a playlist is created, a user may manipulate and edit the playlists freely. However, what is lacking in each of the currently available systems is a method in which a user may easily share or make publicly available created playlists wherein such public playlists are searchable by key input parameters. Further, the current art lacks a sophisticated method of creating a playlist searchable by user-defined descriptor information.

SUMMARY OF THE DISCLOSURE

In one embodiment, the present disclosure provides a method for making a playlist available to the public. In another embodiment, the present disclosure provides a method for creating a playlist comprising user-defined descriptor information, which can be entered as free form text or prose rather than preselected information like a static genre or short title. In another embodiment, the present disclosure provides a method for searching for such public playlists.

In one embodiment, the present disclosure provides a method of identifying a published playlist comprising receiving, from a searching entity, search criteria representing a desire to identify a playlist; accessing a playlist storage, the playlist storage comprising user published playlists, some or all of the published playlists comprising associated user-defined playlist descriptor information, the user-defined playlist descriptor information comprising user developed text; searching the playlist storage to identify a desired playlist result set comprising user published playlists with user-defined playlist descriptor information relevant to the search criteria; and communicating the desired playlist result set to the searching entity.

In one embodiment, the searching entity comprises a user located on a computing device. In one embodiment, the searching entity comprises a software program.

In one embodiment, the search criteria comprises a mood associated with the desired playlist, a situation associated with the desired playlist, and/or an event associated with the desired playlist.

In one embodiment, the playlist storage is located on a server, on the internet, and/or is located as a part of an online media service.

In one embodiment, the desired playlist result set comprises a playlist identifier. In one embodiment, the identifier is a uniform resource locator, a pointer, and/or a universal resource indicator.

In one embodiment, the desired playlist result set comprises metadata associated with the desired playlist results set, and/or a permission level for accessing the desired playlist results. In one embodiment, the permission level is associated with an online media service. In one embodiment, the desired playlist result set comprises an id associated with the desired playlist.

In one embodiment, the method of identifying a published playlist further comprises facilitating the display of the desired playlist result set at computing device associated with the searching entity.

In one embodiment, the present disclosure provides for a method of creating a searchable playlist comprising: receiving at least one media file selection indicating the desire to include at least one media file in a playlist; receiving user-defined playlist descriptor information associated with the playlist, the user-defined playlist descriptor information comprising user developed text; receiving an input indicating the desire to designate the playlist as public, the public designation causing user-defined playlist descriptor information and information associated with the playlist to be searchable by a searching entity; and communicating to a playlist storage, user-defined playlist descriptor information and the associated playlist information so that the user developed text can be searched by a searching entity.

In one embodiment, identifying a published playlist, the playlist storage is located on a server, and/or the internet.

In one embodiment, the playlist storage is located as a part of an online media service.

In one embodiment, the published playlist information comprises information associated with at least one media file, the title associated with the media file, the artist associated with the media file, the genre associated with the media file, and/or a rating associated with the media file.

In one embodiment, the searching entity comprises a user and/or a software program.

In one embodiment, the user developed text is searchable by search input criteria. In one embodiment, the search criteria comprises a mood associated with the playlist, a situation associated with the desired playlist, and/or an event associated with the desired playlist.

In one embodiment, the user defined text comprises a mood associated with the desired playlist, a situation associated with the desired playlist, and/or an event associated with the desired playlist.

In one embodiment, the format comprises a set of searchable field entries. In one embodiment, the set of searchable field entries comprise a portion of the user defined text, all of the user defined text, and/or a portion of the playlist information.

In one embodiment, the method of creating a searchable playlist further comprises synchronizing, upon receiving an edit to the playlist, the user-defined playlist descriptor information and the associated playlist information with the playlist storage.

In one embodiment, the edit comprises an input indicating the desire to designate the playlist as private.

In one embodiment, storing the user-defined playlist descriptor information and the associated playlist information into a format comprises serializing the user-defined playlist descriptor information and the associated playlist information.

In one embodiment, the method further comprises synchronizing, upon receiving an edit to the playlist, the user-defined playlist descriptor information and the associated playlist information with the playlist storage.

In one embodiment, the present disclosure provides one or more computer-readable media having computer-readable instructions thereon which, when executed by one or more computing devices, implements the method of creating a searchable playlist comprising: receiving at least one media file selection indicating the desire to include at least one media file in a playlist; receiving user-defined playlist descriptor information associated with the playlist, the user-defined playlist descriptor information comprising user developed text; receiving an input indicating the desire to designate the playlist as public, the public designation causing user-defined playlist descriptor information and information associated with the playlist to be searchable by a searching entity; and communicating to a playlist storage, user-defined playlist descriptor information and the associated playlist information so that the user developed text can be searched by a searching entity.

In one embodiment, the present disclosure provides one or more computer-readable media having computer-readable instructions thereon which, when executed by one or more computing devices, implements the method of identifying a published playlist comprising receiving, from a searching entity, search criteria representing a desire to identify a playlist; accessing a playlist storage, the playlist storage comprising user published playlists, some or all of the published playlists comprising associated user-defined playlist descriptor information, the user-defined playlist descriptor information comprising user developed text; searching the playlist storage to identify a desired playlist result set comprising user published playlists with user-defined playlist descriptor information relevant to the search criteria; and communicating the desired playlist result set to the searching entity.

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawing figures, which form a part of this application, are illustrative of embodiments of the present disclosure and are not meant to limit the scope of the disclosure in any manner, which scope shall be based on the claims appended hereto.

FIG. 1 is an exemplary flowchart illustrating a method according to one exemplary embodiment;

FIG. 2 is an exemplary user interface according to one exemplary embodiment;

FIG. 3 is schematic illustrating an exemplary system architecture of one embodiment;

FIG. 4 is a schematic representing a playlist entry according to an exemplary embodiment;

FIG. 5 is an exemplary user interface according to one exemplary embodiment;

FIG. 6 is an exemplary user interface according to one exemplary embodiment;

FIG. 7 is an exemplary user interface according to one exemplary embodiment;

FIG. 8 is an exemplary user interface according to one exemplary embodiment;

FIG. 9 is an exemplary user interface according to one exemplary embodiment;

FIG. 10 is an exemplary user interface according to one exemplary embodiment;

FIG. 11 is an exemplary flowchart illustrating a method according to one exemplary embodiment;

FIG. 12 is an exemplary flowchart illustrating a method according to one exemplary embodiment; and

FIG. 13 is a schematic illustrating an exemplary system architecture of one embodiment.

 DETAILED DESCRIPTION

In one embodiment, the present disclosure provides a method for making a playlist available to the public. In another embodiment, the present disclosure provides a method for creating a playlist comprising user-defined descriptor information, which can be entered as free form text or prose rather than pre-selected information like a static genre or short title. In another embodiment, the present disclosure provides a method for searching for such public playlists.

In one embodiment the ability to publish, create, and search for a playlist is facilitated by a media management program. In a further embodiment a user interface of such a media management program allows a user to publish and search for playlists. In other embodiments, non-media management applications, programs, and/or servers are capable of searching for such published playlists.

FIG. 3 depicts an exemplary system configuration supporting the ability to publish, create, and search for a playlist. As can be seen in FIG. 3, the exemplary system configuration comprises a device 335 connected to a processor 300 associated with a user 330. Further embodiments contemplate multiple users each connected to the system configuration via a processor as depicted in FIG. 13. In one embodiment, the device may comprise any type of computing device capable of rendering media files. In another embodiment, the processor 300 may be located on a computing device, which can be, by way of non-limiting example, a personal computer, cellular telephone, personal digital assistant, or a portable media player, or any other device now known or to become known capable of carrying out the features and functions described herein. As seen in FIG. 3, the processor may comprise a media engine 305, a messaging program 310, digital rights management (drm) 325, media files 320, plug-in applications 315, and a local database 380 for storing information such as playlist information. In addition, through the internet 340, the processor 300 is connected to a media server 360, other programs and servers 370 and a messaging platform 365. Of course, the processor can comprise any combination of necessary components know to those skilled in the art in order to perform the functions described herein. Further depicted in FIG. 3, the processor 300 is connected via the internet 340 to a playlist program 345, a playlist storage 355, a playlist index 375, webservices 350, a media server 360, messenger platform 365, and other programs and servers 370. In one embodiment, the playlist program 345 manages the exchange of information to and from the playlist storage 355. In one embodiment, the playlist storage 355 stores all related playlist information. For example, as depicted in FIG. 3, the playlist storage stores playlist entries comprising user-defined descriptor information as further described herein. In one embodiment, the playlist index 375 stores a subset of the playlist information stored in the playlist storage 355 so that the processor 300 and/or other programs and servers 370 can easily and efficiently access the stored playlist information. In a further embodiment, only playlists which have been designated as public are stored in the playlist index 375. Thus, the playlist index 375 may be accessed when searching for public playlists. In one embodiment, the web services 350 provide efficient manner or way to access the playlist storage 355 and/or playlist index 375. In other embodiments, the webservices 350 may not be necessary to access the playlist storage 355 and/or a playlist index 375. In one embodiment, as depicted in FIG. 3, other programs or servers 370 are capable of being connected to the web services 350 and/or internet 340. For example, in some embodiments, other programs or servers 370 can communicate with the playlist index 375, playlist program 345, and/or playlist storage 355 alone or independent of the processor 300 and/or media server 360. Thus, as depicted in FIG. 3, playlists are searchable by any user, program, server, or any entity with an internet connection. In one aspect, the system configuration allows any other program and/or server 370, such as any non-media management program, to search for playlists and/or store created and/or published playlists for searching. For example, a user could search for playlists, i.e. /e. access the playlist index and/or playlist storage, from a search tool found in a downloadable toolbar such as for example the downloadable Yahoo! Toolbar. With reference to FIG. 3, multiple variations and combinations of connections among the various components are contemplated. Furthermore, FIG. 3 is merely exemplary and not meant to limit the system configuration or architecture supporting the present disclosure in any way. Obvious variations of the components and configurations know to those skilled in the art are contemplated.

The publishing of a playlist according to one embodiment of the present disclosure will now be discussed with reference to FIG. 1 that depicts an exemplary method of the present disclosure. In one embodiment, referring to FIG. 1, first, the user creates 105 a playlist. This playlist can be created in any number of different ways (i.e., user created, criteria playlists, affinity playlists) as known in the art. In one embodiment, a playlist comprises at least one media file and/or media file identifier. In one embodiment, once the playlist is created or during playlist creation, a user is able to enter user-defined descriptor information with respect to the playlist. Unlike current published playlists available in the art, user-defined descriptor information permits a user to creatively enter free-form text, prose, tags or keywords that the user believes describe characteristics of or feelings or moods set by the user-published playlist. For example, present published playlists permit a user to identify a title, genre, and/or artist information for the playlist. This information is not entirely useful to a third party seeking to find a playlist for a specific purpose, environment, mood, concept, or task, for example. User-defined descriptor information of the present disclosure, as used herein, refers to any type of user-provided text, prose, tags, keywords and/or descriptors describing a user's understanding, perception and/or feelings toward, or the mood set by, a playlist, as opposed to the less descriptive associated metadata namely playlist title, or artist, genre, or media file title, which are static and while factual may not satisfactorily provide sufficient characteristic information. One exemplary embodiment of a user interface capable of receiving user-defined descriptor information is depicted in FIG. 2. Referring to FIG. 2, the user interface comprises a text field box 205 in which a user can enter user-defined descriptor information. In one embodiment, the user-defined descriptor information may comprise a playlist description as entered by the user. Then, by selecting a user input indicia, such as a button 230, the user can save the user-defined playlist information along with the playlist. For example, FIG. 5 depicts a text description box 205 comprising user-defined descriptor information. In FIG. 5, the playlist description box 205 includes the user-defined descriptor information “playlist for while at work. Not ideal for working out.” In one embodiment, each time the playlist is accessed, the user-defined descriptor information also appears along with the playlist. In further embodiments, the user can edit the user-defined descriptor information as many times as the user desires. In another embodiment, the user-defined playlist information entered into the descriptive field box 205 is indexed or serialized along with the playlist information into a storable playlist entry as described in further detail herein.

Referring back to FIG. 1 once the playlist is created 105, a playlist entry is created 110. In one embodiment, the playlist entry is created 105 by serializing the playlist information and user-defined descriptor information into a searchable playlist entry format. In one embodiment, playlist associated metadata may comprise metadata about the playlist itself such as the playlist name, date created, the duration of the playlist etc. Further, the playlist associated metadata may comprise metadata about each media file within the playlist such as the title of the media file, artist, and album, length, date of creation, and/or rating. In one embodiment, the searchable playlist entry format may comprise a series of searchable fields. For instance, an xml file or XSPF file structure. For example, XSPF standard comprises elements or fields such as title, annotation or comment, identity of the creator, info such as a uri or url, canonical ID, image associated with the playlist, creation date, any licensing term, etc. Thus, in one embodiment, when a playlist is created 105, the playlist information and user-defined descriptor information is serialized into a searchable format.

FIG. 4 depicts an exemplary playlist entry 400 derived from a playlist as depicted in FIG. 5. Referring to FIG. 5, the exemplary playlist 505 entitled “Example Playlist” comprises five media files each listed by song title 510, artist name 515, an indicator 520 of whether the playlist is burnable to a cd or not, the genre 525 associated with the media file, the duration 530 of the particular media file, and a rating 535 associated with a media file. For example, the first media file 540 in the playlist 505 is entitled “Brick,” by the artist “Ben Folds Five” which has duration of four minutes and forty-eight seconds. Further, as can be seen in the user interface, the media file 540 is not burnable and is in the Modern Rock genre. Additionally, the playlist description text box 505 has been entered with user-defined descriptor information 505 corresponding to the playlist. Accordingly, the playlist entry corresponding to the playlist 505 can comprise some, all, or none of the information displayed in the user interface. Of course other, non-displayed information associated with the media files within the playlist may comprise the playlist entry.

Accordingly, FIG. 4 depicts an exemplary playlist entry corresponding to the playlist as depicted FIG. 5. As can be seen in FIG. 4, the exemplary playlist entry 400 comprises several fields 405-435. As depicted in FIG. 4, one field 405 comprises a listing of all the titles associated with the media files in the playlist. As seen, field 405 lists: Brick, Amber, Grace, It Ends Tonight, and Only the Good Die Young. Accordingly, with reference to FIG. 5, these are the same titles associated with the media files of the playlist 505. Similarly, another field 410 comprises a listing of all the artists associated with the media files in the playlist. As seen, field 405 lists: Ben Folds, 311, Jeff Buckley, All-American Rejects, and Billy Joel. Accordingly, with reference to FIG. 5, these are the same artists associated with the media files of the playlist 505. Further, field 420 lists the name of the playlist creator, field 420 lists the name of the playlist, and field 430 lists the genre associated with each media file in the playlist. In further embodiments, the playlist entry comprises a field 425 comprising strings of text representing the user-defined descriptor information into the field description box 205 as depicted in FIG. 5. For example, referring to FIG. 5, the text field description box 205 contains the user-defined playlist information: “Playlist for while at work” and “Not ideal for working out.” As described herein, in one embodiment, the playlist application is capable of serializing the user-defined descriptor information entered into the box into a useful field of the playlist entry. In one embodiment, the field 425 may comprise some or all of the text entered into the text field description box 205. Further, all methods known to those skilled in the art of serializing text into a searchable field are contemplated. Thus, the playlist is searchable by user-defined descriptor information. As can be seen in FIG. 4, field 425 comprises the text strings “Playlist for while at work” and “Not ideal for working out.” Further depicted in FIG. 4, a field entry 435 may comprise pointers to the contents of the playlist and/or physically include the contents of the playlist. In a further embodiment a playlist field entry may comprise a playlist id assigned and recognized among an online media service. Accordingly, in one embodiment, a user or entity is capable of searching the contents of the playlist entry. Thus, the user-defined descriptor information can be used to further enhance indexing and searching capabilities. It is noted that not all of the fields in the playlist entry may be capable of searching. In further embodiments, it may be desirable to indicate which types of fields are not preferred for searching such as the member's user name or profile name. Again, in one embodiment, the playlist entry can comprise any combination of field entries gathered from different sources. Thus, in one embodiment, the categorical aggregation of fields into a useful playlist entry allows for efficient playlist searching capabilities.

Referring back to FIG. 1, once the playlist is created 105 and the playlist entry is created 110, the playlist entry is stored 115 in a playlist index and stored 120 in a playlist storage. In one embodiment, with reference to FIG. 3, the playlist storage 345 stores the playlist entries. Thus, the playlist storage contains all playlist information. In one embodiment, the playlist index 375 stores a subset of the playlist entries stored in the playlist storage 355 so that the processor 300 and/or other programs and servers 370 can easily and efficiently access the stored playlist entries.

Turning back to FIG. 1, in one embodiment, the user can elect to publish 125 a playlist. In one embodiment, when the playlist is selected as published 125, the playlist entry is updated within the playlist index 130 and within the playlist storage 135. Similarly, when a public playlist is elected to become private (not depicted), the playlist entry is updated within the playlist index 130 and within the playlist storage 135. In one embodiment, the playlist index 130 and/or playlist storage 135 are not updated simultaneously upon publication or privatization. Instead, the playlist index 130 and/or playlist storage 135 are updated upon a pre-determined time interval. In one embodiment, only public playlists are stored in the playlist index. Thus, by accessing the playlist index for searching a playlist, only published playlists are searchable.

Accordingly, in one embodiment, a user's playlist is by default considered private. Thus, a user must affirmatively choose to make a playlist public. In one embodiment, a user may choose to publish their playlist, for example, by clicking on a user input indicia such as a button or link. The user is preferably given the option of making the published playlist public, thus allowing other users to not only view the playlist but to listen to media listed in the playlist as well. In one embodiment, the published playlist can contain pointers that identify the network location(s) at which the media file resides or may be accessed (a pointer may comprise a URL or URI), metadata or actual media files, although preferably the playlist contains pointers to avoid the need to store multiple copies of the same media file on the network. Thus, a playlist can be made available to a user at any location by publishing the playlist. Thus, the ability to publish a playlist has the added benefit of making the playlist completely portable by being available to all users, as it will be residing on the media server or other user accessible location(s) on the network.

For example, referring to FIG. 2, through an exemplary user interface, the user is able to select the public feature 210 that publishes the playlist. In one embodiment, selecting the public feature 210 causes a visual indictor to appear or highlighting or any other way of emphasizing and indicating that a particular playlist is public. For example, in FIG. 2, the text of the public feature 210 “Make it public” becomes darken and bolded upon selection. Further, the user can select the private 235 feature at any point to remove the playlist from the public. Similar to selecting the public feature 210, selecting the private feature may cause a visual indictor to appear or highlighting or any other way of emphasizing and indicating that a particular playlist is private. Further, as depicted in FIG. 2, a user can also email 220 a playlist, send 215 the playlist via an instant messaging application, or copy 225 the playlist as a url to share with other users, for example by posting it on a blog or website. In a further embodiment, once a playlist is selected as public, it is published on a profile page which may or may not be incorporated into a media management program as described in further detail herein.

In one embodiment, the playlists are searchable through a user interface as depicted in FIG. 5. As can be seen in FIG. 5, the user interface comprises an area 560 for searching for playlists. In one exemplary embodiment, the area for searching 560 for playlists comprises a drop down menu 545 and a text field box 550. As can been seen in FIG. 5, the user can select the “playlist” choice from the drop down menu 545, enter any search criteria into the text field box 550, and select search indicia such as a button 555 to trigger a search for at least one playlist associated with the search criteria. In one embodiment, the playlist program 345 as depicted in FIG. 3 can receive input criteria from a user 330 or other programs and services 370, reference the playlist entries and retrieve and return the appropriate results back to the user's processor 300 and/or other programs and servers 370. In one embodiment, the processor 300 and/or other programs and servers 370 can directly search the playlist index without use of the playlist program. In one embodiment, referring to FIG. 3, when a search input for a playlist is received from the processor 300 and/or other programs and servers 370, it queries the playlist index 375 for matching playlists. In one embodiment, some or all of the information contained in a playlist entry is searchable. In other embodiments, playlist entry information may be included in the entry and used for display in the user interface, but may not be searchable. This could include the number of songs or media files in the playlist, the images associated with the songs in the playlist, the date the playlist was created and modified, and the genre names of the songs in the playlist. Of course, any other associated playlist information may be used as a field entry and may or may not be searchable.

In one embodiment, the playlist search results are returned via a user interface which displays the resultant playlists. In one embodiment, the user interface may be incorporated in a media management program. For example, in FIG. 6, a user can search for playlists by choosing the playlist parameter 605 from a drop down menu 545 and entering search criteria 610 into a text field box 550. Then, a user can select a button 555 to trigger a search for playlists associated with the search criteria.

In one embodiment, the search criteria are used look for matches against the content of all the playlist field entries. For example, if the search criterion 610 is for the term “working” as depicted in FIG. 6, each playlist entry is referenced looking for the term “working.” For example, the term “working” may relate to playlists for a working environment or even return playlists for working out. In any event, the input criterion can search by any string of text representing any portion or entire concept, situation, event, and/or mood. In one embodiment, if any playlist field contains the term, the playlist will be returned to the searching entity. For example, a playlist will be returned if the term “working” is found in the playlist title field, user-defined descriptor information field, artist field, playlist title field, and/or genre field etc. It is important to note that in some embodiments, the playlists storage and playlist index are capable of storing playlist entries from multiple users and multiple sources. Thus, when a playlist search is triggered, a user or entity can search playlists created by any other user or source. Thus, the present disclosure allows users or entities to search for any playlist indexed and stored in the playlist storage and/or playlist index from any creator and from any source.

An exemplary embodiment of the returned results from a playlist search is depicted in FIG. 9. As can be seen in FIG. 9, in one embodiment, the playlists matching the search criteria are displayed in a scrollable area 905. As depicted in FIG. 9, the results of the playlist search may be displayed in columnar format. In other embodiments, the results of the playlist search may be displayed in table format, in a menu, drop down list or any other suitable way. Further, area 905 comprises a list of each of the matching playlist 910, 915, 920, 925, 930, and 935. In one embodiment, as depicted in FIG. 9, each playlist is numbered 815, listed by title 825, by the member and/or user 945 who created and/or owns the playlist, key artists 830, and number 835 of media files within the playlist. In a further embodiment, as depicted in FIG. 9, a playlist may also have listed a description column 950. In one embodiment, the playlist description 950 column lists an excerpt of terms from the user-defined descriptor information text box associated with each playlist. For example, as shown in FIG. 9, the second returned playlist 915 has descriptive terms such as “easy listening” and “mellow” and the third returned playlist 920 has description terms such as “not for working in groups.” Further, in cases where no user-defined descriptor information has been entered and associated with the returned playlist, those returned playlists will not display a description. For example, the first returned playlist 910 has a blank space in the description column 950. In other embodiments, the description column 950 may comprise a URL, uri, or a pointer that directs a user to the full user-defined descriptor information. In other embodiments, simply toggling over the terms in the description column 950 will cause the full description to appear as an enlarged text box.

In a further embodiment, a user can filter the returned playlist results. For example, as depicted in FIG. 9, a drop down menu 940 filters the displayed results by displaying all of the results or some select portion of the displayed playlists. For example, the playlist results may be filtered according to popularity, recency, the identity of the associated members to show only friends' playlists, by usage rights (for example, to display playlists with only subscription content), and/or any identifiable associated playlist attribute such as artist, album or genre. In other embodiments, the filter parameters may be set through a variety of presets or through a preference menu. For example, a preset could be selected for only displaying returned playlists that have the artist matching the search criteria. Of course, many combinations and variations of filter parameters as known to those skilled in the art are contemplated.

In some embodiments, the search criteria used to identify a playlist is highlighted or otherwise emphasized in the user interface. The search term may be highlighted or emphasized using a particular color, a box around the text, via an icon, or any other known method of highlighting or emphasizing text and/or graphics in a user interface. In one aspect, this allows a user to easily view which field or playlist attribute matched the search criteria. For example, referring FIG. 9, since the search criteria 610 was the term “working”; the term is boxed wherever it appears in the returned playlist user interface. As depicted in FIG. 9, the term “working” appears in the description column 950 of the third playlist “80's Music” 920, the fourth playlist “Working Tunes” 925, and the sixth playlist “High Energy” 935. Meaning, in one embodiment, each of these playlists has associated user-defined descriptor information comprising the term “working.” Also, the term is boxed in the title of the fourth playlist “Working Tunes” 925. Thus, in one embodiment, the user interface displays the search term for quick and easy reference.

In other embodiments, instead of highlighting or otherwise emphasizing the search term in the returned playlist display, the display may comprise a column or some type of indicator that indicates where the search term is located with respect to the returned playlist. For example, the indicator or column can indicate that the search term appears in the title of a media file within the playlist, or is a part of the user-defined descriptor information, and so on.

In one embodiment, the returned playlist results are displayed as media file identifiers such as urls, uris, or pointers that can direct a user to the location of the playlist and/or its contents. Thus, through the user interface as depicted in FIG. 9, a user can select any of the returned playlists and/or the member name to further explore information associated with the playlist and/or member such as viewing and/or playing the playlist.

FIG. 10 depicts an exemplary user interface if the “High Energy” playlist 935 is selected from the returned playlist user interface depicted in FIG. 9. As can be seen in FIG. 10, the media files of the selected playlist 935 are listed in an area 1005. Area 1005 lists each media file in the playlist 935 by media file title 1015, artist 1020, and rating 1025. In a further embodiment, as depicted in FIG. 10, a button 1030 allowing a user to add the media file to their local media file collection, a button 1010 allowing a user to play the media file, and a button 1035 allowing a user to purchase the media file and its associated price 1040 are also listed next to each media file of the playlist 915. In a further embodiment, as depicted in FIG. 10, a description text box 205 corresponding to the selected playlist is displayed. As depicted in FIG. 10, the description box 205 comprises user defined descriptor information 1045 “This was my playlist for working out at the gym . . . when I was going to the gym.” Thus, it can be seen that the search term “working” 610 appears the in the user defined descriptor information 1045 associated with the “High Energy” playlist 935.

In a further embodiment, the playlist program is capable of weighting the fields of a playlist in order to determine which playlists with fields matching the search criteria should be returned to the user or entity. For example, the artist name and media file title fields may be weighted more than the creator name field. Thus, a playlist is more likely to be returned if a search criterion is found in the artist name and/or media file name than if in the creator field. In other embodiments, conditional logic is used to determine whether a particular playlist is returned to a user. In other embodiments, a specific count of occurrences of an input criterion in a playlist entry is required in order for a playlist to be returned to a user. In further embodiments, what playlists are returned is based, in part, on affinity relationships. The playlist program can also use the popularity of a playlist as measured by the amount of time other users spend listening to it to influence relevancy by ranking popular playlists higher than unpopular playlists. Playlist size may also be used as part of relevancy to ensure that users who search get useful playlists returned to them. Of course, many combinations and methods of selecting a playlist using search criteria known to those skilled in the art are contemplated.

In one embodiment, once a playlist is selected to be public, it is published on a profile page of a media management program. In another embodiment, a user's profile page is accessible outside the context of a media management program. Thus, in one embodiment, the profile page is accessible from any authorized internet source. In one aspect, a profile page comprises a page which collects and displays various information about a particular user. In one embodiment, all of a particular user's published playlists may be displayed on the user's profile page. FIG. 7 depicts an exemplary embodiment of a user profile page. As can be seen in FIG. 7, the profile page comprises several areas 705, 725, 730, 740 for displaying various types of information about the user. For example, area 725 displays user-defined text that describes the user's musical interests and/or preferences. Further, area 730 displays users applied media file ratings organized by genre, album, and song, and photos of the user's highest-rated artists. Also, area 740 displays a user's listening preferences. As depicted in FIG. 7, the user can edit each area as desired. In particular, area 705 displays a user's published playlists. As can be seen in area 705, two playlists 715, 720 are listed. The profile page may show the playlist titles 750, 745, along with information such as key artists (not depicted), the number of songs in the playlist (not depicted) and description information 755, 760. This description information 755, 760 may or may not be derived from the playlist's associated user-defined descriptor information. Further, a link 710 is provided so that all of the user's published playlist may be viewed.

An exemplary embodiment of a user interface displaying all of a user's published playlists is depicted in FIG. 8. As can be seen in FIG. 8, a user's published playlists are displayed in a scrollable area 810 and are listed by number 815, playlist title and a representative playlist image 825, key artists included in the playlist 830, and a number 835 of total media files within the particular playlist. For example, the first playlist displayed is entitled “Rock Songs” which has five total songs and “The Rolling Stones” and “U2” as the key artists. In one embodiment, the key artist 830 represents the more popular artists as defined by a user, an online music community, or via ratings within the particular playlist. In another embodiment, the key artist 830 represents the artists with the highest reoccurrence within the playlist. In a further embodiment, the area 810 may also comprise a column for listing user-defined descriptor information (not depicted). In a further embodiment, as depicted in FIG. 8, a corresponding categorical menu area 850 comprises a playlist selection 840 which can be expanded 845 to show all playlists. Thus, area 850 allows for easy browsing of a user's playlists. In one embodiment, area 850 provides a visual indicator (not depicted) indicating whether a playlist is public or not. In one embodiment, the visual indicator may comprise highlighting the public playlists, adding a particular icon next to each public playlist, or subdividing the expanded menu 845 (not depicted) into public playlist and private playlists.

Further, in one embodiment, selecting the play 820 button next to each playlist will cause the playlist to be loaded and played by a media management program (such as media player like Yahoo! Music Engine or MusicMatch). Through such a media management program, a user can further manage their playlists. In one embodiment, the following variations and features regarding managing and the collaborative playlist is controlled by the media management program. For example, a media management program's user interface may allow the user to stop, rewind, fast-forward, pause, and or/stop the playing of the playlist. In another embodiment, the user can copy the playlist and rearrange and/or delete media files to customize the playlist. It is contemplated that users will also be able to bookmark other users' playlists, enabling them to keep access to a playlist even as the creator of the playlist makes changes to it.

Providing access of a user's published playlist on a profile page allows users to further get to know other member's and browse their musical tastes. Of course any combination and other areas of information are contemplated. In one embodiment, users can control access to their playlists by making an individual playlist public or private, or by making the entire profile page public or private. Of course it is contemplated that access to a user's playlist may be controlled by further detailed designations. For example, a user can designated that all playlists are only publicly available to a designated list of friends, other users, or specific online community such as a messenger community.

In one embodiment, the ability to share and view playlists among different users will be dependent on certain Digital Rights Management (DRM). In one embodiment, the playlists created and viewed by another user will contain sufficient DRM information to ensure that the user viewing the playlist has sufficient rights or a specific permission level to permit the user to experience the media contained in the playlist. In one embodiment, this function is controlled by the media management program.

In one embodiment, the ability of a user viewing and/or playing of another user's published playlist to access a media file and/or media file identifier is governed by a permission level. In one embodiment, the permission level may be triggered upon the user attempting to view the playlist. In another embodiment, the permission level may be triggered when the user attempts to play the playlist. Meaning, that in one embodiment, the user can view all playlists, but permission levels will control whether a user can play the media files within the published playlist. Thus, in one embodiment, the ability to view and/or play a media file and/or media file identifier in a published playlist may be governed by a permission level. In one exemplary embodiment, the permission level is associated with the media file. In another exemplary embodiment, the permission level is controlled by a subscription from a service provider. Rights and permissions can be managed by a DRM application or an associated media management application or media player or combination thereof.

In an exemplary embodiment, the permission level depends on each user's status as a subscriber or a non-subscriber to an on-demand-streaming media service (ODSMS). For example, if the user who has published a playlist is a subscriber and the user desiring to view and/or play the published playlist is also a subscriber, then the desiring user can have full access to each ODSMS media file identifier on the playlist. In another exemplary embodiment, if the user publishing the playlist is a subscriber to an ODSMS and the user desiring to view and/or play the published playlist is a non-subscriber, then the desiring user may have limited access to the ODSMS media files. For example, the desiring user may be limited to a pre-determined length clip of each ODSMS media file, such as a 30-second clip when the desiring user plays the media file. In another example, the desiring user may be given a pre-determined number of times the user can play each ODSMS media file. After this pre-determined number of times has been reached, the user is then limited to a default, pre-determined length of time for each media file (such as a 30-second clip). For example, the non-subscribing, desiring user may be limited to playing an ODSMS media file at its full-length to three times. Thus, once the user had played the media file and/or media file identifier three times, the user can now only listen to 30 second clips of the media file. This allows a non-subscribing desiring user to listen to ODSMS music otherwise not available to the user, while enticing the user to subscribe to the service. Accordingly, in one embodiment, once the user's pre-determined numbers of full-length plays are used, the user is prompted and has the option to subscribe to the ODSMS.

Of course, these embodiments are not limited to ODSMS media files, but can apply to any media files which require a specified level of sharing, viewing, and/or playing access. For example, it could be negotiated that certain media files generally not available for full-length sharing could be shared and played between any status (subscribing or non-subscribing) of users for a pre-determined number of times. For example, if there is a particular artist who wants to promote and/or entice users to listen to their media files, the artist or their representatives can allow a particular media file to be able to be viewed and/or played among any type of users. However, the users are limited to playing the media file to a certain number of times.

In another embodiment, the user can further utilize the collaborative playlist by burning the playlist to a CD or transferring the media files to a portable device. For example, the user can burn the media filed listed in playlist in the media player window to a CD and/or transfer the media files to a portable device by clicking a button and selecting the option from a drop-down menu. In some embodiments, the ability to transfer media files to a portable device or burn media files to a CD may depend on whether the user has specified access to those media files. Particularly, the user may be required to pay for files not located on the user's local media library. For example, the user may be required to pay for files located on an on-demand, streaming media service. Thus, the user may be required to pay a price for each media file before downloading or burning the media files. In another example, the user may be required to be subscriber to a service that allows the user to download and burn media files. In a further embodiment, the user can perform any of the above managing functions in any combination as the user desires using the media management program.

In a further embodiment, as depicted in FIG. 3, other programs or applications and multiple users 370 can access the playlist program 345 and the playlist storage 355 to search for playlists from non-media management applications. For example, other Yahoo! applications such as Yahoo! Search could access the playlists and enable users to create, edit, and share playlists through the Search user interface.

In some embodiments, the playlist entries within the playlist storage 355 and/or playlist index 375 are updated with all of a user's newly created or edited playlists. In one embodiment, it is important to keep the playlist storage and/or playlist index currently updated with all the newly created playlists and any edits made to the existing playlists via a user's local processor. In one embodiment, synchronizing all playlist edits and newly created playlists among each user's local processor and the playlist storage and/or playlist index requires both that each playlist be associated with an easy identifiable id and a technique for noting whether each particular playlist has been synchronized. For example, in one embodiment, once a playlist is created, it is associated with an id. In one embodiment, the id is generated by an online media service. Thus, the playlist is recognizable throughout the service via its associated id. In further embodiments, other online communities or media services may have access to these playlist ids in order to catalogue, identify, and/or otherwise interface with the playlists by their associated id.

In one embodiment, the list of playlists and its associated ids are maintained in a database 380 stored on a user's local processor 300 as depicted in FIG. 3. In one embodiment, the local database communicates with all of the components of the local processor 300 including the media engine 305. Further, in one embodiment, this local database 380 also maintains a status list or status table comprising each playlist, its associated id, and a flag, marker, or other type of identifier indicating whether that playlist has been fully updated with respect to the playlist storage 355 and/or playlist index 375. In one embodiment, the status table comprises only two states, updated and not-updated. In one embodiment, a playlist is considered not-updated if any type of edit has been made to a particular playlist, or a new playlist has been created and the playlist has not been synchronized with the playlist storage 355 and/or playlist index 375. Thus, the local media engine 305 can reference the database's status table to determine whether a particular playlist needs to be synchronized with playlist storage 355 and/or playlist index 375.

An exemplary synchronization process is depicted in FIG. 11. An exemplary system architecture or configuration supporting the synchronization process of FIG. 11 is depicted in FIG. 3. Referring to FIG. 11, the synchronization process may be triggered 1105 based on a particular time interval such as every 15 minutes or every 30 minutes. In another embodiment, the synchronization process may be triggered 1105 by an event such as starting the playlist application. In yet another embodiment, the synchronization process may be triggered when the user changes any part of a playlist.

Once the process is triggered 1105, with reference to both FIG. 11 and FIG. 3 the local media engine 305 will request the local database 380 to upload to the playlist storage 355 and/or playlist index 375 any playlists that are flagged as not updated. In another embodiment, a playlist is flagged as updated when a user creates a new playlist or when the user modifies an existing playlist. If the upload is successful 1115, the local media engine 305 flags the each successfully uploaded playlists as updated. In one embodiment, if the upload is not successful 1120 or partially successful, each unsuccessfully uploaded playlist will remain flagged as not updated.

In some embodiments, multiple processors at different locations may be utilized by a single user and/or subscriber to an online media service. An exemplary system configuration comprising multiple processor ids depicted in FIG. 13. As depicted in FIG. 13, the system configuration has the same configuration and functionality as in FIG. 3, however with an additional processor 1300 and user 1330. For example, a user may have a processor at home 300 and a processor 1300 at work and would like to access all updated playlists from each processor 300, 1300. Thus, it is desirable to further synchronize the edited playlists and any new playlists among each of the processors 300, 1300. In one embodiment, media server 360 and/or playlist storage 355 maintains a list of each user's processor wherein each processor is associated with an id. For example, with reference to FIG. 13, processor 300 has an associate id of “ABC” and processor 1300 has an associated id of “DEF.” In a further embodiment, this list is maintained on the playlist program 345, and/or playlist index 375. In one embodiment, when a playlist is updated and uploaded to the media server 360 and/or playlist storage 355 as depicted in FIG. 13, the media server 360 and/or playlist storage 355 will note which processor, via processor id, sent the uploaded playlists. Thus, the media server 360 and/or playlist storage 355 will know which processor ids have the uploaded and updated playlists and which processor ids do not have the uploaded and updated playlists. An exemplary synchronization process is depicted in FIG. 12. An exemplary system architecture or configuration supporting such a synchronization process is depicted in FIG. 13. It should be noted that this process applies to any number of processors and the descriptions are merely exemplary with respect to processor 1300. Further the actions performed by the processor 1300 as FIG. 12 and FIG. 13 can also be performed by the media engine 1305. Referring both to FIG. 12 and FIG. 13, first, the synchronization process is triggered 1205. In one embodiment, the process may be trigged by a pre-determined, configurable time interval or by an event such as a user logging onto a processor. Once the process is triggered 1205, the local processor 1300 requests 1210 from the playlist storage 355 to download any newly edited or newly created playlists to the local processor 1300. Further, in one embodiment, this request 1210 may or may not be facilitated by the media server 360 and/or playlist program 345 as depicted in FIG. 13.

Upon the request 1210, the playlist storage 355 and/or playlist index 375 references the requesting processor's 1300 id to determine whether it already has the updated playlists. If the processor 1300 already has the updated playlists, then the playlist storage 355 and/or playlist index 375 will not need to download 1220 any information to the requesting processor 1300. If the processor 1300 does not have all the updated playlists, the playlist storage 355, and/or playlist index 375 sends 1225 a list of the playlist ids to be downloaded to the requesting processor 1300. In addition, when the list of playlist ids is downloaded to the requesting processor 1225, the local processor 1300 flags each downloaded playlist as not-updated. Thus, when appropriate, the local processor will synchronize the appropriate playlists as depicted in FIG. 11 and when successfully downloaded, will flag each playlist as updated.

Playlists are not limited to music files and can include other audio or video files. For example, this system could be used to build playlists of music videos or to develop playable lists of music, audio news, commentary, rrs feeds, podcasts, still images, and video content. In a future application, users could be given tools to syndicate a playlist as an audio or video podcast.

Those skilled in the art will recognize that the method and system of the present disclosure within the application may be implemented in many manners and as such is not to be limited by the foregoing exemplary embodiments and examples. In other words, functional elements being performed by a single or multiple components, in various combinations of hardware and software, and individual functions can be distributed among software applications at either the client or server level. In this regard, any number of the features of the different embodiments described herein may be combined into one single embodiment and alternate embodiments having fewer than or more than all of the features herein described are possible. Functionality may also be, in whole or in part, distributed among multiple components, in manners now known or to become known. Thus, myriad software/hardware/firmware combinations are possible in achieving the functions, features, interfaces, and preferences described herein. Moreover, the scope of the present disclosure covers conventionally known and features of those variations and modifications through the system component described herein as would be understood by those skilled in the art.

Claims

1. A computer-implemented method of identifying a published playlist comprising:

receiving, by at least one processing unit and from a searching entity, search criteria representing a desire to identify a playlist by a search, the search comprising a search of user-defined playlist descriptor information;
accessing, by the at least one processing unit, a playlist storage, said playlist storage comprising user published and unpublished playlists, some or all of said published and unpublished playlists each comprising title, artist and genre information for each of the playlist's media files in a plurality of playlist fields, each playlist further comprising a title field containing a title of the playlist and another playlist field containing said user-defined playlist descriptor information, said playlist field containing said user-defined playlist descriptor information comprising user-provided text describing one or more of the user's understanding, perception, and feelings toward the playlist in addition to and different from said title field containing said title of the playlist;
searching, by the at least one processing unit, for published playlists of said playlist storage, said search comprising searching one or more playlist fields including searching the user-defined playlist descriptor field containing said user-defined playlist descriptor information to identify a desired playlist result set comprising user published playlists with user-defined playlist descriptor information relevant to said search criteria, at least one field of the one or more fields having an assigned weight for use in determining which user published playlists to include in the playlist result set;
communicating, by the at least one processing unit, said desired playlist result set to said searching entity, wherein said desired playlist result set comprises a playlist identifier comprising a pointer, metadata associated with said desired playlist results set, and a permission level for accessing said desired playlist results, wherein said permission level is associated with an online media service; and
synchronizing, upon receiving an edit to said playlist, said user-defined playlist descriptor information and said associated playlist information with said playlist storage.

2. The method of claim 1 wherein said searching entity comprises a user located on a computing device.

3. The method of claim 1 wherein said searching entity comprises a software program.

4. The method of claim 1 wherein said search criteria comprises a mood associated with said desired playlist.

5. The method of claim 1 wherein said search criteria comprises a situation associated with said desired playlist.

6. The method of claim 1 wherein said search criteria comprises an event associated with said desired playlist.

7. The method of claim 1 wherein said playlist storage is located on a server.

8. The method of claim 1 wherein said playlist storage is located on the Internet.

9. The method of claim 1 wherein said playlist storage is located as a part of an online media service.

10. The method of claim 1 wherein said desired playlist result set comprises a playlist identifier.

11. The method of claim 10 wherein said identifier is a uniform resource locator.

12. The method of claim 10 wherein said identifier is a universal resource indicator.

13. The method of claim 1 wherein said desired playlist results set comprises an id associated with said desired playlist.

14. The method of claim 1 further comprising facilitating the display of said desired playlist result set at a computing device associated with said searching entity.

15. A computer-implemented method of creating a searchable playlist comprising:

receiving, by at least one processing unit, at least one media file selection indicating the desire to include at least one media file in a playlist;
receiving, by the at least one processing unit, user-defined playlist descriptor information associated with said playlist, said user-defined playlist descriptor information comprising user-provided text describing one or more of the user's understanding, perception, and feelings toward the playlist in addition to and different from a title of the playlist;
receiving, by the at least one processing unit, an input indicating the desire to designate said playlist as public, said public designation causing said user-defined playlist descriptor information and information associated with said playlist to be searchable by a searching entity, said associated playlist information comprising title, artist and genre information for each of the playlist's media files and the title of the playlist;
creating, by the at least one processing unit, a playlist comprising, for each media file selection, title, artist and genre information contained in a plurality of fields of said playlist, said playlist further comprising the title field containing the title of said playlist and another playlist field containing said user-defined playlist descriptor information, said user-defined playlist descriptor playlist field containing said user-defined playlist descriptor information is in addition to and different from said title field containing said title of said playlist; and
communicating, by the at least one processing unit, said created playlist to a playlist storage of published and unpublished playlists, some or all of the published and unpublished playlists each comprising said user-defined playlist descriptor information field, said playlist storage storing said playlist comprising said user-defined playlist descriptor information field containing said user-defined playlist descriptor information can be searched by a searching entity to identify one or more published playlists in a search, the search comprising a search of said user-defined playlist descriptor information field containing said user-defined playlist descriptor information, one or more of the user-defined playlist descriptor information, title, artist, genre and playlist title having an assigned weight for use by the searching entity in identifying the one or more published playlists in the search, wherein said created playlist comprises a playlist identifier comprising a pointer, metadata associated with said created playlist, and a permission level for accessing said created playlist, wherein said permission level is associated with an online media service; and
synchronizing, upon receiving an edit to said created playlist, said user-defined playlist descriptor information and said associated playlist information with said playlist storage.

16. The method of claim 15 wherein said playlist storage is located on a server.

17. The method of claim 15 wherein said playlist storage is located on the Internet.

18. The method of claim 15 wherein said playlist storage is located as a part of an online media service.

19. The method of claim 15 wherein said playlist information comprises a rating associated with said media file.

20. The method of claim 15 wherein said searching entity comprises a user.

21. The method of claim 15 wherein said searching entity comprises a software program.

22. The method of claim 15 wherein said user developed text is searchable by search input criteria.

23. The method of claim 22 wherein said search input criteria comprises a mood associated with said playlist.

24. The method of claim 22 wherein said search input criteria comprises a situation associated with said desired playlist.

25. The method of claim 22 wherein said search criteria input comprises an event associated with said desired playlist.

26. The method of claim 15 wherein said user defined text comprises a mood associated with said playlist.

27. The method of claim 15 wherein said user developed text comprises a situation associated with said playlist.

28. The method of claim 15 wherein said user developed text comprises an event associated with said playlist.

29. The method of claim 15 wherein said user-defined playlist descriptor information and said associated playlist information comprise a format comprising a set of searchable field entries.

30. The method of claim 29 wherein said set of searchable field entries comprise a portion of said user developed text.

31. The method of claim 29 wherein said set of searchable field entries comprise all of said user developed text.

32. The method of claim 29 wherein said set of searchable field entries comprise a portion of said associated playlist information.

33. The method of claim 15 further comprising synchronizing, upon receiving an edit to said playlist, said user-defined playlist descriptor information and said associated playlist information with said playlist storage.

34. The method of claim 33 wherein said edit comprises an input indicating the desire to designate said playlist as private.

35. The method of claim 15 wherein said storing said user-defined playlist descriptor information and said associated playlist information into a searchable format comprises serializing said user-defined playlist descriptor information and said associated playlist information.

36. One or more computer-readable storage media storing computer-readable instructions thereon which, when executed by one or more computing devices, implements the method of claim 15.

37. One or more computer-readable storage media storing computer-readable instructions thereon which, when executed by one or more computing devices, implements the method of claim 1.

Referenced Cited
U.S. Patent Documents
5566353 October 15, 1996 Cho et al.
5616876 April 1, 1997 Cluts
5729741 March 17, 1998 Liaguno et al.
5748956 May 5, 1998 Lafer et al.
5864870 January 26, 1999 Guck
5886698 March 23, 1999 Sciammarella et al.
5890152 March 30, 1999 Rapaport et al.
5903892 May 11, 1999 Hoffert et al.
5928330 July 27, 1999 Goetz et al.
5950173 September 7, 1999 Perkowski
5982369 November 9, 1999 Sciammarella et al.
5996015 November 30, 1999 Day et al.
6064380 May 16, 2000 Swenson et al.
6073727 June 13, 2000 DiFranza et al.
6118450 September 12, 2000 Proehl et al.
6157377 December 5, 2000 Shah-Nazaroff et al.
6192340 February 20, 2001 Abecassis
6226672 May 1, 2001 DeMartin et al.
6232539 May 15, 2001 Looney et al.
6248946 June 19, 2001 Dwek
6356971 March 12, 2002 Katz et al.
6389467 May 14, 2002 Eyal
6393430 May 21, 2002 Van Ryzin
6446080 September 3, 2002 Van Ryzin et al.
6466918 October 15, 2002 Spiegel et al.
6477704 November 5, 2002 Cremia
6484157 November 19, 2002 Chowdhury et al.
6484199 November 19, 2002 Eyal
6526411 February 25, 2003 Ward
6538665 March 25, 2003 Crow et al.
6587127 July 1, 2003 Leeke et al.
6605770 August 12, 2003 Yamane et al.
6609096 August 19, 2003 De Bonet et al.
6657116 December 2, 2003 Gunnerson
6662231 December 9, 2003 Drosset et al.
6691162 February 10, 2004 Wick
6721489 April 13, 2004 Benyamin et al.
6728729 April 27, 2004 Jawa et al.
6731312 May 4, 2004 Robbin
6735628 May 11, 2004 Eyal
6738766 May 18, 2004 Peng
6760721 July 6, 2004 Chasen et al.
6763345 July 13, 2004 Hempleman et al.
6772212 August 3, 2004 Lau et al.
6816944 November 9, 2004 Peng
6820238 November 16, 2004 Auflick et al.
6829033 December 7, 2004 Hose et al.
6850256 February 1, 2005 Crow et al.
6928433 August 9, 2005 Goodman et al.
6933433 August 23, 2005 Porteus et al.
6941324 September 6, 2005 Plastina et al.
6943324 September 13, 2005 Ahuja
6968179 November 22, 2005 De Vries
6987221 January 17, 2006 Platt
7013290 March 14, 2006 Ananian
7020704 March 28, 2006 Lipscomb et al.
7024424 April 4, 2006 Platt et al.
7043477 May 9, 2006 Mercer et al.
7096234 August 22, 2006 Plastina et al.
7111009 September 19, 2006 Gupta et al.
7113767 September 26, 2006 Vaananen
7127454 October 24, 2006 Deguchi
7136874 November 14, 2006 Mercer et al.
7146404 December 5, 2006 Kay et al.
7159000 January 2, 2007 Plastina et al.
7219308 May 15, 2007 Novak et al.
7275063 September 25, 2007 Horn
7277852 October 2, 2007 Iyoku et al.
7281034 October 9, 2007 Eyal
7310350 December 18, 2007 Shao et al.
7409639 August 5, 2008 Dempski et al.
7599610 October 6, 2009 Benyamin et al.
7840620 November 23, 2010 Vignoli et al.
20010013061 August 9, 2001 DeMartin et al.
20010018858 September 6, 2001 Dwek
20010025256 September 27, 2001 Oliphant et al.
20010033296 October 25, 2001 Fullerton et al.
20010042107 November 15, 2001 Palm
20010047290 November 29, 2001 Petras et al.
20020002498 January 3, 2002 Hatakeyama
20020010652 January 24, 2002 Deguchi
20020013784 January 31, 2002 Swanson
20020040326 April 4, 2002 Spratt
20020042834 April 11, 2002 Kremens et al.
20020045960 April 18, 2002 Phillips et al.
20020049037 April 25, 2002 Christensen et al.
20020052933 May 2, 2002 Leonhard et al.
20020054134 May 9, 2002 Kelts
20020072967 June 13, 2002 Jacobs et al.
20020083031 June 27, 2002 De Varax
20020087887 July 4, 2002 Busam et al.
20020089529 July 11, 2002 Robbin
20020093884 July 18, 2002 Hochendoner
20020099731 July 25, 2002 Abajian
20020103797 August 1, 2002 Goel et al.
20020113824 August 22, 2002 Myers, Jr.
20020120925 August 29, 2002 Logan
20020126135 September 12, 2002 Ball et al.
20020138619 September 26, 2002 Ramaley et al.
20020151327 October 17, 2002 Levitt
20020152267 October 17, 2002 Lennon
20020156546 October 24, 2002 Ramaswamy
20020184623 December 5, 2002 Hodge et al.
20020188363 December 12, 2002 Ashy
20020194260 December 19, 2002 Headley et al.
20030014767 January 16, 2003 Stumphauzer, II
20030023427 January 30, 2003 Cassin et al.
20030023975 January 30, 2003 Schrader et al.
20030028539 February 6, 2003 Nunome et al.
20030031176 February 13, 2003 Sim
20030037035 February 20, 2003 Deguchi
20030041108 February 27, 2003 Henrick et al.
20030046273 March 6, 2003 Deshpande
20030046399 March 6, 2003 Boulter et al.
20030050834 March 13, 2003 Caplan
20030065639 April 3, 2003 Fiennes et al.
20030071851 April 17, 2003 Unger et al.
20030088571 May 8, 2003 Ekkel
20030110502 June 12, 2003 Creed et al.
20030151618 August 14, 2003 Johnson et al.
20030158737 August 21, 2003 Csicsatka
20030172090 September 11, 2003 Asunmaa et al.
20030182254 September 25, 2003 Plastina et al.
20030182315 September 25, 2003 Plastina et al.
20030191753 October 9, 2003 Hoch
20030200452 October 23, 2003 Tagawa et al.
20030202431 October 30, 2003 Kim et al.
20030212710 November 13, 2003 Guy
20030222907 December 4, 2003 Heikes et al.
20030223411 December 4, 2003 de la Fuente
20030225834 December 4, 2003 Lee et al.
20030225848 December 4, 2003 Heikes et al.
20030228134 December 11, 2003 Kim et al.
20030235402 December 25, 2003 Seo et al.
20030236582 December 25, 2003 Zamir et al.
20030236711 December 25, 2003 Deguchi
20030236832 December 25, 2003 McIntyre et al.
20030237043 December 25, 2003 Novak
20040002938 January 1, 2004 Deguchi
20040003090 January 1, 2004 Deeds
20040003398 January 1, 2004 Donian et al.
20040003706 January 8, 2004 Tagawa et al.
20040019497 January 29, 2004 Volk et al.
20040019658 January 29, 2004 Plastina et al.
20040055445 March 25, 2004 Iyoku et al.
20040056901 March 25, 2004 March et al.
20040057348 March 25, 2004 Shteyn et al.
20040057449 March 25, 2004 Black
20040064476 April 1, 2004 Rounds
20040068606 April 8, 2004 Kim et al.
20040078383 April 22, 2004 Mercer et al.
20040083273 April 29, 2004 Madison et al.
20040088348 May 6, 2004 Yeager et al.
20040103153 May 27, 2004 Chang et al.
20040109137 June 10, 2004 Bubie et al.
20040117442 June 17, 2004 Thielen
20040117843 June 17, 2004 Karaoguz et al.
20040123725 July 1, 2004 Kim
20040128308 July 1, 2004 Obrador
20040137882 July 15, 2004 Forsyth
20040148353 July 29, 2004 Karaoguz et al.
20040162871 August 19, 2004 Pabla et al.
20040162878 August 19, 2004 Lewis et al.
20040174905 September 9, 2004 Caspi et al.
20040177115 September 9, 2004 Hollander et al.
20040177116 September 9, 2004 McConn
20040181517 September 16, 2004 Jung et al.
20040181540 September 16, 2004 Jung et al.
20040184778 September 23, 2004 Jung et al.
20040196315 October 7, 2004 Swearingen et al.
20040199387 October 7, 2004 Wang et al.
20040199667 October 7, 2004 Dobbins
20040201609 October 14, 2004 Obrador
20040202335 October 14, 2004 Lee et al.
20040205028 October 14, 2004 Verosub et al.
20040215731 October 28, 2004 Tzann-en Szeto
20040220791 November 4, 2004 Lamkin et al.
20040220926 November 4, 2004 Lamkin et al.
20040221299 November 4, 2004 Gibbs et al.
20040224675 November 11, 2004 Puskoor et al.
20040226039 November 11, 2004 Jung et al.
20040228618 November 18, 2004 Yoo et al.
20040236568 November 25, 2004 Guillen et al.
20040252604 December 16, 2004 Johnson et al.
20040260753 December 23, 2004 Regan
20040267812 December 30, 2004 Harris et al.
20050004985 January 6, 2005 Stochosky
20050004995 January 6, 2005 Stochosky
20050021398 January 27, 2005 McCleskey et al.
20050021470 January 27, 2005 Martin et al.
20050021750 January 27, 2005 Abrams
20050027539 February 3, 2005 Weber et al.
20050038707 February 17, 2005 Roever et al.
20050038724 February 17, 2005 Roever et al.
20050038814 February 17, 2005 Iyengar et al.
20050038819 February 17, 2005 Hicken et al.
20050038877 February 17, 2005 Gupta et al.
20050044229 February 24, 2005 Brown
20050044574 February 24, 2005 Lau et al.
20050055472 March 10, 2005 Krzyzanowski et al.
20050060264 March 17, 2005 Schrock et al.
20050060350 March 17, 2005 Baum et al.
20050065935 March 24, 2005 Chebolu et al.
20050071780 March 31, 2005 Muller et al.
20050086309 April 21, 2005 Galli et al.
20050086606 April 21, 2005 Blennerhassett et al.
20050091069 April 28, 2005 Chuang
20050091283 April 28, 2005 Debique et al.
20050096018 May 5, 2005 White et al.
20050102191 May 12, 2005 Heller
20050108176 May 19, 2005 Jarol et al.
20050108320 May 19, 2005 Lord et al.
20050114324 May 26, 2005 Mayer
20050114374 May 26, 2005 Juszkiewicz et al.
20050123268 June 9, 2005 Kawaguchi et al.
20050138543 June 23, 2005 Liu
20050146996 July 7, 2005 Roman
20050160111 July 21, 2005 Plastina et al.
20050172001 August 4, 2005 Zaner et al.
20050197906 September 8, 2005 Kindig et al.
20050198317 September 8, 2005 Byers
20050210396 September 22, 2005 Galli
20050210507 September 22, 2005 Hawkins et al.
20050216443 September 29, 2005 Morton et al.
20050216855 September 29, 2005 Kopra et al.
20050227676 October 13, 2005 De Vries
20050234875 October 20, 2005 Auerbach et al.
20050234995 October 20, 2005 Plastina et al.
20050240494 October 27, 2005 Cue et al.
20050246651 November 3, 2005 Krzanowski
20050251565 November 10, 2005 Weel
20050251566 November 10, 2005 Weel
20050251576 November 10, 2005 Weel
20050251807 November 10, 2005 Weel
20050262186 November 24, 2005 Szeto
20060008256 January 12, 2006 Khedouri et al.
20060010240 January 12, 2006 Chuah
20060031770 February 9, 2006 McMenamin
20060041627 February 23, 2006 Tu
20060056324 March 16, 2006 Hyyppa et al.
20060080103 April 13, 2006 Van Breemen
20060088292 April 27, 2006 Guillen et al.
20060095502 May 4, 2006 Lewis et al.
20060095848 May 4, 2006 Naik
20060107297 May 18, 2006 Toyama et al.
20060123058 June 8, 2006 Mercer et al.
20060123113 June 8, 2006 Friedman
20060133768 June 22, 2006 Ellis
20060143236 June 29, 2006 Wu
20060167985 July 27, 2006 Albanese et al.
20060168340 July 27, 2006 Heller et al.
20060173838 August 3, 2006 Garg et al.
20060190410 August 24, 2006 Harper
20060195462 August 31, 2006 Rogers
20060218195 September 28, 2006 LaChapelle et al.
20070011206 January 11, 2007 Gupta et al.
20070016865 January 18, 2007 Johnson et al.
20070050413 March 1, 2007 Kominek et al.
20070143740 June 21, 2007 Hoerentrup et al.
20070159934 July 12, 2007 Weon
20070191108 August 16, 2007 Brunet De Courssou et al.
20080133576 June 5, 2008 Hempleman et al.
20080215882 September 4, 2008 Coldicott et al.
Foreign Patent Documents
1 176 840 January 2002 EP
1 489 800 December 2004 EP
WO 02/33579 April 2002 WO
WO 2004/046874 June 2004 WO
Other references
  • Tzanetakis, George, “Musescape: A Tool for Changing Music Collections into Libraries”, ECDL 2003, LNCS 2769, Springer-Verlag, Berlin, Feb. 26, 2004, pp. 412-421.
  • Cano, Pedro, et al., “MTG-DD: A Repository for Music Audio Processing”, WEDELMUSIC '04, Sep. 13-14, 2004, pp. 2-9.
  • Vinet, Hugues, et al., “The CUIDADO Project”, IRCAM, © 2002, pp. 1-7.
  • Bayardo, Roberto J., et al., “Peer-to-Peer Sharing of Web Applications”, WWW 2003, Budapest, Hungary, May 20-24, 2003, pp. 1-2.
  • Microsoft Computer Dictionary, 5th Edition, Microsoft Press, Redmond, WA, © 2002, pp. 19, 410, 539 and 542.
  • Hayes, Conor, et al., “Context Boosting Collaborative Recommendation”, Knowledge-Based Systems, vol. 17, Issues 2-4, May 2004, pp. 131-138.
  • Pachet, François, et al., “Content Management for Electronic Music Distribution”, Communications of the ACM, vol. 46, No. 4, Apr. 2003, pp. 71-75.
  • Drucker, Steven M., et al., “MediaBrowser: Reclaiming the Shoebox”, AVI '04, Gallipoli, Italy, May 25-28, 2004, pp. 433-436.
  • “XSPF: XML Shareable Playlist Format: Specifications—The XSPF Playlist Format, version 0”, xspf.org/specs, May 2004, 14 pages.
  • XSPF: XML Shareable Playlist Format: Applications—Yahoo! Music Jukebox (Windows), xspf.org/applications, downloaded Apr. 13, 2011, 7 pages.
  • David Bainbridge, Sally Jo Cunningham, and J. Stephen Downie—“Visual Collaging of Music in a Digital Library”—http://hdl.handle.net/10289/43—In Proceedings: Fifth International Conference on Music Information Retrieval. ISMIR 2004: Oct. 10-14, 2004, Barcelona, Spain. (c) 2004 Universitat Pompeu Fabra n—(pp. 1-6).
  • Mark van Setten and Erik Oltmans—“Demonstration of A Distributed MPEG-7 Video Search and Retrieval Application in the Educational Domain”—Proceeding Multimedia '01 Proceedings of the ninth ACM international conference on Multimedia—2001 ACM Sep.-Oct. 5, 2001, Ottawa, Canada—(pp. 595-596).
  • Notification Concerning Transmittal of International Preliminary Report on Patentability dated Oct. 4, 2007 PCT/US06/006440.
  • Notification Concerning Transmittal of International Preliminary Report on Patentability dated Sep. 20, 2007 PCT/US06/006934.
  • Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the declaration dated Oct. 19, 2007 PCT/US06/06683.
  • International Search Report (PCT/US06/06440).
  • Notification Concerning Transmittal of International Preliminary Report on Patentability (PCT/US2006/006687).
  • Notification of Transmittal of The International Search Report and the Written Opinion of The International Searching Authority, or the Declaration (PCT/US06/07124).
  • Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration (PCT/US06/06685).
  • International Preliminary Report on Patentability (PCT/US2006/006932); Mar. 17, 2009; 7 pages.
  • Bassoli, Andrea, et al., “tunA: Local Music Sharing with Handheld Wi-Fi Devices”, Proc. of the 5th Wireless World Conf. 2004, pp. 1-23.
  • Pachet, Francois, et al., “Content Management for Electronic Music Distribution”, Communications of the ACM, vol. 46, Issue 4, Apr. 2003, pp. 71-75.
  • Swain, Michael J. “Searching for Multimedia on the World Wide Web”, IEEE Conf. on Multimedia Computing and Systems, vol. 1, Jun. 7-11, 1999, pp. 32-37.
  • Lienhart, Rainer, et al., “Improving Media Services on P2P Networks”, IEEE Internet Computing, vol. 6, Issue 1, Jan.-Feb. 2002, pp. 73-77.
  • Davies, Nigel, et al. “Supporting Adaptive Video Applications in Mobile Environments”, IEEE Communications Magazine, vol. 36, issue 6, Jun. 1998, pp. 138-143.
  • Macedonia, Michael, “Distributed File Sharing: Barbarians at the Gates?”, Computer, vol. 33, Issue 8, Aug. 2000, pp. 99-101.
  • Swierk, et al. “The Roma Personal Metadata Service”, Mobile Networks and Applications, vol. 7, No. 5, Oct. 2002, pp. 407-418.
  • Qian, Yuechen, et al. “Exploring the Potentials of Combining Photo Annotating Tasks with Instant Messaging Fun”, MUM 2004, College Park, MD, Oct. 27-29, 2004, pp. 11-17.
  • Regan, Tim, et al. “Media Center Buddies: Instant Messaging Around a Media Center”, NordiCHI '04, Tampere, Finiad, Oct. 23-27, 2004, pp. 141-144.
  • Gottesman, Ben Z., “IM Your Photos”, PCMag.com, Dec. 11, 2003, pp. 1-2 (downloaded from www.pcmag.com/print—article2/0,1217,a=114405,00.asp).
  • Bassoli, Arianna et al., “TunA: A Mobile Music Experience to Foster Local Interactions”, UbiComp 2003, Seattle, WA, Oct. 12-15, 2003, pp. 1-2.
  • Grinter, Rebecca E., et al. “Instant Messaging in Teen Life”, CSCW '02, New Orleans, LA, Nov. 16-20, 2002, pp. 21-30.
  • Qian, Yuechen, et al. “Turning Photo Annotating Tasks into Instant Messaging Fun: Prototyping, User Trials and Road Mapping, ”ICEC 2004, LCNS 3166, vol. 3166/2004, Springer, Berlin, Aug. 4, 2004, pp. 610-613.
  • Coursey, David, “My Favorite Ways to Share Digital Photos”, ZDNet, Nov. 7, 2003, pp. 1-3 (downloaded from reviewzdnet.com/AnchorDesk/4520-7298—16-5103567.html).
  • Bolcer, Gregory Alan., “Magi:An Architecture for Mobile and Disconnected Workflow”, IEEE Internet Computing, vol. 4 Issue 3, May/Jun 2000, pp. 46-54.
  • Rajani, Rakhi E., et al., “Viewing and Annotating Media with MemoryNet”, CHI 2004, Vienna, Austria, Apr. 24-29, 2004, pp. 1517-1520.
  • Microsoft Computer Dictionary, 4th Edition, Microsoft Press, Redmond, WA, 1999, p. 348.
  • Bayardo, Roberto J., et al. “Peer-to-Peer Sharing of Web Applications”, WWW 2003, Budapest, Hungary, May 20-24, 2003, pp. 1-2.
  • Gradman, Eric, “Distributed Social Software”, Dec. 12, 2003, pp. 1-10.
  • Pachet, Francois, et al. “Popular Music Access: The Sony Music Browser”, Journal of the American Society for Information Science and Technology, vol. 55, Issue 12, May 13, 2004, pp. 1037-1044.
  • Wolz, Ursula, et al., “r-Music, A Collaborative Music DJ for Ad Hoc Networks,”, WEDELMUSIC '04, Sep. 13-14, 2004, pp. 144-150.
  • Crossen, Andrew, et al., “Flytrap: Intelligent Group Music Recommendation”, RIDE-VE '99, Sydney, Australia, Mar. 23-24, 1999, pp. 148-155.
  • Hauver, David B., et al., “Flycasting: USing Collaborative Filtering to Generate a Playlist for Online Radio”, WEDELMUSIC '01 Nov. 23-24, 2001, pp. 123-130.
  • Ku, William, et al., “Survey on the Technological Aspects of Digital Rights Management”, ISC 2004, LNCS 3225, Springer, Berlin, Sep. 21, 2004, pp. 391-403.
  • Liang, Qianhui, et al. “A United Approach to Discover Multimedia Web Services”, ISMSE '03, Dec. 10-12, 2003, pp. 62-69.
  • Microsoft Computer Dictionary, 4th Edition, Microsoft Press, Redmond, WA, 1999, p. 348 and 461.
  • Imad M. Abbadi, Chris J. Mitchell, “Digital Rights Management Using A Mobile Phone”, Aug. 2007, ICEC '07: Proceedings of the ninth international conference on Electronic commerce, Publisher: ACM, pp. 185-194.
  • Hayes, Conor, et al. “Context Boosting Collaborative Recommendation”, Knowledge-Based Systems, vol. 17, issues 2-4, May 2004, pp. 131-138.
  • Cano, Pedro, et al. “MTG-DB: A Repository for Music Audio Processing”, WEDELMUSIC '04, Sep. 13-14, 2004, pp. 2-9.
  • Vinet, Hughes, et al. “The CUIDADO Project”, IRCAM, 2002, pp. 1-7.
  • Microsoft Computer Dictionary, 5th Edition, Microsoft Press, Redmond, WA, 2002, pp. 19, 410, 539 and 542.
  • Stauffer, “How to do everything with iTunes for Macintosh and Windows.” published Feb. 27, 2004, 11 pages.
  • Mac Observer. “iTunes 4 Tip-Sharing iTunes libraries over IP; It's not just for Rendezvous”. published Apr. 29, 2003 to MacsOberver.com; 2 pages.
  • Lee, Kyung Hee, et al., “Requirements and Referential Software Architecture for home Server based Inter-Home Multimedia Collaboration Services”, IEEE transactions on Consumer Electronics, Vlume 50, Issue 1, Feb. 2004, pp. 145-150.
  • Haneef, Anwar M., et al., “ANMoLe-An Adaptive Multimedia Content Delivery Middleware Architecture for Heterogenous Mobile Multi-Device Neighborhoods”, Multimedia Tools and Applications, vol. 22, No. 2, Feb. 2004, pp. 171-186.
  • Brown, Janelle; “MP3 free-for-all”; [Online] XP002219000; Retrieved from the Internet http://groups.google.com/groups?selm=Pine.GSU.4.10.10002050020300.16171-100000%40adore.lightlink.com&output=gplain; retrieved on Oct. 30, 2002; 6 pages.
  • Epema D. H. J. ,et al.“Music2Share—Copyright—Compliant Music Sharing in P2P Systems” Proceedings of the IEEE, col. 92, No. 6; Jun. 1, 2004; pp. 961-970.
  • Supplementary Search Report EP 06 73 6092.5 dated Aug. 20, 2009; 3 pages.
  • Guterman, Jimmy: “Will AOL Tame Aimster?—file sharing system piggyback's on AOL instant messaging—Company Business and Marketing”; [Online] XP002532806; Dec. 18, 2000; Retrieved from the Internet http://findarticles.com/p/articles/mi—mOHWW/is—51—3/ai—68156286/ retrieved on Jun. 18, 2009; 3 pages.
  • Yang B. et al; “Comparing Hybrid peer-to-peer systems” Proceedings of the 27th VLDB Conference, Roma, Italy; Sep. 11, 2001; pp. 561-570.
  • Supplementary Search Report EP 06 73 6090.9 dated Jun. 18, 2009; 3 pages.
Patent History
Patent number: 8346798
Type: Grant
Filed: Dec 21, 2005
Date of Patent: Jan 1, 2013
Patent Publication Number: 20060195479
Assignee: Yahoo! Inc. (Sunnyvale, CA)
Inventors: Michael Spiegelman (Los Angeles, CA), David E. Brown (Boston, MA), Lori Ann Sutton (La Jolla, CA), Pierre Schiro (Culver City, CA), Christa Maria Stelzmuller (Long Beach, CA), Siddhartha S. Sahay (Rolling Hills, CA), Daniel Baird (Carlsbad, CA), Adam Korman (Glendale, CA), Alexander Stephen Toth, III (Venice, CA), Poorna Chandra Gowda Bannikuppe Ramachandra (Bangalore), Bipin Suresh (Bangalore)
Primary Examiner: Anh Ly
Attorney: Berkeley Law & Technology Group, LLP
Application Number: 11/315,419