US20120114312A1

US20120114312A1 - Method and system for determining the availability of a media controller

Info

Publication number: US20120114312A1
Application number: US12/731,730
Authority: US
Inventors: Harold Sutherland; Hugh Svendsen
Original assignee: Eloy Technology LLC
Current assignee: Concert Technology Corp
Priority date: 2009-03-25
Filing date: 2010-03-25
Publication date: 2012-05-10
Also published as: US9088757B2; US9015757B2; US20120117471A1; US20120117595A1; US20150229993A1; US20160196025A1; US9288540B2; US20120117581A1; US20120117598A1; US20150326938A1; US9083932B2

Abstract

Method and system for determining the availability of a media controller to record a program in the future. A media controller receives a request to schedule the recording of a program during a particular time slot. The media controller obtains an availability probability of the media controller during the time slot. The media controller determines, based on the availability probability, whether the media controller is available to record the program. The availability probability may be based on previous usage data that identifies previous usage associated with the media controller.

Description

RELATED APPLICATIONS

This application claims the benefit of provisional patent application Ser. No. 61/163,086, filed Mar. 25, 2009, the disclosure of which is hereby incorporated herein by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to recording programs, and in particular to determining whether a media controller is available to record a program based on previous usage data associated with the media controller.

BACKGROUND

A media controller, such as a digital video recorder (DVR), records a program by tuning to a frequency on which the program will be transmitted at a designated time. The media controller receives the program content, and stores the program content on a storage medium. The availability of a media controller to record a program is consequently based on the availability of a tuner. Increasingly, media controllers are made with multiple tuners to enable the media controller to perform multiple tasks concurrently, such as recording two programs simultaneously, or viewing one program while recording another.
With the vast selection of program content available from content providers, it is increasingly likely the number of programs which a viewer wishes to access at any given time may exceed the number of tuners in a media controller. For example, a viewer may wish to view a first program and record two other programs simultaneously. If the media controller has only two tuners, a conflict arises. One way to resolve the conflict is to inform the viewer of the conflict and allow the viewer to prioritize the top two choices of the three desired programs. Unfortunately, this results in one program being unrecorded.
Locales, such as a residence, increasingly have multiple media controllers to service multiple televisions. Media controllers are also increasingly network capable, and communications between media controllers coupled to a local area network are increasingly more common. It would be beneficial therefore, if a first media controller could request a second media controller to record a program. While the second media controller may relatively easily determine whether a tuner is immediately available to record a program, if the request is to record a future program, accepting such a request by the second media controller may only ultimately result in a similar conflict on the second media controller. Therefore, it would also be beneficial if it could be determined whether it is likely that the second media controller would be available to record the program at the future point in time.

SUMMARY

Embodiments of the present disclosure relate to determining the availability of a media controller to record a program. Generally, a media controller may determine a program time slot associated with a recording request, obtain previous usage data identifying previous usage of the media controller, and based on the previous usage data determine that the media controller will be available to schedule the recording of the program or will not be available to schedule the recording of the program.
In one embodiment, each media controller is provided previous usage data of other media controllers coupled to a local area network in a locale. A first media controller determines that a viewer desires to concurrently access a number of programs that exceeds the number of tuners of the first media controller. For example, the viewer desires to record three programs during a particular time slot, and the first media controller has only two tuners. The first media controller processes the previous usage data of one of the other media controllers coupled to the network, determines that a probability that the other media controller will be available to record the program during the time slot exceeds an availability threshold, and sends a request to the other media controller to record one of the three programs. The first media controller may process the previous usage data of multiple other media controllers until the first media controller locates an available media controller.
In another embodiment, a first media controller sends a request to a second media controller to schedule the recording of a program. The second media controller determines the program time slot of the program identified in the request, and processes previous usage data associated with the second media controller to determine an availability probability that the second media controller will be available to record the program. Determining the availability probability of the second media controller may include determining the availability probability of each of a plurality of tuners associated with the second media controller. If the availability probability of the second media controller exceeds an availability threshold, the second media controller may schedule the recording of the program and send a message to the first media controller indicating that the second media controller has scheduled the request.
In another embodiment, each media controller provides previous usage data associated with the respective media controller to a media server. If a viewer requests concurrent access to a number of programs that exceeds the number of tuners of a first media controller, the first media controller sends a request to the media server to determine whether another media controller may be available to schedule the recording of one of the programs. The media server may process the previous usage data of one or more second media controllers to determine if the probability of availability of any second media controller exceeds an availability threshold. If so, the media server may request that the second media controller record the program, and send a message to the first media controller indicating that the second media controller has been scheduled to record the program.
In yet another embodiment, the first media controller may ask each of a plurality of other media controllers if the other media controllers are available to schedule the recording of a program during the program time slot. After one or more of the other media controllers respond that they are available to record the program, the first media controller may cause a display identifying the other media controllers that are available to schedule the recording of the program to the viewer. The viewer may select one of the other media controllers, and in response to the viewer selection, the first media controller may send the selected media controller a request to record the program.
Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosed embodiments.

FIG. 1 is an exemplary block diagram of a locale in which embodiments may be practiced;

FIG. 2 is a block diagram illustrating additional detail of a media controller according to one embodiment;

FIG. 3 is block diagram of an exemplary stored item record according to one embodiment;

FIG. 4 is a block diagram illustrating exemplary nodal data according to one embodiment;

FIG. 5 is a block diagram of an exemplary recorder according to one embodiment;

FIG. 6 is a block diagram of an exemplary merged guide according to one embodiment;

FIG. 7 is a flowchart illustrating an exemplary method for generating program records;

FIG. 8 is a block diagram illustrating exemplary update timestamp data according to one embodiment;

FIG. 9 is a flowchart illustrating an exemplary method for receiving and processing program metadata sent from one media controller to another media controller;

FIG. 10 is a flowchart illustrating an exemplary method for sending program metadata to another media controller;

FIG. 11 illustrates an exemplary merged guide at a first point in time;

FIG. 12 illustrates the exemplary merged guide illustrated in FIG. 11 at a second point in time;

FIG. 13 is a block diagram illustrating exemplary mechanisms that may be used by a media controller to determine the identity of a particular viewer;

FIG. 14 is a flowchart illustrating an exemplary method for integrating viewer information with a program record;

FIG. 15 is block diagram illustrating exemplary requests that one media controller may make of another media controller;

FIG. 16 is a flow chart illustrating an exemplary method for determining if another media controller is available to schedule a recording of a program according to one embodiment;

FIG. 17 is a block diagram of an exemplary media controller usage (MCU) record 150 for storing consolidated previous usage data associated with the usage of a media controller according to one embodiment;

FIG. 18 is block diagram of an exemplary client server embodiment;

FIG. 19 is a flow chart illustrating an exemplary method for determining if another media controller is available to schedule a recording of a program;

FIG. 20 is block diagram of another exemplary embodiment implemented in a peer-to-peer architecture;

FIG. 21 is a flow chart illustrating an exemplary method for determining if another media controller is available to schedule the recording of a program;

FIG. 22 illustrates a window which may be displayed on the display device according to one exemplary embodiment;

FIG. 23 is a flowchart illustrating an exemplary method for providing a viewer an option to select another media controller to resolve a tuner conflict; and

FIG. 24 illustrates an exemplary processing device which may be used to implement a media controller, or a server, according to some embodiments.

DETAILED DESCRIPTION

