WO2000074381A1

WO2000074381A1 - Multi-level broadband multimedia delivery system

Info

Publication number: WO2000074381A1
Application number: PCT/US2000/013503
Authority: WO
Inventors: R. Max Mutrux
Original assignee: Bridge Information Systems, Inc.
Priority date: 1999-05-18
Filing date: 2000-05-17
Publication date: 2000-12-07
Also published as: AU5138100A; WO2000074381A9

Abstract

The present invention is directed to a broadband multimedia entertainment delivery system using Asynchronous Transfer Mode (ATM) and Digital Subscriber Line (DSL) or other broadband delivery technologies for delivering multimedia content to Set-Top Boxes (STBs) located in homes or offices. The system has the ability to provide the following services via the Set-Top Box: network television with interactive effects (IEFs); local network affiliates with IEFs; movies on demand with pause/restart; music CD preview on deman; high-speed internet access (available via television set and home computer); regular (voice) telephone service, virtual answering machine/voice mail, and the option of multiple lines; videoconferencing (with other subscribers to the system); remote access to participating corporate computer networks; multiples programmable smart cards. The present invention, when implemented using ATM-DSL delivery technology, has a major advantage over conventional systems in that existing copper telephone lines can be employed for content delivery over the final segment (6.000 feet) of transmission. These may be supplemented by a second twisted-pair DSL line or by VDSL when increased capacity (e.g., more than one STB) is desired.

Description

SPECIFICATION

To All Whom It May Concern:

Be It Known That I, R. Max Mutrux, citizen of the United States, resident of the City

of Wildwood, County of St. Louis, State of Missouri, whose full post office address is 1338

Bear Canyon Road, Wildwood, Missouri 63021, have invented certain new and useful

improvements in

Multi-Level Broadband Multimedia Delivery System

CROSS-REFERENCES TO RELATED APPLICATIONS

Not Applicable.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR

DEVELOPMENT

Not Applicable.

REFERENCE TO MICROFICHE APPENDIX

Not Applicable.

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION

The invention relates to information transmission, and more particularly to broad band

transmission of audio, video and data to a plurality of subscribers.

BACKGROUND

Various means are available for providing information such as audio, video and data

to homes and offices. Such means include radio and television broadcasting, cable systems,

telephone systems, and the like. Although the information transmitted is primarily for the

purpose of entertainment, similar needs arise in the business context or simply in person-to-

person communication.

Available systems function fairly well for many applications, but they can be

improved. For example, many conventional systems would require new wiring or cabling to

supplement or replace existing residential copper wiring. Conventional systems are also

limited in the number of channels which they can supply. And they have other drawbacks.

For example, cable systems are subject to various "cable fraud" problems. Many available

systems are severely limited in bandwidth, which makes delivery of video content, and the

integration of video with other content, very difficult or expensive, or both. Available speeds with many conventional systems are, at best, inadequate to provide acceptable high

bandwidth content.

SUMMARY OF THE INVENTION

The present invention is directed to a broadband multimedia entertainment delivery system

using Asynchronous Transfer Mode (ATM) and Digital Subscriber Line (DSL) or other

broadband delivery technologies for delivering multimedia content to Set-Top Boxes (STBs)

located in homes or offices. The system has the ability to provide the following services via

the Set-Top Box:

• Network television with interactive effects (IEFs)

• Local network affiliates with IEFs

• Movies on demand, with pause/restart

• Music CD preview on demand

• High-speed internet access (available via television set and home computer)

• Regular (voice) telephone service, virtual answering machine/voice mail, and

the option of multiple lines

• Videoconferencing (with other subscribers to the system)

• Remote access to participating corporate computer networks

• Multiple programmable smart cards.

The present invention, when implemented using ATM-DSL delivery technology, has

a major advantage over conventional systems in that existing copper telephone lines can be

employed for content delivery over the final segment (6,000 feet) of transmission. These may

be supplemented by a second twisted-pair DSL line or by VDSL when increased capacity

(e.g., more than one STB) is desired.

- j - Among the various objects and features of the present invention may be noted the

provision of a system which does not require new into-the-house wiring or cabling: existing

copper telephone lines are sufficient to deliver all services included in the system.

Another object is the provision of a system which has the capability of delivering an

unlimited number of channels.

A third object is the provision of such a system which eliminates most fraud problems

currently inherent in cable-type systems.

A fourth object is the provision of such a system which facilitates integration of video

delivery with the internet and provides extraordinarily high speed internet access.

A fifth object is the provision of such a system which provides away-from-home

access to voice-mail, internet, and corporate networks and different media access levels for

different members of each household.

A sixth object is the provision of such a system which is flexible so that yet-to-be-

developed media delivery and exchange possibilities such as STB-to-STB gaming, delivery

of different advertisement content to different boxes depending on their user profiles, and so

on may be readily incorporated into the system.

Other objects and features will be in part apparent and in part pointed out hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

Figs. 1-13 are various block-diagrammatic views showing the elements and

interconnections of the various levels of the present invention, in which:

Fig. 1 illustrates the various levels of the distribution system of the present invention;

Fig. 2 illustrates the connection from a regional level down to neighborhood

distribution nodes with the houses in a particular area; Fig. 3 illustrates the connection of national level sites to regional sites, showing key

components at each level;

Fig. 4 illustrates key components of the national level sites used in the present

invention;

Fig. 5 illustrates key components at the regional level of the system of the present

