JP2001292175A - Method and device for providing scalable and popular- type information service - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an information system for supporting a cut-off device related with the objective receiver of a message. SOLUTION: The system is provided with an information service for transmitting messages to at least one objective receiver, related with the user or the subscriber of the information service. The information service includes an informing server to be connected operationally to at least one gateway. Each gateway is connected to at least one receiving-side device related with the user or subscriber of the information service directly or via an exchange. The gateway preferably includes a message queue for storing a distributed message and a transcoder for transforming the format type of the message received from the information server to a different format type suited to an objective receiving-side device.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates generally to communication systems and, more particularly, to a communication system, and more particularly, to an environment associated with a recipient of a message (hereinafter referred to as a target recipient) in an environment where the device is widespread. Related to the transmission of messages to one or more devices.

[0002]

BACKGROUND OF THE INVENTION The delivery of messages to specific devices is known in the industry today. For example, paging systems deliver messages to subscribers, and cellular services deliver telephone calls to customers. At least in part, due to the prevalence of these and similar devices, individual users often have multiple devices that can receive and even reply to messages. This leads to different problems: That is, if someone wants to send a message to an individual using a conventional message delivery system, the sender must know and maintain multiple addresses (eg, phone numbers, pager numbers, service providers, etc.). Also, the sender may not know which device the intended recipient has at a particular point in time, which generally results in a situation where redundant messages are sent to different devices. In addition, the sender may not know the capabilities of the intended recipient's device and may send the message to a device that cannot process the message effectively. Further, the sender may not know the device that the intended recipient would like to use to receive the message within a given time.

[0003] Conventional message systems attempt to solve some of the problems associated with message delivery today. See, for example, U.S. Patent No. 5,928, Shaughnessy et al.
No. 325 describes the problem of tracking devices associated with a particular user and discloses a solution. Basically, Shaughnessy et al. Provide a way to send a message to one or more user devices currently available to the intended recipient. The system tracks the devices associated with each subscriber and which of these devices are currently active. If someone has to send a message to the subscriber, they send the message to the system, which sends it directly to one or more devices of the subscriber.

[0004] Similarly, US Patent No. 54 to Theimer et al.
No. 93,692 discloses a system (dating back to the aforementioned systems) for delivering messages to a user or to a group of users in an environment that includes mobile and fixed devices. The system by Theimer et al. Delivers messages based on the status of the intended recipient. Messages can be given a level of privacy, a priority, and contextual attributes for their delivery. When the recipient's environment meets the required contextual situation, the system delivers the message to the intended recipient.

[0005] As an example of another conventional messaging system, MessageBlaster (SM) allows subscribers to maintain information about their contacts and send messages to one or more contacts. The system contacts each identified person using one or more methods specified by the sender, such as a telephone, fax, e-mail, pager or mail. MessageBlaster (S
M) Each subscriber to the system must maintain, in addition to the personal list of contacts, the device information of each device possessed by the contacts, and is therefore redundant, error-prone and uninterrupted. Becomes Further, this message delivery approach does not allow the recipient to have any control over how the message is delivered (except for the control provided by the service provider of the device selected by the sender). For more information on this service, see, for example, the MessageBlaster (SM) website (UR
L address, http://www.messageblaster.com (initial creation February 10, 2000) can be referred to.

While all of the above systems solve the problematic aspects described above, any of these systems, individually or in combination,
It does not solve every detail of the complex problem involved.
For example, none of the systems solve the problem of supporting a disconnected device, or the problem of eventually reconnecting a disconnected device to message service. In addition, any system is a two-way communication system (eg,
System, Palm VII system, SMS, etc.). Such communication systems provide an end user with the ability to respond to received messages. This feature provides the opportunity for the end user to respond to messages received via the messaging system, potentially affecting the way the messaging system handles future requests. Some conventional messaging systems allow users to specify limited preferences (preferences), but none of these systems support changing user preferences, or For dynamically changing their preferences,
Not working. In addition, some of these systems use information about the user's current state, user's device, or user's environment, but do not use information about the user's past habits in deciding to deliver a message. .

[0007]

Thus, in the field of electronic message delivery, there is a need to support devices that are disconnected from the system and later reconnect, need to use the features of a two-way communication system, and change user preferences. There is a need to consider historical activity and preferences when deciding on handling needs and complex message delivery.

[0008] It is an object of the present invention to provide a notification system that supports disconnected devices associated with the intended recipient of the message.

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 that can deliver a message to multiple devices at any time during message transmission.

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

[0012] Still another object of the present invention is to provide a notification system capable of dynamic device configuration.

Still another object of the present invention is to provide a notification system capable of confirming delivery of a message to a target device.

[0014]

SUMMARY OF THE INVENTION The present invention provides a method and apparatus for collecting, transforming, and delivering electronic messages to one or more devices associated with a target recipient, thereby providing a method for receiving a message. Is to reform the transmission of messages to the elderly. In a preferred embodiment, the present invention provides
1) support disconnected devices, 2) support multiple similar devices via gateways or device proxies, 3) support variable user preferences, 4) support dynamic device configurations, 5) Supports delivery confirmation returned to the sender, and 6) Supports transcoding within the gateway for improved scalability.

