KR100386642B1 - Method and apparatus for providing a scalable pervasive notification service - Google Patents

Abstract

The present invention relates to a notification service provided for transmitting a message to one or more desired receiving devices associated with a user or subscriber. The notification service includes a notification server operatively connected with one or more gateways. Each gateway is connected directly or via a switch to one or more receiving devices associated with the user (s) or subscriber (s) of the notification service. The gateway includes a message queue storing the message to be delivered and / or a transcoder that converts the format type of the message received from the notification server into a different format type usable by the desired receiving device.

Description

Notification service for sending messages and how to send messages {METHOD AND APPARATUS FOR PROVIDING A SCALABLE PERVASIVE NOTIFICATION SERVICE}

The present invention relates generally to communication systems and, more particularly, to the transmission of messages to one or more devices associated with a desired recipient in an environment in which the devices are distributed.

In today's industry it is well known to deliver messages to specific devices. For example, paging systems deliver messages to subscribers and cellular services deliver phone calls to customers. Due to the proliferation of these and similar devices, a single user often has multiple devices capable of receiving or sending messages. This creates a problem that when someone tries to send a message to an individual using a conventional message delivery system, the sender must know and preserve a number of addresses (eg, phone numbers, pager numbers, service providers, etc.). In addition, the sender may not know the device that the desired receiver is delivering at any specific point of time, resulting in a redundant message is transmitted to different devices. It is also possible to send a message to a device that the sender does not know the capacity of the desired receiving device (s) and cannot efficiently process. Further, the sender may not know which device the desired recipient prefers to receive the message for any given time.

Conventional messaging systems have attempted to address issues related to current message delivery. For example, in US Pat. No. 5,928,325, Soughnessy et al. Discussed the problem of tracking a device associated with a particular user and disclosed a solution. In essence, Sounes et al. Provide a method of sending a message to one or more user devices currently available to a desired recipient. The system keeps track of the devices associated with each subscriber and which of those devices is currently operating. When someone needs to deliver a message to a subscriber, it sends a message to this system, which sends it directly to one or more subscriber's devices.

Likewise, in US Pat. No. 5,493,692, Theimer et al. Disclose a system (date earlier than the system already described) that delivers a message to a user or group of users in an environment involving mobile and fixed devices. Tamers and the like deliver messages based on the context of the intended recipient. The message is given a level of privacy and a priority and contextual attributes for delivery. The system delivers the message to the intended recipient if the recipient's environment matches the desired context.

As another example of a conventional messaging system, MessageBlaster ^SM provides a service that allows subscribers to preserve information about their contacts and send messages to one or more of these contacts. The system will contact each identified person using one or more methods specified by the sender, including telephone, fax, e-mail, pager, and mail. Each subscriber of the MessageBlaster ^SM system must maintain a personal contact list and device information for each device delivered by these contacts, which is tedious, error prone and endless. In addition, this approach to message delivery prevents the receiver from having any control over the way the message is delivered (except for the control provided by the service provider of the device selected by the sender). A more detailed description of this service may be found, for example, by accessing the MessageBlaster ^SM web site at the URL address http://www.messageblaster.com (originally described on February 10, 2000).

Although all of the systems described above solve one aspect of the problems previously described, none of these systems, when considered individually or together, solve all the subtle problems of the complex issues involved. For example, no system can solve the problem of supporting disconnected devices or ultimately reconnecting disconnected devices to a messaging service. In addition, no system can take advantage of the functionality provided by two-way communication systems (such as two-way calling systems, Palm Phone systems, SMS, etc.). Such communication systems provide the ability for end users to respond to received messages. This feature provides an opportunity for end users to respond to messages received through the messaging system and potentially affect how the messaging system handles future requests. Some conventional messaging systems allow users to specify limited user preferences, but none of these systems address how to support highly variable user preferences or allow users to dynamically modify their preferences. I can't. In addition, although some of these systems may use information about the current state of the user, their devices and / or the environment, they may not be able to preserve and / or use information about the user's past habits in determining message delivery. have.

