KR100768153B1 - System and method for user-initiated group messaging - Google Patents

Abstract

A system and method for enabling a user to establish a multicast group messaging (MGM) session, wherein messages are delivered via multicast and the user can perform control over the parties that can receive the multicast messages. The system and method also provide for sending messages for multicasting in connection with a session and for receiving multicast messages for the session.

Description

System and method for user-initiated group messaging}

The present invention relates to a data distribution system and method.

Recently, the use of wired and wireless networks for messaging is increasing. Such messaging includes, for example, email, Short Message Service (SMS), and Multimedia Messaging Service (MMS). While text distribution is still a popular messaging method, messaging methods of distributing content types such as video, audio, and images are also gaining favor. In particular, MMS is gaining popularity as a way to distribute such content types.

In this regard, there may be interest in techniques applicable to messaging.

According to embodiments of the present invention, systems and methods are provided that enable a user to establish a multicast group messaging (MGM) session, wherein messages are delivered via multicast and the user can use multicasted messages. Control over existing parties.

The system and method further provide for sending messages to multicast with respect to the session and receiving multicast messages with respect to the session.

1 shows an exemplary network configuration in accordance with embodiments of the present invention.

2 is a flow diagram illustrating the steps involved in establishing a messaging, in accordance with various embodiments of the present invention.

3 is a flow diagram illustrating the steps involved in terminal receipt and transmission of multicast group messaging (MGM) session information, in accordance with various embodiments of the present invention.

4 is a flow diagram illustrating the steps involved in message multicast, in accordance with various embodiments of the present invention.

5 is a flow diagram illustrating the steps involved in receiving a message, in accordance with various embodiments of the present invention.

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

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

Normal behavior

According to embodiments of the present invention, a user establishes a multicast group messaging (MGM) session, in which messages are delivered via multicast and the user is able to use the multicasted messages for those parties. Control can be executed. More specifically, the user may set up an MGM session or the like by making his terminal send an appropriate request to the MGM server. The server's response to the request may include a key that can be used to decrypt the multicast messages with the MGM session. The user can then distribute the key and / or additional information to parties who wish to have the ability to use multicasted messages in conjunction with the session. The user may further specify whether the parties that have received the key and / or additional information can further distribute the key and / or additional information elsewhere.

Shown in FIG. 1 is an exemplary network structure in accordance with embodiments of the present invention, including an MGM server 101, terminals 103, an access point 105, and a multicast point 107. As described above and described in more detail below, terminal 103 may request the establishment of an MGM session from MGM server 101 via access point 105. The access point 105 may be, for example, a universal mobile telecommunications service (UMTS), a general packet radio service (GPRS), or an internet access point.

The requesting terminal 103 may receive a key and / or additional information from the MGM server 101 via the access point 105. The requesting terminal then delivers the key and / or additional information to one or more terminals 103. The messages to be multicast are sent by the terminal 103 via the access point 105 to the MGM server 101, encrypted by the MGM server, and then used by the appropriate terminals 103. Multicast via 107. The multicast point 107 may be, for example, a unidirectional multicast point such as Digital Video Broadcast-Terrestrial (DVB-T), Digital Video Broadcast-Satellite (DVB-D), or Digital Audio Broadcast (DAB) multicast point. have. In various embodiments, the multicast point may use a bidirectional technique such as UMTS instead of a unidirectional multicast point.

It should be noted that in various embodiments of the present invention, there may typically be more or fewer components 101-107 for each shown in FIG. 1. For example, each of the components 101-107 may be plural.

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

Messaging  Request setting

A user who wants to start an MGM session can use his terminal to request such session start from an MGM server or the like. This request includes a specification of the desired start and end times for the MGM session, a specification of the area in which multicasted messages should be received, and a specification or proposal of what type of encryption should be used for message multicast. , And / or a proposal or specification of a messaging address that must be set in order to submit messages for multicast. According to various embodiments of the present invention, there are a number of ways in which the user can make the request to the appropriate server.

According to some embodiments, a user may send the request by manually creating a message and sending it to a suitable email, Short Message Service (SMS), Multimedia Messaging Service (MMS), or other messaging address. For example, the request may be set such that the request is sent as an SMS message directed to "MGMsetup@messaging.serviceprovider.com".