In accordance with one aspect of the present invention, there is provided a notification service for communicating a message to one or more intended recipient devices associated with a user or subscriber of the notification service. The notification service includes a notification server operatively connected to one or more gateways. Each gateway is connected, either directly or via a switch, to one or more recipient devices associated with the user or subscriber of the notification service. The gateway preferably includes a message queue that stores the messages to be delivered, and a transcoder that converts the format type of the message received from the notification server into a different format type suitable for the intended recipient device. By providing a message queue, the gateway supports message delivery to disconnected devices that are later reconnected to the notification service. In addition, by using a gateway that includes a transcoder, the message transformation is dynamically changed to fit the particular device corresponding to the gateway,
This provides a scalable notification service.

[0016]

DETAILED DESCRIPTION OF THE INVENTION In a preferred embodiment, the present invention provides a method and apparatus for collecting, transforming, and delivering electronic messages. The present invention is not limited by the form or type of data transmission or storage system, as will be appreciated by those skilled in the art, the form of data transmission (eg, RF, wireless, dedicated communication channels, etc.), and for storing information. The type of storage system used (eg, magnetic disk,
Optical media, etc.), all of which are within the scope of the present invention.

The present invention can be more completely understood with reference to FIG. FIG. 1 shows the components of an entire notification server 1000 used in a notification service architecture, according to a preferred embodiment. As shown in FIG. 1, notification server 1000 preferably includes a database including management information 1010. The management information includes, for example, a service subscriber. The information held in the database further includes a user identifier, a password, an encryption key, and the like. As will be appreciated by those skilled in the art, this management database 1010 is preferably a logical database, implemented as one or more physical data stores. One skilled in the art will also appreciate that one or more physical data stores that implement the functions of the logical management database
It will be appreciated that it can be implemented in a variety of ways, including files.

FIG. 1 further shows a preference database 1020 included in the notification server 1000. This preference database 1020 preferably holds the preferences of the subscriber or user of the service. As will be appreciated by those skilled in the art, this database 1020 may be combined with the management functions described above (similar to a UNIX password file holding a selected shell for each user). The preference database 1020 may be modified by a user or by an application program, for example, through the use of a graphical user interface (GUI) 1025. Preference database 1
There are various methods for changing 020, and the method is not limited to the graphical user interface. Further, the present invention is appreciated for supporting potentially frequently changing user preferences. The preference database 1020 stores the notification server 100
Although shown to be contained within 0, the present invention similarly considers the case where the preference database 1020 is external to the notification server 1000.

FIG. 1 also shows a gateway database 1030. Gateway database 1030
Preferably maintains information about the various gateways accessible by the notification service for delivering electronic messages. This information includes, for example, a service identifier (identifying this notification service as a gateway service), a password, and an encryption key. This gateway database 1030 is preferably a logical database and may be implemented as one or more physical data stores. Also, one of ordinary skill in the art will appreciate that one or more physical data stores that implement the functions of the logical gateway database 1030 may be implemented in a variety of ways, including formal databases and flat files.

Still referring to FIG. 1, a transcoder 1040 is shown, which is preferably used to convert or transcode an electronic message before transmitting the message to a gateway. This transcoding includes removing images, modifying images, removing attachments, summarizing content, removing confidential material, summarizing information about the message (eg, sender name, date sent, subject, etc.).

FIG. 1 further shows that the notification server is connected to two other services: a directory service 1050 and an awareness service 1060. Directory service 1050 preferably provides the notification service with information regarding 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. Awareness service 1060 is 2000
No. 09 / 479,821, filed Jan. 7, 1998, which provides information regarding the current accessibility of devices that can be used by a particular subscriber.

FIG. 1 further illustrates a gateway service 10.
A number of connections to 70, 1080 and 1090 are shown. 1
By way of example, gateway 1070 is shown connected to a telephone network, gateway 1080 is connected to an email service network, and gateway 109
0 is connected to another communication service. Each of the gateway services 1070, 1080 and 1090 is preferably a gateway service as detailed in FIG. FIG. 1 also shows that each gateway is connected to one or more switches 1100, 1110, 1120 and 1130. These exchanges 1100, 111
0, 1120 and 1130 provide network connections to specific devices (these switches are described in US Pat.
No. 988325, corresponding to the switch elements indicated by reference numerals 31 and 41). The present invention also considers the case where the switch is removed and the device is directly connected to the gateway.

FIG. 1 shows end user devices 1140, 11
50, 1160, 1170 and 1180, each of which is preferably a suitable switch 1100, 111
0, 1120 or 1130. Switches are located in unique locations and report information about the devices they service to other parties, such as an awareness service 1060 or a gateway service.
As those skilled in the art will appreciate, new gateways may be added and used with the present invention as new network types or topologies are developed. Further, if multiple networks have the same or similar characteristics, they may be handled by a single or common gateway service.

The notification server 1000 preferably includes a central processing unit (not shown), as will be apparent to those skilled in the art, along with other associated functional subsystems (eg, memory, control units, etc.). An application program can be executed to control one or more aspects of the notification server. For example, the central processing unit may control access to any of the aforementioned database information, or convert message data (eg, transcoding), or services associated with the notification server (eg, directory service 1050). , Awareness Service 1060, etc.)
Also used to interface with a user or to send messages to gateways 1070, 1080, 1090.

FIG. 2 illustrates the architectural components that make up the gateway service, according to one embodiment of the present invention. As shown in FIG. 2, the gateway service 1
070 (other gateway services 1080, 109)
0 as well) preferably includes one or more queues 2000 of outstanding message delivery requests. These queues 2
With 000, the present invention can support devices that are disconnected from the notification network and later reconnected. In the preferred embodiment of the invention, the message to be delivered simply waits in queue 2000 until the receiving device reconnects.

One skilled in the art will be aware of the potential problem of disconnecting a device for a sufficiently long time to fill the available queue size with messages awaiting delivery. Conventional means have been used to remedy these problems, including, for example, the use of circular buffers, removal of new messages, or removal of oldest messages. Service providers may offer different levels of service for different queue sizes and for unlimited buffering of messages. The buffer size may also be limited, for example, by defining a maximum wait time per message. If the message is removed because the message cannot be successfully delivered to the intended recipient device, a message erasure notification is preferably returned to the notification server and forwarded to the sender.

With continued reference to FIG. 2, a preferred embodiment of the present invention includes a transcoder 2010 that provides device-specific transcoding. Such transcoding may require detailed information regarding the characteristics of a particular device. Transcoder 2010 also preferably includes:
Supports differences between different models of the same device. FIG.
The transcoder 201 included in the gateway service 1070 of FIG. 2 differs from the transcoder 1040 included in the preferred embodiment of the notification server 1000 shown in FIG.
0 preferably possesses detailed knowledge about the device types served by a particular gateway, including, for example, the characteristics of each different model of the device family (eg, PalmPilot of the connection organizer).
(Trademark) family of Palm I, II, III, V, VII devices).
This type of gateway is a device-specific proxy. An important advantage of this unique approach lies in the increased scalability, which is possible if the majority of the transcoding is performed by the gateway and not by the notification server itself. Further, the system of the present invention preferably supports the addition of new devices with minimal reconfiguration or impact of the notification server design.
This is because detailed device information does not need to be added to the complex code body included in the notification server.

