WO2001013632A1 - Internet-based program broadcast system - Google Patents

Abstract

A decentralized network for the high-quality transmission or live or prerecorded interactive Internet-based programs such as shows, classes, and meetings to a virtually unlimited number of clients (16) any place in the world. At least one bi-directional repeater/aggregator (12) communicates between a server (10) and one or more clients (12) for (1) receiving the program content from the server (10) over the communication pipe and re-broadcasting the content to a plurality of clients (12), and (2) aggregating data from the plurality of clients (12) and sending a composite thereof to the server (10) over the communication pipe.

Description

INTERNET-BASED PROGRAM BROADCAST SYSTEM

This application derives from and claims the benefit of U.S. Provisional

Application No. 60/149,111, filed August 14, 1999, which is incorporated herein by

reference in its entirety, and is also a continuation-in-part of U.S. Application No.

(Attorney Docket No. R7600.0002/P002), filed July 6, 2000, entitled "Decentralized

Internet- Based Program Production System," which is incorporated herein by reference

in its entirety.

BACKGROUND

It will be assumed that the reader is familiar with basic Internet technology. To

the extent that explanatory information is required, the reader is referred to How The

Internet Works by Preston Galla (1997, Ziff-Davis Press) and Computer Networks and

Internets by Douglas Comer (Second Edition, 1999; Prentice-Hall, Inc.), the contents

of which are hereby incorporated by reference.

The production of Internet-based program content and producer information

can be thought of as consisting of two types of signals: (1) the audio and video content

of the program itself (hereinafter, the "A/V content") and (2) commands. The A/V

content is typically sent to the client over the Internet as streaming video and streaming

audio. Because audio and video content contain a large amount of information,

streaming techniques typically compress the content, and transmit the compressed

content to the client in IP packets using UDP protocol. Unlike the TCP protocol typically used to transmit text, UDP does not constantly check to see if data has been

received by the client, and does not resend packets if they are lost in the course of

transmission to the client. The loss of video information (e.g., an occasional frame) or

audio information is acceptable and is frequently minimally detectable by the viewer.

Producer information such as commands tell the system to launch such features as poll,

chat, and talk-back and are known, per se, in Internet- based broadcast system

technology. Poll, for example, typically launches one or more text-based questions,

with a choice of answers for each question, and is a way to gather information about

viewers' tastes, opinions, knowledge, etc. Chat provides the viewer with a way to

interact with other viewers. Talk-back permits the viewer to send questions and

comments directly to the commentator. Other features are known as well, and this list is

only intended to be exemplary.

Similarly, the foregoing descriptions of streaming audio and video signals are

exemplary only, and are not intended to limit the scope of the invention in any way.

Those slcilled in the art appreciate that many different protocols can be used, although

the foregoing are the currently used standards, and will understand that this invention is

not limited to the use of any particular protocol, A/V content or command.

As the program content is created as part of the interactive presentation, the

content's producer (or production team) launches commands, such as poll, with the

intent that the viewer see and respond to the poll questions at particular points in the

presentation. The broadcast is generated by a server to a number of clients. The A/V

content and commands are received by the client and stored in respective buffers. When the buffers fill, or reach some other predetermined condition, an audio player

and a video player are launched within the viewer's computer, and A/V content can be

watched and heard while subsequent packets are being delivered. When viewers are to

interact with the broadcast program, the viewers' responses are sent to the broadcasting

server.

In practice, the number of clients receiving and/or participating in an interactive

broadcast is limited by many factors. Some of them are computer-specific resources

(such as random access memory (RAM), central processing unit (CPU) speed, etc.),

operating system-(OS) specific resources (e.g., WINDOWS NT has different limits than

Unix), and bandwidth and network congestion which can substantially impede the

quality and continuity of the server/client connection. Due to implementation specifics

of sockets under most operating systems, the upper limit for the number of concurrent

socket connections on a single machine is approximately 65,000 regardless of the other

factors that may reduce that number substantially. The broadcast system must,

however, be able to register and address the participants, broadcast to them, receive

interactive input from them and respond appropriately to the interactive input witi in

the limitations imposed.

The problems of bandwidth usage and network congestion are particularly

troubling in the case of sustained Internet-based connections such as those experienced