Such a request may be required to be in some form. For example, a request message may contain one or more lines in the form of "attribute: value" where there are a number of allowable attribute keywords and corresponding allowable values or ranges of values. Can be. For example, one attribute may be "StartTime". The corresponding value may be specified in the form of "dd.mm.yyyy; hh: nn; zzz", where "dd" corresponds to the standard two-digit representation of the day-of-month, "mm" corresponds to the standard 2 digit representation of the month, "yyyy" corresponds to the standard 4 digit representation of the year, "hh" corresponds to the standard 2 digit representation of the hour, and "nn" corresponds to the standard of minutes. 2 digit display ", and" zzz "corresponds to the standard three-character display of the time zone.

Thus, a user who wishes to request an MGM starting at 1:36 pm on October 23, 2005, in European central time may include the line "10.23.2005; 13: 36; ECT" in his request message. Similar properties and corresponding values may be set for other features of the above kind, such as local or session end time.

Such passive requests are alternatively or additionally allowed to be in free and / or natural language form. In this case, the user is asked to indicate certain information elements (eg, MGM session start time), but can select his presentation (presentation) format. Thus, an insert in the request that says "I want to start today at 12:23 pm" could be an acceptable specification for the start time.

In addition to the manual provision of the MGM session request, embodiments of the present invention may additionally or alternatively allow a user to present a session request via an interface. When presented through an interface, one or more presentation program modules running on the user terminal may provide a graphical user interface (GUI) or the like that the user can use to present the necessary information about his or her MGM request. will be.

For example, one or more presentation modules may provide a GUI that allows the user to select things such as start time, end time, areas where multicast messages can be received, and the like. The GUI may additionally allow the user to select and / or specify the MGM server, MGM servers, etc. to which the request will be sent. If a user is provided with a list to select one or more receiving MGM servers or the like, this list can be generated, for example, by having one or more server finder programs running on the terminal access the provider of that information. When accessing a provider, modules will use Simple Object Access Protocol (SOAP), Java Messaging Service (JMS), Remote Method Invocation (RMI), and so on.

When information is gathered from the user that is necessary to place in an MGM request via an interface, one or more request sending program modules running on the terminal can send the request to one or more appropriate MGM servers, and so forth. This can be done in a number of ways. For example, one or more request sending program modules encode all information from a user into a text message and send the message via email, SMS, MMS, etc., to the appropriate server. The encoding may use, for example, XML (eXtensible Markup Language). For example, in embodiments that provide the user with the ability to manually send MGM request information in an SMS message or the like, one or more program modules may encode the message according to any specified format. This designated format may use, for example, the "attribute: value" format described above.

As another example, one or more request sending program modules may send information gathered from the user to a suitable MGM server, etc. via SOAP, JMS, RMI, and the like.

Messaging set up

As shown in FIG. 2, the MGM server or the like receives an MGM session request including various specifications from the terminal as described above (step 201).

When a session request is received via an SMS message, an MMS message, an email message, etc., directed to a particular messaging address associated with the server, one or more request receiving program modules running on the server are operative to extract the features contained therein. (Step 203).

When the specifications are encoded into a message via a certain format, one or more request receiving modules may be operative to extract the specifications in accordance with that format. For example, if the specifications are in the "attribute: value" format described above, one or more modules may retrieve the attributes defined in the incoming messages and observe their values. If one or more required information elements, or portions thereof, are missing from the request, an error message is returned to its providing user and / or terminal via a transmission method (e.g., SMS), perhaps the same as that used to send the session request.

Or, the request receiving modules may attempt to estimate the missing data. For example, when the start time is expressed in hours and minutes but does not indicate data or time zones, modules may assume that the time zone is the user's local time zone. In addition, if the indicated time has not yet reached that day, the modules may assume that an unspecified date is that day. On the other hand, if the indicated time has already passed that day, the date may be assumed to be the next day. In the case of missing information for which no guesses or satisfactory assumptions can be made by the modules, or in embodiments in which the modules do not perform such speculative functions, an error message is generated in the same manner as described above with the requesting user and / or terminal. Can be returned.

When features are entered by the user in a free form and / or unstructured manner, one or more request receiving modules may use natural language interpretation and / or parsing techniques known in the art to extract the features contained in the message. Can be. Due to the nature of the free form of the request, the user can omit any information intentionally, intentionally or unintentionally. For example, user-specified start and end times may be omitted in the belief that they may be embedded or know the date, year, time zone, and the like. In some embodiments, request processing modules may attempt to guess missing data as described above. In the case of missing information for which no guess or satisfactory estimate can be made by the modules, or in embodiments where the modules do not perform such a guessing function, an error message is sent to the requesting user and / or terminal in the same manner as described above. Can be returned.

