Patent Grant
10657168
This application is a continuation of U.S. application Ser. No. 11/923,573, entitled METHODS AND SYSTEMS FOR PERSONALIZED RENDERING OF DIGITAL MEDIA CONTENT, filed on Oct. 24, 2007, which claims the benefit of priority under 35 U.S.C. § 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.
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.
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.
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.
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.”
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.
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:
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.
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.
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.
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.
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.
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.
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.
Additional aspects of the invention are also contemplated as further described and illustrated herein.
Operation with Unidirectional Connectivity
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.
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.
Operation with Bidirectional Connection
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).
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.
Playback Operations
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.
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.
Playback Features
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:
Attention is now directed to
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.
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
PlayerContext—The parent object that implements the overall player behavior.
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).
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.
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.
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.
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.
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.’
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.
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.
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.’
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.’
Header—As described herein, a Header is content metadata that is used to describe the attributes of the content/song. A Bucket manages its inventory by maintaining a list of Headers. Set forth below is a table containing the type of information included within an exemplary Header of a given media file.
Attribute—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.
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.
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).
MediaFile—As described herein, a MediaFile is the content actually rendered by the media player to affect playback of the content.
Sequence—As described herein, a Sequence is the list of content already played and in the queue to be played. The Sequence is examined to implement rules to limit repetition.
SequenceElement—As described herein, a Sequence Element is an element stored in a Sequence. Binds a Header with the timestamp when it was played for use with time-based SequenceRules.
State transition diagrams of embodiments of the device as shown in
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
Attention is now directed to
As shown in
User Interface Handling States
Wireless (Bidirectional) Processing States
State diagram 700 of
Antenna Processing States
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
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 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.
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
Attention is now directed to
As shown in
Stop Station
Referring now to
Skip
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.
Referring now to
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
Next Track
Turning now to
Add To Sequence
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.
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.
Select Track from Bucket
Select Track from Bucket is a process by which the best track is selected from a bucket. Selection involves scanning the bucket for the best scoring track. There are obvious performance optimization schemes for scanning an entire bucket for the best scoring track; however the maximum size of a bucket is typically assumed to be small enough that these are likely to be of small benefit, and therefore a simplified process 1400 as shown in
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:
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.
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.
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
Attention is now directed to
As shown in
Bucket ‘Fit’ Score
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
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.
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:
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.
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.
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:
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 rescaling may be to apply an exponential decay function such that the cooked scores decay towards 1.0 as the raw score increases from the Median towards the Max. Symmetrically, scores decay towards −1.0 as the raw score decreases from the mean toward the min.
As shown here, v represents the raw slider value and v′ is the cooked slider value. λ is the decay constant that controls the speed of decay. We can determine a suitable value for λ 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.
t1/2=(Max−Median)/nhalf-lives
Slider Scoring Rule
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−(Slider Weight/2.0)+((CookedAttributeValue*Slider Weight)/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. NormScore is a normalized score in the range of −1.0 to 1.0. Certain properties of this formula make it desirable for a slider application. These include:
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
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:
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
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
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
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.
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.
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 λ we have:
The solution to this differential equation is the generalized function for exponential decay at time t where N0 is the initial quantity.
N(t)=N0e−λt
It is desirable to choose N0 and decay constant λ such that N(TMinimum Re st)=−1.0 and N(TT arg et Re st)=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 TMinimum Re st and TT arg et Re st:
nhalf-lives=−log2(|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:
t1/2=(TT arg et Re st−TMinimum Re st)/nhalf-lives
Half-life is related to λ as follows:
Re-arranging for λ:
Substituting into the above we have:
N0 can then be determined as the initial score that will decay to −1.0 at TMinimum Re st
N0=−1.0·2T
Having determined the values of N0 and λ 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)=N0e−λt
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
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.
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.
For an exemplary embodiment, the main conventions for combined scores are as follows:
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.
The goal of inventory management is to optimize the storage utilization of the device for the stations in use.
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:
Attention is now directed to
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
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).
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.
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.
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
Inventory Culling
Attention is now directed to
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.
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
Additional details of aspects of inventory management are further described below.
Scoring Tracks for Deletion
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
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.
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.
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 λ we have:
Integrating produces the generalized function for exponential decay at time t where No is the initial quantity.
N(t)=N0e−λt
Applying this technique to short and long term duty cycles we have
ct+1=(ot+1−ct)λ+ct
Where ct+1 is the adapted duty cycle at time t+1, ot+1 is the observed duty cycle at time t+1 and ct is the adapted duty cycle at time t.
Duty Cycle Renormalization
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 Ts min tracks where Ttotal represents the total number of tracks in the service.
cbaseline=Ts min/Ttotal
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 cbaseline to all stations (active and inactive). The residual duty cycle available for allocation to the active stations is then:
cresidual=1.0−(cbaseline·nstations)
Then, the residual duty cycle may be allocated to the active stations in proportion to the predicted duty cycle of each station:
c′i=cbaseline+(ci·cresidual)
A cap Ts 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:
cmax=Ts max/Ttotal
The duty cycle may be set to cmax for any station with a duty cycle greater than cmax. For u0 . . . um−1 representing the duty cycles below the cap we have:
u′i=ui+(cmax/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 cmax; a station just below cmax gets an allocation of excess inventory that could push it over cmax.
Ranking of Tracks in Buckets
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
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
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.
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.
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:
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.
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.
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
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 cstation represent the predicted duty cycle of the station as described above, and let cbucket 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)/(cstation·cbucket)
Deleting Tracks
Attention is now directed to
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.
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.
More particularly, the track deletion process 2400 illustrated in
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.
An embodiment 2500 of a Scan Playlist process is illustrated by the flowchart of
Saving Favorites Processing
Attention is now directed to
As shown in
Checking Inventory Constraints
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
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 Ts min. Thus the minimum size of the services pool is:
Tmin=Amin+(Ts min*inactive stations)
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′low=Wlow−N
The number of tracks removed is approximately:
(Wlow−W′low)/tsize
The operation can be allowed if:
Ttotal−Tflout−((Wlow−W′low)/tsize)≥Tmin
Banning Tracks Processing
Referring now to
As shown in
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.
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
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
Adding New Stations
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 Ts min 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.).
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
Adding Tracks from Unidirectional Connections
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
Wireless (Bidirectional) Update
Station Refresh
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:
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).
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.
Some aspects of the present invention may be embodied in the form or computer software and/or computer hardware/software combinations configured to implement one or more processes or functions of the present invention as described and illustrated herein. These embodiments may be in the form of modules implementing functionality in software, firmware, and/or hardware/software/firmware combinations. Embodiments may also take the form of a computer storage product with a computer-readable medium having computer code thereon for performing various computer-implemented operations, such as operations related to functionality as describe herein, on one or more computer processors. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts, or they may be a combination of both.
Examples of computer-readable media within the spirit and scope of the present invention include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute program code and/or data, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) ROM and RAM devices, Flash devices, and the like. Examples of computer code may include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. Computer code may be comprised of one or more modules executing a particular process or processes to provide useful results, and the modules may communicate with one another via means known in the art. 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.
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.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4881078 | Toshinobu et al. | Nov 1989 | A |
| 4914448 | Ostsuka et al. | Apr 1990 | A |
| 5038211 | Hallenbeck | Aug 1991 | A |
| 5117407 | Vogel | May 1992 | A |
| 5311175 | Waldman | May 1994 | A |
| 5323267 | Galarneau et al. | Jun 1994 | A |
| 5666113 | Logan | Sep 1997 | A |
| 5923267 | Beuk et al. | Jul 1999 | A |
| 5977964 | Williams et al. | Nov 1999 | A |
| 6004135 | Trattner et al. | Dec 1999 | A |
| 6023242 | Dixon | Feb 2000 | A |
| 6049306 | Amarillas | Apr 2000 | A |
| 6317784 | Mackintosh et al. | Nov 2001 | B1 |
| 6349339 | Williams | Feb 2002 | B1 |
| 6351596 | Ostrover | Feb 2002 | B1 |
| 6388345 | Stimpson | May 2002 | B1 |
| 6389321 | Tang et al. | May 2002 | B2 |
| 6437774 | Tsuji et al. | Aug 2002 | B1 |
| 6553222 | Weiss | Apr 2003 | B1 |
| 6563805 | Ma et al. | May 2003 | B1 |
| 6564003 | Marko et al. | May 2003 | B2 |
| 6587127 | Leeke et al. | Jul 2003 | B1 |
| 6658062 | Nakatsuyama et al. | Dec 2003 | B1 |
| 6680677 | Tiphane | Jan 2004 | B1 |
| 6778841 | Buries et al. | Aug 2004 | B1 |
| 6785656 | Patsiokas et al. | Aug 2004 | B2 |
| 6795702 | Sennett | Sep 2004 | B2 |
| 6822635 | Shahoian et al. | Nov 2004 | B2 |
| 6834156 | Marko et al. | Dec 2004 | B1 |
| 6876835 | Marko et al. | Apr 2005 | B1 |
| 6904055 | Pichna et al. | Jun 2005 | B2 |
| 6933433 | Porteus et al. | Aug 2005 | B1 |
| 6934917 | Lin | Aug 2005 | B2 |
| 6972363 | Georges et al. | Dec 2005 | B2 |
| 6985694 | De Bonet et al. | Jan 2006 | B1 |
| 7010263 | Patsiokas et al. | Mar 2006 | B1 |
| 7028082 | Rosenberg et al. | Apr 2006 | B1 |
| 7035932 | Dowling | Apr 2006 | B1 |
| 7057521 | Beuk et al. | Jun 2006 | B1 |
| 7106221 | Horton et al. | Nov 2006 | B2 |
| 7232973 | Kaps et al. | Jan 2007 | B2 |
| 7187947 | White et al. | Mar 2007 | B1 |
| 7216008 | Sakata | May 2007 | B2 |
| 7251452 | Stumphauzer, II | Jul 2007 | B2 |
| 7293066 | Day | Nov 2007 | B1 |
| 7352331 | Quagliaro | Apr 2008 | B2 |
| 7403910 | Hastings et al. | Jul 2008 | B1 |
| 7526728 | Apparao et al. | Apr 2009 | B2 |
| 7555539 | Rosenberg et al. | Jun 2009 | B1 |
| 7483964 | Jackson et al. | Oct 2009 | B1 |
| 7624337 | Sull et al. | Nov 2009 | B2 |
| 7680959 | Svendsen | Mar 2010 | B2 |
| 7756388 | Plastina et al. | Jul 2010 | B2 |
| 7840563 | Powers et al. | Nov 2010 | B2 |
| 7877290 | Arsenault et al. | Jan 2011 | B1 |
| 7884274 | Wieder | Feb 2011 | B1 |
| 7890874 | Kaufman | Feb 2011 | B2 |
| 7953032 | Liang | May 2011 | B2 |
| 8050652 | Qureshey et al. | Nov 2011 | B2 |
| 8204073 | Gailloux et al. | Jun 2012 | B1 |
| 8332512 | Wu et al. | Dec 2012 | B1 |
| 8370351 | Kalasapur et al. | Feb 2013 | B2 |
| 8443007 | Kindig et al. | May 2013 | B1 |
| 8712563 | Milbrandt et al. | Apr 2014 | B2 |
| 8737910 | Zigler et al. | May 2014 | B2 |
| 8838564 | Sahni et al. | Sep 2014 | B2 |
| 8849820 | Kindig et al. | Sep 2014 | B1 |
| 8881209 | Kalmes et al. | Nov 2014 | B2 |
| 20010005900 | Yoshida et al. | Jun 2001 | A1 |
| 20010053944 | Marks et al. | Dec 2001 | A1 |
| 20020016643 | Sakata | Feb 2002 | A1 |
| 20020041692 | Seto et al. | Apr 2002 | A1 |
| 20020072341 | Ricard et al. | Jun 2002 | A1 |
| 20020073225 | Dillon et al. | Jun 2002 | A1 |
| 20020082901 | Dunning et al. | Jun 2002 | A1 |
| 20020092019 | Marcus | Jul 2002 | A1 |
| 20020158838 | Smith et al. | Oct 2002 | A1 |
| 20020164973 | Janik et al. | Nov 2002 | A1 |
| 20020184111 | Swanson | Dec 2002 | A1 |
| 20020199194 | Ali | Dec 2002 | A1 |
| 20030006690 | Roh | Jan 2003 | A1 |
| 20030006892 | Church | Jan 2003 | A1 |
| 20030014496 | Spencer et al. | Jan 2003 | A1 |
| 20030027523 | Lim | Feb 2003 | A1 |
| 20030050997 | Hickey et al. | Mar 2003 | A1 |
| 20030052913 | Barile | Mar 2003 | A1 |
| 20030061611 | Pendakur | Mar 2003 | A1 |
| 20030066090 | Traw | Apr 2003 | A1 |
| 20030073411 | Meade | Apr 2003 | A1 |
| 20030089218 | Gang et al. | May 2003 | A1 |
| 20030110503 | Perkes | Jun 2003 | A1 |
| 20030122779 | Martin et al. | Jul 2003 | A1 |
| 20030182255 | Plastina et al. | Sep 2003 | A1 |
| 20040001690 | Boston et al. | Jan 2004 | A1 |
| 20040017316 | Tanaka et al. | Jan 2004 | A1 |
| 20040044677 | Huper-Graff et al. | Mar 2004 | A1 |
| 20040064476 | Rounds | Apr 2004 | A1 |
| 20040158860 | Crow | Aug 2004 | A1 |
| 20040218067 | Chen et al. | Nov 2004 | A1 |
| 20040220926 | Lamkin et al. | Nov 2004 | A1 |
| 20040267503 | Batterberry et al. | Dec 2004 | A1 |
| 20050108754 | Carhart et al. | May 2005 | A1 |
| 20050114794 | Grimes et al. | May 2005 | A1 |
| 20050120305 | Engstrom et al. | Jun 2005 | A1 |
| 20050172318 | Dudkiewicz et al. | Aug 2005 | A1 |
| 20050179668 | Edwards | Aug 2005 | A1 |
| 20050198690 | Esolen et al. | Sep 2005 | A1 |
| 20050240661 | Heller et al. | Oct 2005 | A1 |
| 20060005148 | Cheng et al. | Jan 2006 | A1 |
| 20060009199 | Mittal | Jan 2006 | A1 |
| 20060123053 | Scannell, Jr. | Jan 2006 | A1 |
| 20060022960 | Fukushima | Feb 2006 | A1 |
| 20060026663 | Kortum et al. | Feb 2006 | A1 |
| 20060031892 | Cohen | Feb 2006 | A1 |
| 20060075007 | Anderson et al. | Apr 2006 | A1 |
| 20060085349 | Hug | Apr 2006 | A1 |
| 20060112082 | Platt et al. | May 2006 | A1 |
| 20060126750 | Friedman | Jun 2006 | A1 |
| 20060143094 | Kohout et al. | Jun 2006 | A1 |
| 20060149813 | Janik | Jul 2006 | A1 |
| 20060156236 | Heller et al. | Jul 2006 | A1 |
| 20060174313 | Ducheneaut et al. | Aug 2006 | A1 |
| 20060194535 | Houldsworth et al. | Aug 2006 | A1 |
| 20060195516 | Beaupre | Aug 2006 | A1 |
| 20060195790 | Beaupre et al. | Aug 2006 | A1 |
| 20060200599 | Manchester et al. | Sep 2006 | A1 |
| 20060206478 | Glaser et al. | Sep 2006 | A1 |
| 20060206493 | Lipscomb et al. | Sep 2006 | A1 |
| 20060212442 | Conrad et al. | Sep 2006 | A1 |
| 20060212444 | Handman et al. | Sep 2006 | A1 |
| 20060218187 | Plastina et al. | Sep 2006 | A1 |
| 20060227905 | Kunysz et al. | Oct 2006 | A1 |
| 20060235864 | Hotelling et al. | Oct 2006 | A1 |
| 20060238517 | King et al. | Oct 2006 | A1 |
| 20060239131 | Nathan et al. | Oct 2006 | A1 |
| 20060242106 | Bank | Oct 2006 | A1 |
| 20060253782 | Stark et al. | Nov 2006 | A1 |
| 20060265329 | Hug | Nov 2006 | A1 |
| 20060265421 | Ranasinghe et al. | Nov 2006 | A1 |
| 20070013593 | Zafar et al. | Jan 2007 | A1 |
| 20070041350 | Famolari | Feb 2007 | A1 |
| 20070073728 | Klein et al. | Mar 2007 | A1 |
| 20070078899 | Gulin et al. | Apr 2007 | A1 |
| 20070079352 | Klein, Jr. | Apr 2007 | A1 |
| 20070089057 | Kindig | Apr 2007 | A1 |
| 20070136753 | Bovenschulte et al. | Jun 2007 | A1 |
| 20070152975 | Ogihara et al. | Jul 2007 | A1 |
| 20070152977 | Ng et al. | Jul 2007 | A1 |
| 20070156589 | Zimler et al. | Jul 2007 | A1 |
| 20070174147 | Klein, Jr. | Jul 2007 | A1 |
| 20070208610 | Pisaris-Henderson et al. | Sep 2007 | A1 |
| 20070220552 | Juster et al. | Sep 2007 | A1 |
| 20070236472 | Bentsen et al. | Oct 2007 | A1 |
| 20070239856 | Abadir | Oct 2007 | A1 |
| 20070281704 | Lin et al. | Dec 2007 | A1 |
| 20070300158 | Kasperkiewicz et al. | Dec 2007 | A1 |
| 20080009268 | Ramer et al. | Jan 2008 | A1 |
| 20080024958 | Mudd et al. | Jan 2008 | A1 |
| 20080052630 | Rosenbaum et al. | Feb 2008 | A1 |
| 20080086379 | Dion et al. | Apr 2008 | A1 |
| 20080097967 | Milbrandt et al. | Apr 2008 | A1 |
| 20080120648 | Carlson et al. | May 2008 | A1 |
| 20080162570 | Kindig et al. | Jul 2008 | A1 |
| 20080215645 | Kindig et al. | Sep 2008 | A1 |
| 20080222546 | Mudd et al. | Sep 2008 | A1 |
| 20080222576 | Hashimoto | Sep 2008 | A1 |
| 20080242277 | Chen et al. | Oct 2008 | A1 |
| 20080258986 | Milbrandt et al. | Oct 2008 | A1 |
| 20080261512 | Milbrandt et al. | Oct 2008 | A1 |
| 20080263098 | Kindig et al. | Oct 2008 | A1 |
| 20080305736 | Milbrandt et al. | Dec 2008 | A1 |
| 20090017866 | White et al. | Jan 2009 | A1 |
| 20090019374 | Logan et al. | Jan 2009 | A1 |
| 20090031007 | Boic et al. | Jan 2009 | A1 |
| 20090147975 | Horbach et al. | Jun 2009 | A1 |
| 20090164419 | Taylor et al. | Jun 2009 | A1 |
| 20100010648 | Bull et al. | Jan 2010 | A1 |
| 20100106852 | Kindig et al. | Apr 2010 | A1 |
| 20100121857 | Elmore et al. | May 2010 | A1 |
| 20100125507 | Tarantino et al. | May 2010 | A1 |
| 20110107381 | Solnik et al. | May 2011 | A1 |
| 20130014136 | Bhatia | Jan 2013 | A1 |
| 20130086078 | Malleshaiah | Apr 2013 | A1 |
| 20130218942 | Willis et al. | Aug 2013 | A1 |
| 20130262966 | Wu et al. | Oct 2013 | A1 |
| 20130318080 | Aravamudan et al. | Nov 2013 | A1 |
| 20140006556 | Shapiro | Jan 2014 | A1 |
| 20140177717 | Li et al. | Jun 2014 | A1 |
| 20140258025 | Bouzid et al. | Sep 2014 | A1 |
| 20140258313 | McCallum | Sep 2014 | A1 |
| 20140280213 | Isquith et al. | Sep 2014 | A1 |
| 20150006544 | Isquith et al. | Jan 2015 | A1 |
| 20170126770 | Kindig | May 2017 | A1 |
| 20170195728 | Mudd et al. | Jul 2017 | A1 |
| Number | Date | Country |
|---|---|---|
| 0406845 | Jan 1994 | EP |
| 1610145 | Dec 2005 | EP |
| 2343053 | Apr 2000 | GB |
| 10-2011-0073484 | Jun 2011 | KR |
| WO 1999012230 | Mar 1999 | WO |
| WO 2001035667 | May 2001 | WO |
| WO 2004097803 | Nov 2004 | WO |
| WO 2005034407 | Apr 2005 | WO |
| WO 2005076117 | Aug 2005 | WO |
| WO 2006042309 | Apr 2006 | WO |
| WO 2006124277 | Nov 2006 | WO |
| WO 2008060032 | May 2008 | WO |
| Entry |
|---|
| Office Action for U.S. Appl. No. 12/582,675, dated Jul. 13, 2018, 16 pages. |
| Office Action for Canadian Application No. 2,680,281 dated Feb. 8, 2018, 2 pages. |
| Office Action for U.S. Appl. No. 14/550,804, dated Jan. 25, 2018, 30 pages. |
| Carlvik, O. et al., “IP-Based Personalized Media on Demand,” ISS '97, World Telecommunications Congress, (International Switching Symposium); Global Network Evolution: Convergence or Collision? Toronto, Sep. 21-26, 1997, pp. 365-370. |
| Hacker, S., “MP3: The Devinitive Guide,” Mar. 1, 2000, O'Reilly Media, Inc., p. 112, ISBN: 978-1-565-92661-5. |
| Motorola, “Complexity analysis of the Motorola Turbo Code Interleaver,” TSG-RAN Working Group 1 Meeting #3, Eskilstuna, Sweden, Mar. 22-26, 1999, pp. 1-5. |
| Tell, E. et al., “A hardware architecture for a multi mode block interleaver,” Proc. ICCSC [Online], Jul. 2004, Moscow Russia, Retrieved from the Internet: <URL: http://www.da.isy.liu.se/pubs/erite/>, [Retrieved on Aug. 14, 2008], pp. 1-4. |
| Wikipedia, “Pandora Radio,” Oct. 7, 2006, [Online], Retrieved from the Internet on: Oct. 12, 2010, <URL: http://en.wikipedia.org/w/index.php?title=Pandora_Radio&oldid=80072157>, 3 pages. |
| Pandora, “Frequently Asked Questions”, Aug. 30, 2006, Pandora Media Inc., Retrieved from the Internet: <URL: web.archive.org/web/20060830160154/http://blog.pandora.com/faq/>, pp. 1-14. |
| U.S. Appl. No. 11/774,481, Office Action dated Apr. 29, 2010. |
| PCT/US2007/072954, International Search Report dated Feb. 1, 2008. |
| PCT/US2007/072954, Written Opinion dated Feb. 1, 2008. |
| PCT/US2007/072954, International Preliminary Report on Patentability dated Jan. 6, 2009. |
| Office Action for Canadian Application No. 2,667,573 dated Jun. 13, 2014, 3 pages. |
| Office Action for Canadian Application No. 2,667,573, dated Jul. 8, 2015, 4 pages. |
| Office Action for Canadian Application No. 2,667,573, dated Jun. 14, 2016, 2 pages. |
| Supplementary European Search Report for European Application No. 07868561.7, dated Jan. 2, 2012, 7 pages. |
| PCT/US2007/082373, International Search Report dated Sep. 22, 2008. |
| PCT/US2007/082373, Written Opinion dated Sep. 22, 2008. |
| PCT/US2007/082373, International Preliminary Report on Patentability dated Apr. 28, 2009. |
| U.S. Appl. No. 12/582,675, Office Action dated Nov. 23, 2012,13 pages. |
| U.S. Appl. No. 12/582,675, Office Action dated Oct. 3, 2014, 11 pages. |
| Office Action for U.S. Appl. No. 12/582,675, dated Mar. 25, 2016, 16 pages. |
| Office Action for U.S. Appl. No. 12/582,675, dated Aug. 24, 2017, 17 pages. |
| Office Action for U.S. Appl. No. 12/582,675, dated Jan. 18, 2017, 15 pages. |
| Office Action for U.S. Appl. No. 12/582,675, dated Jul. 17, 2015, 13 pages. |
| Office Action for U.S. Appl. No. 12/582,675, dated Aug. 9, 2013, 11 pages. |
| U.S. Appl. No. 13/106,754, Office Action dated Jul. 3, 2012. |
| U.S. Appl. No. 12/011,193, Office Action dated Nov. 10, 2010. |
| U.S. Appl. No. 12/011,193, Office Action dated Jul. 22, 2011. |
| U.S. Appl. No. 12/011,193, Office Action dated Nov. 16, 2011. |
| U.S. Appl. No. 12/011,193, Office Action dated Oct. 2, 2013. |
| U.S. Appl. No. 12/011,193, Office Action dated Aug. 4, 2014. |
| Canadian Office Action in Application No. CA 2,680,281 dated Jan. 23, 2015. |
| Office Action for Canadian Application 2,680,281 dated Feb. 8, 2017, 3 pages. |
| European Office Action in Application No. EP 08754882.2, dated Feb. 11, 2010. |
| U.S. Appl. No. 12/045,666, Office Action dated Oct. 6, 2011. |
| U.S. Appl. No. 12/045,666, Office Action dated Jun. 4, 2012. |
| U.S. Appl. No. 12/045,666, Office Action dated Jul. 19, 2013. |
| U.S. Appl. No. 12/045,666, Office Action dated May 21, 2014. |
| PCT/US2008/056451, International Search Report dated Jun. 24, 2008. |
| PCT/US2008/056451, Written Opinion dated Jun. 24, 2008. |
| PCT/US2008/056451, International Preliminary Report on Patentability dated Sep. 8, 2009. |
| Office Action for U.S. Appl. No. 14/550,804, dated Jun. 29, 2017, 29 pages. |
| U.S. Appl. No. 12/032,637, Office Action dated Mar. 21, 2011. |
| PCT/US2006/054184, International Search Report & Written Opinion dated Jul. 2, 2008. |
| PCT/US2006/054184, International Preliminary Report on Patentability dated Aug. 19, 2009. |
| U.S. Appl. No. 12/039,692, Office Action dated Nov. 24, 2010. |
| PCT/US2006/055390, International Search Report dated Aug. 22, 2008. |
| PCT/US2006/055390, Written Opinion dated Aug. 22, 2008. |
| PCT/US2006/055390, International Preliminary Report on Patentability dated Sep. 1, 2009. |
| PCT/US2006/055197, International Search Report dated Aug. 29, 2008. |
| Written Opinion for International Application No. PCT/US2008/055197, dated Aug. 29, 2008, 5 pages. |
| PCT/US2008/055197, International Preliminary Report on Patentability dated Sep. 1, 2009. |
| Office Action for Canadian Application No. 2,680,797, dated Jan. 26, 2015, 5 pages. |
| Office Action for Canadian Application No. 2,680,797, dated Jul. 28, 2016, 4 pages. |
| U.S. Appl. No. 12/048,128, Office Action dated Dec. 23, 2011. |
| U.S. Appl. No. 12/048,128, Office Action dated Sep. 13, 2012. |
| U.S. Appl. No. 12/048,128, Office Action dated Mar. 26, 2015. |
| Office Action for U.S. Appl. No. 12/048,128, dated Feb. 4, 2016, 23 pages. |
| PCT/US2008/056899, International Search Report dated Mar. 27, 2009. |
| PCT/US2008/056899, Written Opinion dated Mar. 27, 2009. |
| PCT/US2008/056899, International Preliminary Report on Patentability dated Sep. 15, 2009. |
| European Office Action in Application No. EP 07869177.1, dated Mar. 13, 2015. |
| Canadian Office Action in Application No. CA 2,672,437 dated Oct. 14, 2014. |
| U.S. Appl. No. 11/637,300, Office Action dated Sep. 30, 2008. |
| U.S. Appl. No. 11/955,299, Office Action dated Oct. 18, 2011. |
| U.S. Appl. No. 11/955,299, Office Action dated Feb. 22, 2012. |
| PCT/US2007/087305, International Search Report and Written Opinion dated Jul. 3, 2008. |
| PCT/US2007/087305, International Preliminary Report on Patentability dated Jun. 16, 2009. |
| U.S. Appl. No. 12/049,113, Office Action dated Jan. 25, 2011. |
| PCT/US2008/057110, International Search Report and Written Opinion dated Aug. 5, 2008. |
| PCT/US2008/057110, International Preliminary Report on Patentability dated Sep. 15, 2009. |
| Office Action for U.S. Appl. No. 14/216,877, dated Sep. 30, 2016, 21 pages. |
| Office Action for U.S. Appl. No. 13/838,244, dated Feb. 9, 2015, 15 pages. |
| Office Action for U.S. Appl. No. 13/838,244, dated Apr. 22, 2016, 33 pages. |
| Office Action for U.S. Appl. No. 13/838,244, dated Nov. 30, 2016, 24 pages. |
| Office Action for U.S. Appl. No. 13/838,244, dated Sep. 29, 2015, 28 pages. |
| PCT/US2014/030837, International Search Report dated Jul. 24, 2014. |
| U.S. Appl. No. 11/923,554, Office Action dated Dec. 23, 2009. |
| U.S. Appl. No. 11/923,554, Office Action dated Nov. 12, 2010. |
| U.S. Appl. No. 11/923,573, Office Action dated Jun. 22, 2011. |
| U.S. Appl. No. 11/923,573, Office Action dated Oct. 14, 2010. |
| Number | Date | Country | |
|---|---|---|---|
| 20160335258 A1 | Nov 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60862736 | Oct 2006 | US | |
| 60886283 | Jan 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11923573 | Oct 2007 | US |
| Child | 14709318 | US |