The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
Embodiments of the present disclosure relate to processing a request to record a program to determine the availability of a media controller tuner to record the program. Generally, a media controller may determine a program time slot associated with the request to record the program, obtain previous usage data identifying previous usage of the media controller during the program time slot, and based on the previous usage data determine that the media controller tuner will be available to record the program or will not be available to record the program. Embodiments may be implemented in any of several different system architectures, including peer-to-peer (P2P) architectures and client-server architectures. Embodiments may also be implemented in conjunction with a merged program guide comprising program data from a plurality of media controllers.
Certain embodiments disclosed herein may be implemented in conjunction with a merged program guide. Accordingly, prior to discussing mechanisms for determining the availability of a media controller to record a program based on previous usage data, the generation of a merged guide will be illustrated. While the merged program guide disclosed herein serves as one mechanism by which previous usage data may be maintained, other embodiments may be implemented in the absence of a merged program guide, as will be discussed in greater detail herein. FIG. 1 illustrates a locale 10, such as a residence, in which media controllers 12A and 12B (generally, media controller 12 or media controllers 12) are located. The media controllers 12 may comprise any device capable of providing, presenting, or otherwise causing the display of content upon demand, such as, for example, a set top box, a digital video recorder, an intelligent gaming console, such as the Microsoft® Xbox®, Sony® PlayStation®, and Nintendo® GameCube®, a media console such as the Apple® TV®, personal computers, and the like.
The media controllers 12 provide content to one or more viewers 14 by causing a display on a display device 16. The display device 16 may comprise any display technology, such as a television, a computer monitor, a projector, and the like. By “causing” or “cause” to display it is meant that the media controllers 12 generate output streams that are provided to output connections on the media controllers 12 (not illustrated), which are directed to a respective display device 16, typically via a cable or other signal-carrying mechanism. While for purposes of illustration the media controllers 12 and display devices 16 are illustrated as devices which are separate from one another, the display device 16 may be integral with the media controller 12. For example, a single unit may include both a media controller 12, such as a digital video recorder, and a display device 16, such as a television. Where a media controller 12 and display device 16 are integral, the signal-carrying connection between the two may not be by a connection cable, but rather by an internal bus or other signal-carrying mechanism.
The media controller 12A receives content from content providers 18A and 18B (generally content providers 18, or content provider 18). The content providers 18 may comprise any provider of content, including service providers that provide content for a direct or indirect fee, cable operators, satellite operators, internet content providers, and the like. The content received by the media controllers 12 may be any content desirable for presentation, display or otherwise rendering to a viewer 14, such as broadcast television, movies, video on demand, music, and the like. Units of content will be referred to herein as programs, and a program can refer to any unit of content that is referred to individually by the content provider, such as a particular television show, a particular movie, a song, and the like.
Content is typically, but not necessarily, provided to the media controllers 12 in a content package that is defined by a particular subscription. The subscription between the media controller 12 and the content provider 18 defines which channels and features make up a particular content package, and therefore defines the programming that will be provided by the respective content provider 18 to the media controller 12 pursuant to the subscription. For example, the media controller 12A may receive a first content package that includes premium movies and high definition content from the content provider 18A pursuant to a first subscription. The media controller 12B may receive a second content package that includes only standard definition content and no premium movies from the content provider 18D pursuant to a different subscription, even though the content provider 18A may be the same content provider as the content provider 18D. The same program may therefore be available to the same or different media controllers 12. Moreover, different versions of the same program may be available to the same or different media controllers 12. For example, the media controller 12A may have access to a high-definition version of a particular episode of the network program Survivor, while the media controller 12B has access only to a standard-definition version of Survivor based on the respective subscriptions.
The content providers 18 typically provide a guide to the media controllers 12 that identifies programs available via the respective content provider 18. Such guides are depicted in FIG. 1 in the form of respective local electronic programming guides 20A, 20B (generally, local guides 20 or local guide 20). While for purposes of illustration each media controller 12 is shown as having only a single local guide 20, it will be understood that each media controller 12 may have multiple local guides 20, since each content provider 18 may provide its own respective local guide 20 to the media controller 12.
Local guides 20 typically comprise program metadata identifying attributes and characteristics of particular programs. The program metadata may be provided to the media controller 12 continually on a particular channel, or upon request by the media controller 12, or at certain predetermined times. The program metadata can include any data that may be useful or desirable to the viewer 14 (typically as determined by the respective content provider 18). For example, program metadata may include a title, a description, identification of well-known actors, a channel on which the program will be provided, a genre, an MPAA rating, a duration, a version, a time and date the program will be provided, and the like. Typically, a viewer 14 accesses a local guide 20 via an input device (not illustrated) such as a remote control, wherein, upon receipt of a request via the remote control, the media controller 12 will cause a display of information from the local guide 20 on the display device 16.
The media controllers 12A, 12B may also contain one or more respective recorded programs 22A, 22B (generally, recorded programs 22 or recorded program 22). The recorded programs 22 may have been previously selected by the viewer 14 for time-shifting purposes, for example, to enable the viewer 14 to view a program at a different time from when the program was originally provided by a content provider 18. Different programs may be recorded at different media controllers 12, and thus, for example, the recorded programs 22A may differ from the recorded programs 22B. The media controllers 12 may also be communicatively coupled to local entertainment libraries 24 that contain a variety of programs, such as movies, songs, videos and the like that may have been downloaded, ripped, or otherwise obtained by the viewer 14. The media controllers 12A, 12B also preferably include respective recording schedules 23A, 23B which identify programs that are scheduled to be recorded on the respective media controllers 12A, 12B at a future point in time.
Each of the media controllers 12A, 12B are communicatively coupled to one another via a local area network 26. The local area network 26 may comprise any suitable communication mechanism that enables the media controllers 12A, 12B to communicate with one another, including, for example, an Ethernet network, Token Ring network, and the like. The media controllers 12 access the network 26 via communication links 28, which may comprise any suitable technology for accessing the network 26, such as, for example, WiFi, an Ethernet cable, and the like. The network 26 may use any suitable message transport protocol to enable message communications between the media controllers 12A, 12B, such as, for example, TCP/IP.
According to one embodiment, each of the media controllers 12A, 12B also includes a respective merged guide 30A, 30B (generally, merged guides 30 or merged guide 30). While the generation and contents of the merged guide 30 will be discussed later in detail, generally, each merged guide 30 contains program records identifying programs available from a variety of different sources, including programs that are available at other media controllers 12. For example, the merged guide 30A may contain program records identifying programs available from each of the content providers 18A-18E, programs available in the entertainment libraries 24A, 24B, and recorded programs 22A and 22B. Similarly, the merged guide 30B associated with the media controller 12B also preferably contains program records identifying programs available from each of the content providers 18A-18E, programs available in the entertainment libraries 24A, 24B, and recorded programs 22A and 22B. As will be discussed in greater detail herein, the media controller 12A may cause a display on the display device 16 which presents information contained in the merged guide 30A. Thus, a viewer 14 may use any media controller 12 that is coupled to the network 26 to determine the entire collection of content that may be consumed by the viewer 14.
The media controllers 12 may discover one another on the network 26 using any suitable device discovery mechanism or techniques. Device discovery mechanisms are known to those skilled in the art and will not be described in detail herein. For example, the media controller 12A may use the Bonjour® service discovery protocol to discover the media controller 12B, but the embodiments are not limited to any particular device discovery mechanism.
The media controller 12A also preferably maintains media controller previous usage data identifying previous usage of a media controller. Previous usage data may include data identifying that a viewer 14 viewed or recorded a particular program. In some embodiments, the previous usage data stored on the media controller 12A may comprise data identifying previous usage of the media controller 12A. In other embodiments, the previous usage data stored on the media controller 12A may comprise data identifying previous usage of media controllers 12 other than the media controller 12A.
In the embodiment illustrated in FIG. 1, the media controller 12A maintains remote media controller previous usage data 25A (referred to hereinafter as “previous usage data 25A” for purposes of simplicity) which identifies previous usage of another media controller 12, such as the media controller 12B, and any other media controllers 12 coupled to the network 26. The word “remote” is merely a reference to a media controller 12 other than the media controller 12A, and does not imply a particular physical distance. For example, the media controller 12B is remote with respect to the media controller 12A, and vice versa. The previous usage data 25A may be based on information received from the media controller 12B, as discussed in greater detail herein. The media controller 12A may use the previous usage data 25A to determine previous usage of the media controller 12B, and thereby determine an availability probability of the media controller 12B for scheduling the recording of a program upon request by the media controller 12A. The media controller 12B similarly includes previous usage data 25B which identifies previous usage of the media controller 12A, and any other media controllers 12 coupled to the network 26, for similar purposes. The media controllers 12 also have respective one or more tuners 34 which may be used to tune to a particular frequency to access a program being provided by one of the content providers 18.
FIG. 2 is a block diagram illustrating additional details of a media controller 12 according to one embodiment. The media controller 12 preferably includes nodal data 32, which includes information that may be unique to the respective media controller 12, such as, for example, a name of the media controller 12, a serial number associated with the media controller 12, log files generated by the media controller 12, and the like. Exemplary nodal data 32 will be discussed in greater detail with reference to FIG. 3. The media controller 12 includes one or more tuners 34 which are used to select particular content provided by a content provider 18. For example, the content provider 18 may concurrently provide a number of different programs to the media controller 12, each program being delivered on a particular frequency. The tuner 34, for example in response to a channel selection from a viewer 14, tunes to a particular frequency and captures the program data being provided at the particular frequency. The tuner 34 then typically causes the program to be displayed on a display device 16, or may record the program, as discussed in greater detail herein. While the tuner 34 has been discussed herein in terms of tuning to a particular frequency, it will be apparent that programs may be differentiated from one another by mechanisms other than a frequency, and the tuner 34 therefore is not limited to a frequency tuner, but may comprise any suitable tuning mechanism capable of selecting a desired program from a plurality of programs.
The media controller 12 preferably includes a recorder 36 for recording a program. The recorder 36 preferably receives input from the tuner 34, encodes the input into a desired format, if necessary, and stores the program data in a storage 38. The storage 38 may comprise any suitable storage technology, such as a hard drive, flash drive, and the like. The storage 38 is preferably a persistent storage that survives the powering down of the media controller 12, and may contain data from a variety of sources, including, for example, the local guide 20, the merged guide 30, the recording schedule 23, the previous usage data 25, and the like.
The media controller 12 may also include a retransmitter 40 which enables the retransmission of a program received by the media controller 12 onto the network 26. For example, the retransmitter 40 may segment the program data received by the media controller 12 into packets and transmit the packets to another media controller 12 via the network 26. The retransmitter 40 may encode the program differently from the way the program was encoded when initially received by the tuner 34. For example, in one embodiment, a first media controller 12 may request from a second media controller 12 a program stream of a program currently being presented to viewers 14 by the second media controller 12. The request may identify that a particular quality, or resolution, of the program stream is desired. For example, the first media controller 12 may intend to display the program stream in a relatively small area of a display device 16 in conjunction with other information, and thus not require a high resolution program stream. The second media controller 12 may then encode the program into a sufficiently lower resolution version of the program prior to transmitting the program stream onto the network 26 to minimize network usage.
The media controller 12 may also include a web server 42 for use in transferring program metadata between media controllers 12. For example, the web server 42 may respond to requests for program metadata from other media controllers 12. In one embodiment the program metadata may be formatted and transferred in an XML format. The media controller 12 may also include update timestamp data 44 that identifies the times that other media controllers 12 last provided program metadata to the media controller 12. The update timestamp data 44 may be used by the media controller 12 to quickly determine which program metadata received by another media controller 12 constitutes new program metadata. The receipt of program metadata by a media controller 12 and the use of the update timestamp data 44 will be described in greater detail herein.
FIG. 3 is block diagram of a stored item record 50-1 that contains data associated with items stored in storage 38, or elsewhere. The storage 38 may contain a plurality of stored item records 50-1-50-N. The stored item record 50-1 contains information identifying, for example, a recorded program 22, or a program in the entertainment library 24. The stored item record 50-1 may include a globally unique identifier (GUID) field 52 that contains a GUID which uniquely identifies the stored item record. The generation of a GUID is known to those skilled in the art, and will not be discussed in detail herein. The stored item record 50-1 also includes a location field 54 identifying a location of the corresponding program. The location field 54 may indicate the program resides in the storage 38, the entertainment library 24, or elsewhere. The stored item record 50-1 preferably includes a metadata GUID field 56 that contains a metadata GUID which uniquely identifies a metadata record containing metadata pertaining to the corresponding program. The metadata record may be in the storage 38, on a local server coupled to the network 26, or on a remote server accessible by the media controller 12 over a wide area network coupled to the network 26.
FIG. 4 is a block diagram illustrating exemplary nodal data 32 according to one embodiment. The nodal data 32 can include a name field 58 that contains a name which identifies the respective media controller 12. For example, the name field 58 of the media controller 12A may be “TIVO DVR”, and the name field 58 of the media controller 12B may be “TimeWarner SetTop.” Alternately, the name field 58 may contain a link or reference to a graphical image that depicts a particular type of media controller 12. The nodal data 32 can include a description field 60 that provides a short textual description of the capabilities of the respective media controller 12. A capabilities field 62 may identify operations performable by the respective media controller 12, and power consumption characteristics. A serial number field 64 may contain a unique manufacturer serial number of the media controller 12. A manufacturer field 66 may identify the manufacturer of the media controller 12. A model field 68 may identify a particular model of the media controller 12. Logs field 70 may comprise data generated during the operation of the media controller 12, such as, for example, faults or errors that occur during the operation of the media controller 12, and/or input selections received from viewers 14, which programs were watched at which times, and the like.
A service field 72 may contain service status information regarding the media controller 12 such as service intervals and/or wear counts. The wear count may indicate how many times particular “wear items” have been used. For example, a media controller 12 containing a hard drive may provide a wear count on the hard drive indicating how many times the hard drive has been written to. This information may in turn be used to predict how much useful life is left on the drive. A state field 74 may contain a status of the media controller 12, such as, for example “Booting”, “On”, “Recording”, “Sleep”, “Updating”, and the like. A location field 76 may identify a location of the media controller 12 within the locale 10. For example, the location field 76 of the media controller 12A may contain “Den”, and the location field 76 of the media controller 12B may contain “Living Room.” The nodal data 32 may also include a preference settings field 78 identifying preferences of one or more viewers 14. Any desired preference data may be stored in the preference settings field 78, such as, for example, genre preferences, actor preferences, time preferences, series preferences, and the like. Preference data may be used, for example, by the media controller 12 to provide program recommendations to a viewer 14.
FIG. 5 is a block diagram of the recorder 36 according to one embodiment. The recorder 36 receives a source 80 from the tuner 34. The recorder 36 uses an encoder 82 to encode the source 80 in a desired format, such as the MPEG-2 format. The encoded program can be stored in the storage 38. The recorder 36 may include a buffer 84 for use in temporarily storing segments of the source 80 while it is being encoded.
FIG. 6 is an exemplary block diagram of a merged guide 30 according to one embodiment. The format of the merged guide 30 depicted in FIG. 6 is but one exemplary layout, and the embodiments are not limited thereto. The merged guide 30 may include a plurality of channel records 86, such as channel records 86-1-86-N. The phrase “record” as used throughout the disclosure means a structure which contains data and may be stored and accessed as necessary, and does not imply a particular format or internal layout. The channel record 86-1 may include an information field 88 that contains text identifying source attributes of the channel, such as the particular service provider, or other source. For example, if the channel 86-1 is provided by a service provider via cable, the information field 88 may contain the name of the cable company. Alternately, the channel information field 88 may contain the ultimate source of the content associated with the channel, such as NBC, ABC, and the like. Where the content associated with the channel is provided by a local source, such as the entertainment library 24, the channel information field 88 may identify the entertainment library 24 by a name, such as “John's Video Library.” The channel 86-1 may also include a rating field 90 that generally describes the content associated with the channel 86-1. For example, if the channel 86-1 is a mature adult channel, the rating field 90 may identify it as such.
Each channel 86 may include one or more program records 92. For example, the channel 86-1 contains a plurality of program records 92-1-92-N. Each program record 92 contains metadata associated with a particular program. Thus, each program record 92 corresponds to a particular program. The program record 92 may contain a GUID field 94 that contains a GUID which uniquely identifies the program. A title field 96 may contain a textual title of the program. A start field 98 may identify a present, past or future start time of the program. A duration field 100 identifies a length of the program. A rating field 102 may contain an MPAA rating of the program. A quality field 104 may identify the encoding quality of the program. An alt location field 106 may contain an alternate location of the program other than the location identified in the source field 116. For example, the location identified in the source field 116 may be the source of a highest quality version of the program, while the alt location field 106 may provide a lower quality version of the program. In one embodiment, a uniform resource identifier (URI) represents the location indicated by the source field 116 and alt location field 106. The URI may point to a local media item, or may reference a program available from another media controller 12 over the network.
A requestors field 108 may contain information identifying one or more viewers 14 that have requested that the program be recorded. A viewers list 110 may identify one or more viewers 14 that were identified as being in proximity to the media controller 12 which presented the program. A metadata GUID field 112 may contain a metadata GUID which uniquely identifies a metadata record containing metadata describing additional attributes of the program. The metadata record may exist, for example, on a local or a remote server accessible by the media controller 12. An originator field 115 may identify the particular media controller 12 which originated the respective program record 92. A record update timestamp (TS) field 114 may contain a timestamp identifying the time of the last update to the record 92-1. A source field 116 may identify a location of the program, and may comprise, for example, a URI.
The program record 92 may also include an operation field 117 for identifying a particular operation performed on the corresponding program by the media controller identified in the originator field 115. For example, the operation field 117 may contain a value of 0 to indicate that no operation was performed on the program, a value of 1 to indicate the program was recorded, a value of 2 to indicate the program was presented to a viewer 14, and a value of 3 to indicate that the program was both recorded and presented to a viewer 14. Where the operation value is greater than zero, and where the media controller 12 identified in the originator field 115 has multiple tuners, the originator field 115 may also identify the particular tuner 34 that performed the identified operation. The operation field 117 may be used by the media controller 12 to relatively rapidly determine which program records 92 may be useful for determining the previous usage data associated with another media controller 12. More particularly, upon receipt of a program record 92 having an operation value greater than zero, the media controller 12 may generate a copy of the program record 92 and store the copy in the previous usage data 25. The use of separate previous usage data 25, while optional, provides a mechanism to store for desired periods of time previous usage data associated with other media controllers 12, while allowing the merged guide 30 to maintain historical program records 92 for a much shorter duration.
Preferably, each media controller 12 coupled to the network 26 generates program records 92 for each program that is available at the respective media controller 12. For example, referring again to FIG. 1, local guide 20A may include guides for programs available from the content providers 18A and 18B. The media controller 12A may read the local guide 20A and generate a program record 92 for each program identified in the local guide 20A. The media controller 12A may also generate program records 92 for each recorded program 22A, and each item available for presentation from the entertainment library 24A. If program metadata for such programs is unavailable, the media controller 12A may access well-known sources of program metadata from, for example, an Internet provider of such data, and use the program metadata to populate the fields of the program record 92.
FIG. 7 is a flowchart illustrating an exemplary method for generating program records 92. Assume that the media controller 12A is traversing a local guide 20A, and determines that the local guide 20A identifies a program that is not identified in the merged guide 30A. For example, the content provider 18A may have recently provided the media controller 12A new program guide data that identifies programs that will be available for presentation one week from the present date. The media controller 12A generates a program record 92 (step 1000). The media controller 12A then generates a GUID that uniquely identifies this program (step 1002). The media controller 12A then populates the fields described above with regard to FIG. 6 with the appropriate data (step 1004). The media controller may insert the current time in the record update timestamp field 114. The media controller 12A then stores the program record 92 in the merged guide 30 (step 1006).
Each media controller 12 preferably provides program metadata from the program records 92 which are available from the respective media controller 12 to the other media controllers 12. For example, referring again to FIG. 1, the media controller 12A provides the media controller 12B program metadata from each of the program records 92 stored in the merged guide 30A. The media controller 12B similarly provides the media controller 12A program metadata from each of the program records 92 in the merged guide 30B. In this manner, each media controller 12 contains program records 92 identifying programs available at not only the respective media controller 12, but which are available at all media controllers 12 coupled to the network 26.
The program metadata may be provided in the same format as the program records 92, or in a different format. The program metadata may be “pushed” as desired by a media controller 12 to the other media controllers, or may be “pulled” from a media controller 12 upon request. In one embodiment, the program metadata may be provided in an XML file, which may have a format similar to the program record 92. In one embodiment, a media controller 12 may broadcast a signal on the network 26 to indicate that new program metadata is available. Referring again to FIG. 1, assume that the media controller 12A has generated one or more new program records 92. The media controller 12A may broadcast a signal on the network 26 indicating that the media controller 12A has new program metadata for distribution. The media controller 12B, upon receipt of the signal, may send a message to the media controller 12A requesting the program metadata. According to one embodiment, each media controller 12 may maintain a last update timestamp for each other media controller 12. Such last update timestamps may be maintained in the update timestamp data 44 (FIG. 2) associated with the respective media controller 12.
FIG. 8 is a block diagram illustrating exemplary update timestamp data 44 according to one embodiment. The update timestamp data 44 may include one or more last update timestamps 120-1-120-N (generally, last update timestamps 120), each of which may correspond to a respective media controller 12. The last update timestamps 120 identify the time of the last update of program metadata from the corresponding media controller 12. For purposes of illustration with regard to FIG. 8, a media controller 12 that has program metadata to provide to another media controller 12 will be referred to as a publishing media controller 12, and the media controller 12 receiving the program metadata will be referred to as a receiving media controller 12. The receiving media controller 12 may use a last update timestamp 120 to indicate to the publishing media controller 12 which program records 92 are needed. For example, in the current example, assume that the last update timestamp 120-1 corresponds to the publishing media controller 12. The receiving media controller 12 may provide the last update timestamp 120-1 to the publishing media controller 12 to indicate to the publishing media controller 12 that the receiving media controller 12 only requires program metadata from those program records 92 that contain a record update timestamp more recent than the last update timestamp 120-1. The publishing media controller 12 may thus use the last update timestamp 120-1 to generate an XML file containing only program metadata for those program records 92 which have a record update timestamp that is more recent than the last update timestamp 120-1. The receiving media controller 12 receives, and then processes, the program metadata and updates the last update timestamp 120-1 with the latest record update timestamp associated with any program record 92 provided by the publishing media controller 12.
FIG. 9 is a flowchart illustrating an exemplary method for receiving and processing program metadata sent from one media controller 12 to another media controller 12. FIG. 9 will be discussed in conjunction with FIGS. 1 and 6. Again, for purposes of illustration with regard to FIG. 9, the media controller 12A will be assumed to have program metadata to distribute to the media controller 12B, and will be referred to as the publishing media controller 12A, and the media controller 12B will be referred to as the receiving media controller 12B. The publishing media controller 12A broadcasts a notification that the publishing media controller 12A has new program metadata available for distribution. The receiving media controller 12B receives the notification (step 2000). The receiving media controller 12B obtains the last update timestamp 120-1 which corresponds to the publishing media controller 12A (step 2002). The receiving media controller 12B generates a request containing the last update timestamp 120-1 and sends the request to the publishing media controller 12A (steps 2004, 2006). The publishing media controller 12A uses the last update timestamp 120-1 to select program metadata from each program record 92 having a record update timestamp that is later than the last update timestamp 120-1. The publishing media controller 12A formats the program metadata and sends it to the receiving media controller 12B.
The receiving media controller 12B receives the program metadata (step 2008). The receiving media controller 12B may, for each program identified by the program metadata, attempt to match the program metadata to an existing program record 92 in the merged guide 30B (step 2010). What constitutes a “match” may be system dependent. Generally, the receiving media controller 12B may determine if various data in the provided program metadata matches corresponding data in any existing program record 92. For example, the receiving media controller 12B may determine that the program identified by the metadata matches a program identified by a program record 92 if the data from the title fields 96 match one another and the data from the start fields 98 match one another.
If the receiving media controller 12B determines that the provided program metadata matches a program identified by a program record 92 (step 2012), then the receiving media controller 12B may generate a child program record 92 from the supplied program metadata, such that the matched program record 92 in the merged guide 30A is stored in association with the child program record 92 (step 2014). Among other advantages, establishing such a parent-child relationship between program records 92 enables the receiving media controller 12B to cause the display of information to a viewer 14 that the same program is available at multiple media controllers 12. If the receiving media controller 12B determines that the program metadata does not match any existing program identified in a program record 92 (step 2012), the receiving media controller 12B may generate a program record 92 as a parent program record 92 that is not a child program record 92 to any other program record 92 (step 2016). While for purposes of illustration only two program records 92 have been shown as stored in association with one another, it is apparent any number of program records 92 that identify the same program may be stored in association with one another.
FIG. 10 is a flowchart illustrating an exemplary method for sending program metadata to another media controller. Assume again that the publishing media controller 12A has new program metadata to distribute. The publishing media controller 12A broadcasts a notification signal onto the network 26 indicating that new program metadata is available (step 3000). The publishing media controller 12A receives a request for data from the receiving media controller 12B (step 3002). The publishing media controller 12A obtains the last update timestamp 120-1 from the request for data (step 3004). The publishing media controller 12A obtains program metadata from those program records 92 having a record update timestamp greater than the last update timestamp 120-1 (step 3006).
FIGS. 11 and 12 are block diagrams illustrating exemplary relationships between several program records 92. FIG. 11 illustrates that at a first point in time, the merged guide 30A contains a plurality of program records 92A-92C, each of which may be considered a parent program record 92. Similarly, the merged guide 30B contains a plurality of program records 92D-92F, each of which may also be considered a parent program record 92. FIG. 12 illustrates an exemplary relationship between program records 92 after the media controller 12A has communicated the program records 92A-92C to the media controller 12B, and has received from the media controller 12B the program records 92D-92F. As illustrated, the media controller 12A determined that the program record 92D identified the same program as identified by the program record 92A, and consequently made the program record 92D a child record to the program record 92A. The program record 92E was also determined to identify the same program as identified by the program record 92B, and was therefore similarly made a child record to the program record 92B. Because the program record 92F did not match any other program record 92 in the merged guide 30A, the program record 92F is made a parent program record 92F.
A similar analysis was conducted by the media controller 12B, and thus the program record 92A was made a child record of the program record 92D, and the program record 92B was made a child record of the program record 92E.
According to one embodiment, the media controller 12 may determine the identity of the viewers 14 that are in proximity to the media controller 12. This information may be stored in the viewers list 110 of the program records 92 for the corresponding programs that are presented by the media controller 12. FIG. 13 is a block diagram illustrating exemplary mechanisms that may be used by a media controller 12 to determine the identity of a particular viewer. The media controller 12A in a den 118 is communicatively coupled to an input device 128. As the viewers 14A, 14B enter the den 118, each viewer 14A, 14B uses the input device 128 to indicate that the respective viewer 14A, 14B is in the den 118 and watching programming presented by the media controller 12A. Prior to exiting the den 118, each viewer 14A, 14B may use the input device 128 to indicate they are departing the den 118. The media controller 12A may maintain the identity of the viewers 14 who are in the den 118, and for each program provided during the presence of a viewer 14, update the viewers list 110 in the program record 92 corresponding to the presented program. The input device 128 may comprise any suitable device and interface, such as a keyboard, or a mouse and a computer having a user interface that enables a viewer 14 to simply click on a designated portion of a display to indicate the presence or departure of the viewer 14 from the den 118. The computer may be wirelessly coupled to the media controller 12A, and communicate the status of incoming and outgoing viewers 14 to the media controller 12 as appropriate.
The media controller 12B in the living room 122 includes a facial recognition processor 130 that is able to identify through facial processing technology the viewers 14C-14E. Facial recognition technology is known to those skilled in the art, and will not be described in detail herein. The facial recognition processor 130 communicates the identity of the viewers 14C-14E to the media controller 12B. While the facial recognition processor 130 is illustrated as being integral with the media controller 12B, in an alternate embodiment, the facial recognition processor 130 may be separate from but coupled to media controller 12B via a wired or wireless communications channel, for example.
The media controller 12C in a bedroom 124 includes a radio frequency identification (RFID) processor 134. The RFID processor 134 may receive a signal from a device worn, or carried, by the viewer 14F. For example, a cell phone of the viewer 14F may emit a signal that can be received by the RFID processor 134. Upon receipt of such signal, the RFID processor 134 can communicate the identity of the viewer 14F to the media controller 12C.
The media controller 12D in a basement 126 is coupled to a wireless Bluetooth interface which enables the media controller 12D to communicate with Bluetooth devices, such as a cell phone, that contain the appropriate software to interface with the media controller 12D. Such software may be programmed to emit a signal that can be detected by the media controller 12D via the wireless Bluetooth interface 132. The signal may contain an identifier identifying a particular viewer 14G, 14H. The media controller 12D may periodically poll the cell phone to determine if the viewer 14G, 14H is still in proximity of the media controller 12D. If the media controller 12D does not receive a response to the poll, the media controller 12D may determine that the viewers 14G, 14H are no longer in proximity of the media controller 12D.
FIG. 14 is a flowchart illustrating an exemplary method for storing viewer information into a program record 92. The media controller 12 determines that a new viewer 14 is in proximity to the media controller 12, and identifies the new viewer 14 (step 4000). The media controller 12 may use one of the mechanisms described with regard to FIG. 13, or any other suitable mechanism. The media controller 12 obtains the program record 92 corresponding to the program that is currently being provided for display by the media controller 12 (step 4002). The media controller 12 updates the viewer list 110 of the program record 92 to include an identification of the new viewer 14 (4004). Preferably, the media controller 12 also updates the record update timestamp of the program record 92. The media controller 12 stores the program record 92 in the merged guide (step 4006). Note that the media controller 12 may also broadcast a notification signal to the network 26 to notify other media controllers 12 that the media controller 12 has new program metadata to distribute. In this manner, each media controller 12 coupled to the network 26 may be, substantially in real-time, provided data that identify who, in which room, is watching which programs.
According to another embodiment, the one media controller 12 may send requests to another media controller 12 for information, or to direct the other media controller 12 to provide a desired function. FIG. 15 is block diagram illustrating certain requests that one media controller 12 may make of another media controller 12 according to one embodiment. For example, the media controller 12A may send an IDENTIFY_CURRENT_PROGRAM request 142 to the media controller 12B. An IDENTIFY_CURRENT_PROGRAM request 142 requests that the media controller 12B identify the specific program that is currently being provided by the media controller 12B. In response, the media controller 12B may provide the media controller 12A the program record 92 corresponding to the program that the media controller 12B is currently presenting. The media controller 12A may send the media controller 12B a RECORDING_STATUS request 144, which requests information regarding the recording status of the program that is currently being presented by the media controller 12B. In response, the media controller 12B provides a message indicating whether the current program being provided by the media controller 12B is being recorded.
The media controller 12A may send the media controller 12B a RECORD PROGRAM REQUEST 146, which requests that the media controller 12B schedule the recording of a particular program. The RECORD PROGRAM REQUEST 146 may include the program record 92 corresponding to the program that is to be recorded. In response, the media controller 12B may determine that no tuner is available to record the program, or may begin recording the desired program, or may schedule the desired program for recording if the program has not begun yet, and if an availability probability of a tuner exceeds an availability threshold, as discussed in greater detail herein. The media controller 12B may provide the media controller 12A a message indicating success or failure of the request. The media controller 12A may send the media controller 12B a PROVIDE_CURRENT_PROGRAM request 148, which requests that the media controller 12B provide a program stream of the program that is currently being provided by the media controller 12B. The media controller 12B, using the retransmitter 40, may then provide a program stream of the program which is currently being provided by the media controller 12B.
Tuner conflicts may arise during the operation of a media controller 12. For example, the media controller 12 may have a single tuner 34, and the viewer 14 may desire to record two programs in the future concurrently. If the media controller 12 has only a single tuner 34, the media controller 12 is able to only record a single program at a time. In one embodiment, to resolve such a tuner conflict, the previous usage data of another media controller 12 is processed to determine if the media controller 12 can schedule the recording of one of the two programs.
FIG. 16 is a flow chart illustrating an exemplary method for determining if another media controller 12 is available to schedule a recording of a program. FIG. 16 will be discussed in conjunction with FIG. 1. Assume for purposes of illustration that the viewer 14 requests the media controller 12A to record two programs concurrently during the same future time slot (step 5000). The media controller 12A contains a single tuner 34 and determines a tuner conflict exists because the media controller 12A can only record a single program at a time (step 5002). A similar situation may arise even without input from the viewer 14 where, for example, a first program has been scheduled to be recorded by the media controller 12A at a future (but imminent) time, and the viewer 14 is watching a program on a second channel minutes prior to the scheduled recording of the first program. The media controller 12A similarly may detect that recording the first program is likely to conflict with the viewer's 14 current use of the media controller 12A.
The media controller 12A may determine if other media controllers 12, such as the media controller 12B, are currently communicatively coupled to the network 26 (step 5004). Device discovery mechanisms are known to those skilled in the art and will not be described in detail herein. For example, the media controller 12A may use the Bonjour® service discovery protocol to discover the media controller 12B, but the embodiments are not limited to any particular device discovery mechanism. If no other media controllers 12 are available, the media controller 12A may cause a display to the viewer 14 identifying the conflict, thereby enabling the viewer 14 to resolve the conflict by selecting one program over another program (step 5006). If another media controller 12 is available, such as the media controller 12B, the media controller 12A may then access the previous usage data 25A (generally, previous usage data 25) to determine previous usage associated with the media controller 12B (step 5008). For example, the previous usage data 25A may include data extracted from program records 92 wherein the value of the operation field 117 is greater than zero. Such data may identify previous usage of the media controller 12B. For purposes of illustration, assume that the media controller 12B similarly contains only a single tuner 34B.
The media controller 12A determines an availability probability for the media controller 12B (step 5010). The availability probability may be used to determine whether the tuner 34B is likely to be available during the desired time slot. Exemplary mechanisms for determining an availability probability will be discussed herein with respect to FIG. 17. The availability probability may comprise any indicator used to determine whether or not a media controller 12 is available to record a program at a future time based on previous usage data. The availability probability may, for example, comprise a numeric representation identifying a probability of availability of the media controller 12B to record a program at a future time. In one embodiment the availability probability is based on a percentage, and will be discussed herein in terms of a percentage, or decimal representation of a percentage. For example, if a probability that the media controller 12B will be available during the desired time slot is 70% (i.e., 0.70), then the availability probability of the media controller 12B is 70% (or 0.70). Where a media controller 12 has a single tuner 34, the availability probability of the tuner 34 is the same as the availability of the media controller 12. Where a media controller 12 has multiple tuners 34, the availability probability of the media controller 12 is a function of the availability probability of each of the tuners 34.
The media controller 12A determines if the availability probability of the media controller 12B exceeds an availability threshold (step 5012). The availability threshold may be a configurable value that may be adjustable by an administrator of the network 26, or by a service provider. The availability threshold may be relatively high to decrease the likelihood that the receiving media controller 12, i.e., the media controller 12B in this example, will encounter a tuner conflict at the time of the scheduled recording. For example, an availability threshold of 90 indicates that the media controller 12B is not available to schedule the recording unless the availability probability exceeds 90%. Alternately, a low availability threshold may be used to facilitate eliminating a current tuner conflict at the media controller 12A at the potential risk of increasing the likelihood of a tuner conflict on the media controller 12B at the time of the scheduled recording.
If the availability probability does not exceed the availability threshold (step 5012), the process returns to step 5004 where it is determined if another media controller 12 may be available to schedule the recording. Otherwise, if the availability probability exceeds the availability threshold (step 5012), the media controller 12A may send the media controller 12B a request to schedule the recording of the program (step 5014). In one embodiment, the media controller 12B may accept or reject such a request. If the media controller 12B rejects the request (step 5016), the process returns to step 5004 where it is determined if another media controller 12 may be available to schedule the recording. If the media controller 12B accepts the request, the media controller 12A may update the recording schedule 23A to reflect that the program will not be recorded by the media controller 12A.
The phrase time slot is used herein to generally refer to a particular period of time. A future time slot, for example, may refer generally to a future period of time during which a program may be scheduled to be provided to a media controller 12. For example, the time slot corresponding to a particular program, such as the Survivor series, may be the 8:00-8:59 time slot. A time slot preferably has a begin time and an end time, although the begin time and end times may vary. For example, generally Survivor is scheduled to be provided in the 8:00 ET time slot, however, due to advertising and the like, may on particular dates begin at 8:01 or 8:02. While time slots will be referred to herein generally as an hourly time slot, e.g., from 8:00-8:59 or 8:00-9:00, it will be apparent that time slots may be any desired length of time, such as 30 minutes.
FIG. 17 is a block diagram of an exemplary media controller usage (MCU) record 150 for storing previous usage data associated with a media controller 12. FIG. 17 will be discussed in conjunction with FIG. 1. Previous usage data, as described herein, may be stored in multiple formats. For example, as discussed previously, previous usage data may be provided by each media controller 12 in the form of program records 92. Each program record 92 identifies a particular previous usage of the media controller. Such information may also be consolidated based on a desired criteria, such as based on the day of the week of a previous usage, and the time slot associated with a previous usage. The MCU record 150 may be generated, for example, by consolidating information contained in multiple program records 92 over a predetermined period of time, such as the previous four weeks, or previous six weeks, for example. In particular, the media controller 12A may process each program record 92 having an operation value greater than zero for each media controller 12 coupled to the network 26 that was created within the previous six weeks. The MCU record 150 is an example of one such consolidation, in particular, a consolidation based on tuner, day of the week, and time slot. However, embodiments are not limited to any particular consolidation of information.
Moreover, while embodiments have thus far been discussed in conjunction with the use of the merged program guide 30, it should be apparent that media controller previous usage data identifying previous usage activity of the media controller 12B could be generated and broadcast to other media controllers 12 without the existence of the merged guide 30. For example, a previous usage data record may be defined that includes information such as the start field 98, the duration field 100, the originator field 115 and the operation field 117. Each time an operation on the media controller 12B occurs, the media controller 12B could generate a previous usage data record and broadcast the record to the other media controllers 12 on the network. Each recipient media controller 12 could then use the data to maintain a MCU record 150 for the media controller 12B.
For purposes of illustration assume that the media controller 12A has determined that a tuner conflict exists with regard to a request to schedule the recording of a program during a 23:00-23:59 time slot on Monday. Assume that the MCU record 150 contains information corresponding to the media controller 12B. The media controller 12A may continually update the MCU record 150 with new information as it is received from the media controller 12B.
The MCU record 150 includes a tuner usage record 152 for each tuner 34 contained in the media controller 12B. In this example, assume that the media controller 12B contains two tuners 34, and thus the MCU record 150 includes a tuner usage record 152A and a tuner usage record 152B (generally, the tuner usage record 152 or the tuner usage records 152). Each tuner usage record 152 includes seven usage-by-day (UBD) records 154. The tuner usage record 152A thus contains UBD records 154A-1-154A-7. Each UBD record 154A contains previous usage data associated with a particular weekday. The tuner usage record 152B similarly contains UBD records 154B-1-154B-7. Each UBD record 154 contains a plurality of usage-by-time slot (UBT) records. Assuming hourly time slots, for example, the UBD record 154A-1 contains 24 UBT records 156-1-156-24. Thus each UBT record 156 contains previous usage data associated with a particular hour of the particular day corresponding to a UBD record 154. Similarly, the UBD record 154A-7 contains 24 UBT records 158-1-158-24. Each UBT record 156, 158, 160, and 162 identifies a usage factor of the respective tuner during a particular time slot. The usage factor may represent the frequency, by percentage, that the corresponding tuner 34 is busy either presenting a program for display to a viewer or recording a program during the respective time slot. Alternately, the usage factor may represent the frequency that the corresponding tuner 34 is not busy.
Assuming that the usage factor represents the frequency, by percentage, that the corresponding tuner 34 is busy, the availability probability (AP) of the tuner 34 during the respective time slot can thus be determined by the following formula:
AP_Tuner _— _Timeslot=(1−usage factor_Timeslot)