When information elements are sent to the server via SOAP, JMS, etc. by modules running on the terminal, request receiving modules running on the terminal may receive the sent elements directly, without having to perform the parsing or the like described above. Can be.

Once the MGM session request specifications have been obtained through one of the schemes described above, the request receiving modules can place them in the associated storage (step 205). Also located here is an indication of the user and / or terminal that provided the request. This indication may be, for example, the MMS address of the user. This may be determined, for example, by examining headers in the case of a session request message, or by analyzing SOAP, JMS, RMI or similar communications. Items located in storage may then be processed by one or more request processing modules running on an MGM server or the like.

As a first step, one or more request processing modules operate to determine a multicast address, such as a multicast Internet Protocol (IP) address to be used for multicast group messaging (step 207). The multicast address may, for example, be selected from a pool of available multicast addresses, possibly with the intention that the address will be returned back to the pool once the requested MGM session has completed. One or more request processing modules will consider one or more received features when making a selection from the pool. For example, start time, end time, and / or area may be considered. After selecting a multicast address, one or more request processing modules may remove that address from the pool of available addresses.

As a next step, one or more request processing modules may set a messaging address, such as an email address, an SMS address, an MMS address, etc. to receive the messages to be multicast (step 209). One or more request processing modules will select the messaging address from the pool of available addresses. If the received specifications include a user's suggestion for a messaging address, the modules will consider this when selecting a messaging address from the pool. For example, when a proposal was made for a messaging address to include the phrase "game and chat", modules could find any available messaging address that includes the phrase or a phrase that closely matches the phrase.

Instead of selecting a messaging address from the pool, one or more request processing modules may set a new messaging address. If the received information elements specify a user's suggestion and / or specification for a messaging address, the newly established messaging address may be tailored to that specification and / or suggestion. When setting up a new messaging address, one or more request processing modules may arrange for messages destined for the messaging address to be received by the MGM server and / or allow the appropriate messaging account to be set up on an integrated and / or separate SMS server. One or more request processing modules may also act to remove the account from the appropriate MMS server or the like upon interruption of the MGM session.

As a next step, one or more request processing modules may specify a correlation between the multicasting address and the messaging address in the associated storage (step 211). Next, one or more request processing modules may schedule (step 213) for multicasts in the MGM session. For example, a multicast can be scheduled to occur every 5 minutes within an hour (eg 5:05 pm, 5:10 pm, 5:15 pm, etc.). This schedule should be determined with the intention of allowing energy to be conserved at the terminals which wish to receive multicasts according to the MGM session, since the terminals will only have to monitor incoming transmissions during the scheduled time.

The schedule decision may take into account the energy usage characteristics of the generic terminals, for example within the region or regions specified during the MGM session. This characteristic can be seen by taking into account service provider records indicating the dissemination of specific terminal models in various regions and by further considering manufacturer technical specifications for these terminal models.

Next, one or more request processing modules may select or generate a key to be used when decrypting the message multicast during the MGM session (step 215). Modules can also choose which encryption method to use. Otherwise, one encryption method may always be used. Selection and / or generation of keys, and / or selection of encryption methods will take into account several factors. Among these factors may be the proposed encryption method included in the received specifications.

As a next step, session information relating to messaging addresses, multicasting addresses, schedules, keys, algorithms, etc., during the MGM session is placed by the modules into storage associated with the server and / or the user requesting the MGM session and / or the user. It may be transmitted to the terminal (step 217). In various embodiments of the present invention, the modules will not send this session information to entities requesting MGM sessions and / or entities other than user terminals.

Transmission can be done in a number of ways. For example, information may be placed in MMS messages, SMS messages, email messages, and so forth directed to be read directly at the user and / or user terminal that sent the MGM session request. As another example, the information may be encoded using XML or the like and placed in an MMS message or the like sent to the user or user terminal. As another example, information may be sent to one or more software modules running on a user terminal via SOAP, JMS, RMI, and the like.

MGM  Terminal reception and transmission of session information