in live and taped broadcasts. Until quite recently, Internet-based communications have

consisted mainly of downloaded Web pages requiring only momentary contacts

between the server and client. Conventionally, the client contacts the desired server for the Web page through the client's Internet service provider ("ISP"). In providing the

communication channel for the client, the ISP, in turn, is typically connected to a high

speed, large bandwidth fine called a "backbone". Contact is made through the

backbone, either directly or through other backbones and/or servers, with the server

providing the desired Web page. Once the Web page is sent by the Web site's server, it

can disconnect from the network handling the request for the client, as can the client's

ISP once it receives the Web page.

Recently, private Internet- based networks have been formed to avoid delays

associated with the public Internet sector. These private networks typically connect

major ISP's, for example, so that communications between clients of the respective ISPs

do not experience the delays that are experienced when links must pass through the

public portion of the Internet.

"Co-location facilities" have arisen that form these private networks by providing

high-speed, large-bandwidth connections between the ISPs. In practice, the ISP pays a

fee to the backbone provider or co-location facility (collectively referred to herein as

"pipes"), which is generally proportional to the amount of traffic the ISP generates.

Stated another way, the ISP pays a fee proportional to bandwidth occupied.

SUMMARY

In accordance with a preferred embodiment, a decentralized network is provided

for the high-quality transmission of live or prerecorded interactive Internet- based

programs such as shows, classes, and meetings to a virtually unlimited number of clients any place in the world. The network can be implemented as, for example, a streaming

media broadcasting network with full interactivity capable of accessing a large world¬

wide audience (e.g., one million users) with a broadcast server requiring only a single Tl

line or the like.

In accordance with a preferred embodiment of the invention, at least one bi¬

directional repeater/aggregator communicates between a server and one or more clients

for ( 1 ) receiving the program content from a server and re broadcasting the content to a

plurality of clients, and (2) aggregating data from the plurality of clients and sending a

composite thereof to the server. Preferably, the server is programmed to fold the

composite input presented by each repeater/aggregator into a picture of the total

audience response.

The resulting increase in number of serviceable clients is arithmetic. If, for

example, each repeater/aggregator can service 10,000 clients, every added

repeater/aggregator can increase the potential audience by 10,000 witiiin substantially

less bandwidth than that required by a direct connection to the same number of

viewers. Thus, with a decentralized network, a content producer with three

repeater/aggregators can reach 30,000 viewers; a content producer with seven

repeater/aggregators can reach 70,000 users, etc., all witiiin the bandwidth typically

required to reach 10,000.

Preferably, the audio, video, and interactive content will travel the shortest

possible distance over the public Internet, ensuring a high-quality transmission. While

the placement of a server and one or more R/As at the upstream end of the program producer's Tl line may solve the operating system and hardware limitations on the

number of concurrent sockets, bandwidth would still be an issue. Preferably, the

network disclosed herein accordingly decentralizes the bandwidth required by putting

the R/As as close to the viewer as possible from a network topology standpoint. For

example, if a number of viewers on AOL are logged onto the program, the preferred

location for the R/A serving them is the same network segment as the modem pool at

AOL where those viewers dial into. The next (less preferred) location is on the AOL

network. The next (even less preferred) location is on a well- connected network that is

connected directly to AOL privately (i.e., not through a public Internet exchange,

which are known to be congested).

In accordance with a preferred embodiment of the invention, one or more bi¬

directional repeaters/aggregators may be located at the client's ISP, a single

transmission received at the ISP can be converted at the ISP's end to the multiple

transmissions needed by the ISP's clients who are receiving the broadcast. If, for

example, 1000 AOL subscribers are receiving the broadcast, the broadcasting server

need not transmit 1000 streams to that group of clients, but only a single stream which

is repeated 1000 times by the repeater/aggregator(s) within AOL's network, thus

saving substantial bandwidth usage between the broadcast server and the ISP network.

Similarly, the return channel may be aggregated prior to transmission so that

responses from the viewers can be sent as a single stream back to the broadcast server

rather than a plurality of individual streams, with attendant bandwidth savings as well.

Back channel responses can be aggregated for pre-determined lengths of time prior to transmission, or until a desired quantity of data has been accumulated, or some

