Video-on-demand recommendations based on previously viewed television programs

[0001] This invention relates to automated video-on-demand recommendations, and more specifically to generating video-on-demand recommendations based on data that identifies previously viewed television programs.

[0002] Systems currently exist that support collection of television data that identifies broadcast television programs that have been watched through a particular client device, such as a cable television set-top box. Furthermore, systems currently exist that automatically generate broadcast television recommendations based on the television data that is gathered. For example, a television recommendation system may recommend broadcast television programs to a particular viewer based on a comparison of television data associated with the particular viewer and television data associated with other viewers, resulting in a “other viewers who watched television program X also watched television program Y” type of recommendation.

[0003] Additionally, video-on-demand (VOD) systems currently exist that record data that identifies VOD purchases associated with a particular viewer. Similar to the broadcast television recommendations, VOD recommendations may be generated based on the gathered VOD data. However, VOD differs from broadcast television programs in that new VOD titles may become available periodically (e.g., monthly or weekly), and older VOD titles may no longer be available, and viewers typically watch a significantly fewer number of VOD titles than they do broadcast television programs. These two factors combined result in a much thinner VOD data set when compared to the television data set, and therefore results in less meaningful VOD recommendations.

[0004] Accordingly, a need exists for techniques for generating meaningful VOD recommendations, even when historical VOD data for a particular viewer is thin or non-existent.

[0005] A technology for automatically generating video-on-demand recommendations is described. Television viewing history data is gathered for multiple client devices within a network. The television viewing history data identifies broadcast television programs that are watched using the client devices. Video-on-demand (VOD) data is also gathered that identifies VOD content that is purchased or viewed using the client devices. Weighted associations are generated between the television data and the VOD data to represent the likelihood that a viewer who watches a particular television program will also purchase a particular video-on-demand.

[0006] In one implementation, the associations are weighted based on the percentage of viewers who purchase or watch a particular video-on-demand and who also have watched a particular television program. In an alternate implementation, the associations are weighted according to a lift algorithm, which is used to calculate a ratio of probabilities. The ratio is defined as the conditional probability that a viewer will purchase a particular video-on-demand given that the viewer has already watched a particular television program divided by the probability that any viewer will purchase the particular video-on-demand.

[0007] In an alternate implementation, a data mining engine is used to generate a decision tree for each VOD title using the TV viewing data to generate tree splitting criteria (e.g., a probabilistic classification tree using a Bayesian score as a splitting criteria).

[0008] In another alternate implementation, a data mining engine may be used to apply association rules algorithms to generate probabilities that a particular VOD title may be purchased or viewed given that particular combinations of television programs have been watched.

[0009] After the associations are generated, video-on-demand recommendations may be generated by comparing the associations with television viewing history data that is associated with a particular viewer. In an exemplary implementation, videos-on-demand that have highly weighted associations with one or more television programs that the viewer has watched are recommended.

[0021] Overview

[0022] The embodiments described below provide techniques for generating meaningful video-on-demand (VOD) recommendations based on broadcast television viewing history data. In the described exemplary implementation, a cable television system headend broadcasts television programs to, and receives television data from, multiple client devices (e.g., television set-top boxes). The television data identifies broadcast television programs that have been watched through one or more of the client devices. In addition, the cable television system headend maintains VOD data that is generated when a viewer purchases or watches a VOD through one of the client devices. A headend process then generates associations between the VOD data and the television data. For example, if a significant number of viewers who purchased or watched a particular VOD also watched a particular television program, then the television program is associated with the VOD.

[0023] A VOD recommendation application executed on a client device provides a user interface that enables a viewer to request VOD recommendations. The headend system generates VOD recommendations by examining television data associated with the viewer, and then identifying VODs that are associated with one or more of the television programs that the viewer has previously watched.

[0024] Exemplary Environment

[0025] FIG. 1 illustrates an exemplary environment 100 that supports automatic generation of meaningful VOD recommendations. Environment 100 includes a headend 102, a network 104, and multiple client devices 106(1), 106(2), 106(3), . . . , 106(N), each connected to a corresponding display device 107(1), 107(2), 107(3), . . . , 107(N). In the illustrated implementation, headend 102 is representative of a cable television system headend, and client devices 106 are representative of television set-top boxes or any other type of client device configured to receive broadcast television programs and other data over network 104.

