U.S. patent application number 11/923573 was filed with the patent office on 2008-07-03 for methods and systems for personalized rendering of digital media content.
Invention is credited to Bradley D. Kindig, Celite Milbrandt.
Application Number | 20080162570 11/923573 |
Document ID | / |
Family ID | 39325381 |
Filed Date | 2008-07-03 |
United States Patent
Application |
20080162570 |
Kind Code |
A1 |
Kindig; Bradley D. ; et
al. |
July 3, 2008 |
METHODS AND SYSTEMS FOR PERSONALIZED RENDERING OF DIGITAL MEDIA
CONTENT
Abstract
Systems and methods are disclosed for providing devices capable
of the reception and playback of one or more crafted media channels
transmitted over an intermittent connection. The one or more
channels may be customized by the end user to bias the programming
towards individual tastes or moods. The channels may be delivered
over an intermittent, unidirectional link, for example a Satellite
Radio receiver in a home or car. Content may also be delivered over
an intermittent, bidirectional link, for example to a portable
media player via a wireless 802.11 or other networked
connection.
Inventors: |
Kindig; Bradley D.; (San
Diego, CA) ; Milbrandt; Celite; (Austin, TX) |
Correspondence
Address: |
COOLEY GODWARD KRONISH LLP;ATTN: Patent Group
Suite 1100, 777 - 6th Street, NW
WASHINGTON
DC
20001
US
|
Family ID: |
39325381 |
Appl. No.: |
11/923573 |
Filed: |
October 24, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60862736 |
Oct 24, 2006 |
|
|
|
60886283 |
Jan 23, 2007 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.107; 707/E17.009 |
Current CPC
Class: |
H04N 21/4826 20130101;
H04N 21/4825 20130101; H04H 60/85 20130101; G06F 16/40 20190101;
G06F 16/13 20190101; H04N 21/443 20130101; H04N 21/41422 20130101;
G06F 16/437 20190101; H04N 21/4828 20130101; H04H 20/106 20130101;
G06F 16/436 20190101; G06F 16/10 20190101; H04N 21/4622 20130101;
H04N 21/4334 20130101; H04N 21/4126 20130101 |
Class at
Publication: |
707/104.1 ;
707/E17.009 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method for facilitating personalized rendering of media files
through on a device configured to access a data link, the method
comprising: receiving, over the data link, a plurality of media
files and associated file metadata, wherein the file metadata
defines one or more attributes of the media files; and storing, in
a memory of the device, ones of the media files and associated file
metadata consistent with one or more channel profiles maintained
within the memory of the device.
2. The method of claim 1 further comprising discarding, based upon
the file metadata associated with said ones of the media files, one
or more media files that are non-responsive to the one or more
channel profiles; categorizing the media files stored in the memory
of the device into one or more categories; and sequencing the media
files for rendering responsive to the one or more categories.
3. The method of claim 2 wherein the media files selected
responsive to the category are selected responsive to a measure to
which the attributes of the media file match a set of attributes
related to the category.
4. The method of claim 3 wherein the media files selected
responsive to the category are additionally selected responsive to
the degree to which the attributes of the media files match one or
more attribute biases selectable by a user.
5. The method of claim 1 wherein sequencing for playback is
responsive to a set of user preferences, said preferences including
user identification of a user preference attribute of the media
file as a favorite.
6. The method of claim 1 wherein sequencing for playback is
responsive to a set of user preferences, said preferences including
user identification of a user preference attribute of the media
file as banned.
7. The method of claim 5 wherein said user preference attribute is
further associated with an artist.
8. The method of claim 1 wherein the amount of storage devoted to
local files associated with a channel is allocated responsive to
the characteristics of the channel.
9. The method of claim 8 wherein the amount of storage devoted to
the local files associated with a channel is allocated responsive
to the characteristics of the categories associated with the
channel.
10. A method for managing inventory of media files on a user
personalized media file rendering device, comprising the steps of:
receiving at the user device, over a communication link, a
plurality of media files and associated metadata; determining a
value metric of each of said plurality of media files, said
determining based at least in part on said metadata; selecting,
based on said determining a value metric, one or more media files
of said plurality of media files for storage; and storing, in a
memory of the device, said one or more selected media files.
11. A method for sequencing media files for rendering on a user
personalized media file rendering device, comprising the steps of:
storing, in a memory of said device, a plurality of media files and
associated metadata; retrieving, from said memory, said metadata
associated with ones of said plurality of media files; determining,
for each retrieved metadata, a rendering value metric; and
sequencing, based on said rendering value metric, one or more of
said media files for rendering.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of priority under 35
U.S.C. .sctn. 119(e) to co-pending U.S. Provisional Patent
Application Ser. No. 60/867,763, entitled "Method and Device for
Playback of Locally-Stored Digital Media Content," filed on Oct.
24, 2006, and to co-pending U.S. Provisional Patent Application
Ser. No. 60/886,283, entitled "Devices and Methods for Distributing
Digital Content," filed on Jan. 23, 2007. This application is also
related to U.S. patent application Ser. No. 11/637,300, entitled
"Method and Apparatus for Distribution of Digital Content," filed
on Dec. 12, 2006. The contents of each of these applications is
hereby incorporated by reference herein for all purposes.
FIELD OF THE INVENTION
[0002] 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.
BACKGROUND
[0003] Traditional AM, FM, television, and satellite radio
receivers are configured to receive real-time broadcasts: i.e., the
broadcast is rendered for playback contiguously with the reception
of the signal. With the introduction of recording capabilities such
as audio tape decks and VCRs, users were enabled to record
broadcast content and play it back at their leisure.
[0004] More recently, the introduction of recording devices such as
digital video recorders (DVRs) allows consumers to more
conveniently "time shift" programming. These devices allow
simultaneous recording and playback, thus enabling features such as
the simulation of pausing, rewinding, or fast-forwarding of live
television.
[0005] 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.
Unfortunately, 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."
[0006] Moreover, 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. In addition,
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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] For a better understanding of the nature and objects of
various embodiments of the invention, reference should be made to
the following detailed description taken in conjunction with the
accompanying drawings, wherein:
[0008] FIG. 1 illustrates an embodiment of a portable device and
associated system in a mobile application in accordance with
aspects of the present invention.
[0009] 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.
[0010] FIG. 3 illustrates an embodiment of a portable device and
associated system in a mobile application in accordance with
aspects of the present invention.
[0011] FIG. 4 illustrates an embodiment of an object configuration
in accordance with aspects of the present invention.
[0012] FIG. 5 is a state diagram showing an embodiment of a content
playback implementation in accordance with aspects of the present
invention.
[0013] FIG. 6 is a state diagram showing an embodiment of a user
interface implementation in accordance with aspects of the present
invention.
[0014] FIG. 7 is a state diagram showing an embodiment of a
wireless connection implementation in accordance with aspects of
the present invention.
[0015] FIG. 8 is a state diagram showing an embodiment of content
processing in a unidirectional connection in accordance with
aspects of the present invention.
[0016] FIG. 9 is a flowchart showing an embodiment of a start
station process in accordance with aspects of the present
invention.
[0017] FIG. 10 is a flowchart showing an embodiment of a stop
station process in accordance with aspects of the present
invention.
[0018] FIG. 11 is a flowchart showing an embodiment of a skip logic
process in accordance with aspects of the present invention.
[0019] FIG. 12 is a flowchart showing an embodiment of a next track
process in accordance with aspects of the present invention.
[0020] FIG. 13 is a flowchart showing an embodiment of an add to
sequence process in accordance with aspects of the present
invention.
[0021] FIG. 14 is a flowchart showing an embodiment of a select
track process in accordance with aspects of the present
invention.
[0022] FIG. 15 is a flowchart showing an embodiment of a playback
scoring process in accordance with aspects of the present
invention.
[0023] FIG. 16 is a graph of song aging results for an 80's station
based on an embodiment of the present invention.
[0024] FIG. 17 is a graph of song aging results for a Classic Rock
station based on an embodiment of the present invention.
[0025] FIG. 18 is a graph of song aging results for an Alternative
station based on an embodiment of the present invention.
[0026] FIG. 19 is a graph of track sequence scoring results as a
function of rest for an embodiment of the present invention.
[0027] FIG. 20 illustrates an allocation of inventory pools for
media content storage for an embodiment of the present
invention.
[0028] FIG. 21 is a flowchart showing an embodiment of an add track
process in accordance with aspects of the present invention.
[0029] FIG. 22 is a flowchart showing an embodiment of an inventory
cull process in accordance with aspects of the present
invention.
[0030] FIG. 23 is a graph of duty cycle adaptation for various
types of stations based on an embodiment of the present
invention.
[0031] FIG. 24 is a flowchart showing an embodiment of a delete
tracks process in accordance with aspects of the present
invention.
[0032] FIG. 25 is a flowchart showing an embodiment of a scan
playlists process in accordance with aspects of the present
invention.
[0033] FIG. 26 is a flowchart showing an embodiment of a save
tracks process in accordance with aspects of the present
invention.
[0034] FIG. 27 is a table illustrating inventory management symbols
and description based on an embodiment of the present
invention.
[0035] FIG. 28 is a flowchart showing an embodiment of a ban tracks
process in accordance with aspects of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
Introduction
[0036] Embodiments of a digital media content reception and
playback device that overcomes many of the shortcomings described
previously, as well as others, is disclosed herein. In one or more
embodiments, 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. Such a content management system and any associated
servers or other components is also described herein simply as the
"server" for purposes of brevity.
[0037] In one embodiment, 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. Thus, the
user is freed from the difficult task of acquiring content and
creating playlists.
[0038] In typical embodiments 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. Thus
the ability to render pristine content is preserved even when the
device is in areas with poor or no reception.
[0039] In one or more embodiments 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.
[0040] In some embodiments the device may be configured to dock in
an automobile or other vehicle. 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.
[0041] Additionally, 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. Those skilled
in the art will readily appreciate that the invention is not
constrained to any particular type of network connection or client
server configuration.
[0042] In some embodiments 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.
[0043] Additional aspects of the invention are also contemplated as
further described and illustrated herein.
Operational Overview
[0044] Operation with Unidirectional Connectivity
[0045] In typical unidirectional embodiments, 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. In accordance with one aspect of the invention,
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.
[0046] 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. In typical embodiments, the device is
configured to be capable of simultaneously playing back content
from the cache while receiving and processing new content into the
cache.
[0047] Operation with Bidirectional Connection
[0048] In typical bidirectional embodiments, 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).
[0049] In a preferred embodiment, 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.
[0050] Playback Operations
[0051] In typical embodiments, whether or not connected, 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.
[0052] 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. In addition, however, 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.
[0053] Playback Features
[0054] Because the 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:
[0055] Ability to skip content. If the user does not like the
current song, they may skip to the next song on the station. [0056]
Ability to replay content. The user may skip backwards to replay
songs. [0057] Ability to pause content. The user may pause the
currently playing track. [0058] Random access to content. The user
may seek forward or backward through the content. [0059] Ability to
ban content. If the user does not like a particular song, artist,
or other content characteristic (composer, commentator, etc.) they
may ban the content from the device. Content matching the banned
characteristics will no longer be played on the device. [0060]
Ability to save favorites. If the user hears a song they like, they
may save it as a favorite. Favorites can be stored in a special
folder or playlist for future access. [0061] Ability to bias
station playback towards certain content. The user may adjust
station knobs or "sliders" to bias the track selection towards
songs with certain attributes. Examples of station slider controls
include (but are not limited to): [0062] Newer .rarw. .fwdarw.Older
[0063] Harder .rarw. .fwdarw.Softer [0064] Popular .rarw.
.fwdarw.Obscure [0065] Favorite .rarw. .fwdarw.Non-Favorite [0066]
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. [0067] 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." [0068] Other unique features
and functions are also contemplated as further described
herein.
Physical Architecture
[0069] Attention is now directed to FIGS. 1-3, which depict the
physical architecture of embodiments of aspects of the invention in
a variety of contexts. Specifically, 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.
For example, as shown in FIG. 1, one embodiment of 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. As shown
in FIG. 1, 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.
[0070] 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.
[0071] 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.
[0072] Those skilled in the art will appreciate that it is possible
to realize a wide range of additional embodiments of systems in
accordance with the invention using a variety of hardware platforms
as well as hardware, software, and network configurations.
Software/Firmware Architecture
[0073] Aspects of the present invention are related to playback and
content management on the device. Before describing embodiments of
algorithms used for playback sequencing and inventory management, 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.
[0074] PlayerContext--The parent object that implements the overall
player behavior.
[0075] Station--As described herein, 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).
[0076] StationProfile--As described herein, a 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. In one embodiment 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.
[0077] 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.
[0078] Optionally, users may create their own custom station
profiles (typically using an application external to the device,
such as a web based application, but devices may also be configured
to allow users to create simple stations on the device through user
interfaces). These profiles would typically be loaded and
provisioned through the bidirectional connection. A StationProfile
includes the definition of the Clock and the Buckets that comprise
the Clock that will be used on the device.
[0079] The StationProfile 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. In one embodiment, the
StationProfile is an XML document. In an alternative embodiment,
the StationProfile 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.
[0080] Clock--As described herein, a Clock is utilized in
sequencing content. In one embodiment 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.` Content that is
introduced for variety might be categorized as `Library.`
[0081] The Clock is an ordered list of these categories (called
Buckets) used to create a song sequence. To create a 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. In practice,
the creator of a Station may define as many Buckets as desired and
sequence them as they see fit.
[0082] Bucket--As described herein, a Bucket is a category of
content used in Clock sequencing as described above. In typical
embodiments two types of buckets, SongBuckets and RuleBuckets are
utilized. SongBuckets are buckets for which songs are explicitly
categorized. That is, a BucketId attribute is associated with the
song (i.e., by a content programmer) that categorizes the song
explicitly into the Bucket with that matching identifier.
[0083] 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.`
[0084] A further specialization of the SongBucket is the
HeavyRotation bucket. A 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.`
[0085] 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.
TABLE-US-00001 TABLE 1 Exemplary Header Information SOF 0xAA55AA55
4 byte Number of Number of frames comprising the music file and 2
byte Frames including the header(s) Data bytes in last Number of
data bytes in the last frame 1 byte frame Opcode 0x0 - Data 1 byte
Version The version number of this header format 1 byte Format
Flags 0x01 = Display as Classical Track 1 byte 0x02 = Multipart
0x04 = Can Overlay Ads 0x08 = Can Overlay Information SongId The
Song Id used for song separation rules 4 byte unsigned integer
PerformanceId The Id of the performance used for content 4 byte
management unsigned integer LicensorId The Id of the content owner
(i.e. record label) 4 byte unsigned integer Song Name The length in
bytes of the song name that follows 2 byte short Length integer
Song Name UTF-8 encoded song name Song Name Length bytes ArtistId
The Id of the featured artist 4 byte unsigned integer Artist Name
The length in bytes of the artist name that follows 2 byte short
Length integer Artist Name UTF-8 encoded artist name Artist Name
Length bytes Composer Name The length in bytes of the composer name
that 2 byte short Length follows integer Composer Name UTF-8
encoded composer name Composer Name Length bytes AlbumId The Id of
the album associated with the track 4 byte unsigned integer Album
Name The length in bytes of the album name that follows 2 byte
short Length integer Album Name UTF-8 encoded album name Album Name
Length bytes Release Year The year of the original release of the
song 2 byte short integer Popularity Relative measure of song
popularity 2 byte short integer Style Length Number of Style, Style
Fit pairs to follow Byte Style Id of a style associated with this
song 2 byte short integer Style Fit Relative strength of style
association 2 byte short integer Additional Style, Style Fit pairs
Bucket Length Number of Bucket, Date pairs to follow Byte Bucket Id
of a radio programming bucket 2 byte short integer Date Date the
song was programmed into the bucket as 4 byte seconds since Jan. 1,
1970 unsigned integer Additional Bucket,Date pairs Energy -1 or 0-4
value representing energy level of the Byte track Multipart Length
Number of Offset, Type, Name triples to follow Byte Offset
Multipart offset 4 byte unsigned integer Offset Type 0 = Audio
Chapter 1 = Play Once Intro 2 = Play Always Intro 3 = Play Once
Outtro 4 = Play Always Outtro 5 = Album Art [if not in mp4
container] Part Name Length in bytes offset name to follow 2 byte
short Length integer Part Name UTF-8 encoded part name (for audio
chapters only) Additional parts Padding or Piggyback data to fill
frame CRC CRC checksum on the frame contents 4 bytes
[0086] Attribute--As described herein, an Attribute is a logical
name/value pair embodying a fact or piece of metadata about the
content. The Header stores Attributes. For efficiency of
transmission and storage, attributes may be stored in a fixed
layout in the Header or stored as Id, Value pairs or ClassId, Id,
Value triples. In the latter case, ClassId serves to specify the
identifier namespace for Id so that multiple, overlapping
identifier spaces can be used.
[0087] 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.
[0088] 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).
[0089] MediaFile--As described herein, a MediaFile is the content
actually rendered by the media player to affect playback of the
content.
[0090] 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.
[0091] 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.
[0092] FIG. 4 is a UML diagram showing an exemplary aggregation of
the core objects described above.
Processing States
[0093] 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. In
typical embodiments the device will have separate threads of
control running simultaneously under control of an operating system
that handles thread and/or process scheduling. Thus, in typical
embodiments the operations associated with the state diagrams will
be operating simultaneously in their own contexts.
[0094] In the description that follows 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. It is noted that, while the operations
associated with the figures include events and states shown in the
figures and described in the associated written description, it is
apparent that other events and states including fewer, more, or
different events and/or states than those shown in the figures are
within the spirit and scope of the present invention. Accordingly,
the state diagrams shown in the following figures are provided for
purposes of illustration, not limitation.
Player States
[0095] Attention is now directed to FIG. 5, which 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: [0096] Playing--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. [0097] Stopped--The device is not
rendering content. The previous Playing sub-state may be preserved
so that a return to the Playing state resumes where it left off.
[0098] Next Track--The device determines the next track to render.
A new file/track is selected for rendering and control returns to
the Playing state.
[0099] As shown in FIG. 5, 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. Upon receipt of a Play
instruction or other input operation 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.
User Interface Handling States
[0100] 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. After turn-on at state 610, 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.
TABLE-US-00002 TABLE 2 Event Processing State Event Handling New
State Stopped Play Send "Play" event to Player thread. Update
Playing display for Playing state. Playing Stop Send "Stop" event
to Player thread. Update Stopped display for Stopped state. Playing
Skip Skip handling. See Skip Playing Playing Ban Ban handling. See
Banning Tracks Playing Processing Playing Save Save handling. See
Saving Favorites Playing Processing * Station Slider Update the
corresponding slider settings for Unchanged Update the current
stations. See <insert reference> Playing Progress Update
track progress indicator Playing Playing NewTrack Update display
with current track info Playing * NewChannel Stop Player, change
channel, update Playing display, Start Player * * Update the
display with current UI view Unchanged, Changes UI Sub-states
Wireless (Bidirectional) Processing States
[0101] 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. Once initialized at state
710, device execution may proceed to a Not Connected Idle state
740. When the device is not connected to a wireless network, 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. If a connection is
established 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.
Antenna Processing States
[0102] 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. In
one embodiment such 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.
[0103] In a preferred embodiment, the AU is implemented as a
docking station that the device plugs into, for example, when the
device is in a car. As shown in FIG. 8, after initialization at
state 810, 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. In the
event of authentication failure, the device may return to Not
Connected Idle state 820 to repeat the process.
[0104] Once authenticated, thread execution may proceed to a
Connected Idle state 840. In this 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. Likewise, track or other
content availability may be signaled by a Track Available Trigger
to transfer execution to Add Track state 860. In this state tracks
or other content may be added, with execution then returned to
Connected Idle state 840. The 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
[0105] Playback processing concerns the implementation of various
processes that are related to the User Interface and Player State
Diagrams previously described. In the description that follows
embodiments of processes as illustrated in the associated figures
are described. These 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.
[0106] 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.
Start Station
[0107] Attention is now directed to FIG. 9, which 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.
[0108] As shown in FIG. 9, 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
[0109] Referring now to FIG. 10, a flowchart 1000 representative of
one embodiment of a Stop Station process in accordance with aspects
of the invention is shown. 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
[0110] Skip handling is typically triggered by a user interface
request to skip the current track. In typical embodiments, the
device will allow users to skip certain tracks. However, 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.
[0111] Referring now to FIG. 11, a flowchart 1100 representative of
one embodiment of a Skip process in accordance with aspects of the
invention is illustrated. As shown in FIG. 11, 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. If a track is not skippable, 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. Alternately, if a track is skippable, 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.
[0112] Alternately, if the track is both skippable and the user is
allowed to skip the track, 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).
Next Track
[0113] Turning now to 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.
Alternately, if the pre-generated sequence has reached a low water
mark, 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.
Add To Sequence
[0114] Adding a track to a sequence is a core process in the
playback processing logic. In a typical embodiment, this logic is
driven by a clock object that orchestrates buckets to select the
next track. As described previously and further detailed below,
clocks are ordered, sequential, and cyclical lists of buckets.
However, there are two special cases of clocks worth noting for
alternate embodiments: a Dynamic Clock dynamically chooses the next
bucket based on special purpose bucket sequencing logic, and a
Trivial Clock contains a single bucket from which the next track is
always chosen.
[0115] By scoring semantics convention, the Clock allows buckets to
provisionally decline to return a track. If the track returned by a
Bucket Selection process scores less than 0.0 (i.e., by convention
is an undesirable track), the bucket is skipped. However, if all
buckets return tracks that score less than 0.0, the highest scoring
track (denoted as the Best Worst Track) is returned.
[0116] FIG. 13 is a flowchart 1300 depicting one embodiment of an
Add to Sequence process further depicting this process. As shown in
FIG. 13, 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. 14), and 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. Otherwise, execution proceeds to step 1370 where
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
[0117] 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. 15) and 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.
[0118] 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.
In typical embodiments, it is generally considered a bad idea to
`ration` the best tracks by mixing in poorer tracks; however, such
an approach may be employed in some embodiments. In an exemplary
embodiment, front-loading the sequence with the best tracks is
considered preferable for at least the following reasons: [0119] 1.
Additional good tracks may be received before the next bucket
selection. [0120] 2. The user may end the session or switch to a
different channel at any time. [0121] 3. The scores of tracks
change as the session progresses and previously played `good`
tracks become sufficiently rested to be repeated.
[0122] It is also considered desirable that 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.
[0123] For instance, one example of a useful semantic relationship
consistent with the invention involves the relationship between
minimum and target rest to content fit. In particular, 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. 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.
[0124] Continuing with this example, 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. In general, 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.
Playback Scoring
[0125] Attention is now directed to FIG. 15, which is a flowchart
1500 depicting one embodiment of a Playback Scoring process in
accordance with the invention. When 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. In addition, a large negative score may be
assigned to tracks that have been banned at either the performance
or artist level. An overview of the process shown in FIG. 15 is
provided below, followed by additional details of aspects of
scoring.
[0126] As shown in FIG. 15, a Playback Score process may begin at
start 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.
At stage 1532 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.
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.
Bucket `Fit` Score
[0127] 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 Score
[0128] 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. Exemplary slider
implementations are further described in the related applications
incorporated herein by reference. In particular, U.S. Provisional
Patent Application Ser. No. 60/886,283 describes exemplary
embodiments of such sliders.
[0129] In typical embodiments 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: [0130] Newer .rarw.
.fwdarw.Older [0131] Harder .rarw. .fwdarw.Softer [0132] Popular
.rarw. .fwdarw.Obscure [0133] Favorite .rarw.
.fwdarw.Non-Favorite
Slider Attributes
[0134] By convention, slider attributes are defined as either `Raw`
or `Cooked.` A `Raw` slider attribute contains an actual value,
typically associated with the attribute. For example,
AlbumReleaseYear is a Raw slider attribute that contains a value
based on release date between approximately 1950 and 2006.
[0135] Cooked slider attributes return a value between (by
convention) -1.0 and 1.0. For example, a Popularity Cooked slider
attribute is shown below in Table 3.
TABLE-US-00003 TABLE 3 Embodiments of Slider Attributes Popularity
Cooked Slider Attribute Value Extremely popular, smash hit 1.0 Very
popular 0.75 Well known 0.50 Somewhat known, not quite obscure 0.0
Not well known, deep, obscure -1.0
[0136] 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. 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). For a simple linear
interpolation (allowing the Median to not be centered between Max
and Min) we have:
[0137] For raw sliders values v where v>Median:
v'=(v-Median)/(Max-Median)
[0138] For raw slider values v where v<Median
v'=(v-Median)/(Median-Min)
[0139] This puts the -1.0 score on Min, the 0.0 score on Median,
and the 1.0 score on Max, with a linear interpolation for values
between these points. However, a linear interpolation does not
account for outlying data points beyond Min and Max. Such points
will exceed the -1.0.1.0 convention or will cease to be
differentiated if capped. In some embodiments, a better way of
cooking sliders during resealing 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.
[0140] For values >=Median:
v'=1.0-e.sup.-.lamda.v
[0141] And for values <Median:
v'=-1.0+e.sup.-.lamda.'v
[0142] As shown here, v represents the raw slider value and v' is
the cooked slider value. .lamda. is the decay constant that
controls the speed of decay. We can determine a suitable value for
.lamda. by determining how close we want the score to be to
1.0/-1.0 for values of Max and Min. We can determine this in terms
of how many half-lives of decay should remain at the Max/Min. For
example, 3 half-lives is a decay of 0.5+0.25+0.125=0.875 leaving a
residual decay of 0.125 for scores that out lie the max.
t.sub.1/2=(Max-Median)/n.sub.half-lives
[0143] Half-life is related to .lamda. as follows:
t 1 / 2 = ln ( 2 ) .lamda. ##EQU00001##
[0144] Re-arranging for .lamda.:
.lamda. = ln ( 2 ) t 1 / 2 , ##EQU00002##
[0145] Substituting into the above we have:
.lamda. = ln ( 2 ) ( Max - Median ) / 3 ##EQU00003##
[0146] Similarly:
.lamda. ' = ln ( 2 ) ( Median - Min ) / 3 ##EQU00004##
[0147] FIGS. 16-18 are plots of age versus score profile for
several embodiments of representative stations generated using the
above equations. FIG. 16 shows a plot 1600 illustrating age scoring
for an "80's" station characterized by the following parameters:
Min=1980, Median=1985, Max=1989. Similarly, FIG. 17 shows a plot
1700 generated for a "Classic Rock" station characterized by the
parameters of Min=1960, Median=1977, Max=1995. Finally, FIG. 18
shows a plot 1800 for an "Alternative" station characterized by the
parameters of Min=1975, Median=2000, Max=2006.
Slider Scoring Rule
[0148] Once the 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)
A more generalized version of this formula is:
Score=MaxScore-(DynamicRange/2.0)+((NormScore*DynamicRange)/2.0)
Where MaxScore is the maximum possible score. DynamicRange is the
maximum delta from MaxScore, such that
MinScore=MaxScore-DynamicRange. Norm Score 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: [0149]
Generating scores in the 1.0-0.0 range that match desired
conventions. [0150] The SliderWeight can be modulated along with
the position of the slider to control the magnitude the attribute
value contributes to the score. [0151] A SliderWeight of 0.0
generates a uniform 1.0 score for all attribute values, which is
ideal for a centered slider. [0152] 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.
Combining Multiple Sliders
[0153] If multiple sliders are in effect simultaneously, they may
be combined to form a single score. In one embodiment, 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).
In some circumstances, 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
[0154] Sequence rules are used to score a candidate track for
bucket selection against the current sequence. In one embodiment,
sequence rules generate scores according to the following
conventions:
TABLE-US-00004 TABLE 4 An Embodiment of Sequence Rules Scoring
Score Semantic <-1.0 Disqualifies track for playback >=-1.0
and < 0.0 Technically eligible for playback, although suboptimal
to the degree of the negative score. 0.0 Track is fully eligible
for playback. Nothing in the sequence history discourages the track
from being played >0.0 Not typically used for Sequence Scores.
May indicate a HeavyRotation track that is overdue for
playback.
[0155] Recall that the Clock may be configured to skip a Bucket if
the best track scores <=0.0. By convention, 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
[0156] Artist Sequence Rules can be configured to typically
generate a 0.0 or -1.0 score. 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.
Album Sequence Rules
[0157] 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.
Track Sequence Rules
[0158] Track Sequence Rules are used to ensure that a track is not
repeated too frequently. The term "rest" is used herein to denote
the number of intervening tracks that are played between plays of a
given track. Each Bucket has the notion of minimum rest and target
rest. Minimum rest is the minimum number of tracks that must be
played between plays of a track. Target rest is the ideal number of
tracks that must be played between repetitions.
[0159] By convention, when a track has less than the minimum rest,
its Track Sequence Score is less than -1.0. When a track reaches
minimum rest, its Track Sequence Score is -1.0. As a track
approaches target rest, its score moves towards 0.0. In typical
embodiments it is desirable to heavily discourage the playing of
tracks with less than minimum rest. Between minimum rest and target
rest, there is a trade-off between optimal rest and best fitting
track. Beyond target rest, the influence of the sequence score
should wane, but there should still be a differentiation between
played and unplayed tracks.
[0160] In an exemplary embodiment, to model this intended behavior,
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. For a quantity N and decay constant .lamda.
we have:
N t = - .lamda. N ##EQU00005##
The solution to this differential equation is the generalized
function for exponential decay at time t where N.sub.0 is the
initial quantity.
N(t)=N.sub.0e.sup.-.lamda.t
[0161] It is desirable to choose N.sub.0 and decay constant .lamda.
such that N(T.sub.Minimum Rest)=-1.0 and N(T.sub.Target Rest)=noise
floor. The noise floor represents a score low enough that the
random noise added to the scores to induce variety will dominate
over the influence of additional rest. An exemplary approach begins
by calculating how many half-lives are required between
T.sub.Minimum Rest and T.sub.Target Rest:
n.sub.half-lives=-log.sub.2(|noise_floor|)
For example, if the noise floor is -0.0625, we need 4 half-lives to
decay the score from -1.0 to -0.0625. The size of a half-life in
number of tracks is can be determined as follows:
t.sub.1/2=(T.sub.Target Rest-T.sub.Minimum
Rest)/n.sub.half-lives
Half-life is related to .lamda. as follows:
t 1 / 2 = ln ( 2 ) .lamda. , ##EQU00006##
Re-arranging for .lamda.:
[0162] .lamda. = ln ( 2 ) t 1 / 2 ##EQU00007##
Substituting into the above we have:
.lamda. = ln ( 2 ) ( T TargetRest - T MinimumRest ) / - log 2 (
noise_floor ) ##EQU00008##
N.sub.0 can then be determined as the initial score that will decay
to -1.0 at T.sub.Minimum Rest
N.sub.0=1.02.sup.T.sup.Minimum Rest.sup.t.sup.1/2
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 0.0125.
[0163] Having determined the values of N.sub.0 and .lamda. based on
constants from the track sequence rules associated with the bucket,
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:
N(t)=N.sub.0e.sup.-.lamda.t
[0164] To ensure maintaining differentiation between played and
unplayed tracks, 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))
In a typical embodiment, MinimumPenalty is preferably a function of
MaxNoise; for example it can be set to MaxNoise/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.
Combined Scoring
[0165] 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.
For RuleBuckets:
[0166]
PlaybackScore=((FitScore+SliderScore)/2)+SequenceScore+Noise
[0167] For SongBuckets:
PlaybackScore=SliderScore+SequenceScore+Noise
That is, the FitScore and the SliderScore for Buckets are averaged
to calculate fit, then the SequenceScore and Noise are added.
[0168] By convention, SongBuckets have no FitScore; all songs
assigned to the Bucket are assumed equally fitting. That is, the
Bucket fit is a Boolean or filtering function. For these buckets,
the SliderScores are used to determine playback fit and add the
SequenceScore and Noise.
[0169] For an exemplary embodiment, the main conventions for
combined scores are as follows: [0170] 1. The combined score must
be greater than 0.0 for the track to be eligible for play. If all
tracks in the Bucket score <=0, the Bucket will be skipped.
[0171] 2. 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. [0172] 3. 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. [0173] 4. 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).
Detailed Inventory Management Processing
[0174] As described herein, Inventory Management processing
concerns the implementation of the Add Track, Save, and Ban
processing states shown in the state diagrams. In certain
embodiments, 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. However, limitations on the amount
of content that may be cached (for example, as dictated by record
label agreements) may make inventory management important for all
device sizes.
[0175] The goal of inventory management is to optimize the storage
utilization of the device for the stations in use. FIG. 20
illustrates a chart 2000 of Inventory Pools for a representative
embodiment. As shown in FIG. 20, device inventory can be
categorized as follows: [0176] Service Content is the storage pool
for files added by the service through either the unidirectional or
bidirectional links. [0177] `Favorites` is the storage pool for
files from the service that have been `saved` by the user. [0178]
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. [0179]
Unused is the unused storage available on the device.
Managing Service Content Inventory Concepts
[0180] In typical embodiments, 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, on the other
hand, 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: [0181] 1. 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). [0182] 2. Add Track
processing from the connections fills the pool towards its upper
limit (high water). [0183] 3. When enough tracks have been added to
reach Inventory "high water" the worst tracks can be removed until
inventory "low water" is reached.
Add Tracks Processing
[0184] Attention is now directed to FIG. 21, which is a flowchart
2100 depicting an embodiment of an Add Tracks process in accordance
with aspects of the invention. In summary, an incoming track is
`offered` to each station on the device, which in turn offers the
track to each of its buckets. If 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. In
a typical embodiment, there are 3 possible results of offering a
track to a Bucket:
[0185] 1. The Bucket does not want the track [0186] a. The Bucket
already has this exact same track [0187] b. The track does not meet
the Bucket's criteria
[0188] 2. The Bucket has added the track (growing in size to do
so).
[0189] 3. The Bucket has added the track by replacing one of its
existing tracks: [0190] a. The Bucket replaced an older version of
the same track [0191] b. The Bucket replaced a different track with
this track
[0192] If some Bucket on some station adds the incoming 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. In a typical
embodiment, 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.
Eviction
[0193] 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.
When new tracks are received into a full HeavyRotation bucket, 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).
[0194] In more detail, process 2100 may begin with an add track
start stage 2110 based on reception of a new track. Execution may
then proceed to a banned selection stage 2115 where an assessment
is made as to whether the particular track or artist has been
banned. If the track or artist has been banned, execution of the
process is terminated at stage 2118 with the track being discarded.
If the track or artist is not banned, 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.
[0195] 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.
[0196] At this point, a test is made at stage 2160 to determine 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.
Inventory Culling
[0197] Attention is now directed to FIG. 22, which is a flowchart
2200 depicting one embodiment of an Inventory Culling process in
accordance with aspects of the invention. In accordance with this
embodiment, once the service pool reaches high water, 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.
Other operational situations may also employ the inventory culling
process.
[0198] In summary, in process 2200 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.
[0199] 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. 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. Once all stations and their
respective buckets and headers have been tested, based on reaching
the end of the stations 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) may then be employed.
[0200] Additional details of aspects of inventory management are
further described below.
Scoring Tracks for Deletion
[0201] As noted above, in a typical embodiment, the overall
strategy for Inventory Management is to rank each track according
to its likely order of playback on the device. The tracks that are
more likely to be played sooner are kept and the tracks that are
likely to be played later are deleted. To score tracks, 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. In an exemplary embodiment, the first step
in this process is to calculate a forward-looking duty cycle for
each station.
Calculating Station Duty Cycles
[0202] 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. Put another
way, 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.
[0203] In an exemplary embodiment, 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. In addition, a tunable
constant may be required to allow the rate of adaptation to be
controlled.
[0204] One such approach is to use an exponential decay function on
the delta between the short-term and long-term observations. As
noted previously, exponential decay is a function where the rate of
decay of a quantity is proportional to the amount of the quantity
remaining. For a quantity N and decay constant .lamda. we have:
N t = - .lamda. N ##EQU00009##
[0205] Integrating produces the generalized function for
exponential decay at time t where No is the initial quantity.
N(t)=N.sub.0e.sup.-.lamda.t
Applying this technique to short and long term duty cycles we
have
c.sub.t+1=(o.sub.t+1-c.sub.t).lamda.+c.sub.t
Where c.sub.t+1 is the adapted duty cycle at time t+1, o.sub.t+1 is
the observed duty cycle at time t+1 and c.sub.t is the adapted duty
cycle at time t.
[0206] FIG. 23 shows a graph 2300 illustrating the general shape of
the duty cycle adaptation starting with 4 equally played stations.
At t0 (start time), the Rock station begins getting 100% of
observed play events. Halfway through the displayed time interval,
the Pop station begins getting 100% of observed play events. The
value of .lamda. chosen (here it is 0.05) controls the rate of
adaptation.
Duty Cycle Renormalization
[0207] While short-term observations may provide a good predictor
of future duty cycle, it may also be desirable to ensure that any
station supported by the device is playable with a minimum
allocation of inventory. To achieve this without disrupting the
overall strategy of using duty cycle as the guide to inventory
allocation, a minimum "baseline" duty cycle floor for all stations
in the device may be set. The baseline duty cycle ensures that
inactive stations get at least T.sub.s min tracks where T.sub.total
represents the total number of tracks in the service.
c.sub.baseline=T.sub.s min/T.sub.total
To calculate the "normalized" duty cycles for active stations
(those with predicted duty cycles >0), the calculation is
started by allocating a duty cycle of c.sub.baseline to all
stations (active and inactive). The residual duty cycle available
for allocation to the active stations is then:
c.sub.residual=1.0-(c.sub.baselinen.sub.stations)
Then, the residual duty cycle may be allocated to the active
stations in proportion to the predicted duty cycle of each
station:
C'.sub.i=c.sub.baseline+(c.sub.ic.sub.residual)
A cap T.sub.s max 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:
c.sub.max=T.sub.s max/T.sub.total
The duty cycle may be set to c.sub.max for any station with a duty
cycle greater than c.sub.max. For u.sub.0 . . . u.sub.m-1
representing the duty cycles below the cap we have:
u'.sub.1=u.sub.i+(c.sub.max/m)
That is, the inventory excess is distributed equally among the m
stations that are below the cap. The rationale is that additional
inventory will have a larger positive impact on smaller stations
(the reason for a cap), but these stations have less likelihood of
being played. It may be assumed that factors cancel, therefore opt
for an even reallocation. This technique can result in duty cycles
greater than c.sub.max; a station just below c.sub.max gets an
allocation of excess inventory that could push it over
c.sub.max.
Ranking of Tracks in Buckets
[0208] As described above, it may be preferable that each Bucket
ranks its tracks in the likely order that the tracks will be played
as part of the inventory management process. By convention,
algorithms used for ranking the tracks versus the bucket vary based
on the bucket type.
Heavy Rotation Buckets
[0209] 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
[0210] For larger buckets (>10 tracks, target rest >100), the
sequence score becomes more important in determining the value of
the track to the bucket. However, there is a tradeoff between
bucket fit and the sequence penalty associated with repetition.
[0211] Slider settings dynamically affect this relationship. A
distinction can be made between saved/locked slider settings and
those used to temporarily tweak playback order. In the former case,
the station is desirably optimized for the particular slider
settings by favoring inventory that matches the sliders. In the
latter case, the slider settings apply to playback only, and do not
affect the ranking of tracks within the bucket for inventory
purposes. In the latter case we assume the sliders may well be in a
different position in the future, so they are irrelevant for
ranking deep into the bucket.
[0212] For locked sliders, a combination of slider score and bucket
fit score (for RuleBuckets) may be used to determine the fit
component of the inventory score:
[0213] For RuleBuckets:
InventoryScore=((FitScore+SliderScore)/2)+InventorySequenceScore
For SongBuckets:
[0214] InventoryScore=SliderScore+InventorySequenceScore
[0215] The calculation of a sequence score may be based on
estimating what the sequence score might be when the track is
played. In an exemplary embodiment, 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. Here t' represents the number of tracks into the future
to calculate the sequence penalty. Nbucket is the number of tracks
in the bucket.
t ' = ( n bucket / 2. ) ( c bucket c station ) ##EQU00010##
[0216] 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.
[0217] As an example, the sequence score for a track that has
recently been played will be a large negative number as a
consequence of the minimum and target rest factors discussed above.
If in this example the value of t' is "40," minimum rest is "30"
and target rest is "50," the discounted sequence score will be
between -1.0 and 0.0 according to the applicable equations set
forth previously. The actual scores are -55.7 after being played
(rest=1), and -0.25 with the t' discount.
Calculating the Score
[0218] 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 (1 . . . n), let
c.sub.station represent the predicted duty cycle of the station as
described above, and let c.sub.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:
score=(r-0.5)/(c.sub.stationc.sub.bucket)
Deleting Tracks
[0219] Attention is now directed to FIG. 24, which is a flowchart
2400 depicting one embodiment of a Track Deletion process in
accordance with aspects of the invention. In general, after
execution of an inventory cull pass through the stations (such as
was previously described), the "worst" tracks are deleted from the
device to free up storage space. In order to implement this, a
process scanning all the files and their scores to accumulate a
list of the at least N worst tracks, where:
N*averageTrackSize>currentInventorySize-lowWatermarkSize
may be done. Since tracks may be scored by estimated play order, by
convention lower scores are better and higher scores are worse.
[0220] In an exemplary embodiment, 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. As described previously, by
convention a file will have a "worst possible" score from the
initialization phase if it is not referenced by any station.
[0221] More particularly, 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. Alternately, the track is not added and
execution likewise proceeds to stage 2440 where 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.
[0222] If the user interface of a particular embodiment supports
adding tracks from the service to user defined playlists, an
additional pass is required to score the tracks that are referenced
by playlists, but no longer referenced by stations. Each of these
tracks can be given a "best possible" score to ensure that they are
not removed.
[0223] 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. If it does, 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.
Saving Favorites Processing
[0224] Attention is now directed to FIG. 26, which shows a
flowchart 2600 illustrating a Saving Favorites process consistent
with aspects of the invention. In a typical embodiment, 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.
[0225] As shown in FIG. 26, 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. Assuming the track is not prohibited from saving,
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. Finally, if the device has
sufficient capacity for storage, 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
[0226] Checking inventory constraints is the process of determining
if there is enough space left in the service to accommodate a
reallocation of storage. In typical embodiments, 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. In general,
the service inventory constraint is defined in terms of the
constant A.sub.min: the minimum number of tracks needed to support
the active stations. Since users divide their listening time
between one or more stations, A.sub.min could be described as the
number of tracks needed to support a single station that gets 100%
of the listening time.
[0227] In addition to tracks for the active stations, 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.sub.s min. Thus the minimum size of the services pool is:
T.sub.min=A.sub.min+(T.sub.s min*inactive stations)
However, this is the minimum size of the services pool at low
water. Space should also be reserved to account for the difference
between low water and high water. Thus the device is full when
T.sub.total-T.sub.float>T.sub.min
A device full warning message may be issued when the device
approaches this threshold:
T.sub.total-T.sub.float.ltoreq.T.sub.min+T.sub.warm
As noted above, when saving favorites or saving service tracks into
user defined playlists, the service pool is decremented by one
track. Therefore, the above constraints for T.sub.total-1 should be
checked before allowing the operation.
Shrinking the Services Pool
[0228] In a typical embodiment, the services pool is designed to
grow to the device capacity or some preconfigured maximum for large
capacity devices. To free excess services storage for other
purposes, the high and low water marks may be adjusted, and an
inventory cull may be performed. To free N bytes of space:
W'.sub.low=W.sub.low-N
The number of tracks removed is approximately:
(W.sub.low-W'.sub.low)/t.sub.size
The operation can be allowed if:
T.sub.total-T.sub.float-((W.sub.low-W'.sub.low)/t.sub.size).gtoreq.T.sub-
.min
Banning Tracks Processing
[0229] Referring now to FIG. 28, a flowchart 2800 of an embodiment
of a Ban Tracks process consistent with aspects of the invention is
shown. In typical embodiments banning of tracks or artists is
accomplished by marking the Headers of the tracks as being banned.
In addition, the banned track may be added to a Banned Track List
and the banned artist may be added to a Banned Artist List.
[0230] As shown in FIG. 28, a ban track process may begin at a
start 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). As a consequence, 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. Finally, a skip
stage 2810, such as was described previously starting with stage
1110 of FIG. 11, may be executed.
[0231] In alternate embodiments, 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.
[0232] 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.
Updating Metadata
[0233] In typical embodiments, 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. While
in future implementations it may be desirable to optimize the
handling of Metadata updates, it is envisioned that 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. 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).
Adding New Stations
[0234] In typical embodiments, 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. 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.sub.smin 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.).
[0235] In a typical embodiment 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.
Detailed Connections Processing
Adding Tracks From Unidirectional Connections
[0236] In typical embodiments, as tracks are received from a
unidirectional connection (i.e. a broadcast type connection), they
are added to inventory using Add Tracks processing as is, for
example, described in process 2100 shown in FIG. 21.
Wireless (Bidirectional) Update
Station Refresh
[0237] In typical embodiments, 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: [0238] 1. An updated Clock if the station definition
has been changed on the server side. [0239] 2. Updated Headers for
tracks currently on the device if metadata for those Headers has
changed. [0240] 3. A list of additional tracks to download in
priority order.
[0241] In response, 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).
[0242] Rather than download all tracks to update a single station,
it may be preferable for the device to get updates for its other
active/high-priority stations and download the highest priority
tracks across all the station updates to ensure that all active
stations get some updates before the connection terminates. Should
the connection persist, all stations will have the opportunity to
process their updates.
[0243] 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.
[0244] 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. For
example, 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.
[0245] The foregoing description, for purposes of explanation, used
specific nomenclature to provide a thorough understanding of the
invention. However, it will be apparent to one skilled in the art
that specific details are not required in order to practice the
invention. Thus, the foregoing descriptions of specific embodiments
of the invention are presented for purposes of illustration and
description. They are not intended to be exhaustive or to limit the
invention to the precise forms disclosed; obviously, many
modifications and variations are possible in view of the above
teachings. The embodiments were chosen and described in order to
best explain the principles of the invention and its practical
applications, they thereby enable others skilled in the art to best
utilize the invention and various embodiments with various
modifications as are suited to the particular use contemplated. It
is intended that the following claims and their equivalents define
the scope of the invention.
* * * * *