invention;

Fig. 6 illustrates key components at the area level of the system of the present

invention;

Fig. 7 illustrates the key connections for the set top box used in the system of the

present invention;

Fig. 8 illustrates the directory server level of the distribution system of the present

invention;

Fig. 9 illustrates real-time video servers used in the present invention;

Fig. 10 illustrates the connections for the Key/IEF/Guide servers used in the present

invention;

Fig. 11 illustrates virtual DVD/CD servers used in the present invention;

Fig. 12 illustrates telephony connection between the set top box and the telephony

gateway in the present invention;

Fig. 13 illustrates the various components and software processes of the set top boxes

used in the present invention.

Similar reference characters indicate similar parts throughout the various views of the

drawings. DESCRIPTION OF THE PREFERRED EMBODIMENT

Turning to the drawings, the overall structure of the system of the present invention

may be seen. It should be understood that this structure allows existing copper phone lines to

be used for final delivery of information to a household. For example, a single twisted-pair

DSL line, with its capacity of 6-8 mb, is sufficient for most households, as indicated below.

With the exception of the internet, if all the most bandwidth-intensive services which can be

used together are simultaneously in use (DVD on demand. PEP, phone A, and phone B), the

required bandwidth is 4.84 mb, much less than the worst-case capacity of a single DSL line (6

mb). In this scenario, a minimum of 1160 k is available for internet use, or considerably

more if other services are not in use. Turning to Fig. 1, it is anticipated that in each participating country, the system has

five distribution levels, which for convenience are called National Operations Center, Central

City Site, City-Area CO, neighborhood distribution node, and Set-Top Box (STB). Of

course, these labels are for convenience only. The National Operations Center ("NOC") is a

central site, there being preferably one NOC per country. The site labeled Central City Site is

a regional site, there being preferably one Central City Site for each major metropolitan area

in the country. At the next level, there are as many City-Area COs (area sites) around each

Central City Site as needed to cover the metropolitan area (e.g., 24 for the greater St. Louis

area). There are in turn as many neighborhood distribution nodes as necessary to connect

with houses in the CO's area (Fig. 2). Each node connects with either 30 or 120 houses, and

the maximum distance between node and house is 6,000 feet.

The National Operations Center contains: (1) Virtual DVD/CD Servers connected to

large drive arrays and satellite transmitters; (2) Management/Provisioning Workstations; and

(3) Key/IEF/Guide Servers. All three groups of machines are connected to on-site ATM

switches, which are in turn connected to outgoing ATM lines (ranging from DS3 to OC12 or

alternatively by dark fiber) to the Central City Sites. (See Figure 3).

As shown in Figure 5, the Management/Provisioning Workstations are used for:

(1) network, switch, and STB monitoring; and (2) for manually entering each STB address,

key, IP address, and phone number into the system as new STBs come on line. Note that the

keys thereby entered are sent to the Key/IEF/Guide Servers at the NOC level, and from there,

are sent to Key/IEF/Guide Servers at Central City Site locations.

Virtual DVD/CD Servers at the national level are used for staging the release of new

movies and music titles. As new titles are received, sixteen-hour blocks of content are built,

stored in the national archives (large drive arrays at the NOC), and released to the City Area COs where they are stored and made available (via the City Area Virtual DVD/CD Servers)

for on-demand viewing/listening. The preferred release/delivery method to the City Area

COs is satellite, but the ATM network may also be used for delivery during its off-peak

hours.

The Key/IEF/Guide Servers receive the STB-related data (ATM address, key, EP

address, phone number) entered into the system at the Management/Provisioning

Workstations. They then route the STB data to a Central City Site Key/IEF/Guide Server in

the STBs metropolitan area. In addition, national IEF and Program Guide documents enter

the system via a TCP connection to the NOC Key/IEF/Guide Servers, which authenticate and

then send the documents out to all Central City Site Key/IEF/Guide Servers.

Turning to the next level, each Central City Site preferably contains: (1) sixteen

Directory Servers; (2) Key/IF/Guide Servers; (3) Real-Time Video (RTV) Servers connected

to satellite and cable line inputs; and (4) Internet Gateways. All four groups of machines are

connected to on-site ATM switches, which are in turn connected to lines from the NOC, OC

3/12/48 lines to other Central City Sites, OC 12/48 lines to the Neighborhood COs, and OC3

lines to the internet. Figure 6 shows a Central City Site.

The sixteen Directory Servers at each Central City Site perform the following

functions:

(1) Authenticate each Set-Top Box (STB) that makes an SVC connection to them

(the Directory Server obtains STB key information by making a call to an on-

site Key/IEF/Guide Server, then stores the keys in its own database).

(2) After authentication, route STB requests to appropriate machines elsewhere in

the system (e.g., channel tuning requests are forwarded to the appropriate RTV Servers; requests for movies-on-demand are forwarded to the Virtual DVD

Servers at the City Area CO closest to the box).

(3) Handle Interactive Effect (EEF) and Program Guide documents by listening to

the IEF and Guide streams from the Key/IEF/Guide Servers; extracting

documents applicable to their host city; storing and scheduling the documents

for release; and releasing them into the system via the RTV Servers or directly

to the STBs at the scheduled time.

Every active STB in a metropolitan area has an active point-to-point SVC connection with a

Directory Server.

The Key/IEF/Guide Servers respond to key lookup requests and sends current IEFs

