WO2004049737A2 - System and method for user-initiated group messaging - Google Patents
System and method for user-initiated group messaging Download PDFInfo
- Publication number
- WO2004049737A2 WO2004049737A2 PCT/IB2003/005102 IB0305102W WO2004049737A2 WO 2004049737 A2 WO2004049737 A2 WO 2004049737A2 IB 0305102 W IB0305102 W IB 0305102W WO 2004049737 A2 WO2004049737 A2 WO 2004049737A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- session
- multicasting
- request
- multicast
- server
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000004891 communication Methods 0.000 claims description 13
- 238000012546 transfer Methods 0.000 claims description 5
- 230000000977 initiatory effect Effects 0.000 claims 18
- 230000009471 action Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 6
- 238000005266 casting Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 2
- 238000004134 energy conservation Methods 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
Classifications
-
- G06Q50/40—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/48—Message addressing, e.g. address format or anonymous messages, aliases
Definitions
- This invention relates to systems and methods for data distribution.
- Such messaging includes, for example, email, SMS (Short Message Service), and MMS (Multimedia Messaging Service).
- SMS Short Message Service
- MMS Multimedia Messaging Service
- MGM Multicast Group Messaging
- the systems and methods further provide for dispatching messages for multicast in conjunction with the session, and for receiving messages multicast in conjunction with the session.
- Fig. 1 shows an exemplary network arrangement according to embodiments of the present invention.
- Fig. 2 is a flow chart showing steps involved in messaging setup according to various embodiments of the present invention.
- Fig. 3 is a flow chart showing steps involved in terminal receipt and forwarding of Multicast Group Messaging (MGM) session information according to various embodiments of the present invention.
- MGM Multicast Group Messaging
- Fig. 4 is a flow chart showing steps involved in message multicast according to various embodiments of the present invention.
- Fig. 5 is a flow chart showing steps involved in message reception according to various embodiments of the present invention.
- Fig. 6 shows an exemplary general purpose computer employable in various embodiments of the present invention.
- Fig. 7 shows a functional block diagram of an exemplary terminal employable in various embodiments of the present invention.
- a user may establish a Multicast Group Messaging (MGM) session wherein messages are delivered via multicast, and wherein she may exercise control over the parties that can consume the multicasted messages.
- MGM Multicast Group Messaging
- the user might establish such an MGM session by having her terminal dispatch an appropriate request to an MGM server. Included in the server's response to the request may be a key employable in decrypting messages multicast in conjunction with the MGM session.
- the user may then distribute the key and/or additional information to the parties she wishes to have the ability to consume messages multicast in conjunction with the session.
- the user might additionally specify if those parties forwarded the key and/or additional information may further disseminate that key and/or additional information to others.
- Fig. 1 Shown in Fig. 1 is an exemplary network configuration according to embodiments of the present invention, including MGM server 101, terminals 103, access point 105, and multicast point 107.
- MGM server 101 could request from MGM server 101, via access point 105, establishment of an MGM session.
- Access point 105 could be, for example, a UMTS (Universal Mobile Telecommunications Service), GPRS (General Packet Radio Service), or internet access point.
- UMTS Universal Mobile Telecommunications Service
- GPRS General Packet Radio Service
- the requesting terminal 103 could receive the key and/or additional information from MGM server 101 via access point 105. The requesting terminal could then forward the key and/or additional information to one or more terminals 103.
- Messages to be multicast could be dispatched by a terminal 103 to MGM server 101 via access point 105, encrypted by the MGM server, and then multicasted via multicast point 107 for consumption by appropriate terminals 103.
- Multicast point 107 could be, for instance, a unidirectional multicast point such as a DVB-T (Digital Video Broadcast - Terrestrial), DVB-S (Digital Video Broadcast - Satellite), or DAB (Digital Audio Broadcast) multicast point.
- the multicast point might instead employ a Didirectional technique such as UMTS.
- each of elements 101-107 there could be greater or fewer of each of elements 101-107 than is illustrated in exemplary Fig. 1. For instance, there could be a plurality of each of elements 101-107.
- a user wishing to initiate an MGM session may employ her terminal to request such from an MGM server or the like.
- the request could include certain specifications such as the start and end time desired for the MGM session, the regions in which multicasted messages should be receivable, a specification or suggestion of what type of encryption should be used in message multicast, and/or a suggestion or specification of the messaging address that should be established for submitting messages for multicast.
- the user could submit the request by manually creating and dispatching a message to an appropriate email, SMS (Short Message Service), MMS (Multimedia Messaging Service), or other messaging address.
- SMS Short Message Service
- MMS Multimedia Messaging Service
- it could be established that such a request should be dispatched as an SMS message directed to "MGMsetupf@messaging.serviceprovider.com”.
- Such a request might be required to be in a certain form.
- the request message may be required to include one or more lines in the form of "attribute: value”, with there being a number of acceptable attribute keywords and acceptable corresponding values or ranges of values.
- attribute could be "StartTime”.
- the corresponding value could be specified to be in the form "dd.mm.yyyy;hh:nn;zzz", with “dd” corresponding to standard two- ⁇ ign m ⁇ ication ior ⁇ ay-ol-month, "mm” corresponding to standard two-digit indication for month, "yyyy” corresponding to standard four-digit indication for year, “hh” corresponding to standard two-digit indication for hour, “nn” corresponding to standard two-digit indication for minute, and "zzz” corresponding to standard three-character indication for time zone.
- a user wishing to request MGM commencing at October 23, 2005 at 1 :36pm European Central Time might include in her request message the line "10.23.2005; 13:36;ECT”. Similar attributes and corresponding values could be established for other specifications of the sort mentioned above, such as regions or session end time.
- Such a manual request might alternately or additionally be permitted to be in free- form and/or natural language form.
- the user might be required to indicate certain informational elements (e.g., MGM session start time), but could choose her presentation form. Accordingly, the inclusion of "I wish to start today at 12:23pm" in the request could be an acceptable specification of start time.
- embodiments of the present invention could, additionally or alternately, allow the user to submit the session request via an interface.
- one or more presentation program modules operating on the user's terminal could present, for example, a graphical user interface (GUI) that the user could employ to submit required information regarding her MGM request.
- GUI graphical user interface
- the one or more presentation modules could present a GUI with which the user could choose, for instance, start time, end time, regions in which multicasted messages should be receivable, and the like.
- the GUI could additionally allow the user to select and/or specify the MGM server, MGM servers, or the like to which the request should be suomi te ⁇ .
- the list could be populated, for instance, by having one or more server discovery program modules operating on the terminal access a provider of such information.
- the modules might employ SOAP (Simple Object Access Protocol), JMS (Java Messaging Service), RMI (Remote Method Invocation), or the like.
- one or more request dispatch program modules operating on the terminal could forward the request to the one or more appropriate MGM servers or the like.
- the one or more request dispatch program modules could encode the information collected from the user into a text message and dispatch the message via email, SMS, MMS, or the like, directed to the appropriate server.
- the encoding could, for instance, employ XML (extensible Markup Language).
- the one more program modules could encode the message in compliance with any specified format.
- Such specified format may employ, for example, the above-described "attribute: value" format.
- the one or more request dispatch program modules could communicate the information collected from the user to the appropriate MGM server or the like via SOAP, JMS, RMI or the like.
- an MGM server or the like may receive from a terminal a request for an MGM session that includes a number of specifications (step 201).
- one or more request receiving program modules running on the server could act to extract from the message the specifications contained therein (step 203).
- the one or more request receiving modules could act to extract the specifications in accordance with the format. For instance, in the case where the specifications are in the above-noted "attribute:value" format, the one or more modules could scan the incoming message for the defined attributes and note the corresponding values. In the case where one or more necessary informational elements, or portions thereof, were missing from a request, an error message could be returned to the submitting user and/or terminal, perhaps via the same transport method (e.g., SMS) that was used to dispatch the session request.
- the transport method e.g., SMS
- the request receiving modules might make an attempt to guess missing data. For example, if a start time was expressed in hours and minutes, but without indication of date or time zone, the modules might make the assumption that the time zone was the user's local time zone. Further, in the case where the indicated time had not yet happened that day, the modules might make the assumption that the unspecified date was that day. On the other hand, in the case where the indicated time had already passed that day, the date could be assumed to be the following day. In the case of missing information, where no guess or satisfactory guess could be made by the modules or in embodiments where the modules performed no such guessing function, an error message could be returned to the requesting user and/or terminal in a manner like that described above.
- the one or more request receiving modules could employ natural language interpretation and/or parsing techniques known in the art to extract the specifications contained in the message. Because of the free-form nature of such a request, users might intentionally or unintentionally omit certain information. For example, a user specifying start and end time might omit date, year, and time zone, perhaps believing these to be inherent or obvious.
- the request processing modules could attempt to guess missing data as above. In the case of missing information, where no guess or satisfactory guess could be made by the modules or in embodiments where the modules performed no such guessing function, an error message could be returned to the requesting user and/or terminal in a manner like that described above.
- request receiving modules running on the terminal could directly receive the passed elements without needed to perform parsing or the like of the sort described above.
- the request receiving modules could place the specifications in an associated store (step 205). Also placed here could be an indication of the user and/or terminal that made the request. The indication could be, for example, the user's MMS address. Such could be determined, for example, by examining the headers if the session request message or by analyzing the SOAP, JMS, RMI, or similar communications.
- the items placed in the store could then be processed by one or more request handler modules running on the MGM server or the like.
- the one or more request handler modules could act to determine a multicast address, such as a multicast IP (Internet Protocol) address, to employ in multicast group messaging (step 207).
- a multicast address such as a multicast IP (Internet Protocol) address
- the multicast address could, for example, be chosen from a pool of available multicast addresses, perhaps with the intention that the address would be returned to the pool once the requested MGM session was complete.
- the one or more request handler modules might take into account one or more received specifications in making the selection from the pool. For instance, start time, end time, and/or region could be considered.
- the one or more request handler modules could remove the address form the pool of available addresses.
- the one or more request handler modules could establish a messaging address, such as an email address, SMS address, or MMS address, for receiving messages to be multicast, (step 209).
- the one or more request handler modules might choose the messaging address from a pool of available messaging addresses. In the case where the received specifications included a user's suggestion for the messaging address, the modules might take this into account when selecting a messaging address from the pool. For instance, if there was a suggestion that the messaging address include the phrase "gaming chat", the modules might look for an available messaging address containing the phrase or closely matching the phrase.
- the one or more request handler modules might newly establish a messaging address.
- the newly established messaging address could be in accordance with the specification and/or suggestion.
- the one or more request handler modules might take steps so that messages directed to the messaging address would be received by the MGM server, and/or have an appropriate messaging account established on an integrated and or separate SMS server, MMS server, or the like.
- the one or more request handler modules might also take steps to have the account removed from the appropriate MMS server or the like upon termination of the MGM session.
- the one or more request handler modules could specify, in an associated store, a correlation between the multicasting address and the messaging address (step 211).
- the one or more request handler modules might determine a schedule for multicasts within the MGM session (step 213). For instance, it might be determined that multicasts would occur every fifth minute within an hour (e.g., 5:05pm, 5:10pm, 5:15pm, and so on). Such a schedule might be determined with the intention of promoting energy conservation in terminals wising to receive multicasts according to the MGM session, as the terminals might only have to monitor for incoming transmission during the scheduled times.
- the schedule determination could take into account, for example, the energy use characteristics of typical terminals in the regions or regions specified for the MGM session. Such characteristics could be known, for instance, by considering service provider records indicating the prevalence of specific terminal models in various regions and further considering manufacturer technical specifications regarding those terminal models.
- the one or more request handler modules could select or create a key to be used in decrypting messages multicast during the MGM session (step 215).
- the modules might also select an encryption method to employ. Alternately, one encryption method might always be used.
- the selection and/or creation of a key, and/or selection of encryption method might take into account a number of factors. Among these factors may be a suggested encryption method inciu ⁇ e ⁇ in tne received specifications.
- session information relating to the messaging address, multicasting address, schedule, key, algorithm, and/or the like for the MGM session could be placed by the modules in a store associated with the server, and/or forwarded to the user who requested the MGM session and/or the user's terminal (step 217).
- the modules might forward this session information to no entities other than the user who requested the MGM session and/or the user's terminal.
- the forwarding could be done in a number of ways.
- the information could be placed in an MMS message, SMS message, email message, or the like directed to the user who dispatched the MGM session request, and/or that user's terminal, for direct reading by that user.
- the information could be encoded employing XML or the like, and placed in an MMS message or the like directed to that user or her terminal.
- the information could be communicated via SOAP, JMS, RMI, or the like to one or more software modules operating on the user's terminal.
- a terminal that dispatched an MGM session request receiving, from an MGM server, information relating to that session, one or more of several actions may take place. For instance, as illustrated in Fig. 3, a session-information-bearing MMS message, email message, or the like, directed to the terminal's user for direct reading by that user, could be retrieved, in a conventional manner, by message viewer program modules running on the terminal (step 301). The user could employ the one or more modules to read the message and could note the session information contained therein. The user could, as necessary, provide the noted information to appropriate program modules and the like running on the terminal (step 303).
- one or more MGM Session information extraction program modules operating on the terminal could act to extract the session information from the message. These modules could record the information and/or, as will be described in greater detail below, pass it to one or more appropriate program modules or the like operating on the terminal.
- the program modules could be aware of the format or formats that MGM servers use to encode session information for direct reading by users, and could employ this knowledge in extracting the session information from the message. Alternately, the modules might parse the message for session information using natural language parsing techniques or the like known in the art.
- the session information extraction modules could act in a similar manner to that just described.
- a message may, for example, be one containing session information encoded in a manner employing XML.
- the modules could be aware of the format or formats that MGM servers employ in encoding session information, and could employ this knowledge in extracting the session information.
- the modules could have the session information displayed to the user, perhaps via a GUI dialog box. The user could note the information and/or provide the information to appropriate program modules and the like running on the terminal.
- the session information extraction modules coui ⁇ receive tne lmormation. in a manner analogous to that noted above, the modules could act to record the information and/or pass it to one or more appropriate program modules or the like operating on the terminal. Alternately or additionally, the modules could have the information displayed to the user.
- actions may take place to forward the session information to one or more additional terminals.
- the forwarding could be performed in a number of ways. For instance, in the case where the user received an MMS message, email message, or the like with the included session information presented for direct reading, the user could forward the message to one or more other users and/or terminals, employing perhaps message sending program modules running on the terminal (step 309).
- the user might interact with the modules via a GUI, voice control, or the like.
- the dialog box or the like could offer a selection to perform forwarding of the information to a specified user and/or terminal.
- the message sending modules could be configured so as to allow specification of whether or not the recipient of a forwarded message could further forward that message (step 305).
- a user could set this option, for example, via a GUI.
- the GUI might be the same one employable to select forwarding.
- the modules could append an indication of such to the forwarded message (step 307).
- program modules operating on terminals could be configured to respect such indicators, such that a user would be disallowed from forwarding a message bearing such an indication.
- the user could be presented with the option to forward an MMS message, email message, or the like containing session information formatted employing XML or the like.
- a GUI dialog box presenting the session information to the user could further allow the user to specify users and/or terminals to which the information should be forwarded.
- the user might be presented with the option to disallow further forwarding of the message.
- the user could be presented with the option to forward MGM session information received via SOAP or the like.
- Such embodiments could offer an interface, such as a GUI dialog box, whereby the user could specify users and/or terminals that should receive the information.
- the user could be presented with the option to prevent those who receive the forwarded session information from further forwarding it.
- Modules running on the terminal could act to dispatch the session information, perhaps with an appended indication of no further forwarding be allowed, to the specified users and/or terminals via SOAP or the like.
- actions analogous to those described above with reference to a terminal receiving session information from an MGM server could take place.
- the user of the receiving terminal could be presented with the forwarded session information via a dialog box or the like, and the forwarded session information could be recorded and/or passed to program modules running on the terminal.
- the receiving user could be presented with the option to further forward the session information to additional terminals and/or users.
- the receiving user could, perhaps, also be presented with the option to specify whether or not a recipient of the newly-forwarded information is allowed to further forward it.
- the terminals and or users receiving the newly-forwarded session information could analogously perform one or more of the above-described actions with regard to the information.
- a user wishing to have a message multicast via the MGM session may, as is illustrated in Fig. 4, act to have that message dispatched to the established messaging address (e.g., SMS address) corresponding to the session (step 401).
- the user could invoke a new message composition window associated with message sending modules operating on her terminal, the modules perhaps being associated with a conventional message dispatch program, such as an MMS, SMS, or email client.
- the user might be presented with a GUI button or the like that could be pressed to launch the composition window.
- the button might carry a label such as "click here to multicast a message to MGM Session x", where in place of "x" could be an identifier associated with the MGM session.
- composition elements such as text, files, graphics, sounds, movies, and the like. It is noted that some embodiments of the present invention could limit the element types that could be added to a message. For instance, in some embodiments only text might be permitted.
- the user could specify that the message be dispatched.
- the user might do this, for example, by entering the established messaging address for the MGM session into a GUI field associated with the composition window. The user might then press a "send" GUI button associated with the window.
- Dispatch of the message to the messaging address could be in accordance with the transport methods known in the art for the messaging address type (e.g., SMS).
- the user might not need to specify the estaonshed messaging address. This could be the case, for instance, in the above-noted embodiments where software modules or the like running on a terminal were made aware of received session information. It is further noted that functionality might be provided whereby session start and end times could be taken into account by software modules running on the terminal of the user wishing to multicast a message. For instance, the software modules might prevent the creation and/or dispatch of a message to be multicast in a session unless the start and stop times indicated the session to be active or to soon be active.
- one or more casting modules operating on the server might first determine the messaging address to which the message was directed (step 403). Next, the modules could access the above-noted store in order to determine the MGM session associated with the messaging address (step 405).
- the modules might determine if the session was active (step 407). This could be done by consulting a clock and/or calendar associated with and/or accessible by the server to determine the current time and/or date, consulting the store to determine the start and stop times associated with the session, and deciding if the present date and/or time was within and/or closely before the session period.
- the terminal might stop further processing on the incoming message, and might send an SMS message or the like to the terminal and/or user that dispatched the message to be multicast (step 409). The message sent could, for example, specify that the session had expired.
- the one or more casting modules could consult the above-noted store to determine the multicast address associated with the MGM session (step 411).
- the modules might then access the store in order to determine the encryption type and/or decryption key associated with the session (step 413).
- the modules could next encrypt the received message for decryption with the key (step 415).
- the modules might access the store to learn of any transmission schedule associated with the MGM session (step 417).
- the one or more casting modules could next take steps to have the encrypted message multicast to the appropriate multicast address in accordance with any schedule associated with the session (step 419).
- the one or more casting modules could achieve this, for instance, by submitting the encrypted message, along perhaps with additional parameters, to one or more software modules operating on a multicast point.
- the multicast point could be, for example, a unidirectional multicast point such as a DVB-T or DVB-S multicast point.
- the multicast point might instead employ a bidirectional technique such as UMTS.
- the additional parameters might specify, for example, scheduling information associated with the session and/or protocols that should be employed in the multicast.
- the one or more casting modules operating on the MGM server might submit the message to the multicast point only at or shortly prior to a multicast time in accordance with the schedule. In such embodiments, scheduling information might not be forwarded to the multicast point. In other embodiments, the one or more casting modules might forward the message to the multicast point without particular regard to the multicast schedule, leaving the task of schedule compliance to software modules operating on the multicast point. As alluded to above, software modules of the multicast point could know of the schedule by way of additional parameters dispatched with the message to be multicast.
- the multicast point might perform formatting or reformatting of the message and/or the elements thereof.
- the message could be formatted or reformatted in a way that employs H ML.
- the multicast point might next multicast the encrypted message.
- the multicast point might multicast in accordance with a schedule associated with the MGM session.
- the multicast could, for example, employ UHTTP (Unidirectional Hypertext Transfer Protocol).
- terminals and/or users may receive MGM Session Information.
- such a user or a user of such a terminal who wishes to receive messages multicast in association with the MGM session may take action to have one or more message reception modules on her terminal be activated.
- the user could make such a specification, for instance, via interaction with GUI elements presented by her terminal. It is further noted hat, according to various embodiments, no such user activation of the one or more message reception modules may be necessary.
- the modules could always be running or might be activated automatically upon reception of MGM session information at the terminal.
- the user might provide to the modules one or more elements of the received session information. The user might do this by entering the elements via a GUI panel or the like.
- the modules might, as alluded to above, automatically receive these elements and/or access them from the previously-noted store.
- the active one or more message reception modules may take action as illustrated in Fig. 5 so that, starting at or near the start time stated in the MGM session information and ending at or near the end time stated in the MGM session information, the terminal would be associated with the multicast address associated with the MGM session (step 501).
- the modules ⁇ ui ⁇ men, siarung at or near the MUM session start time and ending at or near the MGM session end time stated in the received information elements, monitor for incoming transmissions directed towards the MGM session's multicast address (step 503).
- the one more reception modules might only monitor during the scheduled transmission periods. This could lead to improved energy conservation at the terminal in comparison to constant monitoring.
- the message might be received via UHTTP or the like.
- the one or more message reception modules could decrypt the message in accordance with the key and/or algorithm specified in the received session information (step 505).
- the one or more modules could next make the message content available to the user (step 507).
- the modules could, for instance, display the message content to the user via GUI displays, audio outputs, and/or the like.
- the one or more modules might query the user before displaying and/or making available the message content.
- Certain devices employed in accordance with the present invention may be implemented using computers.
- the above-noted servers, multicast points, access points, relay devices, and terminals may be implemented using network-capable computers.
- certain procedures and the like described herein may be executed by or with the help of computers.
- computer refers but are not limited to a processor card smart card, a media device, a personal computer, an engineering workstation, a PC, a Macintosh, a PDA, a wired or wireless terminal, a server, a network access point, a network multicast point, or the like, perhaps running an operating system such as OS X, Linux, Darwin, Windows CE, Windows XP, Palm OS, Symbian OS, or the like, perhaps with support for Java or .Net.
- exemplary computer 6000 as shown in Fig. 6 includes system bus 6050 which operatively connects two processors 6051 and 6052, random access memory (RAM) 6053, read-only memory (ROM) 6055, input putput (I/O) interfaces 6057 and 6058, storage interface 6059, and display interface 6061.
- Storage interface 6059 in turn connects to mass storage 6063.
- I/O interfaces 6057 and 6058 may be an Ethernet, IEEE 1394, IEEE 802. l ib, Bluetooth, DVB-T, DVB-S, DAB, GPRS, UMTS, or other interface known in the art.
- Mass storage 6063 may be a hard drive, optical drive, or the like.
- Processors 6057 and 6058 may each be a commonly known processor such as an IBM or Motorola PowerPC, an AMD Athlon, an AMD Opteron, an Intel StrongARM, or an Intel Pentium.
- Computer 6000 as shown in this example also includes an LCD display unit 6001, a keyboard 6002 and a mouse 6003. In alternate embodiments, keyboard 6002, and/or mouse 6003 might be replaced with a touch screen, pen, or keypad interface.
- Computer 6000 may additionally include or be attached to card readers, DVD drives, or floppy disk drives whereby media containing program code may be inserted for the purpose of loading the code onto the computer.
- a computer may run one or more software modules designed to perform one or more of the above-described operations, the modules being programmed using a language such as Java, Objective C, C, C#, or C++ according to methods known in the art. It is noted that the above-described division of operations among particular software modules is for purposes of illustration, and that alternate divisions of operation may be employed. Accordingly, operations discussed as being performed by one software module might instead be performed by a plurality of software modules. Similarly, operations discussed as being performed by a plurality of modules might instead be performed by a single module.
- embodiments of the invention disclose certain software modules as operating on certain devices, in alternate embodiments these modules might be distributed to run on other devices than those stated. For instance, one or more modules disclosed to be running on an MGM server might instead run on a terminal or vice versa. As another example, operations disclosed as being performed by the MGM server might instead be performed by a plurality of servers and/or other devices. It is further noted that, in various embodiments, grid computing techniques may be employed.
- Fig. 7 Shown in Fig. 7 is a functional block diagram of an exemplary terminal employable in various embodiments of the present invention.
- the terminal of Fig. 7 has been discussed in the foregoing. In the following, corresponding reference signs have been applied to corresponding parts.
- Terminal 7000 of Fig. 7 may be used in any/all of the embodiments described herein.
- the terminal 7000 comprises a processing unit CPU 703, a multi -carrier signal terminal part 705 and a user interface (701, 702).
- the multi-carrier signal terminal part 705 and the user interface (701, 702) are coupled with the processing unit CPU 703.
- One or more direct memory access (DMA) channels may exist between multi-carrier signal terminal part 705 and memory 704.
- DMA direct memory access
- the user interface (701, 702) comprises a display and a keyboard to enable a user to use the terminal 7000.
- the user interface (701, 702) comprises a microphone and a speaker for receiving and producing audio signals.
- the user interface (701, 702) may also comprise voice recognition (not shown).
- the processing unit CPU 703 comprises a microprocessor (not shown), memory 704 and possibly software.
- the software can be stored in the memory 704.
- the microprocessor controls, on the basis of the software, the operation of the terminal 7000, such as the receiving of the data stream, the tolerance of the impulse burst noise in the data reception, displaying output in the user interface and the reading of inputs received from the user interface. The operations are described above.
- the hardware contains circuitry for detecting the signal, circuitry for demodulation, circuitry for detecting the impulse, circuitry for blanking those samples of the symbol where significant amount of impulse noise is present, circuitry for calculating estimates, and circuitry for performing the corrections of the corrupted data.
- the terminal 7000 can be a hand-held device which the user can comfortably carry.
- the terminal 7000 can be a cellular mobile phone which comprises the multi-carrier signal terminal part 705 for receiving the multicast transmission stream. Therefore, the terminal 7000 may possibly interact with the service providers.
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03769795A EP1579338A4 (en) | 2002-11-25 | 2003-11-10 | System and method for user-initiated group messaging |
AU2003278495A AU2003278495A1 (en) | 2002-11-25 | 2003-11-10 | System and method for user-initiated group messaging |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US30320302A | 2002-11-25 | 2002-11-25 | |
US10/303,203 | 2002-11-25 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2004049737A2 true WO2004049737A2 (en) | 2004-06-10 |
WO2004049737A3 WO2004049737A3 (en) | 2004-12-16 |
Family
ID=32392415
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2003/005102 WO2004049737A2 (en) | 2002-11-25 | 2003-11-10 | System and method for user-initiated group messaging |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP1579338A4 (en) |
KR (1) | KR100768153B1 (en) |
CN (1) | CN100416539C (en) |
AU (1) | AU2003278495A1 (en) |
WO (1) | WO2004049737A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1630738A1 (en) * | 2004-08-31 | 2006-03-01 | NTT DoCoMo, Inc. | Email multicasting device |
CN100454806C (en) * | 2004-07-29 | 2009-01-21 | 北京航空航天大学 | Safety group broadcast management system and method |
CN102130788A (en) * | 2011-03-14 | 2011-07-20 | 华为技术有限公司 | Method, device and system for configuring monitoring terminal |
US9288170B2 (en) | 2011-11-16 | 2016-03-15 | Alibaba Group Holding Limited | Group messaging for facilitating interactions between users |
US9363346B2 (en) | 2006-05-10 | 2016-06-07 | Marvell World Trade Ltd. | Remote control of network appliances using voice over internet protocol phone |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE602005027090D1 (en) | 2005-12-02 | 2011-05-05 | Microsoft Corp | news agency |
CN101150533B (en) * | 2006-09-18 | 2010-05-12 | 联想(北京)有限公司 | A secure system and method for multi-point mail push |
CN101212421B (en) * | 2006-12-31 | 2011-12-28 | 联想(北京)有限公司 | Email pushing method and system |
CN101159858B (en) * | 2007-11-21 | 2012-03-28 | 杭州华三通信技术有限公司 | Method and equipment of reading video data |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6650869B2 (en) * | 2000-04-14 | 2003-11-18 | Hughes Electronics Corporation | System and method for managing return channel bandwidth in a two-way satellite system |
US20040064688A1 (en) * | 2000-07-14 | 2004-04-01 | Andre Jacobs | Secure packet-based data broadcasting architecture |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR0171003B1 (en) * | 1995-12-13 | 1999-03-30 | 양승택 | Information protecting protocol |
US6049878A (en) * | 1998-01-20 | 2000-04-11 | Sun Microsystems, Inc. | Efficient, secure multicasting with global knowledge |
US6182214B1 (en) * | 1999-01-08 | 2001-01-30 | Bay Networks, Inc. | Exchanging a secret over an unreliable network |
US6263435B1 (en) * | 1999-07-06 | 2001-07-17 | Matsushita Electric Industrial Co., Ltd. | Dual encryption protocol for scalable secure group communication |
WO2003036857A1 (en) * | 2001-10-24 | 2003-05-01 | Nokia Corporation | Ciphering as a part of the multicast cencept |
-
2003
- 2003-11-10 CN CNB2003801061750A patent/CN100416539C/en not_active Expired - Fee Related
- 2003-11-10 WO PCT/IB2003/005102 patent/WO2004049737A2/en not_active Application Discontinuation
- 2003-11-10 KR KR1020057009354A patent/KR100768153B1/en not_active IP Right Cessation
- 2003-11-10 AU AU2003278495A patent/AU2003278495A1/en not_active Abandoned
- 2003-11-10 EP EP03769795A patent/EP1579338A4/en not_active Withdrawn
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6650869B2 (en) * | 2000-04-14 | 2003-11-18 | Hughes Electronics Corporation | System and method for managing return channel bandwidth in a two-way satellite system |
US20040064688A1 (en) * | 2000-07-14 | 2004-04-01 | Andre Jacobs | Secure packet-based data broadcasting architecture |
Non-Patent Citations (1)
Title |
---|
See also references of EP1579338A2 * |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100454806C (en) * | 2004-07-29 | 2009-01-21 | 北京航空航天大学 | Safety group broadcast management system and method |
EP1630738A1 (en) * | 2004-08-31 | 2006-03-01 | NTT DoCoMo, Inc. | Email multicasting device |
KR100855444B1 (en) * | 2004-08-31 | 2008-09-01 | 엔티티 도꼬모 인코퍼레이티드 | Email multicasting device |
US7590700B2 (en) | 2004-08-31 | 2009-09-15 | Ntt Docomo, Inc. | Email multicasting device |
US9363346B2 (en) | 2006-05-10 | 2016-06-07 | Marvell World Trade Ltd. | Remote control of network appliances using voice over internet protocol phone |
CN102130788A (en) * | 2011-03-14 | 2011-07-20 | 华为技术有限公司 | Method, device and system for configuring monitoring terminal |
CN102130788B (en) * | 2011-03-14 | 2013-04-24 | 华为技术有限公司 | Method, device and system for configuring monitoring terminal |
US9288170B2 (en) | 2011-11-16 | 2016-03-15 | Alibaba Group Holding Limited | Group messaging for facilitating interactions between users |
Also Published As
Publication number | Publication date |
---|---|
EP1579338A4 (en) | 2007-03-14 |
EP1579338A2 (en) | 2005-09-28 |
WO2004049737A3 (en) | 2004-12-16 |
CN1726482A (en) | 2006-01-25 |
CN100416539C (en) | 2008-09-03 |
KR100768153B1 (en) | 2007-10-17 |
KR20050071707A (en) | 2005-07-07 |
AU2003278495A1 (en) | 2004-06-18 |
AU2003278495A8 (en) | 2004-06-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10810623B2 (en) | E-commerce messaging using SMS | |
US7519658B1 (en) | Automatic blogging during media viewing | |
US8073916B2 (en) | Managing electronic messages | |
CN100536561C (en) | Content distribution method and relay apparatus | |
US8369878B2 (en) | Personalized multimedia messaging system | |
US20070067403A1 (en) | Data Delivery System | |
US20100153491A1 (en) | Method, System And Client Terminal For Sending Data In Instant Messaging System | |
WO2008069978A2 (en) | Content sharing system and method for devices | |
JP2007537650A (en) | Method for transmitting message from recipient to recipient, message transmission system and message conversion means | |
WO2004049737A2 (en) | System and method for user-initiated group messaging | |
EP1527558B1 (en) | System and method for the multicast distribution of multimedia messaging service messages | |
US20080189357A1 (en) | Community journaling using mobile devices | |
US20130298020A1 (en) | Apparatus and method for handling interactive media content requests using multiple media managers | |
US9998585B2 (en) | Content selection and delivery of complementary information | |
JP4345893B2 (en) | Method and apparatus for e-commerce message using short message service | |
WO2012131708A2 (en) | Video messaging and mailing service | |
CN101427576B (en) | Method for generating packets for at least one mobile receiver | |
KR20020079326A (en) | On-demand/reservation type wireless multicasting system of using mobile terminal and method thereof | |
RU2388154C1 (en) | Method and system for providing notification message in mobile broadcast system | |
KR20010008460A (en) | Method for processing urgent message in push system | |
WO2008094639A1 (en) | Systems and methods for distributing messages to mobile devices | |
US20130298176A1 (en) | Apparatus and method for handling interactive media content requests using mobile media manager and virtual location media servers | |
WO2013111165A1 (en) | Method and system for transmitting and viewing high quality video on mobile stations | |
CA2406568A1 (en) | Method and apparatus for a universal encoding template for sms ecommerce messaging | |
IL214115A (en) | Personalized multimedia messaging system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 1020057009354 Country of ref document: KR |
|
WWE | Wipo information: entry into national phase |
Ref document number: 20038A61750 Country of ref document: CN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2003769795 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 1020057009354 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2003769795 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |