CN1726482A - Systems and methods for user-initiated group messaging - Google Patents

Abstract

Systems and methods are provided that allow a user to establish a Multicast Group Messaging (MGM) session, where messages are sent by multicast, and where the user may exercise control over the recipients that are able to receive the multicast messages. The system and method also provide for sending multicast messages in conjunction with the session and for receiving multicast messages in conjunction with the session.

Description

Systems and methods for user-initiated group messaging

technical field

The present invention relates to systems and methods for data distribution.

Background technique

In recent years, the use of wired and wireless networks for messaging has increased. Such messaging includes, for example, email, SMS (Short Message Service) and MMS (Multimedia Messaging Service). While the distribution of text remains the primary use of messaging, the use of messaging as a means of distributing content types such as video, audio, and images is also gaining traction. In particular, MMS is gaining popularity as a means of distributing such content types.

With this in mind, one might be interested in techniques that can be applied to messaging.

Contents of the invention

In accordance with embodiments of the present invention, systems and methods are provided that allow users to establish Multicast Group Messaging (MGM) sessions, wherein messages are sent via multicast, and wherein users can receive messages that are capable of receiving the multicast parties to exercise control.

The systems and methods also provide for dispatching multicast messages in conjunction with sessions and for receiving multicast messages in conjunction with sessions.

Description of drawings

Fig. 1 illustrates an exemplary network configuration according to an embodiment of the present invention.

Figure 2 is a flowchart illustrating the steps involved in messaging setup according to various embodiments of the invention.

3 is a flowchart illustrating the steps involved in a terminal receiving and forwarding Multicast Group Messaging (MGM) session information according to various embodiments of the invention.

Figure 4 is a flowchart illustrating the steps involved in message multicasting according to various embodiments of the invention.

Figure 5 is a flowchart illustrating the steps involved in message reception according to various embodiments of the invention.

Figure 6 illustrates an exemplary general purpose computer that may be used in various embodiments of the invention.

Figure 7 illustrates a functional block diagram of an exemplary terminal that may be used in various embodiments of the present invention.

Detailed ways

general operation

According to an embodiment of the present invention, a user may establish a Multicast Group Messaging (MGM) session in which messages are sent by multicast and in which she may exercise control over recipients able to receive the multicast messages. More specifically, a user can establish such an MGM session by having her terminal dispatch appropriate requests to the MGM server. A key that can be used in decrypting messages multicast in conjunction with the MGM session may be included in the server's response to the request. The user may then distribute this key and/or additional information to parties wishing to have the ability to receive messages multicast in conjunction with the session. The user can also specify whether those users who forward the key and/or additional information can further disseminate the key and/or additional information to other users.

Fig. 1 illustrates an exemplary network configuration according to an embodiment of the present invention, including an MGM server 1, a terminal 103, an access point 105 and a multicast point 107. As implied above and as will be described in more detail below, terminal 103 may request from MGM server 101 through access point 105 to establish an MGM session. The access point 105 can be, for example, a UMTS (Universal Mobile Telecommunications Service), GPRS (General Packet Radio Service) or internet access point.

The requesting terminal 103 may receive the key and/or additional information from the MGM server 101 through the access point 105 . The requesting terminal may then forward the key and/or additional information to one or more terminals 103 . Messages to be multicast may be dispatched by terminals 103 to MGM server 101 through access point 105 , encrypted by the MGM server, and then multicast through multicast point 105 to be received by appropriate terminals 103 . The multicast point 107 may be, for example, a one-way multicast point, such as a DVB-T (Digital Video Broadcasting-Terrestrial), DVB-S (Digital Video Broadcasting-Satellite) or DAB (Digital Audio Broadcasting) multicasting point. In various embodiments, the multicast point may also use bi-directional technologies such as UMTS.

It should be noted that in various embodiments of the invention there may be more or fewer terminals 101-107 than illustrated in FIG. 1 . For example, there may be multiple units 101-107.

Various aspects of the invention will now be described in more detail.

Messaging Setup Request

A user wishing to initiate an MGM session can use her terminal to issue this request to an MGM server or the like. The request may include certain specifications, such as the desired start and end times for the MGM session, the regions in which multicast messages should be received, specifications or recommendations for the type of encryption that should be used in Proposal or specification for a messaging address established for multicasting. According to various embodiments of the invention, there are a number of ways in which a user may submit a request to the appropriate server.

According to some embodiments, a user may submit a 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 may be specified that such a request should be dispatched as an SMS message directed to MGMsetup@messaging.serviceprovider.com .