FIGS. 3 and 4 are logical flow diagrams of the processing that occurs when the notification server 1000 of FIG. 1 receives a message to be delivered, in accordance with a preferred embodiment of the present invention. Referring to FIG. 3, upon receiving a message (step 3000), the notification server first identifies the intended recipient of the message (step 3010) and confirms that the intended recipient is a subscriber (ie, a user) of the service. (Step 3020). If the intended recipient is not a subscriber of this service, the notification service preferably determines whether an error message should be generated (step 3110). If not, processing stops at this point (step 3100) and the message is preferably removed. If an error message is to be returned to the sender, an error message is generated and subsequently returned to the sender (step 3120), with the process terminating (step 3100).

If the intended recipient is a subscriber to the notification service, the service preferably examines the intended recipient's preferences (step 3030). This is preferably stored in the aforementioned user preference database 1020 (see FIG. 1).
According to these preferences, the notification system of the present invention:
Preferably, it is determined whether or not to continue the processing (step 3040). If it is determined based on the target recipient's preferences that processing should not continue (e.g., if the target recipient does not want to receive a message from this sender), a response is preferably generated (step 3130),
The processing subsequently stops (step 3100).

Referring to FIG. 4, if the processing is to be continued, the notification server then proceeds to directory service 1050
(See FIG. 1) to identify the devices associated with the intended recipients and the characteristics of those devices (step 30).
50). Devices that can utilize resources in the environment (eg, handheld devices near large screens, publicly addressable display devices) are directory services 105
The contents of 0 may be updated, so that the notification service can react appropriately to these dynamic changes in the configuration. The notification service then determines the accessibility of the intended recipient or user's device (step 306).
0). For example, the notification service system of the present invention uses an awareness service 1060 (see FIG. 1). Alternatively, the system identifies the gateways associated with each device and queries each gateway regarding the availability of the particular device in the network. Such a query may be forwarded to the switch associated with the device. However, the present invention can use other means recognized by those skilled in the art.

Still referring to FIG. 4, based on the availability of the target recipient's device, the recipient's preferences, the content of the message, and the capabilities of each device, the notification server then proceeds to one or more devices that send the message. (Step 30)
70). For each such device, the notification server converts the message as needed (eg, by transcoding) (step 3080), and then converts the message in its original form or in a converted version to its selected device. Send to the associated gateway (step 3090). For example, a message may be transformed by a notification service so that the gateway (or its associated device) removes elements of the message that it cannot process or sends confidential material before sending the message to an uncertain or unprotected gateway. Removed (eg, removes confidential attachments or sends only a summary of information about the message, such as subject line or sender name).
As will be appreciated by those skilled in the art, the message may be sent in an encrypted form to provide an additional level of security. After sending the message (step 309)
0), the process is completed (step 3100).

The notification server submits a distribution request to each gateway of the device owned by the receiver. To avoid multiple delivery, the notification server may further maintain a queue of outstanding notifications, and may request each gateway to notify it when message delivery is successfully completed. it can. At this time, the notification server
Dequeue remaining delivery requests that are currently redundant. Thus, the notification system of the present invention minimizes message delivery time while reducing the hassle and sacrifice of users receiving multiple copies of the same message. of course,
Queuing messages can incur some cost,
An advantage derived from the necessity of sorting out multiple copies of the same message by the recipient would certainly outweigh some cost inconveniences.

The notification server 1000 (see FIG. 1) inquires of the gateway about the delivery cost and, based on the minimum cost,
A decision can be made whether to deliver the message.
This decision is based on, for example, the estimated time of message delivery.
It may be based on other criteria or attributes. This inquiry is sent to the gateway 1070, 1080 or 1090
Can cause subsequent queries to their associated exchanges. Further, the gateways themselves 1070, 1080 or 1090 independently optimize message delivery by interrogating their associated exchanges in a manner similar to that described above. Querying the network for delivery attributes is useful if there are multiple gateways that can deliver the message to a particular device of a particular user, or if there are multiple exchanges connected to a single gateway.
Or it is especially useful if the user has multiple active devices at his disposal. Conversely, interrogation of the gateway or switch is unnecessary if reference information is available through other means.

