EP2025163A1

EP2025163A1 - A scalable unified framework for messaging using multicast and unicast methods

Info

Publication number: EP2025163A1
Application number: EP06803771A
Authority: EP
Inventors: Satish Annapuredy; Stefan De Laet
Original assignee: Nokia Siemens Networks GmbH and Co KG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2006-05-19
Filing date: 2006-09-18
Publication date: 2009-02-18
Anticipated expiration: 2026-09-18
Also published as: WO2007136400A1; WO2007136400A9; EP2025163B1

Abstract

A scalable messaging framework (100) that allows applications to send and manage announcements in an IP network is described. In particular, the messaging framework (100) provides for the end-end delivery of announcements and files over multicast and unicast. Announcements may refer to file updates, messages, commands etc. The format of the event description in the announcement is described by an extensible format called EventMetadata. Announcements can be pushed to the receiving devices (104) using multicast or unicast push mechanisms or downloaded by the receiving devices using unicast poll-pull mechanisms. When using push mechanisms, the announcements are repeatedly sent to all the receiving devices as long as the corresponding event is active to increase the chances of delivery to all receiving devices. When using polling mechanism, the receiving devices poll Messaging framework at intervals determined by Messaging framework on a per receiving device basis to retrieve a list of new announcements since last poll

Description

A SCALABLE UNIFIED FRAMEWORK FOR MESSAGING USING MULTICAST AND UNICAST METHODS

CROSS REFERENCE TO RELATED APPLICATIONS

[1001] This application claims priority from U.S. Provisional Application Serial No. 60/801 ,781 , filed May 19, 2006, which is hereby incorporated by reference in its entirety as if fully set forth herein.

BACKGROUND OF THE INVENTION

Field of the Invention

[1002] This invention relates to Internet Protocol television (IPTV) systems. More particularly, the invention relates to systems and methods for messaging using multicast and unicast methods in an IPTV system.

Description of the Related Art

[1003] Internet Protocol television (IPTV) systems are often concerned with the distribution of messages to clients. In some systems, a multicast approach is taken. In multicast, a sender sends a single copy of a file or other content to selected multiple recipients who have joined a multicast group. Multicast packets are replicated in the network by multicast enabled routers.

[1004] However, in some IPTV systems, multicast is not very reliable or may be unavailable. For instance, in some DSL based IPTV implementations, there may not be enough virtual circuits (VCs) to support any multicast file carousels. In these cases, all the available virtual circuits are dedicated for television channels or for video-on-demand (VOD) movies.

SUMMARY OF THE INVENTION

[1005] These and other disadvantages in the prior art are overcome in large part by systems and methods according to embodiments of the present invention.

Embodiments of the present invention relate to a messaging framework that allows applications to send messages. In particular, the messaging framework provides for the delivery of announcements and files over multicast and unicast. Announcements may refer to file updates, messages, commands etc. If the announcement refers to a file download, the files can be made available to a multicast data carousel for multicast download. A receiving device can fall back to a unicast download if the multicast is not available.

[1006] The format of the event description in the announcement is described by an extensible format called EventMetadata. Announcements can be pushed to the receiving devices using multicast or unicast push mechanisms or downloaded by the receiving devices using unicast poll-pull mechanisms. When using push mechanisms, the announcements are repeatedly sent to all the receiving devices as long as the corresponding event is active to increase the chances of delivery to all receiving devices. When using polling mechanism, the receiving devices poll Messaging framework at intervals determined by Messaging framework on a per receiving device basis to retrieve a list of new announcements since last poll.

[1007] A method according to embodiments of the present invention includes determining that the messaging framework delivers multicast push, unicast push and unicast pull/poll messaging. Unicast pull/poll messaging embodies a client/server protocol of a client reporting the successful receipt of announcement and the server replying with any newer announcements for this client.