Such a request may require a certain format. For example, the request message may be required to include one or more lines in the format of "attribute: value", in which there are multiple acceptable attribute keywords and acceptable corresponding values or value ranges. For example, one attribute could be "start time". The corresponding value can be specified in the format "dd.mm.yyyy;hh:nn;zzz", where "dd" corresponds to the standard two-digit representation of the day of the month, "mm" corresponds to the standard two-digit representation of the month, and "yyyy " corresponds to the standard four-digit representation of the year, "hh" corresponds to the standard two-digit representation of the hour, "nn" corresponds to the standard two-digit representation of the minute, and "zzz" corresponds to the standard three-character representation of the time zone. Thus, a user wishing to request an MGM that started on October 23, 2005 at 1:36 PM Central European Time may include the line "10.23.2005; 13:36; ECT" in her request message. Similar attributes and corresponding values can be established for other kinds of descriptions as described above, such as zone or session end time.

Alternatively or additionally, such a manual request may also be allowed in free format and/or natural language. In this case, the user may be asked to indicate certain information elements (eg MGM session start time), but may choose her presentation format. Therefore, including "I would like to start at 12:23 pm today" within the request may be an acceptable start time specification.

In addition to manual submission of MGM session requests, embodiments of the invention may additionally or alternatively allow users to submit session requests through an interface. In the case of submitting via an interface, one or more presentation program modules operating on the user terminal may, for example, present a Graphical User Interface (GUI) that the user can use to submit the required information related to her MGM request.

For example, one or more representation modules may represent a GUI that a user may use to select, for example, a start time, an end time, and an area where multicast messages should be received. The GUI may also allow the user to select and/or specify one or more MGM servers, etc., to which the request should be submitted. When the user is presented with a list from which to select one or more recipient MGM servers, etc., the list may be populated, for example, by having one or more server discovery program modules operating on the terminal access the providers of such information. The module can use SOAP (Simple Object Access Protocol), JMS (Java Messaging Service) or RMI (Remote Method Invocation), etc. when accessing the provider.

After the information necessary to place within the MGM request has been collected from the user through the interface, one or more request dispatcher modules operating on the terminal may forward the request to one or more appropriate MGM servers or the like. This can be performed in a number of ways. For example, one or more request dispatcher modules may encode information collected from users into a text message and dispatch this message to the appropriate server via email, SMS or MMS, or the like. For this encoding, for example, XML (Extensible Markup Language) can be used. In embodiments that provide, for example, the functionality described above whereby a user may manually submit MGM request information in an SMS message or the like, one or more program modules may encode a message compatible with any specified format. As such a predetermined format, for example, the above-mentioned "attribute: value" format can be used.

As another example, one or more request dispatcher modules may communicate information collected from users to an appropriate MGM server or the like via SOAP, JMS or RMI or the like.

messaging settings

As shown in FIG. 2 , the above-mentioned MGM server or the like may receive an MGM session request including a plurality of descriptions from a terminal (step 201 ).

Where a session request is received via an SMS message, MMS message, or e-mail message, etc. directed to a specific messaging address associated with the server, one or more request receiving program modules running on the server may be used to extract from the message Instructions contained therein (step 203).

Where the specification is encoded within the message by a prescribed format, the one or more request receiving modules may be operable to extract the specification according to the format. For example, where the specification is in the "attribute:value" format described above, one or more modules may scan the input message for the defined attribute and record the corresponding value. In the event that one or more required information elements, or parts thereof, are missing from a request, it may be possible to return an error message to the submitting user and/or terminal.

Alternatively, the request receiving module may try to guess the missing data. For example, if a start time is represented in hours and minutes, but no date or time zone is represented, the module can assume that the time zone is the user's local time zone. Furthermore, the module may assume that the unspecified date is the current day in the event that the indicated time has not yet fallen on that day. Conversely, in the case where the indicated time has passed on the current day, it can be assumed that the date is the next day. In the case of missing information, where the module is unable to make a guess or a satisfactory guess, or in embodiments where the module does not perform such a guessing function, an error message may be returned to the requesting user and/or in a manner similar to that described above. terminal.

Where a user enters instructions in a free-form and/or unstructured manner, one or more request receiving modules may extract the instructions contained within the message using natural language interpretation and/or analysis techniques known in the art . Because of the free-form nature of such a request, users may omit certain information, intentionally or unintentionally. For example, a user specifying a start and end time may omit the date, year, and time zone, perhaps believing that these are inherent or obvious. In some embodiments, the request handling module may attempt to guess missing data as described above. In the case of missing information, where the module is unable to make a guess or a satisfactory guess, or in embodiments where the module does not perform such a guessing function, an error message may be returned to the requesting user and/or in a manner similar to that described above. terminal.

In the case where an information unit is transmitted to a server by a module running on a terminal, possibly via SOAP or JMS, etc., the request interface module running on that terminal can directly receive the transmitted unit without performing an analysis of the kind described above wait.

Once in possession of the MGM session request specification by one of the ways just described, the request receiving module may store the specification in an associated memory (step 205). A representation of the requesting user and/or terminal can also be stored here. The representation may be, for example, the user's MMS address. This can be determined, for example, by examining the headers of the session request message, or by analyzing SOAP, JMS, RMI or similar communications. Items stored in memory may then be processed by one or more request handler modules running on an MGM server or the like.

