HK1079923A - Methods for multicasting content - Google Patents

Description

Method for multicasting content

This patent application claims priority to U.S. provisional application serial No.60/395,365, filed on day 11/7/2002, entitled "METHODS FOR MULTICASTING CONTENT," and U.S. provisional application serial No.60/345,501, filed on day 24/10/2001, entitled "METHODS FOR MULTICASTING CONTENT," the entire CONTENTs of which are hereby incorporated by reference.

Technical Field

The present invention relates to a method for tunneling (tunnel) content through a public network and multicasting the content.

Background

There are many media players available commercially or otherwise for playing back digital data streams. Historically, players have been configured for peer-to-peer communication of data streams between a host and the player itself. Also, despite the use of user datagram protocol ("UDP") and the like to tunnel data streams through multicast nodes of an extended network, an increasing interest remains in playing many multicast streams once, whereas conventional players are simply not compatible with existing multicast distribution schemes. The present invention fulfills these and other needs.

Disclosure of Invention

The present invention relates to a computer-implemented method for tunneling content through a network, wherein the content has been configured into a player-compatible digital format. Before starting a broadcast session (session), a notification is transmitted over the network, the notification including control information about the broadcast session. The control information allows controlled reception of the constituent content and includes a start time. The configuration content is encapsulated into a format that supports multicast distribution and controlled reception on a particular machine. The configuration content is multicast to the plurality of machines in an encapsulated format over the network according to a start time included in the notification. The control information is used to selectively allow reception at a particular machine of the plurality of machines and to strip the encapsulation from the multicast transmission at the particular machine.

The invention also relates to a system for multicasting content that has been configured on a host computer to be compatible with a particular player's digital format.

In one aspect, the present invention provides a computer-implemented method for multicasting content over a public network, comprising the steps of: capturing live audio as a first signal, capturing live video as a second signal, configuring the first and second signals into respective UDP streams of data packets, and encapsulating the data packets from each UDP stream together into a Common Data Multicast Protocol (CDMP) to be transmitted over the common network, the CDMP including header data sufficient to allow a player running on a user machine to replay the captured audio and video.

In another aspect, the present invention provides a computer-implemented method of multicasting content over a public network, comprising the steps of: capturing live audio as a first signal, capturing live video as a second signal, arranging the first and second signals into respective UDP streams of data packets, and encapsulating the data packets of the respective UDP streams into separate CDMP streams for transmission over the common network, the CDMP including header data sufficient to allow a player running on a user machine to replay the captured audio and video.

In yet another aspect, the present invention provides a computer-implemented method of tunneling content through a public network, comprising the steps of: configuring content into a digital format compatible with players, appending a header to the configured content, the header having control information to allow multicast distribution and controlled reception, multicasting the configured data with the header to a plurality of players over the network, using the control information to selectively allow reception at a particular one of the players, and stripping the header from the multicast data, whereby the multicasting provides the configured content compatible with the particular player.

In yet another aspect of the invention, a particular user or machine can be targeted for policy distribution of content by actively managing the user and its network access point.

Further aspects, features and advantages of the present invention will become apparent from the following detailed description and the accompanying drawings.

Drawings

FIG. 1 is a first hardware configuration for practicing the present invention.

Fig. 2 schematically depicts certain software modules within a broadcast platform that enables desktop reception of multicast content.

Fig. 3 is a second hardware configuration for practicing the present invention using the edge of a web server.

FIG. 4 is a first screen shot of a portal page in an exemplary implementation of the invention.

FIG. 5 is a second screen shot of a portal page in an exemplary implementation of the invention.

Fig. 6 illustrates a first operational scenario in accordance with the present invention.

Fig. 7 illustrates a second operational scenario in accordance with the present invention.

Fig. 8 illustrates a third operational scenario according to the present invention.

Fig. 9 illustrates a fourth operational scenario according to the present invention.

Fig. 10 is a block diagram of an exemplary embodiment of a client that may be used to practice the present invention.

Detailed Description

The present invention is described in connection with an embodiment that uses a broadband distribution platform running on a programmable machine (e.g., a computer) to deliver content from a content provider to an end user over a network. Student (i.e., end-user) interactivity is provided through a back channel that is compatible with the content provider's infrastructure. Broadcast platform back channels need not be used for return path interactivity. Each stream transmitted by the content provider has a scheduled broadcast time that takes into account the required bandwidth of the stream.

FIG. 1 represents the main platform modules involved in delivering a live e-learning session directly to a desktop computer. In particular, there is a content provider 10, a network manager 20 (which preferably takes the form of a channel management center ("CMC"), as described in co-pending U.S. patent application Ser. No.09/046,901, filed 24/3/1998, entitled "Method and System for Broadcast Transmission of media objects," which is hereby incorporated by reference herein), and an end user 30.

Generally, however, the block diagram of fig. 1 illustrates a broadcast system in which media objects are provided by one or more content providers (only one content provider is shown in fig. 1) to a network manager or channel management center. The content provider has channel editing capabilities that further allow scheduling of multicast transmissions to a plurality of end users 30, only one of which is shown in fig. 1. The channel editing capability of the content provider can be configured as a professional channel editing center (CEC Pro), a Channel Editing Center (CEC), or a major channel editing center (CEC Master).

In this exemplary embodiment, the content provider is provided with one encoder 12, and the encoder 12 is capable of generating multiple data streams, for example, a first data stream for audio and a second data stream for video. There can be additional data streams managed by the audio server 14, such as return audio. The presence server 16 is capable of generating multiple (e.g., 12) static content streams for transmission to the network manager 20. The camera 18 can be used at the content provider or elsewhere to capture data and combine the data with other material as may be needed or desired for a particular e-learning session. The content provider acts as a channel editing center, using the computer 19 to manage content, reserve bandwidth, and schedule the transmission of e-learning sessions, as is known from the aforementioned 09/046,901 patent application. Bandwidth booking and transmission scheduling is known, for example, from U.S. patent application serial No.09/738,390 entitled "Decision Support System and Method for Planning broadcast transmissions" filed on day 12/15 of 2000, the entire contents of which are incorporated herein by reference. The content provider 10 can further have a server 17 for sharing applications with new intended end users.

In an alternative, more general embodiment, content provider 10 and network manager 20 can be configured substantially as described in the above-identified U.S. patent application serial No.09/046,901.

Suitable hardware configurations for content provider 10 within this exemplary embodiment include many components available from One Touch System, Inc. of san Jose, Calif. In particular they provide suitable encoders, rendering servers, audio servers and application servers, acting as encoder 12, rendering server 16, audio server 14 and application server 17 respectively. An administrator or other person can configure these components by replacing the IP address and port settings with those of the UTP broadcaster addressing the CMC 20. Similarly, the Web access software on the client 31 is set to a dedicated IP multicast address and port for receiving multicast transmissions from the CMC20 or network edge server as the case may be.

Conventionally, providers of streaming content configure their data streams for playback in appropriately configured players. Among the several known types of players are Windows media players available from Microsoft corporation of Remond, Washington, and Frontow players of One Touch Systems, Inc. For such players to play back these streams, they must be in a compatible format. However, conventional players are suitable for unicast delivery, i.e. from one content provider to one end user. In addition, many content providers use proprietary players that expect the data to be played to be in a particular format, sometimes including control or management keys that govern the viewing capabilities of the data stream on a given end user. The present invention therefore seeks to overcome the traditional constraints on streaming by enabling multicast transmission of streaming content regardless of the format of the underlying stream.

The broadcast platform of this exemplary embodiment first configures all streams from the content provider as user datagram protocol ("UDP") streams on a UDP tunneling ("UTP") broadcast server 22 located on the network manager 20. The UTP broadcaster 22 then encapsulates the UDP stream packets within common data multicast protocol ("CDMP") packets. The CDMP packets described below allow subscription management and multiplexing of streams across multicast platforms. The network manager preferably has a broadcast guide server 24 that provides broadcast guide information to subscribing end users. The network manager coordinates broadcast requests received from the content provider's computer 19 on the CMC kernel 26. The CMC kernel communicates and manages those requests with the assistance of the broadcast boot server 24.

In an alternative arrangement, the UDP stream is provided by the content provider 10 directly to the network manager 20, where it is encapsulated into a format that supports multicast distribution (e.g., CDMP packet format).

The CDMP streams are multicast across a common network and received on a plurality of end users 30 (only one shown in fig. 1). Each end user has a client 31 running various programs on any of a number of operating platforms. Among the programs executed on the client 31 are a multicast-ready Web-compatible interface (e.g., a plug-in software module for a Web browser) and a suitable player. Preferably, the multicast-ready interface ("MRI") is the MediaSurfer (trade mark) software product available from Fantastic corporation of Zug, Switzerland. The player may be a front (trademark) player from One Touch Systems, inc, or some other player, such as a Windows media player from microsoft corporation of Remond, washington, or a RealPlayer from RealNetworks, inc. The CDMP stream includes a header and preferably encapsulates the UDP stream or vice versa to include information that allows multicast distribution and controlled reception on authorized and intended end-user machines. These streams are unpacked or reconfigured when received by the MRI on the client. The MRI outputs packets compatible with the player running on the client 31.