[1008] A system according to embodiments of the present invention includes a network; a plurality of user devices operably coupled to the network; a server operably coupled to the network and configured to transmit one or more files to the plurality of user devices using multicast and/or unicast transmission. In some embodiments, the plurality of user devices comprise Internet television client terminals. [1009] A system according to embodiments of the present invention includes a plurality of client devices configured to receive one or more video streams; a messaging framework for transmitting one or more announcements about events and files to the plurality of client devices using multicast and/or unicast transport. In some embodiments, the plurality of unicast transmissions comprise serial transmissions of one or more files to the plurality of user devices while an event is active. In some embodiments, the plurality of unicast transmissions comprise serial transmissions of the one or more files to the plurality of user devices after a polling to retrieve a list of new files since previous polling.

BRIEF DESCRIPTION OF THE DRAWINGS

[1010] The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[1011] FIG. 1 illustrates an exemplary system according to an embodiment of the present invention.

[1012] FIG. 2 is a flowchart illustrating operation of an embodiment of the present invention.

[1013] FIG. 3A and FIG. 3B are a flowcharts illustrating operation of embodiments of the present invention.

[1014] FIG. 4A - FIG. 4C illustrate exemplary client, announcement, and linkage tables for use with a system in accordance with embodiments of the present invention.

[1015] FIG. 5A-FIG. 5B illustrate an exemplary media distribution system that may be used in with a personal video recorder system according to embodiments of the present invention.

[1016] FIG. 6A- FIG. 6B is a diagrammatic representation of a device and system that may be used to implement methods according to embodiments of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[1017] Embodiments of the present invention relate to a messaging framework in an Internet Protocol television (IPTV) system that allow applications to send messages using unicast or multicast transport. When using unicast transport, messages can be sent to a single receiving device or a set of receiving devices. When using multicast transport, messages are delivered to all reachable clients. Embodiments of the present invention support multicast messaging via group expressions that are evaluated on each receiving device.

[1018] According to some embodiments of the present invention, messages are transmitted in "announcements." Announcements can either completely embed the message, e.g., in the case of short messages or data carousel file streams, or refer to a message that is accessible separately as in, e.g., the case of advertisements that contain significant amounts of content.

[1019] Several types of messages can be provided. In some embodiments, these include messages about "events," such as files being streamed on the data carousel; operator-to-subscriber messages such as notification about service outages, bill payment reminders; commands to be executed on the receiving device; advertisements, etc. These messages may contain metadata descriptions of advertisements or notifications including the metadata. When event status or description changes, the corresponding messages are updated to reflect the changes.

[1020] If a message contains a file to download, the files can be made available on a multicast data carousel (MDC) for multicast download. Also, according to some embodiments of the present invention, a fallback unicast download location is provided. This allows a receiving device to fall back on unicast downloads in case multicast download fails. The unicast download location may be on the application repository, as will be explained in greater detail below. As will be explained in greater detail below, announcements can be pushed to the receiving devices using multicast or unicast push techniques or downloaded by the receiving devices using unicast poll-pull techniques. When using push techniques, the announcements are repeatedly sent to all the receiving devices as long as the corresponding event is active to increase the chances of delivery to all receiving devices. When unicast polling is enabled, the receiving devices poll a server-side messaging framework on a per receiving device basis to retrieve a list of new announcements since the last poll. They will then access the unicast download on the application repository.

[1021] When a receiving device processes an announcement, it validates the authenticity of the originating source and integrity of the announcement. In the case of multicast transport, if a group expression is included in the announcement, it is evaluated to determine whether the receiving device belongs to the group defined by the group expression. The announcement is then forwarded to listening applications that match certain metadata included in the announcement, such as category name and attributes.

[1022] Turning now to the drawings and, with particular attention to FIG. 1 , a diagram of a system in accordance with embodiments of the present invention and generally identified with the reference numeral 100 is shown.

[1023] The messaging framework system 100 includes a server side messaging framework (sMF) 102 and a client side messaging framework (cMF) 104. The sMF 102 provides interfaces to applications 114 to send announcements. The sMF 102 is coupled to an application repository 112 where files to download may be stored; and receives announcements from one or more server applications 114. The application repository 112 may also act as a hosting server to enable a unicast download.

