System and method for user-initiated group messaging

Description of equivalent WO 2004049737 A2

SYSTEM AND METHOD FOR USER-INITIATED GROUP MESSAGING

Field of Invention

This invention relates to systems and methods for data distribution.

Background Information

In recent years, there has been an increase in the use of wired and wireless networks for messaging. Such messaging includes, for example, email, SMS (Short Message Service), and MMS (Multimedia Messaging Service). Although distribution of text remains a popular use of messaging, the use of messaging as a way to distribute content types such as video, audio, and images as been gaining favor as well. MMS, in particular, has been gaining popularity as a way to distribute such content types.

In light of this, there may be interest in technologies applicable to messaging.

Summary of the Invention

According to embodiments of the present invention, there are provided systems and methods that allow a user to establish a Multicast Group Messaging (MGM) session wherein messages are delivered via multicast, and wherein the user may exercise control over the parties that can receive the multicasted messages.

The systems and methods further provide for dispatching messages for multicast in conjunction with the session, and for receiving messages multicast in conjunction with the session. Brief Description of the Drawings

Fig. 1 shows an exemplary network arrangement according to embodiments of the present invention.

Fig. 2 is a flow chart showing steps involved in messaging setup according to various embodiments of the present invention.

Fig. 3 is a flow chart showing steps involved in terminal receipt and forwarding of Multicast Group Messaging (MGM) session information according to various embodiments of the present invention.

Fig. 4 is a flow chart showing steps involved in message multicast according to various embodiments of the present invention.

Fig. 5 is a flow chart showing steps involved in message reception according to various embodiments of the present invention.

Fig. 6 shows an exemplary general purpose computer employable in various embodiments of the present invention.

Fig. 7 shows a functional block diagram of an exemplary terminal employable in various embodiments of the present invention.

Detailed Description of the Invention

General Operation

According to embodiments of the present invention, a user may establish a Multicast Group Messaging (MGM) session wherein messages are delivered via multicast, and wherein she may exercise control over the parties that can consume the multicasted messages. More specifically, the user might establish such an MGM session by having her terminal dispatch an appropriate request to an MGM server. Included in the server's response to the request may be a key employable in decrypting messages multicast in conjunction with the MGM session. The user may then distribute the key and/or additional information to the parties she wishes to have the ability to consume messages multicast in conjunction with the session. The user might additionally specify if those parties forwarded the key and/or additional information may further disseminate that key and/or additional information to others.

Shown in Fig. 1 is an exemplary network configuration according to embodiments of the present invention, including MGM server 101, terminals 103, access point 105, and multicast point 107. As alluded to above, and as will be described in greater detail below, a terminal 103 could request from MGM server 101, via access point 105, establishment of an MGM session. Access point 105 could be, for example, a UMTS (Universal Mobile Telecommunications Service), GPRS (General Packet Radio Service), or internet access point.

The requesting terminal 103 could receive the key and/or additional information from MGM server 101 via access point 105. The requesting terminal could then forward the key and/or additional information to one or more terminals 103. Messages to be multicast could be dispatched by a terminal 103 to MGM server 101 via access point 105, encrypted by the MGM server, and then multicasted via multicast point 107 for consumption by appropriate terminals 103. Multicast point 107 could be, for instance, a unidirectional multicast point such as a DVB-T (Digital Video Broadcast - Terrestrial), DVB-S (Digital Video Broadcast - Satellite), or DAB (Digital Audio Broadcast) multicast point. In various embodiments, the multicast point might instead employ a Didirectional technique such as UMTS.

It is noted that, in various embodiments of the present invention, there could be greater or fewer of each of elements 101-107 than is illustrated in exemplary Fig. 1. For instance, there could be a plurality of each of elements 101-107.

Various aspects of the present invention will now be described in greater detail

Request for Messaging Setup

A user wishing to initiate an MGM session may employ her terminal to request such from an MGM server or the like. The request could include certain specifications such as the start and end time desired for the MGM session, the regions in which multicasted messages should be receivable, a specification or suggestion of what type of encryption should be used in message multicast, and/or a suggestion or specification of the messaging address that should be established for submitting messages for multicast. According to various embodiments of the invention, there are a number of ways the user could submit the request to the appropriate server.