[0026] Exemplary headend 102 includes broadcast server 108, TV data store 110, available VOD titles store 112, VOD server 114, VOD data store 116, VOD recommendation engine 118, and TV/VOD association store 120. Headend 102 typically includes other components as well, which are not illustrated in FIG. 1, such as a processor, one or more memory components, one or more network interfaces, and so on.

[0027] Broadcast server 108 is configured to transmit broadcast television programs and other data over network 104 to one or more of the client devices 106. Other data that may be broadcast may include, but is not limited to, electronic program guide data and VOD recommendations that may be broadcast over in-band or out-of-band portions of network 104. Broadcast server 108 typically receives television programs over a satellite link (not shown) and remodulates them onto the broadcast network 104.

[0028] TV data store 110 stores data received from one or more of client devices 106, the data identifying broadcast television programs that have been watched using the client device 106. For example, during configuration of a client device 106, a viewer may be given the opportunity to participate in a data collection system, which may or may not be exclusively associated with generating VOD recommendations. For example, television viewing history data may be collected for other reasons, such as targeted advertising, but the data that is collected may also be used for other purposes, such as generating VOD recommendations. If the viewer chooses to participate in such a system, then for example, anytime the client device is tuned to a particular broadcast television program for at least some given period of time (e.g., three minutes), then data is sent from the client device to the headend indicating that the particular broadcast television program has been watched using the particular client device. This data is stored in TV data store 110. In an exemplary implementation, each record stored in TV data store 110 includes a client device identifier and a program identifier. Other data fields may also be stored including, for example, a time of day during which the program was watched. An example data structure that may be associated with TV data store 110 is described in further detail below with reference to FIG. 8. Techniques for collecting such television data are well known to those skilled in the art.

[0029] Available VOD titles store 112 maintains a listing of VOD titles that are currently available for purchase. VOD server 114 is configured to manage the sale and distribution of those VOD titles to client devices 106. Listings of available VOD titles are broadcast over network 104 to client devices 106. When a viewer chooses to purchases a VOD, VOD server 114 receives from the client device data identifying the client device and the VOD title being purchased. This data is stored in VOD data store 116. As with collection of television data, distribution of VODs and collection of VOD data is well known to those skilled in the art.

[0030] VOD recommendation engine 118 is configured to associate TV data stored in TV data store 110 with VOD data stored in VOD data store 116. These data associations are then stored in TV/VOD association store 120. Generation of the TV/VOD associations is described in further detail below with reference to FIG. 9. VOD recommendation engine 118 is further configured to generate VOD recommendations based on data stored in TV data store 110 and TV/VOD association store 120. Generation of VOD recommendations is described in further detail below with reference to FIG. 10.

[0031] Although shown as a component of headend 102, VOD server 114 may, in alternate implementations, be configured as a separate system or as a component of a separate system. In such an implementation, the VOD server system communicates with headend 102 to provide the data that is stored in VOD data store 116.

[0032] Client devices 106(1), 106(2), 106(3), . . . , 106(N) are configured to receive broadcast television programs, video-on-demand content, and other data (e.g., electronic program guide data) over network 104. Client devices 106 may be implemented as any of a number of devices, such as a television set-top box, a TV recorder with a hard disk, a personal computer, a digital-cable-ready TV that includes facilities to support receipt and control of both digital broadcast and VOD content (illustrated as client device 106(3)), a Media Center device that integrates broadband data and local networks with broadcast and VOD content for display on one or more TV display devices, and so on. Furthermore, network 104 may be implemented as any type of network that supports the client devices 106. This may include two-way hybrid fiber/coax digital cable systems or IP-oriented or other point-to-point broadband data systems that support digital television broadcast and VOD content.

[0033] Exemplary Client Device

[0034] FIG. 2 illustrates select components of an exemplary client device 106. Client device 106 can be implemented in any number of embodiments, including as a set-top box, a TV recorder with a hard disk, a personal computer, and so forth. Client device 106 includes one or more tuners 202. Tuners 202 are representative of one or more in-band tuners that tune to various frequencies or channels to receive television signals, as well as an out-of-band tuner that tunes to a broadcast channel over which other data, such as electronic program guide (EPG) data or listings of available VOD titles, may be broadcast to client device 106.