As a first step, one or more request handler modules may be used to determine a multicast address, such as a multicast IP (Internet Protocol) address, for use in multicast group messaging (step 207). The multicast address may for example be selected from a pool of available multicast addresses, to which it may be desirable to return the address once the requested MGM session has ended. One or more request handler modules may consider one or more received specifications when selecting from the pool. For example, start time, end time and/or region may be considered. Once a multicast address is selected, one or more request handler modules may remove the address from the pool of available addresses.

As a next step, one or more request handler modules may establish a messaging address, such as an email address, SMS address or MMS address, for receiving messages to be multicast (step 209). One or more request handler modules may select the messaging address from a pool of available messaging addresses. The module may take into account when selecting a messaging address from said pool in case the received specification contains a user suggestion for a messaging address. For example, if there is a suggestion that a messaging address includes the phrase "gaming chat," the modules may look for available messaging addresses that contain that phrase or that closely match that phrase.

Instead of selecting a messaging address from the pool, one or more request handler modules may newly create a messaging address. In case the received information element specifies a user suggestion and/or specification of a messaging address, the newly established messaging address may be based on the specification and/or suggestion. When establishing a new messaging address, one or more request handler modules may take steps so that messages directed to the messaging address will be received by the MGM server, and/or have a message established on the integrated and/or separate SMS server or MMS server Appropriate message delivery count for . One or more request handler modules may also take steps to delete the count from the appropriate MMS server or the like once the MGM session ends.

As a next step, one or more request handler modules may specify in an associated memory the relationship between the multicast address and the messaging address (step 211). Next, one or more request handler modules may determine a schedule for multicasting within the MGM session (step 213). For example, it may be determined that the multicast will occur every five minutes within an hour (eg, 5:05pm, 5:10pm, 5:15pm, etc.). Such a schedule may be determined when it is desired to promote energy saving within terminals that want to receive multicasts in accordance with an MGM session, since terminals may only need to monitor incoming transmissions during scheduled times.

The determination of the schedule may take into account, for example, the energy usage characteristics of typical terminals within one or more areas specified for the MGM session. Such characteristics can be learned, for example, by considering service provider records indicating the prevalence of particular terminal models in different regions, and further considering manufacturer specifications associated with these terminal models.

Next, one or more request handler modules may select or establish keys to be used in decrypting messages multicast during the MGM session (step 215). Modules can also choose the encryption method that will be used. Alternatively, one encryption method can always be used. Selection and/or establishment of keys and/or selection of encryption methods may also take into account various factors. These factors may include suggested encryption methods included in the instructions received.

As a next step, session information related to messaging addresses, multicast addresses, schedules, keys, algorithms, and/or other information for an MGM session may be stored by these modules in memory associated with the server, and/or forwarded To the user and/or user terminal requesting the MGM session (step 217). In various embodiments of the invention, the module may forward this session information only to the user and/or user terminal requesting the MGM session.

Forwarding can be done in a number of ways. For example, the information may be placed within an MMS message, SMS message, email message, etc. directed to the user and/or user terminal who dispatched the MGM session request, to be read directly by the user. As another example, this information could be encoded using XML or the like, or placed within an MMS message or the like directed to the user or her terminal. As another example, information may be communicated to one or more software modules operating on the user terminal via SOAP, JMS, or RMI, among others.

Terminal reception and forwarding of MGM session information

Once a terminal dispatching an MGM session request receives information related to the session from the MGM server, one or more of several actions may take place. For example, as shown in Figure 3, through the message browser program module running on the terminal, the session information bearing MMS message or e-mail message etc. pointing to the terminal user can be extracted in a conventional manner, so as to be directly read by the user (step 301 ). The user can read this message using one or more modules and can record the session information contained therein. If necessary, the user may provide the recorded information to an appropriate program module or the like running on the terminal (step 303).

In addition to, or as an alternative to, the user browsing messages and/or recordings contained therein, one or more MGM session information extractions operating on the terminal Program modules are operable to extract session information from the message. These modules may record this information and/or transmit it to one or more appropriate program modules operating on the terminal, etc. as will be described in more detail below. The program module may know the format or formats used by the MGM server to encode the session information to be read directly by the user, and may use this knowledge in extracting the session information from the message. Optionally, these modules can analyze the conversational information of the message using natural language analysis techniques known in the art and the like.

For processing received MMS messages or e-mail messages etc. containing MGM session information not specifically encoded for direct reading by the user, the session information extraction module may perform operations in a similar manner as just described. Such a message could eg be a message containing session information encoded in XML. As mentioned earlier, these modules may know the format or formats used by the MGM server in encoding session information, and may use this knowledge when extracting session information. In addition to or as an alternative to recording and/or transmitting MGM session information, these modules may display the session information to the user, possibly through a GUI session box. A user may record this information and/or provide this information to an appropriate program module running on the terminal, etc.