[1024] In the embodiment illustrated, the server side messaging framework 102 includes an sMF controller 106, a multicast messaging framework server (MMDDF) 108 and a unicast messaging framework server (UMDDF) 110. It is noted that while shown separately, in practice, the servers, the control unit, the application and application repository may be integrated into the same unit or housing.

[1025] As will be explained in greater detail below, the MMDDF 108 implements a multicast announcement server (MAS) 124 and multicast data carousel (MDC) 126. The MAS 124 allows for multicast transmission of announcements, while the MDC 126 allows for multicast transmission of files by interleaving the files into a repeating pattern. The UMDDF 110 implements a polling mechanism 128 to allow receiving device clients to poll for new announcements and a push mechanism 130 to distribute announcements.

[1026] The cMF 104 provides interfaces to listeners on receiving devices to register interest in announcements and receive matching ones. The cMF 104 thus receives announcements and forwards them to interested client applications 122. The cMF 104 includes a multicast listener 120 and a unicast listener 118, which forward received announcements to an announcement handler 116, which communicates with the client application 122. The listeners 120, 118 may be any Java object that implements appropriate interfaces. The cMF 104 and application 122 may be implemented on a receiving device such as a set top box or other device.

[1027] In operation, a server-side application 114 sends the sMF controller 106 an announcement. As discussed above, the announcement can include reference to a file for downloading, which can be accessed via the application repository 112. The sMF controller 106 may specify whether the announcement is to be sent via multicast or via unicast. In some embodiments, the sMF controller 106 will further specify whether the unicast should be a client polling and pulling technique, or a push technique. The transmission of the announcement is then handled by the MMDDF 108 or the UMDDF 110, depending on whether multicast or unicast is selected. Typically, a unicast technique is selected if a multicast is not available. [1028] Announcements are uniquely identified by an announcement-id. The announcement-id may simply be a 32/64 bit number. In some embodiments, the announcement-id is used solely for the purpose of uniquely identifying an announcement and does not imply an order. Announcements may have an expiration time associated with them. In some embodiments, the messaging framework can specify a default configurable expiration time (e.g., 1 year). In some embodiments, for versioned content, every new version gets a new announcement-id.

[1029] In certain embodiments, multicast announcements are pushed over an IP multicast address. The session announcement protocol (SAP) may be used with Session Description Protocol (SDP) content (which may be extended by using extension attributes); SAP messages are sent by default on a predetermined IP address. The SDP content (session name, session id, and version) specifies event metadata. XML can be used for describing event metadata as well.

[1030] In some embodiments, the sMF 102 interfaces to request announcements are independent of the metadata . SAP/SDP may be used to describe the announcement in both the unicast and multicast cases. An application adds an announcement using a method referred to as an AddAnnouncement method. In order to allow the updating of the announcement, the AddAnnouncement method returns a "handle." This handle object has a generated UID that the server can use to map to a category, session-id, EventMetaData version, unicast/multicast call. This allows the server to check whether or not an update request is from the same client (app-s 114).

[1031] In certain embodiments, every announcement has an associated category. The cMF 104 listeners receive announcements by registering to a category. A category is uniquely identified by its name and version. Attributes are name-value pairs that describe events. A category is well- defined to prevent namespace collisions. Every category contains one reserved attribute "keyword" that should be used to include comma separated search-tags. Receiving devices can use these search tags in order to filter announcements.

[1032] A well-known category can be shared by multiple applications. The set of attributes of a well-known category cannot be modified. The sMF 102 defines a set of well-known categories that correspond to predetermined well- known uses, such as file, advertisement, command, notification, etc. An application is also allowed to define its own categories for private, non-shared use.

[1033] When the cMF 104 receives an announcement, it captures the event description into an EventMetaData object that includes a category name and attributes. It then forwards it to one or more applications that registered interest in that particular category.

[1034] As noted above, a multicast data carousel (MDC) 126 may be used to deliver files over multicast and can be used by a client to download files. In such a data carousel implementation 126, a file is divided into numbered blocks and the blocks are encapsulated in user datagram protocol (UDP) packets and sent using IP multicast. The receiving device 104 will reassemble the blocks either in memory or in persistent storage, verify the integrity of the reassembled file by calculating a file digest using a one-way hash function such as MD5, SHA-1 etc and comparing it with the file digest specified in the corresponding announcement.

