Multicasting method and apparatus

ES 2 534 293 T3

DESCRIPTION

Multicast method and apparatus

1. Field of the invention

This document relates to a method and apparatus for providing audio and / or visual communication services, in real time, to a multiplicity of identifiable users on a communication network, such as the Internet. In a preferred embodiment, the invention monitors which users are receiving signals on which of a plurality of channels and modifies the content of at least some signals in response thereto. A particular application is to provide multichannel radio or television-like services with commercial programming content tailored according to the identity of the individual user.

two. Background of the invention

Systems such as the Internet are typically point-to-point (or unicast) systems in which a message is converted into a series of directed packets that are routed from a source node through a plurality of routers to a destination node. In most communication protocols the packet includes a header that contains the addresses of the source and destination nodes as well as a sequence number that specifies the order of the packet in the message.

In general, these systems do not have the ability to broadcast a message from one source node to all other nodes in the network because such capacity is rarely widely used and could easily overload the network. However, there are situations where it is desirable for a node to communicate with some subset of all nodes. For example, the ability to conduct multi-user conferencing analogous to those found in the public telephone system and broadcast to a limited number of nodes are of considerable interest to users of packet-switched networks. To meet these demands, packets destined for various receivers have been encapsulated in a unicast packet and sent from one source to a point in a network where the packets have been replicated and directed to all desired receivers. This technique is known as IP Multicast Backbone (IP Multicast Trunk Network) or MBONE. More recently, routers have become available that can route the multicast addresses (class D addresses) provided in communication protocols such as TCP / IP and UDP / IP. A multicast address is essentially an address for a group of recipient computers that have indicated their desire to participate in that group. Thus, a multicast packet can be routed from a source node through a plurality of multicast routers (or m-router) to one or more multicast packet receiver devices. From there the packet is distributed to all receiving computers that are members of the multicast group.

These techniques have been used to provide audio and video Internet conferencing as well as radio-like broadcasts to stakeholder groups. See, for example, K. Savetz et al. MBONE Multicasting Tomorrow's Internet (IDG Books Worldwide Inc., 1996).

Additional details regarding technical aspects of multicast can be found in Requests for Comments (RFC) 1112 and 1458 for Internet documents reproduced in Appendices A and B of Savetz's book and in DP Brutaman et al., " MBONE provides Audio and Video Across the Internet ”, IEEE Computer, Vol. 27, No. 4, pp. 30-36 (April 1994). A further example can be found in WO95 / 15658 (Discovery Communications Inc.). Document WO95 / 15658 relates to a network manager that monitors and manages cable headend components and set-top terminals in a television delivery system. Another example can be found in EP 0617563, September 28, 1994 (1994-09-28), which describes the data processing system for providing video-on-demand information for a subscriber request, for files of very large video data. The system allows a quick response to requests from network subscribers, regardless of the number of video files offered for selection.

3. Summary of the invention

The present invention relates to a method and a system for measuring real-time streaming media for commercial purposes according to the appended claims.

The present invention is of a scalable architecture for supplying information in real time through a communication network. Embedded within the architecture there is a control mechanism that provides the management and administration of the users who have to receive the information in real time.

In the preferred embodiment, the information being supplied is high quality audio. However, it could also be video, graphics, text or any other type of information that can be transmitted over a digital network. This information is supplied in real time to any number of widely distributed users. It is in real time because for a given information channel, approximately the same information is being sent

ES 2 534 293 T3 at approximately the same time to all those who are enabled to receive the information.

Preferably, multiple channels of information are available simultaneously for delivery to users, each channel consisting of an independent continuous transmission of information. A user chooses to tune or untune a particular channel, but does not choose the time in which the channel distributes its information. Advantageously, interactive (bi-directional) information can be incorporated into the system, multiple streams of information can be integrated for delivery to a user, and certain parts of the information being delivered can be tailored to the individual user.

Four. Brief description of the drawings

These and other objects, features and advantages of the present invention will be more readily apparent from the following Detailed Description of a Preferred Embodiment of the present invention in which Fig. 1 is a schematic diagram representing an overview of the system of the present invention;

Fig. 2 is a schematic diagram representing the network control center for the system of Fig. 1;

Fig. 3 is a schematic diagram depicting a unicast distribution structure;

Fig. 4 is a schematic diagram depicting a multicast distribution structure;

Fig. 5 is a schematic diagram representing the connection between the media server and the user in the system of Fig. 1;

Figs. 6-17 are timing diagrams depicting various aspects of the operation of the system of Fig. 1; and Figs. 18 and 19 represent the user interface for control of the system of Fig. 1.

Where the same reference numbers appear in multiple drawings, the numbers refer to the same or corresponding structure in said drawings.

5. Detailed description of the preferred embodiment

With reference to Fig. 1, the system of the present invention comprises a Network Control Center 10, a plurality of Primary Servers 20, Media Servers 30, Users 40 and Control Servers 50, and an Administration Server 60. Servers are interconnected by a communication network, which in the preferred embodiment is the global connected network known as the Internet. The Network Control Center 10 is the source of the information that is being distributed. It receives audio provided from a satellite, over the air or in other ways and processes this information for delivery over the network in multiple information channels. This processing optionally consists of the registration of information for a future broadcast and the dynamically insertion of paid commercial advertising.

For each information channel, there is a Primary Server 20 that receives the information stream from the Network Control Center 10 and compresses the information stream to allow more efficient transmission. The Primary Servers 20 are directly connected to the network.

Primary Servers send information over the network to a number of Media Servers 30. There may be a large number of Media Servers and in fact there are many levels of Media Servers. For example, a Media Server that receives a stream of information from a Primary Server may send that stream over the network to another Media Server which then sends it to a User 40. This multi-level hierarchical structure is described in more detail below.