When the MGM server distributes the MGM session information to the terminal through SOAP, JMS or RMI, etc., the session information extracting module can receive this information. In a manner similar to that described above, a module may execute to record this information, and/or transmit it to one or more appropriate program modules running on a terminal, etc. Alternatively or additionally, the module may display information to the user.

It should also be noted that upon receipt of MGM session information at a requesting terminal, action may be taken to forward the session information to one or more other terminals. This forwarding can be performed in a number of ways. For example, where a user receives an MMS message or an e-mail message, etc. that includes session information for direct reading, the user may forward the message to one or more other users and/or terminals, possibly using Messaging program module (step 309).

Users can interact with the module through GUI or voice control etc. Where the session information is displayed to the user through a GUI dialog box or the like, the dialog box or the like may provide an option to perform forwarding of the message to a specified user and/or terminal. In some embodiments, the messaging module may be configured to allow specifying whether the recipient of the forwarded message may further forward the message (step 305). A user can set this option, for example, through a GUI. The GUI can be the same as the one used to select forwarding. In case it is specified that no further forwarding should be allowed, the module may add such an indication to the forwarded message (step 307). In such embodiments, program modules operating on the terminal may be configured to take such an indicator into account so that the user will not be permitted to forward messages with such an indication.

In a similar manner, in various embodiments, the user may be presented with the option to forward an MMS message or email message, etc., containing session information formatted using XML or the like. For example, a GUI dialog box displaying session information to the user may further allow the user to specify the users and/or terminals to which the information should be forwarded. As noted above, in some embodiments, the user may be presented with the option to not allow further forwarding of the message.

Also, in a similar manner, in various embodiments, the user may be presented with the option to forward MGM session information received via SOAP or the like. Such an embodiment may provide an interface, such as a GUI dialog box, through which a user may specify the users and/or terminals that should receive the information. In a manner similar to that described above, the user may be presented with an option to prevent further forwarding of session information by terminals that have received it. A module running on a terminal may execute to dispatch session information, possibly with an added indication that further forwarding is not allowed, to specified users and/or terminals via SOAP or the like.

Once the terminal receives the MGM session information forwarded from another terminal, it can perform actions similar to those described above with reference to the terminal receiving session information from the MGM server. For example, the forwarded session information can be displayed to the user of the receiving terminal through a session box, and the forwarded session information can be recorded and/or sent to a program module running on the terminal. As yet another example, if it is not stipulated that further forwarding of the received forwarding session information is not allowed, an option of further forwarding the session information to other terminals and/or users may be displayed to the receiving user.

The receiving user may also be presented with an option specifying whether the recipient of the newly forwarded information is allowed to forward it further. Terminals and/or users receiving newly forwarded session information may similarly perform one or more of the above actions on the information.

message multicast

As shown in FIG. 4 , a user wishing to multicast a message through an MGM session may execute to dispatch the message to an established messaging address (eg, an SMS address) corresponding to the session (step 401 ). Users can invoke new message composition windows associated with messaging modules operating on their terminals, which modules can be associated with conventional message dispatch programs such as MMS, SMS or e-mail clients. A GUI button or the like that can be pressed to launch the authoring window may be displayed to the user. The button may have a label such as "Click here to multicast message to MGM session x", where "x" may be replaced with an identifier associated with the MGM session.

Users can add components such as text, files, graphics, sounds, and movies to messages through the new composition window. It should be noted that some embodiments of the invention may limit the types of elements that can be added to a message. For example, in some embodiments, only adding text may be allowed.

After writing the message, the user can specify the message to be dispatched. The user may do this, for example, by entering the messaging address to be established for the MGM session into a GUI field associated with the composition window. The user can then press the "Send" GUI button associated with that window. The dispatch of the message to the messaging address may be in accordance with a transmission method known in the art for the type of messaging address (eg SMS).

It should be noted that in some embodiments, the user may not need to specify an established messaging address. This may be the case, for example, in the above-described embodiments in which a software module etc. running on the terminal has knowledge of the received session information. It should also be noted that functionality may be provided so that the start and end times of a session may be taken into account by a software module running on a user terminal wishing to multicast a message. For example, a software module may prevent the establishment and/or sending of messages within a multicast within a session until the start and end times indicate that the session is active or about to be active.

Once a message to be multicast is received at an MGM server or the like, one or more dissemination modules operating on the server may first determine the messaging address to which the message is intended (step 403). Next, these modules can access the above-mentioned memory to determine the MGM session associated with the message delivery address (step 405).

Thereafter, the modules can determine whether the session is active (step 407). determine the current time and/or date by consulting a clock and/or calendar associated with and/or accessible by the server, consult memory to determine the start and end times associated with the session, and determine the current date and/or time Whether within and/or just before the session's time period, the above operations may be performed. In case the MGM session is found to be not active, the terminal may stop further processing of incoming messages and may send SMS messages etc. to the terminals and/or users dispatching the messages to be multicast (step 409). The message sent may specify, for example, that the session has expired.