[1035] In some embodiments, the receiving device acquires the download information for the multicast data carousel 126 based on the data carousel metadata inside an announcement. The metadata can contain the address, port, file block size, number of blocks, digest and digest algorithm. This information can be used by the cMF 104 to enable an application 122 to download a file into a datasink. (A datasink can be, e.g., a file on disk, a String, a byte[], or other user-defined implementation).

[1036] In operation, the unicast distribution of announcements can be done via a client polling and pulling technique, or a push-to-client technique. In the poll-pull technique, as will be explained in greater detail below, the receiving device polls the messaging framework for desired announcements at certain times. The messaging framework will return a list of available announcements. The receiving device can then pull any associated files from the application repository 112. In the push technique, as will be explained in greater detail below, the server pushes announcements to the receiving devices at a rate constrained by configured bandwidth limit.

[1037] As noted above, in some embodiments, a messaging framework IOOaccording to the present invention will simultaneously support both multicast and unicast sending of announcements. In such embodiments, the system may be configured such that either can be switched off. When both are enabled, the unicast push mechanism can be switched off to save bandwidth. In some embodiments, a network operator may also have the option to tune the amount of bandwidth used by the push mechanism and the MDC data carousel by adjusting the repetition rates of announcements.

[1038] Operation of the multicast mode is illustrated with reference to FIG. 2, in which a flowchart 200 illustrating operation of embodiment of the present invention is shown. The particular arrangement of elements in the flowchart 200 is not meant to imply a fixed order to the elements; embodiments can be practiced in any order that is practicable.

[1039] In a process step 202, a server-side application 114 sends an announcement to the sMF control unit 106. As discussed above, such an announcement can include messages related to operator-to-client issues, or files, etc. In a process step 204, the MMDDF 108 or sMF 106 determines that multicast is available and multicasts the announcement to group members. In a process step 206, a client device's multicast listener 120 receives the announcement. In a step 208, the announcement handler 116 sends the announcement to the client application 122, if the application has registered to receive it. In a process step 210, the client determines if a file is attached/included. If not, the client 122 will process the announcement, in a process step 212. Otherwise, however, in a process step 214, the client application 122 will read the announcement metadata for MDC information, such as, e.g., address, port, file block size, number of blocks, digest, and digest algorithm. This information is used in a process step 216 to download the file(s).

[1040] Operation of the unicast modes is illustrated with reference to FIG. 3A and FIG. 3B. In particular, as noted above, the unicast methods are implemented if multicast is not available. In particular, as will be explained in greater detail below, a poll-pull technique and a push technique may be used. The unicast push technique may preferably be used in the case of transmission of relatively urgent messages.

[1041] Turning now to FIG. 3A, a flowchart 300 illustrating operation of embodiment of the present invention is shown. The particular arrangement of elements in the flowchart 300 is not meant to imply a fixed order to the elements; embodiments can be practiced in any order that is practicable. In particular, FIG. 3A illustrates the poll-pull technique of the present invention.

[1042] In a process step 302, a client polls the messaging framework. In particular, the client application 122 can register to have the unicast listener poll the sMF 102. The poll message can include, for example, an authentication and a list of the announcements the client 122 has received since the last poll. In a process step 304, the sMF's UMDDF 110 sends a list of pending announcements. In a process step 306, the pending announcements can be downloaded to the client. Files can be received, e.g., via an URL to the application repository.

[1043] Turning now to FIG. 3B, a flowchart 350 illustrating operation of embodiment of the present invention is shown. The particular arrangement of elements in the flowchart 350 is not meant to imply a fixed order to the elements; embodiments can be practiced in any order that is practicable. In particular, FIG. 3B illustrates the unicast push technique of the present invention.

[1044] In a process step 352, the sMF 106 identifies a push message. In a process step 354, the sMF accesses or reads a list of target devices. In a process step 356, the sMF serially transmits the announcement to the listed targets. This may be repeated a preconfigured number of times.