The topology of the Internet dictates the ideal placement of Media Servers, the deployment of each Media Server, and the number of tiers of Media Servers between the Primary Server and the Users. For example, Media Servers that are provided from a Primary Server could be placed at primary points of presence (POP) of each of the large Internet service servers. These Media Servers could also be placed near clouds that serve as high-bandwidth exchange points between the main carriers. Similarly, Media Servers serving users could be placed on or close to networks that have a large number of subscribers to minimize the distance and number of continuous data streams being transmitted.

The Control Servers 50 are responsible for keeping track of which Users are listening to which channels and for directing the Media Servers to start and stop the continuous transmissions of information to those Users. The Control Servers are also responsible for handling other interactions between the various components of the system as will be described in more detail below. Each Control Server is responsible for managing a group of Media Servers; and each Media Server is managed by a single Control Server at any given time. As a result, the Control Servers are distributed over the Internet, preferably located close to the Media Servers.

ES 2 534 293 T3

The Administration Server 60 is responsible for the registration of new Users, authentication of Users who wish to register in the system, and maintenance of audit logs on how many Users are listening to which channels and at what times. Keeping audit trails and collecting statistics are critical features for monitoring the delivery of paid commercial messages as well as for other purposes. For example, for the purposes of evaluating copyrights, audit logs may record the number of listeners for each music or video selection that is distributed by the system. Another application is to determine the percentage of listeners who are interested in listening to a particular musical selection to determine how many listen to the entire selection and how many turn it off.

The system of the present invention can be considered an integrated distribution architecture with a control architecture. The distribution architecture handles the provision of scalable information in real time to any number of Users in a packet-switched network, such as the Internet. The control architecture represents a second system that is scalable and integrated with the distribution architecture for the management and administration of the supply of this information.

The remainder of this description is divided into three sections. The distribution architecture will be described in more detail in the next section. Following that, the control architecture will be described. The third section will illustrate the User interface.

I. Distribution architecture

The distribution architecture provides the provision of information in real time to any number of Users distributed through a network. As will be described in detail below, the distribution architecture is scalable to allow efficient delivery of multiple simultaneous information channels in real time to a large number of Users.

In the preferred embodiment, the information being distributed consists of high-quality audio in addition to other information. It should be appreciated that the basic architecture and other general principles set forth herein would also apply to the provision of video, graphics, text, or any other type of information that can be delivered over a digital network. Furthermore, it should be appreciated that a continuous transmission of information may consist of audio with supplementary information such as text and graphic images and control commands for software running on the User's computer.

The source of information in the preferred embodiment is the Network Control Center 10, depicted in the schematic diagram of Fig. 2. Control Centers of this type of design are available from Broadcast Electronics, Inc. and are similar to those of that would be found in a conventional radio station serving multiple frequencies.

With reference to Fig. 2, the incoming signal can be received in various ways such as from a satellite, through an over-the-air broadcast, cable, or a hard drive. It is then processed by Receiver / Decoder 110, which decodes the signal and provides a stream of incoming audio. The Routing Switch 120 is responsible for routing the incoming audio provided from the Receiver to either the Delayed Registration Workstation 140 or to one of the Playback / Control Workstations 130. The real-time insertion of paid commercial advertising takes place at the Playback / Control Workstations and the resulting integrated audio streaming is delivered to the Primary Servers. The Delayed Registration Workstation is responsible for registering an incoming broadcast so that it can be played back at a later time.

Supervisory Workstation 150 is responsible for the management and control of Playback / Control Workstations, Delayed Registration Workstations, and other computers that may be connected to the local area network within the Control Center. Network Control. The Production Workstation 160 and the AudioVAULT-NFS Server 170 are used to manipulate audio samples, such as commercial messages for use by the Playback / Control Workstations. The audio being supplied may consist of paid television or radio programs, as they would be received via satellite or cable and supplied as described above. These can be delivered live and / or replayed at a later time. It is also possible that the provision of information, such as music, takes place from information that is all stored locally such as on a hard disk. A new playlist and its associated music data can be downloaded periodically to update the channel. Additionally, it is possible to supply commercially free programming, for example public service advertising or specific tagged music.

In the preferred embodiment the Primary Servers are responsible for compression of the radio stream using an advanced perceptual technique developed and licensed from AT&T Corp. and Lucent Technologies, Inc. band available. Advantageously, two bit rates are available, a first rate of approximately 20 kbps and a second rate of approximately 56 kbps. Using the perceptual technique, the quality of the first rate is similar to an FM

ES 2 534 293 T3 monaural (with a sampling rate of approximately 22,000 16-bit samples per second) and the second rate is close to stereo CD quality (with a sampling rate of approximately 32,000 16-bit stereo samples each second). These signals at the two different bit rates comprise two different audio channels and therefore require two different compression processes.

The computational requirements for compressing a real-time audio stream using techniques such as advanced perceptual technique are approximately 100% of a 200 MHz Pentium-Pro computer and the decompression computational requirements for a streaming audio in real time is approximately 30% of a 75 MHz Pentium computer. Future improvements and / or changes in the algorithm could significantly change these requirements. At present, a dedicated computer is required within the Primary Server to compress the audio stream. The decompression process takes place on the User's end computers and preferably only a portion of the computational requirements of the computers would be used, allowing the computers to be used for other tasks while they are processing the audio stream.