Next, one or more casting modules may query the memory to determine the multicast address associated with the MGM session (step 411). The modules may then access the memory to determine the encryption type and/or decryption key associated with the session (step 413). The modules may then encrypt the received message for decryption using the key (step 415). Thereafter, the modules may access memory for any transmission schedules associated with the MGM session (step 417).

One or more dissemination modules may then take steps to multicast the encrypted message to the appropriate multicast address according to any schedule associated with the session (step 419). For example, one or more dissemination modules may implement the above steps by submitting the encrypted message, possibly with additional parameters, to one or more software modules operating on the multicast point. The multicast point may be, for example, a one-way multicast point such as a DVB-T or DVB-S multicast point. In various embodiments, the multicast point may also use bi-directional technologies such as UMTS. Additional parameters may for example specify time scheduling information related to the session and/or protocol that should be used within the multicast.

It should be noted that where a multicast schedule is associated with an MGM session, in some embodiments, one or more propagation modules operating on the MGM server may broadcast only at multicast time or at multicast time according to the schedule. Submit the message to the multicast point just before starting. In these embodiments, the time scheduling information may not be forwarded to the multicast point. In other embodiments, one or more dissemination modules may forward messages to multicast points without special regard to the multicast schedule, leaving the job of following the schedule to software operating on the multicast point module. As implied above, the software modules of the multicast point can know this schedule through an additional parameter dispatched with the message to be multicast.

After having received the message to be multicast and any additional parameters, the multicast point may perform formatting or reformatting of the message and/or elements thereof. For example, the message may be formatted or reformatted in a manner using HTML. The multicast point can then multicast the encrypted message. As implied above, in some embodiments, the multicast point may multicast according to a schedule associated with the MGM session. Multicast can use, for example, UHTTP (Unidirectional Hypertext Transfer Protocol).

message reception

As noted above, terminals and/or users may receive MGM session information. According to some embodiments of the invention, such a user or a user of such a terminal wishing to receive messages multicast in association with an MGM session may take action to activate one or more message receiving modules on his terminal. The user can make such a specification, for example, by interacting with a GUI element displayed by his terminal. It should also be noted that user activation of such one or more message receiving modules is not required in accordance with various embodiments.

For example, these modules may run all the time, or may be activated automatically upon receipt of MGM session information on the terminal. In some embodiments, a user may provide these modules with one or more units of received session information. The user can perform the operation by inputting the unit via a GUI panel or the like. In other embodiments, as implied above, these modules may automatically receive these units and/or access them from the previously mentioned memory.

One or more active message receiving modules may take actions as shown in Figure 5 to start at or near the start time specified in the MGM session information and start at or near the start time specified in the MGM session information Or near the end time, the terminal will associate with the multicast address related to the MGM session (step 501). The module may then begin monitoring for incoming transmissions to the multicast address of the MGM session beginning at or near the MGM session start time specified in the received information element and ending at or near the MGM session end time (step 503) . Where the MGM session information specifies a transmission schedule, one or more receiving modules may only monitor during the scheduled transmission period. This may result in improved energy savings on the terminal compared to continuous monitoring. As implied above, messages may be received over UHTTP or the like.

Upon receiving a message related to the MGM session, one or more message receiving modules may decrypt the message according to a key and/or algorithm specified within the received session information (step 505). One or more modules may then make the message content available to the user (step 507). These modules can, for example, display the message content to the user through GUI display and/or audio output and the like. One or more modules may query the user prior to displaying and/or making available message content.

hardware and software

Some of the devices used in accordance with the present invention can be implemented using computers. For example, the above-mentioned server, multicast point, access point, relay device and terminal can be implemented using a network-enabled computer. In addition, some programs and the like described herein can be executed by means of a computer. The phrases "computer" and "general purpose computer" as used herein refer to, but are not limited to, processor card smart cards, media devices, personal computers, engineering workstations, PCs, Macintosh machines, PDAs, wired or wireless terminal servers, network access Access points, network multicast points, etc., may run operating systems such as OS X, Linux, Darwin, Windows CE, Windows XP, PalmOS, Symbian OS, etc., and may also have Java or .Net support.

The phrases "general purpose computer" and "computer" etc. also mean, but are not limited to, one or more processors operatively connected to one or more memory or storage units, where the memory may contain data, algorithms and/or program code , one or more processors can execute program code and/or operate on the program code, data and/or algorithms. Thus, the exemplary computer 6000 shown in FIG. 6 includes a system bus 6050 operatively connecting two processors 6051 and 6052, random access memory (RAM) 6053, read only memory (ROM) 6055, input output (I/O ) interfaces 6057 and 6058, a storage interface 6059 and a display interface 6061. The storage interface 6059 is in turn connected to a large storage 6063 . Each I/O interface 6057 and 6058 may be Ethernet, IEEE 1394, IEEE 802.11b, Bluetooth, DVB-T, DVB-S, DAB, GPRS, UMTS or other interfaces known in the art.

