CA2321462C - Digital interactive delivery system for tv/multimedia/internet with on-demand applications - Google Patents

Abstract

This invention relates to a system for interactive on-demand delivery of multimedia using a multicast broadband backbone network transmitting IP-configured digital multimedia (e.g. television) signals. More particularly the on-demand system provides, inter alia, a Virtual Digital Video Recorder functionality. A system manager provides interactive access to the multimedia signals by a subscriber through either a decoder in a set top box (connected to a television) or a decoder in a computer (connected to a monitor) configured for converting the IP format signal into a format for display on the television or monitor. A central multimedia storage means is located within the network 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 for display on the television or monitor. The multimedia content is stored in the storage means in a format configured for locating same in response to a deliver request. An interactive program guide (IPG) may provide access to the multimedia signals and the multimedia signals are transmitted through the network according to scheduling corresponding to the interactive program guide. The on-demand component receives a record request (which includes broadcast channel and time information identifying the multimedia content and may utilize the IPG) from a subscriber and stores the multimedia content in response to the record request.

Description

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 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 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 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 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.

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 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.

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 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 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 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 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 (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 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 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 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 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 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 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, 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 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 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 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.

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 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 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 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 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 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 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 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 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

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 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.

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.

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).

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 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 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 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 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.

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 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 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.) 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 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 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 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 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.

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.

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 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 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 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 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.

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.

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 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 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 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) 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 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.

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.

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.

Claims (14)

1. An on-demand multimedia delivery system for use in an integrated multimedia broadcast delivery system extending from a broadcast provider to a subscriber, said broadcast delivery system comprising means for providing multimedia signals configured according to IP (Internet Protocol) format for multicast transmission over a broadband network and a system manager for providing interactive access to said multimedia signals by said 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 said IP format signal into a format for display on said television or monitor, said on-demand delivery system comprising:
(a) a central multimedia storage means located within said broadcast delivery system and remote from said subscriber for storing multimedia content; and, (b) an on-demand component configured for receiving a deliver request from a subscriber for said stored content, for locating said requested multimedia content from said storage means and for delivering said requested multimedia content to said conversion means for display on said television or monitor, wherein said multimedia content is stored in said storage means in a format useful for locating said multimedia content in response to said deliver request.

2. A system according to claim 2 wherein an interactive program guide (IPG) is provided to said subscriber for said access and said multimedia signals are transmitted through said network according to scheduling corresponding to said interactive program guide, said on-demand component being further configured for receiving a record request from a subscriber and for storing said multimedia content from said signals in response to said record request.

3. A system according to claim 3 wherein said record request includes broadcast channel and time information identifying said multimedia content.

4. A system according to claim 3 wherein said record request is made from said interactive program guide.

5. A system according to claim 4 wherein said multimedia content corresponds to a broadcast program.

6. A system according to claim 5 wherein said multimedia content corresponds to multiple programs broadcast at the same time.

7. A system according to claim 5 wherein said record request is received any time up to the end of transmission of said signal corresponding to said program.

8. A method for on-demand delivery of multimedia content to a subscriber using a broadcast delivery system extending from a broadcast provider to a subscriber, said broadcast delivery system comprising means for providing multimedia signals configured according to IP (Internet Protocol) format for multicast transmission over a broadband network and a system manager for providing interactive access to said multimedia signals by said 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 said IP format signal into a format for display on said television or monitor, said method comprising:
(a) providing a central multimedia storage means within said broadcast delivery system and remote from said subscriber for storing said multimedia content;
(b) receiving a deliver request from a subscriber for said stored content;
(c) locating said requested multimedia content from said storage means; and, (d) delivering said requested multimedia content to said conversion means for display on said television or monitor, wherein said multimedia content is stored in said storage means in a format useful for locating said multimedia content in response to said deliver request.

9. A method according to claim 8 whereby said system manager provides an interactive program guide (IPG) to said subscriber for said access and said multimedia signals are transmitted through said network according to scheduling corresponding to said interactive program guide, and further comprising receiving a record request from a subscriber and storing said multimedia content from said signals in response to said record request.

10. A method according to claim 9 whereby said record request includes broadcast channel and time information identifying said multimedia content.

11. A method according to claim 10 whereby said record request is made using said interactive program guide.

12. A method according to claim 11 whereby said multimedia content corresponds to a broadcast program.

13. A method according to claim 12 whereby said multimedia content corresponds to multiple programs broadcast at the same time.

14. A method according to claim 13 whereby said record request is received any time up to the end of transmission of said signal corresponding to said program.