Encapsulation or attachment of packets of content configured to enable multicast transmission is performed at the network manager 20. Illustratively, the network manager 20 includes one or more subscription control managers (e.g., within the CMC kernel 26) that function to encapsulate or encode media objects according to subscription information from the subscription database 508. The subscription-information retrieval manager retrieves subscription information for the received media object from the database 508 and sends the information to the subscription control manager. The subscription control manager encapsulates, encodes, or both encapsulates and encodes the media object based on the subscription information received from the database 508.

The encapsulation or encoding employed by the present invention may take a variety of forms. For example, the subscription control manager may be programmed to identify the header and trailer of a packet and to wrap additional protocol layers of subscription information around the packet.

Alternatively, the subscription information retrieved from the subscription database 508 may include instructions for encoding the media object according to particular encryption software. Only clients subscribed to the service and thus having corresponding decryption software can receive the broadcast object.

In an alternative embodiment, the subscription information may be embedded in the transport bitstream, for example by watermarking the individual data packets. In this alternative embodiment, the subscription information does not have to be added to the bitstream by the subscription control manager 506 b. Subscription information may be added to the data at any point within the system and may be added by the content provider or other party.

The use of encapsulation or coding, as described below, allows the system of the present invention to allow or disallow a particular end user to receive a particular service.

Client 31 accesses broadcast schedule information that informs the end-user of available broadcast program options. Preferably, each UDP stream generated within a single teaching session is included together into a single schedule. The client 31 in this exemplary embodiment is a personal computer; however, the invention may be implemented using other devices for receiving broadcast media objects, such as a set-top cable box, as long as the devices include the appropriate hardware and software to implement the functionality described below.

An exemplary client 31 is illustrated in block diagram form in fig. 10. Client 31 preferably includes a receiver 100 connected to a layered protocol, such as a TCP/IP stack 112, via NDIS driver 110. The TCP/IP stack 112 is connected to a subscription manager 114, the purpose of the subscription manager 114 being to control end user access to received information and to maintain a list of information services for the end user.

The receiver 100 preferably includes one or more components 102 and 108 adapted to receive broadcasts from the broadcast facility 25. Receiver 100 may include an antenna 102 for receiving Rf television transmissions, a CATV modem 104 for receiving cable television transmissions, a satellite receiver 106 for receiving satellite transmissions, and/or a modem 108 for receiving transmissions via a data link, depending on the broadcast technology employed by domain broadcast facility 25.

As noted, receiver 100 is coupled to a protocol stack, such as TCP/IP stack 112, via NDIS driver 110. In a preferred embodiment, TCP/IP stack 112 may comprise a Winsock (TM) TCP/IP stack manufactured by Microsoft corporation. As known to those skilled in the art, one purpose of the TCP/IP stack 112 is to examine arriving data packets that make up a transmission file or other media object to determine that all packets that make up the file have been received and that they have been received in the correct order.

Once TCP/IP stack 112 verifies proper receipt of the TCP/IP communication, the communication is passed to subscription manager 114, and subscription manager 114 determines the subscription and service to which the communication belongs. Subscription manager 114 then determines whether client 31 is authorized to receive transmissions pertaining to the identified service and, if so, whether the service has been allowed by the end user.

In particular, the subscription manager 114 preferably comprises a software program running in the background of the end-user client 31. However, when desired, the end user may maximize the subscription manager 114 and have it display a list of services that the end user client 31 is authorized to receive, i.e., all services included in the subscription package to which the end user has subscribed. The end user may then manually enable or disable the service within a subscription package. For each authorized subscription package, the subscription manager 114 maintains a record of services that have been allowed and disallowed by the end user.

Then, when a communication is received, subscription manager 114 first determines whether the transmission belongs to a service to which the end user has subscribed. Subscription manager 114 typically makes this determination by examining the received communication and determining whether it has subscription information needed to decode or decapsulate the transmission.

As noted above, the use of encapsulation or encoding allows the system of the present invention to allow or disallow the reception of a particular service by a particular end user. In a preferred embodiment, the system may enable a particular PC 30 to receive a particular service by broadcasting a subscription message that addresses all end user PCs that have subscribed to the service. The message preferably contains information about the particular number and channel the service will be broadcast and may also include information about the encapsulation protocol used to encapsulate the transmission. If the service is encrypted, the subscription message may also include information needed to decrypt the transmission. With this information, the client 31 is able to identify broadcast transmissions belonging to the service, strip the encapsulation information, decrypt the transmissions (if necessary), and provide the transmission content to the end user, as will be described in more detail below.

