US20150301692A1

US20150301692A1 - Individual song libraries and personalized channels in broadcast satellite systems

Info

Publication number: US20150301692A1
Application number: US14/233,126
Authority: US
Inventors: Stelios Patsiokas; David George Mantel
Original assignee: Sirius XM Radio Inc
Current assignee: Sirius XM Radio Inc
Priority date: 2011-07-14
Filing date: 2012-07-16
Publication date: 2015-10-22
Also published as: CA2841787C; CA2841786A1; CA2841948A1; MX2014000503A; MX2014000504A; MX342864B; US20200077139A1; WO2013010189A3; WO2013010186A3; MX2014000502A; CA2841790A1; WO2013010185A2; US11372521B2; CA2841787A1; US20230121278A1; MX344100B; WO2013010189A2; CA2841948C; US11928313B2; WO2013010188A1

Abstract

Systems and methods to facilitate recording of individual tracks by a user of a broadcast music service, and the provision of user-specific personalized channels, based on such recordings, are presented. Such systems and methods include (i) recording of a song or audio clip from the broadcast for future playback (referred to as the “Love” functionality), and (ii) providing a shuffled playlist of songs for that user based on a mix of (a) “Loved” songs from a user's song library and (b) favorite artist songs speculatively recorded by the system or device over time in the background based on the user's selections of favorite artists. Such a user-specific playlist can be referred to as “My Channel” functionality.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application Ser. No. 61/572,332, filed Jul. 14, 2011 (the “Provisional Application”), which is hereby incorporated herein by reference.

TECHNICAL FIELD

The present application relates to broadcast and receiver technology, an in particular to various personalized enhancements to the listening experience of a user/subscriber to broadcast audio services including user creation of individualized song libraries and system provided personalized channels, using, in part, such user created song libraries.

BACKGROUND OF THE INVENTION

In a radio receiver or other device capable of receiving multiple channels from a broadcast or streamed content provider, users are provided with many programming options. Many times, users hear something of interest, which in their personal view, they would prefer to hear with greater frequency. However, the audio clip or song in question may not be generally programmed with a high frequency. Additionally, even if there is some local facility to replay songs of high subjective interest to an individual user, this requires the user to specifically instantiate such replay, each time she desires to hear the song or clip. There is no convenient way for a user to program a personalized channel comprising songs so designated.
What is needed in the art are systems and methods to solve these and other problems of the prior art, and to thus make personalized content, both specifically chosen and not chosen by the user, available in a convenient and accessible manner to a user.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present invention will be more readily understood with reference to the exemplary embodiments thereof illustrated in the attached drawing figures, in which:

FIGS. 1-8 present various exemplary screen shots that can be used in a user interface according to an exemplary embodiment of the present invention; and

FIGS. 9-15 illustrate various data categories and functionalities of an exemplary program suggestion algorithm according to an exemplary embodiment of the present invention.

SUMMARY OF THE INVENTION

DETAILED DESCRIPTION OF THE INVENTION

In exemplary embodiments of the present invention, individual track recordings from a broadcast or content streaming service selected by a user, as well as personalized channels, based at least in part on such user selections, can be provided. In what follows, these two functionalities, which greatly enhance a listener's experience, are detailed. They include (i) the recording of a user chosen song or audio clip from the broadcast or content streaming service for future local playback by the user (sometimes referred to herein as the “Love” functionality, inasmuch as a user is said to designate for recording those songs that he or she “loves”), and (ii) providing a shuffled playlist of songs, personalized to the user, based on a mix of (a) “Loved” songs from a user's song library and (b) songs from a favorite artist speculatively recorded by the system or device over time, in the background, based on the user's selections of favorite artists.

Glossary of Key Terms

The following is a glossary of terms and acronyms used herein, or related concepts, for ease of description of the various exemplary embodiments of the present invention. Some of the definitions relate, in particular, to certain exemplary embodiments of the invention based on the Sirius XM Radio Satellite Digital Audio Radio Service (“SDARS”), as implemented on a receiver or other user device arranged to receive the Sirius and/or XM service. It is understood that the specifics of such implementations are not limiting, and merely exemplary.


Glossary/Acronyms

BIC	Broadcast Information Channel. A system data channel used to convey semi-
	realtime data such as Artist/Title labels, PID, other track, channel, and category
	associated metadata, and specialty Extended Metadata such as Artist IDs.
Content	The music, talk shows, sporting events, and other audio programs transmitted on
	an audio channel.
extracting	The act of receiving the content from a channel. Usually refers to an internal
(a channel)	Module activity wherein an audio or data channel is received so its contents can
	be played live, buffered, recorded, or data service content processed. The
	Modules used for the exemplary applications are capable of extracting multiple
	channels simultaneously.
Fast	The act of moving the play point forward in a buffer by a series of small time
Forward	increments, independent of track boundaries. Typically invoked by press/hold of
	a Fast Forward button. (See also Skip)
FIFO	First In - First Out
GB	Decimal gigabytes (i.e. 1,000,000,000 bytes)
HMI	Human-Machine Interface. This software runs in a Sirius XM-capable product,
	controls a Sirius XM receiver, and presents the UI to a user.
Informative	Information provided for clarification or background, but not to be treated as
	formal testable requirements. (see also Normative)
IR	Instant Replay
Last Play	The buffered audio content that was playing at the instant the user tuned away
Point	from a channel (and therefore the last content the user heard from that channel).
	Last play point can be anywhere within a track.
Love	As a verb, implies recording a currently heard song or program.
Metadata	Data fields that describe the contents carried by a channel such as Song Title,
	Artist Name, and Song Tag.
Normative	Information to be treated as formal testable requirements. (see also Informative)
NVM	Non-Volatile Memory such as Flash or EEPROM
Platform	In this document, refers to the reusable “software platform” being implemented to
	support the requirements in this document, exclusive of product-specific user
	interface functions and policy.
Program	In this document, Program refers to an audio event that typically lasts for a half
	hour or more, and might correspond to a complete talk program, sports game,
	special music program, etc. A Program will often consist of multiple tracks.
PID	Program Identifier, a 32 bit value identifying the start of a transmitted audio track.
Radio	In this document, refers to the entire product, not necessarily one subcomponent
	of the product.
RAM	Volatile memory (random access memory). Data in RAM is lost when the
	product is powered off. Term is often used in contrast to NVM.
Reserved	Parameters that have no currently defined meaning. The functionality of these
	parameters may become defined in a future version of a protocol or API.
Rewind	The act of moving the play point backward in a buffer by a series of small time
	increments, independent of track boundaries. Typically invoked by press/hold of
	a Rewind button. (See also Skip)
RFU	Reserved for Future Use: See Reserved.
SID	Service Identifier. A unique fixed number assigned to every broadcast service.
	The SID of a channel is treated as a constant, with the associated user-visible
	Channel Number treated as metadata for the channel, and subject to change.
Skip	The action of jumping forward or backwards to the start of a buffered track. (See
	also Fast Forward and Rewind)
Song	A track (see definition), typically played on a music channel, corresponding to
	the traditional “song” concept, e.g. an individual music selection.
Tuned	The single audio channel currently being heard by the user, whether playing live
Channel	or from the IR buffer.
Track	A unit of audio content identified by a PID (Program ID) value. The Sirius XM
	system uses a PID change to designate the end of one track and the start of the
	next track. Examples of tracks include a song like “Stairway to Heaven” played
	on a music channel, a few minutes of a talk show, an inning in a baseball game
	on a sports channel, or comments by a DJ between two songs,. Though tracks
	correspond to true “songs” for music channels, the definition of a track for talk
	and sports channels is more variable, and may change at Sirius XM's discretion.
TRS	Technical Requirements Specification. For purposes of the exemplary
	implementation, one of a series of documents that derives from higher level BRD
	& FRD requirements documents to provide more requirements detail to various
	engineering design and implementation teams.
UI	User Interface

I. Basic Functionalities

A. “Love” Feature