- AP_Tuner _— _Timeslotis the availability probability of a tuner for a particular day of the week and a particular time slot of that day of the week, and usage factor_Timeslotis the usage factor associated with that tuner during that day of the week and at that time slot.

For example, the AP of Tuner A (tuner usage record 152A) during Time Slot 24 of Day 1 (Monday) indicated by the UBT record 156-24 may be calculated in the following manner:
AP_TunerA _— _Timeslot24=(1−0.23)=0.78=78%
Similarly, the AP of Tuner B (tuner usage record 152B) during Time Slot 24 of Day 1 (Monday) indicated by the UBT record 160-24 during Time Slot 24 of Day 1 (Monday) indicated by the UBT record 160-24 may be calculated in the following manner:
AP_TunerB _— _Timeslot24=(1−0.92)=0.08=8%
It is apparent each UBT record 156-162 could contain the availability probability rather than the usage factor. To derive or otherwise determine the aggregate availability probability of a media controller for a particular time slot the following formula may be used:
AP_{mediacontroller}=Sum(AP_{each tuner})/number of tuners
In the present example, assuming the media controller 12B contains two tuners 34, the following formula may be used:
$\begin{matrix} {AP}_{mediacontroller 12 B} = ({AP}_{TunerA_Timeslo t 24} + {AP}_{TunerB_Timeslo t 24}) / 2 \\ = (.78 + .08) / 2 \\ = .43 \\ = 43 % \end{matrix}$
The media controller 12A also preferably accesses the recording schedule 23B of the media controller 12B. The recording schedule 23B identifies the scheduled recordings of the media controller 12B. The recording schedule 23B may identify that the one or both tuners 34 may be busy during the 23:00-23:59 time slot on Monday recording a program, and may identify the particular programs that are scheduled to be recorded. If the media controller 12A determines that both tuners 34 of the media controller 12B are scheduled to record a program during the 23:00-23:59 time slot on Monday, the media controller 12A may determine the availability probability is 0 for the media controller 12B prior to even accessing the MCU record 150. However, if the media controller 12A determines from the recording schedule 23B that the program which the media controller 12A would like the media controller 12B to schedule for recording is already scheduled for recording on the media controller 12B, the media controller 12A may determine the availability probability is 100.
Where the recording schedule 23B indicates that one tuner 34 will not be available due to a scheduled recording, the availability probability may be calculated as the lowest availability probability of either of the tuners 34.
FIG. 18 is block diagram of embodiments implemented in a client server architecture. Each media controller 12 sends previous usage records identifying previous usage of the respective media controller 12 to a computer server 164, which stores such information in the media controller previous usage data 25. If a merged guide 30 is maintained on the server 164, the information may be provided in program records 92 as discussed previously. If embodiments are being implemented in the absence of a merged guide 30, a previous usage data record may be defined that includes information such as the start field 98, the duration field 100, the originator field 115 and the operation field 117, as discussed previously, to provide such information to the server 164.
FIG. 19 is a flow chart illustrating an exemplary method for determining if another media controller 12 is available to schedule the recording of a program in the client-architecture illustrated in FIG. 18. FIG. 19 will be discussed in conjunction with FIG. 18. Assume for purposes of illustration that a viewer requests the media controller 12A to record two programs concurrently during the same time slot. The media controller 12A contains a single tuner 34 and determines a conflict exists because the media controller 12A can only record a single program at a time. The media controller 12A sends a request to the server 164 to locate another media controller 12 for scheduling the recording of one of the programs. The request may include information such as the program name, the day and time slot, the channel, and any other suitable information. The server 164 receives the request (step 6000). The server 164 determines if other media controllers 12 are present on the network (step 6002). Assume that the media controller 12B is present. The server 164 obtains the previous usage data of the media controller 12B from the media controller previous usage data 25 (step 6004). For example, the server 164 may obtain a MCU record 150 corresponding to the media controller 12B.
The server 164 determines the availability probability for the media controller 12B (step 6006). The availability probability may be determined as discussed previously with regard to FIG. 16, and for the sake of brevity will not be repeated again herein. The server 164 determines if the availability probability of the media controller 12B is greater than the availability threshold (step 6008). The availability threshold may have been included in the request from the media controller 12A, or may apply to all media controllers 12 and be stored on the server 164. If the availability probability is not greater than the availability threshold, the process may return to step 6002 where the server 164 determines if there are other present media controllers 12. If the availability probability of the media controller 12B is greater than the availability threshold, the identity of the media controller 12B may be stored in an available media controllers list (step 6010). In one embodiment, as soon as any media controller 12 is determined to be available to schedule a recording, the identity of the media controller 12 is provided to the media controller 12A. In another embodiment, the availability probability of each media controller 12 coupled to the network 26 may be determined, and each media controller 12 that is determined to be available to schedule a recording is identified to the media controller 12A.
At step 6002, if no other media controllers 12 are present then the server 164 determines whether any media controllers 12 were identified as being available to schedule the recording of the program (step 6012). If not, the server 164 may send the media controller 12A a message indicating that there are no available media controllers 12 to schedule the recording of the program (step 6014). Otherwise, the server 164 sends the media controller 12A a message identifying the available media controllers 12. The media controller 12A may select one of the available media controllers 12, and send the selected media controller 12 a request to schedule the recording of the program. In another embodiment, rather than identify the available media controllers 12 to the media controller 12A, the server 164 may select an available media controller 12 and send the selected media controller 12 a request to schedule the recording of the program. Upon receipt of a confirmation from the selected media controller 12, the server 164 may then identify the selected media controller 12 to the media controller 12A, indicating that the selected media controller 12 has scheduled the recording of the program.
FIG. 20 is block diagram of another exemplary embodiment implemented in a peer-to-peer architecture. Similar to FIG. 1, each media controller 12 may have a merged guide 30 containing program records 92 of all media controllers 12 coupled to the network. However, as discussed previously, the merged guide 30 is optional, and embodiments may be practiced in the absence of the merged guide 30. In the exemplary embodiment illustrated in FIG. 20, each media controller 12 contains media controller previous usage data 25 that contains previous usage data associated with the respective media controller 12, rather than previous usage data of other media controllers 12. For example, the media controller previous usage data 25A includes previous usage data of the media controller 12A, and the media controller previous usage data 25B includes previous usage data of the media controller 12B.
FIG. 21 is a flow chart illustrating an exemplary method for determining if another media controller 12 is available to schedule a recording of a program in the exemplary peer-to-peer architecture illustrated in FIG. 20.
FIG. 21 will be discussed in conjunction with FIG. 20. Assume for purposes of illustration that a viewer 14 requests the media controller 12A to record two programs concurrently during the same time slot. The media controller 12A contains a single tuner 34 and determines a conflict exists because the media controller 12A can only record a single program at a time. The media controller 12A sends a request to the media controller 12B scheduling the recording of one of the programs. The request may include information such as the program name, the day and time slot, the channel, and any other suitable information.
If the media controller 12A includes the merged guide 30A, the media controller 12A may provide the program record 92 corresponding to the program that is to be recorded. The media controller 12B receives the request (step 7000). The media controller 12B obtains the previous usage data of the media controller 12B from the media controller previous usage data 25B (step 7002). The media controller 12B determines the availability probability for the media controller 12B (step 7004). The availability probability may be determined as discussed previously with regard to FIG. 16, and for the sake of brevity will not be repeated again herein. The media controller 12B determines if the availability probability of the media controller 12B is greater than the availability threshold (step 7006). If so, the media controller 12B may schedule the recording of the program (step 7008). The media controller 12B may then update the recording schedule 23B (step 7010). The media controller 12B sends an acceptance message to the media controller 12A (step 7012). If the availability probability of the media controller 12B is less than the availability threshold (step 7006), the media controller 12B may send the media controller 12A a denial message indicating the media controller 12B is not available to record the program (step 7014).
FIG. 22 illustrates a window 168 which may be displayed on the display device 16 according to one exemplary embodiment. Assume again for purposes of illustration that a viewer 14 requests the media controller 12A to record two programs concurrently during the same time slot. The media controller 12A contains a single tuner 34 and determines a conflict exists because the media controller 12A can only record a single program at a time. Assume that the media controller 12A determines that two media controllers 12 are coupled to the network 26 that are available for scheduling a recording of one of the programs. The media controller 12A may have determined this in conjunction with the server 164 (FIG. 18), may have determined it by examining the remote media controller previous usage data 25A containing previous usage data of other media controllers 12 (FIG. 1), or may have determined it by asking each other media controller 12 if the media controller 12 is available to schedule the recording of the particular program.
FIG. 23 is a flowchart illustrating an exemplary method for providing a viewer 14 an option to select another media controller 12 to resolve a tuner conflict. FIG. 23 will be discussed in conjunction with FIG. 22. The media controller 12A causes a display of the window 168 on the display device 16A (step 8000). The window 168 may identify to the viewer 14 that a conflict exists, and identify that a media controller 12 identified as the “DEN DVR” and a media controller 12 identified as the “BEDROOM DVR” are each available for recording the selected program. The viewer 14 may select one of the identified media controllers 12 by, for example, actuating a check box adjacent to the selected media controller 12, and actuating a “Use Selected” button. Alternatively, the viewer 14 may allow the media controller 12A to select the media controller 12 by actuating a “Select One” button. Assume that that the viewer 14 selects the DEN DVR (step 8002). The media controller 12A may then send the DEN DVR media controller 12 a request to schedule the recording of the program (step 8004). The media controller 12A may then update the recording schedule 23A as appropriate (step 8006).
In one embodiment, after a media controller 12 records a program, it may transfer the recorded program over the network 26 to the media controller 12 which requested that it be recorded. Thus, the window 168 may include a “copy back” option which the viewer 14 may actuate to indicate that the viewer 14 would like the DEN DVR media controller 12 to transmit the recorded program to the media controller 12A upon completion of the recording. This may be communicated by the media controller 12A to the DEN DVR media controller 12 in the request to schedule the recording of the program.
In one embodiment, the media controller 12 may implement all or part of the Universal Plug and Play (UPnP) set of networking protocols. One media controller 12 may serve as a UPnP control point when requesting another media controller 12 to schedule the recording of a program, for example. Each media controller 12 may implement at least certain UPnP services, such as ConnectionManager, to enable the streaming of programs from one media controller 12 to another media controller 12, ContentDirectory to provide access to the recorded music and videos at a media controller 12, and ScheduledRecordings to allow each media controller 12 access to the recording schedule 23 of the other media controllers 12.
FIG. 24 illustrates an exemplary processing device 170 which may be used to implement a media controller 12, or a server 164, according to some embodiments. The processing device 170 may, when implementing a media controller 12, comprise a set top box, a digital video recorder, an intelligent gaming console, such as the Microsoft® Xbox®, Sony® PlayStation®, and Nintendo® GameCube®, a media console such as the Apple® TV®, personal computers, and the like. In addition to components discussed previously herein, the exemplary processing device 170 may also include a central processing unit 172, a system memory 174, and a system bus 176. The system bus 176 provides an interface for system components including, but not limited to, the system memory 174 and the central processing unit 172. The central processing unit 172 can be any of various commercially available or proprietary processors. Dual microprocessors and other multi-processor architectures may also be employed as the central processing unit 172.
The media controller 12 may include one or more tuners 34 for selecting program content from a communications channel. The recorder 36 may receive a source input from the tuner 34 and store the content onto a storage device, such as the storage 38. The retransmitter 40 may provide a stream of program content over the network 26 to another media controller 12.
The system bus 176 can be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 174 can include non-volatile memory 178 (e.g., read only memory (ROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), etc.) and/or volatile memory 180 (e.g., random access memory (RAM)). A basic input/output system (BIOS) 182 can be stored in the non-volatile memory 178, which can include the basic routines that help to transfer information between elements within the processing device 170. The volatile memory 180 can also include a high-speed RAM such as static RAM for caching data.
The processing device 170 may further include a storage 38, which may comprise, for example, an internal hard disk drive (HDD) (e.g., enhanced integrated drive electronics (EIDE) or serial advanced technology attachment (SATA)) for storage. The processing device 170 may further include an optical disk drive 184 (e.g., for reading a compact disk or DVD 186). The drives and associated computer readable media provide non-volatile storage of data, data structures, computer-executable instructions, and so forth. For the processing device 170, the drives and media accommodate the storage of any data in a suitable digital format. Although the description of computer-readable media above refers to an HDD and optical media such as a CD-ROM or DVD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as Zip disks, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used in the exemplary operating environment, and further, any such media may contain computer-executable instructions for performing novel methods of the disclosed architecture.
A number of program modules can be stored in the drives and volatile memory 180 including an operating system 188 and one or more program modules 190 which implement the functionality described herein. It is to be appreciated that the embodiments can be implemented with various commercially available operating systems or combinations of operating systems. All or a portion of the embodiments may be implemented as a computer program product, such as a computer usable medium having a computer-readable program code embodied therein. The computer-readable program code can include software instructions for implementing the functionality of embodiments described herein. The central processing unit 172 in conjunction with the program modules 190 in the volatile memory 180 may serve as a control system for the processing device 170 that is adapted to implement the functionality described herein.
In one embodiment, the program modules 190 may be implemented in software and stored in the volatile memory 180. However, the present disclosure is not limited thereto, and in other embodiments, the program modules 190 may be implemented in software, hardware, firmware, or any combination thereof.
A user can enter commands and information into the processing device 170 through one or more wired/wireless input devices, for example, a keyboard and a pointing device, such as a mouse (not illustrated). Other input devices (not illustrated) may include a microphone, an infrared (IR) remote control, a joystick, a game pad, a stylus pen, a touch screen, or the like. These and other input devices are often connected to the central processing unit 172 through an input device interface 192 that is coupled to the system bus 176 but can be connected by other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a universal serial bus (USB) port, an IR interface, etc.
The processing device 170 may drive a separate or integral display device 16, which may also be connected to the system bus 176 via an interface, such as a video output port 194. The processing device 170 may operate in a networked environment using a wired and/or wireless communication network interface 196. The network interface 196 can facilitate wired and/or wireless communications to the network 26 (FIG. 1).
The processing device 170 may be operable to communicate with any wireless devices or entities operatively disposed in wireless communication, for example, a printer, a scanner, a desktop and/or portable computer via wireless technologies, such as Wi-Fi and Bluetooth, for example.
Embodiments have been provided herein for purposes of illustration and explanation, but those skilled in the art will recognize that many additional and/or alternative embodiments are possible.
Those skilled in the art will recognize improvements and modifications to the embodiments. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims

1. A method for scheduling the recording of a program, comprising:

determining a program to record;

determining a time associated with the program;

obtaining an availability probability of a first media controller; and

scheduling the recording of the program with the first media controller based on the availability probability.

2. The method of claim 1, wherein determining the time associated with the program further comprises determining a time slot associated with the program, and wherein the availability probability is based on previous usage data that identifies previous usage of the first media controller during the time slot.

3. The method of claim 2, wherein the previous usage data comprises data identifying previous viewings of a plurality of programs during the time slot.

4. The method of claim 2, wherein the previous usage data comprises data identifying a previous recording of a program during the time slot.

5. The method of claim 1, wherein determining the program to record comprises:

receiving, by the first media controller, a request from a second media controller to record the program; and

wherein obtaining the availability probability of the first media controller comprises accessing previous usage data that identifies previous usage of a first tuner associated with the first media controller.

6. The method of claim 5, wherein scheduling the recording of the program based on the availability probability of the first media controller further comprises:

sending the second media controller a first message indicating that the first media controller is available to record the program based on the availability probability of the first media controller; and

scheduling the recording of the program with the first media controller upon receipt of a second message from the second media controller to schedule the recording of the program.

7. The method of claim 5, wherein obtaining the availability probability of the first media controller further comprises accessing previous usage data that identifies previous usage of a second tuner associated with the first media controller.