After a certain period of time, the disabling of a particular service can be accomplished by including a timestamp in the subscription message that instructs the PC 30 to delete the subscription message from its memory (or that instructs the PC 30 not to use the information included in the service parameter message). Alternatively, the system may change the channel and number of broadcasts for a particular service so that continued reception of those services requires additional service parameter information not available to those PCs 30 that will be prohibited from receiving the service. In addition, if the service is encrypted, a particular PC 30 may be disabled by modifying the encryption and not sending an updated subscription message to the disabled PC 30 regarding the new encryption. Services on one or more PCs 30 are disabled by addressing a disable services message for a service to a particular PC 30 to be removed from the service.

As noted, the subscribe message to enable/disable a particular service may be addressed to a particular PC 30. Specifically, each client 31 may be assigned a unique address. A subscription message is transmitted that includes the address of a particular PC 30 instructing each addressed client 31 to enable and/or disable a particular service in the manner described above. The unique address is preferably implemented in hardware to avoid a user configuring multiple PCs 30 to have the same address. When the subscription manager 114 identifies a subscription message addressed to its client 31, it updates the subscription information according to the content of the received message.

Alternatively, instead of submitting subscription information to a particular PC 30, the system may adjust access to the subscription information in other ways. For example, the subscription information may be encrypted or encapsulated prior to broadcast so that only PCs 30 having proprietary decryption of the decapsulation information can receive the subscription information. Also, the subscription information may be broadcast at a specific time and on a specific channel known only to those PCs 30 that have subscribed to the service to which the subscription information belongs.

If the multicast transmission received at the client 31 belongs to a subscribed service, the subscription manager 114 determines whether the end user has allowed the service.

Assuming that the service is subscribed to and allowed, subscription manager 114 then determines whether the received packet is part of a static media object, such as a file, or a dynamic media object, such as a streaming data transmission. If the packet is part of a file, subscription manager 114 transmits the packet to file receiver 116. Similarly, if the packet is part of a streaming data transmission, the subscription manager 114 transmits the packet to the streaming data receiver 118.

The file receiver 116 is connected to an I-cache proxy server 120, and the server 120 manages an HTTP cache 122. In a preferred embodiment, the HTTP cache 122 stores all received internet data. The user can then send a URL request to the file and gain access to its content. Alternatively, the received information may be stored in a different memory and may be accessed using a browser.

The HTTP cache 122 may be adapted to manage incoming data in a number of ways. Illustratively, the cache 122 may be programmed to overwrite older data as new data is received, or the cache 122 may be programmed to terminate storage of incoming information once the amount of information stored within the cache 122 reaches a threshold.

The streaming data receiver 118 is connected to a real-time data interface 124, and the interface 124 manages the play-out of the streaming data to an output port for display to an end-user of the client 31. In some cases, the play-out may be via an additional interface, such as a DDE interface, excel (tm), or the like. The real-time data interface 124 is connected to a real-time database 126, and the database 126 may temporarily store the received streaming data during play-out.

The client 31 may further be provided with a number of software tools, including HTTP or web browsers, such as Media Surfer (TM)128 and Internet Explorer (TM)130, to assist the end user in navigating the received files and streaming data.

Objects to be broadcast may be compressed and scheduled for broadcast prior to transmission to be broadcast in a compressed form according to bandwidth requirements. Decompression is performed by the client 31 as it receives the broadcast, allowing the media object to be broadcast in compressed form in a manner that is transparent to the end user of the client 31.

The notification precedes the UDP tunneling session. Prior to beginning a broadcast session, content provider 10 schedules a transmission by using reservation system software on computer 19 to reserve the required bandwidth and transmit broadcast guide ("BG") information. The schedule and BG information includes: broadcast start time, broadcast duration, and channel group/channel. This information is transferred to the CMC20, which in turn is broadcast by the CMC20 to the MRI. The graphical user interface ("GUI") of the MRI preferably displays a single BG announcement for each teaching session that can be played. More preferably, the various teaching sessions are filtered to display BG announcements that are intended for, or subscribed to, a channel accessible by a given end user. The notification is listed by the channel to be used during the broadcast. By selecting a BG announcement (e.g., using a mouse or other input device connected to the client 31), a UDP tunneling session is initiated that receives and processes CDMP packets and forwards player-compatible streams to the player.

At the scheduled start time, the content provider 10 starts transmission of the data stream. To view the content, the end user starts his or her player on the client 31. The player may be run from the same computer 31 that runs the MRI or on a different computer. Regardless, if the player has been configured to receive data on an address/port set within the MRI, the player receives a data stream from the content provider. Most preferably, the user can launch the player by selecting a BG session announcement displayed in the GUI of the MRI. This integration between MRI and player on the local machine can be done by mapping between the specific notification and the IP multicast address and port of that player.