In exemplary embodiments of the present invention, a “Love” feature allows a user to record a currently playing song (or other content track) to non-volatile memory, so that it can be re-played later whenever desired. “Loved” tracks can be stored, for example, in a library of such recordings. A given device can, for example, offer various methods of playing the library content so that the user can, for example, enjoy listening to their favorite content multiple times, when convenient. In exemplary embodiments of the present invention there can be, for example, two broad classes of Loved (i.e., recorded) content: “songs” and “programs.” Songs are individual audio tracks which can be identified through metadata as “songs”, and which can be stored in a “Song Library”. Programs are tracks which are not individual songs, and can be, for example, a talk program, sports event, or even a music event or channel that does not necessarily have separately identified songs. Programs can, for example, be stored in a “Program Library”. Thus, as used herein “Love” functionality is synonymous with recording a single song (track) or even multiple-track (track) in non-volatile memory so that the song/track can be played back at a later time. In exemplary embodiments of the present invention, loved songs can be stored in a song library, which can be, for example, a repository of recorded tracks in non-volatile memory such as flash or a hard drive. The song library can be, for example, maintained on a user device in memory (e.g., in flash managed by a processor or integrated in a module). In exemplary embodiments of the present invention, a device can offer various means to a user for playing back song library content, ranging, for example, from simply playing song library contents in some randomized or fixed order, to offering full playlisting and navigation of such content so that a user can control playback order.
In exemplary embodiments of the present invention, song library contents can be managed by a user. In such embodiments, once a song library is filled to capacity, it is then up to a user to (i) delete songs when wishing to add new Loved songs, or to (ii) choose to allow a user device to, for example, automatically delete the oldest song to make room for a newly recorded song (known as a “FIFO” deletion protocol), or use some other rule (e.g., songs with lower rankings, according to a given ranking system), to delete previously stored content.

B. My Channel

In exemplary embodiments of the present invention, a “My Channel” functionality can, for example, build on a Love feature, by, for example, creating a randomized playlist that mixes Loved songs from the user's song library with additional songs speculatively recorded in the background by the radio, or other user device. From a user's perspective, they would hear on such a “My Channel” a mix of songs that they had explicitly recorded, plus some surprises, but all by artists that they had previously indicated as their favorites.
Thus, in exemplary embodiments of the present invention, a user device can offer a user the ability to identify song artists as a “Favorite Artist.” Thereafter, the radio can, for example, scan all broadcast channels in the background looking for new songs by any of the user's Favorite Artists. When a receiver has, for example, the internal resources available to extract (i.e., receive) the channel broadcasting the detected song by a Favorite Artist in its entirety, it can then record that song in the background, and store it in a section of non-volatile memory which can be called, for example, a My Channel Cache.
In exemplary embodiments of the present invention, My Channel Cache contents can then be managed by the user device. New songs can continuously be added to the My Channel Cache in, for example, a FIFO manner, or other replacement algorithm, as noted above. Once it is filled, older songs can be deleted as newer songs are detected and recorded by the radio in the background. When a user then “tunes” to My Channel, the radio can play a mix of Loved songs from the Song Library and Favorite Artist Songs from the My Channel Cache. In exemplary embodiments of the present invention, play order of My Channel can be established by radio software, and need not be under user control, thus simulating a “virtual channel” experience. In exemplary embodiments of the present invention, a user may skip forward from track to track while listening to My Channel, inasmuch as they are all recorded.
In exemplary embodiments of the present invention, one or more My Channels can be music oriented. Thus, a given system can limit the contents to “songs” as defined by program identifier (PID) fields transmitted during the broadcast. For example, a user may be precluded to Love tracks for My Channel that are not songs, nor would the radio capture tracks for the My Channel Cache that are not songs (even though in general, a user could Love such content). Other implementations can allow, for example, recording of individual non-music programs, with playback managed separately from a My Channel functionality. My Channel background recordings (also referred to herein as “Speculative Songs”) for the My Channel Cache can, for example, be supplemented with additional songs based on, for example, artist affinities, filtered by most popular songs, etc.

II. Detailed Features of Love an Exemplary Functionality

Next described are various features and functionality of the Love functionality. In exemplary embodiments of the present invention, a user may invoke a “Love” operation, via a user interface, while listening to a song, resulting in that song then being stored in the song library.
Loved Songs Must be Heard while Recording
In some, but not all, exemplary embodiments of the present invention, when recording a song using Love, only the content that is “heard” by the user is actually recorded. Thus, once Love is initiated, a user device can, for example, require that the user continue to listen to the song for it to be completely recorded. For example, in such schemes, a Love song recording may not proceed “in the background”. In exemplary embodiments of the present invention, if a user attempts to tune away from the recording song being recorded before it has completed, skip forward or back, rewind or fast forward, change to a different connectivity mode, power off, go into demo mode or any operation other than a simple pause/resume (or turning down the volume), that can, for example, cause the song to no longer be heard by the user. Similarly, if a user navigates away from a Now Playing screen for the Loved song, the product can, for example, warn the user and allow them to either (i) abort the recording (stop the recording of the Loved song and delete whatever has already been recorded), (ii) stop the recording and keep the partial recording, or (iii) abort the tune operation (continue listening to the song to complete the recording), or simply allow background recording, where there is no digital rights management issue, for example.
In exemplary embodiments of the present invention, a user can (and practically speaking, must) initiate a Love operation after they have already heard part of the song. Taking this fact into account, whatever portion of the song they have already heard continuously before initiating the recording can, for example, be included in the completed recording. Typically a user will have heard the song from the start, so that the entire song can therefore be recorded. However, if a user tunes to a channel and starts listening at a point after the song has started, the missed portion of the song will not be included in the recording.
In exemplary embodiments of the present invention, a user can Love a song while tuned to a channel regardless of whether they are listening to live broadcast or listening to the song as it is being played from a replay buffer (such as is described, for example, in companion applicaiton PCT/US2012/______, filed herewith, Jul. 16, 2012, entitled “Content Caching Services in Satellite and Satellite/IP Content Delivery Systems”), the disclosure of which is hereby incorporated herein by this reference. It does not matter, as long as they listen to the entire song while it is being recorded. If a user pauses a Love recording using IR controls, recording also pauses. If the user subsequently resumes play, the recording can then resume. If, however, a user pauses and then tunes away from that channel, the recording can, for example, be aborted with a warning as described above. Thus, for a product supporting a “Smart Favorites” functionality, such as is disclosed in commonly owned application number PCT/US2012/025091, filed on Feb. 14, 2012 (The “Tune Start” application), a user cannot start a song recording on channel A, pause, tune to channel B, and return to Smart Favorite channel A at the Last Play Point to resume recording the song. Thus, in exemplary embodiments of the present invention, if a user tunes away from the current channel, even if performing an operation like scan, and returns to that same channel and last play point, a system can, for example, prevent the user from recording the current song except from the point at which she returned. In such exemplary embodiments, a rule that the “song must be heard” to be fully recorded can be interrupted by a simple pause/resume, but not by any other operation that involves playing different content.

Only Real Songs Loved

In exemplary embodiments of the present invention, a user device (or “radio”) can determine if the currently playing track is a song, based on PID transmitted with that track. If the track is not a song, the radio can, for example, either: (i) eliminate the Love option entirely (i.e. graying out a user interface button) or (ii) link the Love option to actions involving “program record” or other recording options. It is noted that this implies that some channels that broadcast songs but do not mark them as a song with PID data may not be supported by the Love song feature (e.g., music programs transmitted as one long Program, live concerts, etc.).

Loved Songs Retain all Track Metadata

In exemplary embodiments of the present invention, when a Loved song is recorded, all metadata currently tracked by the product for live content can be saved with the song, such as, for example, artist, title, content info, song tag, etc. In addition, in exemplary embodiments of the present invention, the channel number and name, and category name and category ID of the channel airing the song can also, for example, be saved with the recording.

Uplink Record Restrictions Observed

In exemplary embodiments of the present invention, if a user attempts to Love a song for which either a song or channel record restriction flag is asserted in the broadcast, the recording can be prevented with an advisory provided to the user. For some products, an icon used to invoke Love can, for example be grayed out when such a song starts playing—from a live broadcast or from within the IR buffer.

Duplicate Song Recording Replaces Old Copy

In exemplary embodiments of the present invention, if a user attempts to Love a song that has already been recorded in the Library, the radio can replace the old recording with the new, thus reducing the aging of that song to the present. No prompt need be provided to inform the user of the replacement in such instance, and the older copy is not deleted until the newer recording is successfully completed. It is here noted that a user may “re-Love” a song for reasons including (a) they know the older version had some corruption, DJ talk, etc. and want a better copy; (b) they simply forgot they already had it; or (c) they want a “newer” copy to avoid FIFO or other “aging band” deletion of the older version, as described above.