It is important to appreciate that the compression and decompression techniques employed by the present invention are not critical to the overall operation of the system and the benefits derived from it could be obtained with other compression methodologies. Advantageously, the identity of the compression technique used can be encoded within the audio stream in the packet header. This makes it possible for the receiver to identify the nature of the decompression algorithm to use; and thereby enables the computer within the Primary Server to select an optimal compression algorithm depending on the nature of the audio stream to be compressed.

The rest of the distribution architecture comprises the multilevel hierarchy of data transmission originating from Primary Server 20 and ending at Users 40 as shown in Fig. 3. In the preferred embodiment, the network is the global Internet. connected. It may also include private networks that connect to the Internet and that could be implemented in any packet-switched, cable-modem-based or cable-satellite-based network system. It is possible that certain links within the global system, for example, the link between the Primary Server and the first level of Media Servers, are private data links that carry only data associated with this system. This could also be true for other data transmission projects in the distribution architecture. The User receiving the information can preferably be anyone who has access to the Internet with sufficient bandwidth to receive the resulting audio data.

It should be appreciated that the distribution architecture of the present invention provides scalability. Using such a structure, any number of Users can be adapted, and as widely distributed as necessary. In the preferred embodiment, the deployment of each level of Media Servers (given the state of technology today) is of the order of ten, but the same structure could be applied with other deployments. The location and deployment of the Media Servers is chosen to minimize the bandwidth consumed by the global network.

The flow of information from Primary Server 20 through the network to User 40 is based on the provision of a continuous sequence of individual pieces of information, or packets. Thus the distribution architecture implements a way of delivering multicast packets to a group. The group in this case is a set of all the users who are listening to a given channel at a given time. Group membership is dynamic, Users can start and stop listening on a channel at any time.

Multicast can be implemented in various ways, and any or all of them can be used in the present invention. In the preferred embodiment, the Media Servers receive unicast packet streams and then duplicate these streams into more unicast streams to other Media Servers that are in the group that belongs to that stream. The lowest level of Media Servers use hardware broadcast, multicast and / or unicast to reach all Users served by that Media Server.

If the Media Server connects directly to the same physical network as the User, hardware broadcast or multicast can be used to transmit streaming packets to all currently listening Users on that network. In this case Media Servers can translate incoming packets into broadcast or multicast packets for transmission on the local network. Only one packet is transmitted at a time on the local network, and any computer directly connected to the local network can receive that packet. Hardware multicast is built into most networks and is lower in overall overhead than hardware broadcast since computers not interested in a transmission do not have to process packets. In the event that a Media Server is serving a User who is not on the same physical network, a unicast transmission is used to reach that User, a separate packet transmission is required for each User connected in that way. In the preferred embodiment, the assignment of Users to Media Servers is performed using control transactions between User 40, Control Servers 50, and Administration Server 60. The system will be more fully described in the section below.

ES 2 534 293 T3

Multicast can also be implemented within the Internet at the IP level using class D IP addresses and the IGMP group control protocol. Fig. 4 illustrates how the multi-level hierarchical distribution architecture would work using multicast provisioning over IP. Under this system, a packet with a multicast address is transmitted for a destination and each router maintains the group membership list for each interface that is connected to it and will send packets through the Internet to other routers so that all users within the global group eventually receive a copy of the package. Unless and until all routers within the Internet understand multicast in this way, it is necessary to supplement them with IP tunneling in which multicast packets are encapsulated in unicast packets and routed by unicast routers to a multicast router. The present invention can and will be able to take advantage of IP multicast when it becomes widely available. Each feed would have its own class D address and then the Media Server would simply transmit packets using the appropriate IP destination address. In this case, no Media Server would be used since this function would be implemented by the routers in use to store and send other IP packets.

Thus it can be appreciated that the implementation of the multicast delivery structure can be implemented using a combination of IP unicast, IP multicast and hardware multicast or any other system that provides a distributed delivery of information to a specific group of destinations. It is expected that a special relationship will be established with Internet providers so that the provision of streaming audio can take place with guaranteed bandwidth in the most efficient way possible.

In the preferred embodiment, the information packets for distribution use the UDP protocol under IP instead of the TCP protocol. TCP provides a reliable streaming supply but at the cost of retransmissions and delays. For real-time information, it is usually more appropriate to use UDP since information is time critical and low latency is more important than reliability. Since TCP is a point-to-point protocol, it is incompatible with IP multicast. However, TCP could be used on the IP unicast links between Media Servers which are expected to have very low packet loss. To handle bad, lost, duplicate, and corrupted packets, UDP packets are serialized.

In the preferred embodiment the size of the audio packets being transmitted is variable and can change from packet to packet. It is expected that when using compression schemes that have a fixed bit rate, such as ADPCM, all packets for that stream would be the same size. Alternatively when using a variable bit rate compression algorithm, the packet size is expected to vary so that approximately the same amount of time is set for each sample. For example, if each packet corresponds to a 20 millisecond speech segment, this could correspond to 100 bytes during one time period and 200 bytes during another. Additionally, the media server may choose to dynamically vary the packet size to accommodate changes in network conditions.

Since the playback of the resulting audio information is sensitive to packet loss and network congestion, the software running on multiple computers that make up this system monitors and adapts to the developing situation in the best way possible. possible. This may involve the use of different Media Servers and / or a decrease in the User data rate. For example, similar to negotiating the quality of the dynamic analog signal present in many analog radio receivers, the user software may request a lower bit rate until the situation is improved. Also, note that the audio information being supplied to the User is preferably interleaved so that a contiguous segment of audio streaming is distributed for transmission over multiple packets. As a result, the loss of a packet is spread across multiple audio samples and causes minimal audio degradation. Advantageously, a small degree of redundancy can be incorporated within the audio stream for better protection against packet loss.