The notification server also preferably initiates a query to determine the expected time of arrival of messages sent to various devices. These inquiries are made to gateways or exchanges, or to awareness services. With this information, the notification service can provide additional information, ie, information on how to best transfer the message, to the sender of the message. In addition, the notification server can automatically use such information itself to make distribution decisions that meet predetermined requirements (eg, delivery time, cost, etc.) while minimizing the use of expensive equipment or networks. it can.

If the sender of the message requests an acknowledgment (eg, similar to that provided by the US mail system), the notification server preferably records this information,
Pass this request to the gateway service. As will be appreciated by those skilled in the art, this information is generated by a simple hash table or any other data structure.

FIG. 5 is a logical flow diagram of the processing that occurs when a notification service sends a message to a gateway, in accordance with a preferred embodiment of the present invention. This figure illustrates the processing that preferably takes place in the gateway in response to the transmission of message data from the notification server (step 3090 in FIG. 4). In the preferred embodiment of the present invention, the transmission of the message data triggers the gateway system to begin processing the data (step 400).
0), the gateway system queues the message for future delivery (ie, stores the message in a message queue) (step 4010).
Next, the gateway system preferably determines whether the message requires acknowledgment (step 40).
20). If the notification system of the present invention determines that acknowledgment is required, the gateway records that the message requires acknowledgment (step 4030). that time,
Additional information required for the gateway to return an acknowledgment to the notification service at the appropriate time is also recorded. Upon completion of this step, the process preferably stops (step 4040). As is evident from FIG. 5, the preferred embodiment includes little processing at this point, but also takes into account other more complex processing known to those skilled in the art (e.g., delivery is the first reception of a message). Sometimes tried). One skilled in the art will appreciate that the gateway service can send the acknowledgment directly, thereby reducing the processing load imposed on the notification service.

FIGS. 6 and 7 illustrate when a gateway processes messages in its delivery queue (ie, messages that arrive in the delivery queue as a result of the processing described in FIG. 5) in accordance with a preferred embodiment of the present invention. FIG. 7 is a logic flow diagram of processing that occurs in FIG. Referring to FIG. 6, processing begins at step 5000 for each pending message in the delivery queue, and at step 5005 it is determined whether the message has already been successfully delivered. If affirmative, the only processing required for this request is basically to send an acknowledgment (see FIG. 7). If the notification service determines that the message has not yet been successfully delivered (step 5005), the system preferably determines whether the target device to which the message was delivered is available in the network (step 5010). . This determination can be made using, for example, the awareness service 1060 (see FIG. 1) or a switch of the network (eg, 1100, 111).
0, 1120 or 1130). The gateway may also request a callback from the awareness service or switch if the state of the device changes.

If the target target device is not currently available, the notification system preferably determines whether message delivery should be attempted at all times or if message delivery should be retried later (step 5110).
When the notification system determines that message delivery should be retried later, the system preferably stops processing this message and continues processing the next message in the queue (step 5100). If delivery is to be attempted, processing simply continues as if the device were available.

With continued reference to FIG. 6, if the device is currently available, or if the delivery attempt continues even though the target device is not known to be available, the process will preferably target the message. Conversion is performed in preparation for reception by the device (step 5020). This is done on the assumption that such a conversion is required or desired. Such conversion requires detailed knowledge of the characteristics of the target device (for example, a format setting corresponding to the screen of the device). Once converted, the gateway sends the message directly to the device or via a switch (or similar means) (step 5030). The system then determines whether the transmission was successful (step 5040). If the transmission fails, the process preferably stops (step 510).
0). Otherwise, processing continues.