Partial and Corrupted Song Recording

In exemplary embodiments of the present invention, a system can (i) offer a means for halting a recording in progress, (ii) provide a choice to stop the recording and discard the partial recording, or (iii) stop the recording and retain the partially recorded song. In exemplary embodiments of the present invention, if a period of sustained signal loss or content bit errors occurs during recording of a Loved song, a system can abort the recording with an advisory to the user. In exemplary embodiments of the present invention, all track recordings generated by a module can be assigned a quality rating attribute from 1 (worst) to 10 (best) once the track has completed, based on the frequency of frame errors detected during the recording. In exemplary embodiments of the present invention, only tracks with a defined quality level, such as, for example, 9 or better can be retained. In exemplary embodiments of the present invention, a quality attribute need not be provided until the end of the track, so as of make sure and obtain a correct overall rating.
Love from Recorded Content
In exemplary embodiments of the present invention, where certain digital rights issues would preclude it, a user cannot Love a song from non-volatile pre-recorded content. More specifically, a user cannot (i) Love a song while listening to a Shadow Recording, Block Recording, or Scheduled Recording, (ii) Love a song from a Showcase recording; and (iii) Love a song while listening to My Channel.

Exemplary Recording Rules

In exemplary embodiments of the present invention, a user can Love a currently playing song after a scan operation has been halted, such as, for example, via either a Channel Scan or a Content Scan. In such exemplary embodiments, a system can include the brief portion of the song heard just before halting the scan as part of the recording. Moreover, for products supporting Song/Artist Alerts, a product may prevent a user from initiating a Love recording for a song heard as a result of changing channels in response to a Song or Artist Alert for that song. Where no digital rights issues are operative, no such restrictions need apply.

Song Library Management

Memory Allocation—Interaction with Other Caching/Recording Operations
In exemplary embodiments of the present invention, a user device can, for example, allocate a partition of non-volatile memory for song library purposes. If the management of memory involves dynamic capacity allocations between the Song Library and other storage, a device must prioritize storage up to the maximum published capacity for the Song Library above storage shared for other functions, including, for example, Shadow Recordings. For example, if all shared memory is full and a new Loved Song is being recorded but the total memory used for the Song Library is less than the maximum published capacity for the Song Library, then the oldest Shadow Recording(s) can be deleted as needed to make room for the Loved Song.
In exemplary embodiments of the present invention, a system can, for example, allow user-initiated reallocation of all Song Library storage for other purposes if the authorization of the user's device set to disallow song recording, for whatever reason. However, if the device does support reallocation, it must also be able to reallocate storage back to the Song Library in case the radio is subsequently authorized for song recording. Thus, it is recommended that such reallocation draw only from naturally ephemeral content storage, such as, for example, Shadow Recordings, to avoid complications with deleting content expected to be more permanent to the user, and thus avoid sharing space with Block and Scheduled recordings. In exemplary embodiments of the present invention, the maximum Song Library capacity can be set at 500 songs, for example. Because songs can range from around a minute to 20 minutes or more for a classical piece, an exemplary device should allocate storage as liberally as is practical to avoid disappointing a user expectation by filling physical memory before the maximum song count is reached. In an exemplary implementation, memory reserved for the Song Library can accommodate a minimum of 500 songs at average 5 minutes each at 56 kbps, or about 1.05 GB (decimal K) excluding memory for track metadata storage.

Capacity Reporting/Full Storage Conditions

In exemplary embodiments of the present invention, a system can be capable of reporting the current storage capacity status at the time a Love recording is initiated, based on remaining song count for new recordings (exclusive of the currently recording song). This allows the user to proactively monitor usage and delete unwanted tracks from the Library before reaching a storage full condition. If the user attempts to record a song and the maximum allowable Song Library count would be exceeded or there is insufficient storage in the Song Library partition to store the recording then a radio can, for example, continue to completely record the song. When completed, it can then prompt the user to choose to either (a) have the radio auto-delete the oldest song(s) in the Library to free sufficient space for the new song, or (b) abort the recording. This implies that the radio must be able to determine which songs in the Song Library are the oldest, in order to implement FIFO storage management (or, for example, track the tags/variables necessary to implement other Song Library management protocols, besides FIFO). Furthermore, a product may optionally present a third alternative, namely providing the user with an option to navigate through the Song Library and delete song(s) of their choosing (if not too complex for the UI to manage). Thus, in such exemplary embodiments, a radio must manage memory such that recording of an unusually long song, for example (at least 10 minutes @ 56 kbps) can continue successfully while the user is allowed to selectively delete songs to free up space.
In the very unusual case that a user has selected the option to manually select songs for deletion to clear memory, but memory is nevertheless exhausted during the recording of a song, the product may simply abort the recording with a “Recording Aborted—Not Enough Space” advisory, or, for example, can automatically allocate 10-20%, for example, additional memory, so as to provide “overdraft protection” to users, and never abort a chosen recording. In exemplary embodiments of the present invention, a given product can offer basic Song Library management services to a user, including song deletion, so that a user can more proactively manage which recorded songs they wish to keep.

User Library Management

In exemplary embodiments of the present invention, the following Song Library management functions can be supported: (i) list songs in the Song Library, with Artist and Title at minimum; (ii) provide the ability to Delete any Song from the Song Library (“Un-Love”); and (iii) show current Song Library capacity metrics (enough for the user to determine if deletions are needed to make room for new recordings). In addition, an exemplary product can also offer, for example, to organize songs in the Song Library in multiple aggregations and sort orders including, for example, song name, artist, chronologically by record time, channel, and category.

Song Transfer Functionalities

In exemplary embodiments of the present invention, a system can either prevent or allow the transfer of recorded songs from a user device to a different device or storage media, as may be desired, or as may be implemented given prevailing digital rights management schemes and contractual obligations.

Song Playback

In exemplary embodiments of the present invention, when playing back Loved songs stored in a Song Library, a product can offer functions typical of song library functions including, for example: (i) select a specific song for play, (ii) Play all songs in the Library, (iii) select an Artist and play songs by that Artist, (iv) select a Channel and play songs recorded from that Channel, (v) select a Category and play songs recorded from Channels with that Category, (vi) create custom playlists of specific songs in the Library, (viii) play a list of songs ordered as listed by the user or in shuffled order; and (ix) repeat vs. one-time play of selected songs or playlist. In exemplary embodiments of the present invention, when playing from a song list derived from a Song Library, there can be no restrictions on the user as regards skipping forward or backward from track to track, rewinds, fast forwards, or replay counts.

Authorization Issues

In exemplary embodiments of the present invention, Loved song recording, playback, and Song Library management functions can be disallowed by a given product if the product detects that a satellite receiver is no longer subscribed to an SDARS, for example. In this connection, it is noted that it is expected that a product owner may listen to the Song Library and to his or her various My Channel when out of satellite (or IP) signal coverage. During this period a given product cannot readily determine whether the user's subscription is still valid. Therefore to address such cases, a product can, for example, support a gradual timeout for out-of-signal usage, giving the user the benefit of the doubt, but ultimately requiring some satellite (or IP) connectivity to verify that the subscription is still active.
In exemplary embodiments of the present invention, a user device need not immediately physically delete Song Library content for a product that becomes unsubscribed (or, as noted above, a given out-of-signal grace period expires). Thus, if the user re-subscribes, Song Library content can be recovered unless the user (or, for example, a refurbishing depot) has explicitly cleared the Song Library through a maintenance function. However, after a defined period of time has elapsed since the out-of-signal grace period has expired, or since the product has been confirmed as unsubscribed, the contents of the Song Library can be permanently deleted. Such defined time period can be, for example, 60, 90, or 120 days.

Song Recording Tiering