[0035] Client device 106 also includes one or more processors 204 and one or more memory components. Examples of possible memory components include a random access memory (RAM) 206, a disk drive 208, a mass storage component 210, and a non-volatile memory 212 (e.g., ROM, Flash, EPROM, EEPROM, etc.). Alternative implementations of client device 106 can include a range of processing and memory capabilities, and may include more or fewer types of memory components than those illustrated in FIG. 2.

[0036] Processor(s) 204 process various instructions to control the operation of client device 106 and to communicate with other electronic and computing devices. The memory components (e.g., RAM 206, disk drive 208, storage media 210, and non-volatile memory 212) store various information and/or data such as content, EPG data, configuration information for client device 106, graphical user interface information, and/or viewing history data.

[0037] An operating system 214 and one or more application programs 216 may be stored in non-volatile memory 212 and executed on processor 204 to provide a runtime environment. A runtime environment facilitates extensibility of client device 106 by allowing various interfaces to be defined that, in turn, allow application programs 216 to interact with client device 106. Alternatively, application programs 216 may be spooled from headend 102 and executed at the appropriate time on client processor 204.

[0038] VOD recommendation application 218 and VOD purchase application 220 are two specific applications that may be stored in non-volatile memory 212 (or spooled from headend 102) and executed on processor 204. VOD recommendation application 218 enables a viewer to request and receive VOD recommendations that are based on previous television viewing data. An example user interface that may be associated with VOD recommendation application 218 is described below with reference to FIGS. 3-6. VOD purchase application 220 enables a viewer to purchase VOD content. VOD purchase applications are well known to those skilled in the art.

[0039] In the illustrated example, a viewing history data store 222 is stored in memory 212 to maintain data associated with television viewing history, such as a log of viewed television programs.

[0040] Client device 106 also includes a decoder 224 to decode a broadcast video signal, such as a DVB or MPEG-2 or other digitally-encoded video signal. Client device 106 further includes a wireless interface 226, which allows client device 106 to receive input commands and other information from a user-operated input device, such as from a remote control device or from another IR, Bluetooth, or similar RF input device.

[0041] Client device 106 also includes an audio output 228 and a video output 230 that provide signals to a television or other device that processes and/or presents or otherwise renders the audio and video data. Although shown separately, some of the components of client device 106 may be implemented in an application specific integrated circuit (ASIC). Additionally, a system bus (not shown) typically connects the various components within client device 106. A system bus can be implemented as one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, or a local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.

[0042] Client device 106 can also include other components, which are not illustrated in this example for simplicity purposes. For instance, client device 106 can include a user interface application and user interface lights, buttons, controls, etc. to facilitate viewer interaction with the device.

[0043] Video-On-Demand Recommendation Application

[0044] FIG. 3 illustrates a portion of an exemplary user interface 302, through which a viewer may request VOD recommendations. In the described implementation, when the VOD recommendation application 218 is launched, for example, by a viewer from a main system menu, a user interface screen similar to that shown in FIG. 3 is displayed. The screen may include a selectable VOD listing button 304, a selectable VOD recommendations button 306, and a selectable exit button 308.

[0045] The VOD listing button 304, when selected, causes a listing of all available VOD titles to be displayed. This type of display may be generated using commonly known technology to receive and display a list of available VOD titles.

[0046] For example, a listing of available VOD titles as stored in available VOD titles store 112 may be downloaded each day and stored on the client device. This local copy of the list may then be displayed to the viewer. Alternatively, a request for the list of available VOD titles may be sent to the server, which in turn sends the list back to the client device.

[0047] The VOD recommendations button 306, when selected, causes one or more lists of recommended VOD titles to be displayed. Recommendations may include those titles rated highest by one or more movie critics, those titles that will only be available as VOD for a short period of time (e.g., three days or less), and/or titles that are recommended to a particular viewer based on specific recommendation criteria. Examples of such lists are described in further detail below with reference to FIGS. 4-6.

