Generating a Customized Social-Driven Playlist

Generating a customized playlist may include identifying a user account for which a playlist is to be generated, where the user account is associated with a user listening history, a taste profile, and a social profile, identifying one or more friend accounts linked to the user account based on the social profile, obtaining an indication of a plurality of songs associated with one or more of the friend accounts, determining a listening history for the one or more plurality of songs based on the friend accounts, obtaining a subset of the plurality of songs based on the listening history of the plurality of songs, and generating a playlist from the subset of the plurality of songs.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
BACKGROUND

This disclosure relates generally to media item playlists and more specifically to generating personalized playlists from media items from a user's social media connections.

Music is an important part of interpersonal relationships, and one of the best ways to learn music is through one's interpersonal relationships. Because of this fact, some technologies display songs that have recently been played back by members of a user's social network. However, such technologies give too much importance to the influence of the social network and many of the songs that are displayed are irrelevant to the user.

SUMMARY

In one embodiment, a non-transitory computer readable medium comprising computer readable code executable by one or more processors is disclosed. The compute readable code is executable by the one or more processors to identify a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile, identify one or more friend accounts linked to the user account based on the social profile, obtain an indication of a plurality of songs associated with one or more of the friend accounts, determine a listening history for the one or more plurality of songs based on the friend accounts, obtain a subset of the plurality of songs based on the listening history of the plurality of songs, and generate a playlist from the subset of the plurality of songs.

In another embodiment, system for generating a playlist is disclosed. The system may include one or more processors, and one or more computer readable media comprising computer readable code executable by the one or more processors. The computer readable code is executable by the one or more processors to identify a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile stored on a social media server, obtain, from a social media server, an indication of one or more friend accounts linked to the user account based on the social profile, obtain an indication of a plurality of songs associated with one or more of the friend accounts, determine a listening history for the one or more plurality of songs based on the friend accounts, obtain a subset of the plurality of songs based on the listening history of the plurality of songs, and generate a playlist from the subset of the plurality of songs.

In another embodiment, method for generating a playlist is disclosed. The method includes identifying a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile, identifying one or more friend accounts linked to the user account based on the social profile, obtaining an indication of a plurality of songs associated with one or more of the friend accounts, determining a listening history for the one or more plurality of songs based on the friend accounts, obtaining a subset of the plurality of songs based on the listening history of the plurality of songs, and generating a playlist from the subset of the plurality of songs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows, in block diagram form, a simplified network diagram according to one or more embodiments.

FIG. 2 shows, in flow chart form, an example method for generating a playlist based on social data, according to one or more embodiments.

FIG. 3 shows, flow chart form, an example method for building a library from which a playlist may be generated in accordance with one or more embodiments.

FIG. 4 shows, in flow chart form, an example method for selecting a subset of songs based on an assigned relevance score for each song, according to one or more embodiments.

FIG. 5 shows an example flow chart for managing feedback for a particular song in a playlist, according to one or more embodiments.

FIG. 6 shows, in flow chart form, an example method for managing a change in relationship between a user and a friend, according to one or more embodiments.

FIG. 7 shows, in flow chart form, an example method for generating a graphical user interface for the socially-driven playlist, according to one or more embodiments.

FIG. 8A shows an example graphical user interface in accordance with one or more embodiments.

FIG. 8B shows an additional example graphical user interface in accordance with one or more embodiments.

FIG. 9 shows an example system diagram for an electronic device in accordance with one or more embodiments.

DETAILED DESCRIPTION

This disclosure is directed to systems, methods, and computer readable media for providing a socially-driven playlist. In general, techniques are disclosed to provide a playlist generated from songs obtained from friend accounts linked to a user account in a social network.

According to one or more embodiments, the disclosed technology addresses the need in the art to provide a customized playlist for a user that while influenced by a user account's social network, also take into account the user account's taste, by using songs or other media items from friend accounts with similar taste profiles. A user account for which a playlist is to be generated may be identified. The user account may be associated with personal data such as a user listening history, taste profile, and a social profile. One or more friend accounts may be identified as associated with the social profile, for example, in a social network. A plurality of songs are identified as being associated with the friend accounts. The plurality of songs may be refined by considering listening history of the friends. For example, only songs that have been listened to recently may be included. A playlist may then be generated from the refined plurality of songs.

According to one or more embodiments, the playlist may be displayed on a graphical user interface. The graphical user interface may include a graphical depiction for one or more songs or other media items of the playlist, such as album art or a depiction of the artist. In addition, according to one or more embodiments, the graphical depiction for the one or more songs may be modified or enhanced with a graphical indication of the user or users from which the song was obtained.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed concepts. As part of this description, some of this disclosure's drawings represent structures and devices in block diagram form in order to avoid obscuring the novel aspects of the disclosed embodiments. In this context, it should be understood that references to numbered drawing elements without associated identifiers (e.g., 100) refer to all instances of the drawing element with identifiers (e.g., 100a and 100b). Further, as part of this description, some of this disclosure's drawings may be provided in the form of a flow diagram. The boxes in any particular flow chart may be presented in a particular order. However, it should be understood that the particular flow of any flow diagram is used only to exemplify one embodiment. In other embodiments, any of the various components depicted in the flow chart may be deleted, or the components may be performed in a different order, or even concurrently. In addition, other embodiments may include additional steps not depicted as part of the flow chart. The language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the disclosed subject matter. Reference in this disclosure to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment, and multiple references to “one embodiment” or to “an embodiment” should not be understood as necessarily all referring to the same embodiment or to different embodiments.