combination of the two. Alternatively, other criteria can be used which make back

channel transmission more efficient and/or cost effective.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a block diagram schematic of an exemplary decentralized network for

transmitting interactive Internet- based programs constructed in accordance with an

exemplary embodiment of the invention.

FIG. 2 is a block diagram of an exemplary decentralized network suitable for

sustained live or taped Internet- based broadcasts, constructed in accordance with an

exemplary embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Preferred embodiments in application of the invention will now be described

with reference to FIG. 1. For illustration purposes only, this disclosure will describe the

production system in terms relevant to classroom and/or entertainment programming.

Unless the context indicates otherwise, the term "commentator" will be used to denote

the classroom instructor, the entertainment program's host and/or other persons being

viewed at the moment by the viewer; "client" will denote the viewer's computer system,

including hardware and software; "server" will denote the computer(s) (including

hardware and software) which deliver the program content to the client, and "viewer"

will refer to the person(s) at the client end of the system. Other embodiments may be realized and structural or logical changes may be made to the disclosed embodiments

without departing from the spirit or scope of the invention. Although the

embodiments are particularly described as applied to production systems in terms

relevant to classroom and/or entertainment programming, it should be readily apparent

that the invention may be embodied in any device or system having the same or similar

problems.

As illustrated in FIG. 1, an exemplary system constructed in accordance with an

exemplary embodiment of the invention is composed of a production server in the form

of audio/video server 10 for broadcasting content and information such as an

audio/video stream and commands to clients 16, 18, 20, 22, 24, 26. A plurality of

repeater/aggregators 12, 14 (each hereinafter, referred to as an "R/A" for brevity) are

coupled for bi-directional communication with the server 10, and receive the broadcast

program from the server. The R/As may be physically located anywhere in the world,

but are preferably geographically positioned to provide the shortest transmission path to

the clients they each serve.

The first R/A 12 is illustratively shown coupled for bi-directional

communication with three clients 16, 18, 20 while the second R/A 14 is illustratively

coupled for bi-directional communication with another three clients 22, 24, 26.

Although only two R/As have been illustrated for clarity, those skilled in the art will

recognize that any number (e.g., thousands) of R/As can be used. Likewise, only three clients have been illustrated for each R/A for clarity, but any number (e.g., thousands)

of clients can be coupled to each R/A in actual use.

Each R/A 12, 14 repeats the interactive content transmitted by the server 10.

Some or all of the content, may conveniently be partially or wholly pre-loaded into the

R/As prior to actual broadcast to the clients.

Each R/A 12, 14 additionally collects and aggregates feedback from the viewers

with whom it is communicating so that a composite user input can be passed along to

the producer's register. If a multiple -choice exam question is launched from the server,

for example, having three possible answers "A," "B," and "C," each R/A aggregates

the answers received from the clients with which it is communicating, and reports back

to the register the number (or percentage of) clients returning "A," returning "B," and

returning "C" answers.

By aggregating the data, information can be returned to the register utilizing less

bandwidth than would be required by the return of individual responses from each

client. Further, each R/A can be programmed to retain the answers from each specific

client, or other non-priority data, for later transmission to the register at a time when

bandwidth is available or the time more convenient. Moreover, any of a variety of

reports can be generated from the raw data accumulated in the R/As. For example,

statistical analyses can be performed, trends and correlations analyzed, etc. The reports

can be generated at the R/As, or some or all the raw data can later be transmitted to

the register or any other location for a global analysis. The data from the R/As to the register or other receiving location, can accordingly be sent continuously or the data

can be batch-processed and forwarded in batches.

In exemplary operation, a viewer may log into the system via an R/A which, in

turn, registers the viewer with the server 10. The client may be registered using any

known identification system, such as by both the socket number at which the client's

R/A is coupled to the server, as well as by the R/As socket number at which the client

is connected. The system is thereby flexible enough to enable the program's A/V

content and/or producer information such as selected commands to be downloaded by

one or more specific clients at one or more specific R/As by tagging the

content/command packet with the appropriate addresses. Thus, producer information

can be sent to viewers in response to specific inputs, the presence of certain keywords in,

for example, a talk-back or chat statement, or in response to any other criteria which the