Since the broadcast session can include multiple streams, simplified subscription and bandwidth scheduling results from multiplexing all data streams from content provider 10 that relate to a single session (e.g., a teaching session). In this exemplary embodiment, this is accomplished with an application program resident on the content provider's computer 19, the computer 19 built on the reservation system (and optionally part of the CEC software itself) to allow the instructor to reserve all streams associated with a single e-learning session at once. This application, referred to herein as an one-time session module 40 ("OSM"), manages the actions required by the CMC20 to ship a session to an end user. In particular, OSM 40 automates the reservation of multiple related streams (e.g., separate video and audio streams) within a single teaching session. On the one hand, it is easy to determine the required bandwidth to be reserved for multiple presentation streams, since they typically use 64 Kbps. Four schedules are typically reserved, e.g. three schedules for each audio stream and one schedule for the video stream. Both shared and dedicated bandwidth can be used. On the other hand, computing bandwidth usage for static content is somewhat complex, since the number of streams is not fixed and typically varies from 1 to 12. Thus, the bandwidth required for a single multiplexed stream cannot be determined, but only the total bandwidth required to accommodate the static content can be calculated.

The OSM 40 can solve the bandwidth performance problem using one of the following alternatives:

1) a schedule can be reserved for each static content stream. The UTP broadcaster 22 monitors all ports (e.g., 12) that can have static content streams.

2) One of the static content streams can be subscribed to a schedule and all of the streams multiplexed into a single stream, if desired, in front of the UTP broadcaster, using a multiplexer 42 on the content provider 10 or on the CMC 20. As shown in fig. 2, the UTP broadcaster 22 monitors the multiplexed stream on a prescribed port and, as the data is received, a demultiplexer 44 residing within or associated with the MRI 46 can provide the demultiplexed stream to a player 48 for playback. This solution causes synchronization problems due to the latency introduced by the multiplexing/demultiplexing process. This latency is currently considered to have little effect since the content is static, and any latency can be resolved by the player at playback (address) to restore synchronization with other streams. Any latency impact can also be offset by performance improvements since the listening threads that must be run to monitor multiple static content streams are reduced. The MRI 46 receives BG notifications for each single session and these notifications are processed by a BG processor 49 within or associated with the MRI 46 for display to the end user under broadcast direction.

The OSM 40 can define a single stream for all audio, video, and static content streams established with or associated with a single learning session and can communicate this information to the UTP broadcaster 22. Thus, BG information management can be as described in the above-mentioned patent application 09/738,390, since only one subscription is needed to broadcast the entire session.

For live session recording, the session can be delivered to the end user using a package delivery (very reliable) or cached content delivery configuration in which the MRI 46 stores the session file on a hard disk or other repository at a specified location. The file can be accessed and viewed at any time using the player 48.

When Packet Delivery (PD) is used for the recorded session, a teaching session is first recorded into a file. The content provider 10 schedules PD transmissions, uses the reservation system to reserve the required bandwidth and provides BG information, as described above. The schedule and BG information includes a file broadcast start time, a file broadcast duration, a channel group/channel, and a file size. In a preferred embodiment, the BG information identifies the type of media so that the media object can be processed and so that the appropriate player can be launched (launch) on the client 31. As noted above, the player can be launched by selecting a BG session announcement displayed in the GUI of the MRI. The file is then uploaded to the CMC20 for broadcast to machines with MRIs 46. The MRI GUI preferably displays a BG announcement for each recorded session file. These notifications can be listed by the channel used to broadcast each session. The machine with the MRI 46 receives the file and stores it in a pre-configured location on the hard disk. Once the file is saved to that machine, the end user can open the file by selecting the relevant BG announcement using the player 48, or by directly accessing the repository. It should be understood that the MRI 46 can reside on another machine than the player 48 (e.g., when the MRI 46 is a local area network server or a network edge server).

If the MIME-type file comprising the recorded teaching session can be identified by a Web browser, such as Internet Explorer available from microsoft corporation, Cache Content Delivery (CCD) is used to pass the file to the MRI 46. In this manner, the teaching session is recorded into a file, and the content provider 10 schedules the CCD transmission again, using the booking system to book the required bandwidth and BG information, as previously described. The teaching session file is uploaded to the CMC20 for broadcast to the machine carrying the MRI 46. The MRI GUI displays a BG announcement for each recorded session file, listing the announcements by the channel used to broadcast each session. The end user accesses the previously recorded session on the player 48 by selecting the relevant BG announcement or by directly accessing the repository.

The above discussion generally relates to a delivery mechanism for multicasting content to the MRI 46 to the desktop machine; however, the present invention is not so limited. Alternatively, intelligent caching techniques can be utilized for multicasting to network edge servers, as described next with reference to FIG. 3.