[1045] Operation of the unicast modes of specific embodiments of the present invention may be explained in greater detail with reference to the tables of FIG. 4A-FIG. 4C. In particular, shown in FIG. 4A is a client table 400 that is indexed by client ID and identifies a client to which a message is to be sent and a time of polling associated therewith. Shown in FIG. 4B is an announcement table 402 that is indexed by announcement-id and identifies an associated data file, an expiration time, and which devices are to receive the announcement (e.g., whether the announcement is to be sent to all user devices). FIG. 4C illustrates a linkage table 404 which identifies pending announcements.

[1046] In some embodiments, the messaging framework 10Opersistently stores in a database all announcements and a list of client Ids 400 to which they must be sent. The client Ids may be mapped to IP addresses using a local cache of the ACS database (not shown). The cache is kept up to date by a polling thread from the messaging framework to the ACS.

[1047] The client receiving device 104 keeps track of which announcements it has received since its last poll. These can be unicast pushed or pulled announcements, as well as multicast announcements. When the client polls the messaging framework sMF 106, the client will report this list of recently completed announcements. The messaging framework updates its tables and responds with any newer pending announcements.

[1048] When an announcement is added without a target list (in case of multicast), for each entry in the client table 400, an entry in the linkage table 404 is added. This processing may be done in multiple batches so as not to block database access. It is noted that a possibility exists that a race condition could occur when the sMF 106 is still processing the batches and a client comes polling, whose new record is not yet written in the database. However, since the sMF is in charge of giving the receiving devices the timestamp for when to return polling, it can take this possibility into account.

[1049] Receiving devices that have not yet pulled from the server 102 will not be present in the client table 400. To solve this, once an unknown receiving device pulls, the messaging framework will add an entry into the linkage table 404 for each announcement that was received without a target list. For this reason, the column send_to_all is used.

[1050] In the poll-pull technique, the client polls the messaging framework 102 at certain times as specified by the messaging framework 102 on the last poll. If its user interface (not shown) is not active, it will wait for the user interface to activate until the poll is sent. The polling may be done by sending client authentication information and the list of announcement-ids that it retrieved since the last poll action. These announcement-ids can be received by both unicast and multicast.

[1051] Whenever the messaging framework gets a poll from a client, it will remove all entries in the linkage table 404 that were notified to be already retrieved, remove all entries from the announcement table 402 that are expired, and then return a list of announcements that remain in the linkage table 404. This list is then sent in the response message, together with a time instance for when the next poll is to be scheduled. Because the messaging framework is in control of this time instance, it can load-balance its amount of traffic equally over time.

[1052] In the timeframe between this poll action, and the next-poll time instance, the client will be allowed a configurable number of poll actions, These actions can be triggered by a reboot, a Ul opening or a Ul refresh action. The reason for restricting the number of times a client can poll is to prevent a denial of service attack wherein a rogue client can repeatedly poll at a very high rate.

[1053] An announcement is pushed by the messaging framework when this is indicated by the server application. This can, for example, be used to send time critical notifications to a series of users. The messaging framework 102 will sequentially send out the announcement to the list of targets related to the announcement. A target must contain a client-ID. If no targets are specified, the messaging framework will not send out the announcement to anyone. If an application 114 wants to send announcements to all users, it should employ the multicast interface. The announcement sent to the receiving device will contain the client ID in order to detect if the announcement was really intended for the particular device (IP addresses on receiving devices may change).

[1054] In certain embodiments, the repetition rate of the sequences, and the number of times an announcement is sent in a given sequence, may be specified. This repeated sending on one timestamp is to take into account the possibility of message loss in UDP.

[1055] As discussed above, embodiments of the present invention are suited to an internet protocol media distribution system. FIG. 5A depicts a representative environment according to the invention. Central to FIG. 5A is a network with ATM network backbone 500. This ATM network is capable of fiber data rates of OC3, OC12, OC48, OC192 or as is available in the art. A plurality of content providers place information onto ATM network 500. Typical sources of content served include broadcast information 502, Internet information 504, telenetwork 506, broadcast content 508, and video 510.