8. The method of claim 7, wherein scheduling the recording of the program based on the availability probability of the first media controller comprises:

determining a first availability probability associated with the first tuner;

determining a second availability probability associated with the second tuner; and

deriving the availability probability of the first media controller based on the first availability probability associated with the first tuner and the second availability probability associated with the second tuner.

9. The method of claim 8, wherein scheduling the recording of the program with the first media controller based on the availability probability of the first media controller further comprises scheduling the recording of the program with the first media controller based on a function of the availability probability of the first media controller and an availability threshold.

10. The method of claim 1, further comprising accessing a recording schedule identifying a plurality of time slots during which programs have been scheduled for recording, wherein scheduling the recording of the program with the first media controller based on the availability probability of the first media controller further comprises scheduling the recording of the program with the first media controller based on the availability probability of the first media controller and on the recording schedule.

11. The method of claim 1, further comprising determining a weekday associated with the program, wherein the availability probability is based on previous usage data that comprises data identifying previous usage of the first media controller during the weekday for each of a plurality of previous weeks, and during the same time slot.

12. A method for scheduling the recording of a program, comprising:

determining, by a first media controller, a program to record at a future time;

determining that a second media controller is available to record the program based on an availability probability of the second media controller;

causing, by the first media controller, a display of information identifying the second media controller to a viewer; and