producer or broadcaster wishes to use. Producer commands thus enable a variety of

functions to be performed such as chat (between two or more clients), poll of users, etc.

Bandwidth is also saved by combining the interactive feedback from all clients at

each R/A prior to transmission to the server. Transmitting combined feedback saves

the protocol overhead which would otherwise arise from generating and processing

separately headered packets from directly connected clients.

Bandwidth can also be saved by using each R/A as a filter to avoid or delay

transmission of irrelevant (or non-priority) data to the server. For example, the

unnecessary transmission to the server, and processing by the server, of each and every

bid in an Internet-based auction is avoided when each R/A only transmits the highest bid cast by the clients to which it is connected. Bids which are less than the highest are

irrelevant. Accordingly, only the highest of the bids received from the clients within

each predefined window are forwarded to the server.

Preferably, clients connect to the producer's register, which assigns the client to

the appropriate R/A, to which the client connects or is connected. Each client's user

logs on by providing his/her username and password. The register to which the user is

connected confirms that the user is registered. If the user is not registered, a

registration procedure can be launched.

Once registration is completed or confirmed, the user receives files which will be

used as the program is viewed. These files may, for example, be plug-ins, players, slides,

interface artwork, and software updates. Preferably, the files have previously been

loaded into a plurality of distribution servers 28, 30 for transmission to the client

through the R/As after log-in. In practice, it is desirable to have one or more ratios of

R/As to each distribution server (e.g., one distribution server for every five R/As). The

server is thereby free to perform other tasks, while many more clients can be serviced

than by the server alone.

Clients may be assigned to a particular R/A based upon parameters deemed

important to the particular broadcast. For example, it may be desirable to assign clients

to R/As that are geographically closest to them. This may, however, result in an

uneven assignment of clients among the available R/As, which load some R/As while

utilizing others inefficiently. Alternatively, users may be assigned to R/As in a "round

robin" manner, whereby users are evenly distributed among the R/As as they log in. Additional servers can be employed if desirable. For example, archive servers are

preferably employed to store archived broadcasts for future, on-demand access by

participants. When receiving and evaluating audience response, it may also be desirable

to assign specific tasks to individual servers. For example, a news programmer might

want to pay special attention to the incoming Talk Back messages, and so would assign

a separate server to handle only Talk Back. Meanwhile, another operator at another

server could tend exclusively to Chat searches, a third operator at a third server could

monitor Poll results, etc.

Incoming data can then be parsed and searched so that an operator can control

the quantity, by controlling the quality, of audience feedback. The program director

will accordingly only receive that input which will most benefit the show.

The network described herein may additionally include monitoring capabilities

to maintain the high levels of performance for its producers. Various "status" systems

monitor the network continuously, redirecting traffic as required by the network,

requiring various "proxy" servers to act as intermediaries in checking producers' and

participants' licenses and registration permissions, handling updates and directing traffic

to the appropriate repeater/aggregators based on geographic location.

The system register permits the producer to register the show, and gather

general and specific demographic information from an aggregated database. The

register creates the aggregated database by tracking all the activity that occurs during

presentation of the program, and organizing the data by producers and participants. All

viewer data is preferably logged in appropriate tables from which reports can subsequently be generated. Viewers connect to the Register to search for show and

schedule information.

The foregoing network may be implemented in accordance with a preferred

embodiment of the invention for sustained live or taped Internet- based broadcasts

which reduces bandwidth use within a pipe.

In the illustrated embodiment, a control provider such as broadcast server 110 is

connected to a pipe 112 to which a plurality of ISPs 114, 116, 118 have connections

available. The ISPs are shown having clients 114a-c, 116a-c and 118a-c, respectively,

who are part of the audience receiving the broadcast from server 110. In practice, there

will be many more than the illustrated three ISPs and three clients/ISP. One or more

repeaters/aggregators 120 are placed in the ISP network as previously described so that

the incoming broadcast stream is duplicated as many times as needed to serve the ISP's

clients logged onto the broadcast. Since only a single stream travels through the pipe to

the ISP, bandwidth use is substantially reduced, as are use-related fees charged to the

ISP by the pipe's owner. When the ISP's clients respond interactively to the broadcast,

their messages are aggregated and sent as a single stream through the pipe or,