Therefore, in the field of electronic message delivery, it is possible to support devices that are disconnected and then reconnected to the system, to take advantage of the characteristics of bidirectional communication systems, to handle highly variable user preferences, and to determine complex message delivery in time. It is necessary to consider the behavior and preference accordingly.

It is an object of the present invention to provide a notification system capable of supporting a device associated with and disconnected from a desired message recipient.

It is another object of the present invention to provide a notification system that supports multiple devices via a gateway or device proxy.

It is yet another object of the present invention to provide a notification system capable of sending messages to multiple devices at any point in the message transmission.

It is yet another object of the present invention to provide a notification system that supports transcoding of messages based on device type or user preference.

Another object of the present invention is to provide a notification system capable of dynamic device configuration.

It is still another object of the present invention to provide a notification system capable of confirming message delivery to a desired device.

The present invention revolutionizes message transmission to a desired recipient by providing a method and apparatus for electronic message collection, transformation, and delivery to one or more devices associated with the desired recipient. In a preferred embodiment, the present invention can support disconnected devices, support multiple similar devices through gateways or device proxies, support highly variable user preferences, support dynamic device configuration, It can support delivery confirmation to be returned to the sender and can increase scalability by supporting transcoding at the gateway.

According to one aspect of the present invention, a notification service is provided for sending a message to one or more desired receiving devices associated with a user or subscriber of the notification service. The notification service includes a notification server operatively connected with one or more gateways. Each gateway is connected directly or via a switch to one or more receiving devices associated with the user (s) or subscriber (s) of the notification service. The gateway preferably includes a message queue storing the message to be forwarded and / or a transcoder for converting the format type of the message received from the notification server into a different format type that the desired receiving device can use. By providing a message queue, the gateway supports message delivery to disconnected devices that are subsequently reconnected to the notification service. In addition, by employing a gateway that includes a transcoder, message translation is dynamically changed to match a particular device corresponding to the gateway to provide a scalable notification service.

These and other objects, features, and advantages of the present invention will become apparent from the following detailed description of the preferred embodiments taken in conjunction with the accompanying drawings, in which like elements are designated by like reference numerals.

1 is a block diagram showing a notification server configured according to an embodiment of the present invention;

2 is a block diagram showing a gateway configured according to an embodiment of the present invention;

3A and 3B are logic flow diagrams illustrating a preferred process for the notification server of FIG. 1 to forward a message in accordance with the present invention;

4 is a logic flow diagram illustrating a preferred process for a gateway such as that shown in FIG. 2 to accept an input message for one of its devices in accordance with the present invention;

5A and 5B are logic flow diagrams illustrating a preferred process for a gateway to service a message in its delivery queue in accordance with the present invention.

Explanation of symbols for the main parts of the drawings

1000: Notification Server 1010: Management Information Database

1020: user preferences database

1025: graphical user interface

1030: Gateway Database

1040: Transcoder 1050: Directory Server

1060: recognition server 1070-1090: gateway

1100-1130: Switch 1140-1180: End User Device

In a preferred embodiment, the present invention aims at a method and apparatus for the collection, conversion and delivery of electronic messages. The invention is not limited to the form or type of data transmission or storage system, and those skilled in the art will appreciate that data transmission forms (e.g., RF, wireless, dedicated communication channels, etc.) and storage systems (e.g., magnetic disks, optical, etc.) used for information storage. Media, etc.) may be modified within the scope of the present invention.

The present invention may be better understood with reference to FIG. 1, which illustrates the components of the overall notification server 1000 used in the notification service architecture in accordance with a preferred embodiment. As shown in FIG. 1, the notification server 1000 preferably includes a database 1010 containing administrative information. Management information may include, for example, service subscribers. Information kept in this database may include, but is not limited to, user identifiers, passwords, and encryption keys. Those skilled in the art will appreciate that this management database 1010 is preferably a logical database and may be recognized as one or more physical data stores. Those skilled in the art will also recognize that one or more physical data stores that implement the functionality of the logical management database 1010 may be implemented in any manner, including a formal database or a flat file. will be.

