EP2580736A2

EP2580736A2 - Media server providing unlimited medai access over wireless infrastructure

Info

Publication number: EP2580736A2
Application number: EP11793294.7A
Authority: EP
Inventors: Brendon P. Cassidy
Original assignee: Cricket Communications Inc
Current assignee: Cricket Communications Inc
Priority date: 2010-06-10
Filing date: 2011-06-10
Publication date: 2013-04-17
Also published as: WO2011156785A2; WO2011156785A3; EP2580736A4

Abstract

Methods, systems, and apparatus are presented for providing unlimited access to media content, such as music. A media server environment can be provided, which maintains an instance of each subscriber account and a central archive of media content. The instance of a subscriber account can include a record of each item of media content stored locally at the subscriber's device. Changes to the instance, e.g. through automatic updates and user requests, can be reflected on the subscriber's device through the addition and/or deletion of media content. Accordingly, correspondence between the instance and state of the subscriber device can be maintained. Access to the local and central media archives can be controlled through the media server environment based on the status of the subscriber's account. If the subscriber's account becomes inactive, access to media content can be disabled. Once the subscriber's account is reactivated, access to media content can be restored.

Description

MEDIA SERVER PROVIDING UNLIMITED MEDIA ACCESS

OVER WIRELESS INFRASTRUCTURE

[0001] This application claims priority under 35 U.S.C. § 1 19(e) to Provisional Patent Application No. 61/353,606 entitled "Unlimited Media Access Over Wireless

Infrastructure" filed June 10, 2010, to Provisional Patent Application No. 61/394,222 entitled "Media Server Providing Unlimited Media Access Over Wireless Infrastructure" filed October 18, 2010, to Provisional Patent Application No. 61/425,192 entitled

"Unlimited Media Access Over Wireless Infrastructure" filed December 20, 2010, and to Provisional Patent Application No. 61/430,086 entitled " Unlimited Access to Media and Applications Over Wireless Infrastructure" filed January 5, 201 1 , the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The present disclosure relates to providing unlimited access to media, such as music and ring tones, to wireless devices over wireless infrastructure, and to managing the distribution of media to wireless devices from a centralized content library.

BACKGROUND

[0003] Mobile communications devices have been adapted to a wide variety of applications, including computing, communication, and entertainment. For example, mobile communications devices permit users to freely initiate and receive voice communications, e.g. through dial-up connections or push-to-talk. Further, mobile communications devices have been developed to provide users with access to data communications through wireless connectivity, such as over IEEE 802.11 or 3G/4G networks. Data communications can provide a user with access to a wide variety of entertainment options, including audio, video, and gaming content.

[0004] Services have been developed which permit a user to load media content, e.g. music and videos, onto a mobile communications device for subsequent playback. For instance, media content can be purchased from an on-line source, such as in accordance with a pay-per-song model. Purchased media content can be downloaded to a computing device, e.g. a desktop or a laptop. Further, the content can be transferred off-line to a mobile communications device from the computing device, e.g. through a sync (or synchronization) procedure. The media content can then be played back on the mobile communications device using a playback application. Once the media content is no longer desired on the mobile communications device, it can be deleted. Accordingly, media device functionality, e.g. an MP3 player, can be

incorporated into a mobile communications device.

[0005] Internet radio (or web radio or streaming radio) also has been developed to stream music over a network, such as the internet, to receivers that can play the streamed content. Internet radio typically is implemented similar to traditional broadcast radio in that the streamed content cannot be paused or replayed. Further, channels can be programmed to feature a particular style, type, or genre of content, but cannot be programmed by the listener. Additionally, the streamed content is not persistently stored on the receiver, so play back is possible only when a connection to the streaming source is available.

SUMMARY

[0006] A service can be structured to provide a subscriber with unlimited access to and/or unlimited use of media content. Unlimited access and/or unlimited use can be truly unlimited, such that no restrictions are placed on the amount of media that can be downloaded in a given period, e.g. a month, or on the amount the media is used.

Alternatively, unlimited access and/or unlimited use can be structured to impose one or more restrictions on access and/or use, such as a limitation on network traffic over a given period, e.g., measured in megabytes or gigabytes.

[0007] Media content can include either or both of audio content, e.g. music, ring tones, and ringback tones, and video content, e.g. movies, television programs, shorts, and music videos. Further, the unlimited access to media content can be provided in conjunction with one or more communications services, including one or more of voice communications and data communications. For instance, a single, unlimited-use offering that includes access to media content and one or more communications services can be provided. The offering can be available as part of a long-term subscription, e.g. a one-year service plan, or can be available as a short-term offering, e.g. on a per-month basis without a long-term contract. In some implementations, the offering can be prepaid, such that the subscription is automatically renewed unless canceled.

[0008] The present inventors recognized a need to provide centralized management of media content. A collection of servers (referred to as "the cloud") can be configured to maintain an instance of each subscriber account, e.g., an account associated with the subscriber that enables access to the unlimited music service. The instance of a subscriber account can maintain a record of each song that has been downloaded to the corresponding subscriber's mobile communications device. The cloud also can be configured to maintain data corresponding to a subscriber account, such as data indicating the frequency with which songs are played, the most recently played song, downloaded songs that have not been played, subscribed play lists, and the frequency with which play lists are accessed. Further, the cloud can be configured to manage social interactions between users, including messaging, introductions, and comparisons of musical interests between users. The need to provide a central media catalog at the cloud also was recognized. A subscriber can access the central media catalog to select items of media that are to be downloaded.

[0009] The present inventors also recognized a need, in an unlimited use model, to allow media content to be stored locally on a mobile communications device. Further, the present inventors recognized the need to store the media content securely, such that digital rights management protections could be enforced. The need to permit removal of the media content storage from the mobile communications device, such as to provide for expansion and transfer, also was recognized. Additionally, the need for the cloud to recognize which media content storage module was accessible to the mobile communications device also was recognized. The present inventors also recognized the need to perform digital rights management, e.g. validation and

verification, at the subscriber account level. [00010] The present inventors also recognized the need to configure the system such that all communications, e.g. the requesting and downloading of media, are to be conducted between the mobile communications device and the cloud. However, the need to permit a subscriber account to be managed through an alternative device also was recognized. For instance, one or more account details, including the media to be stored locally at the mobile communications device, also can be specified through a browser interface from a separate computing device.

[00011] Additionally, the present inventors recognized the need to gather information regarding downloading and playback of media by all or a portion of the media system subscribers. The present inventors also recognized the need to use download and playback information in formulating recommendations and playlists. Further, the need to use download and playback information to schedule updates to a local media archive also was recognized.

[00012] The techniques described in this specification can be implemented to realize one or more of the following advantages. The techniques can be implemented such that a mobile communications device can store locally an archive of media content based on a subscription plan instead of a pay-per-download model. The techniques also can be implemented to permit authorizing a user to access media on the mobile communications device based on having an active subscription to an unlimited use music service, e.g. bundled with an unlimited use communications service plan.

Further, the media archive can be modified as desired without paying additional fees. The techniques also can be implemented to permit automatically altering at least a portion of the media stored on the mobile communications device based on one or more subscribed play lists. For instance, a play list can be altered periodically, e.g. weekly, and music included in the play list that is not presently stored on the mobile

communications device can be automatically downloaded.

[00013] Techniques also can be implemented to permit displaying a portion of the central media archive such that all items included in a particular collection, e.g. an album, are identified and any media items already locally available are visibly

distinguished from the remaining media items. Also, the techniques can be implemented to receive a request to download one or more of the remotely stored media items. Further, the techniques can be implemented such that media items to be downloaded can be prioritized, e.g. based on an indicated preference for immediate access.

[00014] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[00015] FIG. 1 shows an exemplary computing environment in which unlimited access to media can be provided to a subscribing user.

[00016] FIG. 2 shows an exemplary data flow between a mobile communications device, a computing device, and a server.

[00017] FIG. 3 shows an exemplary server configuration for providing unlimited access to media content.

[00018] FIG. 4 shows an exemplary configuration of modules included in the media server environment.

[00019] FIG. 5 shows an exemplary process flow for accessing media content.

[00020] FIG. 6 shows an exemplary process flow for web-based access to a media server environment.

[00021] FIG. 7 shows an exemplary process flow for transferring media content to mobile communications device.

[00022] FIG. 8 shows an exemplary process flow for providing content corresponding to a subscribed play list.

[00023] FIG. 9 shows an exemplary process flow for populating a local media archive.

[00024] FIG. 10 shows an exemplary process flow for managing advertising served to subscribers.

[00025] FIG. 1 1 shows an exemplary process flow for managing a smart shuffle list for use by a subscriber. [00026] FIG. 12 shows an exemplary process flow for recommending neighbors to a subscriber.

[00027] FIG. 13 shows an exemplary process flow for recording information on a mobile communications device and reporting the information to the cloud.

[00028] FIG. 14 shows an exemplary process flow for generating and providing recommendations.

[00029] FIG. 15 shows an exemplary process flow for configuring a subscriber's community.

[00030] FIG. 16 shows an exemplary mobile communications device for use with the media server environment.

[00031] FIG. 17 shows an exemplary process flow for managing bulk downloads to a subscriber's local media archive.

[00032] FIG. 18 shows an exemplary process flow for managing a take-down request.

[00033] Like reference symbols indicate like elements throughout the specification and drawings. Additional figures also are shown in the attached appendix.

DETAILED DESCRIPTION

[00034] FIG. 1 shows an exemplary computing environment in which unlimited access to media can be provided to a subscribing user. Computing environment 100 can include a server 105 (the cloud) configured to provide access to and management of media content. Server 105 can be implemented using a single computing device or multiple computing devices. If implemented using multiple computing devices, the computing devices can be co-located or distributed, in any arrangement, across two or more physical locations. For instance, in some implementations, server 105 can be implemented using one or more application servers, web servers, and data servers, which can be situated in one or more locations.

[00035] Server 105 can host one or more applications configured to manage subscribing users. For instance, server 105 can be configured to validate a user before the user is authorized to perform media related functions, including accessing locally stored media (on the subscriber device) and downloading media from server 105.

Further, server 105 can maintain an instance of one or more user accounts, including user account details, e.g. mobile identification number and subscriber name, an identification of locally stored media, subscribed play lists, managed play lists, play back history, and contacts information. Server 105 also can host a media catalog (or media archive), which can be accessed by subscribing users to select items of media content for download. Additionally, server 105 can be configured to manage the transfer of media to one or more subscribing users, including the transfer of media requested by a particular user and the automated transfer of media associated with subscribed collection, such as a play list.