Fig. 3 illustrates a variation of the arrangement of fig. 1, in which an intelligent cache 50 has been provided in the multimedia content stream between the CMC20 and the end-user machines 31 and their respective players 48. More specifically, the intelligent cache is located at the edge of the network adjacent to many end users. A typical configuration may employ many such machines around the perimeter of the network. The intelligent cache 50 provides multimedia services to a plurality of clients 31 having respective players 48. Among the services provided by the intelligent cache 50 are caching of multimedia content, caching of guaranteed content, streaming management, broadcast guide forwarding, local end-user management, and interfacing with the CMC20 to end-user subscription information.

The intelligent cache 50 preferably has an MRI running within it so that multicast can be processed at the cache and terminated at that machine. An end user accessing the cache only needs to have a suitable player to retrieve the content provider's stream. Preferably, the intelligent cache comprises the "MediaAce" ("MA") product of Fantastic corporation of Zug, switzerland and is used to manage the reception as well as the processing and storage of all broadcast sessions.

The structure of fig. 3 operates substantially as described above in terms of the type and number of streams, their scheduling, booking and broadcasting. However, in this arrangement, the MA module of the intelligent cache 50 receives the CDMP packets comprising the original presentation stream and provides the end user with the teaching session notification through the portal page. The end user accesses the portal page and selects a particular session notification, as desired, by means of a conventional Web browser. This is possible because multicasting has already terminated at the intelligent cache 50 and the data transfer thereafter is in a format compatible with the player 48, so the individual client 31 does not need the MRI 46 (or MA module) to access and view the multicast content from the content provider 10. Any selection made from the portal page causes the MA to forward the presentation stream to the requesting player.

Content broadcast notifications on a particular channel can be presented in a variety of views, including video on demand ("VoD") and streaming. FIG. 4 provides a portal page 100 with exemplary tabs 102, 104 for selecting between these views. For live training sessions, the portal page 100 requires a further view in which the MA portal page displays a BG announcement for each teaching session. These announcements are preferably listed by the channel used in the broadcast.

The user can use a standard input device (e.g., a mouse) to select a BG announcement in the portal page 100 and cause the native presentation player to launch. The player is pre-configured to receive on the IP address and port used by the MA on which the MRI 46 is forwarding the streams. This can be made possible by changing the configuration of the player, as described above. Integrating the control of the player 48 into the portal page 100 provides an additional advantage of allowing the end user to click-start playback.

If a live session has been recorded into a file, the broadcast platform of the present invention is able to deliver that file in a reliable manner through the PD system. (many electronic protocols, including email protocols, can be used to pass the file to the CMC20 manager.) in particular, the teaching session is recorded into a file. The content provider then schedules PD transmissions, reserves the required bandwidth, and broadcasts BG information using the reservation system, as described above. The file and BG information are all uploaded to the CMC for broadcast to the MA. A file comprising the teaching session is received at a machine (e.g., intelligent cache 50) having an MA module and stored in a preconfigured repository on a file server. The MA adds a notification for the received file in the MA view of the portal page 100. The end user can then download the file to his or her machine 31 and view it with a player 48 or other on-demand application. In fig. 5, the portal page 100' shows a selectable tab 106 that is brought to the front of the MA view.

The MA includes a driver that allows files to be referenced from the MA view and retrieved from memory. Within the MA view of the portal page 100', the BG announcement includes a URL that references a file stored on the file server. The end user simply clicks on the notification to retrieve the file and plays the file with the player 48 or another client application.

The present invention will now be described in connection with four integrated scenarios, each using the CEC and CMC broadcast platforms described above. These scenarios differ from each other in the way the end-user accesses a live or on-demand (on-demand) training session.

Fig. 6 illustrates a scenario in which live e-learning is broadcast directly to a client desktop computer 31, the computer 31 having a player 48 and MRI 46 software executing thereon. As described above, the hardware components 12-18 are used to establish a live training session. Live AV streams, as well as fixed content, are scheduled, ordered, uploaded and broadcast to client desktops via a broadcast platform including CEC 19 and CMC20 (including BG broadcaster 24 and CMC kernel 26). The broadcast is a multicast transmission that otherwise cannot be communicated to a typical player 48 or the original stream provided by the content provider 10. On the client side, however, the MRI 46 receives live AV streams as well as fixed content, breaks them down into an understandable format, and makes the streams available to client applications such as the player 48. The recipient accesses the live session through the MRI 46, for example by clicking on a session announcement within the MRI broadcast guide viewer. A user name and password may be required to select and/or play the session.

Fig. 7 illustrates a scenario in which live and on-demand sessions are broadcast directly to client desktops. This scenario allows live sessions to be recorded. A recorded live session can be made available for on-demand viewing by a given end user. Sessions recorded and stored on the server are distributed directly to the MRI 46 via the broadcast platform. These sessions can be broadcast as cached content delivery or as packets delivery. The user can access the on-demand session via an MRI broadcast guide viewer or other application. By clicking on the session announcement in the MRI broadcast guide viewer or by selecting a start-up file stored on the client's hard disk, a login page can be presented in which the user enters the user's name and password to start the viewing session. The viewing session can be activated within the MRI 46.