Referring to FIG. 7, if the transmission is successful, the message is preferably marked as delivered (step 5050). The system then determines whether an acknowledgment is required (step 5060). If an acknowledgment is requested, the notification server is informed that the message was successfully transmitted to the intended recipient device. If the target device includes a two-way communication function (eg, a two-way pager, PalmPilot VII, etc.), confirmation of receipt may be indicated by the device. This second receipt (similar to a U.S. mail acknowledgment) is preferably sent to the sender of the message to provide a two-level delivery confirmation. That is,
One indicates that the message was sent (step 5
070), the other indicates that it was 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 was received by the intended user of the receiving device.

After the delivery confirmation is transmitted (step 507)
0), the system preferably determines whether the delivery acknowledgment has been successfully received by the notification server (step 5080). If the notification to the notification server 1000 fails, processing of this message is preferably performed at step 510.
Stop at 0 (future processing of this message may be a retry of the notification, without having to reprocess the message itself). If the notification to the notification server 1000 is successful or if no notification was originally requested (step 506)
0), the message is preferably dequeued (step 5)
090), and the processing of this message is completed (step 5100). The sender may optionally request a response from the recipient. This response may be processed as in the case of receipt of the acknowledgment described above, indicating that the intended recipient has successfully received the message.

Those skilled in the art will appreciate that confirmation of message delivery (step 5040) can occur at many different levels. Although a direct response from the receiver is preferred, the invention contemplates other suitable alternatives, such as an acknowledgment that the receiver has received the message. If the direct response from the user / receiver fails (for example, if the receiver is using a device that cannot transfer two-way messages or if the receiver is avoiding the message), the sender sends as much information as possible. May be. In a preferred embodiment of the present invention, the sender is notified by the application that the message has been provided to the recipient (eg, displays the message on a screen or outputs a spoken representation of the message through a speaker). One skilled in the art will further understand that such confirmation does not mean that the recipient has processed the message (ie, the recipient has read the displayed message or heard the voice message).

The system of the present invention also preferably depends on how much information is available to the system or how much backward communication is possible, for example, the message was successfully delivered to the device. That the message was successfully transmitted by the switch or the like over the network (but not received by the device), that the message was successfully transferred to the switch, or that the message was The sender can be notified of the successful transfer to the gateway.

In accordance with the present invention, a system for providing a scalable and pervasive notification service 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 the user of the notification service. The gateway includes a message queue that stores the messages to be delivered, and a transcoder that converts the format type of the message received from the notification server into a different format type suitable for the intended recipient device.

[Brief description of the drawings]

FIG. 1 is a component diagram illustrating a notification server formed in accordance with one embodiment of the present invention.

FIG. 2 is a component diagram illustrating a gateway formed in accordance with one embodiment of the present invention.

FIG. 3 is a logical flow diagram illustrating a preferred process for delivering a message by the notification server of FIG. 1 in accordance with the present invention.

FIG. 4 is a logical flow diagram illustrating a preferred process for delivering a message by the notification server of FIG. 1 in accordance with the present invention.

FIG. 5 is a logic flow diagram of a preferred process for a gateway as shown in FIG. 2 to accept an incoming message for one of its devices, in accordance with the present invention.

FIG. 6 is a logical flow diagram illustrating a preferred process by which a gateway services messages in its delivery queue in accordance with the present invention.

FIG. 7 is a logical flow diagram illustrating a preferred process by which a gateway services messages in its delivery queue in accordance with the present invention.

[Explanation of symbols]

1000 Notification server 1010 Management information database 1020 User selection database 1025 Graphical user interface 1030 Gateway database 1040 Transcoder 1050 Directory service 1060 Awareness service 1070, 1080, 1090 Gateway service 1100, 1110, 1120, 1130 Switch 1140, 1150, 1160, 1170, 1180
End User Equipment 2000 Queue 2010 Transcoder

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Maria Rene Ebling, Inventor, United States 10594, Thornwood, NY, Sherman Avenue 843 (72) Inventor Gerney Douglas Holloway-Hunt United States, 10598, Yorktown Heights, NY Wellington Coat 31 (72) Inventor Peter Kenneth Markin United States 10502; Aarsley, NY, Bramble Brook Road 64 (72) Inventor Vivec Chabra United States 10520, Crotton-on-Hudson, NY, Suite 2 N, Baltic Place 22

Claims (15)