1 further illustrates a preferences database 1020 included in notification server 1000. This preference database 1020 preferably includes the preferences of the service subscriber or user. Those skilled in the art will appreciate that this database 1020 can be combined with the administrative functions described above (similar to how a UNIX password file preserves each user's preferred shell). The preference database 1020 may be modified by the user or by an application, for example, through the use of the graphical user interface 1025. The manner of modifying the preferences database 1025 can be changed and is not limited to graphical user interfaces. In addition, it should be understood that the present invention supports user preferences that can potentially change frequently. Although the preference database 1020 is shown as being included in the notification server 1000, the preference database 1020 of the present invention may be external to the notification server 1000.

1 also shows a gateway database 1030. Gateway database 1030 preferably includes information about the various gateways that can access the notification service used to deliver the electronic message. This information may include, but is not limited to, a service identifier (identifying this notification service for the gateway service), a password, and an encryption key. It is to be understood that this gateway database 1030 is preferably a logical database but may be implemented as one or more physical data stores. Those skilled in the art will also appreciate that one or more physical data stores that implement the functionality of the logical gateway database 1030 may be implemented in any manner including a regular database or flat file.

With continued reference to FIG. 1, a transcoding engine 1040 is shown that is preferably used to transcode electronic messages prior to transmission to a gateway. This transcoding removes images, modifies images, removes attachments, content summaries, removes confidential material, information about the message (e.g. sender's name, transmitted data, subject). Etc.), but may not be limited to.

1 further shows that the notification server is connected to two other services: directory service 1050 and recognition service 1060. Directory service 1050 preferably provides the notification service with information about the devices available to particular subscribers and the characteristics of those devices. Directory service 1050 may be provided by an LDAP database or other common directory service. In an IBM patent application entitled "Method and Apparatus for Providing an Awareness-Service Architecture" filed in the United States on January 7, 2000 and currently pending and no application number has been assigned (IBM Case No. YOR9-2000-0008). The recognition service 1060 as described provides information about the current accessibility of the device available to a particular subscriber.

1 also illustrates a number of connections to gateway services 1070, 1080, and 1090. By way of example, gateway 1070 is connected to a telephone network, gateway 1080 is connected to an electronic mail service network, and gateway 1090 is connected to another communication service. Each gateway service 1070, 1080, 1090 is preferably a gateway service as shown in more detail in FIG. 1 shows that each gateway is connected to one or more switches 1100, 1110, 1120, 1130. If these switches 1100, 1110, 1120, 1130 are employed, it is desirable to provide network connectivity for a particular device (these switches are referred to by reference numerals 31 and 41 in US Pat. No. 5,928,325). Can correspond to a switch element designated by. It is to be understood that the apparatus of the present invention may remove the switch and connect directly to the gateway.

1 illustrates end user devices 1140, 1150, 1160, 1170, 1180 that are preferably connected to dedicated switches 1100, 1110, 1120, 1130, respectively. The switches are unique for delivering information about the device they serve to the recognition service 1060 or gateway service similar to that disclosed in the pending patent recognition service architecture patent application (IBM case number YOR9-2000-0008) described above. Lies in position. Those skilled in the art will appreciate that additional gateways may be used with the present invention as new network types and / or topologies are developed. In addition, it should be understood that if multiple networks have the same or similar characteristics, they may be handled by a single or common gateway service.

The notification server 1000, along with other related functional subsystems (e.g., memory, control units, etc.) as will be understood by those skilled in the art, may be a central processing unit capable of executing an application program to control one or more characteristics of the notification server. Not shown). For example, the central processing unit controls access to any of the aforementioned database information, transforms (eg, transcodes) message data, and associates a server (eg, directory server 1050, recognition server 1060) with the notification server. ), Interface with the user, and send messages to the gateways 1070, 1080, 1090.

2 illustrates components including gateway services, such as 1070, 1080, and 1090, in accordance with an embodiment of the invention. As shown in FIG. 2, the gateway service 1070 preferably includes one or more outstanding messages delivery requests 2000. Using these queues 2000, the present invention can support devices that are disconnected from the notification network and subsequently reconnected. According to a preferred embodiment of the present invention, the message to be delivered only needs to wait in the queue 2000 until the time when the receiving device is reconnected.