[0048] FIG. 4 illustrates a portion of an exemplary user interface 302 associated with video-on-demand recommendation application 218, as illustrated in FIG. 2. In the illustrated example, a viewer may be presented with three types of recommendations, represented by the recommendations tab 402, the critics' picks tab 404, and the last chance tab 406. In the illustrated implementation, a maximum of five titles are recommended in association with each tag. It is recognized, however, that the number of titles to be recommended may be more or less than that number, which may be configurable or may be dynamically determined depending on the number of titles that fulfill one or more recommendation criteria.

[0049] In FIG. 4, the recommendations tab 402 is selected. Recommended VOD titles 408, 410, 412, 414, and 416 represent available VOD titles that have been automatically selected for recommendation to the viewer based on viewer-specific recommendation criteria. For example, in the described implementation, television programs that the viewer has previously watched are compared to television programs that have been previously watched by other viewers. When a match is found, VOD titles that have been purchased by those other viewers are then selected for recommendation to the viewer. An exemplary recommendation generation process is described in further detail below with reference to FIG. 10.

[0050] When a viewer selects one of the displayed recommended titles (e.g., “8 Mile” is selected in the illustrated example), a description of the VOD content is displayed in the description area 418 of the user interface. The illustrated user interface screen also includes a purchase button 420 and an exit button 422. When a viewer selects the purchase button 420, a VOD purchase process is initiated for the title that is currently selected. For example, VOD purchase application 220 may be launched. When a viewer selects the exit button 422, the VOD recommendation application closes, and television content that is currently being broadcast is displayed.

[0051] FIG. 5 illustrates a portion of user interface 302 that is displayed when the critics' picks tab 404 is selected. VOD titles 502, 504, 506, 508, and 510 represent available VOD titles that have the highest ratings as given by one or more movie critics.

[0052] As described above with reference to FIG. 4, when a viewer selects one of the displayed recommended titles (e.g., “25^th Hour” is selected in the illustrated example), a description of the VOD content is displayed in the description area 418 of the user interface.

[0053] FIG. 6 illustrates a portion of user interface 302 that is displayed when the last chance tab 406 is selected. VOD titles 602, 604, 606, 608, and 610 represent available VOD titles that are available for only a short period of time. For example, those VOD titles that are only available for up to three more days may be displayed, preferably in order so that those expiring soonest are listed first.

[0054] Data Structures to Support VOD Recommendation Generation

[0055] FIG. 7 illustrates an exemplary data structure for VOD data store 116. In the illustrated example, VOD data store 116 stores multiple records, each including a client device ID 702 and a purchased VOD title 704. In alternate implementations, rather than storing a VOD title, any other type of VOD identifier may be stored. Additionally, VOD data store 116 may also include other data fields, such as a viewer rating of each VOD title, a date purchased, a flag to indicate whether or not the title is still available as a VOD, etc.

[0056] The client device ID data field 702 records an identifier associated with a client device 106 through which a particular VOD was purchased. Privacy issues may exist with a system that stores a client device ID that can be used to personally identify a television viewer (e.g., by specifically identifying a particular set-top box). To overcome such issues, in an exemplary implementation, an ID associated with the client device is obfuscated, for example using an obfuscation function, and then the obfuscated client device ID is stored. The purchased VOD title data field 704 records the title of the VOD that was purchased. For example, the data shown in FIG. 7 indicates that a viewer purchased the movie “Catch Me If You Can” as a VOD using a client device having a device ID of 47. The same client device was used to purchase “Sweet Home Alabama” as a VOD. “Sweet Home Alabama” was also purchased by viewers using client devices with device IDs 53 and 56. Furthermore, a viewer purchased “Just Married” using a client device with device ID 61.

[0057] The data stored in VOD data store 116 may be collected in any number of ways. For example, if headend 102 includes VOD server 114 (as illustrated in FIG. 1), then the data may be collected directly from the client devices 106 as VODs are purchased. Alternatively, as described above with reference to FIG. 1, VOD server 112 may be implemented as a separate server or as part of a separate system that also communicates with the client devices 106. In such an implementation, headend 102 may receive data to be stored in VOD data store 116 from another system that is responsible for collecting VOD data. Data may be collected from the other system at regular intervals, for example daily or weekly.