According to certain embodiments, the user could submit the request by manually creating and dispatching a message to an appropriate email, SMS (Short Message Service), MMS (Multimedia Messaging Service), or other messaging address. For example, it could be established that such a request should be dispatched as an SMS message directed to "MGMsetupf@messaging.serviceprovider.com".

Such a request might be required to be in a certain form. For example, the request message may be required to include one or more lines in the form of "attribute: value", with there being a number of acceptable attribute keywords and acceptable corresponding values or ranges of values. For instance, one attribute could be "StartTime". The corresponding value could be specified to be in the form "dd.mm.yyyy;hh:nn;zzz", with "dd" corresponding to standard two- αign mαication ior αay-ol-month, "mm" corresponding to standard two-digit indication for month, "yyyy" corresponding to standard four-digit indication for year, "hh" corresponding to standard two-digit indication for hour, "nn" corresponding to standard two-digit indication for minute, and "zzz" corresponding to standard three-character indication for time zone. Accordingly, a user wishing to request MGM commencing at October 23, 2005 at 1 :36pm European Central Time might include in her request message the line "10.23.2005; 13:36;ECT". Similar attributes and corresponding values could be established for other specifications of the sort mentioned above, such as regions or session end time.

Such a manual request might alternately or additionally be permitted to be in free- form and/or natural language form. In such a case, the user might be required to indicate certain informational elements (e.g., MGM session start time), but could choose her presentation form. Accordingly, the inclusion of "I wish to start today at 12:23pm" in the request could be an acceptable specification of start time.

Further to manual submission of an MGM session request, embodiments of the present invention could, additionally or alternately, allow the user to submit the session request via an interface. In the case where submission is via an interface, one or more presentation program modules operating on the user's terminal could present, for example, a graphical user interface (GUI) that the user could employ to submit required information regarding her MGM request.

For example, the one or more presentation modules could present a GUI with which the user could choose, for instance, start time, end time, regions in which multicasted messages should be receivable, and the like. The GUI could additionally allow the user to select and/or specify the MGM server, MGM servers, or the like to which the request should be suomi teα. in e case where the user is presented with a list from which to select one or more recipient MGM servers or the like, the list could be populated, for instance, by having one or more server discovery program modules operating on the terminal access a provider of such information. In accessing the provider, the modules might employ SOAP (Simple Object Access Protocol), JMS (Java Messaging Service), RMI (Remote Method Invocation), or the like.

Having collected from the user, via an interface, the information necessary to place in an MGM request, one or more request dispatch program modules operating on the terminal could forward the request to the one or more appropriate MGM servers or the like. This could be performed in a number of ways. For instance, the one or more request dispatch program modules could encode the information collected from the user into a text message and dispatch the message via email, SMS, MMS, or the like, directed to the appropriate server. The encoding could, for instance, employ XML (extensible Markup Language). In, for example, embodiments providing the above-described functionality whereby a user can manually submit MGM request information in an SMS message or the like, the one more program modules could encode the message in compliance with any specified format. Such specified format may employ, for example, the above-described "attribute: value" format.

As another example, the one or more request dispatch program modules could communicate the information collected from the user to the appropriate MGM server or the like via SOAP, JMS, RMI or the like.

Messaging Setup

As illustrated in Fig. 2, an MGM server or the like, as noted above, may receive from a terminal a request for an MGM session that includes a number of specifications (step 201).

In the case where the session request is received via a SMS message, MMS message, email message, or the like directed to a particular messaging address associated with the server, one or more request receiving program modules running on the server could act to extract from the message the specifications contained therein (step 203).

Where the specifications are encoded into the message via a specified format, the one or more request receiving modules could act to extract the specifications in accordance with the format. For instance, in the case where the specifications are in the above-noted "attribute:value" format, the one or more modules could scan the incoming message for the defined attributes and note the corresponding values. In the case where one or more necessary informational elements, or portions thereof, were missing from a request, an error message could be returned to the submitting user and/or terminal, perhaps via the same transport method (e.g., SMS) that was used to dispatch the session request.