Those skilled in the art will recognize the potential problem associated with disconnecting the device for long enough to fill the available queue size with a message waiting to be delivered. Conventional means can be adopted to solve these problems, and as will be understood by those skilled in the art, these means can, for example, use circular buffers, drop new messages, oldest messages It may include a drop of. Service providers can provide different levels of service for different queue sizes as well as for unlimited buffering of messages. The buffer size can be limited, for example, by specifying a maximum wait time per message. If the message is dropped because of a failure to successfully deliver the message to the desired receiving device, then the removed message notification is preferably returned to the notification service for the sender.

With continued reference to FIG. 2, a preferred embodiment of the present invention includes a transcoding engine 2010 that provides device-specific transcoding. Such transcoding may require detailed information regarding the characteristics of a particular device. In addition, the transcoding engine 2010 preferably supports changes between the same devices of different models. Unlike the transcoding engine 1040 included in the preferred embodiment of the notification server 1000 shown in FIG. 1, the transcoding engine 2010 included in the gateway service 1070 of FIG. 2 is a group of different models. It is desirable to include detailed knowledge about the type of device being served by a particular gateway, including the characteristics of each of the devices of the device (eg, Palm I, II, III, V, VIII devices of the PalmPilot ^™ family of connected organizations). This type of gateway is a device-specific proxy. An important advantage of this unique approach is the increased scalability possible when most transcoding is performed by the gateway rather than the notification server itself. In addition, the system of the present invention preferably supports the addition of new devices with minimal reconfiguration or impact on the notification server design, as detailed device information need not be added to the complex body of code contained in the notification server. .

3A and 3B illustrate a logical flow diagram of a process that occurs in accordance with a preferred embodiment of the present invention when the notification server 1000 (of FIG. 1) receives a message to be forwarded. Referring to FIG. 3A, when receiving a message 3000, the notification server first identifies the desired recipient of the message (step 3010) and then verifies that the desired recipient is a subscriber (ie, a user) of the service (step 3020). desirable. If the desired recipient is not a subscriber of this service, the notification service preferably determines (step 3110) whether to generate an error message. Otherwise, the process stops at this point (step 3100) and the message is preferably dropped. If the present invention determines to return an error message to the sender, an error message is generated and returned to the sender (step 3120) before the process is interrupted (step 3100).

If the desired recipient is a subscriber of the notification service, the service preferably retrieves (step 3030) the desired recipient's preferences, preferably stored in the user preferences database 1020 (of FIG. 1). In accordance with these preferences, the notification system of the present invention preferably determines (step 3040) whether to continue the process. Based on the desired recipient's preferences, if it is determined in step 3040 not to continue the process (e.g., indicating that the desired recipient does not want to receive a message from this sender), a response is generated (step 3130), It is desirable to stop the process (step 3100).

Referring now to FIG. 3B and assuming the process continues, the notification service uses directory server 1050 (of FIG. 1) to identify the device (s) associated with the desired recipient and the characteristics of these devices (step 3050). It is preferable. Devices that can utilize resources in their environment (e.g., portable devices near large screens, publicly addressable displays) may cause directory services 1050 to properly respond to dynamic changes in this configuration. It should be understood that the contents of the can be updated. The notification server then preferably determines 3060 accessibility of the desired recipient or user's device (s). For example, the notification service system of the present invention may use the recognition service 1060 (of FIG. 1). Alternatively, the system may identify gateways associated with each device and query each gateway about the availability of specific device (s) over the network. This inquiry is likely to be redirected back to the switch associated with this device, but the present invention also contemplates other means, as those skilled in the art will understand.

With continued reference to FIG. 3B, based on the availability of the desired recipient device (s), the recipient's preferences, the content of the message, and the capacity of each device, the notification server may select one or more devices to send the message to (step 3070). It is preferable. For each such device, the notification server converts the message (e.g., by transcoding) (step 3080) and then sends the message (step 8080) to the gateway associated with the selected device in its original form or translated version, if necessary. 3090). For example, a message may be converted by the notification service to remove components of the message that the gateway (or its associated device) cannot handle, or to provide confidentiality before delivering the message to an untrusted or unsecured gateway. You can filter the material (for example, remove confidential attachments or deliver only a brief overview of the message, such as subject line or sender name). As will be appreciated by those skilled in the art, messages can be delivered in encrypted form in accordance with conventional or proprietary encryption means of the present invention to provide an added level of security. After sending the message (step 3090), the process ends (step 3100).