In the scenario of fig. 8, the live session is broadcast to the MA and then forwarded to the client desktop. By broadcasting the live session to the MA at the entrance of the multicast-enabled LAN, the MRI 46 does not have to be installed on the client's desktop. The user accesses the live session again through the MA portal page 100, 100'.

In the scenario of fig. 9, on-demand sessions are broadcast to the MAs, stored on the file server and downloaded to their respective desktop clients 31. The scenario can be deployed in an environment with a unicast LAN infrastructure. The recorded sessions are scheduled, booked, uploaded, broadcast, and stored as described above. The user/recipient triggers an on-demand session through the MA portal page 100, 100'. By clicking on the session announcement in the MA broadcast guide viewer, a login page for the selected on-demand session is opened. After entering the user name and password, the on-demand session is pulled down from the file server to the client desktop. Finally, an on-demand session can be initiated through an on-demand client application installed on the client desktop. This scenario significantly improves the distribution of the teaching on demand session, since FTP downloading via the internet is now outdated.

Integrating e-learning products into the CEC/CMC broadcast platform, a Subscription Management System (SMS) enables individual end users as well as designated end user groups to be targeted, for example, for intercom and training purposes. This integration will enable the enterprise to export user data (e.g., user name, IP or MAC address of the client desktop, etc.) from the SMS into the player's 48 user management system. Therefore, the recipient of the teaching session only needs to be registered once, i.e., input to the SMS. The process of identifying the recipient for the teaching session is as follows:

step 1: entering subscriber data into SMS

Step 2: establishing a group of recipients for a teaching session within SMS

And step 3: selecting a group within SMS for a particular teaching session

And 4, step 4: user management system for outputting the set of required user data to a content provider

Note that in the case of the scenarios of fig. 8 and 9, the ability to directly target (target) intercom and training efforts to a particular individual cannot be supported. By using the MAs, only the respective IP or MAC address of the MA is entered into the SMS. It is therefore not possible to make a direct connection between the recipient of the teaching session and the information stored in the SMS. However, since only certain recipients will access a particular MA, a certain level of indirection packets will still be provided.

Thus, as described above, the present invention allows the merging and transmission of a wide variety of static and dynamic audio, video and data objects in a manner that provides control over the broadcast parameters and adjustments of the end-users allowed to receive the delivered material.

While the present invention has been described in conjunction with exemplary embodiments thereof, many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description, and all such alternatives, modifications, and variations are to be considered in light of the claims set forth below.

Claims (42)

1. A computer-implemented method for tunneling content through a network, the content having been configured into a digital format compatible with a player running on a particular machine connectable to the network, comprising the steps of:

a) transmitting, over the network, a notification including control information about the broadcast session, the control information allowing controlled reception of the configuration content and including a start time, prior to starting the broadcast session;

b) encapsulating the configuration content into a format that supports multicast distribution and controlled reception on a particular machine on the network;

c) multicasting the configuration content to the plurality of machines in a packaged format over the network according to a start time included in the notification;

d) using the control information to selectively allow reception at a particular machine of the plurality of machines, and

e) the encapsulation is stripped off on these specific machines, whereby the multicasting of the encapsulated content is compatible with the players on these specific machines.

2. The method of claim 1, wherein the player-compatible digital format is a unicast packet format, and wherein the step of encapsulating the configuration content comprises: the unicast packet format is contained in a multicast packet.

3. The method of claim 1, wherein encapsulating the configuration content comprises appending a packet to the configuration content.

4. The method of claim 3, wherein the appended packet includes a header.

5. The method of claim 1, wherein steps d) and e) are both performed by a media-ready interface executing on a particular machine.

6. The method of claim 1, wherein the broadcast session comprises a multicast of the configuration content.

7. The method of claim 1, wherein the notification is a multicast.

8. The method of claim 1, wherein the notification comprises broadcast guide information.

9. The method of claim 1, wherein the notification comprises a subscription message indicating an encapsulation protocol employed in the encapsulating step.

10. The method of claim 9, wherein the subscription message further includes a time and a channel on which a broadcast session service is to be broadcast.

11. The method of claim 9, wherein the subscription message further includes information needed to decrypt the multicast transmission.

12. The method of claim 1, wherein the encapsulated data is multiplexed and demultiplexed at the particular machines prior to being multicast over the network.

13. The method of claim 1, comprising the additional step of allowing interaction with an end user by providing a back channel return path to the content provider.