Alternately, the request receiving modules might make an attempt to guess missing data. For example, if a start time was expressed in hours and minutes, but without indication of date or time zone, the modules might make the assumption that the time zone was the user's local time zone. Further, in the case where the indicated time had not yet happened that day, the modules might make the assumption that the unspecified date was that day. On the other hand, in the case where the indicated time had already passed that day, the date could be assumed to be the following day. In the case of missing information, where no guess or satisfactory guess could be made by the modules or in embodiments where the modules performed no such guessing function, an error message could be returned to the requesting user and/or terminal in a manner like that described above. Where the specifications were entered by a user in a free-form and/or unstructured way, the one or more request receiving modules could employ natural language interpretation and/or parsing techniques known in the art to extract the specifications contained in the message. Because of the free-form nature of such a request, users might intentionally or unintentionally omit certain information. For example, a user specifying start and end time might omit date, year, and time zone, perhaps believing these to be inherent or obvious. In certain embodiments, the request processing modules could attempt to guess missing data as above. In the case of missing information, where no guess or satisfactory guess could be made by the modules or in embodiments where the modules performed no such guessing function, an error message could be returned to the requesting user and/or terminal in a manner like that described above.

In the case where informational elements were passed to the server by modules running on the terminal, perhaps via SOAP, JMS, or the like, request receiving modules running on the terminal could directly receive the passed elements without needed to perform parsing or the like of the sort described above.

Once in possession, via one of the ways just described, of the MGM session request specifications, the request receiving modules could place the specifications in an associated store (step 205). Also placed here could be an indication of the user and/or terminal that made the request. The indication could be, for example, the user's MMS address. Such could be determined, for example, by examining the headers if the session request message or by analyzing the SOAP, JMS, RMI, or similar communications. The items placed in the store could then be processed by one or more request handler modules running on the MGM server or the like. As a first step, the one or more request handler modules could act to determine a multicast address, such as a multicast IP (Internet Protocol) address, to employ in multicast group messaging (step 207). The multicast address could, for example, be chosen from a pool of available multicast addresses, perhaps with the intention that the address would be returned to the pool once the requested MGM session was complete. The one or more request handler modules might take into account one or more received specifications in making the selection from the pool. For instance, start time, end time, and/or region could be considered. Upon choosing the multicast address, the one or more request handler modules could remove the address form the pool of available addresses.

As a next step, the one or more request handler modules could establish a messaging address, such as an email address, SMS address, or MMS address, for receiving messages to be multicast, (step 209). The one or more request handler modules might choose the messaging address from a pool of available messaging addresses. In the case where the received specifications included a user's suggestion for the messaging address, the modules might take this into account when selecting a messaging address from the pool. For instance, if there was a suggestion that the messaging address include the phrase "gaming chat", the modules might look for an available messaging address containing the phrase or closely matching the phrase.

Instead of choosing the messaging address from a pool, the one or more request handler modules might newly establish a messaging address. In the case where the received informational elements specified a user's suggestion and/or specification for the messaging address, the newly established messaging address could be in accordance with the specification and/or suggestion. In establishing a new messaging address the one or more request handler modules might take steps so that messages directed to the messaging address would be received by the MGM server, and/or have an appropriate messaging account established on an integrated and or separate SMS server, MMS server, or the like. The one or more request handler modules might also take steps to have the account removed from the appropriate MMS server or the like upon termination of the MGM session.

As a next step, the one or more request handler modules could specify, in an associated store, a correlation between the multicasting address and the messaging address (step 211). Next, the one or more request handler modules might determine a schedule for multicasts within the MGM session (step 213). For instance, it might be determined that multicasts would occur every fifth minute within an hour (e.g., 5:05pm, 5:10pm, 5:15pm, and so on). Such a schedule might be determined with the intention of promoting energy conservation in terminals wising to receive multicasts according to the MGM session, as the terminals might only have to monitor for incoming transmission during the scheduled times.

The schedule determination could take into account, for example, the energy use characteristics of typical terminals in the regions or regions specified for the MGM session. Such characteristics could be known, for instance, by considering service provider records indicating the prevalence of specific terminal models in various regions and further considering manufacturer technical specifications regarding those terminal models.