The notification server may forward the request to each gate for the device the recipient carries. To prevent multiple deliveries, the notification server may additionally preserve a queue of outstanding notifications, requesting each gateway to notify when the successful delivery of the message is complete. The notification server may then dequeue now-redundant remaining delivery requests. In this way, the notification system of the present invention can reduce the inconvenience and cost of a user receiving duplicate copies of the same message while minimizing message delivery time. Of course, it is less expensive, but it is most important to get the advantage that the recipient does not have to sort duplicate copies of the same message at the expense of some cost.

It should be understood that the notification service 1000 (of FIG. 1) may query the gateway for delivery costs and then determine whether to forward the message based on the lowest cost. It should be understood that this determination may be based on other measures or characteristics such as, for example, estimated message delivery time. Such inquiries may result in subsequent inquiries from gateways 1070, 1080, 1090 to the switches associated with them. Further, the gateway itself 1070, 1080, 1090 may independently optimize message delivery by querying the switch associated with it in a manner similar to that described above in the detailed description. Inquiring forwarding characteristics to a network can be accomplished by multiple gateways capable of delivering messages to a specific user on a particular device, multiple switches connected to a single gateway, or multiple active devices that users can dispose of. This is especially useful. It should be understood that if metric information is available through other means, there is no need to consult the gateway and / or switch.

It is also desirable for the notification server to be able to initiate a query to determine the estimated arrival time of the message sent to the various devices. These queries may consist of gateways and / or switches, or may be made of recognition services. Using this information, the notification service can provide the message sender with additional information regarding the best direction for message delivery. In addition, the notification server can automatically use this information itself in making delivery decisions that meet predetermined conditions (eg delivery time, cost, etc.) while minimizing the use of expensive devices and / or networks.

If the message sender requests a return receipt (eg, similar to that provided by the US Postal System), the notification server preferably records this information and forwards this request to the gateway service. As will be appreciated by those skilled in the art, this information may be generated in a simple hash table or any number of other data structures.

4 is a logical flow diagram of a process that occurs when a notification service sends a message to a gateway according to a preferred embodiment of the present invention. This flowchart illustrates a process that preferably occurs at the gateway in response to message data transmission from the notification server (step 3090 of FIG. 3B). In a preferred embodiment of the present invention, the delivery of message data triggers the gateway system (step 4000) to process the data (step 4010) by queuing the message for future delivery (i.e., storing the message in a message queue). It is desirable to. The gateway system then preferably determines 4020 whether the message requires a return receipt. If the notification system determines that a return receipt was requested, the gateway records that the message requires a return receipt along with any additional information needed to enable the gateway to return the return receipt to the notification service at the appropriate time ( Step 4030). Upon completion of this step, the process is preferably interrupted (step 4040). As can be clearly seen from the flow chart of FIG. 4, the preferred embodiment includes very few processing steps at this point, but as will be appreciated by those skilled in the art, other more complex processing steps (eg, upon initial reception of a message) It may be considered. Those skilled in the art will also recognize that the gateway service may send a return receipt directly to reduce the processing burden imposed on the notification service.

5A and 5B are logical representations of processes that occur when a gateway processes messages in its delivery queue (these messages arrive at the delivery queue as a result of the processing described above in FIG. 4) in accordance with a preferred embodiment of the present invention. A flow chart is shown. Referring to FIG. 5A, for each message in process in the delivery queue, the process is preferably initiated (step 5000) by checking whether the message has already been successfully delivered (step 5005). If the message has been successfully delivered, the only processing required for this request is to deliver a return receipt confirmation (step 5070) (see FIG. 5B). If the notification service determines that the message has not yet been successfully delivered (step 5005), the system preferably determines (step 5010) whether the device to which the message is to be delivered is available in the network. This determination (step 5010) is made, for example, by using the recognition service 1060 (of FIG. 1) or by querying a network switch (eg, 1100, 1110, 1120, 1130). In addition, when the device state changes, the gateway requests a callback from the recognition service or the switch.