[Claims] Claims: 1. A notification service associated with a user
A notification system for transmitting a message to one or more receiving devices, comprising: a notification server including one or more databases for a notification service; and at least one gateway connected to the notification server; One gateway is connected to the at least one gateway;
A message queue for storing messages to be delivered to one or more receiving devices; and a message queue for receiving messages from the notification server from a first format type used by the one or more receiving devices. A notification system including at least one transcoder for converting to a second format type. 2. The notification system according to claim 1, further comprising a user interface connected to said notification server for enabling said information stored in said one or more databases to be changed. 3. The notification service according to claim 1, wherein said notification server includes a transcoder for converting a message to be delivered from a first format type to a second format type. 4. A method for delivering a message to one or more receiving devices associated with a user of the notification service in a notification service including a notification server in communication with at least one gateway, the message from a sender. Receiving the message, identifying a recipient who is the destination of the message, and determining whether the recipient is a user of the notification service; and, if the recipient is a user of the notification service, Retrieving, from a storage medium connected to a server, at least one of information relating to the recipient and information relating to the one or more devices associated with the recipient; Determining whether or not the message should be delivered; and associating the message with the recipient. Identifying one or more devices to be activated and characteristics of the devices; determining availability for receiving the message with respect to the one or more devices associated with the recipient; The one associated with the recipient
Transmitting from one or more devices to one or more gateways associated with the at least one available device. 5. The method of claim 4, further comprising the step of returning an error indication to the sender of the message if the recipient is not a user of the notification service. 6. A method for determining whether a sender of the message has requested an acknowledgment indicating that the message has been delivered to the at least one available device; Transmitting information to the one or more gateways associated with the at least one available device as to whether or not requested by an individual. 7. Prior to said transmitting step, for each of said at least one available device, said message is converted from a first format type to a second format type suitable for said available device. 5. The method of claim 4, comprising the step of: 8. Generating a response indicating that the message is undeliverable to the intended recipient based on the information retrieved from the storage medium; and transmitting the response to the sender. 5. The method of claim 4, comprising: 9. A notification service including a notification server in communication with at least one gateway, said at least one gateway including a message queue storing one or more messages, and associating a message with a user of said notification service. Receiving a message from the notification server; storing the message in the message queue; and delivering a message to be delivered from the message queue. Retrieving; 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 been delivered, the message・ The message searched from the queue Sending the message to the one or more receiving devices; determining whether the transmission of the message was successful; and, if the transmission step was successful, placing the message in the message queue. Removing from the
Method. 10. A step of determining whether or not the message received from the notification server requires a acknowledgment, and storing the acknowledgment notification request if the notification server requests the acknowledgment. Sending a delivery acknowledgment to the at least one of the notification server and the message sender indicating that the message was successfully sent to the one or more receiving devices, if the acknowledgment is required. 10. The method of claim 9, comprising:
The described method. 11. A method for determining whether a destination device to which the message is to be delivered is available for receiving a message, and determining whether to continue message delivery if the destination device is not available. Determining.
The described method. 12. The method according to claim 12, wherein the at least one gateway includes a transcoder, the method comprising: prior to the transmitting step, receiving the message from the notification server for each of the one or more receiving devices. 10. The method of claim 9, including converting from the first format type to a second format type suitable for the receiving device. 13. A notification service including a notification server in communication with at least one gateway, wherein said at least one gateway includes a message queue and a transcoder, and one or more receptions associated with a user of said notification service. A method of receiving a message from the notification server and storing the message in the message queue; and transmitting the message from the notification server to each of the one or more receiving devices. Converting the received first format type to a second format type suitable for the receiving device; and if the message has not been delivered, the message retrieved from the message queue To the one or more receiving devices And a step, way. 14. A step of determining whether or not the message received from the notification server requires a acknowledgment, and storing the acknowledgment request if the notification server requests the acknowledgment. Sending a delivery confirmation to the notification server indicating that the message has been successfully sent to the one or more receiving devices, if the acknowledgment is required. the method of. 15. A method for determining whether a destination device to which the message is to be delivered is available for receiving a message, and determining whether to continue message delivery if the destination device is not available. Determining.
3. The method according to 3.