[1056] In a representative central plant, a plurality of ATM switches 512 interface with network 500 to receive and distribute data from the various content sources. A server side messaging framework 102 as well as application (s) 114 and repository 112, in accordance with embodiments of the present invention may be located upnetwork from the end user. Information flows from ATM switches 512 via a plurality of paths 513 to a plurality of DSL modems 514. DSL modems 514 connect via DSL twisted pair lines 518 to a plurality of modems 516 in various subscribers residences or establishments. From a representative modem 516, there can be attached a telephone 520 and/or a television set 108 which may include and associated set top box 522, and/or a computer 524. The client side messaging framework 104 and client applications 122 of embodiments of the present invention may thus be operable on or in association with devices such as telephone 520, television with set top box 522, and/or computer 524.

[1057] FIG. 5B depicts an overview of a digital programming content distribution system according to a particular embodiment of the present invention. One or more central channel server(s) 580, which may implement the messaging framework 102, server-side applications 114, and repository 112, described herein, collect(s) information about available programming services distributed from a multiplicity of content providers 560. In a preferable embodiment, this information is multicast by the content providers. Channel server 580 maintains a channel list database 570 which tracks available content channel offerings and a subscriber database 580, which contains subscriber identifications and permitted channels for each subscriber. Subscribers interact with central channel server 580 to obtain programming content information, and with content providers 560 to obtain programs. The messaging framework 102 may be implemented as part of or in conjunction with the central channel servers 550. Alternatively, the messaging framework 102 may be implemented in conjunction with the central office. In related embodiments, the channel server 580 and content providers 560 may be co-located on the same machine, or may reside on separate machines. Further, as noted above, the television with set top box 590 may implement the client side messaging framework 104 and applications 122.

[1058] In a representative embodiment, the invention may be practiced using a control system with the basic subsystems and functions depicted in FIG. 6A. In particular, the control unit of FIG. 6A represents, for example, a client device, such as a set top box for implementing the client side messaging framework, or a server for implementing the server side.

[1059] In the representative system of FIG. 6A, a set top or control unit 10 includes bus 12, which is shown schematically as a single bus, but can also be a number of buses such as a local bus and one or more expansion buses (e.g., ADB, SCSI, ISA, EISA, MCA, NuBus, or PCI), which interconnect subsystems such as a central processor 14, which may be an 80x89, 98xxx, RISC, Pentium family, or other suitable microprocessor family, system memory 19, which may be RAM, ROM, or a combination thereof, input/output (I/O) controller 18, an external device such as a serial port 28, such as a USB port, and parallel port 32, detachable keyboard 30, mouse 29, fixed disk drive 32, which may be a hard disk drive or an optical drive or a CD-ROM or DVD- ROM drive or other suitable medium; and a floppy disk drive 33 operative to receive a floppy disk.

[1060] Network connections are usually established through one or more network adapters 44 attached to one of the buses or a modem on a serial port. Network adapters may include 10 Base T, 100 Base T, optical, ATM, DSL, or other network formats.

[1061] MPEG decoder 39 and audio subsystem 42 coupled via bus 12 provide multimedia capability. Many other devices can be connected such as fax 38 connected via serial port 28, touch screen 40 connected directly, infrared peripheral support 34 or printer 20, connected through parallel port 22. Other devices or subsystems (not shown) may be connected in a similar manner. Also, it is not necessary for all of the devices shown in FIG. 6A to be present to practice the invention. The devices and subsystems may be interconnected in different ways from that shown in FIG. 6A without impairing the operation of the system. Source code to implement processing functions in accordance with the present invention may be operably disposed in system memory 16 or stored on storage media such as fixed disk 32 or floppy disk 33.

[1062] Video interface 33 may be any standard video format, such as S- video. Various forms of user input devices may be used with the set top box and/or IRS. For example, a touch screen allows a user to point to objects on the screen to select the object and to move the selected object by pointing to a second position on the screen. Alternatively, an infrared or other coupled handheld control unit may be interfaced with the unit allowing the user to interact with the unit, make changes, and indicate preferences. Various buttons and controls may be displayed on the screen for activation by using the mouse, touch screen, or a remote control via infrared IF 34.

