Tuesday, 6 March 2012

Tag Channels for Follow-up / Sticky EPG (2007)


This was an idea I had back in 2007 which coincidentally was shared by two other colleagues. We collaborated on the the concepts and jointly submitted the idea through the patents process. Unfortunately, having invested a lot of time and energy into fleshing out the patent proposal, and reviewing counter claims -- it was decided that there was enough prior art to nullify the patent application, i.e. the concept was considered a natural evolution of existing features.

Nevertheless, five years down the line, and I have yet to see this feature implemented in any form of user experience in the real world, particularly the satellite Set-Top-Box decoders. For the IP and Internet TV space, there is the concept of bookmarks, but I still haven't seen the concept implemented as I envision it.  I've worked with EPG UI Application development for some years now, and from the basic to the most advanced state-of-the-art, the closest feature remotely related to this idea is that of Favourite Channels.  But I'm pretty sure there must be an IPTV app around that exposes this idea, to be honest, I've not done an in-depth search to verify...

Here's the idea in a nutshell:
Posted: 18 July 2007 Tag Channels for Follow-up
Some users start channel surfing from the first available channel till the last channel, spanning all the channels - in the hope of finding something useful to watch. For each channel that seems interesting to follow up, the user tries to remember it - to get back to it - after completing the search.

It's often the case that the user would forget which channels were interesting, and at times, by the time it took to complete the search, and jumping back to what seemed to be interesting - the event would have finished.

Wouldn't it be nice to allow a channel to be tagged as ''interesting to follow up'' similar to Outlooks ''Mark for follow-up'' on email. When the user finishes the search, he/she could then bring up the list of channels for ''follow-up''. This will be the subset of channels he/she may be interested (yes, you have a way of setting favorites - but this usage scenario is transient - just for one instance).

Wouldn't it be nice if all these channels were being recorded in the background so the you don't miss out the stuff that for following up?

Realistically the box is limited to the number of tuners, and transponders carrying the channels as well - but don't limit this to broadcast - this feature will be possible in the IP-domain, there is no restriction on physical tuners - in the IP-world you can tune and record as many channels as you like.

Then end result could be a mosaic generated for the tagged channels - allowing the user to switch between channels, etc - all with confidence that your items for follow-up are being recorded and will be available for you to consume at your leisure...


Snippets of Patent Application

Background including Known Relevant References:

The invention is in the area of digital TV and the use of the Electronic Program Guide (EPG) and the problem of channel selection from a set of hundreds of available services. The area includes using the following EPG features:
1.      Selecting a television service to watch from a list that is greater than can be shown on a screen at once.
2.      Selecting a television service to watch after having browsed each channel in turn through channel surfing from the first channel, to the last available channel.

Most set top boxes provide a mechanism whereby a list of favourite services is maintained from which the user may select one that could offer entertainment. The user is left to make his selection based on historic performance, i.e. what has been shown on that service in the past – it does not show what that service is currently showing now, or indeed over the next few hours.

In addition, the use of a favourite list restricts the user to a choice of previously selected services – a subset of what is currently available. Thus, favourite lists are static, related to services, although those services themselves may not be showing something interesting that would be worth watching.

The Problem:

When settling down to watch television, or listen to the radio over digital TV, there are is a lot of choice(just over a thousand channels nowadays), certainly more services than can be examined at a time.
The typical scenario for searching for something to watch now, is to use one of the following:
  1. Using the EPG feature of channel listings (example, a Program Guide), one starts from the beginning (say channel 101) and browses till the end (say channel 999) to find a channel that is interesting that is worth following up.
  2. By channel changing in turn (from 101 to 999), spending about 1-3 minutes on the channel, to gauge the channel’s content.

As I am unlikely to see a service that I *must* watch, I will want to search through all available channels first, and then make a selection from those services that I *might* watch (or follow-up on). However, by the time I have reached the end of the search of services, I can no longer remember what the acceptable choices were, and the associated channel numbers!

For example, when looking for something to watch, a possible candidate is the BBC 1 News. But I’ll keep looking, and see if there is a Schwarzenegger film with a high body count. While looking for that, I’ll see a re-run of the definitive Sherlock Holmes series with Jeremy Brett. But I’ve seen them all, so it’s only a ‘maybe’. And so on, until I reach the end of my search, by which time I have no idea of what the choices were, or where to find them, or indeed what the channels or channel numbers were.

The Solution in Brief:

Two approaches for solving the two use cases must be considerd, that will ultimately solve the problem of going back to the list of channels that should be followed up to watch:
  1. Using the EPG grid, that usually displays a program guide consisting of channel listings: By selecting a service in a particular manner (e.g. pressing the purple button while the service is highlighted), it becomes ‘sticky’, always staying on the screen. The other services scroll around it, as the list is navigated. Further services can be selected in the same manner, also remaining on the screen, up to a limit imposed by the number of services that can be displayed on a single screen. Once I reach the end of the list of services, I have a list of services, all of which I might want to watch. I can now select what I consider to be the most interesting.
  2. During the channel surfing (from first to last channel), use special buttons (e.g. pressing the purple button whilst tuned to the channel), the STB “tags” the channel for follow-up, adding it to its “sticky” list in memory. Once I have channel changed to the last channel, I use another special button (e.g. pressing the yellow key) that will present the list of channels I’ve marked for follow-up. The presentation can be similar to the list generated in 1).

The Solution in Detail:

1) Solution for navigating the EPG listings

When the EPG displays a list of services to the user, make one of the remote control keys (e.g. the blue button) into the ‘sticky select’ key.
Consider the list of services displayed on screen to be made up of two lists, displayed one after another on the screen. The second list is scrolled up and down as normal; the first list always occupies the top N locations on the screen. Initially, the first list has zero entries, and the second list has as many entries as can be displayed on the screen (say 8). Behaviour is thus exactly the same as the normal EPG.
When the ‘sticky select’ key is pressed, the currently highlighted service is moved to the first free position in the first list (currently top of screen), and the services in the list above this moved down one. This implementation causes the selected service to appear to be shuffled to the top of screen. The first list now has 1 entry, the second list 7. As the user scrolls through more services, only the 7 lower services scroll – the top service stays put.
‘Sticky select’ another service. This service moves to the second position in the first list, other services move down one line. The first list now has two elements, which stay on the screen, while the user scrolls through the rest of the service list, displaying 6 at a time. Repeat as necessary.
Once the user has viewed the list of all services, he has a selection of services that he might like to watch. Pressing another key on the remote control (say the yellow button), moves the highlight to the sticky list. The user moves up/down in the list by the up/down keys, selects a service by means of the ‘select’ button (which then tunes the STB to the service in the usual manner), or unsticks the service by pressing the blue button, to drop this service from the sticky list. Pressing the yellow button takes the user back to the non-sticky scrolling list.

2) Solution for channel changing (ie. Tune to channel, watch for a short while, tag for follow-up)
The scenario is that one would start from the first channel, surf to the last available channel, tagging a channel (by pressing a special key e.g. purple key) for follow up as desired. Once finished, one then hits another key (e.g. yellow key) to view the list of channels that were tagged or “sticky”.
Because this process is a dynamic and the generation of the stick list is transient, the STB would maintain a cache in volatile memory of all the channels that were tagged. When the STB is powered on, the cache is empty. The cache is built, and updated each time a channel is tagged. If the channel has been tagged before, the STB could either ignore this channel (as it’s already in the cache) or remove the channel from the cache. Alternatively, the user could be asked to confirm deletion. Alternatively, by pressing the blue button, the user is able to untag or “unstuck” the service. This usage scenario should be easily customized via one of the EPG setup menus.
The cache is basically a structure that would contain all information required for the STB to remember the channel details. Usually these details are easily obtained through the STB middleware API, and may vary according to the type of digital TV environment. For example, for systems in the DVB domain, this would typically include all Transport stream data relevant for channel tuning (network triple, delivery descriptor, service descriptors) – and for DirecTV DSS systems in the US, typically APG data. The cache would typically be controlled by the underlying middleware, and could be realized using the existing mechanism of service list database, with the addition of a new flag that marks the service as Sticky. A typical EPG application could then use a simple interface like “Get number of Stick Services” to which the middleware will return the number of sticky services marked. The EPG would then iterate through the number of sticky services, and for each service returned, display the results in the list accordingly. This mechanism of list generation and display is already widely used in STB EPG/Middleware code, and would be relatively straightforward enhancement to this mechanism – making it possible to be realized in past, present and future STB EPGs.


Points of Novelty that go Beyond the Known Relevant References:

This mechanism permits the user to make an informed decision from a small number of nearly equally acceptable choices, in a manner easily integrated into the normal functioning of the STB user interface.
The novelty includes the generation and display of the “sticky list”. On the basic solution would be typlical list displayed on screen, similar to the usual EPG listings.

Possible Novelty Enhancements linked to the basic idea of Sticky Lists
A more advanced novelty is that the STB now has knowledge of the interest channels and can then decide to intelligently record these services in the background. Recording these services in the background ensures the viewer wouldn’t miss out on anything whilst searching for channels to watch. Moreover, it’ll offer enormous benefits to the user knowing that two channels interesting, and the user wouldn’t have to choose between the two, as the channels are being recorded. If the channels are being recorded, then the “sticky list” that’s generated by pressing the said key, could be displayed as a mosaic of services, with video thumbnails of the subset of “sticky services” – not much dissimilar from a mosaic channel, but only this time – this mosaic is dynamic, and generated by the STB in realtime, and by the STB itself, and not displayed by the headend.

No comments:

Post a Comment