EP2656178A1

EP2656178A1 - My channel recommendaton feature

Info

Publication number: EP2656178A1
Application number: EP11851938.8A
Authority: EP
Inventors: Kenneth Alan RUDMAN; Samir M. AHMED; Basil BADAWIYEH; Dana Shawn FORTE; Gregory David GUDORF; Emmanuel B. SANGALANG
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2010-12-22
Filing date: 2011-12-16
Publication date: 2013-10-30
Also published as: JP2014505412A; KR20140005926A; JP5933588B2; EP2656178A4; CN103270472A; WO2012087825A1

Abstract

The disclosed methods and systems are related to providing programming recommendations for a user that are time and/or contextually specific. i.e. "What type of programming would user A watch at 9-12 pm on a Thursday" instead of the more generic "What type of programming would user A watch." In addition, the present invention is capable of providing recommendations that consist of non-scheduled content. Non-scheduled content refers to content that is not part of a providers programming schedule (i.e. shows and movies shown at a specific scheduled time). Examples of non-scheduled content include, but are not limited to, previously recorded content (such as shows or movies on a DVR), video on demand (VOD), over the top services (such as streaming services Netflix, Hulu, Vudu, Pandora, etc.), stored content (such as movies, music, or photos), and web sites.

Description

MY CHANNEL RECOMMENDATION FEATURE

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Serial No. 61/459,988 filed December 22, 2010, which is incorporated by reference herein in its entirety.

Background

Technical Field

The present invention generally relates to personalization features, and more particularly program recommendations.

Description of Related Art

Traditional program recommendations don't provide recommendations that are time and/or contextually specific. That is, traditional program recommendations suggest types of programs (e.g. sports, documentary, science fiction) or channels (ESPN, Discovery, Syfy) to watch. They do not recommend what is the best choice for a user for a particular time period, i.e. "what is the best thing for the user to watch at 9 pm"

Previous recommendation systems track the type of programs and/or channels watched by a user and makes recommendation for related programming of the same type, genre, subject matter, actor, etc. regardless of when the programming is on. For example, DVR systems often have a feature that allows the DVR to fill up empty space on the DVR with recommended programs that are similar to programs that were watched, recorded, and/or rated by the user. However, previous systems do not take into account when the programming was watched or when the user would want to watch recommended programming.

Summary

The invention is related to the idea of providing programming recommendations for a user that are time and/or contextually specific, i.e., "What type of programming would user A watch at 9-12 pm on a Thursday?" instead of the more generic "What type of programming would user A watch?" In addition, the present invention is capable of providing recommendations that consist of non-scheduled content. Non-scheduled content refers to content that is not part of a providers programming schedule (i.e. shows and movies shown at a specific scheduled time). Examples of non-scheduled content include, but are not limited to, previously recorded content (such as shows or movies on a DVR), video on demand (VOD), over the top services (such as streaming services Netflix, Hulu, Vudu, Pandora, etc.), stored content (such as movies, music, or photos), and web sites.

In accordance with one aspect a method for providing viewing recommendations for a user is disclosed. The method involves collecting usage data including the time and context information regarding content viewed by user, processing the user data, and providing one or more recommendations based on time and context information. In addition, at least one of the provided recommendations comprises non-scheduled content. .

In accordance with another embodiment a system for providing viewing

recommendations for a user is disclosed. The system includes a front end and a back end. The front end is configured to collect usage data including the time and context information regarding content viewed by user. The back end is configured to process the user data and provide one or more recommendations based on time and context information, wherein at least one of the provided recommendations comprises non-scheduled content.

Brief Description of the Drawings

Figure 1 is a system diagram outlining the delivery of video and audio content to the home in accordance with one embodiment.

Figure 2 is system diagram showing further detail of a representative set top box receiver.

Figure 3 is a diagram depicting a touch panel control device in accordance with one embodiment.