[00036] Server 105 can be adapted to communicate with subscribing users over a network 1 10, which can be implemented using one or more data networks. For instance, network 1 10 can include either of both of wired and wireless communication links. Further, network 1 10 can be a public network, e.g. the internet, a private network, e.g. a cellular data network, or a combination thereof. Network 1 10 also can include one or more gateways, which facilitate the transfer of data between devices using different protocols. Further, network 1 10 can include either or both of secure links and unsecure links. Additionally, network 1 10 can include network infrastructure provided by multiple parties, such as a host network and one or more partner networks, e.g. roaming partners.

[00037] One or more mobile communications devices 1 15 associated with subscribing users also can be configured to communicate over network 1 10, e.g. with server 105 and other mobile communications devices 1 15. Any number of mobile communications devices 1 15 can be included in computing environment 100. As the number of mobile communications devices 1 15 increases, server 105 and network 1 10 can be scaled, e.g. by adding additional resources, to provide an acceptable level of service. A mobile communications device 1 15 can be any mobile device configured to communicate over the network 1 10 with a host service provider, e.g. server 105. For instance, a mobile communications device 1 15 can be a mobile telephone that is adapted to transmit and receive data communications, e.g., a smart phone. [00038] In addition to communicating with the server 105, a mobile communications device 1 15 can be configured to communicate wirelessly over a cellular network. For instance, the mobile communications device 1 15 can be associated with a subscription to an unlimited use communications plan that provides access to any or all of voice communications, text, and data communications. In some implementations, a subscription permitting unlimited access to media can be bundled with a

communications plan for a single price, such as a communications plan that offers one or more unlimited communications services or a communications plan that provides a fixed amount of service, e.g. minutes or units of data, for a set fee. Moreover, any of the subscription plans can be implemented as a prepaid, partially prepaid, or post-paid plan.

[00039] A mobile communications device 1 15 further can include a data storage device configured to receive and store media content. The data storage device can be adapted to provide secure storage for the media content, as well as to perform digital rights management functions, e.g. decrypting media content for playback on the mobile communications device 1 15. In some implementations, the data storage device can be a removable device, e.g. a flash memory module. Thus, a local media library can be stored across multiple data storage devices, which can be swapped to provide access to different portions of the library.

[00040] A mobile communications device 1 15 also can include a display, e.g. a liquid crystal display (LCD) or a light emitting diode (LED) display, and one or more user input devices, such as a touch screen, a touch pad, one or more buttons, one or more keys, a scroll wheel, a dial, a switch, a microphone, or any other such input device. Further, a mobile communications device 1 15 can be adapted to communicate using one or more protocols, such as 3G, Wi-Fi, or other such protocols. For instance, a mobile

communications device 1 15 can be configured to communicate over Wi-Fi when possible and otherwise to use a 3G connection.

[00041] Additionally, computing environment 100 can include one or more computing systems 120. A computing system 120 can be implemented using an computing device, such as a desktop computer, a laptop computer, a net book, a tablet computing device, a workstation, and a server. Computing system 120 also can be configured to transmit and receive data over network 1 10, e.g. over a TCP/IP connection. Thus, computing system 120 can be adapted to provide data communications with server 105. For instance, computing system 120 can be used to perform functions relating to a subscribing user's account, such as account management and the selection of media.

[00042] FIG. 2 shows an exemplary data flow between a mobile communications device, a computing device, and a server. Computing environment 200 can include a computing device 205, a server 210, and a mobile communications device 215.

Computing device 205 can be implemented using any computer, including a desktop computer, a laptop computer, a net book, a tablet computer, a workstation, and a server. Further, server 210 can be implemented using one or more servers, e.g. as a combination of servers forming a virtual server, including one or more application servers, data servers, and web servers. Additionally, mobile communications device 215 can be any communication device configured to provide data communications, e.g. a smart phone or web-enabled phone.

[00043] Server 210 can communicate separately with both computing device 205 and mobile communications device 215. For instance, server 210 can communicate with computing device 205 over a public network, e.g. the internet, a private network, e.g. a local area network (LAN), or a combination thereof. Further, server 210 can

communicate can communicate with mobile communications device 215 over a network that includes a wireless data network link, e.g. to a 3G or 4G network. Further, computing device 205 can communicate with mobile communications device 215 via a communications network, e.g., via a Wi-Fi or a 3G or 4G network. In some

implementations, computing device 205 and mobile communications device 215 can be configured such that they do not communicate directly with each other.

[00044] Computing device 205 can communicate with server 210 to perform

operations relating to one or more hosted media applications. For instance, computing device 205 can perform account management functions, messaging, and play list management. Server 210 can provide one or more interfaces to computing device 205. In some implementations, the one or more interfaces can be formatted for a larger display and thus can include additional information than corresponding interfaces provided to mobile communications device 215. Further, one or more of the interfaces provided to computing device 205 can be unique, such that they are not available for presentation to mobile communications device 215. Additionally, the one or more interfaces can be presented without installing an application or plug-in, e.g. as web pages presented in a browser. The interfaces can be compatible with multiple browsers, such that subscriber management from the computing device 205 can be platform independent.