Next, the one or more request handler modules could select or create a key to be used in decrypting messages multicast during the MGM session (step 215). The modules might also select an encryption method to employ. Alternately, one encryption method might always be used. The selection and/or creation of a key, and/or selection of encryption method, might take into account a number of factors. Among these factors may be a suggested encryption method inciuαeα in tne received specifications.

As a next step, session information relating to the messaging address, multicasting address, schedule, key, algorithm, and/or the like for the MGM session could be placed by the modules in a store associated with the server, and/or forwarded to the user who requested the MGM session and/or the user's terminal (step 217). In various embodiments of the invention, the modules might forward this session information to no entities other than the user who requested the MGM session and/or the user's terminal.

The forwarding could be done in a number of ways. For example, the information could be placed in an MMS message, SMS message, email message, or the like directed to the user who dispatched the MGM session request, and/or that user's terminal, for direct reading by that user. As another example, the information could be encoded employing XML or the like, and placed in an MMS message or the like directed to that user or her terminal. As yet another example, the information could be communicated via SOAP, JMS, RMI, or the like to one or more software modules operating on the user's terminal.

Terminal Receipt and Forwarding of MGM Session Information

Upon a terminal that dispatched an MGM session request receiving, from an MGM server, information relating to that session, one or more of several actions may take place. For instance, as illustrated in Fig. 3, a session-information-bearing MMS message, email message, or the like, directed to the terminal's user for direct reading by that user, could be retrieved, in a conventional manner, by message viewer program modules running on the terminal (step 301). The user could employ the one or more modules to read the message and could note the session information contained therein. The user could, as necessary, provide the noted information to appropriate program modules and the like running on the terminal (step 303).

In addition to or as an alternative to the user viewing the message and/or noting the session information contained therein, one or more MGM Session information extraction program modules operating on the terminal could act to extract the session information from the message. These modules could record the information and/or, as will be described in greater detail below, pass it to one or more appropriate program modules or the like operating on the terminal. The program modules could be aware of the format or formats that MGM servers use to encode session information for direct reading by users, and could employ this knowledge in extracting the session information from the message. Alternately, the modules might parse the message for session information using natural language parsing techniques or the like known in the art.

To process a received MMS message, email message, or the like containing MGM session information not particularly encoded for direct reading by users, the session information extraction modules could act in a similar manner to that just described. Such a message may, for example, be one containing session information encoded in a manner employing XML. As before, the modules could be aware of the format or formats that MGM servers employ in encoding session information, and could employ this knowledge in extracting the session information. In addition to or as an alternative to recording and/or passing the MGM session information, the modules could have the session information displayed to the user, perhaps via a GUI dialog box. The user could note the information and/or provide the information to appropriate program modules and the like running on the terminal.

In the case where the MGM server dispatches the MGM session information to the terminal by via SOAP, JMS, RMI, or the like, the session information extraction modules couiα receive tne lmormation. in a manner analogous to that noted above, the modules could act to record the information and/or pass it to one or more appropriate program modules or the like operating on the terminal. Alternately or additionally, the modules could have the information displayed to the user.

It is further noted that, upon receipt at the requesting terminal of MGM session information, actions may take place to forward the session information to one or more additional terminals. The forwarding could be performed in a number of ways. For instance, in the case where the user received an MMS message, email message, or the like with the included session information presented for direct reading, the user could forward the message to one or more other users and/or terminals, employing perhaps message sending program modules running on the terminal (step 309).

The user might interact with the modules via a GUI, voice control, or the like. In cases where the session information is presented to the user via a GUI dialog box or the like, the dialog box or the like could offer a selection to perform forwarding of the information to a specified user and/or terminal. In certain embodiments, the message sending modules could be configured so as to allow specification of whether or not the recipient of a forwarded message could further forward that message (step 305). A user could set this option, for example, via a GUI. The GUI might be the same one employable to select forwarding. In the case where it was specified that no further forwarding should be allowed, the modules could append an indication of such to the forwarded message (step 307). In such embodiments program modules operating on terminals could be configured to respect such indicators, such that a user would be disallowed from forwarding a message bearing such an indication.