It should be appreciated that in the development of any actual implementation (as in any development project), numerous decisions must be made to achieve the developers' specific goals (e.g., compliance with system and business-related constraints), and that these goals will vary from one implementation to another. It will also be appreciated that such development efforts might be complex and time consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art of image capture having the benefit of this disclosure.

For purposes of this disclosure, media items are referred to as “songs.” However, in one or more embodiments, the media items referred to as “songs” could be any kind of media item, such as audio media items, video media items, visual media items, textual media items, podcasts, interviews, radio stations, and the like.

Referring to FIG. 1, a simplified block diagram is depicted of a media service 100 connected to a social media service 120 and a client device 140, for example over a network. Client device 140 may be a multifunctional device, such as a mobile phone, tablet computer, personal digital assistant, portable music/video player, wearable device, or any other electronic device that includes a media playback system.

Media service 100 may include one or more servers or other computing or storage devices on which the various modules and storage devices may be contained. Although media service 100 is depicted as comprising various components in an exemplary manner, in one or more embodiments, the various components and functionality may be distributed across multiple network devices, such as servers, network storage, and the like. Further, additional components may be used, some combination of the functionality of any of the components may be combined. Generally, media service 100 may include one or more memory devices 112, one or more storage devices 114, and one or more processors 116, such as a central processing unit (CPU) or a graphical processing unit (GPU). Further processor 116 may include multiple processors of the same or different type. Memory 112 may each include one or more different types of memory, which may be used for performing device functions in conjunction with processor 116. For example, memory 112 may include cache, ROM, and/or RAM. Memory 112 may store various programming modules during execution, including library generator module 102 and playlist generator module 104.

Media service 100 may store various personal data related to listening habits for users of the media service 100 within storage 114. Storage 114 may include one or more physical storage devices. The physical storage devices may be located within a single location, or may be distributed across multiple locations, such as multiple servers. The personal data may include a listening history for users may be stored in a listening history store 106. In one or more embodiments, user listening history may include information regarding songs or other media items that have been listened to or otherwise consumed, as well as timing information indicating a listening history for the songs or media items. The timing information may include, for example, a time stamp for a time at which the media item was last consumed, or may otherwise provide an indication for a specific or relative time at which the media item was last consumed. A taste profile for various users may be stored in taste profile store 108. The taste profile contains data regarding various users' taste in media items, and may be determined based on user input, user consumption habits, user feedback, and the like. Thus, according to one or more embodiments, the taste profile may be related in part to a playback of media items. The taste profile may indicate genres of interest to the user. The taste profile may be automatically determined based on the listening history of the user. The taste profile may also be determined, at least in part, by user input. For example, a user may select particular genres that may be of interest, or may be obtained from user feedback from user listening sessions. An example is a user may up vote or down vote songs that are played in the playlist, which the system may use to ascertain trends or other information for the taste profile. In one or more embodiments, the taste profile may be provided in a full version or a compact version, such as a hash, and may be provided in a manner such that taste profiles of two users may be compared to identify a similarity between the tastes of two users. As an example, if a taste profile is presented as a hash, then in one or more embodiments, a similarity between two taste profiles may be determined by determining how many bits need to be flipped to obtain one taste profile from the other. Thus, a similarity measure between two taste profiles may accordingly be represented by the distance between two taste profiles. Some embodiments for the comparison of taste profiles are described, for example, in U.S. patent application Ser. No. 15/872,929, which is herein incorporated by reference. Additionally, or alternatively, the affinity score may be based on a comparison of the listening history of the user account and the friend account from listening history store 106. For example, the listening history of the accounts may indicate similar genres, songs, music styles, media types, and the like, and the affinity score between the two accounts may indicate how similar the listening history of the two accounts are.

The personal data may also include a social profile for the users of the media service 100, which may be stored in the social profile store 110. In one or more embodiments, the social profile store may include affinity scores between various users of the media service 100. The affinity score may indicate a closeness between two user accounts. In one or more embodiments, the affinity scores may be determined, at least in part, based on a similarity measure between the taste profiles of two users. Said another way, affinity between two users may be based in part on a similarity of the tastes of the two users, which may be calculated as described above. The social profile store 110 may also manage changes or customizations between users of the media service 100. For example, a user may select to upgrade, downgrade, connect with a friend, or disconnect with a friend. In one or more embodiments, the social profile store 110 may manage social relationships specific to use of the media service 100. For example, a user may have very disparate taste in music than a social connection and may prefer to disconnect from that social connection such that the music associated with that social connection is no longer used to generate playlists.

Some of the data utilized for the social profile store may be obtained from a social media service 120. The social profile may include a user account store 122 in which relationship data 124 is manage which indicates a set of user accounts linked to a particular user account, along with graphical identifiers 126 representative of each of the user accounts. For example, the friend accounts may belong to other users that the instant user has selected to be connected to in a social network. Each friend account may include their own user information, such as listening history, taste profile, and social media profile, which may also be stored in media service 100. In one or more embodiments, the relationship data 124 may be used to supplement data in the social profile store 110. In one or more embodiments, predetermined relationships between users indicated within relationship data 124 may supplement relationship data in social profile store 110. As an example, a particular user's connections within social media service 120 may be used to identify and propagate social connections in social profile store 110. Relationship data 124 may also be used to determine the affinity score between users stored in social profile store 110. In one or more embodiments, the affinity score may be determined based on the user account social profile and the friend account social profile, such as how often the two accounts interact, a relationship level indicated by the social profiles, or the like.