The large storage 6063 can be a hard drive or an optical drive, etc. The processors 6057 and 6058 can be known processors, such as IBM or Motorola PowerPC, AMD Athlon, AMD Opteron, Intel StrongARM or Intel Pentium. The computer 6000 illustrated in this example also includes an LCD display unit 6001 , a keyboard 6002 and a mouse 6003 . In alternative embodiments, keyboard 6002 and/or mouse 6003 may be replaced with a touch screen, pen or keypad interface, and the like. The computer 600 may also include or be connected to a card reader, DVD drive, or floppy disk drive whereby a medium containing the program code may be inserted in order to load the code onto the computer.

According to the present invention, a computer may run one or more software modules designed to perform one or more of the above operations, programmed in a language such as Java, Objective C, C, C# or C++, according to methods known in the prior art the module. It should be noted that the division of operations between particular software modules is for illustrative purposes and other divisions of operations may be used. Accordingly, operations described as being performed by one software module may also be performed by a plurality of software modules. Similarly, operations described as being performed by multiple modules may also be performed by a single module.

Furthermore, although embodiments of the invention disclose certain software modules operating on certain devices, in alternative embodiments, these modules may be distributed to run on devices other than those described. For example, one or more modules disclosed to run on the MGM server may also run on the terminal, and vice versa. As another example, operations disclosed as being performed by an MGM server may also be performed by multiple servers and/or other devices. It should also be noted that in various embodiments, grid computing techniques may be used.

FIG. 7 is a functional block diagram of an exemplary terminal that may be used in various embodiments of the present invention. The terminal of Figure 7 has been discussed above. Corresponding reference signs are used for corresponding parts in the following text. Terminal 7000 of Figure 7 may be used in any/all of the embodiments described herein. The terminal 7000 includes a processing unit CPU 703, a multi-carrier signal terminal part 705 and user interfaces (701, 702). The multi-carrier signal terminal part 705 and the user interface (701, 702) are connected with the processing unit CPU 703. One or more direct memory access (DMA) channels may exist between multicarrier signal termination section 705 and memory 704 . The user interface ( 701 , 702 ) includes a display and a keypad enabling a user to use the terminal 7000 . Furthermore, the user interface (701, 702) includes a microphone and a speaker for receiving and generating audio signals. The user interface (701, 702) may also include voice recognition (not shown).

The processing unit CPU 703 comprises a microprocessor (not shown), memory 704 and possibly software. Software may be stored within memory 704 . The microprocessor controls the operation of the terminal 7000 according to software, such as receiving data streams, impulse noise tolerance in data reception, displaying output in the user interface, and reading input received from the user interface. These operations are as described above. The hardware contains signal detection circuits, demodulation circuits, pulse detection circuits, circuits for blanking those samples where a significant amount of impulse noise is present in the symbols, circuits for computing estimates, and circuits for performing error correction for corrupted data.

Still referring to Figure 7, alternatively, a middleware or software implementation may be used. The terminal 7000 may be a handheld device that can be comfortably carried by a user. Advantageously, terminal 7000 may be a cellular mobile telephone comprising multi-carrier signal terminal means 705 for receiving multicast transport streams. Therefore, terminal 7000 may also be able to interact with service providers.

Although the above description contains many details, these are only for illustrating the present invention and should not be construed as limiting the protection scope of the present invention. Thus, it will be apparent to those skilled in the art that various modifications and changes can be made in the system and processing method of the present invention without departing from the spirit or scope of the present invention.

Claims (108)

1. the method for a multicast message comprises:

Receive the request that multicast message is transmitted session from the initiator;

Selection is used for the multicast address of described session;

The message transfer address is associated with described multicast address;

Decruption key is only sent to described initiator, so that be distributed to one or more other sides by described initiator;

By described message transfer address receive will be in described session the message of multicast;

Encrypt described message, so that use described secret key decryption; With

The message of being encrypted by described multicast address multicast.

2. the process of claim 1 wherein that described initiator prevents the described key of described one or more other side's distributions.

3. the process of claim 1 wherein that described selection considers the explanation about session persistence that receives from described initiator.

4. the process of claim 1 wherein described selection consider from described initiator receive about the message of multicast should receivable zone in described session therein explanation.

5. the process of claim 1 wherein and from one group of multicast addresses available, select described multicast address.

6. the process of claim 1 wherein and from one group of available message transfer address, select described message transfer address.

7. the process of claim 1 wherein and advise described message transfer address by described initiator.

8. the method for claim 1 also comprises and determines the multicast timetable.

9. the method for claim 8, wherein definite consideration terminal energy operating characteristic of multicast timetable.