After the terminal sending the MGM session request receives information related to the session from the MGM server, one or more operations may occur. For example, as shown in FIG. 3, message viewer program modules executed on a terminal in a conventional manner are MMS messages, session messages, etc., including session information, sent to the terminal user for direct reading by the user. It can be recovered by (step 301). The user can use one or more modules to read the message and know the session information contained therein. If necessary, the user can provide the learned information to an appropriate program module or the like executed in the terminal (step 303).

In addition to or in lieu of the user viewing the message and / or knowing the session information contained therein, one or more MGM session information extraction program modules operating on the terminal may be operable to extract the session information from the message. These modules record the information as described in more detail below, and send it to one or more appropriate program modules or the like running on the terminal. The program modules may know the format or formats that the MGM servers used to encode the session information to be read directly by the user and use this knowledge to extract session information from the message. Alternatively, modules may parse session information in messages using natural language parsing techniques known in the art.

Session information extraction modules may operate in a manner similar to that described above, to process received MMS messages, email messages, and the like that contain MGM session information that is not very specially encoded to be read directly by users. The message may, for example, include session information encoded in a manner using XML. As before, modules can know the format or formats that MGM servers used to encode session information and can use this knowledge to extract that session information. In addition to recording and / or conveying MGM session information, or instead, modules may cause session information to be displayed to the user, perhaps via a GUI dialog box. The user may know the information and / or provide the information to a suitable program module or the like running on the terminal.

When the MGM server sends the MGM session information to the terminal by SOAP, JMS, RMI, etc., the session information extraction modules may receive the information. In a manner corresponding to that described above, these modules may be operable to record the information and / or send it to one or more suitable program modules or the like running on the terminal. Alternatively, or in addition, the modules may cause the information to be displayed to the user.

It should be noted that after receiving the MGM session information at the requesting terminal, operations for transferring the session information to one or more additional terminals may occur. The delivery can be performed in a number of ways. For example, when a user receives an MMS message, an email message, or the like including session information presented for immediate viewing, the user may use the message transmission program module or the like running on the terminal to send the message to other users and / or Or, it can be delivered to the terminal (step 309).

The user can interact with the modules via a GUI, voice control and the like. When session information is displayed to a user via a GUI dialog box or the like, this dialog box or the like may provide a choice of performing information delivery to a specific user and / or terminal. In certain embodiments, the message transfer modules may be configured to enable specification of whether or not the recipient of the delivered message can deliver the message again (step 305). The user can set this option, for example via the GUI. The GUI may be such as can be used to select a delivery. If it is determined that further delivery should not be allowed, the modules may add such an indication to the transmitted message (step 307). In such embodiments, program modules running on the terminal may be configured to value such instructions, not allowing the user to convey a message containing such instructions.

In a similar manner, in various embodiments, an option may be provided for a user to deliver an MMS message, an email message, etc. including session information formatted using XML or the like. For example, a GUI dialog box that provides session information to a user may enable the user to specify the users and / or terminals to which the information should be delivered. As mentioned above, in certain embodiments the user may be provided with the option of not allowing further delivery of the message.

Likewise, in various embodiments the user may be provided with the option of conveying MGM session information received via SOAP or the like. Such embodiments may provide an interface, such as a GUI dialog box, through which a user may specify users and / or terminals to receive the information. In a manner similar to that described above, the user may be provided with the option to prevent further recipients from receiving the delivered session information. Modules running on the terminal may be operable to send session information to specific users and / or terminals via SOAP or the like, which may have been added to indicate that further delivery is not allowed.

When a terminal receives MGM session information transmitted from another terminal, operations corresponding to those described above with reference to the terminal receiving the session information from the MGM server will occur. For example, the user of the receiving terminal may be provided with the delivered session information through a dialog box or the like, and the delivered session information may be recorded and / or sent to program modules executed in the terminal. As another example, if it is not promised that the received delivery session information should not be delivered again, the received user may be provided with the option to further deliver that session information to additional terminals and / or users.

The receiving user may be provided with the option of specifying whether or not to allow the recipient of the newly delivered information to pass it back. Terminals and / or users who have received the newly delivered session information may similarly perform one or more of the operations described above with respect to that information.

Message multicast

As shown in FIG. 4, a user wishing to multicast a message via an MGM session operates to transmit the message to a message address (eg, SMS address) set corresponding to the session (step 401). The user may bring up a new message synthesis window associated with the message transfer modules operating at his terminal, which modules will be associated with a conventional message transfer program such as MMS, SMS, or email client. The user will be provided with a GUI button or the like that can be pressed to bring up the composite window. This button will contain a label such as "Click here to multicast the message to MGM session x", where "x" may be an identifier associated with the MGM session.