Figure 4 is a diagram depicting some exemplary user interactions for use with a touch panel control device in accordance with one embodiment.

Figure 5 is a flow diagram depicting an exemplary process in accordance with one embodiment.

Figure 6 is a flow diagram depicting an exemplary process in accordance with one embodiment. Figure 7 is an exemplary screen view depicting a user interface in accordance with one embodiment.

Detailed Description

Turning now to FIG. 1, a block diagram of an embodiment of a system 100 for delivering content to a home or end user is shown. The content originates from a content source 102, such as a movie studio or production house. The content may be supplied in at least one of two forms. One form may be a broadcast form of content. The broadcast content is provided to the broadcast affiliate manager 104, which is typically a national broadcast service, such as the American Broadcasting Company (ABC), National

Broadcasting Company (NBC), Columbia Broadcasting System (CBS), etc. The broadcast affiliate manager may collect and store the content, and may schedule delivery of the content over a deliver network, shown as delivery network 1 (106). Delivery network 1 (106) may include satellite link transmission from a national center to one or more regional or local centers. Delivery network 1 (106) may also include local content delivery using local delivery systems such as over the air broadcast, satellite broadcast, or cable broadcast. The locally delivered content is provided to a receiving device 108 in a user's home, where the content will subsequently be searched by the user. It is to be appreciated that the receiving device 108 can take many forms and may be embodied as a set top box/digital video recorder (DVR), a gateway, a modem, etc. Further, the receiving device 108 may act as entry point, or gateway, for a home network system that includes additional devices configured as either client or peer devices in the home network. A second form of content is referred to as special content. Special content may include content delivered as premium viewing, pay-per-view, or other content otherwise not provided to the broadcast affiliate manager, e.g., movies, video games or other video elements. In many cases, the special content may be content requested by the user. The special content may be delivered to a content manager 1 10. The content manager 110 may be a service provider, such as an Internet website, affiliated, for instance, with a content provider, broadcast service, or delivery network service. The content manager 110 may also incorporate Internet content into the delivery system. The content manager 110 may deliver the content to the user's receiving device 108 over a separate delivery network, delivery network 2 (112). Delivery network 2 (112) may include high-speed broadband Internet type communications systems. It is important to note that the content from the broadcast affiliate manager 104 may also be delivered using all or parts of delivery network 2 (112) and content from the content manager 110 may be delivered using all or parts of delivery network 1 (106). In addition, the user may also obtain content directly from the Internet via delivery network 2 (112) without necessarily having the content managed by the content manager 110.

Several adaptations for utilizing the separately delivered content may be possible. In one possible approach, the special content is provided as an augmentation to the broadcast content, providing alternative displays, purchase and merchandising options, enhancement material, etc. In another embodiment, the special content may completely replace some programming content provided as broadcast content. Finally, the special content may be completely separate from the broadcast content, and may simply be a media alternative that the user may choose to utilize. For instance, the special content may be a library of movies that are not yet available as broadcast content.

The receiving device 108 may receive different types of content from one or both of delivery network 1 and delivery network 2. The receiving device 108 processes the content, and provides a separation of the content based on user preferences and commands. The receiving device 108 may also include a storage device, such as a hard drive or optical disk drive, for recording and playing back audio and video content. Further details of the operation of the receiving device 108 and features associated with playing back stored content will be described below in relation to FIG. 2. The processed content is provided to a display device 114. The display device 114 may be a conventional 2-D type display or may alternatively be an advanced 3-D display.

The receiving device 108 may also be interfaced to a second screen such as a touch screen control device 116. The touch screen control device 116 may be adapted to provide user control for the receiving device 108 and/or the display device 114. The touch screen device 116 may also be capable of displaying video content. The video content may be graphics entries, such as user interface entries, or may be a portion of the video content that is delivered to the display device 114 The touch screen control device 116 may interface to receiving device 108 using any well known signal transmission system, such as infra-red (IR) or radio frequency (RF) communications and may include standard protocols such as infra-red data association (IRDA) standard, Wi-Fi, Bluetooth and the like, or any other proprietary protocols. Operations of touch screen control device 116 will be described in further detail below.