10. the method for claim 1 also comprises to described initiator sending described message transfer address.

11. the method for claim 8 also comprises to described initiator sending described multicast timetable.

12. the process of claim 1 wherein by universal mobile telecommunications service communications reception described request.

13. the process of claim 1 wherein by general packet radio service communications reception described request.

14. the process of claim 1 wherein and receive described request by internet communication.

15. the process of claim 1 wherein and assign described request by Email.

16. the process of claim 1 wherein and assign the professional described request of assigning by Multimedia Message.

17. the process of claim 1 wherein and assign described request by short message service.

18. the process of claim 1 wherein and assign described request by Simple Object Access Protocol.

19. the process of claim 1 wherein that described multicast uses unidirectional hypertext transfer protocol.

20. the process of claim 1 wherein and use the digital video broadcast terrestrial link to carry out described multicast.

21. the process of claim 1 wherein and use the satellite digital video broadcast link to carry out described multicast.

22, the process of claim 1 wherein and use the digital audio broadcasting link to carry out described multicast.

23. the process of claim 1 wherein and use the universal mobile telecommunications service link to carry out described multicast.

24. the process of claim 1 wherein and use the multimedia messaging service agreement to carry out described multicast.

25. the process of claim 1 wherein and use the short message service agreement to carry out described multicast.

26. the process of claim 1 wherein and use email protocol to carry out described multicast.

27. a message transmits the method for setting up, and comprising:

Send the request that multicast message is transmitted session to server;

The decruption key that reception is assigned by described server, wherein said server is not tasked other entity with this key branch;

From described server receiving group address, wherein said server has made this multicast address be associated with described session, and wherein said server has made the message transfer address be associated with this multicast address; With

Described key is sent to a side or in many ways, wherein said key can be used for deciphering the message of multicast in described session.

28. the method for claim 27 also comprises the described side of regulation or does not distribute described key in many ways.

29. the method for claim 27 also comprises to the explanation of described server submission about session persistence.

30. the method for claim 29 wherein makes multicast address be associated with described session to consider the explanation about session persistence.

31. the method for claim 27 also comprises to described server and submits explanation about the message of multicast should receivable zone in described session therein to.

32. the method for claim 31 wherein makes multicast address be associated with described session to consider the explanation about the zone.

33. the method for claim 27 is wherein selected described multicast address by described server from one group of multicast addresses available.

34. the method for claim 27 is wherein selected described message transfer address by described server from one group of available message transfer address.

35. the method for claim 27 also comprises to the suggestion of described server submission to described message transfer address.

36. the method for claim 27, wherein said server is determined the multicast timetable.

37. the method for claim 36, wherein definite consideration terminal energy operating characteristic of multicast timetable.

38. the method for claim 36 also comprises from described server receiving described multicast timetable.

39. the method for claim 27 also comprises from described server receiving described message transfer address.

40. the method for claim 27 wherein sends described request by universal mobile telecommunications service communication.

41. the method for claim 27 wherein sends described request by general packet radio service communication.

42. the method for claim 27 wherein sends described request by internet communication.

43. the method for claim 27 wherein sends described request by Email.

44. the method for claim 27 wherein sends described request by multimedia messaging service.

45. the method for claim 27 wherein sends described request by short message service.

46. the method for claim 27 wherein sends described request by the simple target access protocal.

47. the method for claim 27, wherein multicast message uses unidirectional hypertext transfer protocol in described session.

48. the method for claim 27, wherein multicast message uses the digital video broadcast terrestrial link in described session.

49. the method for claim 27, wherein multicast message uses the satellite digital video broadcast link in described session.

50. the method for claim 27, wherein multicast message uses the digital audio broadcasting link in described session.

51. the method for claim 27, wherein multicast message uses the universal mobile telecommunications service link in described session.

52. the method for claim 27, wherein multicast message uses the multimedia messaging service agreement in described session.

53. the method for claim 27, wherein multicast message uses the short message service agreement in described session.

54. the method for claim 27, wherein multicast message uses email protocol in described session.

55. a system that is used for multicast message comprises:

Program code stored therein storer; With

Be operatively coupled to described storer, be used for processor according to described stored program code execution command;

Wherein when being carried out by described processor, described program code makes described processor carry out following step:

Receive the request that multicast message is transmitted session from the initiator;

Selection is used for the multicast address of described session;

Message addresses is associated with described multicast address;

Decruption key is only sent to described initiator, so that be distributed to one or more other sides by described initiator;

By described message transfer address receive will be in described session the message of multicast;

Encrypt described message, so that use described secret key decryption; With

The message of being encrypted by described multicast address multicast.

56. the system of claim 55, wherein said initiator prevent the described key of described one or more other side's distributions.

57. the system of claim 55, wherein said selection is considered from the explanation about session persistence of described initiator's reception.

58. the system of claim 55, wherein said selection consider from described initiator receive about the message of multicast should receivable zone in described session therein explanation.