The new compositing window allows users to add messages under compositing elements such as text, files, graphics, sound, movies, and so on. It should be noted that some embodiments of the present invention may limit element types that may be added to a message. For example, in some embodiments only text may be allowed.

After completing message composition, the user can specify that the message be sent. The user can do this by, for example, entering the messaging address set for the MGM session in the GUI field associated with the synthesis window. The user can then press the "Send" GUI button associated with the window. The message transmission to that message address can be made according to the transmission methods known in the art for the messaging address type (eg SMS).

In certain embodiments, it should be noted that a 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 or the like running on the terminal can know the received session information. It may be further noted that functionality may be provided that allows for session start and end times to be taken into account by software modules running on the terminal of the user wishing to multicast the message. For example, software modules may prohibit the creation and / or transmission of a message to be multicast during a session if the start and end times did not indicate a session to be active or soon to be active.

If the MGM server or the like has received a message to be multicasted, one or more casting modules operating on the server will first determine the messaging address to which the message was sent (step 403). These modules can then access the storage described above to determine the MGM session associated with the messaging address (step 405).

The modules then determine if the session is active (step 407). It examines the clocks and / or calendars associated with the server and / or accessible by the server to determine the current time and / or date, the storage to determine the start and end times associated with the session, the current date and And / or by determining if the time was within or just before the session period. If it is found that the MGM session is not active, the terminal may stop further processing on the incoming message and send an SMS message or the like to the terminal and / or the user who sent the message to be multicast (step 409). The message sent may indicate, for example, that the session has expired.

Next, the one or more casting modules examine the storage described above to determine a multicast address associated with the MGM session (step 411). The modules can then access the storage to determine the encryption type and / or decryption key associated with the session (step 413). The modules can then encrypt the received message to be decrypted with the key (step 415). The modules then access the storage to detect what transmission schedules are associated with the MGM session (step 417).

One or more casting modules may then take action to cause the encrypted message to be multicast to the appropriate multicast address according to some schedule associated with the session (step 419). This may be done by providing one or more casting modules, for example with additional messages, to one or more software modules operating on a multicast point. The multicast point can be, for example, a unidirectional multicast point, such as a DVB-T or DVB-S multicast point. In various embodiments, the multicast point may instead use a bidirectional technology such as UMTS. The additional parameters may be to specify scheduling information related to the session and / or protocols to be used in multicast.

When a multicast schedule is associated with an MGM session, in one embodiment one or more casting modules operating on the MGM server will provide the message to the multicast point only at or immediately before the multicast point according to the schedule. In such embodiments, scheduling information may not be delivered to the multicast point. In other embodiments, one or more casting modules deliver the message to the multicast point without particular relevance to the multicast schedule, leaving the task of following the schedule to a software module operating on the multicast point. As mentioned above, the software modules of the multicast point may know about the schedule through additional parameters sent with the message to be multicast.

After receiving the message to be multicast and some additional parameters, the multicast point may perform formatting or reformatting of the message and / or its elements. For example, the message can be formatted or reformatted in a manner using HTML. The multicast point then multicasts the encrypted message. As noted above, in some embodiments the multicast point will multicast according to a schedule associated with the MGM session. Multicast can use UHTTP (unidirectional HTTP).

Receive a message

As discussed above, terminals and / or users may receive MGM session information. In some embodiments of the present invention, such a user or terminal user who wishes to receive multicasted messages in connection with an MGM session can take action to enable one or more message receiving modules on his terminal. The user may perform such a function, for example, through interaction with the GUI component represented by his terminal. It should also be noted that in many embodiments, such user manipulation of one or more message receiving modules is not necessary.

For example, the modules may run or run automatically whenever the MGM session information is received at the terminal. In some embodiments, a user may provide modules with one or more elements of received session information. This can be done by the user entering the element via a GUI panel or the like. In other embodiments, the modules may automatically receive or access these elements from the aforementioned storage, as described above.

One or more operational messages, starting at or near the start time described in the MGM session information and ending at or near the end time described in the MGM session information, such that the terminal is associated with a multicast address associated with the MGM session (step 501). Receive modules may take the action as shown in FIG. 5. The modules can then monitor the input transmission information sent towards the multicast address of the MGM session, starting at or near the start time described in the MGM session information and ending at or near the end time described in the MGM session information. (Step 503). If the MGM session information specifies a transmission schedule, one or more receiving modules may only monitor during the scheduled transmission period. This can improve energy conservation at the terminal compared to continuous monitoring. As described above, the message may be received via UHTTP or the like.