alternatively, reduced to the minimum number of packets and/or streams capable of

carrying the data, resulting in greater efficiencies and less bandwidth use once again.

In accordance with a preferred embodiment of the invention, one or more

processor- based systems are used to implement the modules described or apparent from

the description herein (e.g., server 10, distribution servers 28, 30, R/As 12, 14, and

clients 16, 18, 20, 22, 24, 26) and to perform the functionality described (or inherent) herein. For each such system, one or more processors (e.g., central processing unit

(CPU)) are provided for execution of one or more computer programs stored on any

(one or more) known recording mediums. The processor(s) perform, control, or at

least inform the various processing steps performed by the system in sending and

retrieving data to and from at least one user interface and/or network. A user interface

may be connected directly to a bus or remotely connected through a network (e.g.,

Internet). The network represents (wired or wireless) connection of two or more

devices, whether directly or indirectly connected (e.g., directly coupling through cable,

indirect coupling through one or more hubs or servers, whether the network is local to

the processor-based system, geographically remote from system, or a distributed

combination of local/remote network components).

Preferably, one or more of the modules depicted in FIG. 1 and/or FIG. 2 are

coupled (directly or indirectly) to one or more database structures for use in supplying

storage functionality for the modules in accordance with the operations described (or

inherent) herein (e.g., storage of pre-loaded content in R/As, operating as the system

or producer's register, etc.). The database structures can take any form from an

individual floppy disk drive, hard disk drive, CD-ROM, redundant array of independent

devices (RAID) system, to a network of storage devices. As is well known in the art, the

database structures may be physically connected within the same location, or have one

or more structures remotely located in different locations. Each module may have

dedicated or shared access to one or more database structures locally or remotely

located from the module. The preferred embodiments described herein relate to Internet- based program

production systems capable of producing live interactive classroom instruction, virtual

"meeting halls," live interactive entertainment-type shows, pre-recorded interactive

programs, and the like. It should be apparent, however, that many modifications (e.g.,

structural, logical, etc.) to the embodiments and implementations of the invention can

be made without departing from the spirit or scope of the invention. The type of

program content, for example, is unlimited and it is foreseeable that the content can be

at least the same as an interactive version of anything currently found on television or in

the cinema. Moreover, any known network or communication system (e.g., intranet,

extranet, local area network (LAN), wide area network (WAN), BBS, instant messaging

network, etc.) may be used in lieu of or in combination with the Internet, as used

herein.

While the exemplary embodiments disclosed herein depict a broadcast system

utilizing a computer-based client application, it should be readily apparent that the

invention may be implemented utilizing any type of equivalent client apparatus (e.g.,

network/stand-alone computers, personal digital assistants (PDAs), WebTV (or other

Internet-only) terminals, set-top boxes, cellular/PCS phones, screenphones, pagers,

kiosks, thin-client, or other known (wired or wireless) communication devices)

executing one or more computer programs (e.g., specialized client software, standard

Web browser software, etc.) to permit communication with a host service. Alternative

embodiments further include both centralized and decentralized distribution of

programs or content. The components described herein may be one or more hardware, software, or

hybrid components residing in (or distributed among) one or more local or remote

computer systems. Although the components are shown or described as physically

separated components, it should be readily apparent that individual components may be

omitted, combined, or further separated into a variety of different components, sharing

different resources (including processing units, memory, clock devices, software

routines, etc.) as required for the particular implementation of the embodiments

disclosed herein. Indeed, even a single general purpose computer executing a computer

program stored on a recording medium to produce the functionality referred to herein

may be utilized to implement one or more of the components in the illustrated

embodiments. Any user interface devices utilized may be implemented as a graphical

user interface (GUI) containing a display or the like, or may be a link to other user

input/output devices known in the art.

In addition, memory units described herein may be any one or more of the

known storage devices (e.g., Random Access Memory (RAM), Read Only Memory

(ROM), hard disk drive (HDD), floppy drive, zip drive, compact disk-ROM, DVD,

bubble memory, etc.), and may also be one or more memory devices embedded within

a processor or CPU, or shared with one or more of the other components. The

computer programs or algorithms described (or inherent) herein may easily be

configured as one or more hardware components, and the hardware components shown

may easily be configured as one or more software components without departing from the invention. Accordingly, the invention is not limited by the description or drawing

of this disclosure, but only by the claims appended hereto.

What is claimed is:

Claims

1. A broadcast system for broadcasting content and broadcaster information to

users during a program, the system comprising:

a broadcaster generating content and related broadcaster information;

at least one repeater/aggregator, wherein each repeater/aggregator receives the

content and the broadcaster information from said broadcaster through a

communication pipe and broadcasts the content and broadcaster information to at least

one user; and

wherein each repeater/aggregator receives feedback information from the at

least one user, aggregates the feedback information, and outputs the aggregated

feedback information to the broadcaster through the communication pipe.

2. The system of claim 1 further comprising a server, said server producing and

outputting over the communication pipe the content and broadcaster information

generated by said broadcaster to said at least one repeater/aggregator, and receiving the

aggregated feedback information from said at least one repeater/aggregator during the

program.

3. The system of claim 1 further comprising at least one interactive client

component associated with at least one user, each client component receiving the

content and broadcaster information from an associated repeater/aggregator and

presenting the content and broadcaster information to the user, each client component

receiving feedback information from the user and transmitting it to its associated

repeater/aggregator.

4. The system of claim 3, wherein the broadcaster information includes at least

one command to be executed on said at least one client component.

5. The system of claim 4, wherein the command comprises a chat function to be

performed between at least two client components associated with at least two users.

6. The system of claim 4, wherein the command comprises a poll function to be

performed by at least one client component associated with at least one user.

7. The system of claim 4, wherein the command comprises a talk-back function

to be performed by at least one client component associated with at least one user.

8. The system of claim 1, wherein each repeater/aggregator filters the feedback

information prior to sending the aggregated feedback information to said broadcaster.

9. The system of claim 1, wherein said at least one repeater/aggregator is a

plurality of repeater/aggregators coupled to the pipe, wherein each repeater/aggregator

is connected to the users via the Internet through an Internet Service provider (ISP).

10. The system of claim 1, wherein the communication pipe is a private

network.

11. A production system comprising:

a production server, said production server producing and outputting a program

and inputting information from viewers during the production of the program; a plurality of interactive clients each respectively associated with at least one

viewer, each client receiving the program and presenting it to a viewer, each client

receiving information from a viewer; and

at least one repeater/aggregator, each repeater/aggregator connected to said

production server by a communication pipe, each repeater/aggregator being further

connected to and associated with at least one client, each repeater/aggregator receiving

the program from the pipe and distributing it to its associated client, each

repeater/aggregator inputting information from its associated client, processing the

information and distributing it to said production server using the pipe.

12. The system of claim 11, wherein the program comprises audio and visual

information.

13. The system of claim 11, wherein the user information comprises feedback

information concerning the program.

14. The system of claim 11, wherein said production server further outputs to

each repeater/aggregator producer information to be executed by at least one client.

15. The system of claim 14, wherein the producer information comprises

commands to be performed by at least one client associated with at least one viewer.

16. The system of claim 11 further comprising at least one distribution server

associated with and connected to at least one repeater/aggregator, each distribution

server being further connected to said production server, each distribution server transmitting files associated with said program to its respective repeater/aggregator for

use by the viewers during the program.

17. The system of claim 16, wherein the files are selected from the group

consisting of plug-ins, players, slides, artwork and software updates.

18. The system of claim 11, wherein the communication pipe is an Internet

backbone.

19. A method of producing a program to be broadcast over a network to a

plurality of users, the method comprising the steps of:

providing the program to a plurality of repeater/aggregators over a private

communication pipe;

distributing the program from each repeater/aggregator to the plurality of users

over the public Internet;

receiving feedback information over the communication pipe from at least one of

the plurality of users through an associated one of the plurality of repeater/aggregators;

aggregating the feedback information; and

incorporating the aggregated feedback into the program.

20. The method of claim 19, further comprising the step of screening content

of the feedback information prior to said aggregating step. wherein at least one of the plurality of repeater/aggregators is located at each of

a plurality of Internet Service Providers (ISPs) connecting the users to the public

Internet, and wherein the plurality of ISPs are coupled to the communication pipe.