sending, by the first media controller, a request to the second media controller to schedule the recording of the program based on input received from the viewer in response to the display.

13. The method of claim 12, wherein the availability probability is based on previous usage data that identifies previous usage associated with the second media controller, further comprising accessing the previous usage data, by the first media controller, from a local storage medium.

14. The method of claim 12, wherein determining that the second media controller is available to record the program based on the availability probability of the second media controller further comprises:

sending the second media controller a request to indicate whether the second media controller is available to record the program, wherein the second media controller accesses previous usage data that identifies previous usage associated with the second media controller on a storage medium that is local to the second media controller in response to the request.

15. The method of claim 12 wherein determining that the second media controller is available to record the program based on the availability probability of the second media controller further comprises:

determining that a third media controller is available to record the program based on an availability probability of the third media controller; and

wherein causing the display of information identifying the second media controller to the viewer further comprises causing the display of information identifying the second media controller and the third media controller to the viewer.

16. A method for identifying an available media controller for recording a program, comprising:

receiving, by a computer server, a request from a first media controller identifying a program to record;

determining, by the computer server, a time slot associated with the program;

obtaining, by the computer server, an availability probability of a second media controller;

determining that the second media controller is available to record the program based on the availability probability of the second media controller; and

sending a message to the first media controller identifying the second media controller based on determining that the second media controller is available to record the program.

