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

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 inFIG. 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)record150 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 alocale10, such as a residence, in whichmedia controllers12A and12B (generally,media controller12 or media controllers12) are located. Themedia controllers12 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.
• Themedia controllers12 provide content to one ormore viewers14 by causing a display on adisplay device16. Thedisplay device16 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 themedia controllers12 generate output streams that are provided to output connections on the media controllers12 (not illustrated), which are directed to arespective display device16, typically via a cable or other signal-carrying mechanism. While for purposes of illustration themedia controllers12 anddisplay devices16 are illustrated as devices which are separate from one another, thedisplay device16 may be integral with themedia controller12. For example, a single unit may include both amedia controller12, such as a digital video recorder, and adisplay device16, such as a television. Where amedia controller12 anddisplay device16 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.
• Themedia controller12A receives content fromcontent providers18A and18B (generallycontent providers18, or content provider18). Thecontent providers18 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 themedia controllers12 may be any content desirable for presentation, display or otherwise rendering to aviewer14, 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 themedia controllers12 in a content package that is defined by a particular subscription. The subscription between themedia controller12 and thecontent provider18 defines which channels and features make up a particular content package, and therefore defines the programming that will be provided by therespective content provider18 to themedia controller12 pursuant to the subscription. For example, themedia controller12A may receive a first content package that includes premium movies and high definition content from thecontent provider18A pursuant to a first subscription. Themedia controller12B may receive a second content package that includes only standard definition content and no premium movies from thecontent provider18D pursuant to a different subscription, even though thecontent provider18A may be the same content provider as thecontent provider18D. The same program may therefore be available to the same ordifferent media controllers12. Moreover, different versions of the same program may be available to the same ordifferent media controllers12. For example, themedia controller12A may have access to a high-definition version of a particular episode of the network program Survivor, while themedia controller12B has access only to a standard-definition version of Survivor based on the respective subscriptions.
• Thecontent providers18 typically provide a guide to themedia controllers12 that identifies programs available via therespective content provider18. Such guides are depicted inFIG. 1 in the form of respective local electronic programming guides20A,20B (generally,local guides20 or local guide20). While for purposes of illustration eachmedia controller12 is shown as having only a singlelocal guide20, it will be understood that eachmedia controller12 may have multiplelocal guides20, since eachcontent provider18 may provide its own respectivelocal guide20 to themedia controller12.
• Local guides20 typically comprise program metadata identifying attributes and characteristics of particular programs. The program metadata may be provided to themedia controller12 continually on a particular channel, or upon request by themedia controller12, or at certain predetermined times. The program metadata can include any data that may be useful or desirable to the viewer14 (typically as determined by the respective content provider18). 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, aviewer14 accesses alocal guide20 via an input device (not illustrated) such as a remote control, wherein, upon receipt of a request via the remote control, themedia controller12 will cause a display of information from thelocal guide20 on thedisplay device16.
• Themedia controllers12A,12B may also contain one or more respective recordedprograms22A,22B (generally, recorded programs22 or recorded program22). The recorded programs22 may have been previously selected by theviewer14 for time-shifting purposes, for example, to enable theviewer14 to view a program at a different time from when the program was originally provided by acontent provider18. Different programs may be recorded atdifferent media controllers12, and thus, for example, the recordedprograms22A may differ from the recordedprograms22B. Themedia controllers12 may also be communicatively coupled tolocal entertainment libraries24 that contain a variety of programs, such as movies, songs, videos and the like that may have been downloaded, ripped, or otherwise obtained by theviewer14. Themedia controllers12A,12B also preferably includerespective recording schedules23A,23B which identify programs that are scheduled to be recorded on therespective media controllers12A,12B at a future point in time.
• Each of themedia controllers12A,12B are communicatively coupled to one another via alocal area network26. Thelocal area network26 may comprise any suitable communication mechanism that enables themedia controllers12A,12B to communicate with one another, including, for example, an Ethernet network, Token Ring network, and the like. Themedia controllers12 access thenetwork26 viacommunication links28, which may comprise any suitable technology for accessing thenetwork26, such as, for example, WiFi, an Ethernet cable, and the like. Thenetwork26 may use any suitable message transport protocol to enable message communications between themedia controllers12A,12B, such as, for example, TCP/IP.
• According to one embodiment, each of themedia controllers12A,12B also includes a respectivemerged guide30A,30B (generally, merged guides30 or merged guide30). While the generation and contents of themerged guide30 will be discussed later in detail, generally, eachmerged guide30 contains program records identifying programs available from a variety of different sources, including programs that are available atother media controllers12. For example, themerged guide30A may contain program records identifying programs available from each of thecontent providers18A-18E, programs available in the entertainment libraries24A,24B, and recordedprograms22A and22B. Similarly, themerged guide30B associated with themedia controller12B also preferably contains program records identifying programs available from each of thecontent providers18A-18E, programs available in the entertainment libraries24A,24B, and recordedprograms22A and22B. As will be discussed in greater detail herein, themedia controller12A may cause a display on thedisplay device16 which presents information contained in themerged guide30A. Thus, aviewer14 may use anymedia controller12 that is coupled to thenetwork26 to determine the entire collection of content that may be consumed by theviewer14.
• Themedia controllers12 may discover one another on thenetwork26 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, themedia controller12A may use the Bonjour® service discovery protocol to discover themedia controller12B, but the embodiments are not limited to any particular device discovery mechanism.
• Themedia controller12A also preferably maintains media controller previous usage data identifying previous usage of a media controller. Previous usage data may include data identifying that aviewer14 viewed or recorded a particular program. In some embodiments, the previous usage data stored on themedia controller12A may comprise data identifying previous usage of themedia controller12A. In other embodiments, the previous usage data stored on themedia controller12A may comprise data identifying previous usage ofmedia controllers12 other than themedia controller12A.
• In the embodiment illustrated inFIG. 1, themedia controller12A maintains remote media controllerprevious usage data25A (referred to hereinafter as “previous usage data25A” for purposes of simplicity) which identifies previous usage of anothermedia controller12, such as themedia controller12B, and anyother media controllers12 coupled to thenetwork26. The word “remote” is merely a reference to amedia controller12 other than themedia controller12A, and does not imply a particular physical distance. For example, themedia controller12B is remote with respect to themedia controller12A, and vice versa. Theprevious usage data25A may be based on information received from themedia controller12B, as discussed in greater detail herein. Themedia controller12A may use theprevious usage data25A to determine previous usage of themedia controller12B, and thereby determine an availability probability of themedia controller12B for scheduling the recording of a program upon request by themedia controller12A. Themedia controller12B similarly includes previous usage data25B which identifies previous usage of themedia controller12A, and anyother media controllers12 coupled to thenetwork26, for similar purposes. Themedia controllers12 also have respective one ormore tuners34 which may be used to tune to a particular frequency to access a program being provided by one of thecontent providers18.
• FIG. 2 is a block diagram illustrating additional details of amedia controller12 according to one embodiment. Themedia controller12 preferably includesnodal data32, which includes information that may be unique to therespective media controller12, such as, for example, a name of themedia controller12, a serial number associated with themedia controller12, log files generated by themedia controller12, and the like. Exemplarynodal data32 will be discussed in greater detail with reference toFIG. 3. Themedia controller12 includes one ormore tuners34 which are used to select particular content provided by acontent provider18. For example, thecontent provider18 may concurrently provide a number of different programs to themedia controller12, each program being delivered on a particular frequency. Thetuner34, for example in response to a channel selection from aviewer14, tunes to a particular frequency and captures the program data being provided at the particular frequency. Thetuner34 then typically causes the program to be displayed on adisplay device16, or may record the program, as discussed in greater detail herein. While thetuner34 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 thetuner34 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.
• Themedia controller12 preferably includes arecorder36 for recording a program. Therecorder36 preferably receives input from thetuner34, encodes the input into a desired format, if necessary, and stores the program data in astorage38. Thestorage38 may comprise any suitable storage technology, such as a hard drive, flash drive, and the like. Thestorage38 is preferably a persistent storage that survives the powering down of themedia controller12, and may contain data from a variety of sources, including, for example, thelocal guide20, themerged guide30, therecording schedule23, theprevious usage data25, and the like.
• Themedia controller12 may also include aretransmitter40 which enables the retransmission of a program received by themedia controller12 onto thenetwork26. For example, theretransmitter40 may segment the program data received by themedia controller12 into packets and transmit the packets to anothermedia controller12 via thenetwork26. Theretransmitter40 may encode the program differently from the way the program was encoded when initially received by thetuner34. For example, in one embodiment, afirst media controller12 may request from a second media controller12 a program stream of a program currently being presented toviewers14 by thesecond media controller12. The request may identify that a particular quality, or resolution, of the program stream is desired. For example, thefirst media controller12 may intend to display the program stream in a relatively small area of adisplay device16 in conjunction with other information, and thus not require a high resolution program stream. Thesecond media controller12 may then encode the program into a sufficiently lower resolution version of the program prior to transmitting the program stream onto thenetwork26 to minimize network usage.
• Themedia controller12 may also include aweb server42 for use in transferring program metadata betweenmedia controllers12. For example, theweb server42 may respond to requests for program metadata fromother media controllers12. In one embodiment the program metadata may be formatted and transferred in an XML format. Themedia controller12 may also includeupdate timestamp data44 that identifies the times thatother media controllers12 last provided program metadata to themedia controller12. Theupdate timestamp data44 may be used by themedia controller12 to quickly determine which program metadata received by anothermedia controller12 constitutes new program metadata. The receipt of program metadata by amedia controller12 and the use of theupdate timestamp data44 will be described in greater detail herein.
• FIG. 3 is block diagram of a stored item record50-1 that contains data associated with items stored instorage38, or elsewhere. Thestorage38 may contain a plurality of stored item records50-1-50-N. The stored item record50-1 contains information identifying, for example, a recorded program22, or a program in theentertainment library24. The stored item record50-1 may include a globally unique identifier (GUID)field52 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 record50-1 also includes alocation field54 identifying a location of the corresponding program. Thelocation field54 may indicate the program resides in thestorage38, theentertainment library24, or elsewhere. The stored item record50-1 preferably includes ametadata GUID field56 that contains a metadata GUID which uniquely identifies a metadata record containing metadata pertaining to the corresponding program. The metadata record may be in thestorage38, on a local server coupled to thenetwork26, or on a remote server accessible by themedia controller12 over a wide area network coupled to thenetwork26.
• FIG. 4 is a block diagram illustrating exemplarynodal data32 according to one embodiment. Thenodal data32 can include aname field58 that contains a name which identifies therespective media controller12. For example, thename field58 of themedia controller12A may be “TIVO DVR”, and thename field58 of themedia controller12B may be “TimeWarner SetTop.” Alternately, thename field58 may contain a link or reference to a graphical image that depicts a particular type ofmedia controller12. Thenodal data32 can include adescription field60 that provides a short textual description of the capabilities of therespective media controller12. Acapabilities field62 may identify operations performable by therespective media controller12, and power consumption characteristics. Aserial number field64 may contain a unique manufacturer serial number of themedia controller12. Amanufacturer field66 may identify the manufacturer of themedia controller12. Amodel field68 may identify a particular model of themedia controller12. Logs field70 may comprise data generated during the operation of themedia controller12, such as, for example, faults or errors that occur during the operation of themedia controller12, and/or input selections received fromviewers14, which programs were watched at which times, and the like.
• Aservice field72 may contain service status information regarding themedia controller12 such as service intervals and/or wear counts. The wear count may indicate how many times particular “wear items” have been used. For example, amedia controller12 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. Astate field74 may contain a status of themedia controller12, such as, for example “Booting”, “On”, “Recording”, “Sleep”, “Updating”, and the like. Alocation field76 may identify a location of themedia controller12 within thelocale10. For example, thelocation field76 of themedia controller12A may contain “Den”, and thelocation field76 of themedia controller12B may contain “Living Room.” Thenodal data32 may also include a preference settings field78 identifying preferences of one ormore viewers14. Any desired preference data may be stored in thepreference settings field78, such as, for example, genre preferences, actor preferences, time preferences, series preferences, and the like. Preference data may be used, for example, by themedia controller12 to provide program recommendations to aviewer14.
• FIG. 5 is a block diagram of therecorder36 according to one embodiment. Therecorder36 receives asource80 from thetuner34. Therecorder36 uses anencoder82 to encode thesource80 in a desired format, such as the MPEG-2 format. The encoded program can be stored in thestorage38. Therecorder36 may include abuffer84 for use in temporarily storing segments of thesource80 while it is being encoded.
• FIG. 6 is an exemplary block diagram of amerged guide30 according to one embodiment. The format of themerged guide30 depicted inFIG. 6 is but one exemplary layout, and the embodiments are not limited thereto. Themerged guide30 may include a plurality ofchannel records86, such as channel records86-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 record86-1 may include aninformation field88 that contains text identifying source attributes of the channel, such as the particular service provider, or other source. For example, if the channel86-1 is provided by a service provider via cable, theinformation field88 may contain the name of the cable company. Alternately, thechannel information field88 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 theentertainment library24, thechannel information field88 may identify theentertainment library24 by a name, such as “John's Video Library.” The channel86-1 may also include arating field90 that generally describes the content associated with the channel86-1. For example, if the channel86-1 is a mature adult channel, therating field90 may identify it as such.
• Eachchannel86 may include one or more program records92. For example, the channel86-1 contains a plurality of program records92-1-92-N. Eachprogram record92 contains metadata associated with a particular program. Thus, eachprogram record92 corresponds to a particular program. Theprogram record92 may contain aGUID field94 that contains a GUID which uniquely identifies the program. Atitle field96 may contain a textual title of the program. Astart field98 may identify a present, past or future start time of the program. Aduration field100 identifies a length of the program. Arating field102 may contain an MPAA rating of the program. Aquality field104 may identify the encoding quality of the program. Analt location field106 may contain an alternate location of the program other than the location identified in thesource field116. For example, the location identified in thesource field116 may be the source of a highest quality version of the program, while thealt location field106 may provide a lower quality version of the program. In one embodiment, a uniform resource identifier (URI) represents the location indicated by thesource field116 andalt location field106. The URI may point to a local media item, or may reference a program available from anothermedia controller12 over the network.
• Arequestors field108 may contain information identifying one ormore viewers14 that have requested that the program be recorded. A viewers list110 may identify one ormore viewers14 that were identified as being in proximity to themedia controller12 which presented the program. Ametadata GUID field112 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 themedia controller12. Anoriginator field115 may identify theparticular media controller12 which originated therespective program record92. A record update timestamp (TS)field114 may contain a timestamp identifying the time of the last update to the record92-1. Asource field116 may identify a location of the program, and may comprise, for example, a URI.
• Theprogram record92 may also include anoperation field117 for identifying a particular operation performed on the corresponding program by the media controller identified in theoriginator field115. For example, theoperation field117 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 aviewer14, and a value of 3 to indicate that the program was both recorded and presented to aviewer14. Where the operation value is greater than zero, and where themedia controller12 identified in theoriginator field115 has multiple tuners, theoriginator field115 may also identify theparticular tuner34 that performed the identified operation. Theoperation field117 may be used by themedia controller12 to relatively rapidly determine which program records92 may be useful for determining the previous usage data associated with anothermedia controller12. More particularly, upon receipt of aprogram record92 having an operation value greater than zero, themedia controller12 may generate a copy of theprogram record92 and store the copy in theprevious usage data25. The use of separateprevious usage data25, while optional, provides a mechanism to store for desired periods of time previous usage data associated withother media controllers12, while allowing themerged guide30 to maintain historical program records92 for a much shorter duration.
• Preferably, eachmedia controller12 coupled to thenetwork26 generates program records92 for each program that is available at therespective media controller12. For example, referring again toFIG. 1,local guide20A may include guides for programs available from thecontent providers18A and18B. Themedia controller12A may read thelocal guide20A and generate aprogram record92 for each program identified in thelocal guide20A. Themedia controller12A may also generateprogram records92 for each recordedprogram22A, and each item available for presentation from the entertainment library24A. If program metadata for such programs is unavailable, themedia controller12A 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 theprogram record92.
• FIG. 7 is a flowchart illustrating an exemplary method for generating program records92. Assume that themedia controller12A is traversing alocal guide20A, and determines that thelocal guide20A identifies a program that is not identified in themerged guide30A. For example, thecontent provider18A may have recently provided themedia controller12A new program guide data that identifies programs that will be available for presentation one week from the present date. Themedia controller12A generates a program record92 (step1000). Themedia controller12A then generates a GUID that uniquely identifies this program (step1002). Themedia controller12A then populates the fields described above with regard toFIG. 6 with the appropriate data (step1004). The media controller may insert the current time in the recordupdate timestamp field114. Themedia controller12A then stores theprogram record92 in the merged guide30 (step1006).
• Eachmedia controller12 preferably provides program metadata from the program records92 which are available from therespective media controller12 to theother media controllers12. For example, referring again toFIG. 1, themedia controller12A provides themedia controller12B program metadata from each of the program records92 stored in themerged guide30A. Themedia controller12B similarly provides themedia controller12A program metadata from each of the program records92 in themerged guide30B. In this manner, eachmedia controller12 contains program records92 identifying programs available at not only therespective media controller12, but which are available at allmedia controllers12 coupled to thenetwork26.
• The program metadata may be provided in the same format as the program records92, or in a different format. The program metadata may be “pushed” as desired by amedia controller12 to the other media controllers, or may be “pulled” from amedia controller12 upon request. In one embodiment, the program metadata may be provided in an XML file, which may have a format similar to theprogram record92. In one embodiment, amedia controller12 may broadcast a signal on thenetwork26 to indicate that new program metadata is available. Referring again toFIG. 1, assume that themedia controller12A has generated one or more new program records92. Themedia controller12A may broadcast a signal on thenetwork26 indicating that themedia controller12A has new program metadata for distribution. Themedia controller12B, upon receipt of the signal, may send a message to themedia controller12A requesting the program metadata. According to one embodiment, eachmedia controller12 may maintain a last update timestamp for eachother media controller12. Such last update timestamps may be maintained in the update timestamp data44 (FIG. 2) associated with therespective media controller12.
• FIG. 8 is a block diagram illustrating exemplaryupdate timestamp data44 according to one embodiment. Theupdate timestamp data44 may include one or more last update timestamps120-1-120-N (generally, last update timestamps120), each of which may correspond to arespective media controller12. The last update timestamps120 identify the time of the last update of program metadata from the correspondingmedia controller12. For purposes of illustration with regard toFIG. 8, amedia controller12 that has program metadata to provide to anothermedia controller12 will be referred to as apublishing media controller12, and themedia controller12 receiving the program metadata will be referred to as a receivingmedia controller12. The receivingmedia controller12 may use alast update timestamp120 to indicate to thepublishing media controller12 which program records92 are needed. For example, in the current example, assume that the last update timestamp120-1 corresponds to thepublishing media controller12. The receivingmedia controller12 may provide the last update timestamp120-1 to thepublishing media controller12 to indicate to thepublishing media controller12 that the receivingmedia controller12 only requires program metadata from those program records92 that contain a record update timestamp more recent than the last update timestamp120-1. Thepublishing media controller12 may thus use the last update timestamp120-1 to generate an XML file containing only program metadata for those program records92 which have a record update timestamp that is more recent than the last update timestamp120-1. The receivingmedia controller12 receives, and then processes, the program metadata and updates the last update timestamp120-1 with the latest record update timestamp associated with anyprogram record92 provided by thepublishing media controller12.
• FIG. 9 is a flowchart illustrating an exemplary method for receiving and processing program metadata sent from onemedia controller12 to anothermedia controller12.FIG. 9 will be discussed in conjunction withFIGS. 1 and 6. Again, for purposes of illustration with regard toFIG. 9, themedia controller12A will be assumed to have program metadata to distribute to themedia controller12B, and will be referred to as thepublishing media controller12A, and themedia controller12B will be referred to as the receivingmedia controller12B. Thepublishing media controller12A broadcasts a notification that thepublishing media controller12A has new program metadata available for distribution. The receivingmedia controller12B receives the notification (step2000). The receivingmedia controller12B obtains the last update timestamp120-1 which corresponds to thepublishing media controller12A (step2002). The receivingmedia controller12B generates a request containing the last update timestamp120-1 and sends the request to thepublishing media controller12A (steps2004,2006). Thepublishing media controller12A uses the last update timestamp120-1 to select program metadata from eachprogram record92 having a record update timestamp that is later than the last update timestamp120-1. Thepublishing media controller12A formats the program metadata and sends it to the receivingmedia controller12B.
• The receivingmedia controller12B receives the program metadata (step2008). The receivingmedia controller12B may, for each program identified by the program metadata, attempt to match the program metadata to an existingprogram record92 in themerged guide30B (step2010). What constitutes a “match” may be system dependent. Generally, the receivingmedia controller12B may determine if various data in the provided program metadata matches corresponding data in any existingprogram record92. For example, the receivingmedia controller12B may determine that the program identified by the metadata matches a program identified by aprogram record92 if the data from the title fields96 match one another and the data from the start fields98 match one another.
• If the receivingmedia controller12B determines that the provided program metadata matches a program identified by a program record92 (step2012), then the receivingmedia controller12B may generate achild program record92 from the supplied program metadata, such that the matchedprogram record92 in themerged guide30A is stored in association with the child program record92 (step2014). Among other advantages, establishing such a parent-child relationship between program records92 enables the receivingmedia controller12B to cause the display of information to aviewer14 that the same program is available atmultiple media controllers12. If the receivingmedia controller12B determines that the program metadata does not match any existing program identified in a program record92 (step2012), the receivingmedia controller12B may generate aprogram record92 as aparent program record92 that is not achild program record92 to any other program record92 (step2016). While for purposes of illustration only twoprogram records92 have been shown as stored in association with one another, it is apparent any number of program records92 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 thepublishing media controller12A has new program metadata to distribute. Thepublishing media controller12A broadcasts a notification signal onto thenetwork26 indicating that new program metadata is available (step3000). Thepublishing media controller12A receives a request for data from the receivingmedia controller12B (step3002). Thepublishing media controller12A obtains the last update timestamp120-1 from the request for data (step3004). Thepublishing media controller12A obtains program metadata from those program records92 having a record update timestamp greater than the last update timestamp120-1 (step3006).
• FIGS. 11 and 12 are block diagrams illustrating exemplary relationships between several program records92.FIG. 11 illustrates that at a first point in time, themerged guide30A contains a plurality ofprogram records92A-92C, each of which may be considered aparent program record92. Similarly, themerged guide30B contains a plurality of program records92D-92F, each of which may also be considered aparent program record92.FIG. 12 illustrates an exemplary relationship betweenprogram records92 after themedia controller12A has communicated the program records92A-92C to themedia controller12B, and has received from themedia controller12B the program records92D-92F. As illustrated, themedia controller12A determined that theprogram record92D identified the same program as identified by theprogram record92A, and consequently made theprogram record92D a child record to theprogram record92A. Theprogram record92E was also determined to identify the same program as identified by theprogram record92B, and was therefore similarly made a child record to theprogram record92B. Because theprogram record92F did not match anyother program record92 in themerged guide30A, theprogram record92F is made aparent program record92F.
• A similar analysis was conducted by themedia controller12B, and thus theprogram record92A was made a child record of theprogram record92D, and theprogram record92B was made a child record of theprogram record92E.
• According to one embodiment, themedia controller12 may determine the identity of theviewers14 that are in proximity to themedia controller12. This information may be stored in the viewers list110 of the program records92 for the corresponding programs that are presented by themedia controller12.FIG. 13 is a block diagram illustrating exemplary mechanisms that may be used by amedia controller12 to determine the identity of a particular viewer. Themedia controller12A in a den118 is communicatively coupled to aninput device128. As theviewers14A,14B enter the den118, eachviewer14A,14B uses theinput device128 to indicate that therespective viewer14A,14B is in the den118 and watching programming presented by themedia controller12A. Prior to exiting the den118, eachviewer14A,14B may use theinput device128 to indicate they are departing the den118. Themedia controller12A may maintain the identity of theviewers14 who are in the den118, and for each program provided during the presence of aviewer14, update the viewers list110 in theprogram record92 corresponding to the presented program. Theinput device128 may comprise any suitable device and interface, such as a keyboard, or a mouse and a computer having a user interface that enables aviewer14 to simply click on a designated portion of a display to indicate the presence or departure of theviewer14 from the den118. The computer may be wirelessly coupled to themedia controller12A, and communicate the status of incoming andoutgoing viewers14 to themedia controller12 as appropriate.
• Themedia controller12B in theliving room122 includes afacial recognition processor130 that is able to identify through facial processing technology theviewers14C-14E. Facial recognition technology is known to those skilled in the art, and will not be described in detail herein. Thefacial recognition processor130 communicates the identity of theviewers14C-14E to themedia controller12B. While thefacial recognition processor130 is illustrated as being integral with themedia controller12B, in an alternate embodiment, thefacial recognition processor130 may be separate from but coupled tomedia controller12B via a wired or wireless communications channel, for example.
• Themedia controller12C in abedroom124 includes a radio frequency identification (RFID)processor134. TheRFID processor134 may receive a signal from a device worn, or carried, by theviewer14F. For example, a cell phone of theviewer14F may emit a signal that can be received by theRFID processor134. Upon receipt of such signal, theRFID processor134 can communicate the identity of theviewer14F to themedia controller12C.
• Themedia controller12D in abasement126 is coupled to a wireless Bluetooth interface which enables themedia controller12D to communicate with Bluetooth devices, such as a cell phone, that contain the appropriate software to interface with themedia controller12D. Such software may be programmed to emit a signal that can be detected by themedia controller12D via thewireless Bluetooth interface132. The signal may contain an identifier identifying aparticular viewer14G,14H. Themedia controller12D may periodically poll the cell phone to determine if theviewer14G,14H is still in proximity of themedia controller12D. If themedia controller12D does not receive a response to the poll, themedia controller12D may determine that theviewers14G,14H are no longer in proximity of themedia controller12D.
• FIG. 14 is a flowchart illustrating an exemplary method for storing viewer information into aprogram record92. Themedia controller12 determines that anew viewer14 is in proximity to themedia controller12, and identifies the new viewer14 (step4000). Themedia controller12 may use one of the mechanisms described with regard toFIG. 13, or any other suitable mechanism. Themedia controller12 obtains theprogram record92 corresponding to the program that is currently being provided for display by the media controller12 (step4002). Themedia controller12 updates theviewer list110 of theprogram record92 to include an identification of the new viewer14 (4004). Preferably, themedia controller12 also updates the record update timestamp of theprogram record92. Themedia controller12 stores theprogram record92 in the merged guide (step4006). Note that themedia controller12 may also broadcast a notification signal to thenetwork26 to notifyother media controllers12 that themedia controller12 has new program metadata to distribute. In this manner, eachmedia controller12 coupled to thenetwork26 may be, substantially in real-time, provided data that identify who, in which room, is watching which programs.
• According to another embodiment, the onemedia controller12 may send requests to anothermedia controller12 for information, or to direct theother media controller12 to provide a desired function.FIG. 15 is block diagram illustrating certain requests that onemedia controller12 may make of anothermedia controller12 according to one embodiment. For example, themedia controller12A may send anIDENTIFY_CURRENT_PROGRAM request142 to themedia controller12B. AnIDENTIFY_CURRENT_PROGRAM request142 requests that themedia controller12B identify the specific program that is currently being provided by themedia controller12B. In response, themedia controller12B may provide themedia controller12A theprogram record92 corresponding to the program that themedia controller12B is currently presenting. Themedia controller12A may send themedia controller12B aRECORDING_STATUS request144, which requests information regarding the recording status of the program that is currently being presented by themedia controller12B. In response, themedia controller12B provides a message indicating whether the current program being provided by themedia controller12B is being recorded.
• Themedia controller12A may send themedia controller12B aRECORD PROGRAM REQUEST146, which requests that themedia controller12B schedule the recording of a particular program. TheRECORD PROGRAM REQUEST146 may include theprogram record92 corresponding to the program that is to be recorded. In response, themedia controller12B 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. Themedia controller12B may provide themedia controller12A a message indicating success or failure of the request. Themedia controller12A may send themedia controller12B aPROVIDE_CURRENT_PROGRAM request148, which requests that themedia controller12B provide a program stream of the program that is currently being provided by themedia controller12B. Themedia controller12B, using theretransmitter40, may then provide a program stream of the program which is currently being provided by themedia controller12B.
• Tuner conflicts may arise during the operation of amedia controller12. For example, themedia controller12 may have asingle tuner34, and theviewer14 may desire to record two programs in the future concurrently. If themedia controller12 has only asingle tuner34, themedia controller12 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 anothermedia controller12 is processed to determine if themedia controller12 can schedule the recording of one of the two programs.
• FIG. 16 is a flow chart illustrating an exemplary method for determining if anothermedia controller12 is available to schedule a recording of a program.FIG. 16 will be discussed in conjunction withFIG. 1. Assume for purposes of illustration that theviewer14 requests themedia controller12A to record two programs concurrently during the same future time slot (step5000). Themedia controller12A contains asingle tuner34 and determines a tuner conflict exists because themedia controller12A can only record a single program at a time (step5002). A similar situation may arise even without input from theviewer14 where, for example, a first program has been scheduled to be recorded by themedia controller12A at a future (but imminent) time, and theviewer14 is watching a program on a second channel minutes prior to the scheduled recording of the first program. Themedia controller12A similarly may detect that recording the first program is likely to conflict with the viewer's14 current use of themedia controller12A.
• Themedia controller12A may determine ifother media controllers12, such as themedia controller12B, are currently communicatively coupled to the network26 (step5004). Device discovery mechanisms are known to those skilled in the art and will not be described in detail herein. For example, themedia controller12A may use the Bonjour® service discovery protocol to discover themedia controller12B, but the embodiments are not limited to any particular device discovery mechanism. If noother media controllers12 are available, themedia controller12A may cause a display to theviewer14 identifying the conflict, thereby enabling theviewer14 to resolve the conflict by selecting one program over another program (step5006). If anothermedia controller12 is available, such as themedia controller12B, themedia controller12A may then access theprevious usage data25A (generally, previous usage data25) to determine previous usage associated with themedia controller12B (step5008). For example, theprevious usage data25A may include data extracted fromprogram records92 wherein the value of theoperation field117 is greater than zero. Such data may identify previous usage of themedia controller12B. For purposes of illustration, assume that themedia controller12B similarly contains only asingle tuner34B.
• Themedia controller12A determines an availability probability for themedia controller12B (step5010). The availability probability may be used to determine whether thetuner34B is likely to be available during the desired time slot. Exemplary mechanisms for determining an availability probability will be discussed herein with respect toFIG. 17. The availability probability may comprise any indicator used to determine whether or not amedia controller12 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 themedia controller12B 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 themedia controller12B will be available during the desired time slot is 70% (i.e., 0.70), then the availability probability of themedia controller12B is 70% (or 0.70). Where amedia controller12 has asingle tuner34, the availability probability of thetuner34 is the same as the availability of themedia controller12. Where amedia controller12 hasmultiple tuners34, the availability probability of themedia controller12 is a function of the availability probability of each of thetuners34.
• Themedia controller12A determines if the availability probability of themedia controller12B exceeds an availability threshold (step5012). The availability threshold may be a configurable value that may be adjustable by an administrator of thenetwork26, or by a service provider. The availability threshold may be relatively high to decrease the likelihood that the receivingmedia controller12, i.e., themedia controller12B in this example, will encounter a tuner conflict at the time of the scheduled recording. For example, an availability threshold of 90 indicates that themedia controller12B 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 themedia controller12A at the potential risk of increasing the likelihood of a tuner conflict on themedia controller12B at the time of the scheduled recording.
• If the availability probability does not exceed the availability threshold (step5012), the process returns to step5004 where it is determined if anothermedia controller12 may be available to schedule the recording. Otherwise, if the availability probability exceeds the availability threshold (step5012), themedia controller12A may send themedia controller12B a request to schedule the recording of the program (step5014). In one embodiment, themedia controller12B may accept or reject such a request. If themedia controller12B rejects the request (step5016), the process returns to step5004 where it is determined if anothermedia controller12 may be available to schedule the recording. If themedia controller12B accepts the request, themedia controller12A may update therecording schedule23A to reflect that the program will not be recorded by themedia controller12A.
• 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 amedia controller12. 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)record150 for storing previous usage data associated with amedia controller12.FIG. 17 will be discussed in conjunction withFIG. 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 eachmedia controller12 in the form of program records92. Eachprogram record92 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. TheMCU record150 may be generated, for example, by consolidating information contained in multiple program records92 over a predetermined period of time, such as the previous four weeks, or previous six weeks, for example. In particular, themedia controller12A may process eachprogram record92 having an operation value greater than zero for eachmedia controller12 coupled to thenetwork26 that was created within the previous six weeks. TheMCU record150 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 themerged program guide30, it should be apparent that media controller previous usage data identifying previous usage activity of themedia controller12B could be generated and broadcast toother media controllers12 without the existence of themerged guide30. For example, a previous usage data record may be defined that includes information such as thestart field98, theduration field100, theoriginator field115 and theoperation field117. Each time an operation on themedia controller12B occurs, themedia controller12B could generate a previous usage data record and broadcast the record to theother media controllers12 on the network. Eachrecipient media controller12 could then use the data to maintain aMCU record150 for themedia controller12B.
• For purposes of illustration assume that themedia controller12A 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 theMCU record150 contains information corresponding to themedia controller12B. Themedia controller12A may continually update theMCU record150 with new information as it is received from themedia controller12B.
• TheMCU record150 includes a tuner usage record152 for eachtuner34 contained in themedia controller12B. In this example, assume that themedia controller12B contains twotuners34, and thus theMCU record150 includes atuner usage record152A and atuner usage record152B (generally, the tuner usage record152 or the tuner usage records152). Each tuner usage record152 includes seven usage-by-day (UBD) records154. Thetuner usage record152A thus containsUBD records154A-1-154A-7. EachUBD record154A contains previous usage data associated with a particular weekday. Thetuner usage record152B similarly contains UBD records154B-1-154B-7. Each UBD record154 contains a plurality of usage-by-time slot (UBT) records. Assuming hourly time slots, for example, theUBD record154A-1 contains 24 UBT records156-1-156-24. Thus each UBT record156 contains previous usage data associated with a particular hour of the particular day corresponding to a UBD record154. Similarly, theUBD record154A-7 contains 24 UBT records158-1-158-24. Each UBT record156,158,160, and162 identifies a usage factor of the respective tuner during a particular time slot. The usage factor may represent the frequency, by percentage, that the correspondingtuner34 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 correspondingtuner34 is not busy.
• Assuming that the usage factor represents the frequency, by percentage, that the correspondingtuner34 is busy, the availability probability (AP) of thetuner34 during the respective time slot can thus be determined by the following formula:
• 
  AP_{Tuner—Timeslot}=(1−usage factor_Timeslot)
