U.S. patent application number 12/731730 was filed with the patent office on 2012-05-10 for method and system for determining the availability of a media controller.
This patent application is currently assigned to Eloy Technology, LLC. Invention is credited to Harold Sutherland, Hugh Svendsen.
Application Number | 20120114312 12/731730 |
Document ID | / |
Family ID | 46019710 |
Filed Date | 2012-05-10 |
United States Patent
Application |
20120114312 |
Kind Code |
A1 |
Sutherland; Harold ; et
al. |
May 10, 2012 |
METHOD AND SYSTEM FOR DETERMINING THE AVAILABILITY OF A MEDIA
CONTROLLER
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.
Inventors: |
Sutherland; Harold; (San
Jose, CA) ; Svendsen; Hugh; (Chapel Hill,
NC) |
Assignee: |
Eloy Technology, LLC
Wilmington
DE
|
Family ID: |
46019710 |
Appl. No.: |
12/731730 |
Filed: |
March 25, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61163086 |
Mar 25, 2009 |
|
|
|
Current U.S.
Class: |
386/296 ;
386/E5.001 |
Current CPC
Class: |
H04N 5/76 20130101; H04N
21/4334 20130101; H04N 5/765 20130101; H04N 5/782 20130101; H04N
21/6582 20130101; H04N 21/4583 20130101; G06F 3/0484 20130101; H04N
21/4622 20130101; H04N 21/4756 20130101; H04N 21/43622 20130101;
H04N 21/458 20130101; H04N 21/44222 20130101; H04N 21/6543
20130101; H04N 21/4312 20130101; H04N 21/84 20130101; H04N 21/4263
20130101; H04N 9/8205 20130101; H04N 21/4532 20130101; H04N
21/47214 20130101; H04N 21/43615 20130101; H04N 21/4826 20130101;
H04N 21/252 20130101; H04N 21/4668 20130101 |
Class at
Publication: |
386/296 ;
386/E05.001 |
International
Class: |
H04N 5/91 20060101
H04N005/91 |
Claims
1. A method for scheduling the recording of a program, comprising:
determining a program to record; determining a time associated with
the program; obtaining an availability probability of a first media
controller; and scheduling the recording of the program with the
first media controller based on the availability probability.
2. The method of claim 1, wherein determining the time associated
with the program further comprises determining a time slot
associated with the program, and wherein the availability
probability is based on previous usage data that identifies
previous usage of the first media controller during the time
slot.
3. The method of claim 2, wherein the previous usage data comprises
data identifying previous viewings of a plurality of programs
during the time slot.
4. The method of claim 2, wherein the previous usage data comprises
data identifying a previous recording of a program during the time
slot.
5. The method of claim 1, wherein determining the program to record
comprises: receiving, by the first media controller, a request from
a second media controller to record the program; and wherein
obtaining the availability probability of the first media
controller comprises accessing previous usage data that identifies
previous usage of a first tuner associated with the first media
controller.
6. The method of claim 5, wherein scheduling the recording of the
program based on the availability probability of the first media
controller further comprises: sending the second media controller a
first message indicating that the first media controller is
available to record the program based on the availability
probability of the first media controller; and scheduling the
recording of the program with the first media controller upon
receipt of a second message from the second media controller to
schedule the recording of the program.
7. The method of claim 5, wherein obtaining the availability
probability of the first media controller further comprises
accessing previous usage data that identifies previous usage of a
second tuner associated with the first media controller.
8. The method of claim 7, wherein scheduling the recording of the
program based on the availability probability of the first media
controller comprises: determining a first availability probability
associated with the first tuner; determining a second availability
probability associated with the second tuner; and deriving the
availability probability of the first media controller based on the
first availability probability associated with the first tuner and
the second availability probability associated with the second
tuner.
9. The method of claim 8, wherein scheduling the recording of the
program with the first media controller based on the availability
probability of the first media controller further comprises
scheduling the recording of the program with the first media
controller based on a function of the availability probability of
the first media controller and an availability threshold.
10. The method of claim 1, further comprising accessing a recording
schedule identifying a plurality of time slots during which
programs have been scheduled for recording, wherein scheduling the
recording of the program with the first media controller based on
the availability probability of the first media controller further
comprises scheduling the recording of the program with the first
media controller based on the availability probability of the first
media controller and on the recording schedule.
11. The method of claim 1, further comprising determining a weekday
associated with the program, wherein the availability probability
is based on previous usage data that comprises data identifying
previous usage of the first media controller during the weekday for
each of a plurality of previous weeks, and during the same time
slot.
12. A method for scheduling the recording of a program, comprising:
determining, by a first media controller, a program to record at a
future time; determining that a second media controller is
available to record the program based on an availability
probability of the second media controller; causing, by the first
media controller, a display of information identifying the second
media controller to a viewer; and sending, by the first media
controller, a request to the second media controller to schedule
the recording of the program based on input received from the
viewer in response to the display.
13. The method of claim 12, wherein the availability probability is
based on previous usage data that identifies previous usage
associated with the second media controller, further comprising
accessing the previous usage data, by the first media controller,
from a local storage medium.
14. The method of claim 12, wherein determining that the second
media controller is available to record the program based on the
availability probability of the second media controller further
comprises: sending the second media controller a request to
indicate whether the second media controller is available to record
the program, wherein the second media controller accesses previous
usage data that identifies previous usage associated with the
second media controller on a storage medium that is local to the
second media controller in response to the request.
15. The method of claim 12 wherein determining that the second
media controller is available to record the program based on the
availability probability of the second media controller further
comprises: determining that a third media controller is available
to record the program based on an availability probability of the
third media controller; and wherein causing the display of
information identifying the second media controller to the viewer
further comprises causing the display of information identifying
the second media controller and the third media controller to the
viewer.
16. A method for identifying an available media controller for
recording a program, comprising: receiving, by a computer server, a
request from a first media controller identifying a program to
record; determining, by the computer server, a time slot associated
with the program; obtaining, by the computer server, an
availability probability of a second media controller; determining
that the second media controller is available to record the program
based on the availability probability of the second media
controller; and sending a message to the first media controller
identifying the second media controller based on determining that
the second media controller is available to record the program.
17. The method of claim 16, wherein the method further comprises:
accessing previous usage data that identifies previous usage
associated with a third media controller to determine an
availability probability of the third media controller; and
determining that the third media controller is available to record
the program based on the availability probability of the third
media controller; wherein sending the message to the first media
controller comprises sending a message to the first media
controller identifying the second media controller and the third
media controller.
18. The method of claim 17, further comprising: receiving a second
message from the first media controller identifying the second
media controller; and in response the second message, sending the
second media controller a third message to schedule the program for
recording on the second media controller.
19. The method of claim 17, wherein the availability probability of
the second media controller is based on previous usage data
associated with the second media controller and the availability
probability of the third media controller is based on previous
usage data associated with the third media controller, and wherein
the previous usage data associated with the second media controller
and the previous usage data associated with the third media
controller are stored at the computer server.
20. The method of claim 17, further comprising: receiving a
plurality of usage messages from the second media controller,
wherein each of the plurality of usage messages identifies at least
a time slot during which the second media controller was in
use.
21. The method of claim 20, further comprising generating previous
usage data associated with the second media controller from the
plurality of usage messages.
22. A media controller comprising: a network interface adapted to
communicate with a network; and a control system comprising a
processor and coupled to the network interface, the control system
adapted to: determine a program to record at a future time;
determine that a second media controller is available to record the
program based on an availability probability of the second media
controller; cause a display of information identifying the second
media controller to a viewer; and send a request to the second
media controller to schedule the recording based on input received
from the viewer in response to the display.
23. The media controller of claim 22, wherein to determine that the
second media controller is available to record the program based on
an availability probability of the second media controller, the
media controller is further adapted to: access previous usage data
from a local storage medium coupled to the media controller.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.
[0005] 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
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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
[0012] 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.
[0013] FIG. 1 is an exemplary block diagram of a locale in which
embodiments may be practiced;
[0014] FIG. 2 is a block diagram illustrating additional detail of
a media controller according to one embodiment;
[0015] FIG. 3 is block diagram of an exemplary stored item record
according to one embodiment;
[0016] FIG. 4 is a block diagram illustrating exemplary nodal data
according to one embodiment;
[0017] FIG. 5 is a block diagram of an exemplary recorder according
to one embodiment;
[0018] FIG. 6 is a block diagram of an exemplary merged guide
according to one embodiment;
[0019] FIG. 7 is a flowchart illustrating an exemplary method for
generating program records;
[0020] FIG. 8 is a block diagram illustrating exemplary update
timestamp data according to one embodiment;
[0021] FIG. 9 is a flowchart illustrating an exemplary method for
receiving and processing program metadata sent from one media
controller to another media controller;
[0022] FIG. 10 is a flowchart illustrating an exemplary method for
sending program metadata to another media controller;
[0023] FIG. 11 illustrates an exemplary merged guide at a first
point in time;
[0024] FIG. 12 illustrates the exemplary merged guide illustrated
in FIG. 11 at a second point in time;
[0025] 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;
[0026] FIG. 14 is a flowchart illustrating an exemplary method for
integrating viewer information with a program record;
[0027] FIG. 15 is block diagram illustrating exemplary requests
that one media controller may make of another media controller;
[0028] 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;
[0029] FIG. 17 is a block diagram of an exemplary media controller
usage (MCU) record 150 for storing consolidated previous usage data
associated with the usage of a media controller according to one
embodiment;
[0030] FIG. 18 is block diagram of an exemplary client server
embodiment;
[0031] 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;
[0032] FIG. 20 is block diagram of another exemplary embodiment
implemented in a peer-to-peer architecture;
[0033] 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;
[0034] FIG. 22 illustrates a window which may be displayed on the
display device according to one exemplary embodiment;
[0035] 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
[0036] 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
[0037] 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.
[0038] 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.
[0039] Certain embodiments disclosed herein may be implemented in
conjunction with a merged program guide. Accordingly, prior to
discussing mechanisms for determining the availability of a media
controller to record a program based on previous usage data, the
generation of a merged guide will be illustrated. While the merged
program guide disclosed herein serves as one mechanism by which
previous usage data may be maintained, other embodiments may be
implemented in the absence of a merged program guide, as will be
discussed in greater detail herein. FIG. 1 illustrates a locale 10,
such as a residence, in which media controllers 12A and 12B
(generally, media controller 12 or media controllers 12) are
located. The media controllers 12 may comprise any device capable
of providing, presenting, or otherwise causing the display of
content upon demand, such as, for example, a set top box, a digital
video recorder, an intelligent gaming console, such as the
Microsoft.RTM. Xbox.RTM., Sony.RTM. PlayStation.RTM., and
Nintendo.RTM. GameCube.RTM., a media console such as the Apple.RTM.
TV.RTM., personal computers, and the like.
[0040] The media controllers 12 provide content to one or more
viewers 14 by causing a display on a display device 16. The display
device 16 may comprise any display technology, such as a
television, a computer monitor, a projector, and the like. By
"causing" or "cause" to display it is meant that the media
controllers 12 generate output streams that are provided to output
connections on the media controllers 12 (not illustrated), which
are directed to a respective display device 16, typically via a
cable or other signal-carrying mechanism. While for purposes of
illustration the media controllers 12 and display devices 16 are
illustrated as devices which are separate from one another, the
display device 16 may be integral with the media controller 12. For
example, a single unit may include both a media controller 12, such
as a digital video recorder, and a display device 16, such as a
television. Where a media controller 12 and display device 16 are
integral, the signal-carrying connection between the two may not be
by a connection cable, but rather by an internal bus or other
signal-carrying mechanism.
[0041] The media controller 12A receives content from content
providers 18A and 18B (generally content providers 18, or content
provider 18). The content providers 18 may comprise any provider of
content, including service providers that provide content for a
direct or indirect fee, cable operators, satellite operators,
internet content providers, and the like. The content received by
the media controllers 12 may be any content desirable for
presentation, display or otherwise rendering to a viewer 14, such
as broadcast television, movies, video on demand, music, and the
like. Units of content will be referred to herein as programs, and
a program can refer to any unit of content that is referred to
individually by the content provider, such as a particular
television show, a particular movie, a song, and the like.
[0042] Content is typically, but not necessarily, provided to the
media controllers 12 in a content package that is defined by a
particular subscription. The subscription between the media
controller 12 and the content provider 18 defines which channels
and features make up a particular content package, and therefore
defines the programming that will be provided by the respective
content provider 18 to the media controller 12 pursuant to the
subscription. For example, the media controller 12A may receive a
first content package that includes premium movies and high
definition content from the content provider 18A pursuant to a
first subscription. The media controller 12B may receive a second
content package that includes only standard definition content and
no premium movies from the content provider 18D pursuant to a
different subscription, even though the content provider 18A may be
the same content provider as the content provider 18D. The same
program may therefore be available to the same or different media
controllers 12. Moreover, different versions of the same program
may be available to the same or different media controllers 12. For
example, the media controller 12A may have access to a
high-definition version of a particular episode of the network
program Survivor, while the media controller 12B has access only to
a standard-definition version of Survivor based on the respective
subscriptions.
[0043] The content providers 18 typically provide a guide to the
media controllers 12 that identifies programs available via the
respective content provider 18. Such guides are depicted in FIG. 1
in the form of respective local electronic programming guides 20A,
20B (generally, local guides 20 or local guide 20). While for
purposes of illustration each media controller 12 is shown as
having only a single local guide 20, it will be understood that
each media controller 12 may have multiple local guides 20, since
each content provider 18 may provide its own respective local guide
20 to the media controller 12.
[0044] Local guides 20 typically comprise program metadata
identifying attributes and characteristics of particular programs.
The program metadata may be provided to the media controller 12
continually on a particular channel, or upon request by the media
controller 12, or at certain predetermined times. The program
metadata can include any data that may be useful or desirable to
the viewer 14 (typically as determined by the respective content
provider 18). For example, program metadata may include a title, a
description, identification of well-known actors, a channel on
which the program will be provided, a genre, an MPAA rating, a
duration, a version, a time and date the program will be provided,
and the like. Typically, a viewer 14 accesses a local guide 20 via
an input device (not illustrated) such as a remote control,
wherein, upon receipt of a request via the remote control, the
media controller 12 will cause a display of information from the
local guide 20 on the display device 16.
[0045] The media controllers 12A, 12B may also contain one or more
respective recorded programs 22A, 22B (generally, recorded programs
22 or recorded program 22). The recorded programs 22 may have been
previously selected by the viewer 14 for time-shifting purposes,
for example, to enable the viewer 14 to view a program at a
different time from when the program was originally provided by a
content provider 18. Different programs may be recorded at
different media controllers 12, and thus, for example, the recorded
programs 22A may differ from the recorded programs 22B. The media
controllers 12 may also be communicatively coupled to local
entertainment libraries 24 that contain a variety of programs, such
as movies, songs, videos and the like that may have been
downloaded, ripped, or otherwise obtained by the viewer 14. The
media controllers 12A, 12B also preferably include respective
recording schedules 23A, 23B which identify programs that are
scheduled to be recorded on the respective media controllers 12A,
12B at a future point in time.
[0046] Each of the media controllers 12A, 12B are communicatively
coupled to one another via a local area network 26. The local area
network 26 may comprise any suitable communication mechanism that
enables the media controllers 12A, 12B to communicate with one
another, including, for example, an Ethernet network, Token Ring
network, and the like. The media controllers 12 access the network
26 via communication links 28, which may comprise any suitable
technology for accessing the network 26, such as, for example,
WiFi, an Ethernet cable, and the like. The network 26 may use any
suitable message transport protocol to enable message
communications between the media controllers 12A, 12B, such as, for
example, TCP/IP.
[0047] According to one embodiment, each of the media controllers
12A, 12B also includes a respective merged guide 30A, 30B
(generally, merged guides 30 or merged guide 30). While the
generation and contents of the merged guide 30 will be discussed
later in detail, generally, each merged guide 30 contains program
records identifying programs available from a variety of different
sources, including programs that are available at other media
controllers 12. For example, the merged guide 30A may contain
program records identifying programs available from each of the
content providers 18A-18E, programs available in the entertainment
libraries 24A, 24B, and recorded programs 22A and 22B. Similarly,
the merged guide 30B associated with the media controller 12B also
preferably contains program records identifying programs available
from each of the content providers 18A-18E, programs available in
the entertainment libraries 24A, 24B, and recorded programs 22A and
22B. As will be discussed in greater detail herein, the media
controller 12A may cause a display on the display device 16 which
presents information contained in the merged guide 30A. Thus, a
viewer 14 may use any media controller 12 that is coupled to the
network 26 to determine the entire collection of content that may
be consumed by the viewer 14.
[0048] The media controllers 12 may discover one another on the
network 26 using any suitable device discovery mechanism or
techniques. Device discovery mechanisms are known to those skilled
in the art and will not be described in detail herein. For example,
the media controller 12A may use the Bonjour.RTM. service discovery
protocol to discover the media controller 12B, but the embodiments
are not limited to any particular device discovery mechanism.
[0049] The media controller 12A also preferably maintains media
controller previous usage data identifying previous usage of a
media controller. Previous usage data may include data identifying
that a viewer 14 viewed or recorded a particular program. In some
embodiments, the previous usage data stored on the media controller
12A may comprise data identifying previous usage of the media
controller 12A. In other embodiments, the previous usage data
stored on the media controller 12A may comprise data identifying
previous usage of media controllers 12 other than the media
controller 12A.
[0050] In the embodiment illustrated in FIG. 1, the media
controller 12A maintains remote media controller previous usage
data 25A (referred to hereinafter as "previous usage data 25A" for
purposes of simplicity) which identifies previous usage of another
media controller 12, such as the media controller 12B, and any
other media controllers 12 coupled to the network 26. The word
"remote" is merely a reference to a media controller 12 other than
the media controller 12A, and does not imply a particular physical
distance. For example, the media controller 12B is remote with
respect to the media controller 12A, and vice versa. The previous
usage data 25A may be based on information received from the media
controller 12B, as discussed in greater detail herein. The media
controller 12A may use the previous usage data 25A to determine
previous usage of the media controller 12B, and thereby determine
an availability probability of the media controller 12B for
scheduling the recording of a program upon request by the media
controller 12A. The media controller 12B similarly includes
previous usage data 25B which identifies previous usage of the
media controller 12A, and any other media controllers 12 coupled to
the network 26, for similar purposes. The media controllers 12 also
have respective one or more tuners 34 which may be used to tune to
a particular frequency to access a program being provided by one of
the content providers 18.
[0051] FIG. 2 is a block diagram illustrating additional details of
a media controller 12 according to one embodiment. The media
controller 12 preferably includes nodal data 32, which includes
information that may be unique to the respective media controller
12, such as, for example, a name of the media controller 12, a
serial number associated with the media controller 12, log files
generated by the media controller 12, and the like. Exemplary nodal
data 32 will be discussed in greater detail with reference to FIG.
3. The media controller 12 includes one or more tuners 34 which are
used to select particular content provided by a content provider
18. For example, the content provider 18 may concurrently provide a
number of different programs to the media controller 12, each
program being delivered on a particular frequency. The tuner 34,
for example in response to a channel selection from a viewer 14,
tunes to a particular frequency and captures the program data being
provided at the particular frequency. The tuner 34 then typically
causes the program to be displayed on a display device 16, or may
record the program, as discussed in greater detail herein. While
the tuner 34 has been discussed herein in terms of tuning to a
particular frequency, it will be apparent that programs may be
differentiated from one another by mechanisms other than a
frequency, and the tuner 34 therefore is not limited to a frequency
tuner, but may comprise any suitable tuning mechanism capable of
selecting a desired program from a plurality of programs.
[0052] The media controller 12 preferably includes a recorder 36
for recording a program. The recorder 36 preferably receives input
from the tuner 34, encodes the input into a desired format, if
necessary, and stores the program data in a storage 38. The storage
38 may comprise any suitable storage technology, such as a hard
drive, flash drive, and the like. The storage 38 is preferably a
persistent storage that survives the powering down of the media
controller 12, and may contain data from a variety of sources,
including, for example, the local guide 20, the merged guide 30,
the recording schedule 23, the previous usage data 25, and the
like.
[0053] The media controller 12 may also include a retransmitter 40
which enables the retransmission of a program received by the media
controller 12 onto the network 26. For example, the retransmitter
40 may segment the program data received by the media controller 12
into packets and transmit the packets to another media controller
12 via the network 26. The retransmitter 40 may encode the program
differently from the way the program was encoded when initially
received by the tuner 34. For example, in one embodiment, a first
media controller 12 may request from a second media controller 12 a
program stream of a program currently being presented to viewers 14
by the second media controller 12. The request may identify that a
particular quality, or resolution, of the program stream is
desired. For example, the first media controller 12 may intend to
display the program stream in a relatively small area of a display
device 16 in conjunction with other information, and thus not
require a high resolution program stream. The second media
controller 12 may then encode the program into a sufficiently lower
resolution version of the program prior to transmitting the program
stream onto the network 26 to minimize network usage.
[0054] The media controller 12 may also include a web server 42 for
use in transferring program metadata between media controllers 12.
For example, the web server 42 may respond to requests for program
metadata from other media controllers 12. In one embodiment the
program metadata may be formatted and transferred in an XML format.
The media controller 12 may also include update timestamp data 44
that identifies the times that other media controllers 12 last
provided program metadata to the media controller 12. The update
timestamp data 44 may be used by the media controller 12 to quickly
determine which program metadata received by another media
controller 12 constitutes new program metadata. The receipt of
program metadata by a media controller 12 and the use of the update
timestamp data 44 will be described in greater detail herein.
[0055] FIG. 3 is block diagram of a stored item record 50-1 that
contains data associated with items stored in storage 38, or
elsewhere. The storage 38 may contain a plurality of stored item
records 50-1-50-N. The stored item record 50-1 contains information
identifying, for example, a recorded program 22, or a program in
the entertainment library 24. The stored item record 50-1 may
include a globally unique identifier (GUID) field 52 that contains
a GUID which uniquely identifies the stored item record. The
generation of a GUID is known to those skilled in the art, and will
not be discussed in detail herein. The stored item record 50-1 also
includes a location field 54 identifying a location of the
corresponding program. The location field 54 may indicate the
program resides in the storage 38, the entertainment library 24, or
elsewhere. The stored item record 50-1 preferably includes a
metadata GUID field 56 that contains a metadata GUID which uniquely
identifies a metadata record containing metadata pertaining to the
corresponding program. The metadata record may be in the storage
38, on a local server coupled to the network 26, or on a remote
server accessible by the media controller 12 over a wide area
network coupled to the network 26.
[0056] FIG. 4 is a block diagram illustrating exemplary nodal data
32 according to one embodiment. The nodal data 32 can include a
name field 58 that contains a name which identifies the respective
media controller 12. For example, the name field 58 of the media
controller 12A may be "TIVO DVR", and the name field 58 of the
media controller 12B may be "TimeWarner SetTop." Alternately, the
name field 58 may contain a link or reference to a graphical image
that depicts a particular type of media controller 12. The nodal
data 32 can include a description field 60 that provides a short
textual description of the capabilities of the respective media
controller 12. A capabilities field 62 may identify operations
performable by the respective media controller 12, and power
consumption characteristics. A serial number field 64 may contain a
unique manufacturer serial number of the media controller 12. A
manufacturer field 66 may identify the manufacturer of the media
controller 12. A model field 68 may identify a particular model of
the media controller 12. Logs field 70 may comprise data generated
during the operation of the media controller 12, such as, for
example, faults or errors that occur during the operation of the
media controller 12, and/or input selections received from viewers
14, which programs were watched at which times, and the like.
[0057] A service field 72 may contain service status information
regarding the media controller 12 such as service intervals and/or
wear counts. The wear count may indicate how many times particular
"wear items" have been used. For example, a media controller 12
containing a hard drive may provide a wear count on the hard drive
indicating how many times the hard drive has been written to. This
information may in turn be used to predict how much useful life is
left on the drive. A state field 74 may contain a status of the
media controller 12, such as, for example "Booting", "On",
"Recording", "Sleep", "Updating", and the like. A location field 76
may identify a location of the media controller 12 within the
locale 10. For example, the location field 76 of the media
controller 12A may contain "Den", and the location field 76 of the
media controller 12B may contain "Living Room." The nodal data 32
may also include a preference settings field 78 identifying
preferences of one or more viewers 14. Any desired preference data
may be stored in the preference settings field 78, such as, for
example, genre preferences, actor preferences, time preferences,
series preferences, and the like. Preference data may be used, for
example, by the media controller 12 to provide program
recommendations to a viewer 14.
[0058] FIG. 5 is a block diagram of the recorder 36 according to
one embodiment. The recorder 36 receives a source 80 from the tuner
34. The recorder 36 uses an encoder 82 to encode the source 80 in a
desired format, such as the MPEG-2 format. The encoded program can
be stored in the storage 38. The recorder 36 may include a buffer
84 for use in temporarily storing segments of the source 80 while
it is being encoded.
[0059] FIG. 6 is an exemplary block diagram of a merged guide 30
according to one embodiment. The format of the merged guide 30
depicted in FIG. 6 is but one exemplary layout, and the embodiments
are not limited thereto. The merged guide 30 may include a
plurality of channel records 86, such as channel records 86-1-86-N.
The phrase "record" as used throughout the disclosure means a
structure which contains data and may be stored and accessed as
necessary, and does not imply a particular format or internal
layout. The channel record 86-1 may include an information field 88
that contains text identifying source attributes of the channel,
such as the particular service provider, or other source. For
example, if the channel 86-1 is provided by a service provider via
cable, the information field 88 may contain the name of the cable
company. Alternately, the channel information field 88 may contain
the ultimate source of the content associated with the channel,
such as NBC, ABC, and the like. Where the content associated with
the channel is provided by a local source, such as the
entertainment library 24, the channel information field 88 may
identify the entertainment library 24 by a name, such as "John's
Video Library." The channel 86-1 may also include a rating field 90
that generally describes the content associated with the channel
86-1. For example, if the channel 86-1 is a mature adult channel,
the rating field 90 may identify it as such.
[0060] Each channel 86 may include one or more program records 92.
For example, the channel 86-1 contains a plurality of program
records 92-1-92-N. Each program record 92 contains metadata
associated with a particular program. Thus, each program record 92
corresponds to a particular program. The program record 92 may
contain a GUID field 94 that contains a GUID which uniquely
identifies the program. A title field 96 may contain a textual
title of the program. A start field 98 may identify a present, past
or future start time of the program. A duration field 100
identifies a length of the program. A rating field 102 may contain
an MPAA rating of the program. A quality field 104 may identify the
encoding quality of the program. An alt location field 106 may
contain an alternate location of the program other than the
location identified in the source field 116. For example, the
location identified in the source field 116 may be the source of a
highest quality version of the program, while the alt location
field 106 may provide a lower quality version of the program. In
one embodiment, a uniform resource identifier (URI) represents the
location indicated by the source field 116 and alt location field
106. The URI may point to a local media item, or may reference a
program available from another media controller 12 over the
network.
[0061] A requestors field 108 may contain information identifying
one or more viewers 14 that have requested that the program be
recorded. A viewers list 110 may identify one or more viewers 14
that were identified as being in proximity to the media controller
12 which presented the program. A metadata GUID field 112 may
contain a metadata GUID which uniquely identifies a metadata record
containing metadata describing additional attributes of the
program. The metadata record may exist, for example, on a local or
a remote server accessible by the media controller 12. An
originator field 115 may identify the particular media controller
12 which originated the respective program record 92. A record
update timestamp (TS) field 114 may contain a timestamp identifying
the time of the last update to the record 92-1. A source field 116
may identify a location of the program, and may comprise, for
example, a URI.
[0062] The program record 92 may also include an operation field
117 for identifying a particular operation performed on the
corresponding program by the media controller identified in the
originator field 115. For example, the operation field 117 may
contain a value of 0 to indicate that no operation was performed on
the program, a value of 1 to indicate the program was recorded, a
value of 2 to indicate the program was presented to a viewer 14,
and a value of 3 to indicate that the program was both recorded and
presented to a viewer 14. Where the operation value is greater than
zero, and where the media controller 12 identified in the
originator field 115 has multiple tuners, the originator field 115
may also identify the particular tuner 34 that performed the
identified operation. The operation field 117 may be used by the
media controller 12 to relatively rapidly determine which program
records 92 may be useful for determining the previous usage data
associated with another media controller 12. More particularly,
upon receipt of a program record 92 having an operation value
greater than zero, the media controller 12 may generate a copy of
the program record 92 and store the copy in the previous usage data
25. The use of separate previous usage data 25, while optional,
provides a mechanism to store for desired periods of time previous
usage data associated with other media controllers 12, while
allowing the merged guide 30 to maintain historical program records
92 for a much shorter duration.
[0063] Preferably, each media controller 12 coupled to the network
26 generates program records 92 for each program that is available
at the respective media controller 12. For example, referring again
to FIG. 1, local guide 20A may include guides for programs
available from the content providers 18A and 18B. The media
controller 12A may read the local guide 20A and generate a program
record 92 for each program identified in the local guide 20A. The
media controller 12A may also generate program records 92 for each
recorded program 22A, and each item available for presentation from
the entertainment library 24A. If program metadata for such
programs is unavailable, the media controller 12A may access
well-known sources of program metadata from, for example, an
Internet provider of such data, and use the program metadata to
populate the fields of the program record 92.
[0064] FIG. 7 is a flowchart illustrating an exemplary method for
generating program records 92. Assume that the media controller 12A
is traversing a local guide 20A, and determines that the local
guide 20A identifies a program that is not identified in the merged
guide 30A. For example, the content provider 18A may have recently
provided the media controller 12A new program guide data that
identifies programs that will be available for presentation one
week from the present date. The media controller 12A generates a
program record 92 (step 1000). The media controller 12A then
generates a GUID that uniquely identifies this program (step 1002).
The media controller 12A then populates the fields described above
with regard to FIG. 6 with the appropriate data (step 1004). The
media controller may insert the current time in the record update
timestamp field 114. The media controller 12A then stores the
program record 92 in the merged guide 30 (step 1006).
[0065] Each media controller 12 preferably provides program
metadata from the program records 92 which are available from the
respective media controller 12 to the other media controllers 12.
For example, referring again to FIG. 1, the media controller 12A
provides the media controller 12B program metadata from each of the
program records 92 stored in the merged guide 30A. The media
controller 12B similarly provides the media controller 12A program
metadata from each of the program records 92 in the merged guide
30B. In this manner, each media controller 12 contains program
records 92 identifying programs available at not only the
respective media controller 12, but which are available at all
media controllers 12 coupled to the network 26.
[0066] The program metadata may be provided in the same format as
the program records 92, or in a different format. The program
metadata may be "pushed" as desired by a media controller 12 to the
other media controllers, or may be "pulled" from a media controller
12 upon request. In one embodiment, the program metadata may be
provided in an XML file, which may have a format similar to the
program record 92. In one embodiment, a media controller 12 may
broadcast a signal on the network 26 to indicate that new program
metadata is available. Referring again to FIG. 1, assume that the
media controller 12A has generated one or more new program records
92. The media controller 12A may broadcast a signal on the network
26 indicating that the media controller 12A has new program
metadata for distribution. The media controller 12B, upon receipt
of the signal, may send a message to the media controller 12A
requesting the program metadata. According to one embodiment, each
media controller 12 may maintain a last update timestamp for each
other media controller 12. Such last update timestamps may be
maintained in the update timestamp data 44 (FIG. 2) associated with
the respective media controller 12.
[0067] FIG. 8 is a block diagram illustrating exemplary update
timestamp data 44 according to one embodiment. The update timestamp
data 44 may include one or more last update timestamps 120-1-120-N
(generally, last update timestamps 120), each of which may
correspond to a respective media controller 12. The last update
timestamps 120 identify the time of the last update of program
metadata from the corresponding media controller 12. For purposes
of illustration with regard to FIG. 8, a media controller 12 that
has program metadata to provide to another media controller 12 will
be referred to as a publishing media controller 12, and the media
controller 12 receiving the program metadata will be referred to as
a receiving media controller 12. The receiving media controller 12
may use a last update timestamp 120 to indicate to the publishing
media controller 12 which program records 92 are needed. For
example, in the current example, assume that the last update
timestamp 120-1 corresponds to the publishing media controller 12.
The receiving media controller 12 may provide the last update
timestamp 120-1 to the publishing media controller 12 to indicate
to the publishing media controller 12 that the receiving media
controller 12 only requires program metadata from those program
records 92 that contain a record update timestamp more recent than
the last update timestamp 120-1. The publishing media controller 12
may thus use the last update timestamp 120-1 to generate an XML
file containing only program metadata for those program records 92
which have a record update timestamp that is more recent than the
last update timestamp 120-1. The receiving media controller 12
receives, and then processes, the program metadata and updates the
last update timestamp 120-1 with the latest record update timestamp
associated with any program record 92 provided by the publishing
media controller 12.
[0068] FIG. 9 is a flowchart illustrating an exemplary method for
receiving and processing program metadata sent from one media
controller 12 to another media controller 12. FIG. 9 will be
discussed in conjunction with FIGS. 1 and 6. Again, for purposes of
illustration with regard to FIG. 9, the media controller 12A will
be assumed to have program metadata to distribute to the media
controller 12B, and will be referred to as the publishing media
controller 12A, and the media controller 12B will be referred to as
the receiving media controller 12B. The publishing media controller
12A broadcasts a notification that the publishing media controller
12A has new program metadata available for distribution. The
receiving media controller 12B receives the notification (step
2000). The receiving media controller 12B obtains the last update
timestamp 120-1 which corresponds to the publishing media
controller 12A (step 2002). The receiving media controller 12B
generates a request containing the last update timestamp 120-1 and
sends the request to the publishing media controller 12A (steps
2004, 2006). The publishing media controller 12A uses the last
update timestamp 120-1 to select program metadata from each program
record 92 having a record update timestamp that is later than the
last update timestamp 120-1. The publishing media controller 12A
formats the program metadata and sends it to the receiving media
controller 12B.
[0069] The receiving media controller 12B receives the program
metadata (step 2008). The receiving media controller 12B may, for
each program identified by the program metadata, attempt to match
the program metadata to an existing program record 92 in the merged
guide 30B (step 2010). What constitutes a "match" may be system
dependent. Generally, the receiving media controller 12B may
determine if various data in the provided program metadata matches
corresponding data in any existing program record 92. For example,
the receiving media controller 12B may determine that the program
identified by the metadata matches a program identified by a
program record 92 if the data from the title fields 96 match one
another and the data from the start fields 98 match one
another.
[0070] If the receiving media controller 12B determines that the
provided program metadata matches a program identified by a program
record 92 (step 2012), then the receiving media controller 12B may
generate a child program record 92 from the supplied program
metadata, such that the matched program record 92 in the merged
guide 30A is stored in association with the child program record 92
(step 2014). Among other advantages, establishing such a
parent-child relationship between program records 92 enables the
receiving media controller 12B to cause the display of information
to a viewer 14 that the same program is available at multiple media
controllers 12. If the receiving media controller 12B determines
that the program metadata does not match any existing program
identified in a program record 92 (step 2012), the receiving media
controller 12B may generate a program record 92 as a parent program
record 92 that is not a child program record 92 to any other
program record 92 (step 2016). While for purposes of illustration
only two program records 92 have been shown as stored in
association with one another, it is apparent any number of program
records 92 that identify the same program may be stored in
association with one another.
[0071] FIG. 10 is a flowchart illustrating an exemplary method for
sending program metadata to another media controller. Assume again
that the publishing media controller 12A has new program metadata
to distribute. The publishing media controller 12A broadcasts a
notification signal onto the network 26 indicating that new program
metadata is available (step 3000). The publishing media controller
12A receives a request for data from the receiving media controller
12B (step 3002). The publishing media controller 12A obtains the
last update timestamp 120-1 from the request for data (step 3004).
The publishing media controller 12A obtains program metadata from
those program records 92 having a record update timestamp greater
than the last update timestamp 120-1 (step 3006).
[0072] FIGS. 11 and 12 are block diagrams illustrating exemplary
relationships between several program records 92. FIG. 11
illustrates that at a first point in time, the merged guide 30A
contains a plurality of program records 92A-92C, each of which may
be considered a parent program record 92. Similarly, the merged
guide 30B contains a plurality of program records 92D-92F, each of
which may also be considered a parent program record 92. FIG. 12
illustrates an exemplary relationship between program records 92
after the media controller 12A has communicated the program records
92A-92C to the media controller 12B, and has received from the
media controller 12B the program records 92D-92F. As illustrated,
the media controller 12A determined that the program record 92D
identified the same program as identified by the program record
92A, and consequently made the program record 92D a child record to
the program record 92A. The program record 92E was also determined
to identify the same program as identified by the program record
92B, and was therefore similarly made a child record to the program
record 92B. Because the program record 92F did not match any other
program record 92 in the merged guide 30A, the program record 92F
is made a parent program record 92F.
[0073] A similar analysis was conducted by the media controller
12B, and thus the program record 92A was made a child record of the
program record 92D, and the program record 92B was made a child
record of the program record 92E.
[0074] According to one embodiment, the media controller 12 may
determine the identity of the viewers 14 that are in proximity to
the media controller 12. This information may be stored in the
viewers list 110 of the program records 92 for the corresponding
programs that are presented by the media controller 12. FIG. 13 is
a block diagram illustrating exemplary mechanisms that may be used
by a media controller 12 to determine the identity of a particular
viewer. The media controller 12A in a den 118 is communicatively
coupled to an input device 128. As the viewers 14A, 14B enter the
den 118, each viewer 14A, 14B uses the input device 128 to indicate
that the respective viewer 14A, 14B is in the den 118 and watching
programming presented by the media controller 12A. Prior to exiting
the den 118, each viewer 14A, 14B may use the input device 128 to
indicate they are departing the den 118. The media controller 12A
may maintain the identity of the viewers 14 who are in the den 118,
and for each program provided during the presence of a viewer 14,
update the viewers list 110 in the program record 92 corresponding
to the presented program. The input device 128 may comprise any
suitable device and interface, such as a keyboard, or a mouse and a
computer having a user interface that enables a viewer 14 to simply
click on a designated portion of a display to indicate the presence
or departure of the viewer 14 from the den 118. The computer may be
wirelessly coupled to the media controller 12A, and communicate the
status of incoming and outgoing viewers 14 to the media controller
12 as appropriate.
[0075] The media controller 12B in the living room 122 includes a
facial recognition processor 130 that is able to identify through
facial processing technology the viewers 14C-14E. Facial
recognition technology is known to those skilled in the art, and
will not be described in detail herein. The facial recognition
processor 130 communicates the identity of the viewers 14C-14E to
the media controller 12B. While the facial recognition processor
130 is illustrated as being integral with the media controller 12B,
in an alternate embodiment, the facial recognition processor 130
may be separate from but coupled to media controller 12B via a
wired or wireless communications channel, for example.
[0076] The media controller 12C in a bedroom 124 includes a radio
frequency identification (RFID) processor 134. The RFID processor
134 may receive a signal from a device worn, or carried, by the
viewer 14F. For example, a cell phone of the viewer 14F may emit a
signal that can be received by the RFID processor 134. Upon receipt
of such signal, the RFID processor 134 can communicate the identity
of the viewer 14F to the media controller 12C.
[0077] The media controller 12D in a basement 126 is coupled to a
wireless Bluetooth interface which enables the media controller 12D
to communicate with Bluetooth devices, such as a cell phone, that
contain the appropriate software to interface with the media
controller 12D. Such software may be programmed to emit a signal
that can be detected by the media controller 12D via the wireless
Bluetooth interface 132. The signal may contain an identifier
identifying a particular viewer 14G, 14H. The media controller 12D
may periodically poll the cell phone to determine if the viewer
14G, 14H is still in proximity of the media controller 12D. If the
media controller 12D does not receive a response to the poll, the
media controller 12D may determine that the viewers 14G, 14H are no
longer in proximity of the media controller 12D.
[0078] FIG. 14 is a flowchart illustrating an exemplary method for
storing viewer information into a program record 92. The media
controller 12 determines that a new viewer 14 is in proximity to
the media controller 12, and identifies the new viewer 14 (step
4000). The media controller 12 may use one of the mechanisms
described with regard to FIG. 13, or any other suitable mechanism.
The media controller 12 obtains the program record 92 corresponding
to the program that is currently being provided for display by the
media controller 12 (step 4002). The media controller 12 updates
the viewer list 110 of the program record 92 to include an
identification of the new viewer 14 (4004). Preferably, the media
controller 12 also updates the record update timestamp of the
program record 92. The media controller 12 stores the program
record 92 in the merged guide (step 4006). Note that the media
controller 12 may also broadcast a notification signal to the
network 26 to notify other media controllers 12 that the media
controller 12 has new program metadata to distribute. In this
manner, each media controller 12 coupled to the network 26 may be,
substantially in real-time, provided data that identify who, in
which room, is watching which programs.
[0079] According to another embodiment, the one media controller 12
may send requests to another media controller 12 for information,
or to direct the other media controller 12 to provide a desired
function. FIG. 15 is block diagram illustrating certain requests
that one media controller 12 may make of another media controller
12 according to one embodiment. For example, the media controller
12A may send an IDENTIFY_CURRENT_PROGRAM request 142 to the media
controller 12B. An IDENTIFY_CURRENT_PROGRAM request 142 requests
that the media controller 12B identify the specific program that is
currently being provided by the media controller 12B. In response,
the media controller 12B may provide the media controller 12A the
program record 92 corresponding to the program that the media
controller 12B is currently presenting. The media controller 12A
may send the media controller 12B a RECORDING_STATUS request 144,
which requests information regarding the recording status of the
program that is currently being presented by the media controller
12B. In response, the media controller 12B provides a message
indicating whether the current program being provided by the media
controller 12B is being recorded.
[0080] The media controller 12A may send the media controller 12B a
RECORD PROGRAM REQUEST 146, which requests that the media
controller 12B schedule the recording of a particular program. The
RECORD PROGRAM REQUEST 146 may include the program record 92
corresponding to the program that is to be recorded. In response,
the media controller 12B may determine that no tuner is available
to record the program, or may begin recording the desired program,
or may schedule the desired program for recording if the program
has not begun yet, and if an availability probability of a tuner
exceeds an availability threshold, as discussed in greater detail
herein. The media controller 12B may provide the media controller
12A a message indicating success or failure of the request. The
media controller 12A may send the media controller 12B a
PROVIDE_CURRENT_PROGRAM request 148, which requests that the media
controller 12B provide a program stream of the program that is
currently being provided by the media controller 12B. The media
controller 12B, using the retransmitter 40, may then provide a
program stream of the program which is currently being provided by
the media controller 12B.
[0081] Tuner conflicts may arise during the operation of a media
controller 12. For example, the media controller 12 may have a
single tuner 34, and the viewer 14 may desire to record two
programs in the future concurrently. If the media controller 12 has
only a single tuner 34, the media controller 12 is able to only
record a single program at a time. In one embodiment, to resolve
such a tuner conflict, the previous usage data of another media
controller 12 is processed to determine if the media controller 12
can schedule the recording of one of the two programs.
[0082] FIG. 16 is a flow chart illustrating an exemplary method for
determining if another media controller 12 is available to schedule
a recording of a program. FIG. 16 will be discussed in conjunction
with FIG. 1. Assume for purposes of illustration that the viewer 14
requests the media controller 12A to record two programs
concurrently during the same future time slot (step 5000). The
media controller 12A contains a single tuner 34 and determines a
tuner conflict exists because the media controller 12A can only
record a single program at a time (step 5002). A similar situation
may arise even without input from the viewer 14 where, for example,
a first program has been scheduled to be recorded by the media
controller 12A at a future (but imminent) time, and the viewer 14
is watching a program on a second channel minutes prior to the
scheduled recording of the first program. The media controller 12A
similarly may detect that recording the first program is likely to
conflict with the viewer's 14 current use of the media controller
12A.
[0083] The media controller 12A may determine if other media
controllers 12, such as the media controller 12B, are currently
communicatively coupled to the network 26 (step 5004). Device
discovery mechanisms are known to those skilled in the art and will
not be described in detail herein. For example, the media
controller 12A may use the Bonjour.RTM. service discovery protocol
to discover the media controller 12B, but the embodiments are not
limited to any particular device discovery mechanism. If no other
media controllers 12 are available, the media controller 12A may
cause a display to the viewer 14 identifying the conflict, thereby
enabling the viewer 14 to resolve the conflict by selecting one
program over another program (step 5006). If another media
controller 12 is available, such as the media controller 12B, the
media controller 12A may then access the previous usage data 25A
(generally, previous usage data 25) to determine previous usage
associated with the media controller 12B (step 5008). For example,
the previous usage data 25A may include data extracted from program
records 92 wherein the value of the operation field 117 is greater
than zero. Such data may identify previous usage of the media
controller 12B. For purposes of illustration, assume that the media
controller 12B similarly contains only a single tuner 34B.
[0084] The media controller 12A determines an availability
probability for the media controller 12B (step 5010). The
availability probability may be used to determine whether the tuner
34B is likely to be available during the desired time slot.
Exemplary mechanisms for determining an availability probability
will be discussed herein with respect to FIG. 17. The availability
probability may comprise any indicator used to determine whether or
not a media controller 12 is available to record a program at a
future time based on previous usage data. The availability
probability may, for example, comprise a numeric representation
identifying a probability of availability of the media controller
12B to record a program at a future time. In one embodiment the
availability probability is based on a percentage, and will be
discussed herein in terms of a percentage, or decimal
representation of a percentage. For example, if a probability that
the media controller 12B will be available during the desired time
slot is 70% (i.e., 0.70), then the availability probability of the
media controller 12B is 70% (or 0.70). Where a media controller 12
has a single tuner 34, the availability probability of the tuner 34
is the same as the availability of the media controller 12. Where a
media controller 12 has multiple tuners 34, the availability
probability of the media controller 12 is a function of the
availability probability of each of the tuners 34.
[0085] The media controller 12A determines if the availability
probability of the media controller 12B exceeds an availability
threshold (step 5012). The availability threshold may be a
configurable value that may be adjustable by an administrator of
the network 26, or by a service provider. The availability
threshold may be relatively high to decrease the likelihood that
the receiving media controller 12, i.e., the media controller 12B
in this example, will encounter a tuner conflict at the time of the
scheduled recording. For example, an availability threshold of 90
indicates that the media controller 12B is not available to
schedule the recording unless the availability probability exceeds
90%. Alternately, a low availability threshold may be used to
facilitate eliminating a current tuner conflict at the media
controller 12A at the potential risk of increasing the likelihood
of a tuner conflict on the media controller 12B at the time of the
scheduled recording.
[0086] If the availability probability does not exceed the
availability threshold (step 5012), the process returns to step
5004 where it is determined if another media controller 12 may be
available to schedule the recording. Otherwise, if the availability
probability exceeds the availability threshold (step 5012), the
media controller 12A may send the media controller 12B a request to
schedule the recording of the program (step 5014). In one
embodiment, the media controller 12B may accept or reject such a
request. If the media controller 12B rejects the request (step
5016), the process returns to step 5004 where it is determined if
another media controller 12 may be available to schedule the
recording. If the media controller 12B accepts the request, the
media controller 12A may update the recording schedule 23A to
reflect that the program will not be recorded by the media
controller 12A.
[0087] The phrase time slot is used herein to generally refer to a
particular period of time. A future time slot, for example, may
refer generally to a future period of time during which a program
may be scheduled to be provided to a media controller 12. For
example, the time slot corresponding to a particular program, such
as the Survivor series, may be the 8:00-8:59 time slot. A time slot
preferably has a begin time and an end time, although the begin
time and end times may vary. For example, generally Survivor is
scheduled to be provided in the 8:00 ET time slot, however, due to
advertising and the like, may on particular dates begin at 8:01 or
8:02. While time slots will be referred to herein generally as an
hourly time slot, e.g., from 8:00-8:59 or 8:00-9:00, it will be
apparent that time slots may be any desired length of time, such as
30 minutes.
[0088] FIG. 17 is a block diagram of an exemplary media controller
usage (MCU) record 150 for storing previous usage data associated
with a media controller 12. FIG. 17 will be discussed in
conjunction with FIG. 1. Previous usage data, as described herein,
may be stored in multiple formats. For example, as discussed
previously, previous usage data may be provided by each media
controller 12 in the form of program records 92. Each program
record 92 identifies a particular previous usage of the media
controller. Such information may also be consolidated based on a
desired criteria, such as based on the day of the week of a
previous usage, and the time slot associated with a previous usage.
The MCU record 150 may be generated, for example, by consolidating
information contained in multiple program records 92 over a
predetermined period of time, such as the previous four weeks, or
previous six weeks, for example. In particular, the media
controller 12A may process each program record 92 having an
operation value greater than zero for each media controller 12
coupled to the network 26 that was created within the previous six
weeks. The MCU record 150 is an example of one such consolidation,
in particular, a consolidation based on tuner, day of the week, and
time slot. However, embodiments are not limited to any particular
consolidation of information.
[0089] Moreover, while embodiments have thus far been discussed in
conjunction with the use of the merged program guide 30, it should
be apparent that media controller previous usage data identifying
previous usage activity of the media controller 12B could be
generated and broadcast to other media controllers 12 without the
existence of the merged guide 30. For example, a previous usage
data record may be defined that includes information such as the
start field 98, the duration field 100, the originator field 115
and the operation field 117. Each time an operation on the media
controller 12B occurs, the media controller 12B could generate a
previous usage data record and broadcast the record to the other
media controllers 12 on the network. Each recipient media
controller 12 could then use the data to maintain a MCU record 150
for the media controller 12B.
[0090] For purposes of illustration assume that the media
controller 12A has determined that a tuner conflict exists with
regard to a request to schedule the recording of a program during a
23:00-23:59 time slot on Monday. Assume that the MCU record 150
contains information corresponding to the media controller 12B. The
media controller 12A may continually update the MCU record 150 with
new information as it is received from the media controller
12B.
[0091] The MCU record 150 includes a tuner usage record 152 for
each tuner 34 contained in the media controller 12B. In this
example, assume that the media controller 12B contains two tuners
34, and thus the MCU record 150 includes a tuner usage record 152A
and a tuner usage record 152B (generally, the tuner usage record
152 or the tuner usage records 152). Each tuner usage record 152
includes seven usage-by-day (UBD) records 154. The tuner usage
record 152A thus contains UBD records 154A-1-154A-7. Each UBD
record 154A contains previous usage data associated with a
particular weekday. The tuner usage record 152B similarly contains
UBD records 154B-1-154B-7. Each UBD record 154 contains a plurality
of usage-by-time slot (UBT) records. Assuming hourly time slots,
for example, the UBD record 154A-1 contains 24 UBT records
156-1-156-24. Thus each UBT record 156 contains previous usage data
associated with a particular hour of the particular day
corresponding to a UBD record 154. Similarly, the UBD record 154A-7
contains 24 UBT records 158-1-158-24. Each UBT record 156, 158,
160, and 162 identifies a usage factor of the respective tuner
during a particular time slot. The usage factor may represent the
frequency, by percentage, that the corresponding tuner 34 is busy
either presenting a program for display to a viewer or recording a
program during the respective time slot. Alternately, the usage
factor may represent the frequency that the corresponding tuner 34
is not busy.
[0092] Assuming that the usage factor represents the frequency, by
percentage, that the corresponding tuner 34 is busy, the
availability probability (AP) of the tuner 34 during the respective
time slot can thus be determined by the following formula:
AP.sub.Tuner.sub.--.sub.Timeslot=(1-usage factor.sub.Timeslot)
[0093] AP.sub.Tuner.sub.--.sub.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.sub.Timeslot is the usage factor associated with that tuner
during that day of the week and at that time slot.
[0094] For example, the AP of Tuner A (tuner usage record 152A)
during Time Slot 24 of Day 1 (Monday) indicated by the UBT record
156-24 may be calculated in the following manner:
AP.sub.TunerA.sub.--.sub.Timeslot24=(1-0.23)=0.78=78%
[0095] Similarly, the AP of Tuner B (tuner usage record 152B)
during Time Slot 24 of Day 1 (Monday) indicated by the UBT record
160-24 during Time Slot 24 of Day 1 (Monday) indicated by the UBT
record 160-24 may be calculated in the following manner:
AP.sub.TunerB.sub.--.sub.Timeslot24=(1-0.92)=0.08=8%
[0096] It is apparent each UBT record 156-162 could contain the
availability probability rather than the usage factor. To derive or
otherwise determine the aggregate availability probability of a
media controller for a particular time slot the following formula
may be used:
AP.sub.mediacontroller=Sum(AP.sub.each tuner)/number of tuners
[0097] In the present example, assuming the media controller 12B
contains two tuners 34, the following formula may be used:
AP mediacontroller 12 B = ( AP TunerA_Timeslo t 24 + AP
TunerB_Timeslo t 24 ) / 2 = ( .78 + .08 ) / 2 = .43 = 43 %
##EQU00001##
[0098] The media controller 12A also preferably accesses the
recording schedule 23B of the media controller 12B. The recording
schedule 23B identifies the scheduled recordings of the media
controller 12B. The recording schedule 23B may identify that the
one or both tuners 34 may be busy during the 23:00-23:59 time slot
on Monday recording a program, and may identify the particular
programs that are scheduled to be recorded. If the media controller
12A determines that both tuners 34 of the media controller 12B are
scheduled to record a program during the 23:00-23:59 time slot on
Monday, the media controller 12A may determine the availability
probability is 0 for the media controller 12B prior to even
accessing the MCU record 150. However, if the media controller 12A
determines from the recording schedule 23B that the program which
the media controller 12A would like the media controller 12B to
schedule for recording is already scheduled for recording on the
media controller 12B, the media controller 12A may determine the
availability probability is 100.
[0099] Where the recording schedule 23B indicates that one tuner 34
will not be available due to a scheduled recording, the
availability probability may be calculated as the lowest
availability probability of either of the tuners 34.
[0100] FIG. 18 is block diagram of embodiments implemented in a
client server architecture. Each media controller 12 sends previous
usage records identifying previous usage of the respective media
controller 12 to a computer server 164, which stores such
information in the media controller previous usage data 25. If a
merged guide 30 is maintained on the server 164, the information
may be provided in program records 92 as discussed previously. If
embodiments are being implemented in the absence of a merged guide
30, a previous usage data record may be defined that includes
information such as the start field 98, the duration field 100, the
originator field 115 and the operation field 117, as discussed
previously, to provide such information to the server 164.
[0101] FIG. 19 is a flow chart illustrating an exemplary method for
determining if another media controller 12 is available to schedule
the recording of a program in the client-architecture illustrated
in FIG. 18. FIG. 19 will be discussed in conjunction with FIG. 18.
Assume for purposes of illustration that a viewer requests the
media controller 12A to record two programs concurrently during the
same time slot. The media controller 12A contains a single tuner 34
and determines a conflict exists because the media controller 12A
can only record a single program at a time. The media controller
12A sends a request to the server 164 to locate another media
controller 12 for scheduling the recording of one of the programs.
The request may include information such as the program name, the
day and time slot, the channel, and any other suitable information.
The server 164 receives the request (step 6000). The server 164
determines if other media controllers 12 are present on the network
(step 6002). Assume that the media controller 12B is present. The
server 164 obtains the previous usage data of the media controller
12B from the media controller previous usage data 25 (step 6004).
For example, the server 164 may obtain a MCU record 150
corresponding to the media controller 12B.
[0102] The server 164 determines the availability probability for
the media controller 12B (step 6006). The availability probability
may be determined as discussed previously with regard to FIG. 16,
and for the sake of brevity will not be repeated again herein. The
server 164 determines if the availability probability of the media
controller 12B is greater than the availability threshold (step
6008). The availability threshold may have been included in the
request from the media controller 12A, or may apply to all media
controllers 12 and be stored on the server 164. If the availability
probability is not greater than the availability threshold, the
process may return to step 6002 where the server 164 determines if
there are other present media controllers 12. If the availability
probability of the media controller 12B is greater than the
availability threshold, the identity of the media controller 12B
may be stored in an available media controllers list (step 6010).
In one embodiment, as soon as any media controller 12 is determined
to be available to schedule a recording, the identity of the media
controller 12 is provided to the media controller 12A. In another
embodiment, the availability probability of each media controller
12 coupled to the network 26 may be determined, and each media
controller 12 that is determined to be available to schedule a
recording is identified to the media controller 12A.
[0103] At step 6002, if no other media controllers 12 are present
then the server 164 determines whether any media controllers 12
were identified as being available to schedule the recording of the
program (step 6012). If not, the server 164 may send the media
controller 12A a message indicating that there are no available
media controllers 12 to schedule the recording of the program (step
6014). Otherwise, the server 164 sends the media controller 12A a
message identifying the available media controllers 12. The media
controller 12A may select one of the available media controllers
12, and send the selected media controller 12 a request to schedule
the recording of the program. In another embodiment, rather than
identify the available media controllers 12 to the media controller
12A, the server 164 may select an available media controller 12 and
send the selected media controller 12 a request to schedule the
recording of the program. Upon receipt of a confirmation from the
selected media controller 12, the server 164 may then identify the
selected media controller 12 to the media controller 12A,
indicating that the selected media controller 12 has scheduled the
recording of the program.
[0104] FIG. 20 is block diagram of another exemplary embodiment
implemented in a peer-to-peer architecture. Similar to FIG. 1, each
media controller 12 may have a merged guide 30 containing program
records 92 of all media controllers 12 coupled to the network.
However, as discussed previously, the merged guide 30 is optional,
and embodiments may be practiced in the absence of the merged guide
30. In the exemplary embodiment illustrated in FIG. 20, each media
controller 12 contains media controller previous usage data 25 that
contains previous usage data associated with the respective media
controller 12, rather than previous usage data of other media
controllers 12. For example, the media controller previous usage
data 25A includes previous usage data of the media controller 12A,
and the media controller previous usage data 25B includes previous
usage data of the media controller 12B.
[0105] FIG. 21 is a flow chart illustrating an exemplary method for
determining if another media controller 12 is available to schedule
a recording of a program in the exemplary peer-to-peer architecture
illustrated in FIG. 20.
[0106] FIG. 21 will be discussed in conjunction with FIG. 20.
Assume for purposes of illustration that a viewer 14 requests the
media controller 12A to record two programs concurrently during the
same time slot. The media controller 12A contains a single tuner 34
and determines a conflict exists because the media controller 12A
can only record a single program at a time. The media controller
12A sends a request to the media controller 12B scheduling the
recording of one of the programs. The request may include
information such as the program name, the day and time slot, the
channel, and any other suitable information.
[0107] If the media controller 12A includes the merged guide 30A,
the media controller 12A may provide the program record 92
corresponding to the program that is to be recorded. The media
controller 12B receives the request (step 7000). The media
controller 12B obtains the previous usage data of the media
controller 12B from the media controller previous usage data 25B
(step 7002). The media controller 12B determines the availability
probability for the media controller 12B (step 7004). The
availability probability may be determined as discussed previously
with regard to FIG. 16, and for the sake of brevity will not be
repeated again herein. The media controller 12B determines if the
availability probability of the media controller 12B is greater
than the availability threshold (step 7006). If so, the media
controller 12B may schedule the recording of the program (step
7008). The media controller 12B may then update the recording
schedule 23B (step 7010). The media controller 12B sends an
acceptance message to the media controller 12A (step 7012). If the
availability probability of the media controller 12B is less than
the availability threshold (step 7006), the media controller 12B
may send the media controller 12A a denial message indicating the
media controller 12B is not available to record the program (step
7014).
[0108] FIG. 22 illustrates a window 168 which may be displayed on
the display device 16 according to one exemplary embodiment. Assume
again for purposes of illustration that a viewer 14 requests the
media controller 12A to record two programs concurrently during the
same time slot. The media controller 12A contains a single tuner 34
and determines a conflict exists because the media controller 12A
can only record a single program at a time. Assume that the media
controller 12A determines that two media controllers 12 are coupled
to the network 26 that are available for scheduling a recording of
one of the programs. The media controller 12A may have determined
this in conjunction with the server 164 (FIG. 18), may have
determined it by examining the remote media controller previous
usage data 25A containing previous usage data of other media
controllers 12 (FIG. 1), or may have determined it by asking each
other media controller 12 if the media controller 12 is available
to schedule the recording of the particular program.
[0109] FIG. 23 is a flowchart illustrating an exemplary method for
providing a viewer 14 an option to select another media controller
12 to resolve a tuner conflict. FIG. 23 will be discussed in
conjunction with FIG. 22. The media controller 12A causes a display
of the window 168 on the display device 16A (step 8000). The window
168 may identify to the viewer 14 that a conflict exists, and
identify that a media controller 12 identified as the "DEN DVR" and
a media controller 12 identified as the "BEDROOM DVR" are each
available for recording the selected program. The viewer 14 may
select one of the identified media controllers 12 by, for example,
actuating a check box adjacent to the selected media controller 12,
and actuating a "Use Selected" button. Alternatively, the viewer 14
may allow the media controller 12A to select the media controller
12 by actuating a "Select One" button. Assume that that the viewer
14 selects the DEN DVR (step 8002). The media controller 12A may
then send the DEN DVR media controller 12 a request to schedule the
recording of the program (step 8004). The media controller 12A may
then update the recording schedule 23A as appropriate (step
8006).
[0110] In one embodiment, after a media controller 12 records a
program, it may transfer the recorded program over the network 26
to the media controller 12 which requested that it be recorded.
Thus, the window 168 may include a "copy back" option which the
viewer 14 may actuate to indicate that the viewer 14 would like the
DEN DVR media controller 12 to transmit the recorded program to the
media controller 12A upon completion of the recording. This may be
communicated by the media controller 12A to the DEN DVR media
controller 12 in the request to schedule the recording of the
program.
[0111] In one embodiment, the media controller 12 may implement all
or part of the Universal Plug and Play (UPnP) set of networking
protocols. One media controller 12 may serve as a UPnP control
point when requesting another media controller 12 to schedule the
recording of a program, for example. Each media controller 12 may
implement at least certain UPnP services, such as
ConnectionManager, to enable the streaming of programs from one
media controller 12 to another media controller 12,
ContentDirectory to provide access to the recorded music and videos
at a media controller 12, and ScheduledRecordings to allow each
media controller 12 access to the recording schedule 23 of the
other media controllers 12.
[0112] FIG. 24 illustrates an exemplary processing device 170 which
may be used to implement a media controller 12, or a server 164,
according to some embodiments. The processing device 170 may, when
implementing a media controller 12, comprise a set top box, a
digital video recorder, an intelligent gaming console, such as the
Microsoft.RTM. Xbox.RTM., Sony.RTM. PlayStation.RTM., and
Nintendo.RTM. GameCube.RTM., a media console such as the Apple.RTM.
TV.RTM., personal computers, and the like. In addition to
components discussed previously herein, the exemplary processing
device 170 may also include a central processing unit 172, a system
memory 174, and a system bus 176. The system bus 176 provides an
interface for system components including, but not limited to, the
system memory 174 and the central processing unit 172. The central
processing unit 172 can be any of various commercially available or
proprietary processors. Dual microprocessors and other
multi-processor architectures may also be employed as the central
processing unit 172.
[0113] The media controller 12 may include one or more tuners 34
for selecting program content from a communications channel. The
recorder 36 may receive a source input from the tuner 34 and store
the content onto a storage device, such as the storage 38. The
retransmitter 40 may provide a stream of program content over the
network 26 to another media controller 12.
[0114] The system bus 176 can be any of several types of bus
structures that may further interconnect to a memory bus (with or
without a memory controller), a peripheral bus, and a local bus
using any of a variety of commercially available bus architectures.
The system memory 174 can include non-volatile memory 178 (e.g.,
read only memory (ROM), erasable programmable read only memory
(EPROM), electrically erasable programmable read only memory
(EEPROM), etc.) and/or volatile memory 180 (e.g., random access
memory (RAM)). A basic input/output system (BIOS) 182 can be stored
in the non-volatile memory 178, which can include the basic
routines that help to transfer information between elements within
the processing device 170. The volatile memory 180 can also include
a high-speed RAM such as static RAM for caching data.
[0115] The processing device 170 may further include a storage 38,
which may comprise, for example, an internal hard disk drive (HDD)
(e.g., enhanced integrated drive electronics (EIDE) or serial
advanced technology attachment (SATA)) for storage. The processing
device 170 may further include an optical disk drive 184 (e.g., for
reading a compact disk or DVD 186). The drives and associated
computer readable media provide non-volatile storage of data, data
structures, computer-executable instructions, and so forth. For the
processing device 170, the drives and media accommodate the storage
of any data in a suitable digital format. Although the description
of computer-readable media above refers to an HDD and optical media
such as a CD-ROM or DVD, it should be appreciated by those skilled
in the art that other types of media which are readable by a
computer, such as Zip disks, magnetic cassettes, flash memory
cards, cartridges, and the like, may also be used in the exemplary
operating environment, and further, any such media may contain
computer-executable instructions for performing novel methods of
the disclosed architecture.
[0116] A number of program modules can be stored in the drives and
volatile memory 180 including an operating system 188 and one or
more program modules 190 which implement the functionality
described herein. It is to be appreciated that the embodiments can
be implemented with various commercially available operating
systems or combinations of operating systems. All or a portion of
the embodiments may be implemented as a computer program product,
such as a computer usable medium having a computer-readable program
code embodied therein. The computer-readable program code can
include software instructions for implementing the functionality of
embodiments described herein. The central processing unit 172 in
conjunction with the program modules 190 in the volatile memory 180
may serve as a control system for the processing device 170 that is
adapted to implement the functionality described herein.
[0117] In one embodiment, the program modules 190 may be
implemented in software and stored in the volatile memory 180.
However, the present disclosure is not limited thereto, and in
other embodiments, the program modules 190 may be implemented in
software, hardware, firmware, or any combination thereof.
[0118] A user can enter commands and information into the
processing device 170 through one or more wired/wireless input
devices, for example, a keyboard and a pointing device, such as a
mouse (not illustrated). Other input devices (not illustrated) may
include a microphone, an infrared (IR) remote control, a joystick,
a game pad, a stylus pen, a touch screen, or the like. These and
other input devices are often connected to the central processing
unit 172 through an input device interface 192 that is coupled to
the system bus 176 but can be connected by other interfaces such as
a parallel port, an IEEE 1394 serial port, a game port, a universal
serial bus (USB) port, an IR interface, etc.
[0119] The processing device 170 may drive a separate or integral
display device 16, which may also be connected to the system bus
176 via an interface, such as a video output port 194. The
processing device 170 may operate in a networked environment using
a wired and/or wireless communication network interface 196. The
network interface 196 can facilitate wired and/or wireless
communications to the network 26 (FIG. 1).
[0120] The processing device 170 may be operable to communicate
with any wireless devices or entities operatively disposed in
wireless communication, for example, a printer, a scanner, a
desktop and/or portable computer via wireless technologies, such as
Wi-Fi and Bluetooth, for example.
[0121] 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.
[0122] 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.
* * * * *