14. A computer-implemented system for tunneling content through a network, wherein the content has been configured to be compatible with a digital format of a player, comprising:

a network manager configured to receive the configuration content from a content provider and broadcast the content over the network in a multicast protocol, the manager comprising a programmed machine comprising:

(a) a broadcast guide broadcaster configured to transmit a notification including control information regarding a broadcast session to a machine of a subscribed end user in communication with the network, the control information allowing controlled reception of the configuration content and including a start time; and

(b) a UTP broadcaster configured to apply encapsulation to the configured content and to multicast the encapsulated content over the network to machines of subscribing end users.

15. The system of claim 14, wherein the UTP broadcaster is further configured to receive the configuration content from a content provider, convert the configuration content into a UDP stream, and encapsulate the UDP stream into CDMP packets.

16. The system of claim 14, further comprising a scheduling system disposed on the content provider that schedules a start time for multicasting the packaged content to the subscribing end-user's machine over the network.

17. The system of claim 16, wherein the start time is scheduled in consideration of a required bandwidth of the content stream.

18. The system of claim 14, wherein the network manager comprises a channel management center, and wherein the content provider comprises a channel editing center.

19. The system of claim 14, wherein the UTP broadcaster has a specified IP address setting and a specified port setting, and wherein the UTP broadcaster receives the configuration content from the content provider at the specified IP address and the specified port.

20. The system of claim 14, wherein the configuration content comprises a plurality of media objects selected from the group consisting of data files, streaming audio, and streaming video.

21. The system of claim 14, wherein the network manager includes a channel management center core that manages broadcast requests received from content providers and directs broadcasters to deliver the broadcasts to subscribed end users using the broadcasts.

22. The system of claim 14, wherein the subscribing end-user's machines each have a multicast-ready interface and a particular player, wherein the machines are connectable to the network, and wherein the multicast-ready interface receives a CDMP stream and outputs a stream compatible with the particular player.

23. The system of claim 22, wherein the machines have one or more players, and wherein UTP broadcasters multicast the packaged content to subscribing end users over the network.

24. The system of claim 22, wherein the multicast-ready interface comprises a graphical user interface that displays notifications transmitted from a broadcast guide broadcaster.

25. The system of claim 24, wherein the notification of the delivery is displayed on the graphical user interface according to the broadcast channel on which the packaged content is to be multicast over the network.

26. The system of claim 24, wherein the multicast-ready interface includes a filter that displays the notification of the delivery as a function of subscribing end users.

27. The system of claim 26, wherein the filter operates based on subscription information.

28. The system of claim 24, wherein the graphical user interface allows a particular subscribing end-user to select one or more multicasts of packaged content using an input device connected to the end-user's machine.

29. The system of claim 14, further comprising a multicast-ready interface configured to selectively allow reception of encapsulated content multicast by the UTP broadcaster using control information provided by the broadcast guide broadcaster.

30. The system of claim 29, wherein the multicast-ready interface is further configured to transform encapsulated content in multicast into a player-compatible format, the transformation being made by removing the encapsulation provided by a UTP broadcaster.

31. The system of claim 14, wherein the UTP broadcaster is configured to multiplex the encapsulated content prior to multicasting over the network.

32. A computer-implemented method of tunneling content through a network, the content having a digital format compatible with a player, comprising the steps of:

attaching a packet to the configuration content, the packet having control information that allows multicast distribution over the network and controlled reception on a plurality of machines connected to the network;

multicasting the configuration content with the header to a plurality of machines over the network;

using the control information to selectively allow reception at a particular one of the machines; and

the additional packet is stripped from the multicast transmission,

whereby the multicast provides the configuration content in a compatible player format to the particular machine.

33. The method of claim 32, wherein the digital format of the compatible player is a unicast packet format, and wherein the step of appending the packet comprises: the unicast packet format is included within a multicast packet.

34. The method of claim 32, wherein the additional packet includes a header.

35. The method as recited in claim 32 wherein steps c) and d) are both performed by a media-ready interface executing on the particular machines.

36. The method of claim 32, wherein a notification is transmitted prior to the multicast transmission step of step b).

37. The method of claim 36, wherein the notification comprises broadcast guide information.

38. The method of claim 36, wherein the notification comprises a subscription message identifying the encapsulation protocol employed in the appending step.

39. The method of claim 38, wherein the subscription message further includes a time and a channel on which a broadcast session service is to be broadcast.

40. The method of claim 36, wherein the subscription message further includes information required for decrypting the multicast transmission.

41. The method of claim 32, wherein the encapsulated data is multiplexed prior to multicasting over the network.

42. The method defined in claim 32 comprising the additional step of allowing interaction with the end user by providing a back channel return path to the content provider.