In the example of Figure 1, the system 100 also includes a back end server 118 and a usage database 120. The back end server 118 includes a personalization engine that analyzes the usage habits of a user and makes recommendations based on those usage habits. The usage database 120 is where the usage habits for a user are stored. In some cases, the usage database 120 may be part of the back end server 118 a. In the present example, the back end server 118 (as well as the usage database 120) is connected to the system the system 100 and accessed through the delivery network 2 (112).

Turning now to FIG. 2, a block diagram of an embodiment of a receiving device 200 is shown. Receiving device 200 may operate similar to the receiving device described in FIG. 1 and may be included as part of a gateway device, modem, set-top box, or other similar communications device. The device 200 shown may also be incorporated into other systems including an audio device or a display device. In either case, several components necessary for complete operation of the system are not shown in the interest of conciseness, as they are well known to those skilled in the art.

In the device 200 shown in FIG. 2, the content is received by an input signal receiver 202. The input signal receiver 202 may be one of several known receiver circuits used for receiving, demodulation, and decoding signals provided over one of the several possible networks including over the air, cable, satellite, Ethernet, fiber and phone line networks. The desired input signal may be selected and retrieved by the input signal receiver 202 based on user input provided through a control interface or touch panel interface 222. Touch panel interface 222 may include an interface for a touch screen device. Touch panel interface 222 may also be adapted to interface to a cellular phone, a tablet, a mouse, a high end remote or the like. The decoded output signal is provided to an input stream processor 204. The input stream processor 204 performs the final signal selection and processing, and includes separation of video content from audio content for the content stream. The audio content is provided to an audio processor 206 for conversion from the received format, such as compressed digital signal, to an analog waveform signal. The analog waveform signal is provided to an audio interface 208 and further to the display device or audio amplifier. Alternatively, the audio interface 208 may provide a digital signal to an audio output device or display device using a High-Definition Multimedia Interface (HDMI) cable or alternate audio interface such as via a Sony/Philips Digital Interconnect Format (SPDIF). The audio interface may also include amplifiers for driving one more sets of speakers. The audio processor 206 also performs any necessary conversion for the storage of the audio signals.

The video output from the input stream processor 204 is provided to a video processor 210. The video signal may be one of several formats. The video processor 210 provides, as necessary a conversion of the video content, based on the input signal format. The video processor 210 also performs any necessary conversion for the storage of the video signals.

A storage device 212 stores audio and video content received at the input. The storage device 212 allows later retrieval and playback of the content under the control of a controller 214 and also based on commands, e.g., navigation instructions such as fast- forward (FF) and rewind (Rew), received from a user interface 216 and/or touch panel interface 222. The storage device 212 may be a hard disk drive, one or more large capacity integrated electronic memories, such as static RAM (SRAM), or dynamic RAM (DRAM), or may be an interchangeable optical disk storage system such as a compact disk (CD) drive or digital video disk (DVD) drive.

The converted video signal, from the video processor 210, either originating from the input or from the storage device 212, is provided to the display interface 218. The display interface 218 further provides the display signal to a display device of the type described above. The display interface 218 may be an analog signal interface such as red- green-blue (RGB) or may be a digital interface such as HDMI. It is to be appreciated that the display interface 218 will generate the various screens for presenting the search results in a three dimensional gird as will be described in more detail below.

The controller 214 is interconnected via a bus to several of the components of the device 200, including the input stream processor 202, audio processor 206, video processor 210, storage device 212, and a user interface 216. The controller 214 manages the conversion process for converting the input stream signal into a signal for storage on the storage device or for display. The controller 214 also manages the retrieval and playback of stored content. Furthermore, as will be described below, the controller 214 performs searching of content and the creation and adjusting of the gird display representing the content, either stored or to be delivered via the delivery networks, described above.

