U.S. patent application number 11/606716 was filed with the patent office on 2007-04-05 for method and apparatus for combining broadcast schedules and content on a digital broadcast-enabled client platform.
Invention is credited to Jay H. Connelly, Jason C. Hallford.
Application Number | 20070079324 11/606716 |
Document ID | / |
Family ID | 25317806 |
Filed Date | 2007-04-05 |
United States Patent
Application |
20070079324 |
Kind Code |
A1 |
Hallford; Jason C. ; et
al. |
April 5, 2007 |
Method and apparatus for combining broadcast schedules and content
on a digital broadcast-enabled client platform
Abstract
.sctn.A service provider broadcast system and method are
described. The method includes acquiring network service
information regarding broadcast service content to be broadcast by
a broadcast service system over a predetermined period. Using the
network service information, a composite content list is created,
including meta-data describing service provider content available
from the service provider system and the broadcast service content.
The composite content listed is broadcast to client systems, which
in turn, provide ratings for the service provider and broadcast
service content described by the composite content list. Using the
received ratings, the service provider system selects a portion of
the broadcast service content and generates a broadcast schedule
for the selected content. The broadcast schedule is then broadcast
to the client systems to enable the client systems to store one or
more of the content data files from the selected portion of the
broadcast service content.
Inventors: |
Hallford; Jason C.;
(Hillsboro, OR) ; Connelly; Jay H.; (Portland,
OR) |
Correspondence
Address: |
INTEL/BLAKELY
12400 WILSHIRE BOULEVARD, SEVENTH FLOOR
LOS ANGELES
CA
90025-1030
US
|
Family ID: |
25317806 |
Appl. No.: |
11/606716 |
Filed: |
November 29, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09854129 |
May 11, 2001 |
|
|
|
11606716 |
Nov 29, 2006 |
|
|
|
Current U.S.
Class: |
725/28 ;
348/E7.07 |
Current CPC
Class: |
H04N 21/4756 20130101;
H04N 21/25891 20130101; H04N 7/17309 20130101; H04N 21/26603
20130101; H04N 21/84 20130101; H04N 21/26283 20130101; H04N
21/26258 20130101; H04N 21/2665 20130101 |
Class at
Publication: |
725/028 |
International
Class: |
H04N 7/16 20060101
H04N007/16 |
Claims
1. A method, comprising: acquiring network service information
regarding broadcast service content to be broadcast by a broadcast
service system over a predetermined period of time; creating a
composite content list including meta-data describing service
provider content available from a service provider system and the
broadcast service content to be broadcast by the broadcast service
system; rating the service provider and broadcast service content,
described by the composite content list; and broadcasting a
broadcast schedule for a selected portion of the broadcast service
content to the one or more client systems in response to the
received ratings, prior to broadcast by the broadcast service
system, thereby enabling the one or more client systems to store
one or more content data files from the selected portion of the
broadcast service content.
2. The method of claim 1, further comprising: broadcasting the
composite content list to one or more client systems; receiving
ratings for the service provider and broadcast service content,
described by the composite content list from the one or more client
systems; selecting a portion of the content data files from the
service provider content and the broadcast service content having
higher ratings based on the received ratings; determining
overlapping content data files as content data files from the
selected portion of the broadcast service content and the service
provider content to be broadcast by the broadcast service system;
eliminating, from the selected portion of the service provider
content and the broadcast service content, the overlapping content
data files to form a plurality of provider content data files; and
broadcasting the plurality of the provider content data files to
the one or more client systems.
3. The method of claim 2, further comprising broadcasting:
broadcasting a composite content broadcast schedule for the
composite content list prior to broadcasting the composite content
list to the one or more client systems; and broadcasting a provider
broadcast schedule for the provider content data files prior to
broadcasting the provider content data files.
4. The method of claim 1 further comprising: selecting one or more
content data files from the selected portion of the broadcast
service content; and broadcasting, by the service provider system,
the one or more selected content data files to the one or more
client systems.
5. The method of claim 1 further comprising: receiving compensation
for each stored content data file accessed by a user; and dividing
the compensation between the service provider system and the
broadcast service system based on a source of each content data
file, such that the source of the content data file is one of the
service provider system and the broadcast service system and
receives a larger compensation portion and a non-source receives a
smaller compensation portion.
6. The method of claim 1, wherein the creating the composite
content list further comprises: eliminating content meta-data from
the broadcast service content and the network service information
that falls into one or more predetermined content categories; and
tagging the network service information with a key to enable
identification of duplicate content.
7. A method, comprising: rating, in response to a content rating
table, at least one content data file from service provider content
available from a service provider system and broadcast service
content to be broadcast by a broadcast service system, as described
by a composite content list, the content rating table generated
responsive to a user; receiving a broadcast schedule for a selected
portion of the broadcast service content broadcast by the broadcast
service system; and when content data files from the selected
portion of the broadcast service content are available, based on
the broadcast schedule, storing one or more of the content data
files based on the content rating table.
8. The method of claim 7 further comprising: receiving a provider
broadcast schedule for a plurality of provider content data files
from the service provider content; receiving the plurality of the
provider content data files; and storing, based on the content
rating table, one or more content data files from the plurality of
the provider content data files.
9. The method of claim 7 further comprising: receiving a composite
content list including meta-data describing service provider
content available from the service provider system and the
broadcast service content to be broadcast by the broadcast service
system; receiving a broadcast schedule for the composite content
list broadcast by the service provider system, the client system
activated in response to the broadcast schedule; and transmitting
the ratings of the at least one content data file from the service
provider content and broadcast service content to the service
provider system.
10. The method of claim 7, wherein the storing the one or more
content data files further comprises: siphoning MPEG data
representing each of the one or more content data files from a
decode stage of an MPEG content transport stream; storing
elementary streams and attendant data from the siphoned MPEG data;
encoding the stored streams and data into packetized element
streams; re-multiplexing the packetized element streams into a
captured content transport stream; and storing the captured content
transport stream into a secondary cache to enable playback, by a
user, of the one or more content data files represented by the
captured content transport stream.
11. The method of claim 7, wherein the storing the one or more
content data files further comprises: capturing the one or more
content data files using content capture functionality of the
client platform; encoding the captured content data files into
packetized element streams; and storing the packetized element
stream into a secondary cache to enable playback, by a user, of the
one or more content data files represented by the packetized
element streams.
12. An apparatus, comprising: a processor having circuitry to
execute instructions; a communications interface coupled to the
processor, the communications interface to broadcast data to one or
more client systems, and to receive data from the one or more
client systems; a storage device coupled to the processor, having
sequences of instructions stored therein, which when executed by
the processor cause the processor to: acquire network service
information regarding broadcast service content to be broadcast by
a broadcast service system over a predetermined period of time,
create a composite content list including meta-data describing
service provider content available from a service provider system
and the broadcast service content to be broadcast by the broadcast
service system, broadcast the composite content list to one or more
client systems, rate the service provider and broadcast service
content described by the composite content list, and broadcast a
broadcast schedule for a selected portion of the broadcast service
content to the one or more client systems in response to the
received ratings, prior to broadcast by the broadcast service, to
enable the one or more client systems to store one or more content
data files from the selected portion of the broadcast service
content.
13. The apparatus of claim 12 wherein the processor is further
caused to: broadcast the composite content list to one or more
client systems, receive ratings for the service provider and
broadcast service content described by the composite content list
from the one or more client systems, select one or more content
data files from the selected portion of the broadcast service
content, and broadcast, by the service provider system, the one or
more selected content data files to the one or more client
systems.
14. The apparatus of claim 12 wherein the processor is further
caused to: select a portion of the content data files from the
service provider content and the broadcast service content having
higher ratings based on the received ratings; determine overlapping
content data file as content data files from the portion of the
broadcast service content and the service provider content to be
broadcast by the broadcast service system; eliminate, from the
selected portion of the service provider content and the broadcast
service content, the overlapping content data files to form a
plurality of provider content data files; and broadcast the
plurality of the provider content data files to the one or more
client systems in response to the received ratings.
15. The apparatus of claim 12 wherein the instruction to create a
composite content list further causes the processor to: eliminate
content meta-data from the broadcast service content and the
network service information that falls into one or more
predetermined content categories; and tag the network service
information with a key to enable identification of duplicate
content.
16. The apparatus of claim 12 wherein the processor is further
caused to: broadcast a broadcast schedule for the composite content
list prior to broadcasting the composite content list to the one or
more client systems; and broadcast a provider broadcast schedule
for the plurality of the provider content data prior to
broadcasting the plurality of the provider content data files.
17. An apparatus, comprising: a processor having circuitry to
execute instructions; a communications interface coupled to the
processor, the communications interface to receive data broadcast
from a service provider system, and to transmit data to the service
provider system; a storage device coupled to the processor, having
sequences of instructions stored therein, which when executed by
the processor cause the processor to: rate, in response to a
content rating table, at least one content data file from service
provider content available from the service provider system and the
broadcast service content to be broadcast by a broadcast service
system, as described by a composite content list, the content
rating table generated responsive to a user, receive a broadcast
schedule for a selected portion of the broadcast service content
broadcast by the broadcast service system, and when content data
files from the selected portion of the broadcast service content
are available based on the broadcast service broadcast schedule,
store one or more of the content data files based on the content
rating table.
18. The apparatus of claim 17 wherein the processor is further
caused to: receive a service provider broadcast schedule for a
plurality of provider content data files; receive the plurality of
the provider content data files; and store, based on the content
rating table, one or more content data files from the plurality of
the provider content data file.
19. The apparatus of claim 17 wherein the processor is further
caused to: receive a composite content list including meta-data
describing service provider content available from the service
provider system and the broadcast service content to be broadcast
by the broadcast service system; receive a broadcast schedule for
the composite content list broadcast by the service provider
system, the client system activated in response to the broadcast
schedule; and transmit the ratings of the at least one content data
file from the service provider content and broadcast service
content to the service provider system.
20. The apparatus of claim 17, wherein the instruction to store the
one or more content data files further causes the processor to:
siphon MPEG data representing each of the one or more content data
files from a decode stage of an MPEG content transport stream;
store elementary streams and attendant data from the siphoned MPEG
data; encode the stored streams and data into a packetized element
stream; re-multiplex the packetized element streams into a captured
content transport stream; and store the captured content transport
stream into a secondary cache to enable playback, by a user, of one
or more content data files represented by the captured content
transport stream.
21. The apparatus of claim 19, wherein the instruction to store the
one or more content data files further causes the processor to:
capture the one or more content data files using content capture
functionality of the client platform; encode the captured content
data file into packetized element streams; and store the packetized
element streams into a secondary cache to enable playback, by a
user, of the one or more content data files represented by the
packetized element streams.
22. A machine-readable medium having instructions stored thereon,
which when executed by a processor cause the processor to: acquire
network service information regarding broadcast service content to
be broadcast by a broadcast service system over a predetermined
period of time; create a composite content list including meta-data
describing service provider content available from a service
provider system and the broadcast service content to be broadcast
by the broadcast service system; rate the service provider and
broadcast service content, described by the composite content list;
and broadcast a broadcast schedule for a selected portion of the
broadcast service content to the one or more client systems in
response to the received ratings, prior to broadcast by the
broadcast service system, thereby enabling the one or more client
systems to store one or more content data files from the selected
portion of broadcast service content.
23. The machine-readable medium of claim 22 wherein the processor
is further caused to: broadcast the composite content list to one
or more client systems, receive ratings for the service provider
and broadcast service content described by the composite content
list from the one or more client systems, select a portion of the
content data files from the service provider content and the
broadcast service content having higher ratings based on the
received ratings; determine overlapping content data files as
content data files from the selected portion of the broadcast
service content and the service provider content to be broadcast by
the broadcast service system; eliminate, from the selected portion
of the service provider content and the broadcast service content,
the overlapping content data files to form a plurality of provider
content data files; and broadcast the plurality of the provider
content data files to the one or more client systems.
24. The machine-readable medium of claim 22 wherein the processor
is further caused to: receive ratings for the service provider and
broadcast service content, described by the composite content list,
from the one or more client systems; and combine the ratings
received from the one or more client systems, if ratings are
received from more than one client system, to generate an overall
ratings list of the service provider and broadcast service content
data files.
25. A machine-readable medium having instructions stored thereon,
which when executed by a processor cause the processor to: rate, in
response to a content rating table, at least one content data file
from service provider content available from a service provider
system and the broadcast service content to be broadcast by a
broadcast service system, as described by a composite content list,
the content rating table generated responsive to a user; receive a
broadcast schedule for a selected portion of the broadcast service
content broadcast by the broadcast service system; and when content
data files from the selected portion of the broadcast service
content are available, based on the broadcast schedule, store one
or more of the content data files based on the content rating
table.
26. The machine-readable medium of claim 25 wherein the processor
is further caused to: receive a composite content list including
meta-data describing the service provider content available from
the service provider system and the broadcast service content to be
broadcast by the broadcast service system; transmit the ratings of
the at least one content data file from the service provider
content and broadcast service content to the service provider
system; receive a provider broadcast schedule for a plurality of
provider content data files; receive the plurality of the provider
content data files; and store, based on the content rating table,
one or more content data files from the plurality of the provider
content data files.
27. The machine-readable medium of claim 25 wherein the instruction
to store one or more of the content data files further causes the
processor to: siphon MPEG data representing each of the one or more
content data files from a decode stage of an MPEG content transport
stream; store elementary streams and attendant data from the
siphoned MPEG data; encode the stored streams and data into
packetized element streams; re-multiplex the packetized element
streams into a captured content transport stream; and store the
captured content transport stream into a secondary cache to enable
playback, by a user, of the one or more content data files
represented by the captured content transport stream.
28. A system, comprising: a service provider broadcast server; and
one or more client systems coupled to the service provider
broadcast server, wherein the one or more client systems rate, in
response to a content rating table, one or more content data files
described by a composite content list, the content rating table
generated responsive to content data files previously accessed and
the composite content list including meta-data describing service
provider content available from a service provider system and
broadcast service content to be broadcast by a broadcast service
system, wherein the one or more client systems transmit, to the
service provider broadcast server, the ratings of the content data
files from the composite content list, wherein the service provider
system selects a portion of the content data files from the service
provider content and the broadcast service content in response to
the ratings received from the one or more client systems, wherein
the service provider system further broadcasts a broadcast schedule
for the selected portion of the broadcast service content to the
one or more client systems, prior to broadcast by the broadcast
service system, to enable the one or more client systems to store
one or more content data files from the selected portion of
broadcast service content, and wherein the service provider
broadcast server further broadcasts the selected portion of the
service provider content to the one or more client systems.
29. The system of claim 28: wherein each one of the one or more
client systems receive content data files from the selected portion
of the broadcast service content; and wherein the one or more
client systems store one or more of the content data files from the
selected portion of the broadcast service content in response to a
content rating table associated with each respective one of the one
or more client systems.
30. The system of claim 28: wherein each one of the one or more
client systems receive content data files from the selected portion
of the service provider content, and wherein the one or more client
systems store one or more of the content data files from the
selected portion of the service provider content in response to a
content rating table associated with each respective one of the one
or more client systems.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of co-pending U.S. patent
application Ser. No. 09/854,129, filed May 11, 2001.
FIELD
[0002] The present invention relates generally to broadcast
systems. In particular, the present invention relates to a method
and apparatus for combining broadcast schedules and content on a
digital broadcast-enabled client platform.
BACKGROUND
[0003] Broadcast systems traditionally transmit data in one
direction--from a server system to a plurality of client systems.
Users of the client systems typically consume the signals received
from the server system as they are broadcast. One paradigm in which
users are provided with content on demand involves server systems
that broadcast the same data continuously and/or at staggered
intervals. Thus, if a user desires to consume a particular data
file on demand, the user "tunes in" to one of the repeated
broadcasts of the data file.
[0004] One example of this paradigm can be illustrated with present
day "pay per view" movies that are available from cable or
satellite television providers. For instance, cable television
providers commonly broadcast the same movies repeatedly on multiple
channels at staggered intervals. Users that wish to watch a
particular movie, "on demand," simply tune in to one of the
channels on which the desired movie is broadcast prior to a
broadcast time of the movie. Unfortunately, these continuous and
repeated broadcasts of the same data or programs results in a very
inefficient use of broadcast bandwidth. Bandwidth used to broadcast
the same data repeatedly on multiple channels could otherwise be
used to broadcast different data.
[0005] Another paradigm for providing content on demand in a
broadcast system involves a user recording a particular data file
and later accessing the data file "on demand. For example, a user
can set up his or her video cassette recorder (VCR) to record a
desired television program. Later, when the user wishes to watch
the television program, "on demand," the user simply plays the
earlier recorded program from his or her VCR. Recently, more
advanced digital video recorders have become available, which
record television broadcasts on internal hard drives instead of the
video cassette tapes used by traditional VCRs. However, use of the
digital video recorders is similar to traditional VCRs in that the
users are required to explicitly set the criteria used (e.g. date,
time) to determine which broadcasts are recorded on the internal
hard drives.
[0006] Another limitation with present day broadcast systems is
that it is difficult for most users of the client systems to
provide feedback to broadcasters with regard to programming. As an
example, many of today's television broadcasters rely upon Neilson
ratings to determine broadcast programming and/or scheduling.
Neilson ratings are generally based upon only a small sampling of a
cross-section of the public. Consequently, most television viewers
have relatively little or no impact on broadcast schedules and/or
content. In fact, the pay-per view movies available are certainly
not based on user feedback. Furthermore, the user does not have a
choice as to when to view a pay-per view event, and therefore must
be available during the event broadcast date and time.
[0007] Therefore, there remains a need to overcome one or more of
the limitations in the above-described, existing art.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The present invention is illustrated by way of example and
not limitation in the accompanying figures.
[0009] FIG. 1 depicts a block diagram illustrating a broadcast
service system as known in the art.
[0010] FIG. 2A depicts a block diagram illustrating a service
provider broadcast system in accordance with one embodiment of the
present invention.
[0011] FIG. 2B depicts a block diagram illustrating a service
provider broadcast system in accordance with a further embodiment
of the present invention.
[0012] FIG. 3 depicts a block diagram illustrating a computer
system representative of a client or a server in accordance with an
embodiment of the present invention.
[0013] FIG. 4 depicts a block diagram illustrating a service
provider broadcast system in accordance with an exemplary
embodiment of the present invention.
[0014] FIG. 5 depicts a flow chart illustrating the flow of events
in a server and a client when combining broadcast schedules and
content on a digital broadcast-enabled client platform in
accordance with an embodiment of the present invention.
[0015] FIG. 6 depicts a flow diagram illustrating the flow of
events in a server when combining existing broadcast content with
cached content in order to generate an optimized broadcast schedule
to reduce broadcast bandwidth in accordance with an embodiment of
the present invention.
[0016] FIG. 7 is a flow diagram illustrating the flow of events
performed by a client for storing a selected portion of content
data files selected by the service provider broadcast system in
accordance with the further embodiment of the present
invention.
[0017] FIG. 8 is a flow diagram illustrating additional events
performed by a client when receiving a broadcast schedule in
accordance with a further embodiment of the present invention.
[0018] FIG. 9 depicts a flow diagram illustrating additional events
performed by a client when receiving a broadcast schedule for
overlapping content data files in accordance with the further
embodiment of the present invention.
[0019] FIG. 10 is a flow diagram illustrating additional events
performed by a client when a selected portion of content data files
are available from a server in accordance with a further embodiment
of the present invention.
[0020] FIG. 11 is a flow diagram illustrating additional events
performed by a client when receiving overlapping content data files
from a broadcast service system in accordance with a further
embodiment of the present invention.
[0021] FIG. 12 is a block diagram depicting the machine illustrated
in FIG. 3 configured as a set-top box to illustrate the logical
flow of data through an MPEG pipeline in accordance with an
embodiment of the present invention.
[0022] FIG. 13 depicts a flow diagram illustrating additional
events performed by a client when receiving a selected content data
file broadcast from a broadcast service system in accordance with
the further embodiment of the present invention.
[0023] FIG. 14 is a flow diagram illustrating additional events
performed by a client when receiving a selected content data file
from the service provider broadcast system in accordance with the
further embodiment of the present invention.
[0024] FIG. 15 depicts a flow diagram illustrating the flow of
events in a client when processing composite content meta-data
broadcast from a server to maintain a content meta-data table and
content rating table in accordance with one embodiment of the
present invention.
[0025] FIG. 16 is an illustration of one example of composite
content meta-data broadcast by a server in accordance with the
teachings of the present invention.
[0026] FIG. 17 is an illustration of one example of a content
meta-data table updated and maintained by a client in accordance
with the teachings of the present invention.
[0027] FIG. 18 is an illustration of one example of a content
rating table updated and maintained by a client in accordance with
the teachings of the present invention.
[0028] FIG. 19 depicts a diagram illustrating content data files
that are classified by a user in accordance with one embodiment of
the present invention.
[0029] FIG. 20 depicts a diagram illustrating a content meta-data
table that is updated in response to user classifications in
accordance with one embodiment of the present invention.
[0030] FIG. 21 is a diagram illustrating one embodiment of a
content meta-data table that is updated after a user access in
accordance with the teachings of the present invention.
[0031] FIG. 22 is a diagram illustrating one embodiment of a
content rating table that is updated, after a user access, in
accordance with the teachings of the present invention.
[0032] FIG. 23 is a diagram illustrating another embodiment of a
content meta-data table that is updated, after another user access,
in accordance with the teachings of the present invention.
DETAILED DESCRIPTION
[0033] An apparatus and method for combining broadcast schedules
and content on a digital broadcast-enabled client platform are
disclosed. In the following description, for the purposes of
explanation, numerous specific details are set forth in order to
provide a thorough understanding of the present invention. It will
be apparent, however, to one skilled in the art that the present
invention may be practiced without some of these specific details.
In addition, the following description provides examples, and the
accompanying drawings show various examples for the purposes of
illustration. However, these examples should not be construed in a
limiting sense as they are merely intended to provide examples of
the present invention rather than to provide an exhaustive list of
all possible implementations of the present invention. In other
instances, well-known structures and devices are shown in block
diagram form in order to avoid obscuring the details of the present
invention.
[0034] In an embodiment, the methods of the present invention are
embodied in machine-executable instructions. The instructions can
be used to cause a general-purpose or special-purpose processor
that is programmed with the instructions to perform the methods of
the present invention. Alternatively, the methods of the present
invention might be performed by specific hardware components that
contain hardwired logic for performing the methods, or by any
combination of programmed computer components and custom hardware
components.
[0035] The present invention may be provided as a computer program
product which may include a machine-readable medium having stored
thereon instructions which may be used to program a computer (or
other electronic devices) to perform a process according to the
present invention. The machine-readable medium may include, but is
not limited to, floppy diskettes, optical disks, Compact Disc,
Read-Only Memory (CD-ROMs), and magneto-optical disks, Read-Only
Memory (ROMs), Random Access Memory (RAMs), Erasable Programmable
Read-Only Memory (EPROMs), Electrically Erasable Programmable
Read-Only Memory (EEPROMs), magnetic or optical cards, flash
memory, or other type of media/machine-readable medium suitable for
storing electronic instructions. Moreover, the present invention
may also be downloaded as a computer program product. As such, the
program may be transferred from a remote computer (e.g., a server)
to a requesting computer (e.g., a client) by way of data signals
embodied in a carrier wave or other propagation medium via a
communication link (e.g., a modem or network connection).
System Architecture
[0036] FIG. 1 is an illustration of one embodiment of a
conventional broadcast service system 100, as known to those
skilled in the art. The broadcast service system 100 includes a
server 103 configured to broadcast information 101 to a plurality
of clients 105, 107 and 109. Client 105 receives a broadcast from
server 103 through a link 115 from a broadcast antenna 111.
Similarly, client 107 receives a broadcast from server 103 through
a link 117 and client 109 receives a broadcast from server 103
through a link 119 from broadcast antenna 111. Unfortunately, links
115, 117 and 119 are uni-directional wireless radio frequency (RF)
links from broadcast antenna 111. Consequently, the broadcast
service system 100 lacks the capability for enabling users of the
client systems to provide feedback to broadcasters with regard to
programming. Moreover, the broadcast service system 100 broadcasts
the same data 101 continuously and/or at staggered intervals.
Unfortunately, these continuous and repeated broadcasts of the same
data or programs 101 results in a very inefficient use of broadcast
bandwidth.
[0037] Referring now to FIG. 2A, a service provider broadcast
system 150 is depicted. The service provider broadcast system 150
is designed to work in conjunction with a standard broadcast
system, such as the broadcast service system 100, as depicted in
FIG. 1. As will be described in further detail below, the service
provider broadcast system enables companies or broadcast systems
who want to optimize pay-per view royalties or subscription fees to
combine their existing broadcast content with digital broadcast
cached content provided by a service provider broadcast system.
[0038] The service provider broadcast system 150 is configured to
broadcast information 151 to a plurality of clients 155, 157 and
159, for example, utilizing bandwidth provided by the broadcast
service system 100. As such, the service provider broadcast system
150 transmits the information 151 to the broadcast server 103. The
service provider information 151 along with the broadcast
information 101 is then broadcast, via antenna 111, to the
plurality of clients 155, 157 and 159. However, those skilled in
the art will appreciate that the broadcast of information, as
contemplated by the present invention, includes broadcast via
cable, satellite, broadcast antenna or the like, as described in
further detail below. Client 155 receives a broadcast from the
broadcast server 103 through a link 165 from a broadcast antenna
111. Similarly, client 157 receives a broadcast from the broadcast
server 103 through a link 167 and client 159 receives a broadcast
from broadcast server 103 through a link 169 from broadcast antenna
111. In this embodiment, links 165, 167 and 169 are uni-direction,
wireless radio frequency (RF links) from broadcast antenna 111. The
format of such broadcasts is, for example but not limited to, known
amplitude modification (AM) or frequency modification (FM) radio
signals, television (TV) signals, digital video broadcasts (DVB)
signals, or the like, which are broadcast through the
atmosphere.
[0039] The broadcast server 103 is configured to broadcast a
plurality of broadcast service content data files 101, which may be
received by clients 155, 157 and 159. In addition, the broadcast
server 103 allocates bandwidth to the service provider server 153
in order to broadcast a plurality of provider content data files
151, which are also received by clients 155, 157 and 159. The
content data files 101/151 may include, for example, any
combination of a number of different types of files including for
example video, audio, graphics, text, multi-media or the like. For
purposes of explanation, many of the examples provided in this
disclosure assume that the content data files to be broadcast by
the server are audio/video files, such as for example movies with
moving images and sound. However, it will be appreciated that the
content data files broadcast in accordance with the teachings of
the present invention are not limited only to audio/video
files.
[0040] As illustrated in FIG. 1, the broadcast service system 100
includes a one-way or uni-directional link between the server 103
and clients 105, 107 and 109. However, the service provider
broadcast system 150, as depicted in FIG. 2A, includes a "back
channel" or communications link between each of client 155, 157 and
159 and the service provider server 153. In particular, the service
provider broadcast system 150 shows links 161, 163 and 165, which
may be used by clients 155, 157 and 159, respectively, to send
information back to service provider server 153, such as providing
feedback to broadcasters regarding programming. Although links 161,
163 and 165 are illustrated as direct links between clients 155,
157 and 159 and service provider server 153, it is appreciated that
clients 155, 157 and 159 may communicate information to the service
provider server 153 through indirect links. Indirect links include,
for example, but are not limited to broadcasted wireless signals,
network communications or the like.
[0041] FIG. 2B is an illustration of a further embodiment of the
service provider broadcast system 170 in accordance with the
teachings of the present invention. As shown, the service provider
server 153 utilizes bandwidth provided by the broadcast server 103
to broadcast information 151 to a plurality of clients 155, 157 and
159 through a network 163. In one embodiment, network 163 may be
any type of communications network through which a plurality of
different devices may communicate such as for example but not
limited to the Internet, a wide area network (WAN), a local area
network (LAN), an Intranet, an Extranet or the like.
[0042] In the embodiment, client 155 receives information 101/151
broadcast from broadcast server 103 through link 165. Similarly,
client 157 receives information 101/151 broadcast from broadcast
server 103 through link 167 and client 159 receives information
101/151 broadcast from the broadcast server 153 through link 169.
It is noted that links 165, 167 and 169 are shown as
uni-directional links from network 163 to clients 155, 157 and 159,
in which a back channel, as depicted in FIG. 2A, may be used to
communicate information to the service provider server 153. In
another embodiment, links 165, 167 and 169 are bi-directional
links, which enable clients 155, 157 and 159 to communication
information to the service provider server 153.
[0043] FIG. 3 is a block diagram illustrating one embodiment of a
machine 201 that may be used for the service provider server 153,
or clients 153, 155 or 157 in accordance with the teachings of the
present invention. The machine 201 is, for example, a computer or a
set top box that includes a processor 203 coupled to a bus 207. The
machine 201 includes a memory 205, a storage 211, a display
controller 209, a communications interface 213, an input/output
controller 215 and an audio controller 227 are also coupled to bus
207.
[0044] In one embodiment, machine 201 interfaces to external
systems through communications interface 213. Communications
interface 213 may include, for example, a radio transceiver
compatible with AM, FM, TV, digital TV, DVB, wireless telephone
signals or the like. Communications interface 213 may also include,
for example, an analog modem, Integrated Services Digital Network
(ISDN) modem, cable modem, Digital Subscriber Line (DSL) modem, a
T-1 line interface, a T-3 line interface, an optical carrier
interface (e.g. OC-3), token ring interface, satellite transmission
interface, a wireless interface or other interfaces for coupling a
device to other devices.
[0045] A carrier wave signal 223 may be received by communications
interface 213 to communicate with antenna 111. In addition, a
carrier wave signal 225 may be received/transmitted between
communications interface 213 and network 113. The carrier wave
signal 225 may also be used to interface machine 201 with another
computer system, a network hub, router or the like. The carrier
wave signals 223 and 225 are, for example, considered to be machine
readable media, which may be transmitted through wires, cables,
optical fibers or through the atmosphere, or the like.
[0046] The processor 203 may be a conventional microprocessor, such
as, for example, but not limited to an Intel x86 or Pentium family
microprocessor, a Motorola family microprocessor, or the like.
Memory 205 may be a machine readable medium such as dynamic random
access memory (DRAM) and may include static random access memory
(SRAM). Display controller 209 controls, in a conventional manner,
a display 219, which may be a cathode ray tube (CRT), a liquid
crystal display (LCD), an active matrix display, a television
monitor or the like. The input/output device 217 coupled to
input/output controller 215 may be, for example, a keyboard, disk
drive, printer, scanner and other input and output devices,
including a television remote, mouse, trackball, trackpad,
joystick, or the like. In one embodiment, audio controller 227
controls in a conventional manner audio output 231, which may
include for example audio speakers, headphones, an audio receiver,
amplifier or the like. In addition, the audio controller may also
control, in a conventional manner, audio input 229, which may
include for example a microphone or input(s) from an audio or
musical device, or the like.
[0047] The storage 211 may, for example, include machine readable
media such as for example but not limited to a magnetic hard disk,
a floppy disk, an optical disk, a smart card or another form of
storage for data. Alternatively, the storage 211 may include, for
example, removable media, read-only media, readable/writable media
or the like. Some of the data may, for example, be written by a
direct memory access process into memory 205 during execution of
software in computer system 201. It is appreciated that software
may reside in storage 211, memory 205 or may be transmitted or
received via modem or communications interface 213. For the
purposes of the specification, the term "machine readable medium"
shall be taken to include any medium that is capable of storing
data, information or encoding a sequence of instructions for
execution by processor 203 to cause processor 203 to perform the
methodologies of the present invention. The term "machine readable
medium" shall be taken to include, but is not limited to
solid-state memories, optical and magnetic disks, carrier wave
signals, and the like.
[0048] Referring now to FIG. 4, one embodiment of a service
provider broadcast system 300, such as illustrated in FIGS. 2A and
2B, is depicted. In one embodiment, the service provider broadcast
system 300 is configured to have a service provider server 303
broadcast the provider content data files 151 to a plurality of
clients 305, 307 and 309 utilizing bandwidth provided by a
broadcast server 103. The service provider broadcast system 300
utilizes broadcast service content 101 broadcast by a broadcast
service system, such as the broadcast service system 100 depicted
in FIG. 1, in order to select the provider content data files 151
broadcast to the clients 305, 307 and 309.
[0049] As described above, the broadcast service system 100
generally broadcasts the same content continuously and/or at
staggered intervals to the system's clients, 105, 107 and 109 (FIG.
1). In one embodiment, the service provider broadcast system 300
utilizes network service information, which describes the content
the broadcast service system 100 will be broadcast over a
predetermined period to generate a composite broadcast schedule or
composite content meta-data set. In an alternative embodiment, the
client systems 305, 307 and 309 generate the composite broadcast
schedule utilizing the network service information for the
broadcast service system 100 and network service information for
the service provider system 300, which describes a plurality of
service provider content data files available from the service
provider system 300. The content meta-data describes the plurality
of service provider content data files available from the service
provider system 300 as well as the broadcast service content data
files 101.
[0050] In general, meta-data can be considered as a set of
descriptors or attribute values that describe content or data files
to be broadcast or potentially broadcast from servers 303 and 103.
In this embodiment, once the composite content meta-data set is
formed, the service provider broadcast system 300 broadcasts the
composite content meta-data set to clients 305, 307 and 309 and
receives feedback from the users of the client system regarding the
content data files described by the content meta-data. Using this
information, the service provider broadcast system 300 ranks the
service provider content data files and the broadcast service
content data files 101. Alternatively, the system 300 may rank the
data files based on box office returns, public opinion polls, movie
awards (e.g., the Academy Awards), user requests or the like. Once
ranked, the system 300 selects a portion of the content data files
having, for example, a higher ranking.
[0051] The selected portion of the service provider content forms
the content provider content data files 151 that the system 300
broadcasts to the clients 305, 307 and 309 via the broadcast server
103. The client systems 305, 307 and 309 will then store one or
more content data files from the provider content data files 151.
However, in order to direct the client system 305, 307 and 309 to
store one or more content data files from the selected portions of
the broadcast service content, the system 300 generates a selected
broadcast service content schedule. In an alternative embodiment,
the client system determines the selected broadcast service content
broadcast schedule based on network service information for the
broadcast service system 100 and network service information for
the content provider content data files 151. Procedural methods for
performing the teaching of the present invention are now
described.
Operation
[0052] FIG. 5 depicts a flow diagram illustrating the flow of
events performed in a server and a client of a service provider
broadcast system 300, for example, as depicted in FIG. 4, for
combining broadcast schedules and content on a digital
broadcast-enabled client platform. As known to those skilled in the
art, digital broadcast networks (whether satellite, cable or
terrestrial) make use of service information (SI) to announce the
availability of, and acquisition parameters, for content.
Typically, these announcements are consumed by a receiver's
electronic program guide (EPG), and are used to present and acquire
programming. In this environment, premium content (e.g.,
"Pay-Per-View", HBO, etc.) may be scattered across the spectrum
presented by the EPG. This problem is exacerbated by the
introduction of additional broadcasting services, such as cached
content service providers that also deal in the distribution of
(possibly overlapping) content that may or may not be directly
integrated into a broadcast service network's SI. Therefore, in
order to reduce the cognitive load placed on users, cached content
service providers can become aware of the broadcast service network
service information, preferably in a pre-processed (i.e., pre-EPG
state) in order to generate a composite content listing.
[0053] Consequently, at process block 401, a service provider
server 303 acquires network SI regarding broadcast service content
to be broadcast by a broadcast service system, for example, as
depicted in FIGS. 1 and 4, over a predetermined period of time. At
process block 403, a composite content list or composite content
meta-data set is created. The composite content meta-data set
includes meta-data describing service provider content available
from the service provider system 300 and the broadcast service
content to be broadcast by the broadcast service system 100.
[0054] In one embodiment, the creation of the composite content
list requires the exclusion of certain content data files that fall
into one or more predetermined categories. In certain embodiments,
the predetermined categories may include sports programs and
events, television programs, news or other repeating broadcasts.
However, the service provider broadcast system may include rating
an eventual broadcast of such programs. As such, non-excluded
programs are then tagged with additional SI attributes. Presumably,
these attributes will include a key that can be cross-referenced
with data available to the service provider broadcast system. As
such, the keys serve the dual purpose of identifying desirable
content while simultaneously facilitating the identification of
potentially duplicate content. As part of the creation of the
composite content list, all duplicate programs are identified and
flagged for future reference. In one embodiment, the predetermined
period of time during which network SI for the broadcast service
content is acquired is, for example, two weeks.
[0055] As referred to herein, a cached content service provider
describes a broadcast system wherein the system selects one or more
data files to broadcast to one or more client system based on
feedback generated by the client system in response to user access
of data files. Once the one or more data files are selected, the
data files are broadcast to the one or more client systems, which
selectively store the one or more of the data files based on
rankings of the data files contained in a content rating table. The
data files are stored by the client systems in order to enable
viewing at a later date and time by a user. This cached content
service is provided by the service provider broadcast system 300,
as depicted in FIG. 4.
[0056] However, the service provider broadcast system 300 can be
utilized to broadcast content in conjunction with the broadcast
service system 100 as depicted in FIGS. 1 and 4. Consequently,
content selected by the service provider broadcast system 300, for
example, in response to client rankings, is transmitted to one or
more client systems using bandwidth provided by the broadcast
service system 100. However, in order to best utilize bandwidth
provided by the broadcast service system 100, the service provider
broadcast system 300 generates a composite broadcast schedule or a
composite content meta-data set in order to receive rankings for
the service provider content data files, as well as the broadcast
service content data files 101. In an alternative embodiment, the
client systems 305, 307 and 309 generate the composite broadcast
schedule utilizing the network service information for the
broadcast service system 100 and network service information for
the service provider system 300, which describes the plurality of
service provider content data files available from the service
provider system 300.
[0057] By using the composite content meta-data set, the system 300
can receive rankings for both the service provider content data
files, as well as the broadcast service data files. Using the
rankings, the system 300 can select a portion of the content data
files, described by the composite content meta-data set, to form a
composite content schedule describing the selected portion of
content data files. Alternatively, the system 300 may rank the data
files based on box office returns, public opinion polls, movie
awards (e.g., the Academy Awards), user requests or the like.
However, the selected portion of content data files may contain
duplicate data files. As referred to herein, duplicate data files
are date files that are available from the service provider system
300 and that will also be by the broadcast service system 100 will
broadcast over the predetermined period of time. Consequently, the
service provider broadcast system 300 can determine whether to
broadcast these duplicate content data files using its own
bandwidth or await a future date and time for broadcast of the
duplicate content data files by the broadcast service system
100.
[0058] At process block 405, the service provider server 303 may
broadcast a composite content meta-data broadcast schedule to the
one or more clients. In one embodiment, the meta-data broadcast
schedule indicates some point in the future when the actual
meta-data is going to be broadcast by the server. Alternatively,
the client systems may use known ports such as, for example, those
used in the DVB, service advertising protocol (SAP) or the like, to
listen for upcoming service announcements from the server.
Otherwise, program and system information protocol (PSIP) tables
are acquired by decoding a stream (identified by a well-known PID)
that has been multiplexed into the MPEG-2 transport stream to
listen for upcoming service announcements from the server.
[0059] Otherwise, each client 305, 307 and 309 can contain a known
scheduling service, which accepts requests to wake up, or be
activated, at a specific time to receive the information broadcast
by the server. This scheduling service enables the client to wake
up at a specified time and select a specified service. For example,
in one embodiment, this selection process can be accomplished by
tuning to a specific frequency, such as for example in an Advanced
Television Systems Committee (ATSC) or a DVB transponder or the
like. The selection process can be based on a set of data, such as
for example multi-cast Internet protocol (IP) addresses, which
define a service.
[0060] At process block 407 client systems may receive the
composite content meta-data broadcast schedule from the service
provider server 303. In one embodiment, client systems 305, 307 and
309 capture and process this pre-broadcast information in order to
determine when to wake-up and receive content, where to receive the
content and which content to receive. Alternatively, when the
meta-data broadcast schedule is received by the client, a
registered application in the client is notified to receive the
meta-data broadcast schedule.
[0061] At process block 409 the composite content meta-data may be
broadcast from the server to the clients at the time specified in
the composite content meta-data broadcast schedule. At process
block 411, the client may receive the broadcast of content
meta-data from the server. At process block 413, the client system
may then update a content meta-data table and a content rating
table. In one embodiment, a meta-data table and a content rating
table are updated and maintained internally or locally by each
client system. In addition, a user of the client system may
optionally classify any one or more of the content data files that
are described by the received composite content meta-data. As will
be discussed, the content meta-data table and content rating table
are updated by the client if there are any user classifications.
This is shown in FIG. 5 with process block 415.
[0062] At process block 417, the client then sends the ratings of
the content data files to the server. In one embodiment, each
client in the broadcast network sends the ratings for all of the
content data files that are described by the composite content
meta-data broadcast earlier from the server. Alternatively, each
client sends all or part of the content rating table maintained on
the client system.
[0063] At process block 419, the server may receive the ratings of
the content data files from the client(s) 305, 307 and 309. At
process block 421, the server then selects a portion of the content
data files from the service provider content and broadcast service
content having, for example, the highest ratings as determined by
the client systems. Alternatively, the system 300 may rank the data
files based on box office returns, public opinion polls, movie
awards (e.g., the Academy Awards), user requests or the like. In
one embodiment, the server includes processing to aggregate all of
the ratings received from the clients. Consequently, the content
data files are sorted according to the aggregated ranking. As a
result, the server broadcasts the most appropriate or relevant data
files for the customer base or clients.
[0064] In one embodiment, the data files to broadcast, and/or the
broadcast schedule are determined dynamically by the server in
response to the ratings received from the client(s) in accordance
with teachings of the present invention. Therefore, in one
embodiment, broadcast schedules can change over time depending on
which data files are available from the server and which content or
data files are accessed and/or classified by the clients.
[0065] At process block 423 the service provider broadcast system
300 generates a broadcast schedule for content data files contained
within the selected portion of broadcast service content, which
will not be broadcast by the service provider broadcast system 300
as the provider content data files 151. A selected broadcast
service content broadcast schedule is then broadcast to the one or
more client systems as shown in block 423. Process block 425 shows
that the client systems then receive the broadcast service
broadcast schedule from the server.
[0066] In one embodiment, the clients wake-up to receive the
selected broadcast service content broadcast schedule from the
server. The broadcast schedule indicates, for example, a future
time in which selected content data files will be broadcast by the
broadcast service system 100. At process block 427, the content
data files from the selected portion of the broadcast service
content are then broadcast from the broadcast service system 100 to
the clients at the time specified in the broadcast schedule.
Process block 429 shows that the client receives the broadcast of
contents data file broadcast from the broadcast service system 100.
In one embodiment, process block 431 shows that client-side
filtering is provided by the client selectively storing content
data files according to the content rating table as the content
data files are broadcast over the predetermined period. In another
embodiment, client-side filtering is provided by the client
selectively waking up to selectively receive and store content data
files broadcast from the broadcast service system according to the
content rating table.
[0067] Process block 433 shows that the client then updates the
content meta-data table and content rating table if there are any
user accesses of the stored data files. As described herein, a user
access may include a user interacting with, viewing, watching,
listening to, reading, consuming, etc., a data file. For instance,
one example of a user accessing a data file may be the user
watching a particular movie or listening to a particular song
provided by one of the stored data files in client. In one
embodiment, a user access will result in the meta-data table and
content rating table on the client being updated locally.
[0068] FIG. 6 depicts a more detailed flow chart illustrating the
selection of the plurality of provider content data files 151 that
are broadcast to one or more client systems by the service provider
broadcast system, for example, as depicted in FIG. 4. At process
block 501, the service provider server 303 selects a portion of the
service provider content data files and the broadcast service
content data files 101 having higher rankings based on the rankings
received from the one or more client systems (selected
provider/broadcast content). However, duplicate content data files
within both the selected portion of service provider content and
broadcast service content should not be broadcast by both the
broadcast service provider system 300 as well as the broadcast
service system 100.
[0069] Consequently, at process block 503, it is determined whether
a selected content data file is contained in the selected portion
of the broadcast service content. If the selected content data file
is contained within the selectively selected portion of broadcast
service content, at process block 505 it is determined whether the
selected data file is also contained within the selected portion of
service provider broadcast content. If the selected content data
file is not contained within the service provider content, at step
509 the selected content data file is added to a set of overlapping
content data files.
[0070] Otherwise, at step 507, it is determined whether the
selected content data file should be broadcast using service
provider bandwidth. (Broadcast by the service provider broadcast
system 300). If the selected content data file will be broadcast
with the service provider bandwidth, at process block 511, the
selected content data file is added to a set of provider content
data files 151. At process block 513, steps 503 through 511 are
repeated for each content data file within the selected portion of
service provider content and broadcast service content. As such,
steps 503 through 513 allow the service provider system to
determine whether duplicate or overlapping files should be
broadcast using service provider bandwidth or broadcast service
system bandwidth (broadcast by the broadcast service system
100).
[0071] At process block 515, the service provider broadcast server
300 broadcasts an optimum/provider broadcast schedule prior to
broadcast of the provider data files 151. The provider data files
151 will each be broadcast to the one or more client systems as a
group in order to enable storage of the provider data files 151
based, for example, on client system content rating tables.
However, the overlapping data files may be broadcast at various
times, depending on the broadcast service system 100 broadcast
schedule. Accordingly, at process block 517, the service provider
server 303 broadcasts a selected broadcast service content
broadcast schedule for the overlapping data files prior to
broadcast by the broadcast service system 100. Consequently,
utilizing the selected broadcast service content broadcast
schedule, the one or more client systems can determine whether to
store a data file contained within the overlapping data files, once
it is available, based on a stored content rating table. In an
alternative embodiment, the client system determines the selected
broadcast service content schedule based on network service
information for the broadcast service system 100 and network
service information for the content provider content data files
151.
[0072] At step 519, the service provider server 303 broadcasts the
provider content data files 151 to the client systems utilizing
service provider bandwidth. For example, in an embodiment of the
present invention, the service provider broadcast system utilizes
bandwidth provided by the broadcast service system 100 in order to
broadcast content data files to the one or more client systems via
antenna 111. However, the service provider broadcast system 300 may
broadcast content data files either via antenna 311 or via network
313. At process block 521, the broadcast service server 103
broadcasts content data files from the overlapping content data
files to the one or more client systems. As described above,
content data files within the overlapping data files will not be
sent as a group. These data files are broadcast at the times
scheduled by the broadcast service system 100.
[0073] Utilizing a service provider broadcast system in accordance
with the teachings of the present invention content available from
the broadcast service system 100 may be combined with cached
content provided by the service provider broadcast system 300.
Consequently, at process block 523, the service provider broadcast
system 300 receives compensation for each stored data file accessed
by a user. At process block 525, it is determined whether the data
file accessed by the user was broadcast to the user using service
provider broadcast system bandwidth or broadcast service system
bandwidth. When service provider bandwidth is used, at process
block 527, the service provider broadcast system 300 receives a
larger portion of the compensation, while at process block 529, the
broadcast service system 100 receives a smaller compensation
portion. Alternatively, when broadcast service system bandwidth is
used to broadcast a data file, the broadcast service system 100
receives a larger portion of the compensation at process block 525,
while at process block 531, the service provider broadcast system
300 receives a smaller compensation portion.
[0074] Referring now to FIG. 7, FIG. 7 is a flow diagram
illustrating events performed by a client system for selectively
storing received content data files. At process block 601, it is
determined whether a client system received a broadcast schedule
for the plurality of provider data files 151 selected by the
service provider broadcast system 300. At process block 602, once
the broadcast schedule is received, the client system stores the
broadcast schedule for the plurality of provider content data files
151 (FIG. 8). At process block 605, it is determined whether a
broadcast schedule for the overlapping content data files was
received from the service provider system 300.
[0075] At process block 607, the client system stores a selected
broadcast service content broadcast schedule for the overlapping
content data files (FIG. 9). At process block 609, it is determined
whether the provider content data files 151 are available. At
process block 611, the client selects one or more content data
files from the provider data files 151 based on a content rating
table (FIG. 10). Generally, the provider content data files
selected by the service provider system 300 will include content
data files which received an overall popularity rating from the one
or more client systems. However, each user of the client system
will be different and will generally select a subset of the content
data files within the provider content data files 151. Once
selected, at process block 613, the client stores the one or more
selected content data files for future viewing by a user (FIG.
10).
[0076] At process block 621, it is determined whether content data
files from the overlapping data files are available. At process
block 623, it is determined whether a content data file, available
from the overlapping data files, is desired by the client system
based on the content rating table (FIG. 11). As described above,
content data files contained within the overlapping content data
files may have various broadcast dates and times. Consequently, the
client systems will utilize the broadcast schedules to, for
example, activate during the availability date and time of the
content data file, assuming the content data file is desired by the
client system. At process block 625, the client system captures the
content data file from the broadcast service broadcast of the
broadcast data files 101 (FIG. 11). At process block 627, the
client system stores the content data files for future viewing by a
user (FIG. 11).
[0077] Referring now to FIG. 12, the machine 201, as depicted in
FIG. 3, is illustrated in a set-top box configuration. This partial
block diagram of the machine 201 depicts the display controller 209
and the display 219 to illustrate the logical flow of data through
an MPEG (Motion Picture Experts Group) pipeline within the display
controller 209. The illustration depicted in FIG. 12 is provided to
demonstrate the capture of selected content data files broadcast by
both the service provider broadcast system 300 as well as selected
content data files broadcast by the broadcast service system
100.
[0078] MPEG-2 defines a standard for coding interlaced images at
transmission rates above four million bits per second. As known to
those skilled in the art, MPEG-2 is generally used for digital TV
broadcast and digital versatile disk. The MPEG-2 standard specifies
an MPEG transport stream which is a time division multiplexed set
of element streams. Generally, content is received by the display
controller 209 and is demodulated by the demodulation block 231 to
determine the original content transport stream. Once demodulated,
the content is demultiplexed by demultiplex block 233 to extract
the desired element streams. Next, the element streams area decoded
at decode block 235 and displayed via display 219.
[0079] Generally, the content is decoded into MPEG-2 to streams and
displayed on the display device. In addition, stored content data
files contained in block 237 may be viewed by a user by being
passed to the decode block 235 and displayed on the display 219.
Likewise, conditional access (CA) block 239 is utilized in order to
provide encryption keys for decoding protected content prior to
display on display device 219, for example, to enable pay-per-view
viewing of certain content. Unfortunately, depending on the content
capture capabilities provided by the various set-top box of the
client's systems, the capture of the selected broadcast content
will vary depending on the client set-top boxes 201.
[0080] FIG. 13 is a flow diagram illustrating the flow of events
630 in a client set-top box when capturing selected broadcast
content broadcast by the broadcast service system 100. At process
block 631, client software will siphon MPEG data representing the
selected content data file from a decode stage 235 of an MPEG
content transport stream. At process block 633, client software
stores the elementary streams and attendant data from the siphoned
MPEG data. At process block 635, client software encodes the stored
content streams and data into, for example, packetized element
streams. The encoding will generally include service information
and file storage information to enable content play-back. Finally,
at process block 637, the client software stores the packetized
element streams into a secondary cache to enable playback by a user
of the client system. In an alternative embodiment, the packetized
element streams are re-multiplexed into a new MPEG-2 transport
stream which is stored in the secondary cache. Consequently, when
presenting stored movies to the user, the secondary cache is
logically merged with a primary cache to create the illusion of a
single unified selection of movies. Upon user selection, the
indicated content is retrieved from its specific respective cache
and channeled through the platforms MPEG decode pipeline for
display via display 219.
[0081] FIG. 14 is a flow diagram illustrating the flow of events
640 performed by client software in order to store selected content
data files that are captured utilizing content capture capabilities
provided by the client system. The content capture capability
includes, for example, PVR functionality. At process block 641,
content data files are captured using content capture functionality
of the client platform. At process block 643, client software
encodes the captured content data file into a packetized element
stream. At process block 645, the client software stores the
packetized element stream into a secondary cache to enable playback
by a user. The encoding procedure described in FIGS. 13 and 14 is
required to wrap the resulting or captured streams into a client
compatible packaging in order to enable playback of the selected
content data files. However, for selected content data files
broadcast by the service provider broadcast system 300, the content
data files will already be encoded into compatible packaging which
is recognized by the client software.
[0082] FIG. 15 is a more detailed flow diagram illustrating one
embodiment of the flow of events 650 in a client when processing
meta-data broadcasted from a server to update and maintain a
meta-data table and a content rating table. In particular, process
block 653 shows that a content meta-data table is updated with
attributes and attribute values included in the content meta-data
broadcast from the server. Process block 605 shows that the content
rating table is then updated with an entry for each one of the
content data files described by the content meta-data broadcast
from the server.
[0083] To help illustrate the meta-data aspect of the present
invention, FIGS. 16-23 illustrate meta-data and content rating
tables in accordance with the teachings of the present invention.
FIG. 16 is an example of one embodiment of content meta-data 700,
which may be broadcast by the broadcast server 103 to the clients
305, 307 and 309. For explanation purposes, it is assumed that the
data files broadcast by the broadcast server 103 in this example
are audio/video files such as, for example, movies or TV
programming. As mentioned above, data files may be other types of
files such as for example but not limited to audio, graphics, text,
multi-media or the like.
[0084] In the illustrated embodiment, meta-data 700 in FIG. 16
shows that four movies, or data files, will be broadcast later by
server 103. These movies shown in this example are "Action Dude,"
"The Funny Show," "Blast 'Em" and "Hardy Har Har." Meta-data 700
includes attributes and attribute values that describe each one of
the movies to be broadcast later by server 103. In the example
illustrated, two attributes are provided to describe each movie in
meta-data 700. The attributes shown in FIG. 16 are "Actor" and
"Genre." It is appreciated that other embodiments of the present
invention may include different attributes as well as or attributes
values. Referring back to the particular example shown in FIG. 16,
"Action Dude" is an "action" movie featuring actor "Joe Smith."
"The Funny Show" is "comedy" movie featuring actress "Jane Doe."
"Blast 'Em" is an "action" movie featuring actor "Jane Doe." "Hardy
Har Har" is a "comedy" movie featuring "Joe Smith."
[0085] FIG. 17 is an example of one embodiment of meta-data table
800, which is updated and maintained locally by each client 305,
307 and 309. In the illustrated embodiment, meta-data table 800 in
FIG. 17 has been populated with the data included in meta-data 700,
which was broadcasted earlier from server 103. In one embodiment,
meta-data table 800 includes a list of attributes, attribute values
and corresponding relevance values and believability factors. In
particular, meta-data table 800 includes attribute values "Joe
Smith," "Jane Doe," "action," and "comedy." At this time, the
relevance values and believability factors for attribute values
"Joe Smith," "Jane Doe," "action," and "comedy" are all zero in
FIG. 17. As will be shown, in one embodiment, the relevance values
and believability factors of the present invention will be updated
and maintained as the user interacts with the client system.
[0086] In one embodiment, the relevance values in meta-data table
800 are indicators as to how relevant the associated attribute and
attribute values are for predicting a particular user's behavior.
For instance, the relevance value indicates how likely it is for
the user to watch a particular movie because of this particular
attribute value, within a range of values such as for example from
-10 to 10. In one embodiment, the believability factors in
meta-data table 800 are weighting factors to be applied to specific
attribute and attribute value pairs when rating or predicting
whether a user will actually access a particular data file having
that particular attribute value. In one embodiment, believability
factors in meta-data table 800 are within a range of values such as
for example from -10 to 10.
[0087] FIG. 18 is an example of one embodiment of a content rating
table 900, which is updated and maintained locally by each client
305, 307 and 309. In the illustrated embodiment, content rating
table 900 in FIG. 18 includes a list of the data files described in
meta-data 700 as well as any additional data files that are
currently stored or cached locally by the client.
[0088] In one embodiment, data files may be stored locally by the
client in for example memory 205, storage 211 or in a locally
accessible network by machine 201 of FIG. 3. For purposes of this
disclosure, data files being stored locally by the client may also
be interpreted to include a data file stored "locally" by the
client in a known network storage configuration, separate from the
server. For purposes of this disclosure, the data file being stored
or cached locally by the client is to be interpreted as the data
file being stored for later access, retrieval or consumption. In
one embodiment, the local cache of the present invention is
considered to be a first level cache. Thus, the local cache the
present invention is sized accordingly to increase the possibility
of a single hit.
[0089] Assuming an audio/video data file, a movie is stored locally
by the client. After a user watches the movie, the storage space
occupied by the movie is generally considered to be available for
storage of another movie to be broadcast sometime later. If a user
has not watched a particular movie, the storage space occupied by
that movie is generally considered not to be available for storage
of another movie. However, if there is no additional storage space
available and a higher rated movie is to be broadcast, the lower
rated unwatched movie may be replaced by the higher rated movie. In
an alternative embodiment, a user of the client may retain selected
stored content data files.
[0090] Referring back to the embodiment of content rating table 900
shown FIG. 18, each movie also has an associated rating, a rating
type indicator, an in cache indicator and a next treatment
indicator. In one embodiment, the rating indicates a rating value
for the associated data file. The rating value in one embodiment
may either be explicitly input by a user or implicitly generated by
the client system by processing meta-data associated with that
particular data file. For example, a relatively high rating value
predicts that the particular data file may be of interest to the
user. Conversely, a relatively low rating value predicts that the
particular data file is unlikely to be of interest to the user.
[0091] In one embodiment, the in cache indicator indicates whether
that particular data file is currently stored or cached locally by
the client. In the embodiment illustrated in FIG. 18, the movies
"Action Dude," "The Funny Show" and "Blast 'Em" already exist in
the local storage of the client system. Conversely, the movie
"Hardy Har Har" has not been stored in the local storage of the
client system in the example illustrated in FIG. 18.
[0092] In one embodiment, the next treatment indicator is used to
track future actions to be taken for the particular data file. For
example, if a movie has already been watched by the user, the next
treatment indicator would indicate "replace" to indicate that the
storage space occupied by that particular movie is available for
storage of another movie. However, if the movie has not yet been
watched by the user, the next treatment indicator would indicate
"keep." In addition, if the movie has not been stored locally by
the client and if the rating value predicts that this particular
movie may be of interest to the user, the next treatment indicator
would indicate "capture." While if the movie has not yet been
broadcast by the server and the rating predicts that this movie is
unlikely to be of interest to the user, the next treatment
indicator would indicate "ignore."
[0093] Referring again to FIG. 15, decision block 657 shows that it
is then determined whether there is a user classification of any of
the data files. Referring briefly to FIG. 16, a user classifies
some of the movies, as described by meta-data 700. In particular,
the user has expressed interest in the movie "Action Dude" by
indicating that he or she wishes to receive that movie. In
addition, the user has expressed that he or she does not have any
interest in the movie "The Funny Show" by indicating that he or she
refuses that movie. However, the user has not provided any
information or classification regarding any of the remaining
movies.
[0094] Referring back to FIG. 15, if the user has classified any of
the data files, process block 659 shows that the relevance values
of the particular attributes of the classified data files are
updated in meta-data table 800. Process block 661 shows that the
ratings of data files having attribute values with relevance values
that were adjusted in response to the user classification(s) are
also adjusted. For example, referring to meta-data table 800 in
FIG. 20, the relevance values for attribute values "Joe Smith" and
"action" are adjusted to reflect that the user explicitly expressed
an interest in "Action Dude." However, if the user has not
classified any data files, process blocks 409 and 411 are
skipped.
[0095] Referring again to FIG. 15, if the user accesses any of the
data files, as determined in decision block 663, process block 665
shows that the relevance values and the believability factors of
the particular attributes of the user accessed data files are
updated in meta-data table 800. Process block 417 shows that the
ratings of data files having attribute values with relevance values
that were adjusted in response to the user access are also
adjusted. In one embodiment, each time a user accesses or interacts
with particular data file, the believability factor of the
attribute values of that film are adjusted or updated. For example,
FIG. 21 shows a meta-data table 800 that is updated or adjusted in
response to the user access of "Action Dude." In this example, the
believability factors of "Joe Smith" and "action" are increased
since the relevance values for these attribute values were greater
than zero. If the user has not accessed any data files, process
blocks 415 and 417 are skipped.
[0096] FIG. 22 shows content rating table 900, which is updated in
response to the user access of "Action Dude," as described in
process block 667. As mentioned earlier, content rating table 900
is also updated as described in process block 661. As shown in
content rating table 900 of FIG. 22, "Action Dude" has a rating
value of 1. The rating type of "Action Dude" is "explicit" because
the user explicitly classified "Action Dude," as described above in
connection with FIG. 19. The in cache indicator indicates that
"Action Dude" is presently locally stored by the client system. The
next treatment indicator indicates replace because the user has
already watched "Action Dude."
[0097] As shown in meta-data table 800 of FIG. 23, the relevance
values and believability factors are updated for the attribute
values of unclassified data files that are accessed. For instance,
assume that the user now watches the movie "Blast "Em," which the
user did not classify. Recall from FIG. 16 that the movie "Blast
'Em" features "Jane Doe" and is an "action" movie. As shown in FIG.
21, the relevance value of "Jane Doe" was less than zero, or -1,
prior to the user watching "Blast 'Em." Nevertheless, the user
watched "Blast 'Em," despite the fact that it featured actress
"Jane Doe." Accordingly, the believability factor of the "Jane Doe"
attribute the value is adjusted downward since this particular
attribute value now appears less likely or relevant when predicting
a user's viewing habits. However, the relevance value and
believability factor for the attribute value "action" are adjusted
upwards since "action" had a relevance value of greater than zero
prior to the user watching "Blast 'Em." Thus, in this example, the
relevance value is adjusted upwards from 1 to 2 and the
believability factor is also adjusted upwards from 1 to 2.
Therefore, the content rating table 800 of FIG. 23 now predicts
that "action" movies are movies that the user is more likely to
watch.
[0098] It is appreciated that the user is not required to classify
data files explicitly in order for the meta-data table 800 and
content rating table 900 to be updated in accordance with the
teachings of the present invention. As a result, the content rating
table over time will more accurately predict data files in which
the user is interested.
[0099] In one embodiment, the data files in which the user is
predicted implicitly to be most interested as well as the data
files in which the user explicitly classified an interest will be
the data files that are cache locally on the client system. In
effect, the movies that the user is most likely to want to watch
are automatically stored locally, and therefore available "on
demand," without the user having to explicitly request these movies
in advance or explicitly specify criteria used to identify the
movies.
Alternate Embodiments
[0100] Several aspects of one implementation of a service provider
broadcast system for combining existing broadcast content with
cached content have been described. However, various
implementations of the service provider broadcast system provide
numerous features including, complementing, supplementing, and/or
replacing the features described above. Features can be implemented
as part of the server or as part of the user's computer system in
different implementations. In addition, the foregoing description,
for purposes of explanation, used specific nomenclature to provide
a thorough understanding of the invention. However, it will be
apparent to one skilled in the art that the specific details are
not required in order to practice the invention.
[0101] In addition, although an embodiment described herein is
directed to a video broadcast, it will be appreciated by those
skilled in the art that the teaching of the present invention can
be applied to other systems. In fact, systems for broadcasting
audio, graphics, text, multi-media files or the like are within the
teachings of the present invention, without departing from the
scope and spirit of the present invention. The embodiments
described above were chosen and described in order to best explain
the principles of the invention and its practical applications.
These embodiments were chosen to thereby enable others skilled in
the art to best utilize the invention and various embodiments with
various modifications as are suited to the particular use
contemplated.
[0102] It is to be understood that even though numerous
characteristics and advantages of various embodiments of the
present invention have been set forth in the foregoing description,
together with details of the structure and function of various
embodiment of the invention, this disclosure is illustrative only.
In some cases, certain subassemblies are only described in detail
with one such embodiment. Nevertheless, it is recognized and
intended that such subassemblies may be used in other embodiments
of the invention. Changes may be made in detail, especially matters
of structure and management of parts within the principles of the
present invention to the full extent indicated by the broad general
meaning of the terms in which the appended claims are expressed.
For example, the particular element may vary depending on the
particular application for the data file format while maintaining
substantially the same functionality without departing from the
scope and spirit of the present invention.
[0103] The present invention provides many advantages over known
techniques. The present invention increases the breadth of offering
provided by a service provider system by enabling scenarios such as
access to content that the service provider system would not
ordinarily have broadcast rights to. This provides the user with
access to programming for multiple services, thereby increasing
their overall satisfaction with the service. In addition, the
present invention reduces the user's cognitive load by providing a
single personalized list of selections from the various services
residing on the box. The user need only learn one interface to
access content and is not required to visit more than one location
for essentially the same service. Finally, the system allows for
optimization of bandwidth by enabling the service provider to
factor content already slated for broadcast (albeit via a different
channel) to a client out of its scale. This means that the service
provider will not have to pay for rebroadcasting content that would
already be sent to a client in a timely fashion, but rather
concentrate on providing a unique offering to the consumer.
[0104] Having disclosed exemplary embodiments and the best mode,
modifications and variations may be made to the disclosed
embodiments while remaining within the scope of the invention as
defined by the following claims.
* * * * *