In a similar manner, in various embodiments the user could be presented with the option to forward an MMS message, email message, or the like containing session information formatted employing XML or the like. For instance, a GUI dialog box presenting the session information to the user could further allow the user to specify users and/or terminals to which the information should be forwarded. As above, in certain embodiments the user might be presented with the option to disallow further forwarding of the message.

Also in a similar manner, in various embodiments the user could be presented with the option to forward MGM session information received via SOAP or the like. Such embodiments could offer an interface, such as a GUI dialog box, whereby the user could specify users and/or terminals that should receive the information. In a manner analogous to that described above, the user could be presented with the option to prevent those who receive the forwarded session information from further forwarding it. Modules running on the terminal could act to dispatch the session information, perhaps with an appended indication of no further forwarding be allowed, to the specified users and/or terminals via SOAP or the like.

Upon a terminal receiving MGM session information forwarded from another terminal, actions analogous to those described above with reference to a terminal receiving session information from an MGM server could take place. For example, the user of the receiving terminal could be presented with the forwarded session information via a dialog box or the like, and the forwarded session information could be recorded and/or passed to program modules running on the terminal. As a further example, where the received forwarded session information was not stipulated to not be further forwarded, the receiving user could be presented with the option to further forward the session information to additional terminals and/or users.

The receiving user could, perhaps, also be presented with the option to specify whether or not a recipient of the newly-forwarded information is allowed to further forward it. The terminals and or users receiving the newly-forwarded session information could analogously perform one or more of the above-described actions with regard to the information.

Message Multicast

A user wishing to have a message multicast via the MGM session may, as is illustrated in Fig. 4, act to have that message dispatched to the established messaging address (e.g., SMS address) corresponding to the session (step 401). The user could invoke a new message composition window associated with message sending modules operating on her terminal, the modules perhaps being associated with a conventional message dispatch program, such as an MMS, SMS, or email client. The user might be presented with a GUI button or the like that could be pressed to launch the composition window. The button might carry a label such as "click here to multicast a message to MGM Session x", where in place of "x" could be an identifier associated with the MGM session.

The user could, via the new composition window, add to the message under composition elements such as text, files, graphics, sounds, movies, and the like. It is noted that some embodiments of the present invention could limit the element types that could be added to a message. For instance, in some embodiments only text might be permitted.

After completing message composition, the user could specify that the message be dispatched. The user might do this, for example, by entering the established messaging address for the MGM session into a GUI field associated with the composition window. The user might then press a "send" GUI button associated with the window. Dispatch of the message to the messaging address could be in accordance with the transport methods known in the art for the messaging address type (e.g., SMS).

It is noted that, in certain embodiments, the user might not need to specify the estaonshed messaging address. This could be the case, for instance, in the above-noted embodiments where software modules or the like running on a terminal were made aware of received session information. It is further noted that functionality might be provided whereby session start and end times could be taken into account by software modules running on the terminal of the user wishing to multicast a message. For instance, the software modules might prevent the creation and/or dispatch of a message to be multicast in a session unless the start and stop times indicated the session to be active or to soon be active.

Upon receipt at the MGM server or the like of the message to be multicast, one or more casting modules operating on the server might first determine the messaging address to which the message was directed (step 403). Next, the modules could access the above-noted store in order to determine the MGM session associated with the messaging address (step 405).

After this, the modules might determine if the session was active (step 407). This could be done by consulting a clock and/or calendar associated with and/or accessible by the server to determine the current time and/or date, consulting the store to determine the start and stop times associated with the session, and deciding if the present date and/or time was within and/or closely before the session period. In the case where the MGM session was found to be not be active, the terminal might stop further processing on the incoming message, and might send an SMS message or the like to the terminal and/or user that dispatched the message to be multicast (step 409). The message sent could, for example, specify that the session had expired.

Next, the one or more casting modules could consult the above-noted store to determine the multicast address associated with the MGM session (step 411). The modules might then access the store in order to determine the encryption type and/or decryption key associated with the session (step 413). The modules could next encrypt the received message for decryption with the key (step 415). After this, the modules might access the store to learn of any transmission schedule associated with the MGM session (step 417).