[0058] FIG. 8 illustrates an exemplary data structure for TV data store 110. In the illustrated example, TV data store 110 stores multiple records, each including a client device ID 802 and a viewed broadcast TV program 804. FIG. 8 illustrates storing a television program title, although it is recognized that any sort of television program identifier may be stored. Furthermore, it is recognized that FIG. 8 illustrates identifying only the name of a series, with no indication of which episode was viewed, which may also be stored in alternate implementations. Other data may also be stored in TV data store 110, such as frequency or number of times that a particular program has been watched, date and/or time at which a particular program has been watched, etc.

[0059] The data that is stored in TV data store 110 is collected from the client devices 106, for example, over an out-of-band channel, which is common in cable television networks. A viewer may typically be given an opportunity to “opt-in”, thereby giving permission for data to be collected that describes their viewing habits. In the described implementation, when a viewer opts in, the data is collected by the client device 106 and stored temporarily in viewing history data store 222, as described above with reference to FIG. 2. Then, at regular intervals (e.g., daily, weekly, etc), the data is transferred from the viewing history data store 222 to the headend 102 over network 104, where it is then stored in TV data store 110.

[0060] The example data shown in FIG. 8 indicates that one or more viewers using a client device with device ID 47 have watched the television programs “CSI”, “Friends”, and “Fraiser”; one or more viewers using a client device with device ID 53 have watched the television programs “Friends”, “Fraiser”, and “Judging Amy”; one or more viewers using a client device with device ID 56 have watched the television programs “Friends”, “Judging Amy”, and “ER”; and one or more viewers using a client device with device ID 61 have watched the television programs “Fear Factor” and “Survivor”.

[0061] FIG. 9 illustrates an exemplary data structure for TV/VOD association store 120. In the illustrated example, TV/VOD association store 120 stores multiple records, each including a VOD title 902, a television program title 904, and a weight 906. It is recognized, that as in FIG. 8, FIG. 9 illustrates identifying only the name of a television series, with no indication of which episode was viewed, which may also be stored in alternate implementations.

[0062] The example data shown in FIG. 9 is representative of TV/VOD associations that may be generated by VOD recommendation engine 116 based on the example data shown in FIGS. 7 and 8. For example, the VOD title “Sweet Home Alabama” is associated with the television programs “Friends”, “Judging Amy”, “Fraiser”, “ER”, and “CSI” because the listed television programs were viewed through client devices through which the VOD title was also purchased (i.e., client device IDs 47, 53, and 56). Similarly, the VOD title “Catch Me If You Can” is associated with the television programs “CSI”, “Friends”, and “Fraiser” because that VOD title and those television programs were purchased and viewed, respectively, through a client device with device ID 47; and the VOD title “Just Married” is associated with the television programs “Fear Factor” and “Survivor” because that VOD title and those television programs were purchased and viewed, respectively, through a client device with device ID 61.

[0063] The weight data field 906 is used to describe the strength or reliability of each of the TV/VOD associations. In the illustrated example, the value of the weight data field represents the percentage of viewers who purchased a particular VOD title and also watched the associated TV program. For example, in the first record 908, the value of 100 in the weight data field 906 indicates that the television program “Friends” was watched through 100 percent of the client devices through which “Sweet Home Alabama” was purchased as a VOD. In the second record 910, the value of 66 in the weight data field 906 indicates that the television program “Judging Amy” was watched through 66 percent of the client devices through which “Sweet Home Alabama” was purchased as a VOD. Similarly, in the fourth record 912, the value of 33 in the weight data field 906 indicates that the television program “ER” was watched through only 33 percent of the client devices through which “Sweet Home Alabama” was purchased as a VOD.

[0064] Accordingly, the data stored in TV/VOD association store 118 can be used to generate meaningful VOD recommendations for viewers. For example, if a viewer who watches CSI requests a VOD recommendation, based on the example data shown in FIG. 9, “Catch Me If You Can” and “Sweet Home Alabama” may both be identified as possible recommendations. Based on the weight, however, “Catch Me If You Can” would be a better recommendation than “Sweet Home Alabama” because 100 percent of the viewers who purchased “Catch Me If You Can” also watched “CSI”; on the other hand, only 33 percent of the viewers who purchased “Sweet Home Alabama” also watched “CSI”.

[0065] It is recognized that there are many techniques for weighting associations between two types of data, and it is hereby recognized that any of those techniques may be used to generate meaningful values for the weight data field 906.