In exemplary embodiments of the present invention, a system can support two tiers of authorization levels related to song recording: (i) Disallowed—no song recording or playback of previously recorded content is allowed; and (ii) Limited—song recording is allowed, but is constrained to a maximum of some defined number of songs or the storage capacity limit of the product, whichever is more constraining. In exemplary embodiments of the present invention, song recording tier authorizations can be managed through standard system business rules. For example, for the Limited tier, the maximum duration of all recorded songs can be anywhere from 300-1,000 songs, for example.
In exemplary embodiments of the present invention, a system can support transitions between the two song recording tiers at any time. Thus, when transitioning from Limited to Disallowed tiers, previously recorded content related to the feature already present in the product can behave similarly as described above; i.e., playback access can be denied, but the recorded content is not physically deleted until 60 days after the transition from Limited to Disallowed. If the product transitions from Disallowed to Limited, user playback access to any related recorded content then remaining still on the device can be, for example, restored. In exemplary embodiments of the present invention, song recording can default to Limited, for example, to allow to choose between Limited and Disallowed (e.g., through some premium package option). Alternatively, for example, the option can be provided to either (a) set all the exemplary implementations to Disallowed or (b) with significant prepatory work set some the exemplary implementations to Disallowed and others to Limited. Thus, the exemplary implementation must be able to accommodate transitions between these two states even though such changes may be very unlikely.

Love for Non-Music Programs

As noted above, in exemplary implementations, Love can be used only for Music content, i.e. “songs” and alternate exemplary implementations, Love functionality can be extended to allow recording of non-music content. This can include the following behaviors, for example: when Love is invoked during a non-music track, the receiver can, for example, determine the duration of the program currently playing and automatically record the Program from the start of the program that had been heard by the user, through the end of the program. The start and end, as well as other metadata (title, description, etc.) can be determined by referring to EPG data corresponding to the current time of recording.
Alternatively, for example, the start and end can be determined by a Program ID within a broadcast marker such as the PID or other new extended metadata field in the BIC, to determine start and end. This can provide robustness in case real-time transmission of the program varies somewhat from EPG data
In exemplary embodiments of the present invention, Loved Programs can be stored in a Program Library that can be managed separately from the Song Library. In exemplary embodiments of the present invention, such Loved Programs could, for example, not be included in My Channel, and alternate methods of accessing and playing the Loved Programs would be provided. It may be allowed, for example, to tune away from the current channel after starting a Love Program recording, effectively treating the recording like a background Block recording. Unlike music, a Program can, in exemplary embodiments of the present invention, be recorded without requiring the user to listen to the entire Program during the recording.

III. Detailed My Channel Functionalities

Next described are various features and functionalities of My Channel. As noted above, in exemplary embodiments of the present invention, My Channel can provide a user with a playlist of songs mixed from the user's Loved Songs, as described above, and additional songs recorded by the radio in a My Channel Cache, based on various criteria including, for example, the user's designated Favorite Artists.

Favorite Artist List Management

In exemplary embodiments of the present invention, a system user interface can allow a user to designate Favorite Artists. For example, a Favorite Artist can be selected when Loving a song. Other products may offer additional methods for identifying Favorite Artists, but all can, in general, involve creating a list of Artist IDs and an associated Artist Name text string.
In exemplary embodiments of the present invention, a system can maintain a Favorite Artists List consisting of Artist IDs (a 32 bit integer) and the corresponding Artist Name (based on the longest provided Artist label available). The size of the Favorite Artists List can be minimum 200 entries. For example, a product user interface can prevent the saving of a Favorite Artist for tracks which are (a) not music tracks, as indicated by the track PID, or (b) have no corresponding Artist ID. For example, a song may be Loved if it has a valid Song ID, but that song may not be tagged with an Artist ID. In such a case the the exemplary implementation Love popup would gray out the checkbox option to select this song's Artist as a Favorite Artist. In exemplary embodiments of the present invention, a product user interface can also provide a user with methods for eliminating an artist from a Favorite Artists List.

Favorite Artist Song Recording (My Channel Cache)