[1063] Operatively disposed in memory 19, or resident on fixed disk 32, operating system software may be PSOS₁ DOS, UNIX, WINDOWS95, WINDOWS CE, WINDOWS XP, or other operating systems known in the art. Executing concurrently and cooperatively with operating system software 710 (FIG. 7B), IP Multicast capable TCP/IP software 712 manages the flow of information into and out of the control unit over the network interface 44. A JAVA enabled Internet browser 714, such as Netscape Navigator Microsoft Explorer or their equivalent in the art provide a web-browser user interface to networked resources through TCP/IP software 712.

[1064] Client control code 619 implements functions specific to the set top box or server operation, such as the processes depicted herein. Output is provided by user interface 618 in conjunction with Video Interface Code 620. Other clients 622 such as Email, facsimile, video conferencing applications or voice mail may also be supported.

[1065] In a related embodiment, the functions of the set top unit are integrated into a television, forming an Internet capable, interactive "Smart Television." In a related embodiment, the functions of the set top unit are integrated into a personal computer, forming an Internet: capable, interactive "Workstation Television."

[1066] As used herein, whether in the above description or the following claims, the terms "comprising," "including," "carrying," "having," "containing," "involving," and the like are to be understood to be open-ended, that is, to mean including but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of," respectively, shall be considered exclusionary transitional phrases, as set forth, with respect to claims, in the United States Patent Office Manual of Patent Examining Procedures (Eighth Edition, August 2001 as revised October 2005), Section 2111.03.

[1067] Any use of ordinal terms such as "first," "second," "third," etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another, or the temporal order in which acts of a method are performed. Rather, unless specifically stated otherwise, such ordinal terms are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term).

[1068] The above described preferred embodiments are intended to illustrate the principles of the invention, but not to limit the scope of the invention. Various other embodiments and modifications to these preferred embodiments may be made by those skilled in the art without departing from the scope of the present invention.

Claims

What is claimed is:

1. A method, characterized by: determining that a multicast download for a download of one or more files is unavailable; and providing a unicast alternative for the download if the multicast download is unavailable.

2. A method in accordance with claim 1 , said unicast alternative comprising a poll-pull alternative.

3. A method in accordance with claim 1 , said unicast alternative comprising a push alternative.

4. A method in accordance with claim 1 , said providing a unicast alternative including specifying a poll-pull or push unicast alternative.

5. A system, characterized by: a network (500); a plurality of user devices (516, 522, 524) operably coupled to the network; a server (102) operably coupled to the network and configured to transmit one or more files to the plurality of user devices (516, 522, 524) using multicast transmission and/or using a unicast transmission.

6. A system in accordance with claim 5, wherein the plurality of user devices comprise Internet television client terminals (522).

7. A system in accordance with claim 6, wherein the unicast transmission comprises a poll-pull transmission.

8. A system in accordance with claim 6, wherein the unicast transmission comprises a push transmission.

9. A system in accordance with claim 6, wherein server is configured to specify a push transmission or a poll-pull transmission.

10. A system in accordance with claim 8, wherein the push transmission comprises the server transmitting one or more files to each of the plurality of clients in a serial fashion.

11. A system, characterized by: a plurality of client devices (522) configured to receive one or more video streams; a messaging framework (100) for transmitting one or more files to the plurality of client devices in a multicast transmission and, if multicast transmission is not available, in a plurality of unicast transmissions.

12. A system in accordance with claim 11 , wherein said plurality of unicast transmissions comprise serial transmissions of one or more files to the plurality of user devices (522) while an event is active.

13. A system in accordance with claim 11 , wherein said plurality of unicast transmissions comprise serial transmissions of one or more files to the plurality of user devices (522) after a polling to retrieve a list of new files since previous polling.

14. A system in accordance with claim 11 , wherein said plurality of client devices (522) comprise Internet Protocol television receivers.