Upon receiving a message associated with an MGM session, one or more message receiving modules may decrypt the message according to a key and / or algorithm specified in the received session information (step 505). One or more modules may then create the message content available to the user (step 507). For example, modules may present message content to the user via a GUI display, audio output, and the like. One or more modules may query the user prior to displaying and / or making the message content available.

Hardware and software

Certain devices used in accordance with the present invention will be implemented using a computer. For example, the servers, multicast points, access points, relay devices, and terminals described above can be implemented using network capable computers. In addition, certain procedures described herein may be executed by the computer or with the help of it. The terms "computer", "universal computer", etc., as used herein, may refer to operating systems such as OS X, Linux, Darwin, Windows CE, Windows XP, Palm OS, Symbian OS, etc., which probably support Java or .Net. Processor card smart card, media device, personal computer, engineering workstation, PC, Macintosh, PDA, wired / wireless terminal, power supply, network access point, network multicast point, and the like.

The terms "universal computer", "computer" and the like also refer to, but are not limited to, one or more processors operatively connected to one or more memories or storage units. The memory or storage may include data, algorithms, and / or program code, and the processor or processors may execute the program code and / or process the program code, data, and / or algorithm. Thus, the typical computer 6000 shown in FIG. 6 has two processors 6061 and 6052, random access memory (RAM) 6053, read only memory (ROM) 6055, input / output (I / O) interface. 6057 and 6058, a storage interface 6059, and a system bus 6050 operably connected to the display interface 6061. Storage interface 6059 is in turn connected to mass storage 6063. Each of I / O interfaces 6057 and 6058 may be Ethernet, IEEE 1394, IEEE 802.11b, Bluetooth, DVB-T, DVB-S, DAB, GPRS, UMTS, or other interface known in the art.

The mass storage 6063 may be a hard drive, an optical drive, or the like. Processors 6057 and 6058 may be one commonly known, such as IBM or Motorola PowerPC, AMD Athlon, AMD Opteron, Intel StrongARM, or Intel Pentium, respectively. The computer 6000 as shown in this example also includes an LCD display unit 6001, a keyboard 6002 and a mouse 6003. In other embodiments, keyboard 6002 and / or mouse 6003 may be replaced with a touch screen, pen, or keypad interface. The computer 6000 may additionally include or connect card readers, DVD drives, or floppy disk drives to insert a medium containing program code for computer loading of the code.

In accordance with the present invention, a computer may execute one or more software modules designed to perform one or more of the above-described operations. The modules are programmed using a language such as Java, object-oriented C, C, C #, or C ++ by methods known in the art. Some of the operations described above among particular software modules are shown for purposes of illustration, and other operating portions may be used. Thus, operations discussed as being performed by one software module may alternatively be performed by a plurality of software modules. Similarly, operations discussed as being performed by a plurality of modules may alternatively be performed by one module.

While embodiments of the present invention have disclosed that certain software modules operate on certain devices, in other embodiments these modules may be assigned to run on other devices than described above. For example, one or more modules described as running on an MGM server may run on a terminal instead of the server, and vice versa. As another example, operations described as being performed by an MGM server may be performed by a plurality of servers and / or other devices instead of this server. In addition, it should be further noted that in many embodiments, grid computing techniques may be used.

Shown in FIG. 7 is a functional block diagram of an exemplary terminal used in various embodiments of the present invention. The terminal of FIG. 7 has been described above. In the following, corresponding references apply to the relevant components. Terminal 7000 of FIG. 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 705, and user interfaces 701 and 702. The multi-carrier signal terminal unit 705 and the user interfaces 701 and 702 are connected to a processing unit (CPU) 703. One or more direct memory access (DMA) channels may exist between the multicarrier signal terminal 705 and the memory 704. User interfaces 701 and 702 include a display and a keyboard to enable a user to use terminal 7000. In addition, the user interfaces 701 and 702 have microphones and speakers for receiving and reproducing audio signals. User interfaces 701 and 702 may also include speech recognition (not shown).