In exemplary embodiments of the present invention, a system can, for example, monitor all channels, looking for songs played by any of the Artists in a user's Favorite Artists List. If a candidate song is detected, the product can, for example, determine if the song is already in the My Channel Cache or in the Song Library of the user's device. If the song is not present in the cache or library, the song can be recorded. If, for example, the song is already present in the cache or library, the song need not be recorded and the product can scan for a different candidate to record.
If, for example, a My Channel Cache is full to capacity, new recordings can replace the oldest recordings in a FIFO manner, or in some other manner, as noted above. As space is made for new recordings, the oldest (or other chosen for deletion) recording can be deleted in its entirety, for example. In exemplary embodiments of the present invention, a My Channel Cache capacity can be, for example, 10 hours of content (assuming 56 kbps, plus storage metadata for an average song length of 3 minutes). It is noted that 10 hours provides sufficient content for a diverse listening experience with My Channel. Also, in cases where the cache is refreshed in a FIFO manner, it provides little incremental user benefit to maintain over 10 hours of content in the cache. Note that the 10 hour My Channel Cache is in addition to storage used for the Song Library, containing the user's Loved Songs.
In exemplary embodiments of the present invention, in general, Favorite Artist songs can be recorded by any of the following receiver channel extraction resources: (i) “Floating Extractions,” i.e. channel extractions available for multiple purposes (in exemplary embodiments of the present invention, there can always be at least one Floating Extraction available for My Channel Cache recording at all times); (ii) Smart Favorite Channels—Favorite Artist songs can be recorded from any of the currently active Smart Favorites, since by definition these channels are continuously being extracted and buffered; (iii) Current Channel—Favorite Artist songs can be recorded from the currently tuned channel; Shadow Record Channels—Favorite Artist songs can be recorded from any of the music channels currently being Shadow Recorded; and (iv) Block/Schedule Recordings—Favorite Artist songs can be recorded from any of the music channels currently being recorded for other purposes.
In exemplary embodiments of the present invention, a receiver module can manage such extraction resources so as to concurrently record as many Favorite Artist songs as possible. Thus, depending on other product and user activities, the number of Favorite Artist songs that can be recorded simultaneously at a given time can range from, for example, zero to seven. In exemplary embodiments of the present invention, a device can insure that Favorite Artist song recordings are complete and error free. The recording of a Favorite Artist song can be aborted, and the partial recording discarded, if either: (i) a recording must be terminated due to device activities that eliminate the ongoing extraction needed for the recording; or (ii) a recording is subject to bit errors that would result in audible errors during playback, indicated by a track audio quality measurement of less than a defined number, say 8 or 9, for example, on a scale of 1 to 10.
In exemplary embodiments of the present invention, a recording can terminate if more than two 432 msec frames (about 1 second) are missed (based on the frame at which the PID marker for the song changes), due to tuning or other latencies. In exemplary embodiments of the present invention, use of “Look Ahead” metadata can alleviate the likelihood of this latency issue. It is noted that the start of the song (as perceived by the user) may still be incorrect since (a) a PID marker may not be associated with the correct frame in the broadcast and (b) it can be no more accurate than the duration of a frame (about ½ second for 432 msec frame structures.
In exemplary embodiments of the present invention, recording of Favorite Artist Songs for a My Channel Cache can be completely transparent to the user. Thus, the user need never be aware of the ongoing recording, management of the cache, handling of aborted recordings, etc. Recording of Favorite Artist Songs for the My Channel Cache can proceed if the user is listening to recorded content in the foreground (e.g., while the user is listening to My Channel, the Song Library, a Shadow Recording, etc.) If a Favorite Artist Song recording is in progress, and the user then attempts to Love the same song which happens to be playing on a different channel, the Favorite Artist Song recording can be halted and the Love recording proceed (all without any notifications to the user).

My Channel Playback

Playlist Creation

In exemplary embodiments of the present invention, a receiver can build and maintain a playlist for My Channel, which can be used whenever the user listens to his or her My Channel. The overall objective of such a playlist algorithm is to shuffle a mixture of both Loved Songs from the Song Library and Favorite Artist Songs from the My Channel Cache. A randomized selection of each next song during play from these two pools of content can be used, for example, with the following additional constraints to accommodate certain unique challenges with mixing songs that a user may have explicitly recorded with content speculatively recorded by the radio, and the likelihood that there may be a dearth of Loved and/or Favorite Artist songs available when the user initially plays a My Channel. By default, My Channel songs can be temporally distributed in the playlist equally between Loved Songs (from the Song Library) and Favorite Artist Songs (from the My Channel Cache), in a ratio proportional to the number of Loved Songs vs. Favorite Artist Songs. For example: if a user has 50 Loved Songs and 100 Loved Artist Songs, this can result in a randomized 150 song playlist, with two Favorite Artist Songs used between each Loved Song. Moreover, no song need be repeated twice in a row, unless there is only one song available in the combination of the Song Library and My Channel Cache.
In an exemplary embodiment of the present invention, on each pass through the playlist the device can play each song in the Song Library and My Channel Cache one time, with the following exception: if there are at least 30 songs available for play, and more than five (5) times the number of Favorite Artist Songs than Loved Songs, a Loved Song can be played at a minimum every 5th song, as long as it does not result in repeating the same song more often than once every 30 songs. This rule is intended to insure that the subscriber's explicitly Loved Songs get played at a minimum frequency in a situation where the number of Favorite Artist Songs is significantly more than the number of Loved Songs, and simple shuffling would result in the user rarely hearing his or her explicitly recorded songs. It is noted, though, that if there are less than 30 songs total, there is no way to avoid the user hearing repeats more than once every 30 songs. Thus, a user may require multiple sessions to play through one cycle of an entire playlist.
In exemplary embodiments of the present invention, regenerating a new playlist each time the user starts My Channel can be avoided, as this could more easily result in rarely playing some songs and repeating others in relatively rapid succession. Since My Channel is not a fixed playlist known to the user, is the case with an shuffled MP3 player playlist, there is no benefit to the user in re-shuffling the playlist each time play starts. While playing through a playlist, a song may be deleted from the My Channel Cache (by FIFO or other recording action, as described above) or Song Library (by the user). The product must then remove the song from the playlist, but need not otherwise regenerate the playlist. If the user is actively playing My Channel and the currently playing song is a candidate for deletion from the My Channel Cache (because it is the oldest song, or otherwise designation for deletion, being replaced by an ongoing new recording), the device can instead, for example, delete the next oldest song from the cache. While playing through a playlist, new songs can, for example, be added to the My Channel Cache (by FIFO or other recording action) or Song Library (via user Love action). The new songs need not be be added to the playlist until the next time it needs to be generated.

My Channel Navigation

In exemplary embodiment of the present invention, while listening to My Channel, a user may skip forward from track to track an unlimited number of times. If the user skips through the entire playlist, the product can regenerates a fresh playlist, transparent to the user. The user can, for example, fast forward by small time increments an unlimited amount of time. A My Channel “listening session” can be, for example, defined to begin any time My Channel play is started after listening to any other content, whether offline or while connected to, a Satellite or IP broadcast or stream or after a power cycle. As one more subtle example, if a Traffic Jump feature causes My Channel to be temporarily interrupted to play a traffic report from live Satellite, then jumps back to the user's My Channel, the resumption of My Channel can be treated as a new listening session.
In exemplary embodiments of the present invention, each time a new My Channel listening session starts, playback can commence from the start of the next track in the My Channel playlist that follows the track that was heard in the previous listening session, even if that previous track was not completely played. The user can skip back to the beginning of the currently playing track, as well as to the start of any track previously played (or skipped over) in his or her current My Channel listening session. At the start of each My Channel listening session, tracks played from the previous My Channel listening session can be, for example, no longer reachable with skip back. In exemplary embodiment of the present invention, any Favorite Artist Song in the My Channel playlist preceding the currently playing My Channel track and within the current listening session playlist can, for example, be locked for FIFO (or other) deletion during the current My Channel listening session.
In exemplary embodiment of the present invention, a user deletes a Loved song or removes it as a My Channel song, while listening to My Channel, that song can no longer be reachable using skip back. The user may rewind by small time increments, but not beyond the start of the currently playing My Channel listening session playlist. The user may pause and resume while listening to My Channel. In exemplary embodiment of the present invention, a the replay list may not be available (icon grayed out) when listening to My Channel.

My Channel Access

In exemplary embodiments of the present invention, when My Channel is authorized for a radio My Channel can be included in the channel spectrum for both IP Mode and Sat Mode. In addition, My Channel can be assigned to a Favorites (presets) bank, can be excluded from any scan functions (Channel Scan or Content Scan), and can be, for example, excluded as a Shadow Recording candidate. Finally, My Channel can be, for example, accessible from Library menus. When My Channel is not authorized for a radio, it need not appear in the Spectrum, Favorites, or any Library menus.

Advisories for Limited My Channel Content

In exemplary embodiments of the present invention, the following policies can apply to conditions where there are insufficient songs to populate My Channel for a useful experience. In exemplary embodiments of the present invention, if a user has neither Loved any songs, nor selected any Loved Artists, on selecting My Channel a prompt can, for example, advise the user to: “Please Love songs and Artists to begin building your My Channel”. If the user has Loved songs, but has not yet selected any Loved Artists, on selecting My Channel the channel can play, but can prompt the user, for example, to “Please select Loved Artists add more content to your My Channel”. In this situation there will be no Loved Artist Songs. Though My Channel can be played with just Loved Songs, in such instance, it is no different from listening to the Loved Songs in the Library. If a given radio has less than, for example, 10 Loved Artist Songs it has accumulated less than, for example, 8 Loved Artist Songs over the last 2 hours of cumulative radio-on time, upon selecting My Channel the channel can play, but can, for example, also prompt a user to: “Please select more Loved Artists add more content to your My Channel”. This accommodates both of the following situations: (i) the user has not picked enough Loved Artists to acquire new Loved Artist Songs fast enough; and (ii) the Loved Artists are not played frequently enough to acquire new Artist Songs fast enough. It is noted that all advisories described above can include, for example, a “Do not show this message again” checkbox.

My Channel Content Management

Eliminating a Favorite Artist

In exemplary embodiments of the present invention, method(s) for eliminating a Favorite Artist from the Favorite Artists List can be provided. For example, this can be accomplished through three methods: (i) within Song Library management functions, the user can, for example, exclude the Artist from My Channel through a popup check box when viewing details of a Loved Song; (ii) while Loving a new song while it is playing, the user can, for example, remove the default check for the “Include Artist in MyChannel” box in the Love popup, implying this Artist is to be furthermore excluded from the My Channel Cache (i.e., speculatively recorded Favorite Artist Songs); and (iii) in a Setup function, the user can, for example, view a list of all Artists that are either (a) in the current Favorite Artists List or (b) are associated with any Loved Song in the Song Library. Artists in the list that are in the Favorite Artists List can be shown, for example, with a check by that Artist. If a user then deselects an Artist, if there is at least one song in the Song Library by that Artist, the entry can, for example, remain in the Setup list. If there is no song in the Song Library associated with such deselected Artist, the next time the user enters the Setup function that Artist will no longer appear.
In all cases above, the resulting action by the recover can be, for example, to: (i) remove the Artist from the Favorite Artists List; (ii) halt further background searches and recordings of that Artist for the My Channel Cache; and (iii) delete all instances of songs by that Artist in the My Channel Cache (i.e., delete all speculatively recorded Favorite Artist Songs by that Artist). The deleted songs can, for example, also be removed from the current My Channel playlist. In exemplary embodiment of the present invention, however, songs by that Artist in the Song Library, i.e. Loved Songs, need not be deleted.)
In exemplary embodiment of the present invention, if a Favorite Artist Song is deleted as a result of deleting all songs by that artist during a My Channel listening session, and that song was in the current listening session playlist preceding the current play point, if the user skips back in the My Channel playlist, that deleted Favorite Artist Song need not be present, for example. In other words, in such exemplary embodiment, a Favorite Artist Song may not be “protected” because it happens to be in an accessible portion of the playlist.
Other exemplary embodiments can, for example, offer additional methods of removing Favorite Artists, such as, for example, allowing the user to peruse the Favorite Artists List and delete Artists from the list.
Deleting Songs from Song Library
In exemplary embodiments of the present invention, a user can, for example, delete Loved Songs from a Song Library (i) through Song Library management functions, or, for example, the ability to delete a Loved Song while listening to the song in My Channel can be supported. If a Loved Song is in fact deleted, an exemplary device can remove it from a My Channel playlist. If the user is currently playing the deleted song in My Channel as it is deleted, the product can, for example, advance to the start of the next song in the playlist and delete the song.

Marking Loved Songs as “not for My Channel”