Returning to the media service 100, the memory 112 includes modules that include computer readable code executable by processor 116 to cause the media service 100 to perform various tasks. As depicted, the memory 112 may include a library generator module 102 and a playlist generator module 104. According to one or more embodiments, the library generator module 102 generates a library from which playlists may be generated for a particular user. The library may be user-specific, such as specific to a user of client device 140. The library may be comprised of songs or other media items associated with friend accounts socially connected to the particular user account. In one or more embodiments, the songs or other media items in the library may include only a portion of all songs or media items associated with social connections to the particular user. For example, the number of songs may be limited to a particular number, and may be selected for inclusion based on a threshold relevance score. Further, the songs may be included in the library based on listening history such that most recently played songs among the friend accounts are included. According to one or more embodiments the various songs associated with friend accounts may be assigned relevance scores based on any number of factors, such as how frequently the song is played, how recently the song was played, the number of friend accounts associated with the song, an affinity score for a friend account or friend accounts associated with the song, and the like. According to one or more embodiments, selectively choosing which songs should be included in a library may optimize storage and/or processing resources required to generate customized playlists without reducing quality.

Memory 112 also includes a playlist generator module 104. In one or more embodiments, the playlist generator module 104 may prepare customized playlists for a particular user from a library of songs generated by library generator module 102. The playlist generator module 104 may generate a playlist on request from a user, such as a user of media player 142 of client device 140. Additionally, or alternatively, the playlist generator module 104 may periodically prepare new playlists, such as on a daily, weekly, or monthly basis. Further, playlist generator module 104 may generate playlists in response to a trigger. Examples of a trigger include a change in a social profile of a particular user, such as the addition or deletion of a social connection, or a change in the user's taste profile. According to one or more embodiments, playlists may be generated based on a requested or determined genre. For example, the genre may be requested by a user, or may be determined based on common genres that occur within the library, or based on the user taste profile and/or the user listening history. In one or more embodiments, a playlist may be based on other seeds, such as a particular artist, tempo, style of music, decade, and the like.

Upon generation of the playlist, the playlist generator module 104 may generate a graphical user interface within which to present the playlist. According to one or more embodiments, the playlist generator module 104 may generate a graphical display of the playlist such that the graphical display provides an indication of the songs of the playlist along with an indication of the friend accounts from which the songs were obtained. The graphical user interface may include a graphical depiction for one or more songs or other media items of the playlist, such as album art or a depiction of the artist. the graphical depiction for the one or more songs may be modified or enhanced with a graphical indication of the user or users from which the song was obtained. In an alternate embodiment, the graphical indication could be a graphical ribbon of users displayed above, below, or otherwise in the vicinity of the playlist in the graphical user interface. The graphical indication may be, for example, an image of the user or users. In one or more embodiments, if the song was obtained from multiple users, then a single user or multiple users may be represented by the graphical indication. In one or more embodiments, the graphical identifier of the user may be obtained from social media service 120, such as in the graphical identifier 126 of the user account store 122. That is, in one or more embodiments, the graphical identifier may be an image that represents the friend account in a social network.

FIG. 2 shows, in flow chart form, an example method for generating a playlist based on social data, according to one or more embodiments. For purposes of explanation, the following steps will be described in the context of FIG. 1. However, it should be understood that the various actions may be taken by alternate components. In addition, the various actions may be performed in a different order. Further, some actions may be performed simultaneously, and some may not be required, or others may be added.

The flow chart begins at 205 where the library generator module 102 identifies a user account associated with a user listening history, a taste profile, and a social profile. According to one or more embodiments, the user account may be a user of the media service, as shown in FIG. 1. The user account identified is a user account for which a customized playlist is to be generated. The user account may be identified, for example, in response to a request for a customized socially-driven playlist. According to one or more embodiments, the user account may be identified in response to determining that the user account is eligible for creation of a customized playlist. For example, the library generation module 102 may require that a user account have a threshold number of associated friend accounts in order to build a library and thus generate a playlist from the library. As another example, the library generation module 102 may require a threshold level of personal information stored by the music service, such as sufficient data to build a listening history and/or a taste profile for the user account.

The flow chart continues at 210, where the library generator module 102 identifies one or more friend accounts linked to the user account based on the social profile. According to one or more embodiments, the user account may be linked to friend accounts within the music service, such as a music service-specific social media network. In one or more embodiments, the user account may additionally, or alternatively, be connected to friend accounts based on a social media network separate from the media service. In one or more embodiments, the friend accounts may be identified based on social profile store 110 and/or relationship data 124. As will be described in greater detail below with respect to FIG. 3, identifying the friend accounts may include identifying a subset of friend accounts socially connected to the user account, for example, based on affinity scores for the friend accounts.

In one or more embodiments, other factors may be considered when identifying the friend accounts. According to one or more embodiments, contextual information may be considered. For example, the library generator module 102 may obtain geographic location information for a user account and a friend account. If a device associated with a user account and a device associated with a friend account are within a same geographic area, such as at a same social event, those friends may be selected to be used to generate the library. In one or more embodiments, the friend accounts used to generate the library may be selected automatically, or may be requested by a use, such as a user of client device 140.