and Guide information to the sixteen on-site Directory Severs. The Key/IEF/Guide Servers at

each Central City Site have a peer-to-peer relationship on a point-to-multipoint stream, in

which each server listens to all of the others. Thus, key data, IEFs, and Guide information

received by any Central City Site Key/IEF/Guide Server is soon propagated to the other(s) at

that site. Key data enters the system at the NOC level, as do IEF and Guide information (the

latter two enter via TCP connections from the networks.)

The Real-Time Video Servers distribute three point-to-multipoint SVC streams for

their assigned television channel: an MPEG 2 stream, an IEF stream, and a PEP stream (for

picture-in-picture). Programming is received directly from the networks/local affiliates, via

cable or satellite. IEFs are received from the on-site Directory Servers. In addition, requests

for STB joins to and deletions from the multipoint streams are received from a Directory

Server.

The Internet Gateway provides internet access to each household via a PVC

connection between the Internet Gateway and a STB. After initial authentication of the connection, the gateway acts as a simple router, sending packets to IP address destinations as

specified.

Turning to the next level in the system, the City- Area COs contain: (1) Virtual

DVD/CD Servers connected to large drive arrays and satellite receivers; and (2) Telephony

Gateways interfacing to Telco voice switches. These (1) and (2) are connected to on-site

ATM switches, which are in turn connected to lines from their Central City Site, and to OC

3/12 fiber lines to the neighborhood distribution nodes within the CO's area. See Figure 2 for

an overview of how City Area COs and neighborhood distribution nodes are laid out.

Figure 7 shows a City Area CO.

The Virtual DVD/CD Servers at each City Area CO receive 16-hour blocks of

programming (movies or CDs) from the NOC. The blocks are stored on large drive arrays

attached to the Virtual DVD/CD Servers, and the content is then available for on-demand

transmission to the STBs via point-to-point SVCs. Prior to establishing the delivery SVC,

guide information (i.e., available movies and CDs) and the user's final choice are exchanged

between the STB and Virtual DVD Server, which also consults a Central City Site Directory

Server for key data with which to authenticate the box^'s request.

The Telephony Gateways at a City Area CO provide a dial-tone to each house in the

city area. A PVC connection is established between each STB and the Telephony Gateway

when the box is first activated, with STB authentication provided via a Telephony Gateway to

Central City Site Directory Server call. The PVC then remains mapped, ready to be activated

whenever a phone connected to the STB, is removed from its cradle.

The neighborhood distribution nodes or area sites consist of low density ATMDSL

switches, with each switch connected to either 30 or 120 houses. Each house must be within 6,000 feet of the ATMDSL switch. Simple switching is the only functionality provided at

this level.

The lowest level of the distribution system of the present invention is the Set Top Box

(STB) shown in Figure 8. Each Set-Top Box (STB) can be attached to a television, home

computer, two telephones (or more, using drop-lines), a microphone, and a camcorder or

videocam. The requisite connections are provided on the back of each box: a DSL line

connection, two phone jacks, an Ethernet port, left and right audio out (to the television),

video out (to the television), video in (for camcorder or videocam), and microphone in. An

amplifier can be added to the system between the STB and television if higher quality audio

is desired. Note also that the STB has an integrated web browser, so internet access is

available via the television and/or the optional home computer attached to the Ethernet port.

Finally, the Ethernet port can be mapped to a closed users' group belonging to the households

of a corporation requiring a SOHO network (VPN).

A smart card slot for multiple external smart cards is provided on the front of the

STB. Each card can be programmed for different access levels to television channels,

internet sites, on-demand media, and so on. The cards are portable, allowing use in other

STBs, thereby providing on-the-road access to voice-mail, internet, and corporate network,

along with other services. The STB is provided with its own keys and the 16 universal

Directory Server addresses upon manufacture.

Authorization and authentication

A digital signature authentication and authorization method is employed at all levels

of the system. Each Set-Top Box is given its own private key upon manufacture, in addition

to the public keys and ATM addresses for the Central City Site Directory Servers. When a

user subscribes to the system, the user's STB public key, ATM address, IP Address, and authorization level (level of service paid for) are entered into the system at the NOC level,

then propagated to all Central City Sites by the Key/IEF/Guide Server system. When the

user's STB is turned on, it establishes an SVC connection with a Central City Site Directory

Server, which checks the public key database to verify that an STB requesting connection

from a particular ATM address is authentic and authorized to receive the requested media.

Every machine in the system is assigned a private key, and as a general rule, each time

an SVC connection is established anywhere in system, the participating machines must

exchange identities to ensure authenticity. Symmetrical authorization is employed, based on

a triple packet exchange, performed as follows. Upon establishing an SVC, the connector

sends a request for authorization with a random number embedded in it. The connectee then

returns the connector's number along with its own number in a signed message. The

connector then returns that message, signed. Both sides of the connection are thereby

authenticated. When point-to-multipoint connections are involved, the multipointer must

sign every packet or provide a heartbeat signature at regular intervals.

Note that authentication usually involves the Directory Servers, as they are connected

to all multimedia delivery machines (RTVSs, Virtual DVD/CD Servers), to all active Set-Top

Boxes, and to the Telephony Gateways and Internet Gateways. With respect to the two

Gateway-based services, authentication only takes place once, when the STB-to-Gateway

PVC is first joined. The other services repeat the authentication procedure every time an