Preferably, there are two bit rate options available to the user for the audio delivery. These are approximately 20 kbps for standard audio and approximately 56 kbps for high-quality audio. Thus, a 28.8 kbps modem connection over an analog telephone line is sufficient for listening to standard audio broadcasts. For listening to high quality audio, an ISDN Internet connection is required, or some other connection with a bandwidth greater than 56 kbps. It should be appreciated that higher bandwidths are currently being made available to End Users. In particular, the use of cable modems and residential fiber networks are improving the bandwidths available to Users and thus making broadcasts with higher bit rates more practical.

In addition to the content of the audio channel being supplied, it is also possible to supply out-of-band information in the sidebar such as graphics, images and text. This side information is synchronized with the audio channel. This may involve only small increases in bandwidth requirements, such as 1-2 kbps. For example a music program could supply images of an album cover, the text of song lyrics, or URLs for use by an Internet browser. The user can preferably choose to have the side information displayed automatically or to be hidden. It is also possible to incorporate a two-way interaction within the system, such as, for example, that Users can participate in a global conversation session during the audio broadcast. These and other details are explained in more detail at

ES 2 534 293 T3 below under the description of the User interface.

The provision of paid commercial advertising information is an important aspect of the present invention. Advertising can be incorporated into the audio stream within the Network Control Center as described above. It can also be incorporated into streaming audio at the User level, or somewhere in between in the distribution architecture. In addition, the sidebar information explained above may also include advertising content. Fig. 5 illustrates the provision to the user of two separate streams 32, 34 of packets, one of which can be used for advertising. In this case, the insertion of the continuous transmission of commercial advertising within the non-commercial transmission takes place on the User's computer. Fig. 5 it also illustrates a continuous transmission 36 of packets identifying the User of the system. This allows the system to monitor which Users are listening to which channels and also allows the system to vary, for example, the advertising content delivered to a User.

An advantage of this alternative is to allow targeted commercial provisioning based on the individual User. That is, an individual User would receive the primary audio provision plus a stream of particular advertising unique to their demographic. Note that ad streaming is typically lower in overall bit rate and generally does not require real-time delivery, thus decreasing the overall load on the network. For example, the advertising stream could be provided to the User in advance on regular schedule, stored in a buffer on the User's computer, and inserted into the regular schedule stream upon receipt of an embedded cue signal. continuous transmission of regular programming. Thus, a substantial number of target groups, perhaps 10 or 100 or even more could be accommodated without an impractical increase in network load.

II. Control Architecture

The control architecture described in this section is responsible for the management and administration of the Users who are receiving the information that is being supplied through the distribution architecture described in the previous section. The control architecture handles new User registrations, User connection, start and stop of streaming audio and monitoring of ongoing transmissions. The control architecture is scalable as is the distribution architecture so that any number of Users can be managed.

This section describes the control protocol, which is made up of the form and sequence of control messages that are exchanged between Users, Control Servers, Media Servers, Primary Servers and the Administration Server. These messages are in the form of objects, which have specific data formats. Objects are preferably exchanged using the TCP protocol although other options are possible. The following describes the sequence of objects that are passed between the various computers and details of the internal structure of each object.

The main objects used in the present embodiment of the invention are set forth in Table 1. For each object, Table 1 provides a brief description of its function, the identification of the names of the fields in the object, their types, and a brief description of your role.

___________________________________________ TABLE 1___________________________________________ Channel Activation Object

Contains information used for channel activation / deactivation. It is sent to the Primary and Media Servers to tell them to transport or stop transporting a specific channel. The Media Servers get the channel from another server in the system hierarchy and the Primary Servers get and encode the provision from the actual input source.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Moniker</td><td>Alias ​​Object</td><td>channel identifier one</td>

<td>Get active</td><td>Whole</td><td>action indicator (on / off)</td>

<td>CompressType</td><td>Whole</td><td>type of compression to use</td>

<td>Host</td><td>Accommodation object</td><td>canal-led accommodation</td>

Canal Guide Object

Contains analytical and descriptive information for a requested section that is uniquely identified by an alias. It is normally the replica of a Channel Guide Request object

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Type</td><td>Whole</td><td>type of content</td>

<td>Result</td><td></td><td>the data of the content itself</td>

ES 2 534 293 T3

Channel Guide Request Object

Transmits a request for analytical and descriptive information about a section identified _______ uniquely through the Alias ​​content. The answer is in the form of a Canal Guide object.

Field name Field type Comments

Token Security Key Object inherited from base class

Type Integer content type

Moniker Alias ​​Object Unique Identifier

Accommodation Object

It encapsulates the attributes of a networked computer related to the operation or services that it offers or requests.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Hostname</td><td>Chain</td><td>computer name and domain</td>

<td>PortNumber</td><td>Whole</td><td>port number for the service</td>

<td>DisplayName</td><td>Chain</td><td>friendly name of the computer</td>

Connection Information Object _______ Encapsulates the name and cable word by which a User is known to the system.

Field name Field type Comments

Token Security Key Object

Login Username string to connect to the system

Password String password of the User in the system (possibly encrypted)

Media Control Interface Request Object (MCI)

It encapsulates a multimedia control command, such as play and stop, and any ________ extra information that may be necessary to perform the requested service ._______________________

Field name Field type Comments

Token Security Key Object

Command Integer multimedia command

String String extra information specific to the command

Alias ​​Object

An alias encapsulates the name of an object or process with the intelligence necessary to work with that name. In other words, it provides naming and merging services. The alias object is used in the system for a unique identification of various components, parts, or features, such as a channel, a directory, or a computer list.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>ID</td><td>Chain</td><td>unique string identifier</td>