The controller 214 is further coupled to control memory 220 (e.g., volatile or nonvolatile memory, including RAM, SRAM, DRAM, ROM, programmable ROM (PROM), flash memory, electronically programmable ROM (EPROM) , electronically erasable programmable ROM (EEPROM), etc.) for storing information and instruction code for controller 214. Control memory 220 may store instructions for controller 214. Control memory may also store a database of elements, such as graphic elements containing content. The database may be stored as a pattern of graphic elements. Alternatively, the memory may store the graphic elements in identified or grouped memory locations and use an access or location table to identify the memory locations for the various portions of information related to the graphic elements. Additional details related to the storage of the graphic elements will be described below. Further, the implementation of the control memory 220 may include several possible embodiments, such as a single memory device or, alternatively, more than one memory circuit communicatively connected or coupled together to form a shared or common memory. Still further, the memory may be included with other circuitry, such as portions of bus communications circuitry, in a larger circuit. The user interface process of the present disclosure employs an input device that can be used to express functions, such as fast forward, rewind, etc. To allow for this, a touch panel device 300 may be interfaced via the user interface 216 and/or touch panel interface 222 of the receiving device 200, as shown in FIG. 3. The touch panel device 300 allows operation of the receiving device or set top box based on hand movements, or gestures, and actions translated through the panel into commands for the set top box or other control device. In one embodiment, the touch panel 300 may simply serve as a navigational tool to navigate the gird display. In other embodiments, the touch panel 300 will additionally serve as the display device allowing the user to more directly interact with the navigation through the grid display of content. The touch panel device may be included as part of a remote control device containing more conventional control functions such as activator buttons. The touch panel 300 can also includes at least one camera element.

Turning now to FIG. 4, the use of a gesture sensing controller or touch screen, such as shown, provides for a number of types of user interaction. The inputs from the controller are used to define gestures and the gestures, in turn, define specific contextual commands. The configuration of the sensors may permit defining movement of a user's fingers on a touch screen or may even permit defining the movement of the controller itself in either one dimension or two dimensions. 2-dimensional motion, such as a diagonal, and a combination of yaw, pitch and roll can be used to define any 4-dimensional motion, such as a swing. A number of gestures are illustrated in FIG. 4. Gestures are interpreted in context and are identified by defined movements made by the user.

Bumping 420 is defined by a two-stroke drawing indicating pointing in one direction, either up, down, left or right. The bumping gesture is associated with specific commands in context. For example, in a TimeShifting mode, a left-bump gesture 420 indicates rewinding, and a right-bump gesture indicates fast-forwarding. In other contexts, a bump gesture 420 is interpreted to increment a particular value in the direction designated by the bump. Checking 440 is defined as in drawing a checkmark. It is similar to a downward bump gesture 420. Checking is identified in context to designate a reminder, user tag or to select an item or element. Circling 440 is defined as drawing a circle in either direction. It is possible that both directions could be distinguished. However, to avoid confusion, a circle is identified as a single command regardless of direction. Dragging 450 is defined as an angular movement of the controller (a change in pitch and/or yaw) while pressing a button (virtual or physical) on the tablet 300 (i.e., a "trigger drag"). The dragging gesture 450 may be used for navigation, speed, distance, time-shifting, rewinding, and forwarding. Dragging 450 can be used to move a cursor, a virtual cursor, or a change of state, such as highlighting outlining or selecting on the display. Dragging 450 can be in any direction and is generally used to navigate in two dimensions. However, in certain interfaces, it is preferred to modify the response to the dragging command. For example, in some interfaces, operation in one dimension or direction is favored with respect to other dimensions or directions depending upon the position of the virtual cursor or the direction of movement. Nodding 460 is defined by two fast trigger-drag up-and- down vertical movements. Nodding 460 is used to indicate "Yes" or "Accept." X-ing 470 is defined as in drawing the letter "X." X-ing 470 is used for "Delete" or "Block" commands. Wagging 480 is defined by two trigger-drag fast back-and-forth horizontal movements. The wagging gesture 480 is used to indicate "No" or "Cancel."