In exemplary embodiments of the present invention, by default each Loved Song in the Song Library can automatically be a candidate for a My Channel Playlist once it is recorded. However, some exemplary embodiments can offer, through Song Library management functions the option for a user to exclude a Song from inclusion in a My Channel playlist. Additionally, a user can also be able to include a Song that was previously excluded from My Channel. Thus, if a Song in the Song Library has been marked for exclusion in My Channel, it can be removed from the current playlist and ignored for purposes of future My Channel playlist generation.
My Channel authorizations share the same methods and meanings as described above for the Love functionality.

Love Technical Requirements

In exemplary embodiments of the present invention, the following can be handled by some combination of SMS, additional middleware, and a receiver or product resident application: (i) speculatively record the currently playing song to memory, supporting a limit of at least 10 minutes at 56 kbps, so the content is proactively captured in memory should the user choose to Love it within 10 minutes; (ii) starting a Love Song recording initiated by user actions, enforcing policies that assure only a real “song” is recorded for Love Song; (iii) storing the recorded audio content, along with song metadata, into the Song Library memory; (iv) determining whether the recorded song is sufficiently error free to warrant retention vs. deletion, based on monitoring signal quality or other information during the recording; (v) management of the Song Library, including FIFO management (i.e., deleting tracks); (vi) generating sorted lists, filtered lists, and playlists from the Song Library in response to user interactions; and (vii) streaming previously recorded audio content when a Song is played by the user.
In one exemplary implementation, the following can be handled by firmware: (i) streaming audio packets for a recording Loved Song, so that the content and associated song metadata can be stored; and (ii) playing previously recorded Loved Songs and decoding audio packets streamed.

My Channel Technical Requirements