59. described multicast address is wherein selected by the system of claim 55 from one group of multicast addresses available.

60. described message transfer address is wherein selected by the system of claim 55 from one group of available message transfer address.

61. described message transfer address is wherein advised by described initiator by the system of claim 55.

62. the system of claim 55, wherein said processor is also carried out the step of determining the multicast timetable.

63. the system of claim 62, wherein definite consideration terminal energy operating characteristic of multicast timetable.

64. the system of claim 55, wherein said processor is also carried out the step that sends described message transfer address to described initiator.

65. the system of claim 62, wherein said processor is also carried out the step that sends described multicast timetable to described initiator.

66. the system of claim 55 is wherein by universal mobile telecommunications service communications reception described request.

67. the system of claim 55 is wherein by general packet radio service communications reception described request.

68. the system of claim 55 wherein receives described request by internet communication.

69. the system of claim 55 wherein assigns described request by Email.

70. the system of claim 55 wherein assigns described request by multimedia messaging service.

71. the system of claim 55 wherein assigns described request by short message service.

72. the system of claim 55 wherein assigns described request by Simple Object Access Protocol.

73. the system of claim 55, wherein said multicast uses unidirectional hypertext transfer protocol.

74. the system of claim 55 wherein uses the digital video broadcast terrestrial link to carry out described multicast.

75. the system of claim 55 wherein uses the satellite digital video broadcast link to carry out described multicast.

76, the system of claim 55 wherein uses the digital audio broadcasting link to carry out described multicast.

77. the system of claim 55 wherein uses the universal mobile telecommunications service link to carry out described multicast.

78. the system of claim 55 wherein uses the multimedia messaging service agreement to carry out described multicast.

79. the system of claim 55 wherein uses the short message service agreement to carry out described multicast.

80. the system of claim 55 wherein uses email protocol to carry out described multicast.

81. one kind is used for message and transmits the system that sets up, and comprising:

Program code stored therein storer; With

Be operatively coupled to described storer, be used for processor according to described stored program code execution command;

Wherein when being carried out by described processor, described program code makes described processor carry out following step:

Send the request that multicast message is transmitted session to server;

The decruption key that reception is assigned by described server, wherein said server is not tasked other entity with this key branch;

From described server receiving group address, wherein said server has made this multicast address be associated with described session, and wherein said server has made the message transfer address be associated with this multicast address; With

Described key is sent to a side or in many ways, wherein said key can be used for deciphering the message of multicast in described session.

82. the system of claim 81, wherein said processor is execution in step also: stipulate a described side or do not distribute described key in many ways.

83. the system of claim 81, wherein said processor is also carried out to the step of described server submission about the explanation of session persistence.

84. the system of claim 83 wherein makes multicast address be associated with described session to consider the explanation about session persistence.

85. the system of claim 81, wherein said processor is also carried out to described server and is submitted step about the explanation that the message of multicast should receivable zone in described session therein to.

86. the system of claim 85 wherein makes multicast address be associated with described session to consider the explanation about the zone.

87. described multicast address is wherein selected by described server by the system of claim 81 from one group of multicast addresses available.

88. described message transfer address is wherein selected by described server by the system of claim 81 from one group of available message transfer address.

89. the system of claim 81, wherein said processor is also carried out to the step of described server submission to the suggestion of described message transfer address.

90. the system of claim 81, wherein said server is determined the multicast timetable.

91. the system of claim 90, wherein definite consideration terminal energy operating characteristic of multicast timetable.

92. the system of claim 90, wherein said processor is also carried out the step that receives described multicast timetable from described server.

93. the system of claim 81, wherein said processor is also carried out the step that receives described message transfer address from described server.

94. the system of claim 81 wherein sends described request by universal mobile telecommunications service communication.

95. the system of claim 81 wherein sends described request by general packet radio service communication.

96. the system of claim 81 wherein sends described request by internet communication.

97. the system of claim 81 wherein sends described request by Email.

98. the system of claim 81 wherein sends described request by multimedia messaging service.

99. the system of claim 81 wherein sends described request by short message service.

100. the system of claim 81 wherein sends described request by Simple Object Access Protocol.

101. the system of claim 81, wherein multicast message uses unidirectional hypertext transfer protocol in described session.

102. the system of claim 81, wherein multicast message uses the digital video broadcast terrestrial link in described session.

103. the system of claim 81, wherein multicast message uses the satellite digital video broadcast link in described session.

104. the system of claim 81, wherein multicast message uses the digital audio broadcasting link in described session.

105. the system of claim 81, wherein multicast message uses the universal mobile telecommunications service link in described session.

106. the system of claim 81, wherein multicast message uses the multimedia messaging service agreement in described session.

107. the system of claim 81, wherein multicast message uses the short message service agreement in described session.

108. the system of claim 81, wherein multicast message uses email protocol in described session.

Images