SVC is joined.

The Switch Infrastructure

The entire system in linked from "top" (the NOC in each country) to "bottom"

(individual STBs) using the ATM protocol to create a nationwide ATM network. In addition,

all Central City Sites (one per major metropolitan area) are linked laterally, so videoconferencing, voice signals and internet information can be sent back and forth between

cities. The ATM switch infrastructure is employed primarily to facilitate: (1) connections

between multimedia delivery machines and STBs, as indicated in the Table 1, and

(2) machine-to-machine connections throughout the delivery system, as indicated in

subsequent tables. (Note that in all tables, arrows describe direction of initial connection

only.)

Table 1* - Multimedia Delivery to STBs

*Arrows indicate the direction of initial connection only.

Note that the two primary multimedia delivery devices, the RTV Servers and Virtual

DVD/CD Servers, connect to the STBs, not vice versa. All channel tuning and media-on-

demand requests from a STB are received by a Directory Server and relayed to the

ι: appropriate multimedia delivery machine, which in turn establishes a connection for the

delivery of content to the STB. As already discussed, authentication of STBs and their

requests occurs primarily at the Directory Server level. The PVC connections for telephone

and internet service are authenticated when first joined (the gateway involved makes a call to

a Directory Server).

The sections below (starting with "Key/IEF/Guide Servers") provide a brief

discussion of each important machine in the distribution system, along with its primary

connectees and connectors. A more detailed view, including each machine's internal

processes, is provided thereafter.

Machine-by-Machine Overview

Key/IEF/Guide Servers

The Key/IEF/Guide Servers (KIGS), which sit at the Central City and NOC levels,

perform a three-part function. As Key Servers, they store the public keys and ATM addresses

for all entities participating in the system, and they respond to requests to look up keys. As

IEF Servers, they receive, authenticate, store, schedule, and transmit current Interactive

Effects, in addition to deleting old ones. As Guide Servers, they receive, authenticate, store,

schedule, and transmit current Program Guide information, in addition to deleting outdated

guide information.

The connections made by a Key/EEF/Guide Server vary according to whether it sits at

the NOC level or at a Central City Site. NOC-based Key/IEF/Guide Servers form (1) point-

to-multipoint SVC connections to all Central City Sites nationwide (connecting to one KIGS

at each site) to disseminate IEF and Program Guide documents; and (2) they also form city-

specific point-to-point SVC connections (to one KIGS in the city) to transfer the keys/ ATM

addresses of new STBs coming on line in that city. Central City Site Key/IEF/Guide Servers sitting at the same site have a peer-to-peer relationship on a point-to-multipoint stream in

which each server listens to the other(s). Thus, key data, IEF content, and Program Guide

content added to one server in a given city is soon known by all the Key/IEF/Guide Servers at

that site. The other connections for Central City Site Key/EEF/Guide Servers are point-to-

multipoint SVCs to the city's Directory Servers, used to provide the Directory Servers with

IEF and Program Guide documents. Finally, the city-based Key/EEF/Guide Servers accept

point-to-point SVC Joins from the Directory Servers for key lookups.

Table 2* - ATM connections for Key/IEF/Guide Servers

*Arrows indicate the direction of initial connection only. Real-Time Video Servers

Real-Time Video Servers sit at the Central City Sites only. Each Real-Time Video

Server (RTVS) receives the real-time video/audio streams for one network television channel.

The RTVS encodes the streams in MPEG 2 format and sends them out via a point-to-

multipoint SVC to all STBs tuned to that channel in the metropolitan area. The RTVS also

sends out a second point-to-multipoint SVC stream for picture-in-picture (PIP), and a third

point-to-multipoint SVC strewn for IEFs. Note that the PIP stream goes to a different group