[00045] The interfaces provided by server 210 can enable access to account details relating to a subscribing user, e.g. address and subscription information. Further, server 210 can provide access to at least a portion of a central media archive as well as remote play lists (i.e., play lists that are not created and managed on a subscriber's mobile communications device). Items of media content can be selected from the central media archive for download to a mobile communications device 215. Also, play lists can be managed from the computing device 205, including generating play lists, modifying play lists, deleting play lists, subscribing to play lists and unsubscribing from play lists. Additionally, server 210 can provide access to one or more social services, including messaging, associated with a media application. The social services can include the ability to read messages that have been received, the ability to generate new messages, and the ability to view and interact with one or more friends and neighbors.

[00046] Server 210 further can be configured to transfer media content selected through computing device 205 directly to mobile communications device 215. For instance, a user can browse the central media archive provided by server 210 through an interface presented on computing device 205, and can select one or more items of media content, e.g. songs (full-track audio files), for download. The items of media content selected for download can be transferred, e.g. through an over-the-air download, directly to mobile communications device 215. Further, one or more media items associated with a play list that was subscribed to through computing device 205 can be transferred directly to mobile communications device 215. As a result, mobile communications device 215 need not be synchronized with, or otherwise communicate with, computing device 205. Also, media content need not be downloaded to or stored on computing device 205. Thus, shared computing devices, e.g. library or school computers, can be used to perform account management and media management functions.

[00047] Additionally, an application can be downloaded to computing device 205 from server 210, which can be executed to identify media items stored on the computing device 205 that correspond to one or more identified media types. For instance, the application can be executed to scan one or more storage locations associated with computing device 205 and to identify files corresponding to one or more predetermined formats, such as MP3 or WAV. Further, metadata associated with media items identified at computing device 205 can be transferred back to the server 210. The transferred metadata can be analyzed by server 210 to determine whether it

corresponds to one or more media items stored in the central media archive. In some implementations, any media items so identified from the central media archive can be automatically downloaded to the mobile communications device 215. In some other implementations, a list of media items included in the central media archive that match metadata transferred from the computing device 205 can be presented to a user, who can select any or all of the listed media items for transfer to the mobile communications device 215.

[00048] FIG. 3 shows an exemplary server configuration for providing unlimited access to media content. A media server environment 300 can be implemented using a collection of servers, e.g. configured to provide the appearance of a single device. The collection of servers can be scaled to correspond to demand. The collection of servers can include one or more core servers 320 (or "the cloud") configured to provide services relating to the provision of media content. Additionally, the collection of servers can include one or more secondary servers, e.g. web management server 325, configured to provide additional functionality. In some other implementations, all of the functionality of media server environment 300 can be resident in the core servers 320. The servers included in media server environment 300 can be co-located or distributed, and can communicate over dedicated connections and/or networked connections, including public and private networks.

[00049] Media server environment 300 can be accessible to subscribers 310 through a subscriber interface 305, which can enable communication between one or more subscriber devices, e.g. mobile communications devices, and the collection of servers. For instance, subscriber interface 305 can include a gateway adapted to format communications transmitted and received by the media server environment 300. Media server environment 300 also can include a content provider interface 315 configured to provide access to one or more content providers. For instance, content provider interface 315 can permit media content providers, e.g. record label companies, to transfer media content into media server environment 300, such as through content intake server 345. Further, content provider interface 315 can permit content providers to receive reports, e.g. relating to media download activity, from media server environment 300. The subscriber interface 305 and content provider interface 315 also can be configured to provide security to control access to media server environment 300 and encryption/decryption of messages transmitted and received by the collection of servers. Additionally, a web management server 325 can be configured to provide user interfaces through which the functions provided by the media server environment 300 can be accessed.

[00050] Core servers 320 (or "Cloud" or "the Cloud") can provide access to media content for subscribers 310. For instance, core servers 320 can include a content database (or central media archive) that includes the media content available for download by subscribers. The media content can include audio, such as music, ring tones, and ringback tones, and video, such as music videos, television programs, movies, and video shorts. Further, the media content can be encoded in one or more supported formats, such as when the media content is transferred into the media server environment 300. For instance, music can be encoded in a format that can support progressive playback, high-quality encoding, metadata support, robust error

management, and compression, e.g. the Dolby (R) Pulse format. In some

implementations, the media content can be received from a content provider in any format and converted to an internal format, e.g. Dolby (R) Pulse, by the content intake server 345.

[00051] The core servers 320 also can provide content related services. Browsing and searching functionality can be provided to permit subscribers to explore one or more portions of the media collection. For instance, a subscriber can search a music catalog based on one or more criteria, e.g. artist, album, song, or genre, or can browse a music catalog to select content. A media guide 335 can be configured to assist with browsing and searching functions, such as by identifying and classifying media included in the media catalog. Play list services also can be provided by the core servers 320. For instance, one or more preconfigured play lists, e.g. top 20 downloads, can be provided and maintained by the system. The play lists also can be automatically updated by the system, e.g. through the media guide 335. Subscribers to a play list can automatically receive as downloads all of the media, e.g. songs, included in the play list. In some implementations, only media from the playlist that is not already stored locally on the subscriber's device is downloaded. Further, as the play list is updated, e.g. by the playlist provider, the media downloaded to the playlist subscribers can be updated as well, such as by downloading to the subscriber devices media that is newly added to the play list. Also, media removed from the play list can be automatically deleted from the subscriber devices, e.g. if the media was not downloaded independently of the playlist or otherwise flagged for retention. Additionally, play list services also can be used to facilitate the creation of custom play lists by subscribers and to permit other subscribers to access the subscribers' custom play lists.

[00052] Downloading media to a subscriber device can be managed through synchronization services provided by the core servers 320. The synchronization is performed over-the-air between the core servers 320 and the subscriber's device, without connecting the subscriber's device to an additional computing device, e.g. a personal computer. An instance of each subscriber's account, which is intended to reflect the state at the corresponding subscriber's device, can be maintained by the core servers 320. The instance can include any and all information necessary to mirror the subscriber's mobile communications device configuration, including one or more of a unique track identification for each track stored in the local media archive, a unique playlist definition that describes the contents of each subscriber created playlist, a unique playlist identifier for each subscribed playlist, contact information, information describing account settings, information describing personalization settings, and configuration information. When the instance of a subscriber's account changes, e.g. when content is request for download or the content associated with a subscribed play list changes, the instance no longer reflects the state at the corresponding subscriber's device. This also is true in instances where the subscriber deletes or otherwise removes an item of media content from the local media archive stored on the subscriber device, or modifies account or personalization settings. When a difference exists between the state of the subscriber's instance at the cloud and the state of the subscriber's device, the synchronization services can be used to update the

subscriber's device, e.g. with respect to downloaded media content. Through

synchronization, the account instance maintained by the core servers 320 and the subscriber's device state can be returned to a matching state. For instance, media that has been added to a subscribed play list can be identified and delivered, e.g. through downloading, to one or more subscriber devices. Synchronization services also can be used to manage the download of media requested through the mobile communications device or the web interface. Further, synchronization can ensure that changes made to information such as account settings, configuration information, and personalization information is updated between the cloud and the local device. For instance, in response to a change in the personalization settings at the local device level indicating that content including explicit material should be hidden, a corresponding change can be implemented at the cloud level during synchronization.

[00053] Further, authorization services can be provided by the core servers 320, separately or in conjunction with a subscriber authentication server 330. For instance, a subscriber can be blocked from accessing media services, including downloading and playback, until the authorization services confirm that the subscriber's account is active. The subscriber authentication server 330 can be configured to maintain authentication information, such as account status, or to retrieve the authentication information from one or more other sources, e.g. billing systems or subscriber account databases. The subscriber also can be required to perform one or more verification and validation functions to confirm the subscriber's identity.

[00054] One or more statistics also can be generated by the core servers 320. The statistics can be associated with an individual subscriber, such as how frequently the subscriber plays a particular song or accesses a particular play list. The statistics also can be associated with multiple subscribers, such as how many times a song is downloaded. Further, the core servers 320 can communicate with a report agent 340 to generate statistics for one or more content providers.

[00055] Social services also can be provided by the core servers 320. The social services can be internal and/or external to the media system. For instance, internal social services can include introductions to other subscribers with similar tastes in media, the ability to review account information corresponding to other subscribers, e.g. friends and neighbors, and messaging with other subscribers, e.g. regarding media content. Further, links can be provided to one or more external social services through social gateway 350. For instance, a subscriber can interface with a social networking service, such as Facebook, MySpace, or Twitter, to provide information describing the subscriber's activities, such as identifying music to which the subscriber is currently listening. Additionally, a messaging gateway 355 also can be provided to facilitate messaging, e.g. through short message service (SMS) messages, between subscribers. In some implementations, messages also can be transmitted to one or more devices associated with users who are not subscribers.

[00056] Additionally, a ringback server 360 can be included in the media server environment 300. Ringback server 360 can store preconfigured ringback tones and ring tones that are accessible to subscribers. Further, ringback server 360 can be

configured to permit users to generate custom ringback tones and ring tones based on media accessible through the core servers 320. For instance, a subscriber can select an item of music from the core servers 320 for download. The subscriber can then identify a portion of the selected item of music for use as a ringback tone or a ring tone, e.g. through specifying a beginning and end defining the portion to be used. Once generated, the ringback tone or ring tone can be stored locally at the subscriber's device. In some implementations, a separate ring tone server (not shown) can be included in the media server environment 300 instead of or in addition to the ringback server 360. The ring tone server can be configured to permit users to generate custom ring tones and/or to select preconfigured ring tones.

[00057] Collaborative filtering also can be provided by the core servers 320. The collaborative filtering can be used to automatically provide media recommendations to subscribers based on their previous interactions with the system, e.g. downloads, and/or the previous interactions with the system of one or more other users. Also, collaborative filtering can be used in conjunction with a recommendation service to facilitate music discovery. For instance, in response to a subscriber request, e.g. a one- click selection, the system can automatically provide (or push) one or more continually updating play lists to the subscriber's device. The content included in the one or more pushed play lists can be determined based at least in part on collaborative filtering. Further, the collaborative filtering can be used in conjunction with social services, e.g. introductions, such as to identify similarities between the media archive of a subscriber and those of one or more neighboring subscribers.

[00058] FIG. 4 shows an exemplary configuration of modules included in the media server environment. The media server environment 300 can incorporate multiple modules, which can be implemented in the various included servers. The modules can be client facing resources, which provide services that are accessible to subscribers, or back office facing resources, which provide support and management functionality. In some implementations, additional, fewer, or different modules can be included.

[00059] An archive browse and search module 402 can provide catalog browsing and searching services for one or more media catalogs accessible through the media server environment 300. The archive browse and search module 402 can present items available in one or more media catalogs through direct lookup, e.g. through artist, title, genre, or other classification, and by search, e.g. for media items that include a search term in a title. Further, the archive browse and search module 402 can provide multiple views for presenting requested information, e.g. album view and track view for a particular artist. For instance, a subscriber can request to view all tracks by U2 and can be presented with one or more pages that present the corresponding tracks. Further, the archive browse and search module 402, alone or in combination with one or more other modules, can render results in a predetermined format, e.g. XML, that can be transferred to a corresponding mobile communications device using compression, e.g. HTTP compression (HTTPC). Also, the results can be streamed to the mobile communications device, e.g. using a Simple API for XML (SAX) parser, to permit search results to be rendered progressively.

[00060] A content statistics services module 404 can be configured to expose statistics maintained by the media server environment 300 to subscriber or system requests. In some implementations, the content statistics services module 404 also can make statistics available to content providers. The statistics can be presented in a user requested format, such as one or more charts or rank-ordered listings. For instance, the statistics can be used to generate a chart of the most frequently accessed media over a period of time, such as the top 20 downloaded country songs over the last day. The statistics also can be used to generate subscriber specific charts relating to a particular user or group of users, which can be viewed by subscribers within the same group, e.g. community. Additionally, the content statistics services module 404 can communicate with other modules to retrieve information used to generate and to provide statistics used for other functions, such as report generation or subscriber preference analysis.

[00061] Media storage and delivery module 406 can be configured to provide subscribers with access to media content. Access can be restricted to authenticated users who have either a current or active subscription to service that includes media content. For instance, media storage and delivery module 406 can communicate with authorization and validation module 422 to confirm that a subscriber is permitted to access media content. Further, media storage and delivery module 406 can transfer requested media content to a mobile communications device using a secure

connection, e.g. over-the-air transmission using an HTTPS connection. Additionally, delivery of media content can be performed by progressive download, e.g. using HTTP 1 .1 , such that media can be accessed before downloading has been completed and to permit downloading to be paused and resumed.

[00062] Play count data warehouse and reporting module 408 stores data indicating downloads and plays of media content items by individual subscribers. The data stored by play count data warehouse and reporting module 408 can be provided to one or more other modules, including content statistics services module 404, the reporting portal module 438, the report formatting and delivery module 440, and the

recommendation engine module 444. Further, data relating to the instance of the subscriber's account, e.g. download history, also is maintained. Additionally, data corresponding to play counts and downloads can be recorded in real-time or near realtime, such that an accurate image of the system is persistently available.

[00063] An intelligent content Artificial Intelligence (Al) module 410 is configured to generate play lists. The Al module 410 can access data from other modules, including the content statistics services module 404, the recommendation and correlation rendering module 412, and the media synchronization module 416, to determine realtime or near real-time download and/or play back trends. Further, the Al module 410 can generate content for a play list for one or more categories of media content, e.g. genre or artist, based on the data received from other modules. The Al module 410 also can be configured to sequence the media content associated with a play list based on one or more criteria. For instance, media content can be arranged from highest to lowest relevance with respect to the play list in which it is included. Relevance can be determined based on one or more specified criteria, such as popularity rating and how recently the media content was added to the media collection. The media included in a play list also can be transferred to a requesting mobile communications device in accordance with the determined sequence, such that the most relevant media content is delivered first. Additionally, Al module 410 can be configured to support

recommendation, e.g. "More Like This," functionality. For instance, a subscriber can submit a request for media content similar to a unit of media content, which can range from a single item, e.g. a song, to an entire media collection. In response, the Al module 410 can return one or more personalized and content-specific

recommendations.

[00064] The recommendation and correlation rendering module 412 can receive ratings data from a collaborative filter, which can correlate items of media content. The recommendation and correlation rendering module 412 also can provide

recommendations and correlations to one or more other modules. Correlations can be generated for media content and for subscribers. For instance, the recommendation and correlation rendering module 412, in conjunction with the collaborative filter, can identify statistically related content, based on consumer taste, for an item or a collection of identified media content. Also, in response to receiving the identification of one or more subscribers, the recommendation and correlation rendering module 412 can generate a list of other subscribers who share common musical preferences. In some implementations, the list of other subscribers can be further limited, e.g. based on geographic location, third party ratings, MyCommunity ratings, ratings based on all subscribers, and/or ratings based on a subset of subscribers.

[00065] Ringback tone (RBT) management module 414 provides an interface with a corresponding ringback server on a communications network. A subscriber's ringback tones can be managed, including adding and deleting tones, from either or both of a mobile communications device and a web-based management platform through RBT management module 414. Subscriber ringback tone settings also can be configured through the module. Thus, a ringback tone acquired through the media server environment 300 can be configured for use through RBT management module 414.

[00066] A ring tone management module 415 also can provide an interface with a corresponding ring tone server on a communications network. A subscriber's ring tones can be managed, including adding and deleting ring tones, from either or both of a mobile communications device and a web-based management platform through the ring tone management module 415. Subscriber ring tone settings also can be configured through the module. Thus, a ring tone acquired through the media server environment 300 can be configured for use through the ring tone management module. In some implementations, the ring tone management module 415 and RBT management module 414 can be consolidated, e.g. in a single module.

[00067] Media synchronization module 416 can synchronize the media catalog stored locally on the mobile communications device with the instance of the subscriber's media catalog maintained at the media server environment 300. The media synchronization module 416 communicates with the mobile communications device to identify differences between the corresponding media catalogs and to identify a list of media content that is to be transferred to the mobile communications device. If multiple storage devices, e.g. memory cards, are used by the mobile communications device to store the local media catalog, the media synchronization module 416 can recognize the storage device presently in use. For example, a separate instance can exist at the media server environment 300 for each storage device. Further, the list can be prioritized based on one or more criteria, such as whether the media content was selected by the subscriber or is being provided based on a subscribed play list.

Additionally, media synchronization module 416 can be adapted to maintain the metadata corresponding to a subscriber's account, including an indication of the items of media content, e.g. tracks, stored locally on the mobile communications device and an indication of the subscribed play lists.

[00068] An internal social services module 418 can manage the community interaction (or social interaction) that occurs in media server environment 300. For instance, a community can include one or more friends who the subscriber has expressly identified or who have been identified based on an existing connection with the subscriber, such as being included in the subscriber's contact list. In some implementations, the subscriber's contact list can be analyzed periodically, e.g. once a week, to identify contact's that have been newly added or who have recently subscribed and can now be listed as friends. The community also can include one or more neighbors identified by the media server environment 300. For instance, one or more neighbors can be identified based on proximity to the subscriber, e.g. including geography and correspondence of musical interests. In some implementations, geographical proximity and musical interests can be weighted to determine who should be identified as a neighbor. For example, a user who has almost identical musical interests to the subscriber can be identified as a neighbor even though they are separated by a large distance, as can a user who simply has more than a threshold amount of commonality with respect to music and is located very near the subscriber. The account details of friends and neighbors can be viewed through community interaction, including any or all of the downloaded media catalog, play history, ring tones, ring back tones, and play lists. Community interaction also can include sending and receiving of shouts (or messages) relating to media content.

[00069] Further, internal social services module 418 can perform or support media content related exploration, such as permitting a subscriber to compare their media collection with that of another user. For instance, a subscriber can compare the contents of their media archive with the contents of a friend or neighbor's archive to determine common media items, media items exclusive to the subscriber, and media items exclusive to the friend/neighbor. In some implementations, either or both of the common items and exclusives can be presented as reports, e.g. in response to the selection of a menu item. Further, a subscriber can create a virtual subscribed playlist based on the media items included in another subscriber's local archive. For instance, subscriber A can create a subscription to the local media archive of subscriber B. As a result, all of the media items unique to subscriber B's local media archive can be identified and ultimately downloaded into subscriber A's local media archive. As long as the subscription is maintained, any media item downloaded to subscriber B's archive that is not already stored in subscriber A's local media archive also will be automatically downloaded into subscriber A's local media archive.

[00070] Other exploration, including viewing another user's most frequently accessed media items or playback history also can be permitted. Additionally, internal social services module 418 can maintain a subscriber's social preferences and an indication of the subscriber's current geographical location, e.g. based on mobile communications device usage. This information can be used in the identification of neighbors and delivery of recommendations. [00071] Social interaction provided through internal social services module 418 also can be extended through external social gateway 420. For instance, a subscriber can configure their account to direct shouts (or messages) they have generated to one or more external social services, such as Twitter and Facebook. A shout (or message) can include one or more links to content, such as a song or play list, and/or information. The external social gateway 420 permits communication with third-parties through published application program interfaces (APIs).

[00072] Authorization and validation module 422 provides authorization and validation services for subscribers seeking to access the media server environment 300. The authorization and validation module 422 can have a persistent connection to an account server, such that a subscriber's account status can be validated in real-time. If a subscriber's account is not current, e.g. has been suspended or closed, access to the media server environment 300 can be denied. Further, authorization and validation module 422 can continue to monitor a subscriber's account status while the subscriber is connected. If the subscriber's account lapses while the subscriber is connected, access can be terminated. The authorization and validation module 422 also can be adapted to inform a subscriber as to whether previously downloaded content should be accessible. Additionally, the authorization and validation module 422 can be configured to communicate with RBT management module 414 to enable and disable a

subscriber's ringback tones and/or ring tones based on their account status.

[00073] Web management module 424 can be configured to support web-based management of a subscriber's account from any computer. Web-based browsing of the media catalog and content selection also can be provided, since content is transferred directly from media server environment 300 to the subscriber's mobile communications device. In some implementations, the web management module 424 can provide interfaces and functionality that mirror those provided through the mobile

communications device. In some other implementations, one or more different interfaces can be provided, e.g. to utilize the expanded viewing area of a computer monitor, and one or more functions can be restricted or removed. Additionally, a downloadable widget can be provided in conjunction with web management module 424. The widget can be installed on any computing device, including any mobile computing device, and can be configured to scan one or more storage devices associated with the computing device to identify resident media content. Metadata identifying any discovered media content can then be provided back to web

management module 424, so that the corresponding media content can be added to the subscriber's media catalog.

[00074] The back office resources can include a media catalog import module 426 that imports media and corresponding metadata from third-party partners, e.g. record label companies, into the media server environment 300. A change list can be generated in conjunction with each new file or set of files received from a third-party, e.g. so that the media catalog can be updated. The media catalog import module 426 also can be configured to validate each new file or set of files that have been received, and to flag any file that fails the validation. Additionally, either or both of the media content and corresponding metadata can be converted (normalized) into a format used within the media server environment 300. Media content that is received and validated can be stored in the media database and made available to subscribers.

[00075] A media file encoder module 428 can communicate with the media catalog import module 426, and can be adapted to encode some or all of the received media content, e.g. files that have not been pre-encoded, in a standard format. For instance, received music files that have not been pre-encoded in the standard format can be encoded in the High-Efficiency Advanced Audio Coding version 2 (HE-AACv2) format. The encoded HE-AACv2 files can employ features to improve quality and/or

compression, including spectral band replication and parametric stereo. A media file validator module 430 also can communicate with the media catalog import module 426 to perform file validation. For instance, the media file validator module 430 can check each received file to verify that it is encoded in the proper format (using the proper codec) and at the proper bit rate. Further, the media file validator module 430 can check the number of channels and duration corresponding to the file. A file that is validated can be made available to subscribers as part of the media catalog.

Alternatively, a file that fails validation for any reason can be flagged and kept separate from the media catalog. In some implementations, the media file validator module 430 also can include media recognition technology to validate that the file corresponds to the correct item of media, e.g. the song it is supposed to be.

[00076] Media content and storage module 432 can provide a virtual file system that spans multiple storage devices. The physical delivery of media content to requesting subscribers can be performed through media content and storage module 432. Further, the media content can be replicated at the file level in order to provide redundancy. By using multiple, physically independent storage devices and/or redundant files, requested files can be more quickly served to subscribers.

[00077] The media guide import and match module 434 matches metadata received from one or more media guides, e.g. the All Music Guide, with media content included in the media catalog. The received metadata can be linked with either or both of files and metadata from other sources stored in the media database. As a result, rich metadata associated with the media content can be provided to subscribers. For instance, the metadata included through the media guide import and match module 434 can include data to enrich presentation, such as album art and artist portraits. Additionally, the received metadata can be used to enhance recommendation functionality.

[00078] Metadata management module 436 provides a management interface that allows administrators to modify metadata associated with files, including overriding existing metadata and adding content details. Metadata can be overridden because administrator-supplied content details can be given precedence, upon publishing, over metadata supplied by third-parties. Further, metadata management module 436 provides the ability to manage media content for inclusion in system-generated play lists.

[00079] Reporting portal 438 can receive and/or extract statistics from other modules and system resources, and can provide the statistics for use by administrators and third- parties, e.g. content providers. Through reporting portal 438, reports can be specified, designed, and scheduled for delivery. Further, reports can be generated in real-time to reflect the current state of the system, including reports on subscriber actions, loading, scaling, and module performance. Reports, both scheduled and real-time, can provide granularity down to individual items of media content. Report formatting and delivery module 440 can receive reports generated by the reporting portal 438 and format them in accordance with requirements specified by third-parties. Once formatted, report formatting and delivery module 440 can deliver the reports to the appropriate third- parties. In some implementations, the reports also can be compressed prior to delivery.

[00080] Phonetic search engine 442 can be configured to process queries from subscribers. The queries can be submitted through either or both of a mobile

communications device and a web-based computing device. In some implementations, the phonetic search engine also can provide support for non-subscriber facing functions, such as content matching and content import functions. A relational also- known-as (AKA) database can be included to provide matches for common misspellings and to provide a by-pass for previously matched items. The phonetic search and AKA database improve searching by providing results even when subscribers do not know the exact spelling and by overcoming typing errors, e.g. resulting from space-limited interfaces on mobile communications devices.

[00081] In performing a phonetic search, the received search phrase can be deconstructed and submitted to artificial intelligence reference analysis. The reference analysis can include one or more analysis tools, such as a phonetic index, a dictionary of common typographical errors, and an AKA dictionary. Further, the analysis also can reference either or both of a media content metadata store and an intelligent search cache. After the analysis has been performed, the search phrase can be reconstructed and the search results can be provided.

[00082] Recommendation engine 444 generates the data stored in the

recommendation and correlation rendering module 412, which is periodically refreshed. The recommendation engine can generate data used for recommendations by aggregating and comparing data describing subscribers with data describing available content. In some implementations, the recommendation engine 444 can support the concepts of any or all of trust, Bayesian boosting, and temporal relevance, which can improve the relevance of recommendations for at least some content, e.g. music. [00083] SMS gateway 446 processes all actions and communications that are to be provided to a subscriber in the form of an SMS message. The SMS gateway 446 can interface with a platform associated with the media server environment 300 or an SMS platform provided by a third-party.

[00084] FIG. 5 shows an exemplary process flow for accessing media content. In the unlimited media access system, media content can be stored locally on a mobile communications device, e.g. using one or more secure memory cards. Further, the unlimited media access system can provide truly unlimited access to and unlimited use of available media content. Alternatively, the unlimited media access system can include one or more express and/or inherent restrictions, such as a limit on the amount of media content that can be stored locally on a subscriber device at any given time and/or a limit on the amount of network usage (download traffic) over a given period of time, e.g., measured in megabytes or gigabytes. In order to access local media content, the subscriber's account to which the device corresponds must be active. In some implementations, the subscriber's account for unlimited media access can be part of a plan that also provides unlimited communications services, including one or more of voice communications, data communications, and messaging. In some other

implementations, the subscriber's account for unlimited media access can be charged as an additional service related to an underlying account for communications services, including any or all of voice, data, and text communications. In still other

implementations, the subscriber's account for unlimited media access can be separate from any account for communications services.

[00085] A request for access can be received from the subscriber device when access to either locally stored media content or the media server environment is requested (505). In response to a request, an access authorization and validation operation can be performed (510). For instance, the subscriber's account status can be determined by the authorization and validation module to confirm that it is current. If the access request is received from a mobile communications device, information

identifying the subscriber's account can be received with the request, e.g. a mobile identification number (MIN). Alternatively, if the access request is received from a web- based device or the identifying information is not received, a request for identification can be presented to the subscriber, e.g. as a username / password prompt.

[00086] Based on the access authorization and validation operation, it can be determined whether the subscriber is authorized (515). If the subscriber is not authorized, an access denial message can be presented (520). Further, the message can include one or more reasons for the denial. Otherwise, if the subscriber is authorized, the music service, e.g. the cloud, can generate a token and provide it to the mobile device (525). The token can be valid for a predetermined period of time, e.g. 24- hours or the time remaining on a pre-paid portion of the subscriber's plan, and can be uniquely associated with the mobile communications device. A token also can be invalidated (or recalled) by the cloud at any time, such that any further access to the music service can be prevented. Further, the token can be provided to the cloud whenever access to the music service is requested. The cloud can authenticate the token, such as by confirming that it is associated with the device requesting service and is still valid. If the token is authenticated, access can be granted. If the token is expired, the authorization and validation process can be repeated. Further, in some implementations, a grace period can be defined, during which an expired token will still be accepted. For instance, if tokens are set to expire at a uniform time, such as midnight, a grace period of minutes or hours can be set to permit all of the requesting devices to provide uninterrupted service while new tokens are being provided.

[00087] Further, it can be determined whether the subscriber is requesting access only to local content (530). If access to local content is being requested, the access can be granted and a requested operation, e.g. playback, can be executed (535). In some implementations, a request for local access can be performed transparently, so that the subscriber is not required to perform any operations. For instance, the music

application on the mobile device can confirm that the token has not expired. Thus, access to local content can be pre-authorized for a predetermined period of time, e.g. a day, or for the duration of a pre-paid period, e.g. a month of service.

[00088] If access to the media server environment was requested, an interface corresponding to the media system, e.g. a home screen, can be presented to the subscriber (540). The subscriber can then be permitted to access functionality provided by the media server system, including media searching, media browsing, downloading selected media, and social services. Additionally, any pending updates, e.g. new media and/or application software, can be transferred to the mobile communications device (545). In some implementations, the secure storage on the mobile communications device, e.g. a secure card, also can require a key for access. In such implementations, the mobile device also can be configured to pass a unique identifier associated with the secure storage to the cloud. The cloud can then generate a key corresponding to that unique identifier and pass the key back to the mobile device for use in accessing secured content. The request for a key can be performed in conjunction with or separately from the authorization and validation operation.

[00089] FIG. 6 shows an exemplary process flow for web-based access to a media server environment. A media server environment providing access to media content, e.g. local and/or remote content, for mobile communications devices can be configured to communicate with other computing devices over public and/or private data networks, e.g. the internet. The media server environment can receive a web-based access request from any networked computing device (605). For instance, the media server environment can be accessible through a browser at one or more published Uniform Resource Locators (URLs). Upon receiving the web-based access request, the media server environment can determine whether the request is from an authorized subscriber (610). For instance, the requestor can be prompted to supply a username / password pair, or other such identification information. Alternatively, the subscriber can be authorized based on a web identifier ("ID"), a token or other such identifier. If the requestor is not in possession of valid identification information, or if the requestor's account is not active, an access denial message can be issued (615).

[00090] If the request is from an authorized user, a web-management interface can be presented (620). The web-management interface can include a home menu (or top- level menu) that can provide links to additional interface screens, each of which can provide access to functions supported by the media server environment, including media search and community functions. In some implementations, the web- management interface can replicate the interface available on the mobile

communications device and provide identical functionality. In some other

implementations, the web-management interface can be formatted differently, e.g. to make use of a larger available display area. The web-management interface also can include reduced functionality with respect to the mobile communications device and/or the provided functionality can differ in at least some respects.

[00091] A media content selection can be received through the web-management interface (625). The selection can specify one or more items of media content that are to be downloaded to the mobile communications device. In some implementations, the subscriber's account status can be verified again before the media content selection is processed, e.g. to verify that the subscriber's account remains current. The selected items of media content can be designated for transfer to the mobile communications device, e.g. by adding them to a download list corresponding to the device (630). The selected items of media content can then be transferred directly to the mobile

communications device, e.g. via an over-the-air transfer. If the mobile communications device is off-line or becomes unavailable before the transfer has been completed, the media items that have not been downloaded can be preserved in the download list, e.g. as represented by a disparity between the subscriber's instance maintained by the media server environment and the state of the mobile communications device, until they are successfully transferred. Additionally, the instance of the subscriber's account maintained by the media server environment can be updated as items of media content are transferred to reflect the changed state.

[00092] FIG. 7 shows an exemplary process flow for transferring media content to mobile communications device. The cloud can maintain a persistent instance of the subscriber's local media archive, e.g. that is maintained on secure storage at the subscriber's mobile communications device. In some implementations, a separate instance can be maintained for each secure storage device employed by the subscriber, e.g. such that each secure storage device is treated as a separate logical archive. The synchronization status for a subscriber is valid (or current) when the state of the instance maintained at the cloud matches the state of the subscriber's local media archive. If a change occurs at one of the cloud level and the local device level, the synchronization status is no longer valid. The synchronization state can be maintained in any manner, such as a flag or binary value indicating that the synchronization state is current or that the local device is out of synchronization with the cloud. A message, e.g. an SMS message, can be transmitted to the subscriber's device when the

synchronization state changes to reflect that synchronization is required. No additional messages need be transferred after synchronization has lapsed, since the subscriber's device already has been notified that it needs to synchronize.

[00093] A synchronization operation can be performed periodically, e.g. once a day or when communication is established between a mobile communications device and the cloud, to execute any required updates. The local content listing, e.g. the contents of the local media archive, can be determined for the subscriber's mobile communications device (705). The corresponding content listing for the subscriber's instance maintained at the cloud also can be determined (710). For example, a listing of unique track identifiers can be generated for both the mobile communications device and the cloud instance.

[00094] Once determined, the local content listing can be compared with the corresponding content listing for the subscriber's instance (715). Further, it can be determined whether there are any differences (720). If no differences exist between the local content listing and the corresponding content listing for the subscriber's instance, the synchronization status is confirmed to be valid and no updating is performed (725).

[00095] Otherwise, if at least one difference exists between the local content listing and the corresponding content listing for the subscriber's instance, it can be determined what content requires updating. In some implementations, one or more change lists can be generated to capture content updates that are to be performed, e.g. a change list for the subscriber device and a change list for the instance. In some other implementations, an update can be performed as it is identified.

[00096] Based on the comparison of the local content listing to the corresponding content listing for the subscriber's instance, any tracks that are to be transferred to the local media archive of the subscriber's device can be identified (730). For example, all of the tracks associated with the subscriber's account, as reflected by the instance at the cloud, can be compared to the tracks stored in the local media archive. If a track is included in the instance at the cloud but is not included in the local media archive, the track can be identified for download. This situation can arise where a user has requested a track, e.g. through the web-management interface or from the mobile communications device, but the track has not yet been downloaded.

[00097] Any tracks that are to be deleted from either or both of the instance at the cloud and the local media archive also can be identified (735). For example, a track can be deleted from a subscribed playlist and thus also can be deleted from the instance maintained at the cloud. Based on the comparison, it can be determined that the track also is to be deleted from the local media archive. In some implementations, before a track is deleted from the instance in response to its removal from a subscribed playlist, it can be determined whether the track was downloaded to the local media archive independent of the playlist, e.g. in response to a subscriber's request, or if the track is still included in another subscribed playlist. Independence from the playlist can be determined by an identifier, such as a flag or source value. If the track was

independently added to the local media archive or is still included in another subscribed playlist, deletion from one playlist will not cause the track to be deleted from the instance. Additionally, a track that has been deleted from the local media archive, e.g. by subscriber action, also can be deleted from the instance maintained at the cloud.

[00098] Further, any tracks included in a subscribed playlist that are not included in the local media archive also can be identified for transfer to the local media archive (740). For example, new tracks can be added to a subscribed playlist. If it is

determined during the comparison that one or more of the new tracks is not included in the local media archive, those one or more tracks can be identified for download. The instance maintained at the cloud can be updated to reflect any changes identified as a result of the comparison (745). For example, one or more tracks deleted from the local media archive since the last synchronization can be deleted from the instance. Also, the local media archive can be updated to reflect any identified changes (750). In some implementations, the updating can be performed as each change is identified, e.g. in real time. In some other implementations, one or more change lists can be generated during the comparison process and the updating can be performed by executing one or more of the change lists. After the updating, the synchronization status is once again confirmed to be valid.

[00099] In some implementations, change records can be maintained by both the subscriber device and the cloud. For instance, each change, such as the deletion of one or more tracks or the creation of a new playlist, that is performed at the local media archive level after a synchronization operation has terminated can be recorded until the next synchronization operation occurs. Similarly, each change, such as the addition to or deletion from a subscribed playlist of one or more tracks, can be identified in a change record associated with the subscriber's instance maintained at the cloud.

During the next synchronization operation, the change record associated with the local media archive can be accessed and the local changes can be applied to the

subscriber's instance at the cloud. Further, the change record associated with the subscriber's instance at the cloud can be accessed and the cloud-based changes can be applied to the subscriber's local media archive. Once the changes included in the change records maintained by the subscriber device and the cloud have been implemented, the synchronization status can be reset.

[000100] FIG. 8 shows an exemplary process flow for providing content corresponding to a subscribed play list. Remote play lists (or remote playlists) can be maintained in the media server environment and made available through subscription to one or more music service subscribers. A remote play list can be generated by anyone other than the subscriber. For instance, a system play list can be generated to introduce subscribers to music within a particular genre, such as alternative or jazz. The system playlist can be generated manually or automatically, e.g. based on collected statistics, artificial intelligence, or a combination thereof. A system play list also can be sponsored by a celebrity, such as a popular musician within a genre. Further, a user play list can be generated by another subscriber, such as a friend or neighbor. A music service subscriber can establish a subscription to any of these remote play lists. Once a subscription has been established, the subscriber's local media archive can be updated automatically to include all of the media associated with the playlist. Also, media can be purged from the subscriber's local media archive when it removed from the playlist.

[000101] One or more available remote playlists can be identified to a subscriber (805). For instance, a list of available remote playlists can be presented in response to the subscriber accessing a portion of a media archive, e.g. a music store or playlist repository. The available remote playlists also can be organized, e.g. based on genre, artist, playlist creator, or other such characteristics. Alternatively or additionally, one or more remote playlists can be discovered by exploring a local media archive of another subscriber, such as a friend or neighbor. For instance, the playlists created by that friend or neighbor can be viewed, including the associated media content.

[000102] A subscription request indicating a remote playlist can be received from a subscriber (810). For instance, each playlist in the music service system can be assigned a unique identifier by which it can be accessed and managed. The local media archive of the requesting subscriber can be compared with the content included in the remote playlist corresponding to the request (815). Based on the comparison, it can be determined whether the remote playlist includes any media that is not already stored in the subscriber's local media archive (820). If all of the media included in the remote playlist is stored in the subscriber's local media archive, the subscription can be completed and the subscriber can use the subscribed playlist (825).

[000103] If one or more items of media included in the remote playlist are not included in the subscriber's local media archive, the one or more items of media can be identified for transfer (or downloading) to the subscriber's mobile communications device for storage in the local media archive (830). For instance, the one or more items of media can be added to a download queue. In some implementations, if the download queue includes multiple items, the items in the download queue can be prioritized for transfer. For instance, media that the subscriber has requested for immediate play back can be given the highest priority and transfer can begin as soon as possible. Further, the remaining media content can be prioritized based on one or more criteria, such as popularity, how recently the media content was added to the media catalog, the position of the media content within the subscribed play list, and how long the media content has been awaiting transfer. The media content can be transferred to the device in accordance with the prioritization, such that the highest priority content is transferred first. Alternatively, the one or more items can be transferred in conjunction with the next synchronization operation based on their addition to the subscriber's instance

maintained at the cloud. The subscription to the remote playlist can be completed and the identified media can be transferred (835). For instance, the subscription to the remote playlist can be added to the subscriber's instance maintained at the cloud.

[000104] After the subscription has been completed, the music service can periodically determine whether the remote playlist has been revised (840). In response to a revision, it further can be determined whether a synchronization event has occurred (845). One or more predetermined synchronization events or conditions can be defined, such as entering a local service area during off peak hours or connecting the mobile communications device to a power source. In some implementations, a synchronization event can be a complex event that includes multiple conditions.

Additionally, playlist updating can incorporate a use-based component. For instance, a frequently accessed playlist can be updated whenever the playlist is revised. On the other hand, an infrequently accessed playlist can be updated only after a predetermined period of time, e.g. a week, because the playlist content will still be relatively fresh even without updating. Accordingly, the amount of data transferred to update playlists can be reduced.

[000105] If a synchronization event has occurred, the subscriber's local media archive can be updated based on the remote playlist (850). For instance, media that has been added to the remote playlist and is not already stored in the subscriber's local media archive can be downloaded. Further, an item of media that has been removed from the remote playlist can be deleted from the subscriber's local media archive, e.g. if the item of media was not added to the local media archive independent of the remote playlist subscription or otherwise flagged for retention.

[000106] FIG. 9 shows an exemplary process flow for populating a local media archive. When a new subscription is established, the subscriber can elect to run a setup wizard that can populate the local media archive with content, such as music tracks. Further, the content can be selected based on one or more parameters provided by the subscriber, e.g. such that the local media archive is personalized for the subscriber. Additionally, because the content is not limited to media expressly identified by the subscriber, more diverse content can be intelligently selected to provide the subscriber with an opportunity to discover new media they may enjoy.

[000107] Wizard setup can be initiated automatically, e.g. the first time the media application is executed on the mobile communications device, or in response to input from the subscriber (905). Once initiated, the wizard can collect one or more items of information from the subscriber for use in preloading the local media archive. The subscriber can be prompted to identify an artist (910). For instance, the subscriber can be asked to select an artist from a predetermined list or to enter the name of an artist. Further, it can be determined whether the subscriber would like to identify an additional artist (915). In some implementations, the subscriber can be permitted to enter as many artists as desired. In some other implementations, the subscriber can be limited to a predetermined number of artists, e.g. three. Also, in some implementations, it is possible for the subscriber to skip the identification of any artists.

[000108] The subscriber also can be prompted to identify a genre (920). For instance, as with artists, the subscriber can be asked to select a genre from a predetermined list or to enter the name of a genre. The level of granularity with which genres are defined can be variable, and particular artists and/or tracks can be included in multiple genres, such that there can be some overlap between genres. After a genre has been identified, it can be determined whether the subscriber would like to identify an additional genre (925). In some implementations, the subscriber can be permitted to enter as many genres as desired. In some other implementations, the subscriber can be limited to a predetermined number of genres, e.g. three. Also, in some

implementations, it is possible for the subscriber to skip the identification of any genres.

[000109] Further, the subscriber can be prompted to identify a playlist (930). For instance, the subscriber can be asked to select a playlist from a list of available playlists. The playlists included in the list can be limited to one source, e.g. playlists provided exclusively by the music service, or can come from multiple sources, including other subscribers. In some implementations, the list of playlists presented to the subscriber can be filtered, e.g. in accordance with one or more artist and genre selections. After a playlist has been identified, it can be determined whether the subscriber would like to identify an additional playlist (935). In some implementations, the subscriber can be permitted to enter as many playlists as desired. In some other implementations, the subscriber can be limited to a predetermined number of playlists, e.g. three. Also, in some implementations, it is possible for the subscriber to skip the identification of a playlist.

[000110] The identification of artists, genres, and playlists can be performed in any order. For instance, in some implementations, one or more genres can be selected first. In response to the selection of one or more genres, a list of artists can be presented for selection. The list of artists can be generated based on one or more of the genre selections, such that the artists presented correspond to at least one of the selected genres. Further, in some implementations, one or more of artists, genres, and playlists can be omitted from the selection process and/or replaced by one or more other categories.

[000111] Additionally, the subscriber can be prompted to set up a profile (940). For instance, the subscriber can be asked to provide one or more items of personal information and/or to specify one or more preferences that can be used to initialize a profile. The information for which the subscriber is prompted can be collected in any sequence, and one or more items of information provided earlier in the sequence can be used to guide the collection of the remaining information. Further, in some implementations, one or more of the steps can be modified or excluded, and one or more other steps can be added. Once information has been collected by the wizard, the subscriber's local media archive can be populated (945). For instance, media included in the central media archive of the music service that corresponds to any or all of the identified artist, genre, and playlist information can be downloaded to the subscriber's local media archive. Additionally, one or more items of media that are similar to the identified artist, genre, or playlist information also can be downloaded to the local media archive. [000112] The amount of media content downloaded to the local media archive during initialization through the wizard can be determined based on one or more factors, including the amount of storage available to house the local media archive and the amount of bandwidth available to transfer the media. For instance, the automatically loaded content can be limited to a third or a half of the available storage capacity, such that the local media archive has storage available to accommodate media that is expressly selected by the subscriber. Further, the transfer of media to the local media archive can be performed in stages, such that one portion of the media content is immediately available for use and the remainder of the content is transferred at other times, such as off-peak hours or when the mobile communications device is connected to a fixed power source.

[000113] FIG. 10 shows an exemplary process flow for managing advertising served to subscribers. Advertising can be presented in various portions of interfaces presented to subscribing users, including interfaces relating to the acquisition, playback, and management of media. The advertising can take on various forms, e.g. banner ads and embedded images, and can be directed to any product or service. In the media system, one form of advertising can be the identification and display of information relating to a particular artist, album, actor, or film.

[000114] In the media system the content in the central media archive can be monitored (1005). For instance, the amount of content provided by one contributor, e.g. a music label, as a percentage of the whole archive can be determined for a time period, such as a day or a month. Other measures also can be determined, such as the number of downloads or playback instances that are attributable to a particular provider, either as a total or as a percentage of all downloads or playback instances. In some instances, measures separate from the media system also can be determined, such as the market presence of a particular provider.

[000115] In response to one or more measures associated with the media content, an advertising distribution can be determined (1010). The advertising distribution can be determined for any period, such as a day, week, or month. Further, the advertising distribution can reflect either one or more current measures (i.e., real-time or near real- time) or can be based on measures determined for a previous period. For instance, the advertising distribution for a current day can be based on one or more measures for a previous day.

[000116] Further, an advertising event can be detected (1015). The advertising event can be any event for which an advertisement (or ad impression) can be served. For instance, an interface that is presented to a user can include one or more ad display areas into which an advertisement can be inserted. Upon detecting an advertising event, an advertisement can be selected in accordance with the determined advertising distribution (1020). For instance, the advertisement can be selected such that the advertisements served over a given period comply with the distribution model. In some circumstances, advertisements can be selected solely to ensure that distribution requirements are satisfied. In some other circumstances, an advertisement can be selected based on a combination of the distribution model and one or more parameters corresponding to the subscriber, e.g. musical taste or commercial habits, such that advertisement selection can be personalized. The selected advertisement can be served to the subscriber (1025), e.g., by inserting the advertisement into an interface that is presented to the subscriber. Additionally, the advertisement impression can be recorded (1030), such that the distribution can be updated for subsequent ad selection and compliance with the distribution scheme can be demonstrated.

[000117] FIG. 11 shows an exemplary process flow for managing a smart shuffle list for use by a subscriber. The media system can provide a smart (or intelligent) shuffle capability that sequences music for playback in an intelligent manner, rather that a randomized sequence. Accordingly, the smart shuffle can provide a playback

experience more like a playlist or radio station, in that tracks cannot be repeated in close succession and adjacent tracks can have a greater degree of relatedness than if the sequence were truly random.

[000118] A smart shuffle list can be generated in advance of a subscriber request. To generate the smart shuffle list, the media service, e.g. through a smart shuffle module, can access the subscriber's instance maintained at the cloud (1 105). The media service also can access a playback history corresponding to the subscriber (1 1 10). The playback history can cover any period. Further, in some implementations, the playback history can be weighted, such as to give higher importance to more recent events.

[000119] A smart shuffle list can be generated for the subscriber (1 1 15). The smart shuffle list can include any portion of the tracks included in the subscriber's local media archive, as identified by the subscriber's instance. For instance, the smart shuffle list can be limited to a predetermined duration, such as six or twelve hours. Alternatively, the smart shuffle list can include most or all of the tracks in the local media archive, thus permitting the subscriber to skip one or more songs without risk of prematurely exhausting the smart shuffle list. Further, one or more tracks from subscribed playlists also can be included in the smart shuffle list. However, the smart shuffle list can be restricted to content that is available in the subscriber's local media archive.

[000120] The smart shuffle list can be generated in accordance with the subscriber's playback history, e.g. to prevent tracks that have been heavily played in the recent past from being prominently featured and to utilize tracks that the subscriber listens to at least periodically. Additionally, the smart shuffle list can be generated in accordance with one or more external factors, e.g. to feature currently trending tracks and to group tracks in accordance with the playback patterns of other subscribers. The smart shuffle list also can be generated in light of the sequence used for one or more previous smart shuffle lists, e.g. so that the same or a similar sequence is not repeated close in time. The smart shuffle list can be structured in any manner, including as a list of unique track identifiers that are included in the subscriber's local media archive.

[000121] The smart shuffle list can be transferred to the subscriber's device and persistently stored (1 120). For instance, the smart shuffle list can be transferred during a synchronization operation, along with other items such as media content. The smart shuffle list can be stored until it has been accessed (1 125). For example, the sequence of the smart shuffle list will not be stale until it has been used for playback. If one or more tracks are deleted from the local media archive before the smart shuffle list is accessed, those tracks can be skipped during playback based on the list. In some implementations, the smart shuffle list can be set to expire after a predetermined period of time, e.g. a week, even if it has not been accessed. If the smart shuffle list expires, it can be replaced by a new smart shuffle list during the next subsequent synchronization operation. Additionally, once the smart shuffle list has been accessed, it can be replaced by a new smart shuffle list.

[000122] FIG. 12 shows an exemplary process flow for recommending neighbors to a subscriber. The media service can include a social component through which

subscribers can interact. For instance, a subscriber can identify one or more other subscribers as friends, and interact with those friends in a social community, e.g.

through the exchange of Shout! messages and by exposing media content, such as songs and playlists, to one another. Further, the sharing of media discovery can be extended through the identification of neighbors within the social community. Neighbors can be other subscribers who have at least a threshold level of interest with respect to media in common with the subscriber and who are located within a certain proximity of the subscriber.

[000123] The media system can determine a set of subscribers to be compared (1205). The set can be any portion of the total subscriber community. Once established, two or more subscribers can be selected from the set (1210). The media interests of the selected subscribers can be compared (1215). The comparison of media interests can be performed based on any media characteristics, including one or more of genre, artist, and individual items of media content. For instance, a track-based comparison of the subscribers' respective local media archives can be performed to determine the degree of overlap. Based on the comparison, it can be determined whether the media tastes or interests of the subscribers being compared are sufficiently similar (1220). In some implementations, the degree of commonality necessary to identify subscribers as potential neighbors can be variable. For instance, for a subscriber whose taste in media is very similar to that of many other subscribers, a strong degree of similarity can be required for a neighbor identification. In contrast, for a subscriber with unique taste in media, a lesser degree of similarity can be required for a neighbor identification. If the determined degree of similarity is not sufficient, the comparison of the selected subscribers can be abandoned. [000124] Otherwise, the geographical proximity of the subscribers can be determined (1225). The geographic location used for a comparison can be the permanent location of the subscriber, such as a billing address or home address. Alternatively, the current (or recent) location of the mobile communications device associated with the subscriber can be determined, e.g. based on usage. The geographical proximity of the subscribers can be determined by comparing their respective locations, and it can be determined whether they are sufficiently close to be identified as neighbors (1230). The evaluation of geographical proximity also can be flexible, in that the amount of physical separation between subscribers can increase with greater commonality in media interests. For example, if two subscribers have all of the available Belinda Carlisle tracks in their respective local media archives, they can be identified as having a high degree of commonality with respect to music. As a result, they can be identified as neighbors even if they are located on different coasts, e.g. New York and Los Angeles. If the selected subscribers are not sufficiently close, the comparison of the selected subscribers can be abandoned. Otherwise, the subscribers can be added to a list of potential neighbors (1235).

[000125] After a comparison of the selected subscribers has been completed, it can be determined whether the set of subscribers is empty (1240). If the set is not empty, one or more subscribers can be selected from the set for comparison (1210). Otherwise, one or more neighbor recommendations can be provided (1245). For instance, one or more potential neighbors identified through the comparison can be linked with the subscriber's account, such that they can be viewed when the subscriber accesses the community. Once identified, at least a portion of a linked neighbor's account, such as their local media archive, can be explored, e.g. to discover new music.

[000126] FIG. 13 shows an exemplary process flow for recording information on a mobile communications device and reporting the information to the cloud. Information relating to a variety of activities can be recorded on the mobile communications device during operation, between synchronization operations with the cloud. For instance, statistics regarding playback and deletion of media content can be collected during operation. Also, statistics regarding the configuration, access, and use of ringtones and ringback tones can be collected.

[000127] Local reporting can be initialized on a mobile communications device participating in the media service (1305). After reporting has been initialized, reporting information can be stored locally, e.g. in a database or file (1310). The information that is collected in conjunction with reporting can vary based on the requirements or preferences specified by the media service. For example, playback information can be collected to determine what media the user is accessing and how, including one or more of a unique track identifier for each playback instance, a date/time the playback is started, and a date/time the playback is halted. Further, the granularity of one or more items of information can be specified, such as determining times to the second or millisecond. Other items of information also can be captured, including ringtone information, ringback tone information, messaging information, and browsing

information, such as tracks, playlists, and social resources the subscriber accessed.

[000128] Further, it can be determined whether a synchronization operation has been initiated (1315). If synchronization has not been initiated, the collection and storage of reporting information can continue (1310). Otherwise, if a synchronization operation is occurring, the locally stored reporting information is transferred to the cloud (1320). Once transferred, the reporting information can be accessed by one or more cloud resources. For instance, the locally recorded playback statistics can be used to derive information regarding the genres, artists, and albums the subscriber is playing, and to calculate the top tracks and/or albums for any or all genres. Accordingly, playback statistics can be used to generate media system wide statistics for purposes including providing recommendations, developing programming, and creating playlists. The playback statistics also can be used to formulate personal recommendations for the subscriber, e.g. based on the items of media for which the subscriber has shown a preference. Further, usage statistics, e.g. for ringtones and ringback tones, can be used to determine the amount of compensation due to content providers.

[000129] The mobile communications device can determine whether confirmation of the transfer has been received from the cloud (1325). If confirmation has not been received, the mobile communications device can continue to wait for confirmation, e.g. until the synchronization process is terminated. If confirmation is received, the locally stored reporting information has been successfully transferred to the cloud and can be deleted from the local storage (1330). Accordingly, the amount of reporting information that is stored locally at any given time can be limited to preserve storage capacity.

[000130] FIG. 14 shows an exemplary process flow for generating and providing recommendations. Recommendations can be requested from a wide variety of interfaces, including interfaces associated with each of the functional areas included in the media service, such as MyMusic (the local media archive), MyDJ (playlists), GetSocial (the social networking community), and GetMusic (the music store). In some implementations, the recommendations can be generated and provided to a requesting subscriber in real-time or near real-time. In some other implementations,

recommendations can be generated offline for all or part of the central media catalog, and then provided to a requesting user in real-time or near real-time.

[000131] A request for a recommendation can be received in response to the selection of a recommendation button or other such subscriber command input (1405). For instance, a recommendation or suggestion button can be included in an interface that lists one or more items of media content. Further, the request for a recommendation can specify one or more seed items of media upon which the request is founded, such as one or more tracks, albums, artists, or genres. In some implementations, a request also can be founded on a playlist or collection, such as another subscriber's local media archive.

[000132] In response to the received request, the media service can identify items of media content that match the seed items included in the request (1410). If subscriber history is available, a list of media items can be generated based on direct and indirect associations between the one or more referenced media items and either or both of tracks and subscribers, as indicated by system data. For instance, one or more tracks that are similar to a referenced track can be identified, e.g. based on a correspondence between the genre or artist. Further, one or more tracks that are jointly held by subscribers with one or more of the referenced tracks also can be identified as similar. Alternatively, if subscriber history is not available, a list of similar media items can be identified based on classifications in one or more catalogs, such as the All Music Guide. For instance, a list of similar artists, albums, or songs can be identified in response to a referenced artist, album, or song, respectively. The matching items of media content can represent the full list of candidate items that can be provided as a recommendation to the subscriber.

[000133] Once the full list of candidate items has been developed, the list of possible recommendations can be filtered (1415). The filtering can be used to narrow the list of possible recommendations down to a manageable amount. The filtering can be performed based on a variety of factors, including user history and industry data. For instance, the list of possible recommendations can be filtered to remove all tracks, artists, or albums the user has previously deleted. Also, the list can be filtered to remove any tracks, albums, or artists the user has played more than a threshold number of times. Further, the remaining items in the list of recommendations can be weighted, e.g. based on an assigned rating, industry picks, and user preferences, e.g. for preferred artists and/or genres. In some implementations, filtering also can be performed based on items of media that already are stored in the requesting

subscriber's local media archive.

[000134] The number of items to return as recommendations also can be determined. For instance, the storage capacity and degree to which it is filled can be determined. Also, it can be determined whether one or more media items, e.g. relating to an unused playlist, can be deleted from the local media archive. The list of media items can then be reduced to the number of media items that can be recommended, e.g. the top 25 items. Once identified, the recommended media items can be identified to the requesting subscriber (1420). For instance, an interface providing a track listing can be returned. In some implementations, the recommendation process can be iterative, and the subscriber can further request a recommendation based on a selected one or more of the recommended media items.

[000135] FIG. 15 shows an exemplary process flow for configuring a subscriber's community. The community can provide a forum for social interaction within the media server environment. Further, the community for each subscriber can be different, as it includes other subscribers with whom the subscriber has formed a connection. The community can include friends, with whom the subscriber has formed an explicit connection, and neighbors, who can be identified to the subscriber based on one or more common aspects, such as music preferences.

[000136] Configuration of a subscriber's community can be initiated, e.g. in response to the subscriber accessing the community portion of the media server environment (1505). It can be determined, whether the subscriber has stored or otherwise identified any contacts (1510). For instance, a contact list maintained on the subscriber's mobile communications device can be analyzed and contact information can be extracted. Further, a computing device from which web-based management is performed also can be scanned to identify any defined contacts. If any contacts are identified, information identifying the one or more contacts can be provided to the media server environment, e.g. to the internal social services module 418. The identified contact information can then be compared with information identifying subscribers to the media system (1515). For instance, name, phone number, and/or e-mail address information can be used to determine whether any of the identified contacts also are subscribers to the media system. If any matching contacts are identified, the contacts can be automatically added to the subscriber's community as friends (1520). In some implementations, the addition of contacts as friends can require subscriber approval. Additionally, the subscriber's contact list can be analyzed periodically to determine whether any new contacts who also are subscribers have been added. Newly discovered contacts who also are subscribers can be added as friends as they are discovered.

[000137] Further, it can be determined whether the subscriber has created a local media archive (or catalog or library) (1525). If the subscriber has not created a local media archive, configuration of the subscriber's community can be terminated (1545). Otherwise, the subscriber's media archive can be accessed (1530). The subscriber's media archive can then be compared with the media archives maintained by other subscribers to determine neighbor recommendations (1535). They neighbor recommendations can then be presented to the subscriber (1540) and community configuration can be terminated (1545).

[000138] FIG. 16 shows an exemplary mobile communications device for use with the media server environment. Mobile communications device 1600 can be configured to provide wireless voice communication and data communication. Mobile

communications device 1600 can include physical controls, e.g. a power button 1602, a volume control 1604, a phone button 1606, an end call button 1608, and a camera button 1610. Further, mobile communications device 1600 can include outputs, such as microphone 1612 and display 1614, which can be a touch sensitive display, e.g.

resistive or capacitive. In some implementations, mobile communications device 1600 also can include one or more speakers 1616 configured to output voice and/or music. The one or more speakers can be located on either or both of the back and front of mobile communications device 1600. Further, an accessory jack, e.g. for headphones, also can be included.

[000139] Additionally, mobile communications device 1600 can include a media button 1618, which can be used to access media functionality. In some implementations, the media button 1618 can be a multi-function button. For instance, a single press of the media button 1618 can toggle the display between a media playback interface and the phone interface. Further, pressing and holding the media button 1618 can cause an interface corresponding to the media service, e.g. a home menu, to be presented. The mobile communications device 1600 can be configured such that accessing the media button 1618 causes the corresponding media functionality to be presented, regardless of the previous function being performed and location within the device's command hierarchy.

[000140] FIG. 17 shows an exemplary process flow for managing bulk downloads to a subscriber's local media archive. The cloud can be configured to permit and manage the transfer of a bulk category of media content to the local media archive of a subscribing user. A request to transfer a bulk category, such as all of the media items associated with a particular artist, can be transmitted from a subscriber device to the cloud (1705). The request can be formatted and transmitted as a single request encompassing all of the media items within that category. For instance, the request can specify that all media items corresponding to the artist "Journey" are to be transferred to the requesting subscriber's local media archive. The subscriber's instance maintained at the cloud can then be updated to include all media items available in the central media archive that are associated with the artist "Journey" (1710). No change will be noted, e.g. in a change record, for media items already associated with the subscriber's instance. A synchronization operation can be performed subsequent to issuance of the bulk transfer request (1715). Through the synchronization operation, media items associated with the bulk transfer request can be transferred to the subscriber's device (1720). The transfer can be managed in accordance with established rules and protocols, including time of day and bandwidth restrictions.

[000141] FIG. 18 shows an exemplary process flow for managing a take-down request. A take-down request can be received by the media system from a content provider, requesting that a target item of media content, e.g. a track, be removed from the media system, including the local media archives and the central media archive (1805). The take-down request also can specify a period in which compliance is required to be obtained, such as 24 or 48 hours.

[000142] In response to the take-down request, local media archives in which a copy of the target item of media content is stored can be identified (1810). The subscriber local media archives storing the target item of media content can be identified based on the instances maintained by the cloud, without communicating with any subscriber devices and without accessing any local media archives. Further, a synchronization directive can be issued from the cloud to the subscriber devices in which the target item of media content is stored (1815). In some implementations, the identification of local media archives storing the target item of media content and transmission of the

synchronization directives can be performed automatically, in response to receipt of the take-down request.

[000143] The target item of media content can then be deleted from the central media archive and any playlists managed by the cloud (1820). Further, through the

synchronization operations, the target item of media content can be deleted from the local media archive of each subscriber device storing a copy (1825). Reference to the target item of media content also can be deleted, such as references or links in playlists and play queues. A message also can be transmitted to the subscribers whose local copy of the target item of media content was deleted, e.g. notifying the subscriber of the deletion and the reason therefore (1830). Because the cloud can determine which subscriber devices have the target item of media content stored locally, only those subscriber devices need be forced to synchronize and to receive the communication regarding the take-down.

[000144] Additionally, e.g. using the subscriber instances maintained at the cloud, it can be determined that the take-down process has been completed (1835). Upon completion, a message confirming deletion of all copies of the target item of media content from the media system can be transmitted to the requesting content provider (1840). In some implementations, two or more of the steps included in the take-down process can be performed in parallel.

[000145] The disclosed techniques for providing subscribers with unlimited access to media content may be implemented using one or more computer programs comprising computer executable code stored on a tangible computer readable medium and executing on the data processing device or system. The computer readable medium may include a hard disk drive, a flash memory device, a random access memory device such as DRAM and SDRAM, removable storage medium such as CD-ROM and DVD- ROM, a tape, a floppy disk, a Compact Flash memory card, a secure digital (SD) memory card, or some other storage device. In some implementations, the computer executable code may include multiple portions or modules, with each portion designed to perform a specific function described in one or more figures. In some

implementations, the techniques may be implemented using hardware such as a microprocessor, a microcontroller, an embedded microcontroller with internal memory, or an erasable, programmable read only memory (EPROM) encoding computer executable instructions for performing the disclosed techniques. In other

implementations, the techniques may be implemented using a combination of software and hardware. [000146] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, including graphics processors, such as a GPU. Generally, the processor will receive instructions and data from a read only memory, a random access memory, or both. The elements of a computer include a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic disks, magneto-optical disks, and optical disks.

Information carriers suitable for embodying computer program instructions and data include all forms of non volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD

ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[000147] To provide for interaction with a user, the systems, apparatus, and techniques described here can be implemented on a data processing device having a display device (e.g., an LED (light emitting diode) or LCD (liquid crystal display) monitor) for displaying information to the user and a positional input device, such as a keyboard and a pointing device (e.g., a touch screen, mouse, or trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[000148] While this specification contains many specifics, these should not be construed as limitations on the scope of any innovation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular innovations. Certain features that are described in this specification in the context of separate embodiments also can be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment also can be implemented in multiple embodiments, either separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[000149] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program

components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[000150] Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this application, including in the attached appendix.

Claims

What is claimed is:

1 . A media content distribution system comprising:

a mobile communications device configured to communicate over a wireless telecommunications network; and

a media server environment comprising one or more servers configured to communicate over the wireless telecommunications network and to tangibly store media content, the media server environment including processor electronics configured to perform operations comprising:

receiving an access request from the mobile communications device; identifying a subscriber account associated with the mobile communications device;

determining that the subscriber account is current and authorized to access the media server environment; and

providing authorization to access the media server environment;

wherein the authorization also enables access to media content stored on the mobile communications device.

2. The media content distribution system of claim 1 , wherein the processor electronics are further configured to perform operations comprising:

maintaining a subscriber account instance that identifies media content stored on the mobile communications device.

3. The media content distribution system of claim 2, wherein the processor electronics are further configured to perform operations comprising:

receiving a request, associated with the identified subscriber account, to download an item of media content stored in the media server environment; and

updating the subscriber account instance to include an identification of the item of media content.

4. The media content distribution system of claim 3, wherein the processor electronics are further configured to perform operations comprising:

initiating transfer of the item of media content to the mobile communications device over the wireless telecommunications network.

5. The media content distribution system of claim 4, wherein transfer of the item of media content is initiated in response to detection of a synchronization event.

6. The media content distribution system of claim 3, wherein the request to download an item of media content is received by the media server environment from a device other than the mobile communications device.

7. The media content distribution system of claim 1 , wherein the stored media content comprises full-track audio files.

8. A media content distribution system comprising:

a mobile communications device configured to communicate over a wireless telecommunications network, the mobile communications device including a memory for tangibly storing a user media archive; and

receiving a request from the mobile communications device to subscribe to a playlist;

comparing a track listing associated with the playlist and a track listing corresponding to the user media archive;

identifying, based on the comparing, a track associated with the playlist that is not included in the user media archive; and transferring, during a synchronization operation, the identified track to the mobile communications device for storage in the user media archive.

9. The media content distribution system of claim 8, wherein the processor electronics are further configured to perform operations comprising:

associating the playlist with an instance of the user media archive maintained by the media server environment.

10. The media content distribution system of claim 8, wherein the identified track comprises a full-track audio file.

1 1 . The media content distribution system of claim 8, wherein transferring further comprises transmitting the identified track to the mobile communications device over the wireless telecommunications network.

12. The media content distribution system of claim 8, wherein the processor electronics are further configured to perform operations comprising:

determining that the identified track has been deleted from the subscribed playlist; and

deleting the identified track from the user media archive.

13. The media content distribution system of claim 8, wherein the mobile communications device memory comprises a removable memory module.

14. A method of providing media to a mobile communications device, the method comprising:

receiving, by a media server, a request to access an item of media;

identifying a subscriber account corresponding to the received request;

associating the item of media with an instance of the identified subscriber account, the instance being maintained at the media server; and transferring the item of media to a mobile communications device associated with the identified subscriber account.

15. The method of claim 14, wherein the subscriber account is provided with unlimited access to media content.

16. The method of claim 14, wherein the item of media comprises one of a ring tone and a ringback tone.

17. The method of claim 14, further comprising:

detecting, during a synchronization operation, that another item of media has been deleted from the mobile communications device; and

deleting an indication of the another item of media from the instance of the identified subscriber account.

18. The method of claim 14, further comprising:

maintaining, by the media server, multiple instances of the identified subscriber account, wherein each of the multiple instances corresponds to a different memory device.

19. The method of claim 14, further comprising:

validating the identified subscriber account based at least in part on information associated with the received request prior to transferring the item of media to the mobile communications device.

20. The method of claim 14, further comprising:

associating a synchronization indicator with the instance of the identified subscriber account; and setting a value of the synchronization indicator to indicate that synchronization has been lost when a change to the instance of the identified subscriber account is detected.