17. The method of claim 16, wherein the method further comprises:

accessing previous usage data that identifies previous usage associated with a third media controller to determine an availability probability of the third media controller; and

determining that the third media controller is available to record the program based on the availability probability of the third media controller;

wherein sending the message to the first media controller comprises sending a message to the first media controller identifying the second media controller and the third media controller.

18. The method of claim 17, further comprising:

receiving a second message from the first media controller identifying the second media controller; and

in response the second message, sending the second media controller a third message to schedule the program for recording on the second media controller.

19. The method of claim 17, wherein the availability probability of the second media controller is based on previous usage data associated with the second media controller and the availability probability of the third media controller is based on previous usage data associated with the third media controller, and wherein the previous usage data associated with the second media controller and the previous usage data associated with the third media controller are stored at the computer server.

20. The method of claim 17, further comprising:

receiving a plurality of usage messages from the second media controller, wherein each of the plurality of usage messages identifies at least a time slot during which the second media controller was in use.

21. The method of claim 20, further comprising generating previous usage data associated with the second media controller from the plurality of usage messages.

22. A media controller comprising:

a network interface adapted to communicate with a network; and

a control system comprising a processor and coupled to the network interface, the control system adapted to:

determine a program to record at a future time;

determine that a second media controller is available to record the program based on an availability probability of the second media controller;

cause a display of information identifying the second media controller to a viewer; and

send a request to the second media controller to schedule the recording based on input received from the viewer in response to the display.

23. The media controller of claim 22, wherein to determine that the second media controller is available to record the program based on an availability probability of the second media controller, the media controller is further adapted to:

access previous usage data from a local storage medium coupled to the media controller.