of STBs (tuned to the server's channel for PIP), than the main MPEG 2 stream and the IEF

stream, which go to STBs tuned to the channel for their main-screen program.

Each RTVS also maintains SVC connections with all 16 on-site Directory Servers,

thereby receiving IEFs and STB join requests. In response to join requests, the RTVS

adds/deletes STBs from its point-to-multipoint SVC streams, as appropriate. Authentication

of the STB requests takes place at the Directory Servers.

Table 3* - ATM connections for Real-Time Video Servers

*Arrows indicate the direction of initial connection only. Directory Servers

Sixteen Directory Servers sit at each Central City Site, where they perform two

broad functions: (1) handling IEF/Guide information; and (2) coordinating/controlling

responses to Set- Top Box actions such as tuning a channel. The Directory Servers listen to

the IEF and Guide information sent out by the Key/Guide/EEF Servers, accepting and storing

the information that applies to channels available in their city. IEF documents are then sent

to channel-appropriate RTV Servers just prior to their scheduled "on-screen" time. Directory

Servers also accept (or reject) SVC connections initiated by the STBs, based on authorization

information extracted from the Key/IEF/Guide Servers sitting at the Central City Site. If a

connection is accepted, Directory Servers can then:

Refer all channel tuning requests from the STB to the appropriate RTV Server;

• Send IEFs due within 30 sees, directly to the box when a channel is changed;

• Send current Program Guide information to the STB, and allow STB access to the

Guide database for more detailed queries

• Route requests for on-demand media to an appropriate VDVD/CD Server (at

Neighborhood CO site closest to STB).

Table 4* - ATM connections for Directory Servers

*Arrows indicate the direction of initial connection only.

Each of the 16 Directory Servers at a Central City Site has a "well known" ATM address, and

the same set of sequential addresses is used for each city. This allows STBs to be imprinted

with Directory Server addresses upon manufacture. A newly activated STB in any city can

then simply make an SVC call to an address picked randomly from its imprinted list, rolling

through the list until a connection is found.

Virtual DVD/CD Servers

Virtual DVD/CD Servers at the City Area COs have access to 16-hour blocks of

programming (movies or CDs) stored on large drive arrays. When an STB requests on- demand media, the Central City Site Directory Server provides the ATM address of an

appropriately located Virtual DVD/CD Server with "scheduler" functionality (two Virtual

DVD/CD Servers per site have this functionality). The STB then connects to the Virtual

DVD/CD "Scheduler" Server, which provides movie or CD guide information (i.e., available

titles), and authenticates/authorizes the requesting STB by making a key-lookup call to a

Central City Site Directory Server. If the box is properly authorized, the user may then select

a movie or CD, and the STB relays the request back to the "Scheduler" Server via the already

established connection. The Scheduler Server checks all on-site servers for a program block

slot which contains the requested media. If a slot is found (each server can handle up to 64

users), the Scheduler Server requests that an SVC be joined from the Virtual DVD Server

with the open slot to the STB, and the content is delivered. If no slot is found, a message is

sent by the scheduler server to the STB and the transaction is cancelled, or a later time is

scheduled.

Table 5 - ATM connections for Virtual DVD/CD Servers

^Arrows indicate the direction of initial connection only.

Telephony Gateways

A dial tone is provided to each house in an area via the Telephony Gateways at the

City Area CO. A PVC connection is established between each STB and the Telephony

Gateway when the box is first activated. The usual authentication process occurs, and the

PVC then remains mapped, ready to be activated whenever a phone connected to the STB is

removed from its cradle. A Tl interface to Telco voice switches is used to provide a dial- tone. Outgoing calls can be routed via the same Tl interface, or through the ATM switching

system to another City Area CO Telephony Gateway or directly to a STB.

Table 6* -Telephony Gateway(TG) connections

*Arrows indicate the direction of initial connection only.

Internet Gateways

Internet gateways, located at Central City Sites, provides internet access to each

household. A PVC connection between the Internet Gateway and each STB is initially set up

at the NOC level (entered into the system via the Management/Provisioning Workstations,

along with the STB's ATM address and IP address). Then, when the STB is activated for the

first time, it is authenticated (using the standard symmetrical, triple-packet-exchange

authorization) and informed of its IP address. The gateway then acts as a simple router,

sending packets to EP address destinations as specified.

Set-Top Boxes

As already noted, multimedia content generally connects to the boxes, not vice versa

(see Table 1 on page ). If a television channel is tuned, the STB receives a "What^'s on Now"

Guide from a Directory Server, programming and IEFs from an RTVS. IEFs from a Directory Server if the channel has just been tuned, and PIP from an RTVS. If the media-on-demand

feature is in use, the STB receives a movie or CD from a Virtual DVD/CD Server. The STB

can be said to connect directly to content (not the content connecting to the box) only for the

services which use an already mapped PVC connection— telephony (including

videoconferencing), the internet, and the optional NAT services for home access to a

corporate network.

STB requests are sent out to the rest of the system primarily via a Central City Site

Directory Server. The exceptions, again, are requests for telephony, videoconferencing, and

internet access, which an active box has access to without the Directory Server functioning as

an intermediary. Note, however, that the Directory Server is also involved in these service

connections, as follows. (1) The Telephony Gateway queries the Directory Server for key

(i.e., authorization) data and for the telephone numbers and ATM addresses of other gateways

in the system. (2) At initial set-up, the STB queries the Directory Server to get its own IP

address and the IP address of the Internet Gateway at the Central City Site.

Various components of the present invention are described in more detail below:

Directory Servers

As previously described. Directory Servers have two broad functions: (1) coordinating

and controlling system repines to STB requests, and (2) handling IEF and Program Guide

information. The Directory Server processes which handle these functions are shown in

Figure 8.

With respect to the IEF/Guide function, the Directory Server receives EEF and

Program Guide documents from the city's Key/IEF/Guide Servers. The EEF and Guide

Multipointer running on the KIG Server sends the documents to the EEF and Guide Listener

(upper left area of Fig. 8). The documents that pertain to the respective city (based on channels available there) are placed in the server's EEF and Guide Database, from which they

are extracted by the IEF and Guide Scheduler, then sent out at the appropriate times, as

follows:

• The IEF documents are sent to channel-appropriate RTV Servers by means of

the RTVS Connection Manager process. (The subsequent RTVS-to-STB

transmission is timed so that the EEFs arrive at Set-Top Boxes 30 seconds

prior to display time, thus causing a window of EEF non-availability up to

seconds 30-seconds long when a new channel is tuned. This gap is covered by

the procedure described next.)

• IEF documents are also sent directly from Directory Servers to STBs for up to

30 seconds whenever a box tunes a new channel, thereby covering the 30-

second window described in the previous bullet-point. (The required EEF

documents are extracted from the server's EEF and Guide database by the

STB Connection Manager process, and sent out via the already established

SVC to the box).

• The Guide information is sent out via the Guide Mulupointer as a "What's on

Now" guide, consisting of the Program Guide documents for programs

scheduled in the current hour (or other unit of time). These are sent directly to

the STBs over a point-to-multipoint SVC used for Program Guide information

only. The current-hour documents are looped by the multipointer.

To obtain more detailed Program Guide information, functionality may be added whereby

users can query the Program Guide database maintained by each Directory Server. The

queries would be received by the Directory Server via the STB-to-DS SVC established when

a box is turned on. In addition to handling the IEF/Guide information, Directory Servers coordinate and

control responses to Set-Top Box actions, as follows.

• Directory Servers accept (or reject) SVC connections initiated by the STBs,

based on authorization information extracted from the Key/IEF/Guide Servers

sitting at the Central City Site, and using the method described previously

under "Authorization and Authentication".

• Directory Servers refer all channel tuning requests from the STBs to the

appropriate RTV Servers (for main channel and PEP). If a channel is tuned

which the box is not authorized for, the tuning request is refused and a

message sent to the affected STB.

• Directory Servers store the keys, ATM address, telephone number, and IP

address for each STB in the metropolitan area, in addition to the IP address of

the internet gateway assigned to each STB, and the location of the Telephony

Gateway and VDVD/CD Servers closest to the box. Subsets of the

information may be shared with STBs and other machines in the system to

facilitate authentication and connection with resources located closest to the

STB.

Real-Time Video Servers

Each Real-Time Video Server (RTVS) receives the real-time video/audio streams for

one broadcast television channel. The RTVS encodes the streams in MPEG 2 format and

sends them out via a point-to-multipoint SVC to STBs tuned to that channel in the

metropolitan area. The RTVS also sends out a second point-to-multipoint SVC stream for

picture-in-picture (PIP), which consists of images one-sixth the size of the regular stream

(without audio), and at a rate of 10 frames per second (FPS) instead of 29.97 FPS. Finally, the RTVS sends out a third point-to-multipoint SVC stream consisting of the IEFs for its

station (sent out 30 seconds prior to display, and held in a buffer by the STBs). Note that the

PIP stream will go to a different set of STBs (tuned to the server's channel for PIP), than the

main MPEG 2 stream and the IEF stream, which will go to STBs tuned to the server's

channel for their main program.

The functionality just described corresponds to the processes running on each RTVS,

shown in Figure 9. Simply, the RTVS consists of three roughly congruent systems which

handle input, process the input if necessary, then hand it to the three multipointer s. The input

for MPEG 2 (the "main channel") enters directly into the MPEG 2 Encoder (upper left area of

Fig. 9) as raw, real-time video and audio streams. The encoder processes the streams into a

single, MPEG 2 audio/video stream, and sends the encoded stream to a dedicated driver

which in turn sends it to the MPEG 2 Multipointer. The input for PIP (the "picture in

picture") enters as a second raw, real-time video stream (with no audio) into the Frame

Grabber, which renders it at 10 FPS, and sends it to a dedicated driver which in turn sends it

to the PIP Multipointer. The input for IEFs is sent from the Directory Servers, and enters via

the Control Process (bottom left area of Fig. 9). The Control Process, which receives 16

copies of each IEF document (one from each Directory Server), discards 15 copies, and sends

one to the IEF Multipointer. In addition, the Control Process—which is connected to all 3

multipointers— receives join and delete requests from the Directory Servers and routes them to

the appropriate multipointers, which then add STBs or delete STBs from their point-to-

multipoint SVC streams.

Several virtual Real-Time Video Servers may be assigned to each physical box at the

City Central site, depending on the hardware used. Whether RTVSs are essentially "virtual"

(several running side-by-side on each box), or "real" (one per box), the same principles apply: Each RTVS is assigned one television channel, received as raw video/audio streams, and has

three outgoing point-to-multipoint streams. An SVC connection is maintained to each on-site

Directory Servers., from which the RTVS receives EEFs and join/delete requests.

Virtual DVD/CD Servers

When first brought on line, the Virtual DVD/CD Servers connect to a Central City

Site Directory Server to announce their existence, and the Directory Server adds their ATM

addresses to its database, so when an individual Set-Top Box requests a movie, the Directory

Server can determine the proper Virtual DVD/CD Server for the STB to query (i.e., a server

at the City Area CO nearest the STB). The processes running on the Virtual DVD/CD

Servers are shown in Figure 11. Note that the "Scheduler" functionality (shown in the bottom

right quadrant) of Figure 11 is available only on two of a City Area CO's Virtual DVD/CD

Servers.

When an STB requests on-demand media, the Central City Site Directory Server

provides the ATM address of an appropriately located Virtual DVD/CD "Scheduler" Server,

and the STB connects to it. Movie or CD guide information (i.e., available titles) is provided

to the STB by the scheduler. The user then selects a title, the Scheduler makes a key lookup

call to a Directory Server to authenticate/authorize the requesting STB, and a point to point

SVC is then joined from a Program Block Server to the STB for the delivery of the requested

content. If no available slot on a Program Block Server can be found (each server can handle

up o 64 users), a message is sent to the STB and the transaction is cancelled, or a later time is

scheduled.

Telephony Gateway

closest City Area CO. As shown in Figure 12, a PVC connection is established between each STB and the Telephony Gateway when the box is first activated (see PVCs going into PVC

Decoder process in Fig. 12). The usual authentication process occurs, and the PVC then

remains mapped, ready to be activated whenever a phone connected to the STB is removed

from its cradle. A Tl interface to Telco voice switches is used to provide a dial-tone.

Outgoing calls can be routed via the same Tl interface, or through the ATM switching system

to another City Area CO Telephony Gateway or directly to a STB.

Set-Top Box

Each Set-Top Box contains two CPUs, which boot from common flash memory.

CPU 1 then runs with its own private DRAM memory, and CPU 2 runs from flash and

common DRAM. (See Figure 13a) In general terms, CPU 1 routes anything coming into the

box from outside the house (MPEG, telephone, internet), and its basic function is simply

moving data, in addition to running the ATM SVC-PVC Manager and ATM/DSL Driver.

CPU 2 handles user requests (tuning channels), and performs most of the higher functions of

the box, such as requesting a new channel and checking for authorization via the Directory

Servers while sending a control message to CPU 1 to inform it that a new point-to-point

stream will be coming in from the new channel, and the previous stre.itn should be discarded.

As shown in Figure 13a, a Set-Top Box contains the following main hardware

components.

CPU #1 - runs the ATM/DSL controller, Ethernet controller, and POTS lines 1 and 2.

CPU #2 - connects to IR, keyboard, mouse, USB, smart card interface

MPEG 1 and 2 audio and video decoder

Video Controller

Audio Controller

64 mb DRAM (common) • 16 mb FLASH (common)

16 mb of DRAM (private)

Between the two CPUs is 64 mb of common DRAM and 16 mb of common FLASH. The

latter will contain the boot software for both CPUs. The video controller has video in and out

as a pass-through. It also has an overlay feature used to superimpose graphics on top of the

MPEG 2 display.

Figures 13b and 13c show the software processes running on CPU 1 and CPU 2,

respectively. Note that the processes on the two CPUs have a mailbox interface, with the

structure of the interface appearing the same from either side. As already stated, CPU 1 is

primarily concerned with data coming into the box via the ATM-DSL Controller. The

incoming data is routed by the ATM SVC/PVC Manager process, which sends it (the data) to

the proper subsystems (for MPEG 2, Telephony, and the internet, as shown in Fig. 13b).

Next to the ATM SVC/PVC Manager in Figure 13b is the SVC/PVC Manager for CPU 2.

This process allows the processes from CPU 2 access to the ATM layer running off of CPU 1.

As shown in Figure 13c, most of the services offered via the MMDS System have a

corresponding process running on CPU 2. When one of these processes is activated (e.g., a

channel is tuned, activating the Real-Time Video process near the middle of the diagram), it

generally sends a request via the ATM PVC/SVC Remote Stub and mailbox interface to the

CPU 2 SVC/PVC Manager in Figure 13b. From there the request is handed off to the ATM

SVC/PVC Manager and is routed out of the box to the proper machine in the system (in this

case, it goes to a Directory Server). Tuning a channel

1. Turn on STB, tune channel 100. The DS Proxy /Agent (a process running on the STB,

on CPU 2) makes and SVC call to the Directory Server. This connection stays up as

long as the STB is turned on.

2. The Real-Time Video Coordinator (also a process on CPU 2 of the STB) tells the

Video Stream Subsystem on CPU 1 to throw away its previous connection, if any.

3. The Real-Time Video Coordinator tells the DS Proxy /Agent to request channel 100.

4. The STB Connection Manager (a process running on the Directory Server) checks the

STB database on the DS for authorization information. If the STB is authorized for

channel 100, the (Directory Server's) Real-Time Video Connection Manager is so

informed.

5. The Real-Time Video Connection Manager (RTVCM) sends an STB-join request to

the Real-Time Video Server for channel 100. (The RTVCM has accepted and

maintained an SVC connection from each RTVS since the RTVS came on line.)

6. The control process running on the RTVS receives the join request and hands it off to

the MPEG2 multipointer, which performs an ATM join of its point-to-multipoint

stream to the Video Stream Subsystem running on CPU 1 of the STB.

7. The packet stream thereby entering the STB is then decoded by the MPEG Decoder

and sent as two streams (for video and audio) to the Video Controller and Audio

Controller, respectively.

8. At the Video Controller, the video stream is merged with any graphic IEFs provided

via CPU 2. If there are no graphic effects, the video passes straight through the

controller. 9. The video and audio out of the respective controllers go directly to the television

video and audio inputs.

On-Demand Movies

1. User clicks STB button requesting an on-demand movie.

2. The command goes through the STB control plane running on CPU 2, turns off

whatever process is currently running (e.g., tells CPU 1 to stop receiving video from

an RTVS), and sends a request via CPU 2s Directory Server Proxy Agent to the

Directory Server.

3. The Directory Server looks up the addresses of the primary and secondary VDVD

machines at the City Area CO closest to the STB, and returns that information to the

STB.

4. The STB makes a point-to-point SVC connection to the Scheduler process running on

a Virtual DVD/CD Server at the nearest City Area CO.

5. The Scheduler queries its Program Database and returns a Movie Guide display to the

STB. The Guide, listing available choices, pops up on screen.

6. User selects a movie, and a message is sent back to the VDVD Scheduler, which then

checks Program Block Server availability for the user's selection. At the same time,

the Scheduler makes a call to a Directory Server to verify authorization and

authenticate the STB.

7. If everything's OK, an on-screen display document to that effect is returned to the

STB. User hits "play."

8. VDVD Scheduler tells Program Block Server (PBS) to open an SVC to the box.

9. Video stream subsystem on CPU 1 of the box requests a block from the PBS, and

continues to request (unless User "pauses" movie) until the movie is over.

50 10. The Block Delivery System manages duration of the VDVD Server to STB

connection, terminating the connection at twice the duration of the movie. (For a 2-

hour movie, users can take up to 4 hours to view it.)

While a preferred form of the invention has been shown in the drawings and

described, variations in the preferred form will be apparent to those skilled in the art, so the

invention should not be construed as limited to the specific form shown and described.

Claims

WHAT IS CLAIMED IS:

1. A multi-level broadband multimedia delivery system comprising:

at least one central site having servers for storing entertainment media such as

motion pictures, having satellite transmitters for transmitting information from the

servers, and having workstations for controlling and monitoring the system;

at least one regional site connected to the central site by ATM switches, said

regional site having directory servers for authenticating regional system connections

and for routing user system requests, said regional site also having real-time video servers for supplying real-time video information regionally through ATM switches;

at least one area site for each regional site, each area site having a plurality of

virtual servers and telephony gateways, each virtual server having storage for entertainment received from the central site and having satellite receivers to receive

entertainment from said central site; said area site having ATM switches connected to its corresponding regional site and to a local telephone company switch, and further having fiber optic

connections for supplying said entertainment and voice telephone capability to

neighborhoods; a plurality of neighborhood distribution nodes connected to each area site by

the fiber optic connections, each neighborhood distribution node being connectable to

at least thirty buildings such as houses, each building to which a node is connected

being within 6,000 feet of said distribution node, each distribution node including an

ATMDSL switch;

for each building to which a distribution node is connected, at least one in-

home end user unit connected to its corresponding neighborhood distribution node by

a line having at least the carrying capacity of a single twisted-pair digital subscriber line, said end user unit being adapted to receive entertainment in a predetermined

format and supply said entertainment to a television or home computer.

2. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each end user unit has stored therein a unique unit identification

number, said number being recorded at said central site.

3. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein said line connecting the neighborhood distribution node to the end

user unit is a conventional copper telephone line.

4. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each neighborhood distribution node is connectable to up to 120 buildings.

5. The multi-level broadband multimedia delivery system as set forth in claim 1 wherein the central site workstations include means for entering each end user unit identifying and authenticating information into the system and for communicating

said identifying and authenticating information at least to the regional sites.

6. The multi-level broadband multimedia delivery system as set forth in

claim 5 wherein each regional site includes means for authenticating end user units

indirectly connected thereto from the identifying and authenticating information

received from the central site.

7. The multi-level broadband multimedia delivery system as set forth in

claim 5 wherein the identifying and authenticating information includes an ATM

address for each end user unit and a security key for said unit.

8. The multi-level broadband multimedia delivery system as set forth in

claim 7 wherein the identifying and authenticating information further includes an IP

address for the end user unit and a telephone number for the unit.

9. The multi-level broadband multimedia delivery system as set forth in claim 1 wherein the regional site directory servers are programmed to route

authenticated requests from end user units to sources which fulfill those requests.

10. The multi-level broadband multimedia delivery system as set forth in

claim 9 wherein if the request is for a particular video channel, the regional directory

servers route the request to a real-time video server.

11. The multi-level broadband multimedia delivery system as set forth in

claim 10 wherein each available channel of real-time video has its own real-time video server.

12. The multi-level broadband multimedia delivery system as set forth in

claim 9 wherein if the request is for a motion picture, the regional directory servers route the request to a virtual server in an area site.

13. The multi-level broadband multimedia delivery system as set forth in claim 12 wherein the motion picture request is routed to the area site closest to the end user unit initiating the request.

14. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each active end user unit has an active point-to-point SVC connection

with a regional directory server throughout the time said end user unit is active.

15. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein the real-time video servers are each assigned to a single

corresponding television channel and distribute the video from that channel in

MPEG2 format.

16. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each regional site further includes an internet gateway for providing

internet access to each end user unit.

17. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein the area sites are connected to the neighborhood nodes by a

connection having at least the capacity of an OC3/12 fiber connection.

18. The multi -level broadband multimedia delivery system as set forth in

claim 1 wherein each end user unit further includes connections for at least one

telephone, connection for telephone service to the end user unit being made through

the corresponding area site to the local telephone company.

19. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each end user unit further includes slots adapted to receive external

smart cards, said smart cards being programmed for various access levels to the services offered by the system.

20. The multi-level broadband multimedia delivery system as set forth in claim 19 wherein said smart cards are portable, whereby access to user services may

be obtained at any end user unit suitably equipped to accept smart cards.

21. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein each end user unit has its own private key stored > ,ιcrein, along with

public keys and ATM addresses for the regional sites.

22. The multi-level broadband multimedia delivery system as set forth in

claim 21 wherein each end user unit scrolls through the ATM addresses for the

regional sites until it finds the regional site corresponding to the geographic area in

which that end user unit is located.

23. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein the real-time video servers and virtual servers are connected to the

end user units upon request so that only those end user units which have requested particular real-time video or motion picture information are supplied those videos and information.

24. The multi-level broadband multimedia delivery system as set forth in

claim 1 wherein the virtual servers may each provide stored entertainment to up to a predetermined number of end user units.

25. The multi-level broadband multimedia delivery system as set forth in

claim 24 wherein the predetermined number of end user units is sixty-four.