<td>DisplayName</td><td>Chain</td><td>User-readable name</td>

Ping object

Ping is the name given to the operation "Are you alive?" useful in determining whether a specific computer is up and running. This object is used in the system when a server has to be queried about its operational status. You can also provide ________time information for statistical purposes and quality of service evaluations .______________________

Field name Field type Comments

Token Security Key Object

Date Date system date

Time Time system time

Protocol list object

Encapsulates a general-purpose collection object.

Field name

Token

Tyfie

Field type

Integer Security Key Object

Remarks list of object types

ES 2 534 293 T3

<td colspan="3">Result Message Object It acts as an acknowledgment for a successfully transported requested service that produces or reports errors that occur in the system during a client / server transaction.</td>

<td>Token field name Code Message</td><td>Field type Integer Security Key Object Chain</td><td>Observations result code message corresponding to the code</td>

<td colspan="3"></td>

<td colspan="2">Security Key Object Contains the authorization key for a transaction. perform any service.</td><td>The key must be validated before it is</td>

<td>Field name ID</td><td>Field type Chain</td><td>Observations Transaction ID / Authorization Key</td>

Server Activation Object

Contains information used in the server activation / deactivation process. Used for announcement as well as control purposes (for example, a server can notify the administration database that it is now up or a server can be instructed to manage ________ some other) ._____________________________________ ________________________________________________________

Field name Field type Comments

Token Security Key Object

Activate Integer action indicator (on / off)

Manage Integer control indicator (manage / associate)

Type Integer type of server

Host Accommodation object accommodation to be controlled

Server List Request Object

Encapsulates the request for a list of available server resources for an identified service _______ (for example, a request for a list of Control Servers for a specified channel) ._______ Field name Field type Comments

Token Security Key Object

Type Integer type of service

Moniker Alias ​​Object Unique Content / Channel Identifier

Host Object of Accommodation local accommodation information

Statistics Object

Contains system-related information that can be used for load balancing algorithms and for statistical purposes.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Load</td><td>Whole</td><td>system load</td>

<td>Threads</td><td>Whole</td><td>number of running threads</td>

<td>Users</td><td>Whole</td><td>number of users being served</td>

<td>Uptime</td><td>Whole</td><td>amount of running time</td>

<td>NumberManaged</td><td>Whole</td><td>number of managed servers</td>

<td>NumberAssociated</td><td>Whole</td><td>number of associated servers</td>

Statistics Request Object

Encapsulates a request for system-related information that can be used for load balancing algorithms and statistical purposes.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Load</td><td>Whole</td><td>request indicator (active / inactive)</td>

<td>Threads</td><td>Whole</td><td>request indicator (active / inactive)</td>

<td>Users</td><td>Whole</td><td>request indicator (active / inactive)</td>

<td>Uptime</td><td>Whole</td><td>request indicator (active / inactive)</td>

<td>NumberManaged</td><td>Whole</td><td>request indicator (active / inactive)</td>

<td>NumberAssociated</td><td>Whole</td><td>request indicator (active / inactive)</td>

ES 2 534 293 T3

User Object

