WO2008052050A2 - Procédé et dispositif de lecture de contenu multimédia numérique - Google Patents

Procédé et dispositif de lecture de contenu multimédia numérique Download PDF

Info

Publication number
WO2008052050A2
WO2008052050A2 PCT/US2007/082373 US2007082373W WO2008052050A2 WO 2008052050 A2 WO2008052050 A2 WO 2008052050A2 US 2007082373 W US2007082373 W US 2007082373W WO 2008052050 A2 WO2008052050 A2 WO 2008052050A2
Authority
WO
WIPO (PCT)
Prior art keywords
media files
content
playback
media
track
Prior art date
Application number
PCT/US2007/082373
Other languages
English (en)
Other versions
WO2008052050A3 (fr
Inventor
Bradley D. Kindig
Original Assignee
Slacker, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Slacker, Inc. filed Critical Slacker, Inc.
Priority to CA2667573A priority Critical patent/CA2667573C/fr
Priority to EP07868561A priority patent/EP2080114A4/fr
Publication of WO2008052050A2 publication Critical patent/WO2008052050A2/fr
Publication of WO2008052050A3 publication Critical patent/WO2008052050A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41422—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance located in transportation means, e.g. personal vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4826—End-user interface for program selection using recommendation lists, e.g. of programs or channels sorted out according to their score

Definitions

  • This invention relates generally to methods, systems, and devices for receiving, storing and playing back digital media files and, more particularly, to methods, systems, and devices capable of acquiring digital media files over wired and wireless communications links that may be intermittently connected and potentially subject to noise, interference, or other forms of connectivity disruption.
  • Portable media players and media-enabled phones are able to load content from personal computers over wired connections.
  • a few media players and certain phones are able to load content over wireless networks.
  • a few portable media players have connectivity to satellite radio systems. At least one such portable player also allows the user to record and store content from the satellite broadcast as if the device contained an integrated tape deck.
  • traditional broadcast mediums such as television, radio, and even satellite radio tend to offer minimal opportunities for user customization and interactivity. While the number of channels continues to increase in each of these mediums, the mediums themselves fail to accommodate even simple customizations such as "Classic Rock with extra U2, and no Supertramp.”
  • existing portable music players also fail to address the needs of many users that want a professionally programmed listening experience akin to traditional radio, but want their user specific preferences adhered to. With these existing devices, the users must acquire their own content and program their own channels at substantial time, effort, and cost.
  • existing media players capable of receiving broadcast transmissions such as satellite radio receivers used in cars and other portable devices, can be frustrating to use in that temporary losses in signal result in interruption of the listening experience.
  • FIG. 1 illustrates an embodiment of a portable device and associated system in a mobile application in accordance with aspects of the present invention.
  • FIG. 2 illustrates an embodiment of a portable device and associated system in a residential or office application in accordance with aspects of the present invention.
  • FIG. 3 illustrates an embodiment of a portable device and associated system in a mobile application in accordance with aspects of the present invention.
  • FIG. 4 illustrates an embodiment of an object configuration in accordance with aspects of the present invention.
  • FIG. 5 is a state diagram showing an embodiment of a content playback implementation in accordance with aspects of the present invention.
  • FIG. 6 is a state diagram showing an embodiment of a user interface implementation in accordance with aspects of the present invention.
  • FIG. 7 is a state diagram showing an embodiment of a wireless connection implementation in accordance with aspects of the present invention.
  • FIG. 8 is a state diagram showing an embodiment of content processing in a unidirectional connection in accordance with aspects of the present invention.
  • FIG. 9 is a flowchart showing an embodiment of a start station process in accordance with aspects of the present invention.
  • FIG. 10 is a flowchart showing an embodiment of a stop station process in accordance with aspects of the present invention.
  • FIG. 11 is a flowchart showing an embodiment of a skip logic process in accordance with aspects of the present invention.
  • FIG. 12 is a flowchart showing an embodiment of a next track process in accordance with aspects of the present invention.
  • FIG. 13 is a flowchart showing an embodiment of an add to sequence process in accordance with aspects of the present invention.
  • FIG. 14 is a flowchart showing an embodiment of a select track process in accordance with aspects of the present invention.
  • FIG. 15 is a flowchart showing an embodiment of a playback scoring process in accordance with aspects of the present invention.
  • FIG. 16 is a graph of song aging results for an 80's station based on an embodiment of the present invention.
  • FIG. 17 is a graph of song aging results for a Classic Rock station based on an embodiment of the present invention.
  • FIG. 18 is a graph of song aging results for an Alternative station based on an embodiment of the present invention.
  • FIG. 19 is a graph of track sequence scoring results as a function of rest for an embodiment of the present invention.
  • FIG. 20 illustrates an allocation of inventory pools for media content storage for an embodiment of the present invention.
  • FIG. 21 is a flowchart showing an embodiment of an add track process in accordance with aspects of the present invention.
  • FIG. 22 is a flowchart showing an embodiment of an inventory cull process in accordance with aspects of the present invention.
  • FIG. 23 is a graph of duty cycle adaptation for various types of stations based on an embodiment of the present invention.
  • FIG. 24 is a flowchart showing an embodiment of a delete tracks process in accordance with aspects of the present invention.
  • FIG. 25 is a flowchart showing an embodiment of a scan playlists process in accordance with aspects of the present invention.
  • FIG. 26 is a flowchart showing an embodiment of a save tracks process in accordance with aspects of the present invention.
  • FIG. 27 is a table illustrating inventory management symbols and description based on an embodiment of the present invention.
  • FIG. 28 is a flowchart showing an embodiment of a ban tracks process in accordance with aspects of the present invention.
  • the digital media content reception and playback device (hereinafter also denoted for brevity as a “device” or a “player”) is capable of receiving content over intermittent connections and organizing and sequencing the content into a program that leaves a listener with the impression that traditional programming is being delivered, but which nonetheless accommodates the listener's specific preferences and may be customized and tailored dynamically to user preferences.
  • Content may be created, managed, and provided by a content management system including one or more servers configured to receive user information as well as content and content requests, store content, manage content, customize content, distribute content via wired or wireless channels, and provide other related management and distribution functions.
  • a content management system including one or more servers configured to receive user information as well as content and content requests, store content, manage content, customize content, distribute content via wired or wireless channels, and provide other related management and distribution functions.
  • a content management system and any associated servers or other components is also described herein simply as the "server” for purposes of brevity.
  • the device leverages the expertise of professional content programmers that acquire and filter a broad base of relevant content and define the rules that determine the mix and sequencing of content to be played on the device.
  • the user is freed from the difficult task of acquiring content and creating playlists.
  • the device will be configured to filter incoming content for transmission errors and discard content that contains artifacts that would be perceived by the user.
  • the ability to render pristine content is preserved even when the device is in areas with poor or no reception.
  • the device comprises a personal digital audio player for use in and out of automotive or other mobile environments. While this embodiment is described hereinafter in terms of audio playback, it will be apparent to those skilled in the art that the invention is equally applicable to photos, graphics, images, video or other types of multimedia content.
  • the device may be configured to dock in an automobile or other vehicle.
  • the device When the device is docked in an automobile, it may be connected to a satellite antenna that is capable of receiving a unidirectional broadcast of audio content and data.
  • the device may be configured with built-in wired or wireless capabilities using networks such as those based on IEEE standard 802.11, or other local or wide area networks capable of providing connection to wireless networks.
  • networks such as those based on IEEE standard 802.11, or other local or wide area networks capable of providing connection to wireless networks.
  • the device may be configured to dock or otherwise connect with home or office based systems such as personal computers or other devices capable of networking, or with home entertainment or similar systems.
  • home or office based systems such as personal computers or other devices capable of networking, or with home entertainment or similar systems.
  • the device when the device is operating with a unidirectional connection as it typically is when receiving content over a satellite link, the device receives content that is broadcast on the connection, with content typically originating from a server or servers that are part of a content management system.
  • the device compares the content against one or more station profiles and decides whether to keep the content or whether to discard it. In essence, the device decides if the content is of interest to its user, based on a set of user preferences, and stores the content of most interest for playback.
  • One aspect of the present invention relates to systems and methods for implementing decision processes for selecting, storing, and playing content and is described in detail in the sections that follow in relation to Inventory Management.
  • the process of receiving, analyzing, and caching or discarding content typically takes place independently of device playback.
  • the device will continuously receive and process incoming content so long as it is sufficiently powered and has an operational connection.
  • the device is configured to be capable of simultaneously playing back content from the cache while receiving and processing new content into the cache.
  • the device when connected to an associated content broadcasting service with a bidirectional connection, the device is configured so that it can transmit its preferences to a content management system so that only content of interest is provided and downloaded to the device. This is done by either fully or partially offloading the Inventory Management function to the server side of the connection (where the device is part of the client side).
  • the device transmits its station profiles to the server and receives a prioritized list of content to download.
  • the device downloads the content in priority order.
  • the list is prioritized so as to maximize the improvement to the device's inventory should the connection be lost before all tracks are downloaded.
  • the device can play the content in its cache.
  • the cached content may be organized such that the device's algorithms can efficiently generate playlists that approximate the crafted song sequences created by professional radio programmers.
  • Professional radio programmers may be used to support the device population by categorizing the content transmitted to the device into stations and station categories. The radio programmers may also specify the rules used by the device to sequence the content for a given station. This may be done in conjunction with the content management system, with the information being input, stored, processed, and output by one or more servers or other data storage and distribution elements.
  • the user may then access these sequences on the device by selecting the station by name or preset button, similar to the way a user selects a station on a traditional car stereo or satellite radio receiver.
  • the user may also be provided with options and selections to customize the station and interact with playback order in a way that is not possible using traditional broadcast receivers. Embodiments of these processes are further described and illustrated below.
  • each device may be configured to select the next song for playback independently of the broadcast stream, each device can customize playback order according to the preferences of its owner or user. For example, some of the unique features of the device that are not possible with traditional radio receivers may include:
  • station playback The user may adjust station knobs or "sliders" to bias the track selection towards songs with certain attributes.
  • station slider controls include (but are not limited to): o Newer ⁇ - -> Older o Harder ⁇ - -> Softer o Popular ⁇ - -> Obscure o Favorite ⁇ r -> Non-Favorite • Ability to create user tailored stations. While most stations can be created by professional radio programmers, users that are so inclined can create their own stations using these same tools or variants thereof.
  • Very large station catalog While a limited number of stations are supported through the unidirectional channel, users that update their players via bidirectional channels can have access to a very large catalog of stations. Potentially, this catalog can contain stations created by the user community as well as stations created by programming professionals. This can also include content published by Really Simple Syndication (RSS) including audio-blogs or "podcasts.”
  • RSS Really Simple Syndication
  • FIGS. 1 and 2 depict the physical architecture of embodiments of aspects of the invention in a variety of contexts.
  • FIGS. 1 and 2 provide representations of embodiments of systems in accordance with the invention in cases where the digital media playback device is docked within an automobile and in a home location, respectively.
  • a system 100 may include a portable device 110 connected to a car dock 130, wherein the car dock 130 may include the capability of receiving and/or sending content to a content management system 160 through a radio service 150.
  • This connection will typically be via a wireless connection using systems based on satellite communication and/or wireless networks such as those based on IEEE 802.11 standards (Wi-Fi) or other local or wide area networking standards.
  • the docking may include standard interfaces between the portable device 110 and the dock 130 such as USB, or may be based on proprietary interfaces.
  • FIG. 2 illustrates one embodiment of a system 200 configured for home, office, or business use of portable device 110.
  • System 200 may include connection through a home dock 230 and/or via other connection methods such as through a home or office networking device 220, a PC 250, home A/V equipment 260, or via other connections configured to send information and receive content from a content management system 160.
  • FIG. 3 illustrates one embodiment of a system 300 wherein portable device 110 is used as a mobile or portable device in conjunction with a wireless network connection 220, such as a router or other networking device based on IEEE standard 802.11 or other local or wide area networking standards.
  • a typical portable system 300 will include a listening device (headphone, ear buds, etc.) 310 allowing the user to move about and isolate audio content from the environment if desired.
  • aspects of the present invention are related to playback and content management on the device.
  • a set of core objects used in a preferred embodiment are described below and illustrated in FIG. 4. It is noted that the object-oriented architecture described below is not unique and other objects and associated object configurations may also be used in keeping within the spirit and scope of the invention.
  • PlayerContext The parent object that implements the overall player behavior.
  • a Station is a content channel analogous to a terrestrial radio station.
  • the user may store one or more favorite stations as 'presets' on the device to optimize their ability to access the channel.
  • the user will have access to the broader catalog of all available Stations through the device.
  • the Station holds the settings / customizations that are used to bias the content cached or played on the station (sliders) as well as the engine used to sequence the Station's content (Clock).
  • StationProfile is a definition of the rules and settings used to assemble a station.
  • a set of StationProfiles is loaded onto the device.
  • Some settings in the StationProfile may be customized by the device user. Such customization may involve, for example, setting sliders in accordance with user preferences.
  • the station profile includes the current biases (as set by sliders) towards selecting content based on Popularity, Energy (hard/smooth), Favorites, and Age. Providing a setting to control whether or not certain types of content will be permitted to be played enables an alternate form of customization to be effected.
  • StationProfiles for a core set of stations are typically created and maintained by professional radio programmers. These station profiles may be transmitted on either the bidirectional or unidirectional links to update the profiles in the device from time to time.
  • a StationProfile includes the definition of the Clock and the Buckets that comprise the Clock that will be used on the device.
  • the StationProf ⁇ le may be thought of as a set of rules or instructions for creating a station or a serialization of the Station and its associated objects.
  • the StationProf ⁇ le is an XML document.
  • the StationProf ⁇ le is a more compact binary format with a corresponding parsing schema.
  • Other embodiments of StationProfiles based on any of a variety of data formatting and storage methods may also be used.
  • Clock - As described herein, a Clock is utilized in sequencing content.
  • content for a station is categorized. For example, songs that are the current hits and are getting the most airplay might be categorized as 'Current' songs. Content that was formerly a Current song, but is fading in popularity might be categorized as 'Recurrent.'
  • the Clock is an ordered list of these categories (called Buckets) used to create a song sequence.
  • Buckets used to create a song sequence.
  • a song is chosen from the first Bucket in the Clock, followed by the second Bucket and so on until the last Bucket is reached, whereupon sequencing continues by returning to the first Bucket.
  • the creator of a Station may define as many Buckets as desired and sequence them as they see fit.
  • Bucket - is a category of content used in Clock sequencing as described above.
  • two types of buckets SongBuckets and RuleBuckets are utilized.
  • SongBuckets are buckets for which songs are explicitly categorized. That is, a Bucketld attribute is associated with the song (i.e., by a content programmer) that categorizes the song explicitly into the Bucket with that matching identifier.
  • RuleBuckets categorize content by scoring one or more attributes of the song against the Bucket's rules. For example, a RuleBucket might select content that is 'older than 1975 ' and 'in the Hard Rock genre. '
  • HeavyRotation bucket is a bucket whose songs are designed to repeat at a given rate. Most buckets will implement logic to avoid the repetition of songs to ensure variety.
  • HeavyRotation buckets contain the 'new, hot' songs that are desirable to repeat so long as they are still 'new and hot.'
  • Header As described herein, a Header is content metadata that is used to describe the attributes of the content/song.
  • a Bucket manages its inventory by maintaining a list of Headers. Set forth below is a table containing the type of information included within an exemplary Header of a given media file.
  • Attribute is a logical name/value pair embodying a fact or piece of metadata about the content.
  • the Header stores Attributes.
  • attributes may be stored in a fixed layout in the Header or stored as Id, Value pairs or Classld, Id, Value triples. In the latter case, Classld serves to specify the identifier namespace for Id so that multiple, overlapping identifier spaces can be used.
  • Rule - As described herein, Rules serve to combine Attributes and other derived information (for example, the last time the track was played) in order to form scores. Scores are ultimately used to determine playback order and priority during inventory management. Specializations of Rules include SequenceRules for scoring Headers based on the history of matching artists, albums, or tracks in the Sequence; AttributeRules for scoring Headers based on attribute matching; as well as RuleSets for combining a set of Rules into a single score. Other specializations of Rules may also be used. [0070] RuleSet - As described herein, a RuleSet executes a set of rules and combines their scores in a specific way. There are specialized RuleSets for combining SequenceRules into sequence scores (SequenceRuleSet) and for combining AttributeRules into attribute scores (AttributeRuleSet).
  • a MediaFile is the content actually rendered by the media player to affect playback of the content.
  • Sequence As described herein, a Sequence is the list of content already played and in the queue to be played. The Sequence is examined to implement rules to limit repetition.
  • SequenceElement - As described herein, a Sequence Element is an element stored in a Sequence. Binds a Header with the timestamp when it was played for use with time -based SequenceRules.
  • FIG. 4 is a UML diagram showing an exemplary aggregation of the core objects described above.
  • State transition diagrams of embodiments of the device as shown in FIGS. 5-8 illustrate high-level functional behavior and provide a roadmap for the detailed descriptions that follow.
  • the device will have separate threads of control running simultaneously under control of an operating system that handles thread and/or process scheduling.
  • the operations associated with the state diagrams will be operating simultaneously in their own contexts.
  • embodiments of state diagrams as illustrated in the associated figures are described.
  • the program execution associated with the various state diagrams are typically implemented on one or more modules within the device, such modules typically including computer hardware, software, firmware and/or combinations of these elements.
  • the computer software is typically stored on a computer readable medium such as memory and includes instructions configured to be executed by one or more processors.
  • FIG. 5 illustrated an embodiment of a state diagram 500 representative of the processing states and events related to device playback of stored media files. These processing states are described in detail as applicable. An overview is as follows:
  • the device renders content by transferring audio or other data from the current track to the decoder.
  • the decoder decodes the data and sends the raw digital audio or other content to a digital to analog converter (DAC) or other output device such as a display, and to the device's audio amplifiers and line outputs.
  • DAC digital to analog converter
  • process execution may first begin in an initialization state 510. Execution may then transition to a stopped state 520, wherein execution is stopped pending user input or other execution initialization.
  • execution transitions to a Playing state 530 wherein playback of content such as audio files/tracks (MP3s, WMAs, etc.) is performed (i.e. the track is played/rendered on the device).
  • a user may be able to provide input to direct execution of the device to Skip a track, or the track or file may end, wherein a Next Track state is entered, with execution proceeding to determine a new track to be played and then return execution to the Playing state 530.
  • a user and/or other input may also be enabled to enter a Stop instruction wherein device execution transfers from Playing state 530 to Stopped State 520.
  • FIG. 6 illustrates an embodiment of a state diagram 600 showing some of the states used in an implementation of a state machine providing a device user interface.
  • An associated event processing table is shown below in Table 2. Additional states/functions that may be peripheral are not shown for purposes of clarity.
  • execution proceeds to an initialization phase at state 620, where the application registers event handlers for the various input devices and other events generated by the device. Execution then proceeds to a Wait state 630. When an event is received, the handler is dispatched at state 640. The event handler may create a new thread to handle the event or place the event in the queue of an existing thread. Table 2 below further illustrates state and event processing of one embodiment of the invention.
  • State diagram 700 of FIG. 7 illustrates one embodiment of a set of processing states and events relating to connection of the device to wireless networks and to updating of media file content stored by the device via such networks.
  • device execution may proceed to a Not Connected Idle state 740.
  • the thread may be configured to wait for an event to trigger a connection, for example a timer expiring or an explicit request by the user to connect. Power management may also affect this logic. From this state, execution may proceed to a Scanning state 720 where potential connections may be detected. A time out may also be applied allowing execution to return to the Not Connected Idle state 740 after a predetermined period.
  • execution may proceed to state 730, where a networking update may be performed based on desired network utilization. For example, if the connection succeeds, an update exchange sending information and/or receiving content with the content management system and/or any associated servers may be executed. If the update completes before disconnection of the device, the device may enter the Connected Idle state 750 and wait for triggers to initiate an additional update at state 730. Upon disconnection based on, for example, timeouts, user requests to disconnect, or other events, execution may be returned to Not Connected Idle state 740.
  • FIG. 8 is a state diagram 800 illustrating an embodiment of various processing states related to the processing of content in the case of unidirectional connections to a source of content.
  • a unidirectional connection is established between the playback device and a satellite-based delivery system through an Antenna Unit (AU) capable of being operatively connected to the playback device.
  • the Antenna Unit is responsible for receiving tracks and data over the unidirectional (satellite) connection and creating regular files from the received signal.
  • the AU is implemented as a docking station that the device plugs into, for example, when the device is in a car.
  • execution may proceed to a Not Connected Idle state 820.
  • the device thread may remain in the idle state until it detects that it has been connected to the AU by, for example, a user request or AU trigger event.
  • the device and the AU may then perform a secure handshake at Player/AU Handshake state 830 to authenticate one another and pass decryption keys or other information.
  • the device may return to Not Connected Idle state 820 to repeat the process.
  • thread execution may proceed to a Connected Idle state
  • a Data Available trigger event may transition execution to an Update Data state 850 wherein a data file or files may be provided, after which execution may be returned to Connected Idle state 840.
  • Track or other content availability may be signaled by a Track Available Trigger to transfer execution to Add Track state 860.
  • tracks or other content may be added, with execution then returned to Connected Idle state 840.
  • Connected Idle state may also allow for a transition to Not Connected Idle state 820 based on a disconnection signaled triggered by a user input, timeout, or other event.
  • Playback processing concerns the implementation of various processes that are related to the User Interface and Player State Diagrams previously described.
  • processes are typically implemented on one or more modules within the device, such modules typically including computer hardware, software, firmware and/or combinations of these elements.
  • the computer software is typically stored on a computer readable medium such as memory and includes instructions configured to be executed by one or more processors. It is noted that, while the processes associated with the figures include particular stages shown in the figures and described in the associated written description, it is apparent that other processes including fewer, more, or different stages than those shown in the figures are within the spirit and scope of the present invention. Accordingly, the processes shown in the following figures are provided for purposes of illustration, not limitation.
  • FIG. 9 is a flowchart 900 representative of one embodiment of a Start Station process in accordance with aspects of the invention.
  • Stations may generate the sequence of content to be played one or more items ahead. This allows the player to more efficiently pipeline content into the decoders. It may also allow for potentially faster skip operations as well as displaying to the user a song or songs that are to come in the playback sequence.
  • execution may begin with a Start Station initialization stage 910 wherein a user may select a particular station for execution or a station for execution may otherwise be selected. Stage 920 may then determine whether the desired station is the current station. If it is, the station selection process may be concluded by transitioning to stage 970. Alternately, if the desired station is not the current station, stage 930 may determine whether a current station is playing. If a station is playing, it is stopped at stage 950 (an implementation of this stage is further shown starting at stage 1010 as shown in FIG. 10), and execution transferred to Start Player stage 960. Alternately, if a current station is not playing as determined at stage 930, Start Player stage 960 may be directly executed. Playback/rendering of audio tracks and/or other content are then initiated at Start Player stage 960, after which execution of the Start Station process is completed at stage 970.
  • Stop station execution begins at stage 1010, with execution transferring to Stop Player stage 1020 wherein station playback/rendering is halted. The portion of the sequence pre-generated for future playback may be truncated at stage 1030. The stop station process is then completed at stage 1040.
  • Skip handling is typically triggered by a user interface request to skip the current track.
  • the device will allow users to skip certain tracks.
  • the device logic must enforce certain business rules such as only allowing users with a specific tier of service to skip tracks, applying certain limits on the number of skips, or preventing users from skipping certain content such as advertisements.
  • a flowchart 1100 representative of one embodiment of a Skip process in accordance with aspects of the invention is illustrated.
  • a skip process is typically initiated at stage 1110, such as by a user request.
  • Execution proceeds to stage 1120, where a determination is made as to whether the track can be skipped (i.e. whether the track is "skippable").
  • Tracks may not be skippable based on user service limitations, content limitations, DMCA or other statutory requirements, or for other reasons.
  • a Can't Skip Dialog may be presented at stage 1140 providing a display, audible indication, or other indication that the track cannot be skipped, after which execution of the skip process is completed at stage 1160.
  • a second test may be applied at stage 1130 to determine whether the particular user's service allows skipping the track. This may be based on reasons such as those described above, as well as others such as the number of tracks skipped previously and the like. If the user is not allowed to skip the particular track a Not Allowed Dialog 1150 stage, providing a display, audible indication, or other indication that the track cannot be skipped, may be executed, with execution of the skip process then completed at stage 1160.
  • playback of the track may be skipped by transferring execution from stage 1130 to a next track stage 1170 wherein the next playable track may then be played/rendered (an implementation of the next track stage is further shown starting at stage 1210 as shown in FIG. 12).
  • FIG. 12 a flowchart 1200 representative of one embodiment of a Next Track process in accordance with aspects of the invention is provided.
  • the device triggers Next Track processing when it needs a new track to play.
  • This logic pre-generates the sequence "high water” tracks ahead whenever the sequence falls to "low water” tracks into the future. More specifically, Next Track processing may begin at stage 1210 wherein execution proceeds to a test stage 1220 wherein the pre-generated sequence is tested to see whether the sequence has fallen below a low water mark. If the sequence has not reached a low water mark the Next Track process is completed at stage 1240 where the next track in the sequence is returned for playback/rending.
  • new content may be added to the sequence at stage 1230 (an implementation of an add to sequence stage is further shown starting at stage 1310 as shown in FIG. 13) and then the sequence is again tested at stage 1235 to see if the track content has risen above a high water mark. If it has not, execution is returned to stage 1230 where another track is added to the sequence and the sequence is again tested at stage 1235. Once the sequence has risen above the high water mark execution is completed at stage 1240 with the next track in the sequence returned for playback/rendering.
  • Adding a track to a sequence is a core process in the playback processing logic.
  • this logic is driven by a clock object that orchestrates buckets to select the next track.
  • clocks are ordered, sequential, and cyclical lists of buckets.
  • a Dynamic Clock dynamically chooses the next bucket based on special purpose bucket sequencing logic
  • a Trivial Clock contains a single bucket from which the next track is always chosen.
  • FIG. 13 is a flowchart 1300 depicting one embodiment of an Add to Sequence process further depicting this process.
  • an Add to Sequence process may begin at a start stage 1310, with execution proceeding to stage 1320 where the bucket at the index of the clock for the current station is examined.
  • a track is selected from the bucket at stage 1330 (an implementation of a select track from bucket stage is further shown starting at stage 1410 as shown in FIG.
  • stage 1340 the index is incremented at stage 1340.
  • the index is tested at stage 1350 to determine if it is greater than the number of buckets. If it is, the index is then reset to 0 at stage 1355, with execution then proceeding to stage 1360. Alternately, if the index is less than the number of buckets execution proceeds to stage 1360 where the track score is tested. If the track score as tested at stage 1360 is greater than zero, the track is added to the sequence at stage 1364 and the add to sequence process is completed. Alternately, if the track score is less than or equal to zero the track score is tested against the best worst score at stage 1366. If the track score is greater than the best worst track score the tested track is then assigned to the best worst track.
  • step 1370 examination of the number of buckets tested is done. If all buckets have not been tested, execution is returned to stage 1320 where the process is repeated. Alternately, if all buckets have been tested and no track has been added to the sequence at stage 1364, the best worst track is added to the sequence at stage 1380 and execution of the Add to Sequence process is completed. Select Track from Bucket
  • Select Track from Bucket is a process by which the best track is selected from a bucket. Selection involves scanning the bucket for the best scoring track. There are obvious performance optimization schemes for scanning an entire bucket for the best scoring track; however the maximum size of a bucket is typically assumed to be small enough that these are likely to be of small benefit, and therefore a simplified process 1400 as shown in FIG. 14 is illustrated. As shown in FIG. 14, the Select Track from Bucket process begins at a start stage 1410, with execution proceeding to stage 1420 where the next track in the bucket is examined. A track playback score may then be calculated at stage 1430 (an implementation of a playback scoring stage is further shown starting at stage 1510 as shown in FIG.
  • this playback score may then be compared to a Best Track score at stage 1440. If the current track score is greater than the Best Track score, the current track is set to the Best Track at stage 1445, and execution is returned to stage 1450. Alternately, if the current track scores lower than the Best Track at stage 1440 execution may proceed to stage 1450 where a determination of remaining tracks in the bucket is made. If there are remaining tracks in the bucket execution returns to stage 1420 where the process may then be repeated. If there are no remaining tracks in the bucket, execution proceeds to stage 1460 where the identified Best Track is returned/selected. [0097] When there are significant differences in the quality of tracks available to be selected, that is, the available tracks have a wide range of scores, it is desirable to choose the best track.
  • the user may end the session or switch to a different channel at any time.
  • the scoring methodology not be so rigid that the sequence becomes deterministic or is perceived as such by the user. For this reason, a random 'noise' component may be added to the scores to reduce the likelihood of this perception. It is noted that the description of certain preferred embodiments defines certain conventions for scoring. These are designed to create semantic relationships between the scores by defining conventions relating to the meaning of the scores. It will, however, be apparent to those skilled in the art that other scoring conventions are possible assuming they preserve a consistent interchange between the different score types.
  • one example of a useful semantic relationship consistent with the invention involves the relationship between minimum and target rest to content fit.
  • a track when a track has already been played, it may be "rested” for a certain minimum number of plays (i.e., a "minimum rest” period) before becoming eligible to be played again.
  • a "target rest” period Upon expiration of a "target rest” period, the track is deemed to be sufficiently “rested” to be nearly as eligible for playback as a track that has never been played.
  • Content fit determines how well a track matches the ideal track and is typically a function of the sliders in SongBuckets or a combination of the slider scores and the rule scores in RuleBuckets.
  • a balance between content fit and sequencing rules like "rest” may be achieved by defining a convention (i.e., a semantic relationship) applicable to the meaning of the scores.
  • a content fit score of 1.0 may be used to define a perfect fit.
  • a sequence score of -1.0 or less means the track is not eligible for play, as does a combined score of 0.0. Relating this convention to rest, a track gets a large negative sequence score after having been just been played. This decays to -1.0 as the rest approaches target and further decays toward 0.0 as the rest exceeds the target.
  • FIG. 15 is a flowchart 1500 depicting one embodiment of a Playback Scoring process in accordance with the invention.
  • scoring the tracks in a bucket to determine Bucket Selection it may be desirable to look at the fit of the track to the bucket, the fit of the track to the current slider settings, and how well the track obeys the sequencing rules relative to the history of tracks that have already been played or are queued for playback.
  • a large negative score may be assigned to tracks that have been banned at either the performance or artist level.
  • a Playback Score process may begin at start stage
  • stage 1510 with execution proceeding to stage 1515 where score is assigned a calculated Bucket Fit Score.
  • the Bucket is next tested to determine if it has sliders for user customization at stage 1520. If it does, a slider score is calculated at stage 1530.
  • the track is tested for simple Boolean membership. If it does not have simple Boolean measurement, the track score is assigned the average of the fit and slider scores at stage 1540. If it does, the track is tested to determine if it is a bucket member. If it is a bucket member the score is assigned the value of the slider score at stage 1542. Alternately, if it is not a bucket member, the score is assigned a value of zero at stage 1544.
  • stage 1550 Following stages based on whether the bucket has a slider, execution resumes at stage 1550 where the track is tested for banning. If the track is banned it is assigned a very low score (for example, -10) at stage 1555. If it is not banned a sequence score is calculated at stage 1560, a noise score is calculated at stage 1565, and the score, sequence score, and noise score are returned/provided to other stages at stage 1570. Additional details and features related to FIG. 15 are further described below.
  • the Bucket Fit score determines how well the track fits the category of the Bucket. In a typical embodiment, for SongBuckets, all songs assigned to the bucket score a perfect value of 1.0. All songs not assigned to the Bucket score the minimum value of 0.0. This is also denoted herein as a 'Boolean' membership. For RuleBuckets, the fit score is the result of executing the AttributeRules against the song attributes. The fit score for RuleBuckets, by convention, is a score between 0.0 (worst fit, not in Bucket) to 1.0 (best possible fit).
  • Slider Rules allow the user to customize the station. When applied during sequencing, they bias track selection towards tracks with certain attributes. When applied during Inventory Management (as discussed in successive sections), they bias the addition of new tracks towards tracks with certain attributes. As the name implies, Slider
  • Rules may be conceptually or actually connected to sliders or knobs in the User Interface.
  • Serial No. 60/886,283 describes exemplary embodiments of such sliders.
  • Sliders are associated with a Station, although the effects of the slider may differ depending on the type of Bucket.
  • the following exemplary sliders bias track selection in a preferred embodiment: o Newer ⁇ - -> Older o Harder ⁇ - -> Softer o Popular ⁇ - -> Obscure o Favorite ⁇ - -> Non-Favorite
  • slider attributes are defined as either 'Raw' or
  • a 'Raw' slider attribute contains an actual value, typically associated with the attribute.
  • AlbumReleaseYear is a Raw slider attribute that contains a value based on release date between approximately 1950 and 2006.
  • Cooked slider attributes return a value between (by convention) -1.0 and 1.0.
  • a Popularity Cooked slider attribute is shown below in Table 3.
  • Raw slider attributes may be converted into cooked slider attributes by rescaling them using a Rescaling Rule that includes a Min, Max, and Median parameter.
  • a Rescaling Rule that includes a Min, Max, and Median parameter. This allows, for example, for an 80's radio station to define 'newer' as 1989 and 'older' as 1980, with 1985 as 'median' (the term median is used herein not in the strict mathematical sense, but to denote a value that should map to the center of the slider range - that is, a value that is neither 'old' or 'new' for the given station).
  • a simple linear interpolation (allowing the Median to not be centered between Max and Min) we have:
  • a better way of cooking sliders during rescaling may be to apply an exponential decay function such that the cooked scores decay towards 1.0 as the raw score increases from the Median towards the Max. Symmetrically, scores decay towards -1.0 as the raw score decreases from the mean toward the min.
  • V - 1.0 + ⁇
  • v represents the raw slider value and v' is the cooked slider value, ⁇ is the decay constant that controls the speed of decay.
  • ⁇ is the decay constant that controls the speed of decay.
  • Half- life is related to ⁇ as follows: ln(2)
  • FIGS. 16-18 are plots of age versus score profile for several embodiments of representative stations generated using the above equations.
  • slider attribute is 'Cooked', that is, converted to a standard range (-1.0...1.0 by convention), it can be converted into a slider score using the default slider scoring rule:
  • Score 1.0 - (SliderWeight / 2.0) + ((CookedAttributeValue * SliderWeight) /2.0)
  • Score MaxScore - (DynamicRange / 2.0) + ((NormScore * DynamicRange) /2.0)
  • MaxScore is the maximum possible score.
  • NormScore is a normalized score in the range of -1.0 to 1.0. Certain properties of this formula make it desirable for a slider application. These include:
  • the SliderWeight can be modulated along with the position of the slider to control the magnitude the attribute value contributes to the score.
  • a SliderWeight of 0.0 generates a uniform 1.0 score for all attribute values, which is ideal for a centered slider. • The negation of a slider weight inverts the scores in a symmetrical way. That is, the score order produced by a SliderWeight of 1.0 will be exactly reversed with a SliderWeight of -1.0. The score deltas in both lists will be symmetric.
  • sliders are in effect simultaneously, they may be combined to form a single score.
  • the average of all slider scores for which the SliderWeight is not 0.0 is taken (if all sliders are weighted 0.0, the slider score is set to 1.0).
  • a weighted average of the slider scores or other techniques to balance the contribution of unequal sliders may also be used. However, this approach should not be necessary if the attribute scores are well balanced across different types of sliders.
  • Sequence rules are used to score a candidate track for bucket selection against the current sequence.
  • sequence rules generate scores according to the following conventions:
  • the best possible Bucket/Slider fit is 1.0, so the sequence score must be greater than -1.0 to render an otherwise perfect track playable.
  • Artist Sequence Rules can be configured to typically generate a 0.0 or
  • the default Artist Sequence rule is parameterized by the number of times an Artist can appear in a sub-sequence, and the size of the sub-sequence to check. If the artist associated with the track being scored appears more than the given number of times in the interval, the rule returns -1.0. Otherwise the Artist Sequence Rule returns 0.0. Intervals may be specified in terms of time or number of tracks. Number of tracks is generally preferred for simplicity of implementation and better overall functionality (i.e. the device won't play an artist back-to-back regardless of how much time elapses between tracks). However, time based rules may be required to implement the sequencing rules specified by the Digital Millennium Copyright Act (DMCA) or by other statutory or regulatory content playback requirements.
  • DMCA Digital Millennium Copyright Act
  • Album Sequence rules are analogous to Artist Sequence Rules, except it is the Album associated with the track that is checked against the sequence. Album Sequence Rules are not typically used except in enforcement of DMCA rules or other statutory or regulatory requirements.
  • an exponential decay function may be used to decay the sequence score penalty towards zero.
  • Exponential decay is a function where the rate of decay of a quantity is proportional to the amount of the quantity remaining.
  • the noise floor is -.0625
  • the size of a half- life in number of tracks is can be determined as follows: ⁇ * MimmumRe st V " half -lives
  • Half- life is related to ⁇ as follows: ln(2)
  • N 0 can then be determined as the initial score that will decay to -1.0 at T MmmumRest
  • FIG. 19 shows a graph 1900 of sequence score as a function of track rest for one embodiment under the following conditions: Target Rest is 300, Minimum Rest is 150, Noise floor is .0125.
  • track sequence scores for each track can be calculated. If the track has not been played, the track sequence score is 0.0. If the track has been played, the number of tracks since the last play can be counted and used as 't' in the track sequence scoring formula:
  • a minimum sequence penalty for played tracks can optionally be introduced and used as a ceiling for sequence scores of played tracks.
  • TrackSequenceScore MIN(MinimumPenalty, N(t))
  • MinimumPenalty is preferably a function of Max ⁇ oise; for example it can be set to Max ⁇ oise / 2.0. This ensures that the penalty of a played track, no matter the rest, is not washed out by the noise used to randomize the system.
  • a particularly efficient way of computing rest for a track may be to keep a global variable that is incremented with each track played on the device. When a track is played, the value of the variable is recorded in the track header. Thus the rest is the difference between the current value and the value stored in the track.
  • the Fit, Slider, and Sequence scores are typically combined to generate a score that ranks the tracks in the Bucket for playback priority. Different combining rules may be applied. In an exemplary embodiment, for playback, different scoring may be used to rank the tracks for RuleBuckets and SongBuckets.
  • PlaybackScore ((FitScore + Slider Score) /2) + SequenceScore + Noise
  • Fit and Slider scores are combined to form a 0.0 - 1.0 score that reflects the relevancy of the content to the desired content programming for the Bucket. 1.0 is perfect fit, 0.0 is no fit.
  • Sequence scores are used to enforce repetition and other ordering rules.
  • a sequence score of -1.0 or lower is used to make a track ineligible for play.
  • Noise is added to the combined score. Noise is a random value between +/- MaxNoise/2.0. MaxNoise is a tunable system parameter, and represents the significance of score deltas. That is, a track that scores MaxNoise better than another track will always be selected ahead of the other track. However, tracks that score within MaxNoise of each other may be selected in either order (with a probability determined by the delta and the random distribution).
  • Inventory Management processing concerns the implementation of the Add Track, Save, and Ban processing states shown in the state diagrams.
  • Effective Inventory Management may be crucial to optimal operation, particularly with lower storage capacity devices. It may be less of an issue for higher capacity devices with large amounts of storage.
  • limitations on the amount of content that may be cached may make inventory management important for all device sizes.
  • FIG. 20 illustrates a chart 2000 of Inventory Pools for a representative embodiment.
  • device inventory can be categorized as follows:
  • Service Content is the storage pool for files added by the service through either the unidirectional or bidirectional links.
  • 'Favorites' is the storage pool for files from the service that have been 'saved' by the user.
  • User Content is the storage pool dedicated to storing files explicitly transferred to the device from the user's personal collection, such as user owned MP3 or other media files.
  • Unused is the unused storage available on the device.
  • Favorites and User Content are considered separate storage pools, because once the user saves a favorite or loads their own content the storage is deemed largely untouchable. That is, only the user can free this storage by explicitly removing items.
  • the Service Content pool is dedicated to providing the best possible enhanced radio experience and must optimize its use of storage autonomously. Basic concepts behind the managing of the service inventory are as follows:
  • the service storage pool will grow to the capacity of the device (for smaller capacity devices) or a fixed upper limit (for larger capacity devices).
  • FIG. 21 is a flowchart 2100 depicting an embodiment of an Add Tracks process in accordance with aspects of the invention.
  • an incoming track is 'offered' to each station on the device, which in turn offers the track to each of its buckets.
  • the station is programmed using only SongBuckets, it may be possible to route the track directly to the station/buckets to which the track is targeted as an optimization.
  • Stations that contain RuleBuckets must score the track against their rules to determine if the track fits or not.
  • the Bucket does not want the track a.
  • the Bucket already has this exact same track b.
  • the track does not meet the Bucket's criteria
  • the Bucket has added the track (growing in size to do so).
  • the Bucket has added the track by replacing one of its existing tracks: a.
  • the Bucket replaced an older version of the same track b.
  • the Bucket replaced a different track with this track
  • the media file may then be stored on the device. If no Bucket on any station adds the track, the media file is discarded.
  • the device monitors available storage space using a high and low water mark model. Once storage usage reaches the high water mark, an operation to cull inventory is undertaken to bring storage utilization back down to the low water mark.
  • HeavyRotation buckets typically contain the most popular and frequently played songs on standard stations. The bucket has a fixed maximum size that, combined with the significant station duty cycle, may yield a fairly high rate of individual song repetition.
  • old tracks must be removed from the bucket to make room for the newer tracks. Since the displaced track is still potentially very valuable to the station, the station can be programmed to allow tracks 'evicted' from one bucket to be automatically assigned to a new bucket. If no eviction bucket is specified, the evicted track is removed (providing no other stations hold references).
  • process 2100 may begin with an add track start stage
  • a station may next be selected for examination at stage 2120, with the next available bucket examined at stage 2125.
  • the bucket fit score of the track may be examined at stage 2130, and the score tested at stage 2135. If the score is less than zero, execution returns to the next bucket stage 2125. Alternately, if the score is greater than zero the track header may be added to the bucket at stage 2140, and tested to see if it replaces an earlier version of the header at stage 2142.
  • stage 2150 If there is an earlier version in the bucket, it will be removed at stage 2150 with execution proceeding to stage 2160. If not, the bucket may be tested for fullness at stage 2144 and, if full, execution proceeds to stage 2160. Finally, at stage 2146 if the bucket is not full and the bucket has an eviction bucket, the worst track header will be moved to the eviction bucket at stage 2152, with execution returned to stage 2160. If there is no eviction bucket execution proceeds from stage 2146 to stage 2154, where the worst track header is removed and execution proceeds to stage 2160.
  • stage 2160 determines if more buckets need to be tested. If so, execution proceeds to stage 2125. If no more buckets need to be tested for the current station, a test is made at stage 2170 to determine if additional stations need to be tested. If so, execution returns to stage 2120 to test the next station. Alternately, a test is made at stage 2172 to determine if any bucket wants the track and if not, the track is discarded at stage 2180. At stage 2173 a test is performed to determine if the service inventory has exceeded the capacity (or high water mark). If it has, the inventory may be culled at stage 2176 (an implementation of a cull inventory stage is further shown starting at stage 2210 as shown in FIG. 22). If capacity (i.e. high water) has not been exceeded, the track will be kept/added to inventory at stage 2182.
  • capacity i.e. high water
  • FIG. 22 is a flowchart 2200 depicting one embodiment of an Inventory Culling process in accordance with aspects of the invention.
  • an inventory culling process may be employed to remove the 'worst' tracks and bring the inventory levels down to a desired 'low water' mark. This process may be used to aid in ensuring that there is always free storage to handle the next 'Add Track' event.
  • Other reallocation of device storage may also be implemented through Inventory Culling. For example, to free up space for additional user content to be transferred onto the device, the service pool allocation may be adjusted by changing the high and low water marks. Inventory culling then removes the tracks to free up the required space.
  • a scan traverses all stations and buckets and scores each track based on an estimate of the eventual order of playback. If a track appears in more than one bucket, the largest of its scores may be assigned to the track. Note that since the score indicates the predicted next time the track will play, it is possible to manage inventory by removing all tracks with a score greater than a calculated threshold. The calculation should take into account the repetition of tracks in HeavyRotation buckets as well as tracks that appear in multiple buckets. This approach may be slightly more efficient (i.e. a heap is not required), but is less flexible in regard to the scoring algorithm.
  • Process 2200 is further described below, with additional details related to specific aspects further described following the overall process description.
  • the process may begin at an inventory cull start stage 2210, with execution proceeding to a calculate duty cycles stage 2215.
  • the current score for all files may initially be set at the lowest possible score at stage 2220, with each station successively examined, starting at stage 2225. For each station the buckets in the station are examined at stage 2230, with the headers in the examined bucket examined at stage 2235.
  • the inventory score for the header being examined is determined at stage 2240. If the determined score is greater than the file's current score, the current score is assigned to the file at stage 2248. If not (i.e.
  • stage 2250 if the current is less than or equal to the file current score the file current score is retained with execution proceeding to stage 2250.
  • Each header within the bucket are then examined based on a test at stage 2250, each bucket in the station are examined based on the test at stage 2255, and each station is examined based on a test at stage 2260.
  • a delete tracks stage 2270 an implementation of this stage is further shown starting at stage 2410 as shown in FIG. 24
  • the overall strategy for Inventory Management is to rank each track according to its likely order of playback on the device.
  • each track may be ranked in a bucket according to its probable play order within that bucket.
  • Duty cycle is then accounted for with respect to both the bucket within the station and the station within the player to achieve a score that ranks all tracks within the device.
  • the worst tracks can then be deleted until inventory levels are within a desired range.
  • the first step in this process is to calculate a forward-looking duty cycle for each station.
  • the available inventory for the device may be managed according to the predicted "duty cycle" for each station.
  • Duty cycle for a station represents the percentage of total device plays attributed to the station.
  • a goal is to calculate a forward-looking duty cycle for each station.
  • the forward-looking duty cycle must adapt to changing patterns of usage. For example, if a user starts listening to a new station, the forward looking duty cycle for that station should increase upwards even if the actual duty cycle of the station over the life of the device is quite low.
  • the duty cycle should be adapted based on a weighted average of recent and longer term observations; simply measuring the long term observed duty cycles of each station creates a system that fails to adapt quickly to new patterns, whereas a system based entirely on short-term observations neglects the information provided by the device's longer term history.
  • an adaptive strategy that varies the rate of adaptation based on the delta between short term and longer-term observations is employed.
  • the goal is for the duty-cycle of a new station to increase relatively rapidly based on short-term observations, at the same time taking into consideration an extended number of observations to completely overcome the longer-term usage patterns of the device.
  • a tunable constant may be required to allow the rate of adaptation to be controlled.
  • exponential decay is a function where the rate of decay of a quantity is proportional to the amount of the quantity remaining.
  • c t+l is the adapted duty cycle at time t+1
  • o t+1 is the observed duty cycle at time t+1
  • c t is the adapted duty cycle at time t.
  • FIG. 23 shows a graph 2300 illustrating the general shape of the duty cycle adaptation starting with 4 equally played stations.
  • the Rock station begins getting 100% of observed play events.
  • the Pop station begins getting 100% of observed play events.
  • the value of ⁇ chosen (here it is .05) controls the rate of adaptation.
  • the residual duty cycle may be allocated to the active stations in proportion to the predicted duty cycle of each station: ⁇ i ⁇ ⁇ baseline ' ⁇ ' ⁇ residual )
  • a cap T s J113x on the number of tracks in a station may also be established, beyond which the extra inventory for a station provides negligible benefit. After ensuring that the duty cycle accounts for baseline inventory for all stations, we can re-apportion the excess from stations that exceed the cap.
  • the duty cycle cap for any station is:
  • the duty cycle may be set to C 1113x for any station with a duty cycle greater than C 1113x .
  • M 0 --- M m -i representing the duty cycles below the cap we have:
  • each Bucket ranks its tracks in the likely order that the tracks will be played as part of the inventory management process.
  • algorithms used for ranking the tracks versus the bucket vary based on the bucket type.
  • HeavyRotation Buckets are buckets of fixed maximum size to achieve a desirable repetition rate. HeavyRotation buckets may be ranked for inventory management by fit/slider score first and secondarily by programming date. Because HeavyRotation buckets are small in comparison to their duty cycle, they tend to stay mostly in inventory. Library Buckets and Medium Rotation Buckets
  • the calculation of a sequence score may be based on estimating what the sequence score might be when the track is played.
  • the sequence penalty associated with a track in relationship to the fit score may be discounted.
  • the same sequence scoring algorithms that are used for playback may be used, but they can be calculated for a future time / track interval.
  • t' represents the number of tracks into the future to calculate the sequence penalty.
  • Nbucket is the number of tracks in the bucket.
  • t' For time -based rules (e.g., rules resulting from the requirements of the DMCA concerning the maximum number of times tracks for a given artist can be played in a given time period), t' can be multiplied by average track length. The inventory sequence score is then calculated at t':
  • InventorySequenceScore sequenceScore ⁇ t') The sequence score should have a maximum value of slightly less than zero for tracks that have been played, but are well rested, and a uniform value of 0.0 for tracks that have not been played.
  • the bucket rank may then be combined with bucket duty cycle and station duty cycle to obtain a score that represents an estimate of an overall track playback order for the device. If r represents the rank of the track in the bucket (l..n), let c statwn represent the predicted duty cycle of the station as described above, and let c bucket represent the duty cycle of the bucket with respect to the station, that is, the number of times the bucket appears in the clock divided by the number of slots in the clock, this results in:
  • FIG. 24 is a flowchart 2400 depicting one embodiment of a Track Deletion process in accordance with aspects of the invention.
  • the "worst" tracks are deleted from the device to free up storage space.
  • a process scanning all the files and their scores to accumulate a list of the at least N worst tracks, where:
  • N * averageTrackSize > currentlnventorySize - lowWatermarkSize may be done. Since tracks may be scored by estimated play order, by convention lower scores are better and higher scores are worse.
  • a Min-Heap is used to efficiently accumulate the worst tracks.
  • the process deletes each of the files in the Heap in worst to best order until the desired low water mark is achieved. Note that since the score indicates the predicted next time the track will play, inventory can conceivably be managed by removing all tracks with a score greater than a calculated threshold. The calculation must take into account the repetition of tracks in HeavyRotation buckets as well as tracks that appear in multiple buckets. This method may be slightly more efficient (i.e. a heap is not required), but is less flexible in regard to the scoring algorithm. In the described embodiment, this process may also be used to delete tracks that are no longer referenced by stations or playlists.
  • the track deletion process 2400 illustrated in FIG. 24 may first begin at a start stage 2410, with execution proceeding to a scan playlists stage 2415 (details of an embodiment of a scan playlists stage are further illustrated starting at stage 2510 as shown in FIG. 25).
  • a Min Heap sized at approximately the number of tracks to delete may be created at stage 2420. Examination of tracks begins at stage 2425. If the score is greater than the Heap Best Score, or the Heap is not full, the track may be added to the Heap at stage 2435, with execution proceeding to stage 2440.
  • stage 2440 a test is made of whether additional tracks need to be tested. If they do, execution returns to stage 2425 for examination and testing of additional tracks. If no tracks remain to be tested at stage 2440, execution proceeds to stage 2450 where the heap is reverse sorted. A loop is then performed where the next track is deleted at stage 2460, the heap end of space is tested against the low water mark, and if it is greater than or equal to the low water mark execution returns to stage 2460 where an additional track is deleted and the process repeated. Once the heap end of space is below the low water mark the process may be completed at stage 2480.
  • An embodiment 2500 of a Scan Playlist process is illustrated by the flowchart of FIG. 25.
  • the process of scanning files may begin with a scan playlists start stage 2510, with execution proceeding to a successive looped examination of playlists at stage 2520 and associated headers at stage 2530.
  • a Score is assigned initially to the file at stage 2540 equal to the favorites score. The Score is tested at stage 2544 to determine if it exceeds the File Current Score.
  • the Current Score is set to Score at stage 2548 and execution is transferred to stage 2550. If Score does not exceed the File Current Score at stage 2544, execution is transferred to stage 2550 without any further action. Once execution of the loops of stage 2550 and 2560 are finished the process may be completed at stage 2570.
  • FIG. 26 shows a flowchart 2600 illustrating a Saving Favorites process consistent with aspects of the invention.
  • the operation of saving favorites or adding tracks from the service into user- defined playlists essentially moves the track from one storage pool to another. Although these tracks are still part of the station inventory and still contribute to the station, this distinction is made because the tracks are protected so that they can no longer be removed from the system without the user explicitly doing so. Removal of a track from the service inventory pool can be thought of as essentially removing a re -usable slot. Constraints should be checked and enforced to ensure that the service cannot be substantially degraded by saving favorites.
  • a save track (saving favorites) process may begin with a start stage 2610. This may be initiated by, for example, a user input based on a desire to save the track. The track may then be tested at stage 2620 to determine whether it is saveable. If it is not, a can't save dialog may be executed at stage 2625, along with a display not allowed error or other indication provided at stage 2638. Assuming a track is saveable, it may then be tested at stage 2630 to determine if the user is allowed to save the track. If not, a similar series of not allowed and error displays may be executed at stages 2635 and 2638 respectively.
  • inventory constraints may be checked/determined at stage 2640 (details of inventory constraints checking are further described and illustrated below with respect to FIG. 27). Based on this information, device fullness may be tested at stage 2560. If the device is full, dialog stage 2654 and error stage 2658 may be executed. If, instead, the device is not full but close to capacity as determined by device almost full stage 2660, a device nearly full warning stage 2665 may be executed.
  • the track may be added to the station favorites playlist at stage 2670, the header may be marked as a favorite at stage 2672, the service pool size may be decremented accordingly at stage 2674, the favorites pool size may be incremented at stage 2676, and the save track process completed at stage 2680.
  • Checking inventory constraints is the process of determining if there is enough space left in the service to accommodate a reallocation of storage.
  • the minimum space required to operate the service may be defined in terms of a few tunable and derived parameters as set forth in FIG. 27.
  • the service inventory constraint is defined in terms of the constant A ⁇ cm : the minimum number of tracks needed to support the active stations. Since users divide their listening time between one or more stations, A ⁇ am could be described as the number of tracks needed to support a single station that gets 100% of the listening time.
  • the service pool needs to reserve a minimum number of tracks for each inactive station that renders the station listenable as it transitions from an inactive station to an active station. This constant is denoted as T smm .
  • T smm the minimum size of the services pool is:
  • a device full warning message may be issued when the device approaches this threshold:
  • the services pool is designed to grow to the device capacity or some preconf ⁇ gured maximum for large capacity devices.
  • the high and low water marks may be adjusted, and an inventory cull may be performed.
  • the number of tracks removed is approximately:
  • the operation can be allowed if:
  • FIG. 28 a flowchart 2800 of an embodiment of a
  • Ban Tracks process consistent with aspects of the invention is shown.
  • banning of tracks or artists is accomplished by marking the Headers of the tracks as being banned.
  • the banned track may be added to a Banned Track List and the banned artist may be added to a Banned Artist List.
  • a ban track process may begin at a start stage
  • a test stage 2810 with execution proceeding to a test stage 2820 where artist/track ban-ability is tested. If the artist or track is not ban-able, a not ban-able dialog stage 2825 may be executed, followed by completion of the process at stage 2840. Likewise, a test may be applied at stage 2830 to determine whether the user is allowed to ban the particular track. If not, a similar not allowed dialog stage 2835 may be executed, and the process completed at stage 2840. Alternately, if the track or artist is ban-able, a test of track or artist ban may be done at stage 2850 (to determine whether ban applies to the single track or all of the artist's tracks).
  • the track/artist may be added to a banned track/artist list at stages 2860 or 2870 respectively, and the banned attribute set in the track header or all headers with the artistID at stages 2865 or 2875 respectively.
  • a skip stage 2810 such as was described previously starting with stage 1110 of FIG. 11, may be executed.
  • banning based on other criteria can be implemented in a similar or analogous fashion. Tracks that are marked as banned may be given 'worst possible' rankings in their buckets when scoring tracks for inventory culling, and thus will be deleted on the next inventory cull cycle.
  • the banned lists may also be consulted for other functions, such as when an incoming track is received so that banned artists or tracks are not re-added to device memory.
  • both bidirectional and unidirectional connections can provide updated metadata and media files for tracks.
  • the connection may send metadata only (i.e. the Header) or may send an updated Header + Media File combination.
  • the simplest way of handling Metadata updates is to process the updated Header with an Add Track process, such as process 2100 as illustrated in FIG. 21. Processing metadata updates via the Add Track process requires that all Buckets offered the Header scan their inventory for a reference to a previous version of the Header (as defined by having equivalent Performance Ids) even if they don't want the track.
  • the Bucket If the Bucket doesn't want the new version of the track, but holds a reference to the old version, the Bucket must remove the old version (possibly triggering the removal of the associated media file if this was the last reference). If the Bucket still wants the track, the old header must be replaced with the new one (if the media file is not updated, the new header must be pointed at the old media file; if the media file is updated, the old media file and header must be removed at the end of the update operation).
  • the user when the device is connected via a bidirectional connection the user will have the opportunity to add niche or custom stations that are only reasonable to populate across this connection type.
  • the inventory When adding a new station, the inventory must be adjusted to accommodate the new station.
  • the device must have room for at least an additional T srmn tracks. If this is not the case, the user may be prompted to facilitate making room for additional stations by removing stations, favorites, or media files (i.e. mp3s, etc.).
  • a new station should receive a default initial duty cycle above and beyond the baseline, and predicted duty cycles should be re-calculated, (it is assumed that the user will listen to the newly added station). As tracks are added across the bidirectional connection and the high water mark is reached, inventory is freed according to the predicted duty cycles. See, for example, the process for culling inventory as is shown in process 2200 illustrated in FIG. 22.
  • the device when the device has a bidirectional connection to the broadcasting services/content management system, the device will attempt to obtain updates only for its active stations in priority order. Thus, the device can request targeted updates and utilize the connection only for tracks known to be of interest to the device. To obtain targeted updates, the device first re-calculates its predicted duty cycles as described above. The stations that have the largest negative delta between actual and predicted/allocated inventory are the first priority for update. The current inventory of the player relative to a station may be transmitted to the server along with the target inventory level for that station based on device capacity and predicted duty cycle. The server can then reply with an update to the station that may include the following information, as well as other information: 1. An updated Clock if the station definition has been changed on the server side.
  • the device processes the reply message by updating the station definition (if changed), and updating the Headers as indicated (see Updating Metadata above).
  • the device then begins receiving/downloading each of the specified tracks in the order specified.
  • Each track is 'added' to the player as if it where received on a unidirectional connection (this may be done to ensure that the player is consistent in the face of adds from both connection types, simplifies implementation, and handles the case where received tracks are targeted to multiple stations).
  • Some aspects of the present invention may be embodied in the form or computer software and/or computer hardware/software combinations configured to implement one or more processes or functions of the present invention as described and illustrated herein. These embodiments may be in the form of modules implementing functionality in software, firmware, and/or hardware/software/firmware combinations. Embodiments may also take the form of a computer storage product with a computer- readable medium having computer code thereon for performing various computer- implemented operations, such as operations related to functionality as describe herein, on one or more computer processors.
  • the media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts, or they may be a combination of both.
  • Examples of computer-readable media within the spirit and scope of the present invention include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute program code and/or data, such as application-specific integrated circuits ("ASICs"), programmable logic devices ("PLDs”) ROM and RAM devices, Flash devices, and the like.
  • Examples of computer code may include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter.
  • Computer code may be comprised of one or more modules executing a particular process or processes to provide useful results, and the modules may communicate with one another via means known in the art.
  • some embodiments of the invention may be implemented using Java, C#, C++, or other programming languages and software development tools as are known in the art.
  • Other embodiments of the invention may be implemented in hardwired circuitry in place of, or in combination with, machine-executable software instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention concerne des systèmes et des procédés pour fournir des dispositifs capables de réception et de lecture d'un ou de plusieurs canaux multimédias préparés transmis sur une connexion intermittente. Le(s) canal/canaux peut/peuvent être personnalisé(s) par l'utilisateur final pour influencer la programmation vers des goûts et des humeurs individuels. Les canaux peuvent être distribués sur un lien intermittent unidirectionnel, par exemple, un récepteur radio par satellite à domicile ou dans une voiture. Le contenu peut également être distribué sur un lien intermittent bidirectionnel, par exemple, vers un lecteur multimédia portatif via un réseau sans fil 802.11 ou toute autre connexion en réseau.
PCT/US2007/082373 2006-10-24 2007-10-24 Procédé et dispositif de lecture de contenu multimédia numérique WO2008052050A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA2667573A CA2667573C (fr) 2006-10-24 2007-10-24 Procede et dispositif de lecture de contenu multimedia numerique
EP07868561A EP2080114A4 (fr) 2006-10-24 2007-10-24 Procédé et dispositif de lecture de contenu multimédia numérique

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US86276306P 2006-10-24 2006-10-24
US60/862,763 2006-10-24
US88628307P 2007-01-23 2007-01-23
US60/886,283 2007-01-23

Publications (2)

Publication Number Publication Date
WO2008052050A2 true WO2008052050A2 (fr) 2008-05-02
WO2008052050A3 WO2008052050A3 (fr) 2008-12-31

Family

ID=40193599

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/082373 WO2008052050A2 (fr) 2006-10-24 2007-10-24 Procédé et dispositif de lecture de contenu multimédia numérique

Country Status (1)

Country Link
WO (1) WO2008052050A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9355174B2 (en) 2012-09-07 2016-05-31 Iheartmedia Management Services, Inc. Multi-input playlist selection

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2343053A (en) 1998-10-23 2000-04-26 Sony Uk Ltd Recording broadcast material
US20020199194A1 (en) 1999-12-21 2002-12-26 Kamal Ali Intelligent system and methods of recommending media content items based on user preferences
US20040220926A1 (en) 2000-01-03 2004-11-04 Interactual Technologies, Inc., A California Cpr[P Personalization services for entities from multiple sources

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001025948A1 (fr) * 1999-10-05 2001-04-12 Zapmedia, Inc. Systeme et procede de distribution de parcs de support a des dispositifs utilisateurs et de gestion des droits des utilisateurs des parcs de supports
US7777125B2 (en) * 2004-11-19 2010-08-17 Microsoft Corporation Constructing a table of music similarity vectors from a music similarity graph

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2343053A (en) 1998-10-23 2000-04-26 Sony Uk Ltd Recording broadcast material
US20020199194A1 (en) 1999-12-21 2002-12-26 Kamal Ali Intelligent system and methods of recommending media content items based on user preferences
US20040220926A1 (en) 2000-01-03 2004-11-04 Interactual Technologies, Inc., A California Cpr[P Personalization services for entities from multiple sources

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9355174B2 (en) 2012-09-07 2016-05-31 Iheartmedia Management Services, Inc. Multi-input playlist selection
US10318651B2 (en) 2012-09-07 2019-06-11 Iheartmedia Management Services, Inc. Multi-input playlist selection
US11526547B2 (en) 2012-09-07 2022-12-13 Iheartmedia Management Services, Inc. Multi-input playlist selection

Also Published As

Publication number Publication date
WO2008052050A3 (fr) 2008-12-31

Similar Documents

Publication Publication Date Title
US8849820B1 (en) Systems and devices for personalized rendering of digital media content
US20100106852A1 (en) Systems and methods for providing user personalized media content on a portable device
JP4944919B2 (ja) メディアファイルの自動選択
US20140143204A1 (en) Intelligent identification of multimedia content for grouping
US12034989B2 (en) Using machine learning and other models to determine a user preference to cancel a stream or download
US20200104278A1 (en) Methods and systems for personalized rendering of digital media content
RU2475995C2 (ru) Способ и система формирования рекомендации для хотя бы одного дополнительного элемента содержания
KR101224354B1 (ko) 다중 사용자 플레이리스트 생성 방법
US9143381B2 (en) Sequenced transmission of digital content items
US7853712B2 (en) Activity indicators in a media sharing system
JP5080520B2 (ja) 移動通信装置における音楽同期用システム及び方法
US7721314B2 (en) Scheduled retrieval, storage and access of media data
KR102077154B1 (ko) 사용자 선호도 기반 음악 추천 시스템 및 방법, 그리고 이에 적용되는 서버와 단말
JP5819649B2 (ja) 自動でコンテンツを推薦するモバイルシステム、コンテンツ推薦システム、およびコンテンツ推薦方法
US20090259621A1 (en) Providing expected desirability information prior to sending a recommendation
US10628385B2 (en) Virtual collection of entities in sync process
JP2004509402A (ja) ディジタル・ネットワークを介してメディア・コンテンツを提供し／受け取るための方法およびデバイス
JP2007082231A (ja) デジタルマルチメディア機器で保存されたマルチメディアコンテンツを管理する方法及び装置
JP2013526150A (ja) 再生品質が改善されたメディアコンテンツ
JP2006524857A (ja) 携帯用装置とネットワークとの間のコンテンツ交換
KR20080039578A (ko) 모바일 사용자를 위한 스마트 다이나믹 브라우징 방법
US10657168B2 (en) Methods and systems for personalized rendering of digital media content
US20100094880A1 (en) Media list management
WO2008052050A2 (fr) Procédé et dispositif de lecture de contenu multimédia numérique
JP2005531076A (ja) クライアント・サーバ・システムにおけるお気に入り管理

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07868561

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2667573

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007868561

Country of ref document: EP