At 215, the library generator module 102 obtains an indication of a plurality of songs associated with one or more of the friend accounts. Said another way, the library generator module 102 determines a set of songs that friends of a user have been listening to. In one or more embodiments, each friend account may be associated with a plurality of songs in a number of ways. For example, a user associated with a friend account may have music or other media files stored on one or more client devices owned by the user. As another example, a user of a friend account may utilize the media service 100 for streaming songs, and may tag certain songs as being favorites, adding them to a playlist, or otherwise marking songs as being of particular interest to the user. In one example, the library generator module 102 may obtain a list of songs played by a friend account recently, such as within a predetermined time. The flow chart continues at 220, where the library generator module 102 determines a listening history for the one or more plurality of songs based on the friend accounts. The listening history may be obtained from listening history store 106. The listening history store 106 may be used to identify a length of time that has elapsed since the last time a friend account played a particular song, or may classify songs associated with a friend account based on a length of time since the song was last played (e.g., within the last day, within the last week, within the last month, etc.).

At 225, the library generator module 102 obtains a subset of the plurality of songs based on the listening history from friend accounts. Said another way, the library generator module 102 may build a library from the obtained subset of the plurality of songs. In one or more embodiments, the subset is obtained to produce a smaller, customized set of songs than the plurality of songs obtained at 215. As will be described in greater detail below with respect to FIG. 4, the listening history may be used to determine a relevance score for each song. The subset of the plurality of songs may also be obtained based on a weighted strength of the friend account from which the song was obtained.

The flow chart concludes at 230 where the playlist generator module 104 generates a playlist from the subset of the plurality of songs. The playlist may be generated on demand, in response to a request from the user. Alternatively, or additionally, the playlist generator module 104 may periodically generate one or more playlists and offer the playlists to the user, such as through media player 142 of the client device 140. Further, in one or more embodiments, playlists may be generated based on a context of the user. In one or more embodiments, contexts may be determined from sensor data from the client device 140, or from other data associated with the user account, such as calendar entries, websites visited, email, and the like. According to one or more embodiments, context-specific customized playlists may be generated by identifying songs with tags that are associated with a particular context. geotags may be used to determine where a user is located, and songs associated with that geotag may be weighted as more relevant while the user is in the determined location. As another example, other contextual information may be used to differently weight the songs. For example, if a user is in a location such as a gym, songs with an upbeat tempo may be weighted more heavily. By contrast, if a user is determined to be in a library, a slower tempo may be more heavily weighted. In one or more embodiments, the characteristics of the songs may be determined based on tags or other metadata stored with respect to the song. As an example, tags may identify a particular song as acoustic, aggressive, rhythmically complex, danceable, energetic, fast, happy sounding, harmonious, melodic, percussive, relaxing, smooth, and the like. In one or more embodiments, the type of song weighted heavily for a particular context may additionally be based on the user's taste profile, which may indicate a user's taste in a particular context. As an example, one user may prefer acoustic songs while driving, whereas another user may prefer aggressive songs. Some embodiments for determining relevant contexts for media items are described in U.S. patent application Ser. No. 15/720,880, which is herein incorporated by reference.

Customized playlists may be generated in a number of ways. A description of some of the ways a customized playlist may be generated may be found in U.S. patent application Ser. No. 15/273,428, entitled “Personal Music Content,” which is herein incorporated by reference. As will be described in greater detail below with respect to FIG. 7, the playlist generator module 104 may cause transmission of the playlist to the client device 140 along with or as part of a graphical user interface (GUI).

FIG. 3 shows, flow chart form, an example method for building a library from which a playlist may be generated in accordance with one or more embodiments. Specifically, FIG. 3 shows a flow chart that depicts how the plurality of songs are obtained, for example at 215 of FIG. 2.

The flow chart begins at 305 where the library generator module 102 determines a similarity measure between each friend account and the user account. In one or more embodiments, the similarity measure may be based on a comparison of a taste profile for the user account and a taste profile for the friend account. As described above, in one or more embodiments, the taste profile may be expressed in the form of a hash, where a similarity between the user account and the friend account may be determined based on how many bits must be flipped from the taste profile of the user account to achieve the taste profile of the friend account. Additionally, or alternatively, the similarity measure may be based on a comparison of the listening history of the user account and the friend account. For example, if the user account has listened to very similar music within the last week, but the use account and the friend account otherwise have disparate taste profiles, the similarity measure between the user account and the friend account may be stronger than it would be otherwise not taking into consideration the listening history of the two accounts.

The flow chart continues at 310, where the library generator module 102 determines a predetermined social relationship between each friend account and the user account. According to one or more embodiments, the predetermined social relationship may be one selected or identified by the user and/or a user associated with the friend account. For example, the social profile store 110 and/or the relationship store 124. In one or more embodiments, a certain closeness of a relationship may indicate that songs associate with certain friend accounts may be weighted more heavily. For example, two users who interact frequently in a social network application, or two users who have self-identified as being in a relationship, or being related, may be weighted more heavily. At 315, the library generator module 102 determines an affinity score for each friend account based on one or both of the similarity measure and the predetermined social relationship.

The flow chart continues at 320, and the library generator module 102 selects a subset of the friend accounts based on the affinity scores for each friend account. In one or more embodiments, a number of friends included in the subset may be based on a threshold affinity score. For example, a predetermined threshold for the affinity score may be used to select the subset of friends. Alternatively, or additionally, the number of friends included in the subset may be based on a number of songs associated with the plurality of friends. For example, the friend accounts may be ranked based on affinity score, and a number of friend accounts may be selected from the top ranked friend accounts such that the number of songs associated with the selected friend accounts constitute a threshold number of songs. The flow chart concludes at 325 when the library generator module 102 obtains the plurality of songs from the subset of friends.

FIG. 4 shows, in flow chart form, an example method for selecting a subset of songs based on an assigned relevance score for each song, according to one or more embodiments. In one or more embodiments, FIG. 4 describes a more detailed view of selecting a subset of songs as in 225 of FIG. 2 for example.