[0066] In a particular alternate implementation, a lift algorithm is used. Using the lift algorithm, the value of the weight data field is calculated as the conditional probability that a viewer will purchase the VOD title given that the user has already watched the associated television program divided by the probability that any viewer will purchase the VOD title. Use of the lift algorithm results in a fewer number of personalized recommendations for VOD titles that are popular with a large portion of the general population and a greater number of personalized recommendations for VOD titles that are popular among groups of people who also watch a particular television program.

[0067] Video-On-Demand Recommendation Method

[0068] FIG. 10 is a flow diagram that illustrates an exemplary video-on-demand recommendation method 1000. The illustrated process can be implemented in any suitable hardware, software, firmware or combination thereof. In the described implementation, the illustrated process is performed by a server system such as headend 102 as illustrated in FIG. 1.

[0069] At block 1002, the headend maintains TV data for multiple television viewers. In an exemplary implementation, a client device records data that indicates that a particular program has been viewed, for example, when the channel on which the program is being aired is tuned to for at least three minutes. The client device then transmits that data to headend 102, where it is maintained in TV data store 110.

[0070] At block 1004, the headend maintains VOD data for multiple television viewers. The VOD data identifies which on demand videos have been purchased through which client devices. For example, a list of available VODs is broadcast to multiple client devices. A television viewer may purchase one of the VODs, causing the VOD content to be downloaded to the viewer's client device. Data associated with the purchase process (e.g., a client device identifier and a VOD identifier) is transmitted from the client device to headend 102 where it is maintained in VOD data store 116.

[0071] Collection and storage of TV data and VOD data as described above with reference to blocks 1002 and 1004 may be performed continuously, at regular intervals, or at irregular intervals, as data is received from one or more client devices.

[0072] At block 1006, the TV data stored in TV data store 110 is associated with VOD data stored in VOD data store 116. For example, a VOD identifier is associated with a television program identifier if the same client device identifier is associated with both the television program and the VOD in the TV data store 110 and the VOD data store 116, respectively. In an exemplary implementation, a weighting factor is assigned to each association based, for example, on a percentage of the client devices that are associated with a particular VOD that are also associated with a particular television program. For example, an association between a particular VOD and a first television program is assigned a high weighting factor if a large percentage of viewers who purchased the VOD also watched the first television program. Similarly, an association between the particular VOD and a second television program is assigned a low weighting factor if only a small percentage of viewers who purchased the VOD also watched the television program.

[0073] Alternatively, a lift algorithm may be used to calculate the weighting factor as a ratio of two probabilities. Such an algorithm is described above with reference to FIG. 9.

[0074] In another exemplary implementation, in order to associate TV viewing data with VOD purchase data, both the TV viewing data and the VOD purchase data for each client device is combined as a table or set of dependent tables in a database. Because it is difficult to a priori determine the most salient aspect of TV viewing behavior that will create the best recommendations, a data mining engine is used to analyze and score each VOD title for each client. The data mining engine derives from the TV viewing data, predictions for VOD viewing. In one implementation, a decision tree algorithm is used. In this case the data mining engine creates a decision tree for each VOD title using the TV viewing data to generate the tree splitting criteria. The tree that is generated lists from most significant to less significant the TV shows that separate clients who have purchased the VOD from those who have not. In one implementation, the data mining engine creates a probabilistic classification tree using a Bayesian score as a splitting criteria. The VOD titles for which the tree best matches the TV viewing behavior of the client in question receive the best scores.

[0075] In alternate implementations, other data mining algorithms, such as association rules algorithms may also be used. An association rule is defined to represent the probabilities that for each set of TV programs viewed by one or more viewers, a particular VOD will be also viewed (or purchased). Because the number of possible TV programs is large, the number of possible combinations of TV programs that can be viewed by any particular viewer is very large. Accordingly, when the data mining engine computes the set of association rules, it prunes them to only include those that provide sufficiently high-quality (i.e. high-confidence) predictions. A more detailed explanation of uses of association rules is given in “Algorithms for Association Rule Mining—A General Survey and Comparison” by Hipp, Guntzer, and Nakhaeizadeh, published in SIGKDD Explorations, Newsletter of the ACM Special Interest Group on Knowledge Discovery and Data Mining, June 2000, Volume 2, Issue 1, pages 58-64, which can also be found at http://www.acm.org/sigs/sigkdd/explorations/issue2-1/hipp.pdf, and is hereby incorporated by reference in its entirety.