• • AP_{Tuner—Timeslot}is 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 record152A) duringTime Slot24 of Day 1 (Monday) indicated by the UBT record156-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 record152B) duringTime Slot24 of Day 1 (Monday) indicated by the UBT record160-24 duringTime Slot24 of Day 1 (Monday) indicated by the UBT record160-24 may be calculated in the following manner:
• 
  AP_{TunerB—Timeslot24}=(1−0.92)=0.08=8%
• It is apparent each UBT record156-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 themedia controller12B contains twotuners34, the following formula may be used:
• $\begin{array}{c}{\mathrm{AP}}_{\mathrm{mediacontroller}12B}=\left({\mathrm{AP}}_{\mathrm{TunerA\_Timeslo}t24}+{\mathrm{AP}}_{\mathrm{TunerB\_Timeslo}t24}\right)/2\\ =\left(\mathrm{.78}+\mathrm{.08}\right)/2\\ =\mathrm{.43}\\ =43\%\end{array}$
• Themedia controller12A also preferably accesses therecording schedule23B of themedia controller12B. Therecording schedule23B identifies the scheduled recordings of themedia controller12B. Therecording schedule23B may identify that the one or bothtuners34 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 themedia controller12A determines that bothtuners34 of themedia controller12B are scheduled to record a program during the 23:00-23:59 time slot on Monday, themedia controller12A may determine the availability probability is 0 for themedia controller12B prior to even accessing theMCU record150. However, if themedia controller12A determines from therecording schedule23B that the program which themedia controller12A would like themedia controller12B to schedule for recording is already scheduled for recording on themedia controller12B, themedia controller12A may determine the availability probability is 100.
• Where therecording schedule23B indicates that onetuner34 will not be available due to a scheduled recording, the availability probability may be calculated as the lowest availability probability of either of thetuners34.
• FIG. 18 is block diagram of embodiments implemented in a client server architecture. Eachmedia controller12 sends previous usage records identifying previous usage of therespective media controller12 to acomputer server164, which stores such information in the media controllerprevious usage data25. If amerged guide30 is maintained on theserver164, the information may be provided in program records92 as discussed previously. If embodiments are being implemented in the absence of amerged guide30, a previous usage data record may be defined that includes information such as thestart field98, theduration field100, theoriginator field115 and theoperation field117, as discussed previously, to provide such information to theserver164.
• FIG. 19 is a flow chart illustrating an exemplary method for determining if anothermedia controller12 is available to schedule the recording of a program in the client-architecture illustrated inFIG. 18.FIG. 19 will be discussed in conjunction withFIG. 18. Assume for purposes of illustration that a viewer requests themedia controller12A to record two programs concurrently during the same time slot. Themedia controller12A contains asingle tuner34 and determines a conflict exists because themedia controller12A can only record a single program at a time. Themedia controller12A sends a request to theserver164 to locate anothermedia controller12 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. Theserver164 receives the request (step6000). Theserver164 determines ifother media controllers12 are present on the network (step6002). Assume that themedia controller12B is present. Theserver164 obtains the previous usage data of themedia controller12B from the media controller previous usage data25 (step6004). For example, theserver164 may obtain aMCU record150 corresponding to themedia controller12B.
• Theserver164 determines the availability probability for themedia controller12B (step6006). The availability probability may be determined as discussed previously with regard toFIG. 16, and for the sake of brevity will not be repeated again herein. Theserver164 determines if the availability probability of themedia controller12B is greater than the availability threshold (step6008). The availability threshold may have been included in the request from themedia controller12A, or may apply to allmedia controllers12 and be stored on theserver164. If the availability probability is not greater than the availability threshold, the process may return to step6002 where theserver164 determines if there are otherpresent media controllers12. If the availability probability of themedia controller12B is greater than the availability threshold, the identity of themedia controller12B may be stored in an available media controllers list (step6010). In one embodiment, as soon as anymedia controller12 is determined to be available to schedule a recording, the identity of themedia controller12 is provided to themedia controller12A. In another embodiment, the availability probability of eachmedia controller12 coupled to thenetwork26 may be determined, and eachmedia controller12 that is determined to be available to schedule a recording is identified to themedia controller12A.
• Atstep6002, if noother media controllers12 are present then theserver164 determines whether anymedia controllers12 were identified as being available to schedule the recording of the program (step6012). If not, theserver164 may send themedia controller12A a message indicating that there are noavailable media controllers12 to schedule the recording of the program (step6014). Otherwise, theserver164 sends themedia controller12A a message identifying theavailable media controllers12. Themedia controller12A may select one of theavailable media controllers12, and send the selected media controller12 a request to schedule the recording of the program. In another embodiment, rather than identify theavailable media controllers12 to themedia controller12A, theserver164 may select anavailable media controller12 and send the selected media controller12 a request to schedule the recording of the program. Upon receipt of a confirmation from the selectedmedia controller12, theserver164 may then identify the selectedmedia controller12 to themedia controller12A, indicating that the selectedmedia controller12 has scheduled the recording of the program.
• FIG. 20 is block diagram of another exemplary embodiment implemented in a peer-to-peer architecture. Similar toFIG. 1, eachmedia controller12 may have a mergedguide30 containing program records92 of allmedia controllers12 coupled to the network. However, as discussed previously, themerged guide30 is optional, and embodiments may be practiced in the absence of themerged guide30. In the exemplary embodiment illustrated inFIG. 20, eachmedia controller12 contains media controllerprevious usage data25 that contains previous usage data associated with therespective media controller12, rather than previous usage data ofother media controllers12. For example, the media controllerprevious usage data25A includes previous usage data of themedia controller12A, and the media controller previous usage data25B includes previous usage data of themedia controller12B.
• FIG. 21 is a flow chart illustrating an exemplary method for determining if anothermedia controller12 is available to schedule a recording of a program in the exemplary peer-to-peer architecture illustrated inFIG. 20.
• FIG. 21 will be discussed in conjunction withFIG. 20. Assume for purposes of illustration that aviewer14 requests themedia controller12A to record two programs concurrently during the same time slot. Themedia controller12A contains asingle tuner34 and determines a conflict exists because themedia controller12A can only record a single program at a time. Themedia controller12A sends a request to themedia controller12B 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 themedia controller12A includes themerged guide30A, themedia controller12A may provide theprogram record92 corresponding to the program that is to be recorded. Themedia controller12B receives the request (step7000). Themedia controller12B obtains the previous usage data of themedia controller12B from the media controller previous usage data25B (step7002). Themedia controller12B determines the availability probability for themedia controller12B (step7004). The availability probability may be determined as discussed previously with regard toFIG. 16, and for the sake of brevity will not be repeated again herein. Themedia controller12B determines if the availability probability of themedia controller12B is greater than the availability threshold (step7006). If so, themedia controller12B may schedule the recording of the program (step7008). Themedia controller12B may then update therecording schedule23B (step7010). Themedia controller12B sends an acceptance message to themedia controller12A (step7012). If the availability probability of themedia controller12B is less than the availability threshold (step7006), themedia controller12B may send themedia controller12A a denial message indicating themedia controller12B is not available to record the program (step7014).
• FIG. 22 illustrates awindow168 which may be displayed on thedisplay device16 according to one exemplary embodiment. Assume again for purposes of illustration that aviewer14 requests themedia controller12A to record two programs concurrently during the same time slot. Themedia controller12A contains asingle tuner34 and determines a conflict exists because themedia controller12A can only record a single program at a time. Assume that themedia controller12A determines that twomedia controllers12 are coupled to thenetwork26 that are available for scheduling a recording of one of the programs. Themedia controller12A may have determined this in conjunction with the server164 (FIG. 18), may have determined it by examining the remote media controllerprevious usage data25A containing previous usage data of other media controllers12 (FIG. 1), or may have determined it by asking eachother media controller12 if themedia controller12 is available to schedule the recording of the particular program.
• FIG. 23 is a flowchart illustrating an exemplary method for providing aviewer14 an option to select anothermedia controller12 to resolve a tuner conflict.FIG. 23 will be discussed in conjunction withFIG. 22. Themedia controller12A causes a display of thewindow168 on thedisplay device16A (step8000). Thewindow168 may identify to theviewer14 that a conflict exists, and identify that amedia controller12 identified as the “DEN DVR” and amedia controller12 identified as the “BEDROOM DVR” are each available for recording the selected program. Theviewer14 may select one of the identifiedmedia controllers12 by, for example, actuating a check box adjacent to the selectedmedia controller12, and actuating a “Use Selected” button. Alternatively, theviewer14 may allow themedia controller12A to select themedia controller12 by actuating a “Select One” button. Assume that that theviewer14 selects the DEN DVR (step8002). Themedia controller12A may then send the DEN DVR media controller12 a request to schedule the recording of the program (step8004). Themedia controller12A may then update therecording schedule23A as appropriate (step8006).
• In one embodiment, after amedia controller12 records a program, it may transfer the recorded program over thenetwork26 to themedia controller12 which requested that it be recorded. Thus, thewindow168 may include a “copy back” option which theviewer14 may actuate to indicate that theviewer14 would like the DENDVR media controller12 to transmit the recorded program to themedia controller12A upon completion of the recording. This may be communicated by themedia controller12A to the DENDVR media controller12 in the request to schedule the recording of the program.
• In one embodiment, themedia controller12 may implement all or part of the Universal Plug and Play (UPnP) set of networking protocols. Onemedia controller12 may serve as a UPnP control point when requesting anothermedia controller12 to schedule the recording of a program, for example. Eachmedia controller12 may implement at least certain UPnP services, such as ConnectionManager, to enable the streaming of programs from onemedia controller12 to anothermedia controller12, ContentDirectory to provide access to the recorded music and videos at amedia controller12, and ScheduledRecordings to allow eachmedia controller12 access to therecording schedule23 of theother media controllers12.
• FIG. 24 illustrates anexemplary processing device170 which may be used to implement amedia controller12, or aserver164, according to some embodiments. Theprocessing device170 may, when implementing amedia controller12, 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, theexemplary processing device170 may also include acentral processing unit172, asystem memory174, and asystem bus176. Thesystem bus176 provides an interface for system components including, but not limited to, thesystem memory174 and thecentral processing unit172. Thecentral processing unit172 can be any of various commercially available or proprietary processors. Dual microprocessors and other multi-processor architectures may also be employed as thecentral processing unit172.
• Themedia controller12 may include one ormore tuners34 for selecting program content from a communications channel. Therecorder36 may receive a source input from thetuner34 and store the content onto a storage device, such as thestorage38. Theretransmitter40 may provide a stream of program content over thenetwork26 to anothermedia controller12.
• Thesystem bus176 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. Thesystem memory174 can include non-volatile memory178 (e.g., read only memory (ROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), etc.) and/or volatile memory180 (e.g., random access memory (RAM)). A basic input/output system (BIOS)182 can be stored in thenon-volatile memory178, which can include the basic routines that help to transfer information between elements within theprocessing device170. Thevolatile memory180 can also include a high-speed RAM such as static RAM for caching data.
• Theprocessing device170 may further include astorage38, 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. Theprocessing device170 may further include an optical disk drive184 (e.g., for reading a compact disk or DVD186). The drives and associated computer readable media provide non-volatile storage of data, data structures, computer-executable instructions, and so forth. For theprocessing device170, 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 andvolatile memory180 including anoperating system188 and one ormore program modules190 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. Thecentral processing unit172 in conjunction with theprogram modules190 in thevolatile memory180 may serve as a control system for theprocessing device170 that is adapted to implement the functionality described herein.
• In one embodiment, theprogram modules190 may be implemented in software and stored in thevolatile memory180. However, the present disclosure is not limited thereto, and in other embodiments, theprogram modules190 may be implemented in software, hardware, firmware, or any combination thereof.
• A user can enter commands and information into theprocessing device170 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 thecentral processing unit172 through aninput device interface192 that is coupled to thesystem bus176 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.
• Theprocessing device170 may drive a separate orintegral display device16, which may also be connected to thesystem bus176 via an interface, such as avideo output port194. Theprocessing device170 may operate in a networked environment using a wired and/or wirelesscommunication network interface196. Thenetwork interface196 can facilitate wired and/or wireless communications to the network26 (FIG. 1).
• Theprocessing device170 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 (23)

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 ofclaim 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 ofclaim 2, wherein the previous usage data comprises data identifying previous viewings of a plurality of programs during the time slot.

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

5. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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.

Images