The one or more casting modules could next take steps to have the encrypted message multicast to the appropriate multicast address in accordance with any schedule associated with the session (step 419). The one or more casting modules could achieve this, for instance, by submitting the encrypted message, along perhaps with additional parameters, to one or more software modules operating on a multicast point. The multicast point could be, for example, a unidirectional multicast point such as a DVB-T or DVB-S multicast point. In various embodiments, the multicast point might instead employ a bidirectional technique such as UMTS. The additional parameters might specify, for example, scheduling information associated with the session and/or protocols that should be employed in the multicast.

It is noted that where a multicast schedule is associated with the MGM session, in certain embodiments the one or more casting modules operating on the MGM server might submit the message to the multicast point only at or shortly prior to a multicast time in accordance with the schedule. In such embodiments, scheduling information might not be forwarded to the multicast point. In other embodiments, the one or more casting modules might forward the message to the multicast point without particular regard to the multicast schedule, leaving the task of schedule compliance to software modules operating on the multicast point. As alluded to above, software modules of the multicast point could know of the schedule by way of additional parameters dispatched with the message to be multicast.

Having received the message to be multicast and any additional parameters, the multicast point might perform formatting or reformatting of the message and/or the elements thereof. For example, the message could be formatted or reformatted in a way that employs H ML. The multicast point might next multicast the encrypted message. As alluded to above, in some embodiments the multicast point might multicast in accordance with a schedule associated with the MGM session. The multicast could, for example, employ UHTTP (Unidirectional Hypertext Transfer Protocol).

Message Reception

As noted above, terminals and/or users may receive MGM Session Information. According to certain embodiments of the invention, such a user or a user of such a terminal who wishes to receive messages multicast in association with the MGM session may take action to have one or more message reception modules on her terminal be activated. The user could make such a specification, for instance, via interaction with GUI elements presented by her terminal. It is further noted hat, according to various embodiments, no such user activation of the one or more message reception modules may be necessary.

For instance, the modules could always be running or might be activated automatically upon reception of MGM session information at the terminal. In certain embodiments, the user might provide to the modules one or more elements of the received session information. The user might do this by entering the elements via a GUI panel or the like. In other embodiments the modules might, as alluded to above, automatically receive these elements and/or access them from the previously-noted store.

The active one or more message reception modules may take action as illustrated in Fig. 5 so that, starting at or near the start time stated in the MGM session information and ending at or near the end time stated in the MGM session information, the terminal would be associated with the multicast address associated with the MGM session (step 501). The modules υuiα men, siarung at or near the MUM session start time and ending at or near the MGM session end time stated in the received information elements, monitor for incoming transmissions directed towards the MGM session's multicast address (step 503). In the case where the MGM session information specified a transmission schedule, the one more reception modules might only monitor during the scheduled transmission periods. This could lead to improved energy conservation at the terminal in comparison to constant monitoring. And alluded to above, the message might be received via UHTTP or the like.

Upon reception of a message associated with the MGM session, the one or more message reception modules could decrypt the message in accordance with the key and/or algorithm specified in the received session information (step 505). The one or more modules could next make the message content available to the user (step 507). The modules could, for instance, display the message content to the user via GUI displays, audio outputs, and/or the like. The one or more modules might query the user before displaying and/or making available the message content.

Hardware and Software

Certain devices employed in accordance with the present invention may be implemented using computers. For example, the above-noted servers, multicast points, access points, relay devices, and terminals may be implemented using network-capable computers. Furthermore, certain procedures and the like described herein may be executed by or with the help of computers. The phrases "computer", "general purpose computer", and the like, as used herein, refer but are not limited to a processor card smart card, a media device, a personal computer, an engineering workstation, a PC, a Macintosh, a PDA, a wired or wireless terminal, a server, a network access point, a network multicast point, or the like, perhaps running an operating system such as OS X, Linux, Darwin, Windows CE, Windows XP, Palm OS, Symbian OS, or the like, perhaps with support for Java or .Net.