The flow chart begins at 405, where a library generator module 102 determines how recently each song was played. According to one or more embodiments, songs may be considered more relevant the more recent they were played. How recently each song was played may be determined, for example, from the listening history store 106. In one or more embodiments, the library generator module 102 may obtain an indication of how recently a song was played based on a listening history for the friend account from which the song was obtained. The listening history store may include a time stamp indicating the last time a song was played by the friend account, or may include a categorization of how recently the song was played by the friend account from which the song was obtained. The flow chart continues at 410, and the library generator module 102 determines a number of friend accounts from which each song was obtained. In one or more embodiments, the library generator module 102 may determine the number of friends based on a listening history for each friend account from the listening history store 106. According to one or more embodiments, the number of friend accounts may be determined out of the identified friend accounts from 210 of FIG. 2. At 415, the library generator module 102 determines a frequency each song is played among the friend accounts. The frequency may also be determined from the listening history store 106. According to one or more embodiments, frequency may be determined within a predetermined period of time, such as within the last day, week, or month. Frequency may be determined with respect to all friends (i.e., how frequently the song is played among all selected friend accounts, or among the combined friend accounts from which the song is obtained). Alternatively, frequency may be determined on an individual basis based on the one or more friend accounts from which the song is obtained.

The flowchart continues at 420, when the library generator module 102 assigns a relevance score for each song based on one or more of how recently the song was played, the number of friend accounts from which the song was obtained, and the frequency the song was played. The various metrics may be weighted in different manners, according to one or more embodiments. For example, how recently a song was played may have less importance than how frequently a song is played. In one or more embodiments, assigning the relevance score also includes, at 425, weighting the relevance score based on the affinity score for the friend account(s) from which the song was obtained. For example, the affinity score between accounts of romantic partners or family members may be weighted more heavily based on the predetermined relationship.

The flow chart concludes at 430, when the library generator module 102 selects a subset of the songs based on the relevance score. According to one or more embodiments, the subset of songs may be all the songs or may be a portion of the songs for which a relevance score is determined. Further, in one or more embodiments, the subset may be determined based on a threshold number of songs to be included in the subset as well as the relevance score. That is, the songs for which a relevance score is assigned may be ranked, and a number of songs may be selected based on the threshold. The threshold may also be provided in other ways, such as a threshold data size such that the number of songs satisfies a certain data size.

FIG. 5 shows an example flow chart for managing feedback for a particular song in a playlist, according to one or more embodiments. Specifically, FIG. 5 describes how relevance scores and affinity scores are impacted by feedback for a particular song from a user, once the generated playlist is presented to the user.

The flow chart begins at 505 where the library generator module 102 receives feedback for a particular song of the subset of songs. The feedback may be received through a graphical user interface, for example. According to one or more embodiments, a user may provide feedback for a particular song by providing an indication that the user enjoys the song, or that the user does not enjoy the song. In one or more embodiments, the user feedback may be more passive. For example, a user listening to the entire length of a song may be considered positive feedback, whereas a user skipping a song may be considered negative feedback.

The flow chart continues at 510, and a determination is made regarding whether the feedback is positive or negative. If the feedback is positive, then the flow chart continues at 515 and the library generator module 102 increases the affinity score for the friend account from which the particular song was obtained. The flow chart continues at 520 and the library generator module 102 increases the relevance score for the particular song. According to one or more embodiments, the feedback may indicate a relative level of positive feedback (e.g., like or love a song, rate out of five stars, and the like). In the case where the feedback includes a relative level of positive feedback, the affinity score and/or the relevance score may be increased accordingly.

Returning to 510, if the feedback is negative, then the flow chart continues at 525 and the library generator module 102 decreases the affinity score for the friend account from which the particular song was obtained. The flow chart continues at 530 and the library generator module 102 decreases the relevance score for the particular song. Similar as described above to positive feedback, in the case where the feedback includes a relative level of positive feedback, the affinity score and/or the relevance score may be increased accordingly. The flowchart concludes at 535 when the library generator module 102 augments the taste profile for the user account.

FIG. 6 shows, in flow chart form, an example method for managing a change in relationship between a user and a friend, according to one or more embodiments. As described above, relationships between the user account and friend accounts may be managed by either the media service 100 or the social media service 120, which may be separate from the media service 100 (i.e., a separate social network). According to one or more embodiments, a change in a relationship between two users may trigger a change in how media items from those users are treated for each other. Thus, a change in a relationship between two user accounts may trigger an update to the library and, thus, an update to the playlist.

The flow chart begins at 605, when the library generator module 102 receives an indication of a change in social relationship between the user account and a friend account. As an example, one or both of the user account and the friend account may indicate a change in relationship. For example, the two accounts may be newly linked. As another example, one account may select to disengage with the other or otherwise remove the friend account from a list of friend accounts. As yet another example, a type of relationship may be changed, such as a change in a romantic relationship between users of two accounts.

The flowchart continues at 610 and a determination is made regarding whether the friend account is unlinked from the user account. If at 610 it is determined that the friend account is unlinked from the user account, then the flow chart continues at 615, and the library generator module 102 removes songs obtained from the removed friend account to obtain a new plurality of songs. The flow chart continues at 620 where the library generator module 102 obtains a new subset of the new plurality of songs based on the listening history of the remaining friends.

Returning to 610, if a determination is made that the friend account is not unlinked from the user, the flow chart continues at 625, where the library generator module 102 modifies the affinity score for the friend account from which the particular song was obtained. The flow chart continues at 630 when the library generator module 102 modifies the weight of the relevance score for songs obtained based on the modified affinity score.