In one exemplary implementation, the following can, for example, be handled by some combination of SMS, additional middleware, and a host application: (i) capturing and managing the Favorite Artists List, including non-volatile media storage of the list; (ii) scanning all channels using Look Ahead metadata to identify candidate Favorite Artist Songs, and determining if a potential candidate recording should proceed or not (i.e., recording terminated if it is a duplicate in the cache and library); (iii) when a qualified candidate Favorite Artist Song is found, initiate streaming of the identified channel to the Host so the song audio can be stored; (iv) determining whether the recorded song is sufficiently error free to warrant retention vs. deletion, based on monitoring signal quality or other information during the recording; (v) managing extraction resources, to optimize extractions between competing product recording functions, based on information provided by the receiver; (vi) management of the My Channel Cache, including FIFO management (including deleting tracks. In such exemplary implementation, as the receiver provides a new recording which requires deletion of the oldest recording in the My Channel Cache, it can, for example, handle the complications that can arise if the oldest recording happens to be playing to the user as part of My Channel play; (vii) generation of the my channel playlist; (viii), an aging playback of my channel, interacting with a user; and (ix) streaming previously recorded audio content when My Channel is played by the user.
In such exemplary implementation, the following can handled by firmware: (i) streaming audio packets for a recording Favorite Artist Song so the content and associated song metadata can be stored; and (ii) playing previously recorded Loved Songs and Favorite Artist Songs for My Channel, decoding audio packets streamed.

Song Recording Tier Control

In exemplary embodiments of the present invention, authorization control can be provided to convey the following authorizations to a receiver:
Value Meaning
Not Authorized Song Recording=Disallowed

- Radios are not allowed to record individual songs to non-volatile memory.

Also, the radio must not allow playback of any previously recorded individual songs using disaggregated playback services such as playing Loved songs from a Library, or playing My Channel content.
Authorized Song Recording=Limited

- Radios may record individual songs to non-volatile memory for purposes of supporting features such as Love and My Channel, but are subject to maximum limits on the count of recorded songs. Also, the radio may play individual recorded songs using disaggregated playback services such as playing Loved songs from a Library, or playing My Channel content.
  song recording tier control authorization can, for example, be independent of any other control used for recording-related entitlements. This, for example, authorizations for “Instant Replay Navigation Tier Control” recording can, for example, be independent of authorizations for Song Recording Tier Control, inasmuch as legal/business objectives and constraints may require different treatment of these capabilities. It is noted that, In exemplary embodiment of the present invention, the song recording tier control affects only individual song recordings; it has no effect on recordings of non-music tracks or on block recording capabilities such as, for example, Shadow, Block, and Scheduled Recording. A radio that is Unsubscribed or Suspended can thus ignore the authorization value above, if present, and comply with a Song Recording=Disallowed policy.

Expiration of My Channel Cached Content

In exemplary embodiments of the present invention, content recorded in a My Channel Cache (i.e., songs by favorite artists recorded in the background) can require an expiration and can, for example, automatically be deleted if still present in the Cache n days after originally recorded (where n can be, for example, 30 days or similar). This implies individual tracking of a record date for each track in a My Channel Cache individually. It is noted that a track can still be eliminated before its expiration due to FIFO (or other deletion protocol) movement of newer content into the cache. In exemplary embodiment of the present invention, the n expiration days can, for example, also become a global constant delivered in a data service.

Additional Tiers for Love/My Channel

In exemplary embodiments of the present invention, an additional authorization tier of Love can allow a user to tune away from a recording (Loved) song, and have it continue to record in the background. Similarly, an additional authorization tier for My Channel can, for example, allow the user to directly view and manage the My Channel Cache (i.e. speculatively recorded Favorite Artist Songs).

Blocked Song (“Hate”) Management

In exemplary embodiments of the present invention, the ability can be provided for a user to block specific songs and songs from a channel in user selected Category(s) from being recorded as Favorite Artist Songs for My Channel. This is essentially an opposite functionality to

Exemplary User Interface

FIGS. 1-8, next described, illustrate an exemplary user interface for My Channel and Love functionality, according to an exemplary embodiment of the present invention.
In general, My Channel functionality does not require specific screens over core radio functionality, because the recording of Favorite Artist content occurs in the background, and when playing My Channel the appearance can be nearly identical to playing a “normal” radio channel.
FIG. 1 illustrates the use of a “heart” icon on an exemplary touchscreen UI for invoking an exemplary Love function. While listening to a song that has been identified as a valid candidate for a Loved Song recording, a user can, for example, press the heart icon, starting the recording process. A popup can then, for example, appear, allowing the user to also add the Artist associated with this song to the Favorite Artists list. By default, the checkbox for this functionality can be checked (meaning add this Artist to the list), but if a user wishes to record the song but avoid including this Artist in background My Channel Favorite Artist Song recordings, they can, for example, uncheck the box before selecting OK.
As indicated in FIG. 1, in exemplary embodiments of the present invention, during recording, the heart (“Love” icon) can be animated as if slowly beating, to signify to the user the recording is proceeding. If the user was listening to a track that was not a candidate for Loved Song recording, such as, for example, not a real “song”, subject to Record Restrictions, etc., the heart icon can be grayed out while listening to the song to signify to the user that the particular track cannot be Loved.
FIG. 2 illustrates a prompt that would appear if the user attempts to tune away from the current channel while the Loved recording is still proceeding. Here a user can choose to stay tuned and continue recording, or proceed with the operation that will tune away, but lose the recording.
Once a user begins playing My Channel content, the appearance is very similar to that of playing any live channel, as shown in FIG. 3. In FIG. 3, the only hint on the “now playing” screen that My Channel is playing is the presence of a special icon (see upper right of screen shot) in lieu of a traditional channel icon.
FIG. 4 illustrates entry into the Song Library function, wherein a user can view a list of Loved songs, sorted by Artist or by Song, and select a specific song for play, or, for example, play all songs in this list linearly or in shuffle mode. Once song(s) are playing, presentation can, for example, be very similar to listening to a regular channel (i.e., Artist/Title displayed, etc.)
FIG. 5 depicts use of an action panel associated with a specific song already in the Song Library that can be used, for example, to (a) exclude or include the Artist for that Song as part of the Favorite Artists list and (b) include or exclude that Loved Song from being used in the My Channel playlist.
Similarly, while hearing a song playing in My Channel, FIG. 6 illustrates methods provided for a user to (a) exclude or include the Artist for that Song as part of the Favorite Artists list and (b) include or exclude that Loved Song from being used in the My Channel playlist in the future. Thus, in the left panel of FIG. 6, a user can move to an “Artist” screen (middle image) and form there, using “Edit” move to an Edit screen and include/not include the Artist and/or the Song in My Channel. As shown, Artist and Song default is on. Deselecting the Artist removes the Artist form My Channel Playback. Remove Song, on the other hand, removes only the Song, but not the Artist, from My Channel Playback.
Finally, FIG. 7 illustrates functions available through a product setup function that can, for example, allow a user to quickly edit their cumulative list of Favorite Artists, and indicate whether they want songs from the listed Artists to be recorded for My Channel, or not.
The setup function also provides a list of Loved Songs with checkboxes to include/exclude each song in My Channel Playlists, allowing the user to keep Loved Songs in their Song Library, but exclude them from My Channel use, as shown in FIG. 8, for example.

Exemplary Program Suggestion Algorithms

FIGS. 9-15, next described, illustrate exemplary program suggestion algorithms according to an exemplary embodiment of the present invention. Such exemplary algorithms can utilize various topic, subtopic and affinity data, next described.
In exemplary embodiments of the present invention, the following categories can be defined in a program suggestion engine or module:
Topics—a hierarchical list of major and minor, assignable to each program in the Program Schedule. The topics list can be updated relatively infrequently, with topic assignments to specific programs regularly updated along with Program Schedule updates by programming staff.
Topic Affinities—a Topic “Affinity” indicates whether a listener interested in one Topic might also be interested (or disinterested) in a given other Topic For each Topic “X”, a Topic Affinity Matrix can include a reference to each other Topic “Y” indicating whether a listener who likes Topic “X”, she may also strongly like, somewhat like, or dislike Topic “Y”. This data can be updated by programming staff as needed. In exemplary embodiments of the present invention, such data is used to generate recommendations to users, predict preferences, etc.
Listener Profile Parameters—data used to fine-tune calculations made in the receiver to derive personalized listener profiles. This data can, for example, be updated relatively infrequently.
In exemplary embodiments of the present invention, Topics can provide a two-level hierarchical list of subject matter descriptions for characterizing programs in an exemplary Program Schedule. Major Topics can, for example, be further subdivided into Minor Topics. Examples of a few possible Topics are shown in Table 1, provided as FIG. 9, it being understood that a fully-flushed out topic list can be very large and detailed.

Topic Definitions

In exemplary embodiment of the present invention, various Topics can be defined. Each defined Topic can be designated as either a “Major Topic” or a “Minor Topic.” There can be, for example, 256 Major Topics, and 256 Minor Topics assigned to any single Major Topic. Each Minor Topic thus belongs to a single Major Topic. Each Topic can be assigned a text name, for example, of up to 32 displayable characters. In exemplary embodiments of the present invention, a Topics definition list can be continuously broadcast, carousel style, as part of an Electronic Program Guide (“EPG”) service, for example.

Topic Program Associations

In exemplary embodiments of the present invention, an EPG transmission can include, for example, associations of Topics to selected programs in a Program Schedule. For example, each Program can be associated with up to eight (8) Topics. Though not necessary, Programs can also be tagged with Minor Topics, inasmuch as Minor Topics provide more specificity than Major Topics, which is useful for classifying program content.

Topic Affinity Table

In exemplary embodiments of the present invention, an EPG transmission can include, for example, a Topic Affinity Table, indicating potential “like” and “dislike” relationships between each Topic pair. For each Topic “X”, the Affinity Table can indicate one of the following affinities for each other Topic “Y”:

- Typically Likes (2)—A listener who likes Topic “X” will typically also like Topic “Y”.
- May Like (1)—A listener who likes Topic “X” may also like Topic “Y”.
- Neutral (0)—No strong negative or positive affinity between Topic “X” and Topic “Y”.
- Typically Dislikes (−1)—A listener who likes Topic “X” will typically dislike Topic “Y”.

The resulting Topic Affinity Table can be viewed as a matrix, with Topic identifiers on the X and Y axes, and intersecting cells indicating the affinities between Topic pairs using a numerical value to represent the affinity (such as, as shown above, {2, 1, 0 and −1}). Table 2, provided in FIG. 10, illustrates an excerpt of an exemplary Topic Affinity Table, covering a few example Topics. The four example affinity values {2, 1, 0, and −1} each represent the four exemplary affinities described above, but it is understood that different classification systems, with different numerical affinity values, can be used as may be desired or useful.
It is noted that most of the entries in Table 2 have symmetric relationships (Topic “X” to Topic “Y” is the same as Topic “Y” to Topic “X”). However, in exemplary embodiments of the present invention, asymmetric relationships can also be used such, as for example, Topic “X” to Topic “Y” is different from Topic “Y” to Topic “X”.
In exemplary embodiments of the present invention, this data can be transmitted continuously, as part of an EPG transmission, for example, in a compressed format. In such exemplary embodiments, topic affinities can be established, for example, by system programming staff, or other sources, as a tool for use by receivers to filter and prioritize program suggestions to individual users, as described in Section 4.1 below. Inasmuch as they are based on human psychology, it is understood that these affinities are hardly “absolutes”—there is a wide variation in personal preferences for content and what is considered “similar”. However, they can provide a useful element in algorithms used by a radio to prioritize content suggestions to a user, and to deprioritize suggestions that a user might find inappropriate.
In exemplary embodiments of the present invention, Topic Affinity Table values can, for example, be updated infrequently, such as, for example, when adding or removing Topics, or for fine-tuning the algorithms used to suggest programming alternatives to the end users.

Listener Profile Parameters

In exemplary embodiments of the present invention, an service data transmission, such as, for example, one related to an EPG service, or otherwise, can include a number of parameters used to influence calculations made by receiver software in recommending programs to a user. These can be based on, for example, (i) listening history, (ii) contents of the Program Schedule, and (iii) a Topic Affinity Matrix.
The values of transmitted Listener Profile Parameters, can, for example, be provided in a table, for example, of maximum 2,048 bytes. They can, for example, be modified only when deemed necessary to fine-tune the behaviors of radios implementing “What's Hot Now” suggestions.
Using this data, a program suggestion engine or algorithm can provide, for example, a radio listener with simple access to a short list of program suggestions that have been highlighted by system programming staff and are prioritized based on historical listening habits of the listener. This feature, illustrated in FIG. 10, emphasizes simplicity (access with a button press or two, no user setup required) and personalization (users with different listening histories can receive a different list of suggestions).
Though the technical process behind it may involve multiple steps and calculations, for a listener this feature is very simple: press a button and get personalized suggestions. Thus, in exemplary embodiments, the procedures described below are handled by product software, and are not visible to a listener. In exemplary embodiments of the present invention, broadcast service programming staff can, for example, enter full program data in an EPG Program Schedule, stored in a server. During this regularly repeated task, the programming staff can also, for example, select a number of programs to designate as “Highlighted” and “Featured”, and so tag them in the database. Typically, Highlighted and Featured programs are chosen based on their unique content, wide appeal to many listeners, or deep interest by some groups of the broadcaster's audience.
In exemplary embodiments of the present invention, each program in the schedule can also be associated with one or more Topics, thus characterizing the content of the program, and building the Topic Affinity Table, described above (FIG. 9). This can be done based on, for example, programmer expertise, statistical analyses of user behavior and perceptions, etc., and can further be used to assign positive and negative affinities between Topics. The values in the Affinity Table need not be changed often, as they represent overall Topic affinities, and not specific program affinities.
In exemplary embodiments of the present invention, an Affinity Table can be transmitted to all receivers, where they can be stored for example, in local product memory.
In exemplary embodiments of the present invention, every radio can receive the same Affinity Table. Additionally, each radio or other product supporting program recommendations can, for example, continuously monitor its listening behaviors to build a simple weighted table of relative time spent on the receiver listening to each Topic, based on the Topics assigned to the Programs to which the user listens. (In exemplary embodiments of the present invention, this information need not be sent outside the radio. Rather, it can, for example, be used only internally by the radio software for prioritizing suggestions as described below, thus maintaining strict privacy of the data.)
Thus, a radio listener wishing to get a list of suggestions for alternate programs currently playing can press a button on the radio, such as, for example, a soft button labeled On Now. The radio software can then build a Program Suggestion List containing programs currently playing across all channels, prioritized by an algorithm that considers: (i) Program Highlights and Features established by broadcaster programming staff in the Program Schedule; (ii) the listener's personal and historical Topic preferences, based on listening history and explicit Topic and Preset choices; (iii) Topics assigned to the currently playing programs; and (iv) Topic Affinities.
Such an exemplary list order emphasizes programs Highlighted and/or Featured by programming, while at the same time (i) prioritizing programs most likely to appeal to this listener and (ii) avoiding suggestions most likely to be inappropriate for this listener. The incorporation of Affinity Table information can add program suggestions for channels never sampled by this listener, thus supporting the goal of introducing listeners to content and channels they may not be aware of.
In exemplary embodiments of the present invention, radio software can display the first few programs in a Program Suggestion List. Although processing in the radio software is involved, the user experience is simple: quick access to a personalized list of recommended programs playing right now.
In exemplary embodiments of the present invention, a receiver UI can, for example, allow a user to cycle through the list, or, for example, in a multi-line display just show the first few suggestions. Radios with limited display capability can, for example, present suggestions through techniques such as, for example, (i) temporarily populating a reserved bank of presets or favorites list with channels playing the suggested programs, (ii) using a “scan” feature to preview the suggestions, or (iii) simply cycling through the suggestions with channel up/down while in a “What's Hot” or equivalent mode of operation, for example.
It is noted that although all receivers can use the same Program Schedule and Affinity Table data, the weighting influence of a personalized Listening Preferences Table can result in different suggestions for different listeners, sometimes significantly, thus providing a personalized experience.

SUMMARY

Thus, exemplary PSA code can produce, for example, an ordered list of programming recommendations. PSA client code can, for example, collect various data from the EPG Service and data that describes the listener's habits and preferences. The PSA code can, for example, request this data from the client code via its API as required.
The PSA's goal is accomplished by assigning points to the listener's data. Relative weights are given to each program by adding up these points. This can be done, for example, by relating the listener's data and the program guide data using program topics delivered in the EPG service. To promote new programming discovery for the listener points are given to programs derived from the listener habits and preferences by use of a topic affinity table can be delivered in the EPG service, and then used in exemplary embodiments of the present invention to drive one or more recommendation engines.
Once the programs have a relative weight with each other the PSA can add variety to the top program recommendations. Along with adding variety at least one program highlighted or featured by Sirius XM programming staff is moved near the top of the list if its topics are in the listener's domain of interests.

PSA Control Fields

PSA control fields enables the algorithm to consider (or not to consider) topic elections created from the listener's preset channels, topics chosen from a list, listening times for topics, affinity topics (each degree individually controlled), highlighted and featured programs, topics currently playing and principal selections by the listener. It also controls whether or not the “Add Variety” step is included and how its rules are applied (which rules in which order).

PSA Configuration Fields

The PSA configuration fields sets the number of points used to wait each type of election, provides a nonlinear function for converting or relative topic listening times to points, and defines a set of rules used in the add variety step.

Exemplary Program Suggestion Algorithm (“PSA”)

FIG. 12 illustrates how all playing programs can, for example, provide all playing subtopics; profiles and elections obviously pick playing subtopics; affinity subtopics add related picks to A, B and C; highlighted or featured programs, picked by programming, can emphasize a subset of programs.
In exemplary embodiments of the present invention, the following steps can be performed as part of a PSA:

- 1. A list of all playing programs is created from the Electronic Program Guide.
  - a. The current audible program is excluded from list
- 2. A weighting value in each recommendation for playing programs is set to one (1).
- 3. Any playing subtopic matching the Elected topic list has its election weight added to the recommendation for programs playing this subtopic (area B and C).
  - a. Subtopics from the Channel Presets have an election weight of 1.
  - b. Subtopics purposely chosen by the listener have an election weight of 2.
- 4. Any playing subtopic matching the Profiled subtopic list has its profile weight added to the recommendation for programs playing this subtopic (area A and B).
  - a. Profile weights are based on listening time.
  - b. A non-linear function is used to create profile weights 1-9.
- 5. Using all elected subtopics as keys create a list of affinity subtopics.
  - a. The weight given to each affinity subtopic is determined by the affinity degree and frequency of occurrence.
  - b. Affinity subtopics already in the Elected or Profiled list are discarded.
  - c. The Elected subtopic list is replaced by the just created affinity subtopic list.
- 6. Step 5 is repeated but applied to the Profiled list of subtopics.
  - a. In 5c the Profiled affinity list is joined with the Elected affinity election list.
- 7. Steps 3 and 4 are repeated using the affinity list created in steps 5 and 6.
- 8. The weight of each recommendation is increased by feature and highlight weights of the program it recommends.
  - a. 20 is added for featured programs, moves up list in sort done below.
  - b. 40 is added for highlighted programs, moves up list in sort done below.
  - c. Programs with a recommendation weight of one are skipped in this step.
- 9. Recommendation variety is added to the list by changing weights to minimize topic overlap among the top recommendations and ordering these by various sources (types) of elections.
- 10. The playing program list is now sorted by recommendation weight and presented for selection.

It is noted that all numbers shown in the above exemplary method can be adjustable over the air. Further, in step 9 the degree of overlap and ordering of election sources can be, for example, programmable over the air. Finally, it is noted that the same steps can be applied to other, specific, program suggestion based features, such as, for example, a “What's Hot This Week” or a “What's Hot Now” feature. Each of these can, for example, have their own OTA configuration to control which steps apply and what weights are used.
As shown in FIG. 13, an election of a topic can be, for example, created any time the listener shows an interest in a topic. Thus, a recommendation is a summation of those interests, and a profile entry is a type of election that has a time component.
FIGS. 14 and 15 illustrate exemplary differing recommendations for each of two exemplary users, Frank and Harry. Such recommendations, as shown, can be generated using an exemplary PSA as described above, for example.
The above-presented description and figures are intended by way of example only and are not intended to limit the present invention in any way, except as set forth in the following claims. It is particularly noted that persons skilled in the art can readily combine the various technical aspects of the various elements of the various exemplary embodiments that have been described above in numerous other ways, all of which are considered to be within the scope of the invention.

Claims

What is claimed:

1. A method of providing user-specific content on a device, comprising:

receiving an audio broadcast or content stream on a user device, the broadcast or content stream comprising multiple tracks;

receiving a signal identifying at least one of said tracks for storage;

storing the track in a library in non-volatile memory; and

providing a user with the ability to play back the track on demand.

2. The method of claim 1, wherein said tracks include individual songs, larger programs, events, and concerts, and wherein said individual songs are stored in a song library, and all other tracks are stored in a program library.

3. The method of claim 2, wherein each of the song library and the program library can be stored in one of host memory and module memory.

4. The method of claim 1, wherein said providing the user with playback ability includes at least one of playing library contents in some randomized or fixed order, and offering full playlisting and navigation of library content so that a user can control playback order.

5. The method of claim 2, further comprising providing a user the ability to manage the contents of the song library and program library.

6. The method of claim 1, wherein the user is provided the ability to play back the track via an interactive user interface.

7. A method of providing user-specific content on a device, comprising:

receiving a signal identifying at least one of said tracks for storage;

storing the track in a library in non-volatile memory; and

creating a randomized playlist that mixes said stored tracks from the library with additional tracks speculatively recorded by the user device;

making available the randomized playlist to a user as a personalized channel.

8. The method of claim 7, wherein said speculatively recorded tracks comprise a mix of songs all by artists that a user has previously indicated as a favorite artist.

9. The method of claim 7, where a user can choose, via a user interface, to deselect an artist or song from inclusion in the personal channel.

10. The method of claim 7, wherein said speculatively recorded tracks are chosen using a program suggestion algorithm.

11. The method of claim 10, wherein said program suggestion algorithm chooses songs and artists based on a user's preferences or inferred preferences.

12. The method of claim 10, wherein said program suggestion algorithm utilizes a division of audio content into topics and subtopics.

13. The method of claim 12, wherein said program suggestion algorithm seeks to maximize affinities as to at least one of topics and subtopics between said speculated recordings and tracks in the library.

14. The method of claim 2, wherein when the song library is full, a user is notified to delete songs.

15. The method of claim 2, wherein when the song library is full, and a user identifies a new track for storage, an existing song is automatically deleted to make room for the new track.

16. The method of claim 15, wherein said existing song is chosen on at least one of a FIFO basis and a ranking based on user preferences.

17. The method of claim 2, wherein if a signal is received to record a track that has already been recorded in the Library, the receiver can replace the old recording with the new, thus reducing the aging of that song to the present.

18. The method of claim 1, wherein said signal identifying at least one of said tracks for storage can be generated by at least one of a user, a receiver resident algorithm, and metadata received from a content provider.