The phrases "general purpose computer", "computer", and the like also refer, but are not limited to, one or more processors operatively connected to one or more memory or storage units, wherein the memory or storage may contain data, algorithms, and/or program code, and the processor or processors may execute the program code and/or manipulate the program code, data, and/or algorithms. Accordingly, exemplary computer 6000 as shown in Fig. 6 includes system bus 6050 which operatively connects two processors 6051 and 6052, random access memory (RAM) 6053, read-only memory (ROM) 6055, input putput (I/O) interfaces 6057 and 6058, storage interface 6059, and display interface 6061. Storage interface 6059 in turn connects to mass storage 6063. Each of I/O interfaces 6057 and 6058 may be an Ethernet, IEEE 1394, IEEE 802. l ib, Bluetooth, DVB-T, DVB-S, DAB, GPRS, UMTS, or other interface known in the art.

Mass storage 6063 may be a hard drive, optical drive, or the like. Processors 6057 and 6058 may each be a commonly known processor such as an IBM or Motorola PowerPC, an AMD Athlon, an AMD Opteron, an Intel StrongARM, or an Intel Pentium. Computer 6000 as shown in this example also includes an LCD display unit 6001, a keyboard 6002 and a mouse 6003. In alternate embodiments, keyboard 6002, and/or mouse 6003 might be replaced with a touch screen, pen, or keypad interface. Computer 6000 may additionally include or be attached to card readers, DVD drives, or floppy disk drives whereby media containing program code may be inserted for the purpose of loading the code onto the computer. In accordance with the present invention, a computer may run one or more software modules designed to perform one or more of the above-described operations, the modules being programmed using a language such as Java, Objective C, C, C#, or C++ according to methods known in the art. It is noted that the above-described division of operations among particular software modules is for purposes of illustration, and that alternate divisions of operation may be employed. Accordingly, operations discussed as being performed by one software module might instead be performed by a plurality of software modules. Similarly, operations discussed as being performed by a plurality of modules might instead be performed by a single module.

Further, although embodiments of the invention disclose certain software modules as operating on certain devices, in alternate embodiments these modules might be distributed to run on other devices than those stated. For instance, one or more modules disclosed to be running on an MGM server might instead run on a terminal or vice versa. As another example, operations disclosed as being performed by the MGM server might instead be performed by a plurality of servers and/or other devices. It is further noted that, in various embodiments, grid computing techniques may be employed.

Shown in Fig. 7 is a functional block diagram of an exemplary terminal employable in various embodiments of the present invention. The terminal of Fig. 7 has been discussed in the foregoing. In the following, corresponding reference signs have been applied to corresponding parts. Terminal 7000 of Fig. 7 may be used in any/all of the embodiments described herein. The terminal 7000 comprises a processing unit CPU 703, a multi -carrier signal terminal part 705 and a user interface (701, 702). The multi-carrier signal terminal part 705 and the user interface (701, 702) are coupled with the processing unit CPU 703. One or more direct memory access (DMA) channels may exist between multi-carrier signal terminal part 705 and memory 704. The user interface (701, 702) comprises a display and a keyboard to enable a user to use the terminal 7000. In addition, the user interface (701, 702) comprises a microphone and a speaker for receiving and producing audio signals. The user interface (701, 702) may also comprise voice recognition (not shown).

The processing unit CPU 703 comprises a microprocessor (not shown), memory 704 and possibly software. The software can be stored in the memory 704. The microprocessor controls, on the basis of the software, the operation of the terminal 7000, such as the receiving of the data stream, the tolerance of the impulse burst noise in the data reception, displaying output in the user interface and the reading of inputs received from the user interface. The operations are described above. The hardware contains circuitry for detecting the signal, circuitry for demodulation, circuitry for detecting the impulse, circuitry for blanking those samples of the symbol where significant amount of impulse noise is present, circuitry for calculating estimates, and circuitry for performing the corrections of the corrupted data.

Still referring to Figure 7, alternatively, middleware or software implementation can be applied. The terminal 7000 can be a hand-held device which the user can comfortably carry. Advantageously, the terminal 7000 can be a cellular mobile phone which comprises the multi-carrier signal terminal part 705 for receiving the multicast transmission stream. Therefore, the terminal 7000 may possibly interact with the service providers.

-xaiuiiicauυπs ana scope

Although the description above contains many specifics, these are merely provided to illustrate the invention and should not be construed as limitations of the invention's scope. Thus it will be apparent to those skilled in the art that various modifications and variations can be made in the system and processes of the present invention without departing from the spirit or scope of the invention.