The flowchart concludes at 635 when the library generator module 102 generates a new playlist. According to one or more embodiments, a change in relationship may trigger a new playlist to be generated. Further, according to one or more embodiments, the new playlist may be generated the next time a playlist is periodically generated.

FIG. 7 shows, in flow chart form, an example method for generating a graphical user interface (GUI) for the socially-driven playlist, according to one or more embodiments. In one or more embodiments, the GUI may improve the display of data related to a playlist by better identifying why a particular song was added to the playlist. For example, in this disclosure, the GUI may present a song or other media item along with an indication of a friend account from which the song was obtained.

The flow chart begins at 705 when the playlist generator module 104 obtains a graphical representation of one or more songs from the generated playlist. The graphical representation may be obtained for each song of the playlist generated by playlist generator module 104. According to one or more embodiments, the graphical representation of the one or more songs may include album artwork, an image of the artist, or the like. The graphical representation may be obtained from the media service 100, or from a different location across a network. Further, a default graphical image may be utilized in the case where the graphical representation of the one or more songs are unavailable.

The flow chart continues at 710 and the playlist generator module 104 obtains a graphical indication of one or more friend accounts from which the one or more songs are obtained. A graphical representation may be obtained for each friend account from which a song was obtained for the playlist. As described above, the graphical indication of the friend account may be obtained from within the media service 100. For example, a user may select a graphical image that represents their user account. In one or more embodiments, the graphical indication may be obtained from a separate social media service 120, such as from the graphical identifier 126 of the user account store 122. Thus, the graphical representation of the user may be specific to the media service, or may be related to a separate social media service.

Optionally, the flow chart includes, at 715, a determination as to whether multiple friend accounts are associated with the song. If a determination is made at 715 that multiple friend accounts are not associated with the song, then the flow chart continues at 720 and the playlist generator module 104 obtains a graphical indication of the single friend account, for example, from the social media service. Returning to 715, if a determination is made that multiple friend accounts are associated with the song, then the flow chart continues at 725, and the playlist generator module 104 optionally selects a representative friend account. The flow chart then continues at 730 and the playlist generator module 104 generates a multi-friend indication using the representative friend account. Alternatively, if the determination is made that multiple friend accounts are associated with the song, then graphical representations for each of the friend accounts may be obtained and a multi-friend representation may be generated, for example by presenting all the graphical representations for all the friend accounts, or by showing a stacked version of the graphical representation of the friend accounts, where a first graphical representation of a first representative friend account is fully visible, and additional graphical representations of one or more additional friend accounts are partially visible. The representative friend account may be selected in a number of ways. For example, the representative friend may be selected based on a predetermined social relationship between the user account and the friend account. That is, a closeness in a social network. As another example, the representative friend may be selected based on an affinity score between the friend account and the user account (i.e., the friend account with the highest affinity score for the user account is selected). In another embodiment, the representative friend may be selected based on the listening history of the friend accounts. For example, a representative friend may be chosen based on a friend account whose listening history indicates the friend was the last user to listen to the song, the friend account which has listened to the song with the greatest frequency, and the like.

The flow chart continues at 735 where the playlist generator module 104 generates a graphical user interface based on the graphical representation of the one or more songs and the graphical indication of the one or more friend accounts. According to one or more embodiments, the graphical indication of the one or more friend accounts may be presented in association with the graphical representation of the one or more songs associated with the friend account. That is, a graphical representation of a song may be presented as associated with the graphical indication of the friend account from which it was obtained. In one or more embodiments, the graphical indication of the friend account may be presented in a badging manner, such that the graphical indication of the friend account may be overlaid on the graphical representation of the corresponding song. According to one or more embodiments, the graphical user interface may additionally, or alternatively, present the graphical representations of the friend accounts that contributed to the playlist separately from the graphical representations of the one or more songs, for example in a ribbon format. The flow chart concludes at 740 when the playlist generator module 104 causes transmission of the graphical user interface to a client device associated with the user account.

FIG. 8A shows a first example graphical user interfaces in accordance with one or more embodiments. Specifically, FIG. 8A illustrates a multifunctional device 800 having a touch screen that displays media content, such as within media player 142 of FIG. 1. The media player application displays content browsing user interface 802, which may include a representation of the customized playlist generated in any manner as described above. The content browsing user interface may include a title 632 and a Friends Mix artwork 840 corresponding to the socially-driven customized playlist described herein. The content browsing user interface 802 may also include a description 824, which may describe the playlist in more detail. According to one or more embodiments, the description 824 may also include details such as the last time the playlist was generated, a genre or category for the playlist, and the like.

As described above, the content browsing user interface 802 may include the graphical representation of the song, as shown by 824A and 824B. Thus, the graphical representation of Song A may be Album A Art 824A, which may be an album on which the song was released. Similarly, the graphical representation of Song B may be Album B Art 824B, which may be an album on which the song was released. Each graphical representation of the song 824 may be presented with a graphical indication of a friend account from which the song was obtained. For purposes of the example playlist, the graphical representation of Song A 824A may be badged by a picture of Friend A 824A, who is associated with the friend account form which Song A was obtained for the playlist. Additionally, the graphical representation of Song B 826B may show a multi-friend account indication 824B, with a representative friend account indication visible (e.g., a picture of Friend B). The content browsing user interface 802 may include additional features such as a textual description of each song, as with Song A 828A and Song B 828B. According to one or more embodiments, the textual description may additionally include a reason the song is included in the playlist. For example, the textual description 828 may convey which of the user's friends' listening activity has resulted in the inclusion of a particular song in the playlist.