Depending on the complexity of the sensor system, only simple one dimensional motions or gestures may be allowed. For instance, a simple right or left movement on the sensor as shown here may produce a fast forward or rewind function. In addition, multiple sensors could be included and placed at different locations on the touch screen. For instance, a horizontal sensor for left right movement may be placed in one spot and used for volume u/down, while a vertical sensor for up down movement may be place in a different spot and used for channel up/down. In this way specific gesture mappings may be used. Figure 5 depicts a flow diagram 500 of the process involved in providing

recommendations as described in this disclosure. The process involves collecting or obtaining usage data (step 510), processing the user data (step 520), and providing recommendations (step 530). Each of these steps will be discussed in more detail below. Pursuant to the first step of figure 5, data regarding the usage habits of a user is collected. The usage information can include information collected from the receiving device 108 and the touch screen control device 116. The type of information collected may include channels watched on the display device 114, the time the channels where watched, how long the channel was watched, the type of program on the channel, information about the program watched (e.g. genre, director, actor, etc.); what was viewed on the touch screen control device 116 (i.e. program guide, additional program information, websites, applications, etc.); what time content was viewed on the touch screen control device 116, how long the content was viewed, and information about the content watched (type of content, genre, etc.). Table 1 provides some examples of the types of usage data collected via the touch screen control device.

Table 1

Once usage data is collected (step 510), the usage data is provided to the back end server 118 where it can be processed (step 520) to build a user profile. By knowing what the user watches as well when and for how long, it is possible to map the user's usage habits. For this particular invention, knowing the temporal aspects of a user usage habits are of particular importance for the desired programming recommendation is time specific In other words, it is important to know what a user prefers to watch at particular time in order to provide a programming recommendation for that particular time. The collected user data, well as user profiles, are stored in the usage database 120.

The following properties are sent via user activity logging and will be used to calculate the contents of the MyChannel application.

View Content Start Action/View Content End Action

Timestamp

Household ID User ID

Device ID

Session ID

Application ID

Channel ID

Once the collected data is processed (step 520), the resulting user profile can be used to provide programming recommendations (step 530). For example, the system could recommend what a particular user should watch at a particular time. One example of the process involved in providing such a recommendation can be seen below in Figure 6.

In the example of Figure 6, the recommendation is performed at the back end server 118 in response to a request from a front end device such as the receiving device 108. The logic for the process (600) of Figure 6 is the following:

1. The front end calls the RESTful service (610) with the userld and optional date/time .

2. For the sake of examples, let's take userld = "A" and the current date/time request is on 11/23/2010 1 :30 AM.

3. The backend (620) tries to formulate the more effective "priority" time the "MyChannel" item lineup should start with. In this case, since the time was requested after the 16^th minute of the hour, the priority will be based on the next hour, "2:00 AM." However, since the viewer would probably want to watch something before then, the application would try to find a program that will best fit the priority start time by looking for a program that starts at "1 :00 AM." It will then try to examine if the program it found would end at "2:00 AM" based on the viewing history of the user.

a. A viewing history is referred to as the list of content (in this case channels) the viewer had watched in the past for that particular time block. A time block is thirty minute interval, starting with midnight as the first block. The last viewing block of a day will be on "23:30" or "11 :30 PM." Logically, there are forty-eight (48) logical time blocks in a day. History for the same time block is not exactly the same for two different days of the week. For example, the information of the viewing history of a user for "1 :00 AM" on Monday is not aggregated with the viewing history of the user for Tuesday. However, the following Monday will be aggregated with whatever data for the day is already in the database. For example:

The user watched: Channel A on 11/8/2010 for ten (10) minutes at "1 :05 AM" and the same channel on 11/15/2010 for another ten (10) minutes at "1 : 10 AM." The history will contain information about the user, watching "Channel A" for twenty (20) minutes from "1 :00 AM to 1 :30 AM." History is only recorded if the viewer has stayed on the channel for more than a specified amount of time. At this point, the configuration is at five (5) minutes.

If a user has watched a content (in this case a sows on channel) for more than the thirty (30) minute time block, the history is aptly divided to the different time blocks involved in the viewing experience. For example, if the user has watched Channel A from 1 :15 AM to 2:00 AM, two records will be generated for the viewing history. Fifteen (15) minutes for the time block from 1 :00 AM to 1 :30 (exclusive) AM and the next time block, 1 :30 AM to 2:00 AM (exclusive). The user must do something before the "n" number of hour(s) lapses. In this example, the application is configured to allow for only two (2) hours of inactivity. The reasoning behind it is that inactivity for two hours might mean the user has slept in front of the TV and that it may not be the intent of the viewer to affect his/her history should they fall asleep or leave the TV on with the same channel for long hours.

If the channel found in Step 3 is airing/broadcasting a program that will end before or at 1 :30, it tries to find another program that will start at 1 :30 and end at 2:00 AM.

The application keeps on trying to find a schedule that will match the criteria until it has exhausted all possibilities in the schedule of the provider (or history has run out). History is derived from the viewing history by returning the channel for the time block with the most number of minutes as the top of the list and works its way down to the channel with the least number of viewing minutes for the user.

a. The history starts off by looking at the viewing history of the user b. If no history is found with the user, it tries to aggregate the viewing history of the household for that particular time block

c. If nothing can be derived from the user and household, it will use the general public's aggregated result to figure out the viewing history. d. The application calls the EJBs (630) in subscriber for the history of the user, household and general public.

When calculating for the next item on the list of "MyChannel," the application figures out the "end time" of the program it selected and tries to associate that particular "end time" to a time block. For example, if in "Step 3," the application found a program that ends at 2:45 AM, it will try to find the viewing history of the user for the time block between "2:30 AM" and "3:00 AM." It will try to find a program according to the history that will start at "2:45 AM." If none is satisfied, it will add thirty minutes to the "end time" of the current program and round it up to the next full thirty minute block. (So, in the example of "2:45 AM," it will add adjust it to "3: 15 AM" and round it up to "3:30 AM.") The logic is currently being tested for "round up first" and adjust appropriately. For example, with "2:45 AM," it will round it up to "3:00 AM." Because it's a full hour block, it will not add another thirty (30) minutes to search for the next start time. Another thirty (30) minutes will be added if there are no programs found that starts at "3:00 AM" according to the viewing history. In this case, the last program is extend up to the next calculated start time.

Rounding up of time occurs with the following logic

a. If minutes less than 30 minutes after the hour, it is rounded off to the 30^th minute of the hour. For example: "1 : 15 AM" is rounded off to "1 :30 AM."

b. If the minutes of the hour is more than 30 minutes after the hour, it is rounded off to the next hour. "1 :45 AM" is rounded off to "2:00 AM." c. If the current time is exactly on the zero minute or 30^th minute of the hour, it is not rounded up.

Having determined the channel ID and time block, the application can then search Catalog Web Services (640) for the current broadcasting program for the provider. The information about the channel is retrieved by invoking catalog service's "getTvGuideByProgramServiceld." It will return a list of content being aired at a particular time. It is examined for the first content that is available in its list. That content's information is further examined by making a call to, "getContentlnformation" into catalog.

The same step is repeated until five (5) or "n" number of programs (as requested by the front end application) is satisfied. The total aggregated duration of the programs returned should also satisfy at least two (2) hours or "x" number of hours (as requested by front end application). The resulting recommendation can then be provided back to the front end such as the receiving device where it can be displayed to the user on the display device 114 or the touch screen control device 116. For example, the recommendation provided by the process set forth above in Figure 6 could be displayed to the user on the touch screen control device as shown in Figure 7.

