Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02321462 2000-09-29
DIGITAL INTERACTIVE DELIVERY SYSTEM FOR
TVIMULTIMEDIAIINTERNET WITH ON-DEMAND APPLICATIONS
Technical Field
This invention relates generally to a system for the delivery of IP-configured
digital multimedia (e.g. television) signals to a subscriber (consumer) using
multicast
transmissions over a broadband network and, more particularly, to a system for
interactive on-demand delivery of multimedia providing, inter alia, a Virtual
Digital
1 o Video Recorder functionality.
Background
With the proliferation of TV broadcast providers delivering regular
programming
as well as specialty services, such as pay per view and first run movies, TV
viewers
are frequently faced with scheduling problems in order to view their favorite
programs.
The scheduling problem is even more severe in a typical household having one
television with several potential viewers each having their own viewing
preferences.
The known video cassette and digital video recorders (VCRs and DVRs) which
attach
to televisions enable consumers to record a television program on a current or
2 o scheduled basis but they do not permit one to record two programs
simultaneously
and, further, have associated with them many inconveniences such as the need
to
have a usable recording medium (i.e. tape or disc) at hand at the time one
wishes to
record a program and considerable operational time and know-how with respect
to
use of the hardware which has become more complex with the addition of pre-
2 s programming features which utilize program codes.
TV broadcasts are currently delivered through service providers such as cable
companies, and satellite operators and, of course, direct broadcast reception
via
traditional antennas and rabbit ears. Conventional cable service requires the
3 o installation of a dedicated cable to the subscriber's residence. Satellite
broadcast
service requires that the user have a satellite dish located on or somewhere
close to
1
CA 02321462 2000-09-29
their residence. Antennas and rabbit ears are generally limited to the
reception of
local programming. Additionally, program delivery via all of these services is
at the
convenience of the service provider or broadcaster and, hence, the user or
subscriber
must arrange his or her schedule to coincide with program availability.
It is well known that the purchase of personal computers by homeowners has
increased dramatically in recent years. Previously, these computers were used
primarily for word processing, accounting and other record keeping purposes
and also
for Web surfing and email using modems and conventional telephone service for
to connecting to the Internet. Frequently, however, these modems have a low
baud rate
making the transfer of data, particularly graphics, unacceptably slow. More
recently,
however, with the development of Digital Subscriber Line (DSL) technologies
such as
ADSL an expanded scope of broadband capacity exists for the copper wire
(twisted
pairs) at the user-end of the telecommunications network and this capacity may
be
used to provide enriched communications services to consumers including
multimedia
such as television and video.
With the increased availability of broadband backbone and delivery networks,
and increased usage of PCs by consumers, an increasing demand is evolving for
on-
e o demand multimedia services which enable consumers to plan their
entertainment to
their own schedule and interests rather than tailor their entertainment
viewing habits to
a service provider's broadcast schedule. Moreover, there is a need to overcome
the
inherent limitations presented by the usual home installations of VCRs and
DVRs
connected to television sets. The fixed hardware of such machines is
inherently time-
limited and any upgrades or design changes to implement new services must be
done
physically either by installing new hardware/software packages in the machine
or,
more likely, by buying a new machine to replace an outdated one (causing much
expense to the consumer). Further, from the perspective of consumers, using
VCR
and DVR machines to record and view broadcast multimedia is undesirably
machine-
3 0 limited in that one mush have a separate VCR/DVR machine connected to its
own
2
CA 02321462 2000-09-29
television in order for two persons in a household to watch different recorded
programs. Further, from the perspective of multimedia content providers, home
usage
of VCR/DVR machines to record proprietary multimedia content undesirably
renders
that content fully in the hands of the consumer (i.e. in the form of a video
tape or disk
s on which a program is stored) and, thus, beyond the control of the
multimedia content
provider whose interests are best served in an environment providing digital
rights
management.
Summar~.r of the Invention
to In accordance with the invention there is provided an on-demand multimedia
delivery system and method for use in an integrated multimedia broadcast
delivery
system extending from a broadcast provider to a subscriber. The broadcast
delivery
system comprises means for providing multimedia signals configured according
to IP
(Internet Protocol) format for multicast transmission over a broad band
network and a
15 system manager for providing interactive access to the multimedia signals
by the
subscriber through conversion means, being either a decoder in a set top box
and a
television or a decoder in a computer and a computer monitor, configured for
converting the IP multicast format signal into a format for display on the
television or
monitor. The on-demand delivery system comprises central multimedia storage
2 o means located within the broadcast delivery system and remote from the
subscriber
for storing multimedia content. An on-demand component is configured for
receiving a
deliver request from a subscriber for the stored content, for locating the
requested
multimedia content from the storage means and for delivering the requested
multimedia content to the conversion means for display on the television or
monitor.
2 s The multimedia content is stored in the storage means in a format
configured for
locating same in response to the deliver request.
An interactive program guide (IPG) is preferably provided to the subscriber by
the system manager of the broadcast delivery system for said access and the
3 o multimedia signals are transmitted through the network according to
scheduling
3
CA 02321462 2000-09-29
corresponding to the interactive program guide. The on-demand component is
further
configured for receiving a record request from a subscriber and for storing
the
multimedia content from the signals in response to the record request. The
record
request includes broadcast channel and time information identifying the
multimedia
s content and may be made from the interactive program guide. The multimedia
content may correspond to one or multiple broadcast programs. The record
request
may be received any time up to the end of transmission of the signal
corresponding to
the program.
1 o Brief Description of the Drawings
The present invention will now be described in greater detail with reference
to
the following drawings in which like reference numerals refer to like elements
throughout.
Figure 1 is a block diagram of a preferred multimedia broadcast delivery
system
15 in accordance with the invention (hereinafter referred to as the "delivery
system");
Figure 2 is a further block diagram of the delivery system;
Figure 3 is a schematic block diagram of the elements of the delivery system
and the operational components of the system manager component 40 (hereinafter
referred to as the "system manager");
2 o Figure 4 is a schematic operational diagram of the delivery system and
system
manager;
Figure 5 is a schematic diagram illustrating a layered relationship of the
components of the delivery system and system manager;
Figure 6 is an exemplary interactive program guide (IPG) generated by the
2 s system manager for display by a television through a set-top box;
Figure 7 is another exemplary interactive program guide (IPG) generated by the
system manager for display by a personal computer (PC);
Figure 8 is an exemplary player window and virtual remote control generated by
the system manager for display by a personal computer (PC);
3 o Figure 9 is an exemplary virtual remote controller, showing the basic
functions
4
CA 02321462 2000-09-29
available, as generated by the system manager for display by a personal
computer
(PC);
Figure 10 is the virtual remote controller of Figure 10 but showing the
"options"
box selected and the various available optional functions displayed; and,
Figure 11 illustrates a system for concurrent transmission of MPEG-1 and
MPEG-2 encoded signals;
Figure 12 shows three exemplary interactive television or computer display
windows (GUIs) generated by the virtual DVR on-demand application of the
present
invention by which the user may instruct the recording of a designated program
to selected from an IPG (a), a program display (b) or a main menu (c);
Figure 13 is an exemplary interactive television or computer display window
(GUI) screen generated by the virtual DVR on-demand application of the present
invention by which the user may instruct the recording of a designated program
by
selecting a channel, day and time;
Figure 14 is an exemplary interactive television or computer display window
(GUI) generated by the virtual DVR on-demand application showing a sample Play
List of a current program recordings which may be played;
Figure 15 is an exemplary interactive television or computer display window
(GUI) screen generated by the virtual DVR on-demand application of the
invention
2 o showing the program information for a program selected for recording and
providing
recording options;
Figure 16 is another exemplary interactive television or computer display
window (GUI) screen generated by the virtual DVR on-demand application of the
invention showing the program information for a program which has been
selected for
recording and providing play and delete options for that recording;
Figure 17 is an architectural schematic diagram of the Virtual DVR system
described herein; and,
Figure 18 is a schematic model diagram illustrating the Administration and
Operations aspects of the Virtual DVR system described herein.
5
CA 02321462 2000-09-29
Detailed Description of a Preferred Embodiment
Figure 1 is a high-level block diagram of the basic elements of an exemplary
multimedia delivery system as contemplated herein; for the convenience of the
reader
a glossary of several terms used herein, setting out their well-known meaning
in the
s communications art, is provided herein as Appendix A.
At the head-end 24 of the system a video source 12 retrieves multimedia/
television/Internet signals for broadcast from various sources such as
satellites in the
form of MPEG-compliant, Multi-Program Transport Streams (MPTS) and these
signals
to are delivered to (analog-to-digital) video encoders 14 or (digital-to-
digital) transcoders
130 where they are converted to one or more IP Multicast Single-Program
Transport
Streams (SPTS). The encoder 14 encodes analog video and audio inputs. The
transcoder 130 decodes digital video and audio signals, perhaps high-speed
MPEG
video SPTS or MPTS, and re-encodes them into a format which is suitable for
the
15 subscriber device being STB 22 or PC 30. Each IP multicast SPTS is a
packetized
MPEG stream which is subsequently sent out over a broadcast provider network
16
to a Digital Subscriber Line Access Multiplexer (DSLAM 18) 18 which might be
located
in a telephone company central office. The DSLAM 18 serves two purposes:
firstly, it
connects broadband lines in the transport network to xDSL lines in the access
network
2 o and, secondly, it separates high-speed data from voice data, putting high
speed data
on the data network and low speed data on the conventional phone system. This
allows concurrent use of the telephone and the system manager components on
the
same phone line. An IP Multicast signal from the DSLAM 18 is delivered to a
subscriber's residence over an xDSL link such as an Asymmetric Digital
Subscriber
2 s Line (ADSL), where it is received by an ADSL modem 20 and delivered to a
client
server such as a set top box (STB) 22 or a PC 30. More precisely, xDSL lines
connect the DSLAM 18 to an ethernet interface on the xDSL modem, and a 10BaseT
cable connects the ethernet interface on the xDSL modem to an ethernet
interface
card on the set-top or PC.
6
CA 02321462 2000-09-29
The delivery system comprises software for enabling a service provider to
offer
broadcast television over Internet Protocol (1P), including IP multicast and
unicast,
which allows channel browsing by selecting and retrieving IP multicast
streams. 1P
multicast is characterized by the sending out of data to distributed servers
on a
s multicast backbone network. For large amounts of data (including video
transmissions), IP multicast is more efficient than normal Internet unicast
transmissions because the server can broadcast a message to many recipients
simultaneously. Unlike traditional Internet traffic that requires separate
connections
for each source-destination pair, IP multicasting allows many recipients to
share the
to same source. This means that just one set of packets is required to be
transmitted for
all the destinations.
If the bit rate of the satellite transmission is not greater than 1 MBPS the
signal
may be transcoded directly to IP multicast MPEG. This takes existing digital
15 transmissions from a satellite and reprocesses them for delivery on an IP
Multicast
delivery system. The advantages of this are that it lowers the cost of head-
end
equipment 24 (satellite dish, etc.) by replacing the encoder 14 with a
transcoder 130,
and it also maximizes the quality of the signal being delivered from a digital
signal
source at the head-end (since it is only digitized once, and remains that
way). At the
2 o broadcast provider location a split/distributed head-end (signal from
satellite) can also
be employed to optimize transport facility cost. As shown in Figure 2, the
video
source may be a satellite located at head-end 24, which may be operated by a
broadcast provider such as a telephone company or other service provider. The
head
end 24, and a system server complex 40, interface with a broadband network 26
2 s through an IP multicast router 28 and a transport router 42, respectively.
Digital video equipment gathers, processes, and distributes video. This
equipment can include satellite dishes, satellite receiver units, encoders,
remultiplexers, video servers, and IP gateways. Encoders and remultiplexers
process
3 0 live video, and video servers support the distribution of stored video.
Encoders and
CA 02321462 2000-09-29
remultiplexers perform two main functions: firstly, they convert individual
MPEG-
compliant, Multi-Program Transport Streams (MPTS) from satellite into one or
more IP
multicast Single Program Transport Streams (SPTS) in real time and, secondly,
they
multicast the IP SPTS's over the service provider's IP network.
The server complex of the management system 40 (also referred to herein as
the "system manager", "DTVM" or "Digital TV Manager") contains vital software
components and comprises two main servers, namely, a system manager (DTVM)
server and a database server. The DTVM server incorporates standard web server
1 o software, and other standard software, such as JVM (Java Virtual Machine),
DHCP/BootP, RPC, and NFS. The database server runs standard database software
and stores all data for consumers (such as IPG data) including events data.
The broadband network is IP Multicast compatible and has sufficient bandwidth
capacity to transport encoded video signals. A subscriber to the broadcast
service
has access to the network via a broadband link. Examples of broadband links
include
Digital Subscriber Line (xDSL) (such as Asymmetric Digital Subscriber Line
(ADSL))
Asynchronous Transfer Mode (ATM), Frame Relay, Synchronous Optical Network
(SONET), Local Multipoint Distribution System (LMDS), Hybrid Fiber Coax (HFC),
or
2 o Fiber To The Home (FTTH). xDSL is of particular significance because it
allows a
broadcast provider to deliver programming to residential communities over
existing
copper wire (i.e. the twisted pairs linking the customer premises to the
telecommunications network) without having to delay introduction of the
service until
the other access technologies become widely available.
The subscriber can access the TV broadcast with either a personal computer
(PC) 30 having an associated monitor or a television 32 with a set top box
(STB) 22
such that, in essence, the STBs and PC's act as network computers. Each PC and
STB is configured from downloaded multicasted data sources and uses a head-end
3 o server for persistent storage. Accordingly, the consumer access 20
operates out of
8
CA 02321462 2000-09-29
memory (RAM) rather than a hard disk and this means that there is no
dependence at
the consumer end on moving parts and this, in turn, provides improved
performance,
decreased costs, reduced noise and fewer equipment failures and facilitates
automatic
software upgrades. Dependence on servers at the consumer-end is minimized and
s servers are not required for regular television viewing or Web browsing.
Once an STP
or PC boots up, basic television viewing depends only on the availability of
the video
source and the associated network.
The set top box 22 includes decoding circuitry for decoding MPEG-1 and/or
to MPEG-2 as well as IP Multicast. To view the broadcast from a PC 30 it is
equipped
with appropriate software and may optionally be equipped with an associated
MPEG
card. The STB 22 is activated by an interface unit such as a keyboard or
remote
device 23 and the PC 30 interfaces the subscriber via a keyboard and/or mouse.
15 As shown in Figures 1 and 2 the broadcast provider is able to access
television
broadcast signals from various sources such as satellite 12, off-air broadcast
or a
static source such as a storage medium containing movies or the like. The
service
provider encodes the broadcast signal (MPEG) and makes it available to service
subscribers (i.e. consumer users of the delivery system) through the broadband
2 o network 26 using the Internet protocol (1P). The system manager 40 is
linked to the
network 26 via a transport router 42 and provides end-to-end management of
services
and resources provided by the integrated broadcast delivery system.
Figure 3 shows the architectural configuration of the delivery system
including
2s the consumer end appliances (PC and/or STB), the broadband IP network and
the
DTVM components. Figure 3 also shows another aspect of the deliverable
services,
i.e. Internet access 56. User access to the network is through an xDSL access
element such as an ADSL Transmission Unit (ATU) 20. The broadband IP network
and services section includes access router 28 and the transport network
'cloud' 26.
3 o The transport network 26 has access to various components running parallel
to the
9
CA 02321462 2000-09-29
head-end, namely, video-on-demand (VOD) 50 and near video-on-demand (NVOD)
52, and the following additional "on-demand" applications: virtual digital
video recorder
(VDVR) 90 90?, "timeless" TV application and TV-on-demand, as well as e-mail
54
and Web access through the Internet 56.
For standard broadcast signals and pay-per-view (PPV) or near video on
demand (NVOD) services a multicast IP protocol is used in order to make
efficient use
of bandwidth. With this protocol numerous subscribers can have access to a
program
at the same time. For true video-on-demand service (VOD, VDVR, timelessTV and
to TV-on-Demand), however, a unicast IP protocol is used. The DTVM software
application 40 provides several features to a subscriber of the delivery and
manager
systems. These include but are not limited to customer profile management 68,
billing
and reporting 84, Interactive Program Guide (IPG) access 60, connection and
channel
packaging 104 including a self-service option 71, channel blocking (not
shown), on-
line multilingual support (not shown) and information banner functions 64.
Figure 4 is an operational schematic diagram of the broadcast delivery system.
The Digital Subscriber Line Access Multiplexer (DSLAM 18) 18 at the edge of
the high
speed IP network is a network device which may be located at a telephone
company
2 o central office. The DSLAM 18 enables a telephone company to provide
subscribers
with xDSL, such as ADSL, technology and to connect the subscriber to a fast
backbone such as an ATM transport network 26. The ATM network routes the
various broadcast services, previously mentioned, to the DSLAM 18 which, in
turn,
makes them accessible to subscribers via their PC 30 and/or STB 22. Figure 5
shows
2 s in a layer format the relationship between suppliers of the various
components of the
overall TV broadcast delivery system. At the bottom layer (layer 1 ) are the
equipment
and appliance suppliers such as set top box and computer suppliers, etc. The
second
layer (layer 2) represents the service provider such as a Telco who make
available the
IP and other protocols necessary to transport the video and furnish the
manager
3 o application functions between the service provider and subscriber. The
third layer
to
CA 02321462 2000-09-29
(layer 3) includes the application functionality of the DTVM. As indicated in
Figure 5,
these include consumer 80 and administration 82 service components, reporting
and
billing components 84 and IPG 65 and browser 75 components.
s The system manager (DTVM) utilizes some standards-based components and
its components can be categorized into two groups, namely, client (subscriber)
and
server components. Client components run locally on the STB or PC and are
collectively referred to herein as subscriber device components. They provide
three
capabilities: firstly, they provide viewing capability based on a user
profile; secondly,
1 o they provide business rules based on a user profile that specify
permissions and
restrictions to resources; and, thirdly, they forward events and registration
information
to the server. Registration information includes, among other things, the IP
address of
each device. Server components generate, manage, and update the data that is
sent
to the STB or PC. Server components also organize data according to a user
profile.
15 The DTVM may run on a Sun Solaris platform (this currently being a
preferred
platform) but the platform used will be dictated by the service provider based
on its
needs.
The subscriber device component of this embodiment uses four components
2 o that are installed the STB or PC, namely, an MPEG player, a browser, a
networking
API and a windowing API. The MPEG player supports video viewing and the
browser
supports Web browsing. The networking API supports the protocols used by the
DTVM applications such as IP, NFS, and MPEG. The windowing API specifies what
interface screens can be drawn and how. Within the DTVM software there are
many
2 s components which perform the following functions: management of the
display of all
content (including MPEG video, Interactive Program Guide (IPG), and web
pages),
processing of remote control commands, providing time measurement ability,
sending
of events data to the server, listening for updates from the server in the IP
multicast
stream, prompting the user for registration input, sending retrieved data to
the server
3 o for further processing, and registering STB or PC with the DTVM/service
provider. An
11
CA 02321462 2000-09-29
SNMP Management Information Base (MIB) component is also provided in each STB
or PC which, conventionally, uses SNMP to query and reset remote indicators
(i.e.
receives and responds to SNMP compliant messages) and, unconventionally, uses
SNMP to update consumer specific data on client devices for purposes of remote
s diagnostics, notification of new data availability and reminders or news
items.
Several "off the shelf' server components are used by the system manager and
they play the following roles:
~ A Web server stores servlets that support administration (provisioning,
remote
to diagnostics, etc.) and self service (pay-per-view, channel blocking, etc.)
transactions
and standard products such as the NetscapeT"" Enterprise Server and ApacheT"'
are
used in this.
~ JDBC (JavaT"" Database Connectivity) and SQL*NETT"" are used to enable the
Java
applications of the DTVM to access the database.
15 ~ A database stores all data for consumers, the IPG, events, etc., and the
persistence architecture of the DTVM is able to support multiple database
models,
including OracIeT"" and SyQuestT"".
~ The operating system layer provides BootP/DHCP and NFS components to support
set top box boot up and profile retrieval.
The DTVM server components are written in the JavaT"' programming language
and their roles are as follows:
~ DTVM uses two daemons (i.e. automated background processing modules):
multicast and Remote Procedure Call ('RPC'). The multicast daemon broadcasts
2s multicast data content to specific multicast addresses to deliver data to
the STB or PC.
The RPC daemon forwards events data and registration information from the STB
or
PC to the database server. The RPC daemon also has an RMI (Remote Method
Invocation) interface to support distributed Java applications. Both daemons
use the
SunT"" native JVM (Java Virtual Machine).
~ Batch transactions automate the IPG update process. The IPG update process
12
CA 02321462 2000-09-29
consists of three phases: in phase one a retrieval process uses FTP to
retrieve a data
file from the data provider that contains television programming data, in
phase two a
mapping process maps the data file to the database and in phase three a
preparation
process formats and forwards the IPG data to the multicast server.
s ~ Servlets may be used to generate HTML pages that support service
administration
and self service transactions and also to invoke persistence architecture
components
in order to make changes to the database. Alternatively, JSP (Java Servlet
Pages)
and applets may be used (instead of servlets) if increased configurability and
interactivity of self-service screens is desired.
~ Persistence architecture components facilitate connections and exchanges
between
Java business objects and database tables.
The subscriber accesses the IPG through components in the STB 22 or PC 30.
Some memory may be available locally for storing specific information, or
alternatively,
the entire IPG may be maintained in the network. The subscriber uses the
remote
control or keyboard/mouse 23 for interfacing with the IPG displayed on the
television
or computer monitor the interactive nature of the IPG gives a subscriber
control over
many aspects of the broadcast system. Program scheduling information may be
presented in a form as shown in Figures 6 and 7 (Figure 6 showing a STB IPG
and
2 o Figure 7 showing a PC IPG). With this listing displayed on a TV monitor or
computer
display the user can scan the channel line-up 126 and program schedule cells
123
listed on the display, choose, highlight and then click on a desired program
and the
television or computer will then automatically retrieve the selected IP
multicast stream.
In addition, as indicated in Figures 6 and 7, another clicking configuration
may display
2 s a brief information banner 121 with relevant data concerning program
content and
timing for a highlighted selection (i.e. "Travel with Beth" in Figure 6 and
"Debbie
Travis' Painted House" in Figure 7). Additionally, a user can click on a
desired
program and select it for recording (i.e. utilizing the VDVR application). The
DTVM in
conjunction with the IPG provides a subscriber with the ability to channel
browse for
3o TV programs and/or Web sites and order pay-per-view programs. In the
preferred
13
CA 02321462 2000-09-29
embodiment a seven day channel lineup with scheduled automatic refresh is
provided.
The IPG client software is automatically updated by the system at regular
intervals.
The data provider must provide programming data in a pipe delimited text file
once
every 24 hours, or such other period as may be appropriate. The DTVM system
s transfers data from the text file into the service provider's database and
then
multicasts IPG data from the service provider's database across the network to
the
user on the PC display or television.
In the PC environment, as shown by Figure 7, the IPG information is displayed
on the PC's monitor for programs that are currently in progress as well as
future
scheduled programs. Using a keyboard or mouse, the consumer is able to: use a
seven-day schedule for available channels; by browsing the IPG window, change
the
day by selecting another day from the Scheduled Day controller124 which is
operative
as a drop down control ; quickly access other times in the current day by a
Quick
Access controller 125; obtain the details, in the form of a Show Block 127 and
an
Information Block 121, for a show when it's clicked; retrieve the IP multicast
stream
corresponding to the selected channel when a Program Schedule cell 123 is
double
clicked (or the <Enter> key is pressed) if the show is currently running. The
Scheduled Day controller 124 is a list box giving the consumer the possibility
to select
2 o the day he/she is interested to browse. When the IPG window is activated,
the current
day is displayed. All future dates are shown as the day of the week followed
by the
calendar month and day of month. The Quick Access controller 125 is also a
list box
providing an easy and fast access to a specific daytime. A cell of the Channel
Lineup
126 column contains the station call letters and channel number for the
station that is
2s broadcasting the listed programs. On operation of the IPG the top station
of the
channel lineup is the channel currently playing unless no station is playing
in which
case the top one is the first available.
The data associated with the Program Schedule Cells 123 is controlled
3o according to the following. When the IPG window is activated, the 7 day IPG
data is
14
CA 02321462 2000-09-29
already prepared and stored in the local memory of the PC (the client device).
The
system selects the IPG data of the selected day beginning with the current
time and
displays it in the IPG window. When another day is selected by the Scheduled
Day
controller 124, the corresponding data is selected and displayed again. These
cells
contain the show title and represent the area the consumer may browse through
to
view the one day program schedule or select a program that is currently being
broadcast on a station. When a highlighted program is currently in progress
the
consumer may select that program by double clicking (or by pressing the
<Enter> key)
the program cell 123. The cells 123 are displayed with corners marking the
start and
1 o end times.
A program cell 123 can be selected through three different processes as
follows:
1 ) The user can use the mouse to click a cell and the cell will then be the
selected cell;
2) The user can scroll using the keyboard arrow keys and each arrow key press
will
select the cell the user is navigating to; or, 3) When the system timer adds a
minute to
the local clock and the first cell on the grid then becomes in the past, the
new first cell
in that row will become the selected cell. If the selected cell is not in view
when
automatic scrolling takes place, nothing will change, but the system will
display the
2 o appropriate selected cell when it comes into view. Similarly, three
different processes
are provided for changing the viewable contents of the program cells grid: 1 )
The user
may use the arrow keys to navigate and as the selected cell meets a boundary,
the
grid automatically scrolls if there is more information in the desired
direction; 2) The
user may click the scroll bars 120 and as long as there is information in the
direction
the user is scrolling, the grid will scroll; or, 3) If the system clock
updates and visible
cells become in the past, the grid will automatically scroll.
The IPG functionality as described above is identical to that of the TV/set-
top
box environment but without the PC's windows-based features including the
ability to
3 o minimize/resize the IPG window, the scroll bars 120 and the drop down list
box
CA 02321462 2000-09-29
functionality provided by the Scheduled Day controller 124 and Quick Access
controller 125. In addition, the PC's user-input mouse clicks would be
substituted with
STB remote controller clicks.
s When the IPG component is invoked (i.e. by clicking on the IPG icon 109 or
on
the Remote Controller's IPG button) the system manager retrieves the correct
current
date and time for the consumer's time zone, corrects all the shows times
according to
the consumer's time zone, selects the IPG data for the whole current day
beginning
with the current time, assigns the selected data to the IPG window's
components and
to activates the IPG window.
As stated above the IPG is a software application that operates in, for
example,
both a windows and set-top environment and provides a link to a client
MPEG-1/MPEG-2 decoder and a client conditional access module. This software
also
15 provides the user with access to all broadcast content on the broadband
multicast IP
network as well as supporting services (i.e. subscription management). The IPG
data
delivery software component 60 is server software which provides the broadcast
content schedules to the IPG client component software 65 based on the
broadcast
provider, customer location and customer profile. The server software 60
operates to
2 o extract broadcast content schedules from various existing data sources.
A banner server 64 is server software which provides scheduled ad insertion
into the IPG based on certain criteria such as the time of day, the broadcast
provider,
the customer location and the customer profile. A near video-on-demand (NVOD)
2s server 66 provides scheduled managed delivery of pre-recorded material via
an IP
multicast network. A customer profile management system/subscription
management
software component 68 stores and tracks customer preferences, usage patterns,
billing status, mailing addresses, client devices, service subscription, etc.
It also
provides the core data for many of the other components of the system manager
3 0 (DTVM). A notifier and indicator software component 70 enables the system
to script,
16
CA 02321462 2000-09-29
send and display on the customer's television/set top box or computer display
notices
and messages such as notifications regarding service changes or regarding
broadcast
scheduling changes affecting programs which have been scheduled for recording,
promotional features, telephone message caller ID and recorded messages.
The IPG may also provide access to VOD, NVOD, VDVR, Timeless TV and TV-
on-demand, Internet programming and video and audio content. "VOD" is an
umbrella
term referring to technologies that enable individuals to select a video (e.g.
movie)
from a static array of pre-recorded multimedia choices provided from a central
server
1 o for viewing on a television or computer screen. The on-line applications
enable
individuals to select program content stored in a dynamic array of recorded
video
broadcasts provided from a central server for viewing on a television or a
computer
screen. The multimedia selection could, similarly, provide for games-on-demand
whereby NintendoT""-type games may be made available for access by subscribers
through the IPG. Alternatively, a Web user interface may be provided for
selection of
a game whereby subscribers are charged per game/time played.
The on-demand VDVR software server 100 provides the user access to video
playback using interactive DVR controls for optimal control. It includes tools
for
2 o storing, managing and delivering real-time, full-screen video and audio
content. In
addition to tools for recording, storing, managing and delivering full screen
video and
audio content, it utilizes the core components of the system manager,
including, but
not limited to, Customer Profile Management 68, Interactive Program Guide 65,
Consumer Self-Service 71, Operational Services 88, Multilingual Support (not
shown),
2 s and Channel Packaging 104.
A conditional access system (not shown) consists of both a source and
destination software component and is responsible for the encryption, as
desired, of
data between the source and destination to protect against unauthorized use or
3 o copying.
m
CA 02321462 2000-09-29
A consumer services application 80 enables and controls connection services,
self-ordering services and provisioning. An automatic service function of the
consumer services application 80 eliminates the need for the service provider
(e.g.
Telco service trucks) to go to the consumer's location to add or remove new
channel
offerings. Instead, the subscriber is provided the means to change
channel/package
information online. Consumer profiles are updated immediately to the
consumer's
STB or PC by way of IP Multicast and/or SNMP. This eliminates any need for
equipment and/or personnel's physical presence to be dispatched to the user's
home
to connect or disconnect the appropriate channels. An administration services
to application 82 handles, inter alia, the importation of IPG data on a
scheduled basis.
Channel packaging, which enables a user to manage the user's subscription
(including self-service), is provided by a user interface module 71 and
enables the
user to view, add and delete channels from the user's service subscription. A
report
and billing software application 84 provides integrated billing and reporting
which
enables a user (subscriber) to dynamically monitor service usage, keep track
of
service costs on a self-serve basis and pay bills. A user is able to utilize
this ability to
monitor the household's viewing history to determine, for example, the amount
of
television being viewed by children and whether the programs watched are
suitable.
A database software component 86 provides an information database of broadcast
2 o content unique to the broadcast distribution system provider to feed the
IPG database.
An operational services component 88 of the system manager integrates the
control of
all the broadcast delivery system components into a networked management
framework and provides quality management functions and collects usage
information.
Additionally, the DTVM enables remote management of the user appliances
including the ability to query and reset key indicators such as system health
indicators
(e.g. MPEG diagnosis), application and network status (e.g. current viewed
channel,
current NFS server), and to re-initialize a user device. This may be
accomplished by,
3 o for example, an SNMP protocol. The DTVM also remotely informs the user, to
the
18
CA 02321462 2000-09-29
user's set top box or computer display, that new data and/or software is
available and
should be retrieved. This may be accomplished by, for example, IP multicast
and/or
SNMP.
s The broadcast delivery system may also provide to the service provider an
option of assigning URL's to channel numbers. A URL is an address used to
enable
an Internet browser program to find a particular Internet resource, for
example,
'http://www.imagictv.com'. Using this feature a subscriber could view a URL
channel
on the IPG similar to a television or video channel. Subscribers are then able
to scan
to through URL channels and select a desired URL by entering the associated
numbers
from the remote device in the same way as television or video channels are
selected.
Going through a URL channel would switch the user device (e.g. the set top box
or
PC) to a web browser and thereby access a selected web page. The broadcast
delivery system may also provide for channel hotlinks such that while watching
a
15 program, or when a program is highlighted on the IPG, the user can operate
a remote
entry device to activate a transfer to a dynamic web page. Such web page could
display, for example, information on the program, on the channel, or on the
subject
matter currently being shown.
2 o The DTVM software enables a subscriber to personalize channel selection,
for
example, create a list of favourite programs which the user can scan on the
IPG and
select from or have the television/set top box (or computer) automatically
switch to at
designated times. In addition, a one touch search feature may be provided to
enable
a user to specify certain searching criteria, such as program theme, by actor,
by
2 s program/movie title, etc, and initiate one step searching to retrieve
requested
programming information from the IPG. Similarly, the user may be provided with
the
ability to view a program's video trailer from the interactive program guide
when the
user "clicks on"/selects that program. The DTVM software may also provide an
intelligent agent which may be set up to remind a user of an upcoming program,
or
3 o recommend program content based on user criteria, provide gathered data
from
19
CA 02321462 2000-09-29
outside source such as TV Guide, movie critics, etc.
Other features provided by the DTVM include Multicast download where
information required to boot a network device to a multicast group is
constantly
delivered by a network server. The DHCP server is configured to return the
multicast
address and port as parameters in a BOOTP response. The network device is
programmed to join the multicast group and download a bootstrap program to
local
memory and boot from the local memory rather than across the network. Also,
the
system can provide a multicast file system wherein a server constantly
delivers a read-
only file system to a multicast group. A network device is programmed to
access the
file system by joining the multicast group and waiting until the requested
file appears.
Encryption is used for security and compression is used to minimize bandwidth.
Since
multicast UDP may lose packets, the multicast group is rejoined and holes in
the files
are filled if holes exist.
For the PC user, the DTVM includes a PC component for installation in the PC
which, advantageously, allows the user to watch television programming on a PC
using the normal PC hardware and without requiring special hardware such as a
TV
tuner card. The PC component utilizes the core components of the DTVM such as
2 o Report and Billing Services 84 (including Integrated Reporting, Integrated
Billing, and
Service Administration), Administrative Services 82 (including IPG Data
Import,
Channel Packaging and Service Administration), Consumer Services 80 (including
Connect Services, Consumer Self-Service and Provisioning), the Interactive
Program
Guide Client (including NVOD, Live Mpeg, Notifiers and Indicators, Profile,
IPG Data
2 5 Delivery and a Banner Service), the Browser Client (including Email, the
World Wide
Web, VOD, the On-Demand products, and Self-Ordering) and the Operational
Services 88 (including Event Export, Event Collection and Network Management).
On
the client side, the PC component provides all of its functionality in
software.
20
CA 02321462 2000-09-29
The PC component is itself comprised of three main components: a player
window component, a virtual remote control component and an IPG component. The
player window component provides a resizable viewing window 112, as
illustrated by
Figure 8, containing three selectable objects: a channel selector 108 , a
program
s guide icon 109 , and a remote control icon 110. The channel selector 108 is
a pull
down window that enables the user to select and retrieve an IP multicast
stream
corresponding to a specific channel. When the remote control icon 110 is
selected a
virtual remote controller 114 (being a window-type GUI) is opened and
displayed as
illustrated in Figure 8. When the program guide icon is selected an IPG as
shown by
to Figure 7 appears as a separate contollable window.
The PC component is navigated by the user using traditional windows-based
click functions on drop down lists, together with the virtual remote control.
The remote
control design is such that, for user comfort, it represents a virtual model
of the known
15 physical hand-held remote controllers. The virtual remote controller 114,
showing the
basic functions available, is illustrated in Figure 9. Figure 10 shows the
"options" box
selected for the virtual controller 114 and the various optional functions
which are
available to the user are displayed below the "options" button. As shown by
Figures 9
and 10 the virtual remote controller 114 includes user-selectable features for
channel
2o up 131, channel down 132, volume control 133, power off 134, Guide (i.e. go
to IPG)
135 plus an expandable options feature 136 providing "preferences" 137 (viz.
which
directs the system manager to always hide the remote controller on start-up or
to
display the remote contoller to the left, to the right or always on top of the
player
window), TV Off 138 (which directs the system manager to turn off the player
window
2 s but to continue to run the system manager), Hide Remote 139 (which directs
the
system manager to close the virtual remote controller display) and About 140
which
provides particulars of the version of the system manager application which is
being
run. The DTVM's Interactive Program Guide is interactive and allows users to
scroll
up, down, forward or back through several days of programming. A further
optional
3 o function which can be provided by the PC component is to enable the
subscriber to
21
CA 02321462 2000-09-29
store a received program in the hard drive of the PC whereby the PC would
emulate a
Personal Digital Recording device.
The PC component is made available to the user through downloading of
s software from a Web-based self-service component 71. The download software
includes a Java Runtime Environment and Java Media Framework (being
executables
which are required by the PC component) and a PC setup program module. Once
installed the PC component retrieves the IP address of the Application Server,
the
default language and the help desk registration number from the local config
file
1 o downloaded during the install process. It then establishes a connection to
the
Application Server and retrieves the system data from a Registry file. It also
retrieves
the IP addresses and ports of the IPG data and IPG related data from the
database.
To retrieve IPG related data the PC periodically joins the IP Multicast group
for the
IPG related data for the specified IP address and port, waits for the
beginning of the
15 stream and downloads the IPG data until the end of the stream and then
extracts and
stores the program information for existing stations including schedule
information on
its local drive. The delivery system searches the server for the consumer file
to
confirm the consumer has subscribed to the service and retrieves the consumer
specific information from the consumer file including any custom profiles the
user may
2 o have created.
Channel selection for the PC component is identical to that for the STB in
that
when the user selects a channel from the channel lineup, the system checks for
the
source type of the channel and, ilf it's video/audio, it gets the IP multicast
address and
25 port of the selected channel from the IPG Related Data object and 'tunes'
into the
channel by joining the multicast address, thereby retrieving the signal from
the
transport network rather than, as in conventional tuning systems, tuning into
one of
several signals broadcast into the home. If the source is a Web channel, the
system
clears the player window, gets the homepage URL associated with the channel,
and
3 0 launches the default browser for the already retrieved URL. In the home,
subscribers
22
CA 02321462 2000-09-29
select a channel number on the virtual remote controller. This triggers the PC
component to issue an IGMP (Internet Group Management Protocol) request to
join
the corresponding IP multicast address. That is, the channel entry triggers
the PC
component to 'tune into' the IP multicast address where the channel can be
found. To
s service the request, an IGMP-enabled network router sends channel data to
the PC.
Completing the process, the PC decodes the packetized MPEG stream into video
and
audio for display on the PC monitor.
Optionally, as shown by Figure 11, concurrent transmission of each channel via
to both MPEG-1 and MPEG-2 may be provided to allow fall back when access
bandwidth becomes impaired. This, in effect, provides a backup system if
failure
occurs on the main transmission facility. Use of such a back-up system, based
on a
configurable algorithm, enables the system manager to recognize that there has
been
a failure to deliver a video signal and, on doing so, to switch to an
alternate signal.
15 This increases the level of broadcast availability in the event of a loop
(e.g. xDSL)
impairment, encoder failure, or facility/network failure. This also allows for
multiple
client devices (STBs and/or PCs) in a single home to negotiate for the best
available
signal.
2o In accordance with the present invention broadcast on-demand applications,
designated herein as "TimelessTV", "VirtuaIDVR (VDVR)", and "TV-on-Demand",
are
provided for integration with the broadcast delivery system. Each such on-
demand
application is based on a Network DVR (NDVR) component. End-user interfaces
for
the Virtual DVR and TimelessTV applications are patterned as a historical or
non-
2 s linear interactive program guide (TimelessTV) or as a personal video
recording library
(Virtual DVR) and each is implemented on the system manager (DTVM). TV-on-
Demand programs are accessed through searching and browsing interfaces. Figure
4
shows a schematic block diagram of the delivery system in which these on-
demand
applications are integrated. As detailed below, for each of the VDVR and
Timeless TV
3 o applications, one or more on-demand video servers 90 in the network
maintain a
23
CA 02321462 2000-09-29
continuous recording of the IP Multicast broadcast content from a number of
previous
days (the number is application specific) for on-demand access by a subscriber
(user)
at some user-selected finite time after the program was initially shown. The
stored
data is indexed and made available to the subscriber in an easy-to-use format
via the
s HTML-based IPG on the subscriber's television or computer monitor. The
VirtuaIVDR
application uses the video server 90 to provide a subscriber with all the
features of a
standard television-connected VCR/DVR machine plus random access and
simultaneous multiple station recording functionality, plus automatic
upgrading for new
services/features. The Timeless TV application uses the same continuous
recorded
1 o broadcast content to enable subscribers to select a program for on-demand
viewing
without need to view such program at the scheduled broadcast time for such
program.
For the TV-on-Demand application one or more on-demand video servers 90 in the
network maintains a periodically updated inventory of programs provided by a
multimedia content providers for on-demand access by a subscriber at some user-
15 selected finite time.
The on-demand applications of the present invention are comprised of the
following three broad software components:
1. Client, administrative, and operational software components implement the
2 o subscriber interfaces to the on-demand applications.
2. Administrative and operational software components implement administrative
and operational interfaces to the on-demand video server.
3. On-demand video server software.
2 5 For the TimelessTV application network video servers record all or most of
the
multicast content from a selected set of broadcast sources (i.e. stations) and
the
recorded programs are made available to subscribers by extending the DTVM
interactive program guide (IPG) to include historical IPG data. TimelessTV
subscribers are thereby enabled to view any previously aired program, provided
that
3 o the program was recorded within the particular service window (eg, past 7
days) which
24
CA 02321462 2000-09-29
has been implemented by the service provider. All on-demand applications
integrate
simply and seamlessly with the DTVM IPG.
The Virtual DVR application also uses video servers to capture all or most of
the multicast content from a selected set of broadcast sources. The functional
difference between the Virtual DVR and TimelessTV applications is that for the
former
subscribers explicitly select the broadcast programs that they want to record
before or
during the actual broadcast of the programs. The service provider maintains a
personal video recording library for each subscriber of the Virtual DVR
application and
1 o subscribers are permitted to playback recorded content only from their own
library.
From the subscriber's perspective, the basic service obtained from the Virtual
DVR
application is equivalent to the service provided by video recording using a
standard
household VCR machine connected to the television.
For the TV-on-Demand application the service provider/content providers)
determine the programming to be made available to subscribers and the duration
for
which such material is to be made available for playback. Content providers
use the
service provider's multicast transport network to upload a fresh set of
programming
and advertising content on a periodic basis (e.g. daily). This content is made
available
2 o to subscribers for playback on the next service day and is retained by the
service
provider for the duration of a designated service cycle.
The VDVR on-demand application user interfaces enable subscribers to record
a program from the IPG, while watching a program or from a main menu portal
(see
2 5 Figure 12 in which each of these options is illustrated, wherein a "Hockey
Night"
program is selected from an IPG (a) for recording and thereby added to a
Schedule
List window (d) displayed to the user, and also showing a recording selection
from a
program display (b) showing that hockey game and a selection of the Schedule
List
window directly from a main menu (c)). The Schedule List window displays a
listing of
3 o the programs which have been selected for recording and the program just
selected is
CA 02321462 2000-09-29
shown in highlighted form. From the Schedule List (d) the subscriber may
select a Set
VCR or Play List window, the Set VCR (Set to Record) window being shown in
Figure
13 and the Play List window being shown in Figure 14 (and, as shown, the Play
List
window also allows the user to select the Set VCR option). Information
pertaining to a
s program selected for recording is obtained by highlighting and selecting the
program
from the Schedule List window whereby a Program Info window is displayed as
shown
in Figure 15. As shown, using the Program Info window the user is able to
direct the
recording record to Record Once (for one time recording of the program),
Record
Always (for setting the system to always record that particular program in
future when
1 o and if it is broadcast on a specified channel at a specified time) or
Extend Time (for
setting the system to automatically extend the recording time for the program
so that a
late running of the program, such a hockey game, will also be recorded). The
Set to
Record window of Figure 13 provides the subscriber (user) with an alternative
means
of scheduling a program for recording whereby the user selects the channel,
the date
15 and the time to record a program. This screen is accessible from either the
Schedule
List, the Play List or the main menu portal. A second Program Info window as
shown
in Figure 16 is displayed instead of that of Figure 15 when a recording
directive has
already been selected for a selected program and, as shown, this user
interface
window enables the user to direct that the system either play or delete the
program. It
2 o is to be noted that the designations "Virtual VCR" and "VCR" appearing in
Figures 12-
16 refer equally to the designations "Virtual DVR" and "DVR" used herein, the
latter
being used herein only because DVRs represent more current technology and are
tending to replace VCR.
25 The central storage device (being remote from the subscribers) on which the
recorded program is stored, and its associated software, record only one copy
of a
subscriber-tagged program for access by multiple users later. Multiple
channels may
be recorded at one time for later, on-demand play by the user. Further, the
recording
is performed by the system on a "just in time" basis whereby the user is able
to direct
3 o a recording after the program broadcast has commenced, up to the time the
broadcast
26
CA 02321462 2000-09-29
has finished, because the system automatically captures all broadcasts and
decides
upon those which are to be stored to satisfy user-entered recording directives
only
after the broadcasting of the program has been completed.
s When a program is selected for play the VDVR component provides an HTML
GUI providing VCR/DVR- like control functions of Play, FastForward, Pause and
Rewind, and Stop. Optionally, the system may be configured to allow a
subscriber to
record pay-per-view programs once they have purchased the pay-per-view program
through the DTVM. Also optionally, on-screen multilingual support may be
provided
to by the DTVM and the service provider may configure an Online Help function
on a
customized basis.
A Web interface may, optionally, be provided to enable subscribers to access
through the Internet, using a password or other secure access means, the VDVR
15 component user interfaces (e.g. per Figures 12-16) as well as the DTVM IPG
component. Using such an interface a subscriber is able to select programs for
recording from any place where the subscriber has access to a Web browser and
the
I nternet.
2o Security is established by referencing the client IP address against the
DTVM
database 86. The service provider is able to manage the recordable stations by
packaging such station channels. That is, by referencing the DTVM database,
recorded channels can be made a subset of the channels subscribed to by the
subscriber. Advantageously, the subscriber is able to remotely activate or
deactivate
2 s the Virtual DVR system through their TV screen, or monitor, without third
party
intervention.
The Virtual DVR component framework is represented at a high level by the
schematic block diagram of Figure 17. The Virtual DVR component model uses the
3 o servlet model as the basis for all user interactions, including
subscriber, operator, and
27
CA 02321462 2000-09-29
administrator interactions. In this model, the VirtuaIDVR servlet (server)106
provides
the external interface to users interacting with the VirtuaIDVR component 100
by
serving up HTML pages in response to user requests 101, 102 and 103 and
process
user directives encoded in those requests. Additionally, the VirtuaIDVR
servlet
s inherits from its framework the following core components that permit it to
be
recognised and to operate as an integrated component of the DTVM:
Logging
I nternationalization
Security
~ Error handling
Service configuration
The VirtuaIDVR servlet 106 provides all control functions for the Virtual DVR
application and acts as the first point of contact between VirtuaIDVR users
and the
z5 component. This includes parsing request URLs to determine the nature of
each
request, updating the application data model based on the settings of
parameters
included in the request, and handing the request off to an appropriate JSPT""
(Java
Server PageT"") to generate the HTML to be included in the response.
Additionally,
the servlet creates and maintains the VirtuaIDVR application context and makes
this
2 o available to VirtuaIDVR JSPs through exported interfaces.
VirtuaIDVR JSPs generate formatted HTML pages using application and user
data extracted from the supporting data model and from the VirtuaIDVR
application
context. There is one JSP for every frame on every distinct user screen, and
each
2 s JSP is associated with a request handler that the servlet calls to prepare
the data for
the dynamic content of the JSP and obtain a request dispatcher that the
servlet uses
to invoke the JSP.
All servlet and request handler access to subscriber and system data relating
to
3 o the VirtuaIDVR application is effected through interfaces exposed in the
VirtuaIDVR
28
CA 02321462 2000-09-29
component 100. The request handler prepares the data required by its JSP and
associates the prepared data with the client request to make it available to
the JSP.
The actual VirtuaIDVR data is distributed over several components of the DTVM
data
model, and the request handlers and VirtuaIDVR component 100 interact with a
core
s Data Acquisition Component (DAC) 107 and other core components as required.
When the VirtuaIDVR servlet is initialised it first loads its configuration
files.
This is a two-step process. First, a default application configuration file
that is
maintained for the application framework is loaded into the servlet context.
This
to framework configuration file contains configurable settings that are global
to all
servlets that are based on the application framework and contains only one
setting
that relates to the VirtuaIVCR servlet. That setting refers to a fully
qualified path to a
VirtuaIDVR configuration file containing configurable settings unique to the
VirtuaIDVR
application.
15 The settings contained in the framework and VirtuaIDVR configuration files
are then
made available to VirtuaIDVR request handlers and to the VirtuaIDVR
application
component through a VirtuaIVCR servlet context object. The VirtuaIDVR servlet
context extends the generic servlet context defined by the application
framework, so
the methods defined for the generic servlet context will be inherited and
exposed by
2 o the VirtuaIDVR servlet context. Once the configuration files have been
loaded into the
servlet context, the servlet creates and initialises an instance of the
VirtuaIDVR
application component and provides it with a reference to the VirtuaIDVR
servlet
context.
2 s A section of the VirtuaIDVR configuration file specifies two lists of
fully qualified
Java class names. One of these lists, the request map, specifies the set of
request
handlers defined for the application. The other list, the command map,
specifies the
set of command handlers defined for the application. When the servlet loads
these
lists it creates a single instance of each request or command handler and
associates it
3 o with its unqualified class name, which is used in client URLs to refer to
the request or
29
CA 02321462 2000-09-29
command handler. For each request or command handler, the servlet provides
references to the VirtuaIDVR servlet context and application component. The
initialisation of the VirtuaIDVR servlet is complete when the application
component
and all of the request and command handlers have been created and initialised.
At
s this point, the servlet is ready to begin its service cycle.
Each client request submitted to the servlet is encoded as a URL comprised of
a reference to the VirtuaIDVR servlet on the host Web server and a list of
parameters
and parameter values, characterized according two parameter sets - request
1 o parameters and, optionally, command parameters. Command parameters consist
of
an command identifier, corresponding to a particular action that is to be
performed
before processing the request parameters, and additional parameters that may
be
defined for a particular command. Typically, these actions involve modifying
the
underlying data model but may also be directed to modifying some aspect of the
15 servlet context. In any case, the servlet uses the command identifier to
determine
which additional command parameters to pull out of the client URL to dispatch
the
command and pre-processed parameters to an appropriate command handler. Not
all
client requests must contain command parameters so it is acceptable for a
client
request to contain no command directive and associated parameters.
Request parameters consist of a request identifier and a list of parameters
that
are defined for the particular request handler. The servlet uses the request
identifier
to determine which additional request parameters to pull out of the client URL
and
route the request and pre-processed parameters to an appropriate request
handler.
2s The request handler is invoked to prepare the dynamic data required by the
associated JSP and returns a request dispatcher that is used by the servlet to
invoke
the associated JSP, which in turn generates the HTML for the user page or
frame and
returns it to the client for display on the client screen. This completes the
processing of
the client URL.
30
CA 02321462 2000-09-29
Each Web client request that is forwarded to the servlet is handled on a
separate thread. The servlet expects all persistent state information to be
maintained
within the servlet context and application component and all request and
command
handlers to be stateless and fully re-entrant. All (and only) the classes that
comprise
the servlet context and application component will be synchronised to ensure
thread
safety.
The VirtuaIDVR context is comprised of the union of the generic servlet
context
(derived from the application framework), which provides support for
multilingual text
to and graphics, logging, error handling, and security, and additional context
that is
specific to VirtuaIDVR. The specific context includes access to VirtuaIDVR
configurable items defined in the VirtuaIDVR configuration file and helper
functions to
support the generation of well-formed VirtuaIDVR URLs including request and
command parameters.
All request and command handlers are created and initialised during servlet
initialisation. When the servlet creates a request or command handler, it
passes
references to the servlet context and the application component to the
handler. Each
handler stores these references and creates and initialises any class data
members
2 o that it requires. Importantly, request and command handlers are
discouraged from
creating any mutable class or instance data members since they are considered
by
the servlet to be available for concurrent use by multiple threads.
The names of request and command handlers are encoded in VirtuaIDVR
servlet URLs and used as a basis for routing client requests to specific
request and
command handlers. Each request handler is aware of the location of its
associated
JSP and knows which parameters are required to satisfy the request. The
request
handler undertakes to parse these parameters out of client URLs, prepare the
dynamic data required by its JSP, and return to the servlet a request
dispatcher that
3 o the servlet can use to invoke the JSP.
31
CA 02321462 2000-09-29
A Network DVR (NDVR) application is central to each of the on-demand
applications. The NDVR captures the broadcast video content in real-time by
selecting a number (e.g. up to 100) of concurrent multicast stations according
to a
recording schedule determined by the service-provider. The granularity of the
s recording schedule is very course (e.g. allocated in half-hour or hour
segments) and
this allows the NDVR to capture large blocks of IP multicast content without
reference
to the particular programming schedule of recorded stations. In the preferred
embodiment the recording schedule covers an entire week of programming and
recording is enabled during high-demand times of each day. Since the daily
recording
1 o pattern is the same, the schedule for a single day is set up and repeated
on each day.
The period of time between cycles of the recording schedule is referred to
herein as
the "scheduling window". The number of days that recorded content is retained
and
available for playback is referred to herein as the "service window".
15 An appropriate recording schedule for the NDVR is multistation recording on
a
24 hours/day over a 7-day cyclic scheduling window or 12 hours/day over a 1-
day
scheduling window. The NDVR recording schedule is not dependent on the
particular
programming schedules of the recorded stations but instead is designed to
capture
everything over a service provider -defined scheduling window (or, for
example, could
2 o be designed to capture content aired during the most popular times of day
for the
most popular stations). The mapping from specific programming events to
recorded
media is supported by I-frame indices in playlists maintained by the NDVR and
appropriate application interfaces.
2s The coupling between the NDVR and end-user interface for each of the on-
demand applications is designed to be loose because the factors which will
enable
future improvements for the NDVR (i.e. video server hardware and software
improvements) independent from and unrelated to the factors that will
determine the
specific implementations and improvements of the particular on-demand
applications
3 0 (i.e. legal and regulatory issues, market forces).
32
CA 02321462 2000-09-29
The preferred embodiment of the NDVR application is based on nCube
MediaCube 4 video server hardware and OVS 4.0 software and utilizes Optibase
encoders. A master NDVR installation is used at the head-end of the broadcast
delivery system and a number of edge NDVR installations (preferably in the
ratio of
s 1:5) are provided at the edge of the service provider network, the master
NDVR
capable of recording 50-100 stations and each edge NDVR capable of recording
10-
20 stations. The service window designated for the master NDVR is 168 hours
(24
hours x 7days) and for each edge NDVR is 36 hours (12 hours x 3 days). The
minimum disk storage capacity required of the master NDVR is 10-20 TB and for
each
1 o edge NDVR it is 400-800 GB and the number of outbound streams of the
master
NDVR is at least 2000-4000 and for each edge NDVR is 500-1000 so as to provide
for
an aggregate number of 4500-9000.
The networked master and edge servers run identical software loads but
15 operate according to different recording schedules and their supporting
hardware
differs. This configuration provides scalability so that the on-demand
application can
scale seamlessly from low loads (eg, 30 stations, 12 hours/day, 3 day cycle)
to high
loads (100 stations, 24 hours/day, 7-day cycle). The master NDVR is deployed
at the
service provider's head end to capture all of the content that is to be made
available to
2 o VirtuaIDVR subscribers for the full duration of the service window.
Additionally, for the
preferred embodiment, edge servers are deployed within locally distributed
central
offices and these are scheduled to record a high demand subset of the content
recorded by the master server and to retain it for a shorter service period
than the
service period of the master server. A high hit rate on the edge servers may
be
2 s obtained by tuning their recording schedules on the basis of ratings and
other data,
even if a shorter retention period is used for them. Additionally, for the
preferred
embodiment, edge servers are deployed within locally distributed central
offices and
these are scheduled to record a high demand subset of the content recorded by
the
master server and to retain it for a shorter service period than the service
period of the
3 o master server (i.e. the edge server does not capture and cache any content
from the
33
CA 02321462 2000-09-29
master server). The edge server recording schedules are designed so that, on
average, 80% of client playback requests can be satisfied by the closest edge
server;
the other 20% of requests that miss the edge servers will be satisfied from
the master
server.
All NDVR content is recorded by tuning into real-time IP multicasts
originating
from the MPEG1 encoders at the service provider head end and are recorded in
identical formats (2 Mbps fixed rate). On recording the NDVR must tune into an
IP
multicast stream and record content from the stream on a scheduled basis
and/or
1 o under software control. The recording scheduling interface provided by the
video
server software may be based on scheduling tables maintained in an associated
database or on software APIs that directly control content acquisition in real
time. In
either case, it provides the following controllable parameters for each
multicast
station:
~ multicast group IP address and port
record in point -- record content to include first I-frame in stream following
this time
(wall clock time reference) and multicast must be tuned in in advance to
enable this
record out point -- recording will stop at or shortly after this time
(recorded content
may be slightly longer, but must include all of the content from the in point
up to but
2 o not necessarily including the out point)
segment size -- length of time (in milliseconds) to be recorded into each file
segment
~ file segment name prefix -- used to generate sequential filenames for the
file
segments that constitute the recording
For the on-demand application embodiment described herein the broadcast
sources do not contain embedded service information (S1) and, consequently,
video
server content creation time stamps are used to resolve mappings from IPG data
onto
recorded content. Alternatively, however, if service information were to be
provided in
3 o the digital streams that are transcoded at the service provider head end
it would be
34
CA 02321462 2000-09-29
possible to arrange for the upstream decoder to pass some of this information
along
for the downstream encoder to insert into the multicast stream. This would
allow for
precise mapping of program boundaries on the basis of current IPG data and, if
the SI
information could be used to trigger recording, it would also enable precision
recording
(i.e. the start/stop for recording would occur on program boundaries and these
boundaries would be marked within recorded content that spans program
boundaries).
Each NDVR application (both master and edge) provides fully automated, best-
effort recording of all scheduled recording blocks, concurrently for multiple
sources as
to required. Additionally, each NDVR enables fully automated recovery of
storage space
for all recorded content as it ages out of the service window.
Each NDVR application utilizes a cyclic recording process that has a period
equal to the duration of the scheduling window but which is enabled
(recording) only
within the boundaries of scheduled recording blocks set up for the IP
multicast source.
The recorded content for each block is distributed over several sequential
files of
equal length (for example, record a 12-hour block into 24 files of 30 minutes
duration)
and a playlist is created to map this distribution for playback purposes. The
method of
cyclic recording, whereby content is recorded to a ring of files of equal
length, has a
2 o number of advantages. First, this method enables the video server to
record
continuously by wrapping around and overwriting the first (oldest) file
segment with
new media when the last (most recent) segment becomes full, thereby automating
the
process of storage recycling. Second, the consistent use of equal size files
for all
recording helps to alleviate the problem of disk fragmentation, which can
become
severe when the rate of storage recycling is high.
Just before a new scheduled recording block is started, the NDVR creates a
new playlist and copies the current scheduled recording block and service
window
duration into the playlist for future reference. It then allocates an empty
content file to
3 o record into, joins the multicast source stream, and co-ordinates the start
of the
CA 02321462 2000-09-29
recording on the new file. When the file is filled, the source stream is
seamlessly cut
over to a new, empty content file. When the scheduled recording block is
finished the
multicast receiver leaves the stream, closes the last content file, and saves
the
playlist. This is repeated for the all recording blocks of the scheduling
window and
s then the whole cycle is repeated successive scheduling windows.
The NDVR also operates according to a cyclic service process having a period
equal the duration of the service window. The oldest recorded playlists are
tracked
and their content files are recovered (i.e. for re-use) as they age out of the
service
1 o window. This is done in real time, so that playlists that are aging out of
the service
window lose content files from one end while subscribers continue to play
unexpired
content at the other end. Playlists are deleted after all of their associated
content files
have been recovered. This means of handling the storage media achieves an
automatic recycling of all recorded content and playlists after the completion
of each
15 cycle of the service window with a minimization of disk fragmentation.
For the VirtuaIDVR application, a greater recovery rate of content files is
achieved by monitoring the scheduled recording blocks and identifying those
that do
not contain programs that have been marked for recording by at least one
subscriber,
2 o whereby those which have not been marked by a subscriber are recovered.
Preferably, all scheduled recording blocks are recorded without regard to
whether or
not any subscriber has previously marked a program within the block for
recording as
this enables subscribers to select (mark) a program for recording at any point
up to the
end of the scheduled program broadcast. After that point, however, it is
selected that
2 s subscribers of the VirtuaIDVR application cannot mark a program for
recording and,
on this basis, a map of subscriber recording requests is constructed for each
recording
block at the end of that scheduled recording block. The complement of this map
is
used to identify and immediately recover those content files that do not
contain
subscriber-designated recordings.
36
CA 02321462 2000-09-29
A "best-effort" recording method is applied by the NDVR application. Each
scheduled record block is demarcated with real-time Coordinated Universal Time
(UTC) record in and out points with millisecond resolutions. In the absence of
embedded SI in the multicast source stream, these time references are
interpreted
against the real-time clock of the video server and although this involves a
margin of
error due to the unknown difference between the real-time clocks of the source
(broadcaster) and sink (video server) the effect is insignificant.
The video server makes a best effort to capture the media between the record
1 o in and out points and creates a playlist to map the locations of
successfully recorded
frame sequences with respect to the realtime clock. Since the source signal
may drop
out occasionally due to IP multicast packet loss or transient faults at the
source
encoder, each run of successfully recorded frames must be correctly located in
real
time so that its relative position in the playlist can be fixed. Once the real-
time position
of the head of the playlist is fixed, this is done accurately using the
program clock
reference (PCR) embedded in the source MPEG transport stream, taking the PCR
value of the head of the playlist as a basis reference point. This use of PCR
values
recovered from the source signal to correctly locate frame positions relative
to the
head of the playlist enables frame-accurate random access to any GOP within a
2 o recorded block, irrespective of any drop-outs that may have occurred
during the
recording process. This feature enables accurate translation between user
playback
requests, which are expressed using UTC in and out points within the recorded
block,
and the file locations of the I-frames at the playback request in and out
points. It also
forms the basis for a playback integrity metric, such as the percentage of
frames
2 s recorded successfully between the playback request in and out points.
Recording from multicasts requires that content metadata be generated in real
time as content is recorded, and this will involve a high system overhead as
the entire
MPEG stream must be parsed to recover the PCR, I-frame file location offsets
(and, if
3 o present, any SI information). Also, software RAID (Redundant Array of
Inexpensive
37
CA 02321462 2000-09-29
Disks) incurs a high system overhead and cannot be effectively pipelined with
MPEG
parsing. Therefore, the benefits of RAID must be weighed against the costs, in
terms
of processing overhead (software RAID), additional expense (hardware RAID),
and
the impact of individual media storage drive failures which will largely
depend upon the
s manner in which contiguous content is distributed across drives. If recorded
content
files corresponding to a single scheduled recording block tend to be
concentrated
within drives, the failure of any single drive would tend to affect only a few
programs
on a single station. Accordingly, the service provider may elect not to
attempt RAID
recovery of the drive contents in these cases if drive failure is a relatively
infrequent
1 o event.
For the on-demand applications, the primary functional requirement of the
video
server on the playback side is to provide playback of whole programs. A
request for
playback of a given program is based on IPG data that determines the station
(source)
15 that the program was aired on, the air date, and the duration of the
program. When
this information is mapped to the physical media file, it may be the case that
content is
distributed across several media files and that there are several
discontinuities
(dropouts) in the recorded program material owing to unreliable transport and
encoder
restarts. The use of the playlist for each scheduled recording block makes the
actual
2 o distribution of the content across the video server's media store
inconsequential. The
video server software creates a master playlist mapping the distribution of
successfully
recorded media and of dropouts over the files that comprise the scheduled
recording
block. This playlist is used as the point of reference for playback purposes
for all of
the on-applications, as described below. The duration of the playlist matches
exactly
2s the duration of the recording block as scheduled, with any dropouts that
may be
present being represented by pointing to a proxy clip that can be played in a
loop to fill
the duration of each dropout.
In the absence of SI information marking the positions of individual programs
3 o within the playlist, the problem of locating program boundaries is solved
on the basis
38
CA 02321462 2000-09-29
of IPG and recording schedule data and this involves a margin of error. The
method
applied by the NDVR application for resolving a subscriber request to play a
particular
program (identified by station, air date, and duration) is as follows:
1. Using the station ID and air date, determine which recording playlist
contains
s the program and verify the entire duration of the program is contained
within the
playable region of the playlist (ie, the region within the service window);
2. Subtract the program air date from the air date for the start of the
recording
block to obtain an offset into the master playlist for the recording block
corresponding to the start of the program (in point);
3. Add the duration of the program to the in point to obtain an out point for
the
program;
4. Determine the percentage of the program that was successfully recorded
(this
can be done on the basis of the information in the playlist), to be used as a
measure of the integrity of the recorded program;
5. Encode the playlist ID, the in and out points, and the integrity metric for
the
program as a content locator URL and return this to the subscriber.
(Note: If SI were present in the source stream on which program start markers
within
the master playlist could be based, a more accurate determination of program
in and
out points within the master playlist would be possible but the foregoing
steps 1, 4,
2o and 5 would remain the same.)
6. In the master playlist, locate the program start marker closest to the
program air
date and the offset to the next sequential program start marker or end of
playlist
and verify that this matches the duration of the program to within a few
minutes;
and,
2 s 7. Using the program markers located in the preceding step, obtain in and
out
points in the playlist.
(Note: In either case, the client playback device (i.e. set top box or
computer) IP
address is recorded and stored on the NDVR server. When the client playback
request is subsequently received by the NDVR, the device IP address can be
3 o recovered from the session information and used to validate the request.)
39
CA 02321462 2000-09-29
A playlist can be used for playback only over regions that are within the
service
window, so that playback requests received for a playlist are granted only if
the
requested in point is still within the service window when the request is
received. It
may be selected to set a threshold some time in advance of the trailing edge
of the
s service window and block the generation of content locator URLs with in
points falling
below the threshold so as to facilitate a recycling of the content associated
with earlier
portions of the playlist as it leaves the service window. Once the out point
of a playlist
leaves the service window it is deleted.
to Figure 17 details the administration and operations processes on the on-
demand applications. The service administrator configures the storage options
113
determining the number of days that recorded content will be maintained on the
server, that is, the duration of the service window or archive time frame. The
service
administrator configures the Virtual DVR feature parameters 114, namely, the
15 parameters for the delivery of the Virtual DVR feature to the service
provider's
subscriber base. These parameters include recording options to be made
available to
subscribers (record always, autoreplace, permitted playback controls).
The service administrator defines and modifies services 115 that will be made
2 o available to a subscriber base and defines the type and name or
description of the
service. The service provider may define and change packages in accordance
with
marketing factors. Packages may consists of stations and/or services. Packages
that
include services, may be configured to include details for the service 116.
For
instance, for a package containing the Virtual DVR service, the service
administrator
2 s must provide the number of recording slots available (the number of
recording
schedule entries) and the retention time (the length of time that recording
will be
available to a consumer). The service administrator is able to obtain service
usage
and capacity reports 117 pertaining to the Virtual DVR service. The service
administrator also creates, modifies and deletes recording tasks within a
specific
3 o recording schedule 118. Each recording schedule, and its corresponding
recording
CA 02321462 2000-09-29
tasks, are for a specific video server or group of video servers. Recording
tasks can
be a single occurrence or be recurring. All recording tasks have a
corresponding
station that is retrieved from the current IPG in DTVM. Recording tasks are
time/station based and are independent of shows. There can be an unlimited
number
s of recording tasks configured for a specific server. Recording tasks cannot
overlap
with a recording task for a specific station. Recording tasks can be for a
maximum of
24 hours in length but can recur daily to create a continuous recording of a
specific
station. From an operations standpoint a video servers recording schedule can
be
modified 119. The system converts each recording task into one or more
schedule
to recordings. Single recording tasks will create a single schedule recording.
Recurring
recording tasks create multiple schedule recordings. To start a record 120,
the
system clock must be greater than or equal to the start time of the schedule
recording.
The system requests the video server to begin recording a specific station for
a
specific duration. The record request requires a start time so that the
corresponding
1 s content can be referenced via a wall clock time. Recording requests only
know start
time duration and station. There is no concept of programs, only a wall-clock
time.
Each recording request requires a unique ID for future recovery. Where a video
server is being shut down the record component is cancelled or suspended 121.
The
system requests that the video server suspend or terminate for a specific
recording
2 o session previously initiated by the start record component 120. This
occurs typically
for maintenance purposes and provides a means to safely terminate or suspend
any
file creation activities. The cancel request is immediate and uses the unique
ID
generated by the start record component 120. When the video server restarts,
the
system requests that the video server resume normal activities for a specific
recording
2 s session previously suspended by the cancel/suspend record component 121.
The
resume request component 122 is immediate and uses the unique ID generated by
the start record component 120.
Expired content may be removed when the system clock is equal to the start
time of
the scheduled process. Content storage is incrementally recovered by deleting
3 o expired content. The expiry date of content is determined by the date the
content was
41
CA 02321462 2000-09-29
recorded and the storage options specified by the service administrator.
Expired
content and all references to that content (eg metadata) are deleted by the
remove
expired content component 123. Unreferenced content may be removed when the
system clock is equal to the start time of a scheduled process whereby content
s storage is incrementally recovered by deleting unreferenced recorded
content.
Content is unreferenced if it contains programs that have not been selected
for
recording by any VirtuaIDVR subscribers. Since recording requests are honored
only
before or during the broadcast of the program, the determination of whether or
not it
has been requested can be made as soon as the program ends. The DTVM IPG and
to subscriber scheduled recording data are periodically reviewed to locate
programs that
have not been requested for recording and their content is selectively deleted
by a
remove unreferenced content component 124.
From a client perspective, a subscriber recording interface is provided to the
15 subscriber and is embodied in the existing DTVM IPG whereby recording is
initiated
by a point and click on the monitor. Alternatively, a custom search function
may be
provided to allow the subscriber to create an IPG containing only selected
programming as determined by parameters input by the subscriber.
2 o Appendix B hereto sets out the requirements of the video server hardware
and
software which supports the Network DVR (NDVR).
The terms application, algorithm, component and module herein are used
interchangeably and refer to any set of computer-readable instructions or
commands
2 s such as in the form of software, without limitation to any specific
language,
architecture, size, location or means of operation of the same. The terms
subscriber,
consumer and customer are also used interchangeably herein to refer to the
PC/STB
user of the broadcast delivery system.
3 o It is to be understood that the specific elements of the on-demand system
and
42
CA 02321462 2000-09-29
method described herein are not intended to limit the invention defined by the
appended claims. From the teachings provided herein the invention could be
implemented and embodied in any number of alternative computer program
embodiments by persons skilled in the art without departing from the claimed
invention.
43
CA 02321462 2000-09-29
Appendix A: Glossary
BootP Refers to Bootstrap Protocol which is an Internet protocol that enables
a
diskless workstation to discover its own IP address, the IP address of a BOOTP
server
on the network, and a file to be loaded into memory to boot the machine. This
enables
the workstation to boot without requiring a hard or floppy disk drive.
Daemon A process that runs in the background and performs a specified
operation at
predefined times or in response to certain events. The term daemon is a UNIX
term,
1 o though many other operating systems provide support for daemons.
Data Provider For the subject matter herein described, a company that provides
detailed information about television programs, including station information,
show
titles, scheduled air times, etc.
DHCP Dynamic Host Configuration Protocol. A protocol for assigning dynamic IP
addresses to devices on a network. With dynamic addressing, a device can have
a
different IP address every time it connects to the network. In some systems,
the
device's IP address can even change while it is still connected. DHCP also
supports a
2 o mix of static and dynamic IP addresses. Dynamic addressing simplifies
network
administration because the software keeps track of IP addresses rather than
requiring
an administrator to manage the task. This means that a new computer can be
added
to a network without the hassle of manually assigning it a unique IP address.
Many
ISPs use dynamic IP addressing for dial-up users.
Domain A group of computers and devices on a network that are administered as
a
unit with common rules and procedures. Within the Internet, domains are
defined by
the Internet Protocol (1P) address. All devices sharing a common part of the
IP
address are said to be in the same domain.
44
CA 02321462 2000-09-29
DNS Domain Name System. An Internet service that translates domain names into
IP
addresses. For example, a DNS server might translate the domain name
"www.example.com" into the IP address 198.105.232.4.
DSLAM Digital Subscriber Line Access Multiplexer. A technology that
concentrates
traffic in xDSL implementations through a process of TDM (time division
multiplexing)
at the Telco's central office (CO) or remote line shelf.
HTTP Hypertext Transfer Protocol. The underlying protocol used by the World
Wide
1 o Web. HTTP defines how messages are formatted and transmitted, and what
actions
Web servers and browsers should take in response to various commands. For
example, when you enter a URL in your browser, this actually sends an HTTP
command to the Web server directing it to fetch and transmit the requested Web
page.
IGMP Internet Group Management Protocol. Defined in RFC 1112 as the Internet
standard for IP multicasting. IGMP establishes host memberships in particular
multicast groups on a single network. The mechanisms of the protocol allow a
host to
inform its local router, using Host Membership Reports, that it wants to
receive
messages addressed to a specific multicast group. All hosts conforming to
level 2 of
2 o the IP multicasting specification require IGMP.
1P address An identifier for a computer or device on a TCP/IP network.
Networks that
use the TCP/IP protocol route messages based on the IP address of the
destination.
The format of an IP address is a 32-bit numeric address written as four
numbers
2 5 separated by periods. Each number can be zero to 255. For example, 1.
160.10.240
can be an IP address.
1P Multicast Sending out data to distributed servers on the MBone (Multicast
Backbone). For large amounts of data, IP Multicast is more efficient than
normal
3 o Internet transmissions because the server can broadcast a message to many
CA 02321462 2000-09-29
recipients simultaneously. Unlike traditional Internet traffic that requires
separate
connections for each source - destination pair, IP Multicasting allows many
recipients
to share the same source. This means that just one set of packets is
transmitted for
all the destinations.
JDBC Java Database Connectivity. A Java API (Application Interface) that
enables
Java programs to execute SQL statements. This allows Java programs to interact
with any SQL-compliant database. Since nearly all relational database
management
systems support SQL, and because Java itself runs on most platforms, JDBC
makes it
to possible to write a single database application that can run on different
platforms and
interact with different database management systems.
Macrovision An anti-taping process that protects original material from video
piracy.
For example, a viewer cannot record a pay-per-view movie if Macrovision
protection is
in place.
MAC address Media Access Control address. A hardware address that uniquely
identifies each node of a network. In IEEE 802 networks, the Data Link Control
(DLC)
layer of the OSI Reference Model is divided into two sublayers: the Logical
Link
2 o Control (LLC) layer and the Media Access Control (MAC) layer. The MAC
layer
interfaces directly with the network media. Consequently, each different type
of
network media requires a different MAC layer.
MIB Management Information Base. A database of objects that a network
management system can monitor. SNMP uses a standardized MIB format that allows
any SNMP tool to monitor any device defined by a MIB.
MPEG Moving Picture Experts Group. A family of digital video compression
standards
and file formats. MPEG generally produces better-quality video than competing
3 o formats, such as Video for Windows, Indeo and Quicklime. MPEG files can be
46
CA 02321462 2000-09-29
decoded by special hardware or by software. MPEG achieves a high compression
rate by storing only the changes from one frame to another, instead of each
entire
frame. The video information is then encoded using a technique called DCT.
MPEG
uses a type of lossy compression, since some data is removed but the
diminishment
s of data is generally imperceptible to the human eye. There are two major
MPEG
standards: MPEG-I and MPEG-2. Common implementations of the MPEG- I standard
provide a video resolution of 352-by-240 at 30 frames per second (fps). This
produces video quality slightly below the quality of conventional VCR videos.
A newer
standard, MPEG-2, offers resolutions of 720x480 and 1280x720 at 60 fps, with
full
1 o CD-quality audio. This is sufficient for all the major TV standards,
including NTSC,
and even HDTV. MPEG-2 is used by DVD-ROMs. MPEG-2 can compress a two hour
video into a few gigabytes. Suggested reading: MPEG Video Compression
Standard,
ISBN 0-412-08771 -5; and, Digital Video: An Introduction To MPEG-2, ISBN 0-412-
08411-2.
NAT Network Address Translation. An Internet standard that enables a local-
area
network (LAN) to use one set of IP addresses for internal traffic and a second
set of
addresses for external traffic. A NAT box located where the LAN meets the
Internet
makes all necessary IP address translations. NATs serve two main purposes:
They
2 o provide a type of firewall by hiding internal IP addresses and they enable
a company
to use more internal IP addresses. Since they're only used internally, there's
no
possibility of conflict with IP addresses used by other companies and
organizations.
NFS Network File System. An open architecture operating system designed by Sun
2 s Microsystems that allows all network users to access shared files stored
on computers
of different types. NFS provides access to shared files through an interface
called the
Virtual File System (VFS) that runs on top of TCP/IP. Users can manipulate
shared
files as if they were stored locally on the user's own hard disk. With NFS,
computers
connected to a network operate as clients while accessing remote files, and as
3 o servers while providing remote users access to local shared files. The NFS
standards
47
CA 02321462 2000-09-29
are publicly available and widely used. Because the set-top box referenced
herein
has no internal hard drive, it remotely accesses an NFS server to load its
operating
system, software, and preferences.
PDU Protocol Data Unit. An OSI (Open Systems Interconnection) term that means
"packet". A PDU is a data object exchanged by protocol machines (entities)
within a
given layer. PDUs consist of both data and control (protocol) information that
allows
the two to coordinate their interactions.
RFC Request for Comment. A series of notes about the TCP/IP standards,
procedures, and specifications. Anyone can submit an RFC. Eventually, if it
gains
enough interest, it may evolve into an Internet standard. Each RFC is
designated by
an RFC number.
RMI Remote Method Invocation. A set of protocols being developed by Sun's
JavaSoft division that enables Java objects to communicate remotely with other
Java
objects.
2 o RPC Remote procedure call. A type of protocol that allows a program on one
computer to execute a program on a server computer. Using RPC, a system
developer need not develop specific procedures for the server. The client
program
sends a message to the server with appropriate arguments and the server
returns a
message containing the results of the program executed.
Servlet An applet that runs on a server. The term usually refers to a Java
applet that
runs within a web server environment. This is analogous to a Java applet that
runs
within a Web browser environment. Java servlets are becoming increasingly
popular
as an alternative to CGI programs. The biggest difference between the two is
that a
3 o Java applet is persistent. This means that once it is started, it stays in
memory and
48
CA 02321462 2000-09-29
can fulfill multiple requests. In contrast, a CGI program disappears once it
has fulfilled
a request. The persistence of Java applets makes them faster because there's
no
wasted time in setting up and tearing down the process.
s SNMP Simple Network Management Protocol. A set of protocols for managing
complex networks. SNMP works by sending messages, called protocol data units
(PDUs), to different parts of a network. SNMP-compliant devices, called
agents, store
data about themselves in Management Information Bases (MIBs) and return this
data
to the SNMP requesters.
to
Time Division Multiplexing A technique for transmitting a number of separate
data,
voice and/or video signals simultaneously over one communications medium by
quickly interleaving a piece of each signal one after another.
15 TCPIIP Transmission Control Protocol/Internet Protocol. The suite of
communications
protocols used to connect hosts on the Internet. TCP/IP uses several
protocols, the
two main ones being TCP and IP. TCP/IP is built into the UNIX operating system
and
is used by the Internet, making it the de facto standard for transmitting data
over
networks.
UDP User Datagram Protocol. A connectionless protocol that, like TCP, runs on
top
of IP networks. Unlike TCP/IP UDP/IP provides very few error recovery
services,
offering instead a direct way to send and receive datagrams over an IP
network. It's
used primarily for broadcasting messages over a network. The system manager
2 s described herein uses the UDP protocol for the RPC server and this was
chosen
instead of TCP because TCP allows a limited number of set-top box connections
through the RPC server. If the RPC server went down, the set-top boxes could
not
reconnect.
49
CA 02321462 2000-09-29
URL Universal Resource Locator. An address format used by a Web browser for
locating an Internet resource.
xDSL x Digital Subscriber Line. Generic term for all types of digital
subscriber lines,
including ADSL (Asymmetrical DSL) and VDSL (Very-high-data-rate DSL). DSL
technologies use complex modulation schemes to pack data onto copper wires.
They
are sometimes referred to as last-mile technologies because they are used only
for
connections from a telephone switching station to a home or office, not
between
switching stations. xDSL is similar to ISDN inasmuch as both operate over
existing
to copper telephone lines (POTS) and both require short runs to a central
telephone
office, usually less than 20,000 feet. However, xDSL offers much higher speeds
- up
to 32 Mbps for downstream traffic, and from 32 Kbps to over I Mbps for
upstream
traffic.
CA 02321462 2000-09-29
Appendix B: Video Server Technical Requirements
The VirtuaIDVR applications build upon a foundation of high-capacity and high-
performance video servers that can record digital television content from many
concurrent IP multicasts and play recorded content back to subscribers over an
IP
network.
The following outlines the specific extensions to and modifications of the
Oracle Video
Server (OVS) that are required to support the VirtuaIDVR framework.
to
Video Server Essential Requirements
A. Recording
1. A capability to set up, maintain, and tear down a recording session under
software control is required. Since OVS will rely primarily on RTSP to set up,
maintain, and tear down playback sessions, the use of the RTSP RECORD command,
with suitable extensions may be used for this purpose. The command parameters
must minimally permit the recording client (component) to specify:
(a) Multicast source IP address and port.
(b) Media format and bit rate.
2 0 (c) Date and time of day to begin recording (record in point).
(d) Duration of time to record for.
(e) A string prefix to be used to generate names for files created by the
recording.
2. The ability to record from IP multicasts of MPEG-2 single program transport
streams is required. The video server must be capable of maintaining multiple
(up to
100) concurrent recording sessions.
3. The video server must create an index that accurately relates the recorded
media to the timeline of the source stream originating at the head end. In
particular,
3 o this index must accurately map out in time the locations of any media that
may have
51
CA 02321462 2000-09-29
been dropped (i.e. not recorded) owing to IP packet loss or other transient
conditions.
4. Recording sessions must be robust and fault tolerant. In particular, the
video
server must maintain recording sessions under conditions of multicast IP
packet loss
and other transient conditions.
5. The video server must maintain a control connection to the recording
client to permit status queries and reports to be communicated between the
recording
server and client. In addition to responding to client requests for session
information,
1 o the video server will be required to asynchronously send status
information to the
recording client in the event of significant changes to the status of
recording sessions,
such as persistent loss of signal.
B. Media storage allocation and recovery
1. While recording sessions will typically span several hours, it is required
that the
video server will distribute the content recorded within each session over a
series of
file containers of equal capacity. This is required in order to facilitate
incremental
recovery of storage associated with a session and to minimize the effects of
disk
2 o fragmentation on the continuous, high-volume, 24/7 recording service.
2. It is required that these file containers be of exactly identical length,
even if the
video server requires that they begin and end on particular boundaries (e.g. I-
frame or
GOP boundaries). A relatively small amount of internal file fragmentation is
of little
consequence in comparison to the advantages of ensuring minimal external disk
fragmentation.
3. The index file that maps the recorded timeline (see A.3 above) must ensure
the
correct sequencing of the file containers that hold the actual media recorded
within a
3 o recording session, in addition to mapping the time location of any media
that may
52
CA 02321462 2000-09-29
have been dropped during the session.
4. The video server must provide methods to permit VDVR applications to
enumerate all recorded timelines available on the video server, including
timelines that
are in the process of being recorded. The video server must also provide
methods to
allow VDVR applications to retrieve associated metadata for each timeline,
including
(at least) the record in point (date & time), duration (normal play time,
compensating
for recording drop-outs and deleted file containers), media format, and bit
rate.
l 0 5. The video server must provide methods to permit VDVR applications to
enumerate all of the file containers associated with a recorded timeline.
6. The video server must provide methods to selectively delete file containers
from
within a timeline, without impacting the ability to play back other regions of
the timeline
where the associated file containers are available. This is required to permit
media
storage to be recovered progressively from the head of the timeline as the
timeline
ages out of the VDVR service window, and to permit file containers that are
associated with regions of the timeline that are not referenced by any
consumers to be
2 o recovered.
C. Content locators and playback
1. Named recorded timelines will form the basis for the generation of content
locators URLs for playback clients. The play in and out points for content
locators,
expressed as millisecond offsets in relation to the record timeline (ie, in
normal play
time, irrespective of recording drop-outs and deleted file containers), will
be included
as modifiers in the URL. This is consistent with standard RTSP usage.
3 0 2. The video server must provide a method to permit VDVR applications to
53
CA 02321462 2000-09-29
determine the viability of a content locator before including it in a play
command. This
can be expressed as a percentage of media indicated by the play in and out
points
that is actually available on the server.
3. The video server must permit playback of content locators that are not 100%
viable. The intention here is to allow playback of content locators that span
recording
drop-outs of short duration (e.g. a few seconds). For the present, it is
acceptable if
the video server simply "plays through" these drop-outs.
1 o D. Security
1. The video server must provide a method to allow a service administrator to
register with the video server the IP addresses of the servers that will host
VDVR
recording clients. The video server must vet all recording requests against
its
database of registered VDVR servers and log and refuse all recording requests
not
originating from a registered DTVM host.
2. The video server must also provide a method to prevent playback of content
locators not brokered by VDVR. Conceptually, the authorization model must
include
2 o the following capabilities:
(a) The video server must provide a method to permit the application server to
inform
the video server that a particular client has the right to view a particular
piece of
content.
(b) The video server must vet client requests to view recorded assets and
refuse or
grant these requests on the basis of access rights assigned by the application
server.
Oracle Video Server Support for VirtuaIDVR~DDVR)
54
CA 02321462 2000-09-29
A model provided by Oracle Corporation which meets the foregoing
requirements and is used to support the VDVR is referred to as the Network DVR
(NDVR).
Scheduling and recurrence: From a subscriber's (consumer's) point of view,
VirtuaIDVR record requests are templates or generators for individual program
recordings (e.g. record all episodes of this program from this station, record
a single
episode from this station, record this program slot every weekday, etc). The
VirtuaIDVR application retains complete control over recurring record requests
in the
Zo NDVR model and this task is simplified by requiring only that the generated
specific
recording requests be added as rows to a subscriber recording table maintained
by
the video server. This table is used by the NDVR to calculate an optimal
recording
schedule that captures all generated requests as space permits.
Consumer recording: The NVCR model does not require a predefined recording
schedule to be maintained as all recording scheduling is performed on the
server side
by analysing the set of pending subscriber record requests. This enables
subscribers
to record programs from VirtuaIDVR-enabled stations at any time.
2 o Post facto recording: Post facto recording is a term used to refer to
recording a
program after the program's air date is past. The NDVR enables or disable post
facto
recording on a per-station basis and, when it is enabled, to continually
record the
station in a rolling recording window of sufficient duration to store any
entire program
(say, 4 hours). Any post facto subscriber recording requests can then be
satisfied by
retaining and not recycling the corresponding recorded media as it rolls off
the rolling
feed window. The NDVR also supports an opportunistic method of post facto
recording that enables subscribers to request recordings for programs that
have
already started to broadcast.
3 o Recording sessions: The NDVR model maintains a table of all subscriber
recording
CA 02321462 2000-09-29
requests and analyses and coalesces these requests to generate an optimal
schedule
to drive the recording processes. The recording processes maintain status and
end-
point information in the subscriber requests table on a regular basis to
provide nearly
real time views of the status of in-progress subscriber recordings. This
avoids any
need for the service administrator to maintain a master recording schedule for
each
VirtuaIDVR-enabled station or for the VirtuaIDVR service to setup, maintain,
and tear
down live recording sessions in real time.
Recorded program boundaries: A table of all subscriber recording requests is
1 o maintained and includes the record in and out points in each row. The
inclusion of
this information allows the video server to maintain complete control over the
recovery
and allocation of media storage without application (VDVR) intervention.
Fault tolerant recording: The video server tolerates transient signal loss
(i.e. dropped
multicast packets) but terminates recording sessions if the input signal is
lost for more
than a few minutes. Restartable recording sessions may be used and the
locations of
persistent media loss may be visibly marked by playing a proxy clip to fill
unrecorded
gaps.
2 o Integrity metrics & playback: An integrity metric is required in order to
enable the
DTVM to inform subscribers in the event that one of their recorded programs
contains
regions of dropped media of significant extent. This may take the form of the
number
of minutes of dropped media (total for the recorded program) and the duration
of the
longest dropped region. In the event that an incompletely recorded program is
2 s requested for playback, the video server will play through short drop-outs
and will play
a proxy clip in place of longer drop-outs.
Storage allocation: Since the VirtuaIDVR application may cohabit the same
video
server installation with other video server applications a fixed percentage of
the
3 o available media storage is allocated to VirtuaIDVR using a global
configurable setting.
56
CA 02321462 2000-09-29
The video server will accept subscriber record requests at any time and will
make the
determination of available storage space just before the respective air dates.
Requests that cannot be satisfied due to low disk storage conditions are
marked
accordingly in the corresponding rows of the subscriber recording table.
Storage recycling: The NDVR records content to series of fixed-length files
(segments)
to minimize disk fragmentations and permit incremental recovery of storage
allocated
during recording sessions. Accordingly, the recovery process is driven using
the
information in the subscriber recordings table. The VirtuaIDVR is required to
add and
to remove rows in the subscriber recording table as subscriber's request and
delete
recordings. The task of locating unreferenced segments and deleting them is
handled
entirely by a background process running on the video server at regular (e.g.
hourly)
intervals.
Security and integrity: For each subscriber recording a row is maintained in
the video
server subscriber recording table that includes the record in and out points.
This can
take greater advantage of the end point information in the subscriber
recording table
to manage ticketing and to ensure the integrity of the subscriber end points
during
playback (i.e. to constrain consumer fast forward and rewind operations to
remain
2 o within the recorded program boundaries).
Distribution model: The NDVR model manages multiple VirtuaIDVR video servers
comprised of a master server and a number of associated edge servers. A
service
administrator selects the high-demand stations and times and the VirtuaIDVR
duplicates each recording request that falls within these stations and times
on the
master server and the edge server that is closest to the requesting
subscriber. In this
manner, most of the high-demand content is recorded to both the master and
nearest
edge servers and can be played back from either server, as required, to
minimize
network traffic.
57
CA 02321462 2000-09-29
Administration: The NDVR model allows the video server to fully encapsulate
the
video server from a subscriber's perspective but some administrative and
operational
interfaces may not be completely hidden to the video server. OVS
administrative and
operational interfaces are used for certain aspects of VirtuaIDVR maintenance
viz.
server startup and shutdown. Direct interfaces between VirtuaIDVR
administrators
and operational personnel are minimized by using appropriately configured
interfaces
where desired.
58