The content browsing user interface 802 may also include selectable icons 830A and 830B which allow the user to add the song to the user's library, such as a personal library separate from the library described above which is comprised of songs obtained from friend accounts associated with the user account. The content browsing interface 802 may also include an indication of the current song playing, along with play controls, such as a pause button and a skip button, as shown by user consumption interface 840. Thus, the user consumption interface 840 may allow a user to play and navigate through the playlist.

FIG. 8B shows a second example graphical user interfaces in accordance with one or more embodiments. Specifically, FIG. 8B illustrates the multifunctional device 800 having a touch screen that displays media content, such as within media player 142 of FIG. 1. The media player application displays content browsing user interface 802, which may include a representation of the customized playlist generated in any manner as described above. In the example of FIG. 8B, the content browsing user interface 802 additionally includes a friends ribbon, which depicts the graphical indication of friend accounts which contributed to the playlist. Further, the content browsing user interface 802 may also include an artist ribbon 810, which includes graphical indications of artists which contributed to the playlists. The artists may be represented, for example, by graphical representations 824, or by different graphical representations specific to the artists rather than representative of the songs of the playlist.

Referring now to FIG. 9, a simplified functional block diagram of illustrative multifunction device 900 is shown according to one embodiment. Multifunctional device 900 may show representative components, for example, for devices of media service 100, social media service 120, and client device 140 of FIG. 1. Multifunction electronic device 900 may include processor 905, display 910, user interface 915, graphics hardware 920, device sensors 925 (e.g., proximity sensor/ambient light sensor, accelerometer and/or gyroscope), microphone 930, audio codec(s) 935, speaker(s) 940, communications circuitry 945, digital image capture circuitry 950 (e.g., including camera system) video codec(s) 955 (e.g., in support of digital image capture unit), memory 960, storage device 965, and communications bus 970. Multifunction electronic device 900 may be, for example, a digital camera or a personal electronic device such as a personal digital assistant (PDA), personal music player, mobile telephone, or a tablet computer.

Processor 905 may execute instructions necessary to carry out or control the operation of many functions performed by device 900 (e.g., such as the generation and/or processing of images as disclosed herein). Processor 905 may, for instance, drive display 910 and receive user input from user interface 915. User interface 915 may allow a user to interact with device 900. For example, user interface 915 can take a variety of forms, such as a button, keypad, dial, a click wheel, keyboard, display screen and/or a touch screen. Processor 905 may also, for example, be a system-on-chip such as those found in mobile devices and include a dedicated graphics processing unit (GPU). Processor 905 may be based on reduced instruction-set computer (RISC) or complex instruction-set computer (CISC) architectures or any other suitable architecture and may include one or more processing cores. Graphics hardware 920 may be special purpose computational hardware for processing graphics and/or assisting processor 905 to process graphics information. In one embodiment, graphics hardware 920 may include a programmable GPU.

Image capture circuitry 950 may include two (or more) lens assemblies 980A and 980B, where each lens assembly may have a separate focal length. For example, lens assembly 980A may have a short focal length relative to the focal length of lens assembly 980B. Each lens assembly may have a separate associated sensor element 990. Alternatively, two or more lens assemblies may share a common sensor element. Image capture circuitry 950 may capture still and/or video images. Output from image capture circuitry 950 may be processed, at least in part, by video codec(s) 955 and/or processor 905 and/or graphics hardware 920, and/or a dedicated image processing unit or pipeline incorporated within circuitry 965. Images so captured may be stored in memory 960 and/or storage 965.

Sensor and camera circuitry 950 may capture still and video images that may be processed in accordance with this disclosure, at least in part, by video codec(s) 955 and/or processor 905 and/or graphics hardware 920, and/or a dedicated image processing unit incorporated within circuitry 950. Images so captured may be stored in memory 960 and/or storage 965. Memory 960 may include one or more different types of media used by processor 905 and graphics hardware 920 to perform device functions. For example, memory 960 may include memory cache, read-only memory (ROM), and/or random access memory (RAM). Storage 965 may store media (e.g., audio, image and video files), computer program instructions or software, preference information, device profile information, and any other suitable data. Storage 965 may include one more non-transitory computer-readable storage mediums including, for example, magnetic disks (fixed, floppy, and removable) and tape, optical media such as CD-ROMs and digital video disks (DVDs), and semiconductor memory devices such as Electrically Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Memory 960 and storage 965 may be used to tangibly retain computer program instructions or code organized into one or more modules and written in any desired computer programming language. When executed by, for example, processor 905 such computer program code may implement one or more of the methods described herein.

The scope of the disclosed subject matter should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”

Claims

1. A non-transitory computer readable medium comprising computer readable code executable by one or more processors to:

identify a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile;
identify one or more friend accounts linked to the user account based on the social profile;
obtain an indication of a plurality of songs associated with one or more of the friend accounts;
determine a listening history for the plurality of songs based on the friend accounts;
obtain a subset of the plurality of songs based on the listening history of the plurality of songs; and
generate a playlist from the subset of the plurality of songs.

2. The non-transitory computer readable medium of claim 1, further comprising computer readable code to:

generate a user interface for the playlist comprising a graphical representation of one or more songs of the playlist with a graphical indication of the one or more friend accounts from which the one or more songs are obtained.

3. The non-transitory computer readable medium of claim 1, further comprising computer readable code to:

determine an affinity score for each friend account of the plurality of friend accounts based on a similarity measure of the listening history for the user account and a listening history for each friend account of the plurality of friend accounts,
wherein the plurality of songs are selected from one or more friend accounts of the friend accounts associated with an affinity score that satisfies a predetermined threshold.

4. The non-transitory computer readable medium of claim 3, wherein the affinity score for each friend account is further determined based on a predetermined social relationship between the user account and the respective friend account.

5. The non-transitory computer readable medium of claim 1, wherein the computer readable code to obtain a subset of the plurality of songs based on the listening history of the plurality of songs further comprises computer readable code to:

assign a relevance score to each of the plurality of songs based on how recently the respective song was played; and
select the subset of the plurality of songs based on the assigned relevance score for each of the plurality of songs.

6. The non-transitory computer readable medium of claim 5, wherein the relevance score is further assigned based on a number of friend accounts from which each of the plurality of songs are associated.

7. The non-transitory computer readable medium of claim 5, wherein the relevance score is further assigned based on a frequency of which each of the plurality of songs is played.

8. The non-transitory computer readable medium of claim 1, further comprising computer readable code to:

receive a feedback indication for a particular song of the subset of the plurality of songs from the user account; and
modify an affinity score for a friend account from which the particular song was obtained based on the feedback indication.

9. A system for generating a playlist, comprising:

one or more processors; and
one or more computer readable media comprising computer readable code executable by the one or more processors to: identify a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile stored on a social media server; obtain, from a social media server, an indication of one or more friend accounts linked to the user account based on the social profile; obtain an indication of a plurality of songs associated with one or more of the friend accounts; determine a listening history for the plurality of songs based on the friend accounts; obtain a subset of the plurality of songs based on the listening history of the plurality of songs; and generate a playlist from the subset of the plurality of songs.

10. The system of claim 9, further comprising computer readable code to:

obtain, from the social media server, a graphical indication of the one or more friend accounts from which one or more songs of the playlist are obtained; and
generate a user interface for the playlist comprising a graphical representation of one or more songs of the playlist with the graphical indication of the one or more friend accounts from which the one or more songs are obtained.

11. The system of claim 9, the one or more computer readable media further comprising computer readable code to:

determine an affinity score for each friend account of the plurality of friend accounts based on a similarity measure of the listening history for the user account and a listening history for each friend account of the plurality of friend accounts,
wherein the plurality of songs are selected from one or more friend accounts of the friend accounts associated with an affinity score that satisfies a predetermined threshold.

12. The system of claim 11, wherein the affinity score for each friend account is further determined based on a predetermined social relationship between the user account and the respective friend account.

13. The system of claim 9, wherein the computer readable code to obtain a subset of the plurality of songs based on the listening history of the plurality of songs further comprises computer readable code to:

assign a relevance score to each of the plurality of songs based on how recently the respective song was played; and
select the subset of the plurality of songs based on the assigned relevance score for each of the plurality of songs.

14. The system of claim 13, wherein the relevance score is further assigned based on a number of friend accounts from which each of the plurality of songs are associated.

15. The system of claim 13, wherein the relevance score is further assigned based on a frequency of which each of the plurality of songs is played.

16. A method for generating a playlist, comprising:

identifying a user account for which a playlist is to be generated, wherein the user account is associated with a user listening history, a taste profile, and a social profile;
identifying one or more friend accounts linked to the user account based on the social profile;
obtaining an indication of a plurality of songs associated with one or more of the friend accounts;
determining a listening history for the plurality of songs based on the friend accounts;
obtaining a subset of the plurality of songs based on the listening history of the plurality of songs; and
generating a playlist from the subset of the plurality of songs.

17. The method of claim 16, further comprising:

determining an affinity score for each friend account of the plurality of friend accounts based on a similarity measure of the listening history for the user account and a listening history for each friend account of the plurality of friend accounts,
wherein the plurality of songs are selected from one or more friend accounts of the friend accounts associated with an affinity score that satisfies a predetermined threshold.

18. The method of claim 17, wherein the affinity score for each friend account is further determined based on a predetermined social relationship between the user account and the respective friend account.

19. The method of claim 16, wherein the computer readable code to obtain a subset of the plurality of songs based on the listening history of the plurality of songs further comprises computer readable code to:

assign a relevance score to each of the plurality of songs based on how recently the respective song was played; and
select the subset of the plurality of songs based on the assigned relevance score for each of the plurality of songs.

20. The non-transitory computer readable medium of claim 5, wherein the relevance score is further assigned based on at least one selected from a group consisting of a number of friend accounts from which each of the plurality of songs are associated, and a frequency of which each of the plurality of songs is played.

Patent History
Publication number: 20200004495
Type: Application
Filed: Jun 27, 2019
Publication Date: Jan 2, 2020
Inventors: Bekir B. Dundar (Moraga, CA), Arvind S. Shenoy (San Jose, CA), Daniel Cartoon (South San Francisco, CA), Denise L. Chen (Menlo Park, CA), Drew R. Domm (Oakland, CA), Fredric R. Vinna (San Francisco, CA), Mark H. Levy (Winchester), Paul C. Irvine (Mill Valley, CA), Priyo Mustafi (Fremont, CA), Thomas Alsina (Saratoga, CA), Erik Lindholm (Cupertino, CA), Uli M. Schoberl (San Francisco, CA)
Application Number: 16/454,668
Classifications
International Classification: G06F 3/16 (20060101); H04L 29/08 (20060101); G06F 3/0482 (20060101); G06F 16/638 (20060101); G06F 16/2457 (20060101);