In this example, the screen 700 shows recommendation was based on the current time and the user. The returned recommendation included recommended programs for the current time slot (710) as well as the next four time slots (720-750). In this example, additional information (760) about each of the recommended program is also provided.

It should be understood that although the present example just recommended scheduled content (i.e. television shows) the recommended content should also include non-scheduled content such as recorded programs, on demand programming, streaming content, music, websites, or the like, as well any combination thereof. For example, the recommendation for 10:00 am could be a program previously recorded on the system while the 11 :00 am recommendation is another live television program with the 12 and 1 time period recommendations are a movie available on demand.

In certain implementations, certain types of programming can be given preference over others (i.e. "free content" over "pay" content or vice versa, television over internet content, etc.). In other embodiments, a spending limit or "wallet" concept could be used to limit the amount of "pay" content is recommended. Similarly, bandwidth limits may also be used for downloaded, streamed, or web content recommendation.

Additionally, the window of time for recommendation is not limited to 4 hours or four programs but can be smaller or larger as desired. In other implementations, the shown time window may be sliding such that a user can see recommendation further out than the next four hours. In still other implementations the user may be provide with an option to record provided recommendations. Season pass type recording options may also be provide that don't require specific program designation (i.e. always record

recommendations for Thursdays 9-10) While the example set forth above has focused on an electronic device, it should be understood that the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which, when loaded in a computer system, is able to carry out these methods. Computer program or application in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduction in a different material form.

Additionally, the description above is intended by way of example only and is not intended to limit the present invention in any way, except as set forth in the following claims.

Claims

CLAIMS:

1. A method of providing viewing recommendations for a user, the method comprising:

collecting usage data including the time and context information regarding content viewed by user;

processing the user data; and

providing one or more recommendations based on time and context information;

wherein at least one of the provided recommendations comprises non- scheduled content.

2. The method of claim 1, wherein the non-scheduled content is selected from the group comprising:

stored content;

web-sites;

over-the-top service content;

video on demand content; and

downloadable content.

3. The method of claim 2, wherein the stored content is selected from the group comprising:

locally stored content; and

remotely stored content.

4. The method of claim 1, wherein the time and context information comprises at least one of: user, length of viewing, time of day, day, month, year, content name, content type, content source, content genre, length of content, and cast and crew data.

5. The method of claim 1, wherein the step of collecting usage data including the time and context information regarding content viewed by user is performed by a front end.

6. The method of claim 5, wherein the front end comprises a touch screen control device.

7. The method of claim 5, wherein the front end comprises a receiving device.

8. The method of claim 1, wherein the step of processing the user data is performed at a back end.

9. The method of claim 8, wherein the back end comprises:

a server; and

a usage database.

10. The method of claim 1, wherein the step of providing one or more recommendations based on time and context information is performed at a back end.

11. The method of claim 1 , where the one or more provided recommendations include recommendations for time periods beyond the current time period.

12. The method of claim 1, wherein additional information about the one or more provided recommendations is also provided.

13. The method of claim 1, wherein the one or more provided recommendations are displayed to a user.

14. The method of claim 1, wherein the one or more provided recommendations are based on the cost of the content.

15. The method of claim 1, wherein the one or more provided recommendations are based on the amount of bandwidth available.

16. A system allowing for providing viewing recommendations for a user, the system comprising:

a front end configured to collect usage data including the time and context information regarding content viewed by user;

a back end configured to process the user data and provide one or more

recommendations based on time and context information, wherein at least one of the provided recommendations comprises non-scheduled content.

17. The system of claim 16, wherein the front end comprises a touch screen control device.

18. The system of claim 16, wherein the front end comprises a receiving device.

19. The system of claim 16, wherein the back end comprises:

a server; and

a usage database.

20. The system of claim 16, wherein the front end is further configured to display one or more recommendations.