[0076] Once the data mining engine has scored the VOD titles for the client, the VOD titles with the highest scores for each client are stored or transmitted to the client devices.

[0077] At block 1008, the headend 102 receives a client device-initiated request for VOD recommendations.

[0078] At block 1010, the headend 102 generates VOD recommendations based on TV data associated with the client device and the TV/VOD associations stored in TV/VOD association store 118. For example, VOD recommendation engine 116 identifies VODs to be recommended as those VODs that are associated (with highest weighting factors) with television programs most watched through the client device through which the VOD recommendations were requested.

[0079] Alternatively, the headend 102 accesses pre-computed VOD recommendations for the client device.

[0080] At block 1012, headend 102 transmits the generated VOD recommendations to the requesting client device.

[0081] In a particular implementation, an association between a VOD title and a television program is based, at least in part, on the frequency with which the television program has been watched. For example, an association between a VOD title and a particular television series may have a higher weight value if the television series is watched frequently by viewers who purchased the VOD title. Conversely, an association may be assigned a lower weight value if the particular television series is watched less frequently by those viewers who purchased the VOD title.

[0082] In an alternate implementation, VOD recommendations for each client device are pre-determined at regular intervals (e.g., daily or weekly). The pre-determined recommendations may then be broadcast to client devices 106, for example, using a carousel file system over an in-band or out-of-band channel.

[0083] Video-On-Demand Recommendation Request Method

[0084] FIG. 11 is a flow diagram that illustrates an exemplary video-on-demand recommendation request method 1100. The illustrated process can be implemented in any suitable hardware, software, firmware or combination thereof. In the described implementation, the illustrated process is performed by a client device such as client device 106 as illustrated in FIGS. 1 and 2.

[0085] At block 1102, the client device transmits TV data to a server system. For example, client device 106 may record (e.g., based on a viewer opt-in to have data collected) data that identifies television programs that are watched through the client device. The title of the television program being watched may be recorded, for example, if the client device is tuned to the channel on which the program is being broadcast for at least three minutes (or some other configurable length of time). (Setting a threshold time prevents data from being gathered for every program that is scanned while a viewer is, for example, channel surfing.) In one implementation, the data may be gathered and immediately transmitted to the server (e.g., headend 102). Alternatively, the data may be gathered and maintained by the client device in viewing history data store 222 as shown in FIG. 2. In such an implementation, the data may then be transmitted from the viewing history data store 222 to the server at regular intervals, such as once a day.

[0086] At block 1104, the client device transmits VOD data to a server system. For example, when a viewer purchases a VOD through client device 106 data that identifies the on-demand video that is being purchased is transmitted from VOD purchase application 220 to VOD server 114. The purchased VOD is then downloaded to the client device. In the illustrated implementation, this function is performed by headend 102, although, as described above, it is recognized that VOD server 114 may be implemented as a separate system or as a component of a system that is separate from headend 102. In such an implementation, all or a portion of the VOD data that is transmitted to the VOD server is then transmitted from the VOD server to the headend 102, where it is stored in VOD data store 116.

[0087] It is not necessary for a viewer to have previously purchased VOD content in order to request VOD recommendations. If this is the case, then the processing described with reference to block 1104 will not be performed until a VOD is actually purchased.

[0088] At block 1106, a viewer requests VOD recommendations. This may be initiated, for example, through a user interface similar to the one illustrated in FIGS. 3-6. When the viewer initiates the request, a request for VOD recommendations is sent over network 104 to headend 102.

[0089] At block 1108, the client device 106 receives from headend 102, one or more lists of recommended on-demand videos. These lists may then be displayed to the user using, for example, a user interface similar to the one illustrated in FIGS. 3-6.

[0090] Alternatively, recommendations may be generated at regular intervals (e.g., daily or weekly) and broadcast to the client devices. The recommendations may then be stored at the client device for display when requested by a viewer. Alternatively, pre-computed VOD recommendations may be cached on a VOD proxy server (not shown) that mediates dialog between the VOD server 114 and the client device 106.

[0091] Conclusion

[0092] The systems and methods described above enable the generation of meaningful VOD recommendations.

[0093] Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.