Processing unit (CPU) 703 includes a microprocessor (not shown), memory 704 and, if possible, software. Software may be stored in memory 704. Based on the software, the microprocessor controls the operation of the terminal 7000, such as reception of the data stream, immunity of impulse burst noise upon data reception, display of outputs on the user interface, and reading input received from the user interface. These operations have been described above. The hardware includes circuitry for signal detection, modulation circuitry, impulse detection circuitry, circuitry for blanking samples of symbols with a significant amount of impulse noise, estimation calculation circuitry, and circuitry for correcting corrupted data.

With further reference to FIG. 7, alternatively, middleware or software configurations may be applied. The terminal 7000 may be a portable device that a user may conveniently carry. Terminal 7000 may be a cellular mobile phone comprising a multi-carrier signal terminal 705 that receives a multicast transport stream. Accordingly, the terminal 7000 may interact with service providers.

Results and scope of the invention

While the description includes several specific details, these are provided merely to illustrate the invention and should not be construed as limiting the scope thereof. It will be apparent to those skilled in the art that numerous modifications and variations can be made to the systems and processes of the present invention without departing from the spirit and scope of the invention.

Claims (110)

In a method of multicasting messages, Receiving, from the initiator, a request for a multicast messaging session; Selecting a multicast address of the session; Associating the multicast address with a messaging address; Sending a decryption key to the initiator for distribution to one or more other parties by the initiator; Receiving, via the messaging address, a message to be multicast in the session; Encrypting the message to be decrypted using the key; And Multicasting the encrypted message via the multicast address. The method of claim 1, wherein the initiator prohibits the one or more other parties from distributing the key. delete delete 2. The method of claim 1, wherein the multicast address is selected from a bank of available multicast addresses. delete 2. The method of claim 1 wherein the messaging address is suggested by the speaker. 2. The method of claim 1, further comprising the step of establishing a multicasting schedule. delete 2. The method of claim 1, further comprising sending the messaging address to the initiator. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete In the messaging setup method, Sending a request for a multicast messaging session to a server; The server receiving the decryption key sent without sending it to the other party; Receiving, from the server, a multicast address associated with the session and messaging address by the server; And Transmitting the key to one or more parties that can be used to decrypt the multicasted messages in the session. 28. The method of claim 27, further comprising specifying that the one or more parties fail to distribute the key. 28. The method of claim 27, wherein the server provides a specification for a session duration. delete delete delete delete delete delete 28. The method of claim 27, wherein the server schedules a multicasting. delete delete 28. The method of claim 27, further comprising receiving the messaging address from the server. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete In a system for multicasting messages, A memory for storing program code; And A processor operatively connected with the memory to perform an instruction according to the stored program code, The program code, when executed by the processor, causes the processor to receive a request for a multicast messaging session from an initiator, to select a multicast address of the session, to convert a messaging address to the multicast address. Associating with a message, transmitting a decryption key to the initiator for distribution to one or more other parties by the initiator, receiving, via the messaging address, a message to be multicast in the session, Encrypting the message to be decrypted using the key, and multicasting the encrypted message via the multicast address. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete In the messaging setup system, A memory for storing program code; And A processor operatively coupled with the memory to execute instructions according to the stored program code, The program code, when executed by the processor, causes the processor to: send a request for a multicast messaging session to a server, receive a decryption key sent by the server without sending it to another party, from the server, Receive a multicast address associated with the session and messaging address, and transmit the key to one or more parties that can be used to decrypt the multicast messages in the session. system. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete In the terminal, A memory for storing program code; And A processor operatively coupled with the memory to execute instructions according to the stored program code, The program code, when executed by the processor, causes the processor to: send a request for a multicast messaging session to a server, receive a decryption key sent by the server without sending it to another entity, multicast Receiving the multicast address from a server that associates an address with the session and a messaging address with the multicast address, and sends the key to one or more parties used to decrypt the multicast messages in the session. And a terminal for performing the operation. In the server, A memory for storing program code; A processor operatively coupled to the memory for executing instructions in accordance with the stored program code; And A network interface operatively connected with the processor, The program code, when executed by the processor, causes the processor to receive, from an initiator, a request for a multicast messaging session, select a multicast address of the session, the multicast address and a messaging address. Associating a message, sending a decryption key to the initiator for distribution to one or more other parties by the initiator, receiving, via the messaging address, a message to be multicast in the session, Encrypting the message to be decrypted using the key, and multicasting the encrypted message through the multicast address.

Images