If the desired target device is not currently available, the system preferably determines (step 5110) whether it should attempt to deliver the message somehow or retry message delivery later. If the notification system determines that message delivery should be retried later, the system preferably stops processing this message (step 5100) and continues with the next message in the queue. If delivery must be retried, the process only needs to continue as the device is available.

Continuing with reference to FIG. 5A, if a device is determined to be currently available, or if a delivery is to be attempted even if the desired device is not known to be available, the message is converted to be received by the desired device, assuming that conversion is desired or desirable. It is preferable to continue the process by (step 5020). Such conversion may include requiring detailed knowledge of the desired device characteristics (eg, formatting of the device's screen, etc.). After conversion, the gateway preferably sends a message (step 5030) to the device either directly or via a switch (or similar means). The system then preferably determines 5040 whether the transmission was successful. If the transfer fails, the process is preferably interrupted (step 5100). Otherwise, the process continues.

Referring to FIG. 5B, if the transmission is successful, it is preferable to mark the message as delivered (step 5050). The system then preferably determines 5060 whether a return receipt has been requested. If a return receipt is requested, the notification server notifies 5050 that the message was successfully sent to the desired receiving device. If the target device includes a capacity for two-way communication (eg, two-way pager, PalmPilot® ^TM, etc.), the device displays a receipt confirmation. This second receipt (similar to a return receipt in US mail) is sent to the sender of the message, preferably having two levels of delivery confirmation. One is transmitted (step 5070) and the other is received. However, it is important to recognize that this confirmation only indicates that the user's device has received the message, not that the message has been received by the desired user of the receiving device.

After the delivery confirmation is sent (step 5070), the system preferably determines (step 5080) whether the delivery confirmation was successfully received by the notification server. If the return receipt notification to the notification server 1000 fails, processing of this message is preferably interrupted (step 5100) (subsequent processing of this message continues retrying the return receipt notification and does not reprocess the message). . If the return receipt notification to the notification server 1000 is successful, or if the return receipt was not originally requested (as determined in step 5060), the message is dequeued (step 5090), and processing of this message is subsequently performed. It is preferable to end (step 5100). It should be understood that the sender may request a response from the receiver. This response may be processed similarly to the confirmation receipts described and may indicate that the desired recipient has successfully received the message.

Those skilled in the art will appreciate that message delivery confirmation (step 5040) may occur at many different levels. Although direct response from the recipient is preferred, the present invention also contemplates other suitable alternatives, such as acknowledgment that the recipient has received the message. If the direct response from the user / receiver fails (for example, because the receiver uses a device that is not capable of bidirectional messaging or the recipient rejects the message), the sender will prefer as much information as possible. In a preferred embodiment of the present invention, the sender is informed that the message has been presented to the recipient by an application (such as displaying a message on a screen or playing an audio representation of the message on a speaker). Those skilled in the art will also recognize that such acknowledgment does not imply that the recipient has processed the message (ie, the recipient has read the displayed message or listened to the audio message).

The system of the present invention is a switch or similar, depending on the amount of information available to the system and the amount of reverse communication available, such as that a message has been successfully delivered (but not yet displayed) to the device. It is desirable to notify by way of successful transmission over the network (but no reception on the device is known), successful transmission to the switch, or successful transmission to the gateway.

A system for providing a scalable pervasive notification service in accordance with the present invention preferably includes a notification server operatively connected to one or more gateways. Each gateway is connected directly or indirectly to one or more receiving devices associated with a user of the notification service. The gateway includes a message queue for storing the forwarded message and / or a transcoder for converting the format type of the message received from the notification server into a different format type available to the user of the desired receiving device.

Although the exemplary embodiments of the present invention have been described with reference to the accompanying drawings, the present invention is not limited to these exact embodiments, and various modifications by those skilled in the art without departing from the spirit and scope of the present invention. It should be understood that they may be modified.

According to the present invention, it is possible to support a device associated with a desired message receiver and disconnected, to support multiple devices through a gateway or device proxy, to send a message to multiple devices at any point in the message transmission, In addition, the device may support transcoding of a message based on a device type or a user preference, may configure a dynamic device, and confirm message delivery to a desired device.

Claims (15)

delete delete delete In a notification service comprising a notification server operatively communicating with at least one gateway, sending a message to one or more receiving devices associated with at least one user of the notification service and operatively connected to the at least one gateway. A method, wherein the method is performed by the notification server; Upon receipt of a message from a sender, identifying an intended recipient of the message and determining whether the desired recipient is a user of the notification service; If the desired recipient is a user of the notification service, retrieving at least one of information about the desired recipient and information about the one or more devices associated with the desired recipient from a storage medium operatively connected to the notification server; Wow, Determining whether the message is to be delivered, based on the information retrieved from the storage medium; Identifying one or more devices and corresponding properties associated with the desired recipients; Determining the availability of the one or more devices associated with the desired recipient in receiving the message; Sending the message from the one or more devices associated with the desired recipient to one or more gateways associated with at least one available device. Message transmission method comprising a. The method of claim 4, wherein If the desired recipient is not a user of the notification service, returning an error indication to the sender of the message. The method of claim 4, wherein Determining whether the sender of the message requested a return receipt, the return receipt indicating that the message was delivered to the at least one available device; Transmitting information as to whether the return receipt was requested by the sender to the one or more gateways associated with the at least one available device. Message transmission method further comprising. The method of claim 4, wherein For each of the at least one available device, further comprising converting the message from a first format type to a second format type usable by the available device, wherein the converting step is performed prior to the transmitting step. How to send a message. The method of claim 4, wherein Based on the information retrieved from the storage medium, generating a response indicating that the message cannot be delivered to the desired recipient; Forwarding the response to the sender Message transmission method further comprising. A notification service comprising a notification server operatively communicating with at least one gateway comprising a message queue for storing one or more messages, wherein the notification service is associated with at least one user of the notification service and the at least one. A method for transmitting a message to one or more receiving devices operatively connected with a gateway of the method, the method being performed by the at least one gateway. Receiving a message from the notification server; Storing the message in the message queue; Retrieving a message to be delivered from the message queue; Determining whether the message retrieved from the message queue has already been delivered to the one or more receiving devices; If the message has not yet been delivered, transmitting the message retrieved from the message queue to the one or more receiving devices; Determining whether the transmission of the message was successful; If the sending step is successful, removing the message from the message queue Message transmission method comprising a. The method of claim 9, Determining whether the message received from the notification server requests a return receipt; If the notification server requests the return receipt, storing a return receipt request; When the return receipt is requested, sending a delivery confirmation to at least one of the notification servers and the sender of the message, wherein the delivery confirmation indicates that the message was successfully sent to the one or more receiving devices. step Message transmission method further comprising. The method of claim 9, Determining whether a device to which the message is to be delivered is available in receiving a message; If the desired device is not available, determining whether to continue message transmission Message transmission method further comprising. The method of claim 9, For each of the one or more receiving devices, converting the message received from the notification server from a first format type to a second format type usable by the receiving device, wherein the converting step is performed before the transmitting step; Message transmission method further comprising. At least one receiving device associated with at least one user of said notification service and operatively connected with said at least one gateway, in a notification service comprising a notification server operatively communicating with at least one gateway comprising a transcoder. Sending a message to the at least one gateway; Receiving a message from the notification server; For each of the one or more receiving devices, converting the message received from the notification server from a first format type to a second format type usable by the receiving device; Transmitting the message fetched from the message queue to the at least one receiving device if the message has not yet been delivered. Message transmission method comprising a. The method of claim 13, Determining whether the message received from the notification server requests a return receipt; If the notification server requests the return receipt, storing a return receipt request; If the return receipt is requested, sending a delivery confirmation to the notification server indicating that the message was successfully sent to the one or more receiving devices. Message transmission method further comprising. The method of claim 13, Determining whether the device to which the message is to be delivered is available in receiving a message; If the desired device is not available, determining whether to continue message transmission Message transmission method further comprising.