Users and Servers use this object to register themselves in the administration database. Provides the information for subsequent connections (name, keyword) and other information related to the system. End Users provide personal, demographic and system-related information.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Login</td><td>Information Object of</td><td>connection information (name, word</td>

<td></td><td>Connection</td><td>key code</td>

<td>FirstName</td><td>Chain</td><td>User name</td>

<td>Lastname</td><td>Chain</td><td>user's last name</td>

<td>Title</td><td>Chain</td><td>user occupation title</td>

<td>Company</td><td>Chain</td><td>user's employer</td>

<td>Address1</td><td>Chain</td><td>user's home address</td>

<td>Address2</td><td>Chain</td><td>extra in the direction of the user</td>

<td>City</td><td>Chain</td><td>city, village</td>

<td>State</td><td>Chain</td><td>foreign state, province or country</td>

<td>ZipCode</td><td>Chain</td><td>zip or postal code</td>

<td>Age</td><td>Chain</td><td>user's age</td>

<td>Gender</td><td>Chain</td><td>user's gender</td>

<td>PhoneNumber</td><td>Chain</td><td>phone number</td>

<td>FaxNumber</td><td>Chain</td><td>fax number</td>

<td>E-mail</td><td>Chain</td><td>Email address</td>

<td>Demographics</td><td>Dictionary</td><td>extra user information for commercial purposes</td>

<td>SystemInfo</td><td>Dictionary</td><td>system relative information</td>

Version Object

All system components use this object to replicate their version information to the party with which they negotiate to use a protocol that they both understand. They are also given the opportunity to update themselves if there is a new version.

<td>Field name</td><td>Field type</td><td>Observations</td>

<td>Token</td><td>Security Key Object</td><td></td>

<td>Major</td><td>Whole</td><td>major protocol version number</td>

<td>Minor</td><td>Whole</td><td>secondary protocol version number</td>

<td>Type</td><td>Whole</td><td>sender type</td>

<td>Client</td><td>Version</td><td>client version information</td>

Unlike traditional state computer-based protocols, the control protocol of the present invention is a lightweight, stateless protocol that comprises simple sequences of objects. It is lightweight because in most sequences only two objects are involved in the transaction and after the sequence completes the connection can be reused. It is also stateless because the server does not maintain information about the client. Each transaction is handled independently of the previous ones. The state exists at the lowest levels, for example within the TCP layer, to express logical states of a network connection but they are not really part of the control protocol.

In the preferred embodiment, the software running on the Control Servers, Media Servers, and Primary Servers is programmed for a Windows NT and UNIX environment using an OLE environment. In addition, COM interfaces are used between components. The Rogue Wave system is used to transfer objects between applications running on various computers. The software running on the User's computer is preferably programmed for a 32-bit Windows environment, so that it runs on a Windows 95 or Windows NT computer. Alternatively, Macintosh and UNIX environments can be adapted using other User software.

The basic process of a control transaction consists of a version sequence followed by one or more protocol sequences. The release sequence begins after the computer that initiates the transaction, the client, has established a connection with the computer that completes the transaction, the server. The client sends a version object (defined in Table 1) and in response the server then sends back its own version object. This version sequence is used so that both the client and the server are aware of the version numbers of the software they are using. If a version number is older than expected, either the client or the server can choose to adapt to the previous version or abort the transaction, depending on their needs and capabilities. If a version number is newer than expected, in most cases the current transaction can be completed since software systems are designed to be

ES 2 534 293 T3 fully backward compatible with previous versions. Additionally, in the case that the transaction server is the Administration Server, the client receives information about the latest version number and thus the client can be informed that a software update is necessary. The process of automatic management of the User software update is described in more detail below.

After the version sequence, one or more protocol sequences take place in which other objects are exchanged between client and server. When a particular protocol sequence is complete, another independent protocol sequence can be serviced. The protocol sequences that are part of the control architecture 10 of the present invention are summarized in Table 2 and are described below in conjunction with Figures 6-17.

TABLE 2

<td colspan="4">Summary of Protocol Sequences</td>

<td>Control sequence</td><td>Client</td><td>Server</td><td>Main Items Exchanged</td>

<td>User registration and connection (see Fig. 6)</td><td>User</td><td>Administration</td><td>Version Object User Object Channel Guide Object</td>

<td>User connection (see Fig. 7)</td><td>User</td><td>Administration</td><td>Version Object Connection Information Object Channel Guide Object</td>

<td>Channel reproduction (see Figs. 8a, 8B, 8C)</td><td>User</td><td>Administration Control Media</td><td>Version Object Server List Object Version Object Server List Object Version Object MCI objects - OPEN / PLAY / STOP / CLOSE Ping objects (TCP connection remains open)</td>

<td>Key validation (see Figs. 9A, 9B)</td><td>Control or Media or Primary</td><td>Administration or Control</td><td>Version Object Security Key Object</td>

<td>Server registration and connection (see Fig. 10)</td><td>Media or Control</td><td>Administration</td><td>Version Object User Object Server Activation Object</td>

<td>Server Connection (see Fig. 11)</td><td>Media or Control</td><td>Administration</td><td>Version Object Connection Object Server Activation Object</td>

<td>Control Server Activation (see Fig. 12)</td><td>Administration</td><td>Control</td><td>Version Object Server Activation Object</td>

<td>Activating the Media Server (see Fig. 13)</td><td>Control</td><td>Media</td><td>Version Object Server Activation Object Ping objects (TCP connection remains open)</td>

<td>Control channel activation (see Fig. 14)</td><td>Administration</td><td>Control</td><td>Version Object Channel Activation Objects</td>

<td>Activation of the media channel (see Fig. 15)</td><td>Control</td><td>Media</td><td>(opens TCP connection) Channel Activation Objects</td>

<td>Triggering distribution (see Fig. 16)</td><td>Media</td><td>Media or Primary</td><td>Version Object MCI objects - OPEN / PLAY / STOP / CLOSE Ping objects (TCP connection remains open)</td>

ES 2 534 293 T3

<td>Statistics request (see Fig. 17)</td><td>Administration Control or Media</td><td>Version Object Statistics Object</td>

The User registration and connection sequences are the processes by which a new User registers with the system, accesses and retrieves programming information. Channel playback sequences take place when a User requests to listen to a particular channel. The key validation sequence is used to verify that a computer requesting a service is authorized to do this. The Server registration, connection and activation sequences are used by the Control and Media Servers when they become active. The Control Server and Media Server wake-up sequences are used to manage the Control and Media Servers. The control channel, media channel and distribution activation sequences are used to cause a channel to be distributed to a Media Server. Finally, the statistical request is used for administrative purposes.

Fig. 6 illustrates the User registration and connection sequence in more detail. This sequence takes place after the User has installed the User software on their computer. The User is expected to download the software from the Internet and then call it, which in the preferred embodiment will mean using the Windows Wizard interface. This will guide the User through the installation process including filling in the registration form, which will be described in more detail in the next section. After the User has selected a name and password and selected the registration option, the User's computer opens a TCP connection with the Administration Server. Advantageously, the full domain name of the Administration Server is embedded in the User software, although it could be discovered in other ways. The User and the Administration Server then exchange version objects with the Administration Server as described above. If the version numbers meet expectations, the User sends a User Object to the Administration Server. The format of the User Object is shown in Table 1. Once the Administration Server receives the User Object, it verifies that the information is filled in properly and that the selected User name is unique. If the User Object is invalid for any reason, the Administration Server returns a Result Message Object with a code indicating the reason. The format of the Result Message Object is shown in Table 1. If the User information is valid, the Administration Server updates the global database of User names and keywords and then generates a security key for that User. This security key is then returned to the User in a Result Message Object.

Upon receipt of the Result Message Object, the User saves the security key for future use. This key is an identifier that allows the User to request services from the Administration Server and other computers within the global system. The security key is not permanently saved or recorded on the User's computer. Normally, the User software immediately then sends a Channel Guide Request Object to the Administration Server and a Channel Guide Object is returned. The format of these objects is also shown in Table 1. Note that in principle, this is a separate transaction and can take place in a separate TCP connection with the Administration Server. In particular, once the User has registered and accessed, they can request a Channel Guide Object again as it may have been updated from the previous request. At this point the TCP connection with the Administration Server is closed.

The User registration process only needs to take place once for each User. However, anyone can re-register at any time, even after the software has been installed. In particular, it is expected that if multiple people use a computer, each person will register and have their own username and password. If the registration process is not completed successfully, the User software saves the registration information and asks the User if they would like to try again the next time the software is called.

Since the security key is not permanently saved by the User software, it is lost when the User software is closed, and the security key must be retrieved again from the Administration Server the next time the User wishes to use the system. . This process is the purpose of the connection sequence illustrated in Fig. 7. This sequence is used if a User has already registered and only needs to retrieve a valid Security key. In this case, the sequence consists of sending by the user a Connection Information Object to the Administration Server. The Administration Server then consults the User database to validate the connection name and the password. If the login name and keyword are correct, the security key is returned to the User. Normally the reception of the security key will be immediately followed by a channel information request sequence, precisely in the previously described registration sequence.

The control sequence that occurs when a User initiates a channel playback operation is illustrated in Figs. 8A, 8B and 8C. First the User software requests a List of Control Servers from the Administration Server. Note that the Server List Request object, illustrated in Table 1 contains a channel identifier. The Administration Server generates a classified list of Administration Servers

ES 2 534 293 T3

Control based on the overall load of the system and the location of the User in the network and returns this list to the User using a Protocol List Object. Once the List of Control Servers is returned to the User, the Administration Server is no longer needed and the TCP connection is closed.

The User software then searches the list of Control Servers and opens a TCP connection with the first listed host. If that hosting computer is not responding, then it is tried with the next Control Server in the list and so on in succession. Upon obtaining a response from a Control Server, the User software uses a Server List Request Object to request a List of Media Servers from the Control Server. If the Control Server is too busy to service the User, it returns a Result Message Object indicating so and the User software deals with the next Control Server on the list. However, in the likely scenario that the Control Server is able to handle the User's request, a classified list of Media Servers is generated and returned to the User's computer using a Protocol List Object. The TCP connection to the Control Server is then closed by the User software.

At this point the User software initiates a TCP connection with the first Media Server in the list provided by the Control Server. As in the previous case, it tries to connect to the first host on the list and if unsuccessful it tries the next host in succession. Once the Version objects are exchanged, the User software sends an MCI Request object to the Media Server. An MCI Request Object can be used for four basic commands: OPEN, PLAY, STOP, and CLOSE. The User software must first send an OPEN command for the desired channel. If the returned Result Messages Object indicates success, the User software then sends a PLAY command.

When the Media Server receives a valid PLAY command, it starts supplying audio information to the User as described in the previous section. Note that this could be in the form of broadcast, multicast, or unicast packets to a specific UDP port. The TCP connection through which the MCI Request Objects were sent remains open during the audio playback operation. In addition, Ping objects are sent to the User periodically to verify that the computer is still working and active. When the User software receives a Ping object, it simply returns it. The Media Server uses the Ping objects to measure round-trip times and also to determine when a User's computer has abnormally terminated. In this case, the streaming audio is ended.

In the case of normal termination of the audio stream, the User makes an explicit selection to stop it and this causes a STOP command to be sent to the Media Server in an MCI Request Object. The Media Server then ends streaming audio to that User. When the User closes the application software or selects to play another channel, the User software will send a CLOSE command to the Media Server on an MCI Request Object and the TCP connection is closed.

The initiation of audio streaming by the Media Server causes a log entry to be generated and sent to the Administration Server. This information is important so that the Administration Server can update its database to indicate which Users are listening to which channels. The security key is used to identify the User who initiates the streaming audio. Additionally, when the continuous transmission of audio to any User is finished, another registration message is generated and sent to the Administration Server.

Fig. 9A illustrates the process by which security keys are validated. The Administration Server is the only server that can validate a security key. Thus, when a User requests services from a Control Server or from a Media Server, that server must return to the Administration Server with a key validation sequence. However, Control Servers and Media Servers are allowed to store security key validations so that they do not have to repeatedly validate keys once they have validated it the first time. In the event that the Media Server receives a request, the password will be validated with the Control Server that is managing that Media Server. Fig. 9B identifies the various key validation scenarios.

Fig. 10 illustrates the process by which a new Server is registered. This process is similar to a new User registration. It is expected, however, that the Server installation will be done through a Web interface rather than through a Help Program. The Administration Server, upon receipt of the User Object from a Media Server or Control Server, validates the User name and password and generates a security key just as in the case of the User registration. Typically the server immediately sends back a Server Activation Object indicating that it is ready to be used as a system resource. After this process is completed, the TCP connection to the Administration Server is closed.

If a Media Server or Control Server that has sent a Server Activation Object to the Administration Server becomes inactive, it will send another Server Activation Object indicating this situation. In the case of a Media Server, this object is sent to the Control Server that manages it. In the case of the Server

ES 2 534 293 T3 of Control, this object is sent to the Administration Server. As in the case of the User registration, the registration of the Media Server and the Control Server needs to take place only once per computer. However, if the computer is restarted, the Server must connect and retrieve a security key again. This is the server connection and activation sequence shown in Figure 11.

Once a Control Server has indicated to the Administration Server that it is ready, the Administration Server can activate that Control Server by sending a Server Activation Object to the Control Server as illustrated in Fig. 12. This is a separate transaction and is used to tell the Control Server which Media Servers it is supposed to manage. Remember that a Control Server and a number of Media Servers form a grouping of Media Servers. The only Control Server managing that pool should be given a list of host computers that correspond to the Media Servers in that pool.

The process by which a Control Server activates the Media Servers it manages is illustrated in Fig. 13. The Control Server sends a Server Activation Object to the Media Server indicating that it is responsible for managing the channel. . This TCP connection between the Control Server and the Media Server remains open for as long as both servers are active. The Control Server periodically sends Ping Objects to the Media Server over this open TCP connection to verify that the Media Server is still running.

Fig. 14 illustrates the process by which a given channel is activated by the Administration Server. The Administration Server opens a connection to a Control Server that it wants to carry a given channel and provides a Channel Activation Object. This object indicates to the Control Server to which Media Server or Primary the Control Server should direct its Media Servers to obtain the provision of them. At this point the Control Server is said to be transporting that channel and will be a valid accommodation in a list of Control Servers requested by a Channel Play sequence.

Fig. 15 illustrates what happens when a Control Server needs to provide a channel. It first sends a Channel Activation Object to one of the Media Servers that it manages through an open TCP connection previously described. This object tells the Media Server that it should start receiving the identified channel and from where it should receive it.

In Figs. 16A and 16B is represented as a Media Server requesting the distribution of an audio channel from another Media Server or from a Primary Server. This sequence is largely the same as that in which a User requests the distribution of audio information from a Media Server. Note that a Media Server receives a single incoming stream for each channel it is carrying and will then redistribute this stream to all Users or other Media Servers that request it.

Finally, Fig. 17 illustrates the statistics request sequence. This sequence is used by the Administration Server to collect information from the Media Servers and Control Servers to manage the overall system. You can use this information to detect failures and to balance the load when dynamic conditions change. As noted above, you can also use this information to monitor which Users are listening to which channel or whether Users stop listening on a channel at any time, such as during the playback of a particular song. You may also use this information to control the advertising content that is downloaded to a particular User prior to the receipt of regular audio programming and / or to monitor the delivery of advertising to Users.

The control architecture described in this section is scalable to handle any number of Users. Note that the User registration process only happens once for each subscriber and that the connection process only happens once per session. These interactions, which require the Administration Server, are expected to constitute a very small percentage of the overall system bandwidth. If the Administration Server were to become saturated, however, it would be possible to duplicate it and have the database it maintains distributed and automatically updated to guarantee consistency.

Control Servers are distributed throughout the network and can handle the lowest level of interactions with Users and Media Servers. A single Control Server can preferably handle on the order of ten Media Servers and up to several hundred Users. The bit rate between Users, Control Servers and Media Servers is expected to be small compared to the audio transmission bit rate. Ping Objects usually only involve the User and the closest Media Server. They are also low overhead since they are small and only transmitted infrequently.

ES 2 534 293 T3

III. User interface

The User interface is provided by the client application running on a single computer and its associated graphical interface. In the preferred embodiment the User interface is available for Windows 32-bit (95 and NT), Macintosh, and UNIX platforms. Preferably anyone on the Internet can freely download a copy of the client software and install it on their computer.

Fig. 18 illustrates the main User screen in the preferred embodiment. The screen is made up of three sections: channel guide (upper left frame), program guide (upper right frame), and multimedia frame (lower half of screen). The channel guide lists, as a hierarchical tree, the channels that are available from the system. The user selects a channel from the list of those shown in the channel guide. The program guide provides information pertaining to the selected channel. This information can be a detailed schedule of programming that has been or will be played on the selected channel. Additionally, other relevant information will be displayed in this box, for example, a news item in relation to an upcoming special event on another channel. The multimedia box provides a built-in Internet browser that displays information through a series of tabbed sections.

The information contained in the channel guide, program guide, and tabs of the multimedia framework is dynamically transmitted to the client. For example, if a new channel begins operation, the client application can immediately display it as available. Additionally, the tabs displayed may be specifically relevant depending on what song is playing. For example, you can display tabs showing album cover, artist information, song lyrics, tour dates. Additionally, as shown in the example of Figure 18, a tab may be available that allows the user to order the CD or allow the user to participate in a channel-related chat session.

Figure 19 illustrates the key drop-down menus available on the User main screen in the preferred embodiment. Table 3 provides the description of each of the functions available through the drop-down menus, as shown in figure 19.

As will be apparent to those skilled in the art, numerous modifications can be made within the scope of the invention.

Table 3

<td colspan="3">Drop-down menu functions</td>

<td>Choice of menu</td><td>Choice of submenu</td><td>Description</td>

<td>File</td><td>Connection</td><td>Allows the user to connect to the system.</td>

<td></td><td>Disconnection</td><td>Allows the user to log out of the system.</td>

<td></td><td>Register Close</td><td>Opens a dialog so that the User can register with the system for the first time. Minimize the screen.</td>

<td>Edition</td><td>Copy</td><td>Allows User to copy selection to clipboard.</td>

<td></td><td>Properties</td><td>Allows User to set various properties.</td>

<td>Audio</td><td>Reproduction</td><td>Playback of the selected channel starts.</td>

<td></td><td>Stop</td><td>For playing the selected channel.</td>

<td></td><td>Mute</td><td>For audio playback</td>

<td>Sight</td><td>Toolbar</td><td>Shows or hides the toolbar (which provides access to drop-down menu functions).</td>

<td></td><td>Status bar</td><td>or hide the status bar normally located at the bottom of the screen.</td>

<td></td><td>Browser bar</td><td>Shows or hides the toolbar section that provides access to Internet browser functions.</td>

<td>Help</td><td>Help topics</td><td>Open a list of available online help topics.</td>

<td></td><td>About...</td><td>Presents summary information regarding this application, such as version number, copyright information, and the like.</td>