GB2366032A

GB2366032A - Method and apparatus for providing a scalable pervasive notification service

Info

Publication number: GB2366032A
Application number: GB0102968A
Authority: GB
Inventors: Maria Rene Ebling; Guerney Douglass Holloway-Hunt; Peter Kenneth Malkin; Vivek Chhabra
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-02-24
Filing date: 2001-02-07
Publication date: 2002-02-27
Also published as: KR100386642B1; KR20010085334A; JP2001292175A; GB0102968D0

Abstract

A notification service is provided for communicating messages to one or more intended recipient devices associated with users or subscribers of the notification service. The notification service comprises a notification server operatively connected to one or more gateways. Each gateway, in turn, is connected, either directly or via a switch, to one or more recipient devices associated with a user(s) or subscriber(s) of the notification service. The gateway includes a message queue, for storing messages to be delivered, and/or a transcoder for transforming the format type of a message, received from the notification server, to a different format type adapted for use by the intended recipient devices.

Description

2366032 METHOD AND APPARATUS FOR PROVIDING A SCALABLE PERVASIV19

NOTIFICATION SERVICE The method and apparatus of the present invention relate generally to 5 communication systems, and more particularly relates to the communication of messages to one or more devices associated with an intended recipient in an environment in which the devices are pervasive.

Delivering messages to specific devices is well known in the industry 10 today. For example, paging systems deliver messages to their subscribers and cellular services deliver telephone calls to their customers. Due, at least in part, to the proliferation of these and similar devices, individual users frequently have multiple devices that can receive messages, or even send messages in return. This leads to a different 15 problem: when someone wants to send a message to an individual using conventional message delivery systems, the sender must know and maintain multiple addresses (e.g., telephone numbers, pager numbers, service providers, etc.). Also, the sender may not know which device the intended recipient is carrying at any particular point in time, a situation that 20 generally results in redundant messages being sent to different devices.

In addition, the sender may not know the capabilities of the intended recipient's device(s) and may send a message to a device which is incapable of effectively processing it. Furthermore, the sender may not know on which device the intended recipient prefers to receive messages during any 25 given time.

Prior art messaging systems have attempted to address some of the issues involving present delivery of messages. For example, in U.S. Patent Number 5,928,325, Shaughnessy et al. discuss the problem of keeping track 30 of devices associated with a particular user and disclose a solution. In essence, Shaughnessy et al. provide a method for sending messages to one or more user devices presently available to an intended recipient. This system keeps track of the devices associated with each subscriber as well as which of those devices are currently active. When someone must get a 35 message to a subscriber, they send the message to this system and the system sends it directly to one or more of the subscriber's devices.

Similarly, in U.S. Patent Number 5,493,692, Theimer et al. disclose a system (that predates the previously described system) for delivering 40 messages to a user or a group of users in an environment containing mobile and fixed devices. The Theimer et al. system delivers a message based upon the context of the intended recipient. The message may be given a level of privacy and a priority as well as contextual attributes for its delivery.

The system delivers the message to the intended recipient when the recipient's environment matches the required contextual situation.

As an example of another prior art messaging system, MessageBlasterSM

5 offers a service that allows subscribers to maintain information about their contacts and send one or more of those contacts a message. This system will contact each of the identified people using one or more methods specified by the sender, including telephone, fax, e-mail, pagers, or mail.

Each subscriber to the MessageBlastersm system must maintain a personal list 10 of contacts as well as device information for each device carried by those contacts -- a tedious, error-prone and continuous process. Further, this approach to message delivery does not allow the recipient any control (other than those controls provided by the service provider of the device chosen by the sender) over how messages are delivered. A more detailed 15 description of this service may be found, for example, by accessing the

MessageBlasterlm web site at URL address http://www.messageblaster.com (originally described on February 10, 2000).

Although all of the systems described above address some aspect of 20 the problems previously described, none of these systems, when considered either individually or in combination, addresses all the subtleties of the complex issues involved. For example, neither system addresses the problem of supporting disconnected devices, or the problem of having a disconnected device eventually reconnect to the messaging service. Furthermore, neither 25 system exploits the functionality offered by two-way communication systems (e.g., two-way paging systems, the Palm VII system, SMS, etc.). Such communication systems offer the ability for end users to respond to messages received. This functionality provides an opportunity for the end-user to respond to messages received via a messaging system and to 30 potentially influence the ways in which that messaging system handles future requests. Although some prior art messaging systems allow users to specify limited user preferences, neither of these systems address how to support highly variable user preferences, or to allow users to modify their preferences dynamically. In addition, although some of these systems may 35 exploit information about the current state of the users, their devices and/or their environment, they do not maintain and/or exploit information about the users' past habits in making message delivery decisions.

There remains a need, therefore, in the field of electronic message

40 delivery, to support devices that disconnect and later reconnect to the system, to exploit the features of two-way communication systems, to handle highly variable user preferences, and to consider historical activities and preferences in making complex message delivery decisions.

According to one aspect of the present invention, there is provided a notification service for communicating messages to one or more intended recipient devices associated with at least one user of said notification service, said notification service comprising: a notification server, the 5 notification server including one or more databases for storing at least one of administrative information, user preferences, gateway information, directory service information and awareness information; and at least one gateway operatively connected to the notification server, the at least one gateway including at least one of: a message queue for storing messages to 10 be delivered to said one or more recipient devices operatively connected to the at least one gateway; and a transcoder for transforming a message, received from said notification server, from a first format type to a second format type for use by said one or more intended recipient devices operatively connected to the gateway.

According to a second aspect of the present invention, there is provided, in a notification service comprising a notification server operatively communicating with at least one gateway, a method for communicating a message to one or more recipient devices associated with at 20 least one user of said notification service, said one or more devices being operatively connected to said at least one gateway, said method, performed by said notification server, comprising the steps of: identifying, upon receiving a message from a sender, an intended recipient of said message and determining whether said intended recipient is a user of the 25 notification service; retrieving, if said intended recipient is a user of said notification service, from a storage medium operatively coupled to the notification server, at least one of: information relating to said intended recipient; and information relating to said one or more devices associated with said intended recipient; determining, on the basis of said information 30 retrieved from said storage medium, whether said message is to be delivered; identifying one or more devices, and characteristics corresponding thereto, associated with said intended recipient; determining the availability of said one or more devices, associated with said intended recipient, for receiving said message; and transmitting said message to one 35 or more gateways associated with at least one available device from said one or more devices associated with said intended recipient.

According to a third aspect of the present invention, there is provided, in a notification service comprising a notification server 40 operatively communicating with at least one gateway, said at least one gateway including a message queue for storing one or more messages, a method for communicating a message to one or more recipient devices associated with at least one user of said notification service, said one or more devices being operatively connected to said at least one gateway, said method, performed by said at least one gateway, comprising the steps of:

receiving a message from said notification server; storing said message in said message queue; retrieving a message to be delivered from said message queue; determining whether said message retrieved from said message queue 5 has already been delivered to said one or more recipient devices; transmitting said message retrieved from said message queue to said one or more recipient devices if said message has not already been delivered; determining whether said transmitting of said message was successful; and removing said message from said message queue if said transmitting step was 10 successful.

According to a fourth aspect of the present invention, there is provided, in a notification service comprising a notification server operatively communicating with at least one gateway, said at least one is gateway including a transcoder, a method for communicating a message to one or more recipient devices associated with at least one user of said notification service, said one or more devices being operatively connected to said at least one gateway, said method, performed by said at least one gateway, comprising the steps of: receiving a message from said 20 notification server; transforming, for each device of said one or more recipient devices, said message from a first format type received from said notification server to a second format type adapted for use by said recipient device; and transmitting said message retrieved from said message queue to said one or more recipient devices if said message has not already 25 been delivered.

The present invention revolutionises the communication of messages to an intended recipient(s) of the messages by providing a method and apparatus for the collection, transformation and delivery of electronic 30 messages to one or more devices associated with the intended recipient. In a preferred embodiment, the present invention is capable of: supporting disconnected devices; supporting multiple similar devices via a gateway or device proxy; supporting highly variable user preferences; supporting dynamic device configuration; supporting delivery confirmation to be 35 returned to the sender; and supporting transcoding in the gateway to increase scalability.

In accordance with one embodiment, a notification service is provided for communicating messages to one or more intended recipient devices 40 associated with users or subscribers of the notification service. The notification service comprises a notification server operatively connected to one or more gateways. Each gateway, in turn, is connected, either directly or via a switch, to one or more recipient devices associated with a user(s) or subscriber(s) of the notification service. The gateway preferably includes a message queue, for storing messages to be delivered, and/or a transcoder for transforming the format type of a message, received from the notification server, to a different format type adapted for use by the intended recipient device (s). By providing a message queue, the 5 gateway supports message delivery to disconnected devices that later reconnect to the notification service. Moreover, by employing a gateway which includes a transcoder, message transformation can be dynamically altered to conform to the specific devices corresponding to the gateway, thus providing a notification service that is scalable.

Features and advantages of the present invention will become apparent from the following, by way of example, detailed description of the preferred embodiments thereof, which is to be read in conjunction with the accompanying drawings, wherein like elements are designated by identical 15 reference numerals throughout the several views, in which:

Figure 1 is a component diagram depicting a notification server, formed in accordance with one embodiment of the present invention; 20 Figure 2 is a component diagram depicting a gateway, formed in accordance with one embodiment of the present invention; Figures 3A and 3B are a logical flow diagram illustrating a preferred process by which the notification server of Figure 1 delivers a message, in 25 accordance with the present invention; Figure 4 is a logical flow diagram illustrating a preferred process by which a gateway, such as that shown in Figure 2, accepts an incoming message for one of its devices, in accordance with the present invention; and 30 Figures 5A and 5B are a logical flow diagram illustrating a preferred process by which a gateway services the messages in its delivery queue, in accordance with the present invention.

In a preferred embodiment, the present invention is directed to a 35 method and apparatus for the collection, transformation, and delivery of electronic messages. It is to be appreciated that the present invention is not limited by the form or type of data transmission or storage system described with relation to the specific embodiments and that those skilled in the art will understand that the form of the data transmissions (e.g., 40 RF, wireless, dedicated communications channel, etc.), as well as the form of the storage systems used for storing information (e.g., magnetic disk, optical media, etc.), may vary.

The present invention may be more fully understood with reference to Figure 1, which illustrates the components of an overall notification server 1000 used in a notification service architecture, in accordance with a preferred embodiment. As shown in Figure 1, the notification server 1000 s preferably includes a database containing administrative information 1010.

This administrative information may include, for example, service subscribers. The information maintained in this database might also include, but is not limited to, user identifiers, passwords and encryption keys. Those skilled in the art will recognise that this administrative 10 database 1010 is preferably a logical database and could be realised as one or more physical data stores. Those skilled in the art will also recognise that the one or more physical data stores that implement the functionality of the logical administrative database 1010 may be implemented in any number of ways, including a formal database or a flat file.

Figure 1 further depicts a preferences databases 1020 included in the notification server 1000. This preferences database 1020 preferably maintains the preferences of the service's subscribers or users. Those skilled in the art will appreciate that this database 1020 may be combined 20 with the administrative functionality described previously (similar to how a UNIX password file maintains each user's preferred shell). The preferences database 1020 may be modified by the user or by an application program through the use of, for example, a graphical user interface 1025.

The method of modifying the preferences database 1020 may vary and is not 25 limited to graphical user interfaces. Furthermore, it is to be appreciated that the present invention supports user preferences that could potentially change frequently. Although the preferences database 1020 is depicted as being included within the notification server 1000, the present invention similarly contemplates that the preferences database 1020 may be external 30 to the notification server 1000.

Figure 1 also depicts a gateway database 1030. The gateway database 1030 preferably maintains information about the various gateways accessible to the notification service for use in delivering electronic messages.

35 This information might include, but is not limited to, service identifiers (to identify this notification service to the gateway service), passwords and encryption keys. It is to be appreciated that this gateway database 1030 is preferably a logical database, and may be realised as one or more physical data stores. Those skilled in the art will also recognise that 40 the one or more physical data stores that implement the functionality of the logical gateway database 1030 may be implemented in any number of ways, including a formal database or a flat file.

With continued reference to Figure 1, there is also shown a transcoding engine 1040 which is preferably used to transcode the electronic message prior to transmission to the gateway. This transcoding might include, but is not limited to, removing images, modifying images, 5 removing attachments, summarising content, removing confidential material, summarising information about the message (e.g., name of sender, date sent, subject, etc.) and the like.

Figure 1 further shows the notification server connected to two other 10 services, namely, a directory service 1050 and an awareness service 1060.

The directory service 1050 preferably provides information to the notification service regarding the devices available to a particular subscriber and the characteristics of those devices. The directory service 1050 could be provided by an LDAP database or other common directory 15 service. The awareness service 1060, such as that described in the co-pending IBM patent application filed on January 7, 2000, serial number yet unassigned (IBM docket number Y09-2000-0008), entitled "Method and Apparatus for Providing an Awareness-Service Architecture," provides information regarding the current accessibility of the devices available to 20 a particular subscriber.

Figure 1 further depicts a number of connections to gateway services 1070, 1080 and 1090. By way of example, gateway 1070 is shown connected to a telephone network, gateway 1080 is connected to an e-mail service network 25 and gateway 1090 is connected to another communication service. Each of the gateway services 1070, 1080 and 1090 is preferably a gateway service such as that illustrated in more detail in Figure 2. Figure 1 also shows each gateway connected to one or more switches, 1100, 1110, 1120 and 1130.

These switches, 1100, 1110, 1120 and 1130, if employed, preferably provide 30 network connectivity to particular devices (These switches may correspond to the switch elements designated by reference numerals 31 and 41 in U.S.

Patent Number 5,928,325). It is to be appreciated that the present invention contemplates that a device may also be connected directly to a gateway, in which case the switch may be eliminated.

Figure 1 shows end-user devices 1140, 1150, 1160, 1170 and 1180, each of which is preferably connected to an appropriate switch, 1100, 1110, 1120, or 1130. The switches are in a unique position to report information regarding the devices they service to other parties, such as to an 40 awareness service 1060 or to a gateway service. Those skilled in the art will recognise that additional gateways can be added for use with the present invention as new network types and/or topologies are developed. In addition, it is to be appreciated that if multiple networks have the same or similar characteristics, they could be handled by a single or common gateway service.

The notification server 1000 preferably includes a central processing 5 unit (not shown) which, in conjunction with other related functional subsystems (e.g., memory, control unit, etc.), as appreciated by those skilled in the art, is capable of running an applications program for controlling the one or more aspects of the notification server. For example, the central processing unit may be used for controlling access to 10 any of the database information described above, transforming message data (e.g., transcoding), communicating with services associated with the notification server (e.g., directory server 1050, awareness sever 1060, etc.), interfacing with users, or transmitting messages to the gateways 1070f 1080, 1090.

Figure 2 illustrates the architectural components comprising a gateway service such as 1070, 1080 and 1090, in accordance with one embodiment of the present invention. As shown in Figure 2, the gateway service 1070 preferably includes one or more queues 2000 of outstanding 20 message delivery requests. Using these queues 2000, the present invention is able to support devices that disconnect and later reconnect to the notification network. In accordance with a preferred embodiment of the present invention, messages to be delivered simply wait in the queue 2000 until such time as the recipient device reconnects.

Those skilled in the art will recognise the potential problems associated with having a device disconnected sufficiently long so as to fill the available queue size with messages waiting to be delivered.

Conventional means may be employed to solve these problems and may include, 30 for example, the use of circular buffers, dropping new messages, dropping the oldest message, and so on, as appreciated by those skilled in the art.

Service providers may offer different levels of service for different queue sizes, as well as for unlimited buffering of messages. Buffer size can also be limited, for example, by defining a maximum wait time per message.

35 When a message is dropped because of an inability to successfully deliver the message to an intended recipient device, a purged message notification is preferably returned to the notification service for forwarding to the sender.

40 With continued reference to Figure 2, a preferred embodiment of the present invention includes a transcoding engine 2010 for providing device-specific transcoding. Such transcoding may require detailed information regarding the characteristics of a particular device. The transcoding engine 2010 also preferably supports variations between different models of the same device. Unlike the transcoding engine 1040 included in a preferred embodiment of the notification server 1000 shown in Figure 1, the transcoding engine 2010 included in the gateway service 1070 of Figure 2 preferably possesses detailed knowledge about the device type 5 serviced by a specific gateway, including the characteristics of each different model of a family of devices (e.g., the Palm I, II, III, V, VII devices of the PalmPilot- family of connected organizers). This type of gateway is a device-specific proxy. An important advantage of this unique approach is the increased scalability that is possible when the majority of 10 transcoding is performed by the gateway rather than by the notification server itself. In addition, the system of the present invention preferably supports adding new devices, with minimal reconfiguration or impact on the notification server design, since the detailed device information need not be added to the complex body of code included in the notification server.

Figures 3A and 3B illustrate a logical flow diagram of the processing that occurs, in accordance with a preferred embodiment of the present invention, once the notification server 1000 (see Figure 1) receives a message to be delivered. With reference to Figure 3A, upon receipt of a 20 message 3000, the notification server preferably first identifies the intended recipient of the message 3010 and verifies that the intended recipient is a subscriber (i.e., user) of the service 3020. If the intended recipient is not a subscriber of this service, the notification service preferably determines whether an error message should be generated 25 3110. If not, processing stops 3100 at this point and the message is preferably dropped. If the present invention determines that an error message is to be returned to the sender, the error message is generated and subsequently returned 3120 to the sender before processing stops 3100.

30 If the intended recipient is a subscriber of the notification service, the service preferably looks up the intended recipient's preferences 3030, which are preferably stored in the user preferences database 1020 (see Figure 1) described herein above. Depending on the content of those preferences, the notification system of the present 35 invention preferably determines whether to continue processing 3040. Based upon the intended recipient's preferences, if it is determined 3040 that processing should not continue, a response will preferably be generated 3130 and processing subsequently stops 3100 (e.g., the intended recipient has indicated that it does not wish to receive messages from this sender).

With reference now to Figure 3B. assuming that processing is to continue, the notification service then preferably identifies 3050 the device(s) associated with the intended recipient, as well as the characteristics of those devices using the directory server 1050 (see Figure 1). It is to be appreciated that a device capable of exploiting resources in its environment (e.g., a handheld device near a large screen, publicly addressable display) may update the contents of the directory server 1050 so that the notification service can react appropriately to 5 such dynamic changes in configuration. The notification service then preferably determines 3060 the accessibility of the intended recipient's or user's device(s). For example, the notification service system of the present invention may use an awareness service 1060 (see Figure 1).

Alternatively, the present system could identify the gateways associated 10 with each device and query each gateway regarding the availability of the particular device(s) with the network. Such a query would likely be redirected to the switch associated with this device, although the present invention contemplates other means, as appreciated by those skilled in the art.

With continued reference to Figure 3B, based upon the availability of the intended recipient's device(s), the preferences of the recipient, the content of the message and the capabilities of each device, the notification server then preferably selects 3070 one or more devices to 20 which to transmit the message. For each such device, the notification server preferably transforms the message 3080 (e.g., by transcoding), if necessary, and subsequently transmits the message 3090, either in its original form or a transformed version of the message, to the gateway associated with the selected device. For example, a message might be 25 transformed by the notification service to remove elements of the message for which the gateway (or its associated device) is not capable of processing, or to filter confidential material prior to sending the message to an untrusted or unsecured gateway (e.g., removing confidential attachments or sending just a brief summary of information about the

30 message, such as the subject line and the name of the sender). As appreciated by those skilled in the art, the message may also be transmitted in an encrypted form, in accordance with conventional or proprietary encryption means, to provide an added level of security. After transmitting the message 3090, processing may then be completed 3100.

The notification server may submit delivery requests to each gateway for which the recipient carries a device. To avoid multiple deliveries, the notification server could additionally maintain a queue of outstanding notifications and request that each gateway inform it when a successful 40 delivery of the message has been completed. The notification server could then dequeue the now-redundant remaining delivery requests. In this manner, the notification system of the present invention can reduce the annoyance and cost to the user of having received multiple copies of the same message while minimising the delivery time of the message. Queuing the message might, of course, incur a small cost, although the advantages to the recipient of not having to sort through multiple copies of the same messages would most likely outweigh any slight cost penalty.

5 It is to be appreciated that the notification service 1000 (see Figure1) could query the gateways for the cost of delivery and then make a determination as to whether to deliver the message based upon the lowest cost. It is to be appreciated that this decision may be based upon other metrics or attributes as well, such as, for example, the estimated time to 10 deliver the message, etc. This query may result in a subsequent query from the gateways 1070, 1080, or 1090 to their associated switches.

Furthermore, the gateways themselves, 1070, 1080, or 1090, may independently optimise the delivery of a message by querying their associated switches in a manner similar to that previously described 15 herein. Querying the network for delivery attributes is especially useful when there are multiple gateways or multiple switches connected to a single gateway that could deliver the message to a particular user on a particular device, or when the user has multiple active devices at his or her disposal. It is to be appreciated that querying the gateways and/or 20 switches may be unnecessary if the metric information is available through some other means.

The notification server can also preferably initiate a query to determine the estimated time of arrival of messages sent to various 25 devices. These queries may be made of the gateway and/or switch, or they may be made to an awareness service. With this information, the, notification service can provide additional information to the sender of the message about how best to direct the message. Moreover, the notification server may automatically use such information itself in making 30 delivery decisions that meet predetermined requirements (e.g., delivery time, cost, etc.) while minimising use of expensive devices and/or networks.

If the sender of the message has requested a return receipt (e.g., 35 similar to that offered by the U.S. mail system), then the notification server preferably records this information and passes this requirement to the gateway service. This information may be made in a simple hash table or any number of other data structures, as appreciated by those skilled in the art.

Figure 4 is a logical flow diagram of the processing that occurs when the notification service sends a message to a gateway, in accordance with a preferred embodiment of the present invention. This diagram illustrates the processing that preferably occurs in the gateway in response to the transmission of message data 3090 (see Figure 3B) from the notification server. In the preferred embodiment of the present invention, the transmission of message data preferably triggers the gateway system to start 4000 processing that data by enqueuing the message 4010 for future 5 delivery (i.e., storing the message in the message queue). The gateway system then preferably determines 4020 whether the message requires a return receipt. If the present notification system determines that a return receipt is requested, the gateway records 4030 that the message requires a return receipt, along with any additional information required 10 to enable the gateway to send the return receipt back to the notification service at the appropriate time. Upon completion of this step, processing preferably stops 4040. As is evident in the diagram of Figure 4, the preferred embodiment includes little processing at this point, although it is to be appreciated that other, more complex, processing is contemplated 15 (e.g., a delivery attemDt could be made upon the initial receipt of the message), as known by those skilled in the art. Those skilled in the art will also recognise that the gateway service could send the return receipt directly, thus reducing the processing burden placed on the notification service.

Figures 5A and 5B illustrate a logical flow diagram, in accordance with a preferred embodiment of the present invention, of the processing that occurs when the gateway processes the messages in its delivery queue (these messages arrived in the delivery queue as a result of the processing 25 previously described in Figure 4). With reference to Figure 5A, for each pending message in the delivery queue, processing preferably starts 5000 by confirming 5005 whether the message has already been successfully delivered. If so, then essentially the only processing necessary for this request is that of sending the return receipt confirmation 5070 (see Figure 30 5B). If the notification service determines 5005 that the message has not yet been successfully delivered, then the system preferably checks to determine if the intended device to which the message is to be delivered is available in the network 5010. This determination 5010 may be made, for example, through the use of an awareness service 1060 (see Figure 1) or by 35 querying the network's switch (e.g., 1100, 1110, 1120, or 1130). The gateway may also request a callback from either the awareness service or the switch if the status of the device changes.

If the intended target device is not currently available, then the 40 system preferably determines 5110 whether the message delivery should be attempted anyway, or whether the message delivery should be retried at a later time. If the notification system determines that the message delivery should be retried at a later time, then the system preferably stops 5100 processing this message and continues with the next message in the queue. If a delivery attempt should be made, then processing simply continues as if the device were available.

With continued reference to Figure 5A, if it is determined that the 5 device is currently available, or if a delivery attempt is being made even though the intended device is not known to be available, then processing preferably continues by transforming 5020 the message for receipt by the intended device, assuming such transformation is required or desired. Such transformation may include those that require detailed knowledge of the 10 intended device's characteristics (e.g., formatting for the device's screen, etc.). Once transformed, the gateway then preferably transmits 5030 the message to the device, either directly or via a switch (or similar means). The system then preferably determines whether or not the transmission was successful 5040. If the transmission fails, then 15 processing preferably stops 5100. Otherwise, processing continues.

With reference now to Figure 5B, if the transmission succeeds, then the message is preferably marked as having been delivered 5050. The present system then preferably determines 5060 whether or not a return 20 receipt had been requested. If a return receipt had been requested, the notification server would be informed 5070 that the message had been successfully transmitted to the intended recipient device. When the target device includes the capability for bi-directional communication (e.g., a two-way pager, a Palm Pilot VII, etc.), confirmation of receipt may be 25 indicated by,the device. This serond receipt (s.im.ilar to a retilrn receipt for U.S. Mail) is preferably sent to the sender of the message and gives two levels of delivery confirmation: one that it was sent (5070) and another that it was received. It is important to realise that this confirmation, however, only indicates that the user's device has received 30 the message, not that the message has been received by the intended user of the recipient device.

After delivery confirmation has been sent 5070, the present system preferably determines 5080 if the delivery confirmation notice was 35 successfully received by the notification server. If the return receipt notification to the notification server 1000 fails, then processing of this message preferably stops 5100 (future processing of this message may continue with a retry of the return receipt notification and would not reprocess the message). If the return receipt notification to the 40 notification server 1000 succeeds, or if no return receipt was originally requested (as determined in step 5060), then the message is preferably dequeued 5090 and processing of this message subsequently completes 5100.

It is to be appreciated that a sender may optionally request a response from the recipient. This response can be handled similarly to the way the confirmation receipts have been described and may indicate that the intended recipient successfully received the message.

Those skilled in the art will recognise that confirmation of message 5 delivery 5070 may take place at many different levels. A direct response from the receiver is preferred, although the present invention contemplates other suitable alternatives, for example, an acknowledgement that the receiver received the message. Failing a direct response from the user/receiver (e.g., either because the receiver is using a device 10 incapable of two-way messaging or because the receiver is avoiding the message), the sender might like as much information as possible. In a preferred embodiment of the present invention, the sender is notified that the message has been presented to the receiver by an application (such as, for example, displaying the message on a screen or playing an audio 15 representation of the message on a speaker). Those skilled in the art will further recognise that such a confirmation does not imply that the receiver has processed the message (i.e., that the receiver read the displayed message or listened to the audio message).

20 The system of the present invention may also preferably inform the sender that, for example, the message was successfully delivered to the device (but perhaps not yet displayed), successfully transmitted through the network by the switch or similar manner (but receipt on the device is unknown), successfully transferred to the switch, or successfully 25 transferred to the gateway, depending upon how much information is available to the system and how much reverse communication is possible.

A system for providing a scalable pervasive notification service, in accordance with the present invention, preferably includes a notification 30 server operatively connected to one or more gateways. Each gateway, in turn, is connected, either directly or indirectly, to one or more recipient devices associated with a user(s) of the notification service. The gateway includes a message queue, for storing messages to be delivered, and/or a transcoder for transforming the format type of a message, received from the 35 notification server, to a different format type adapted for use by the intended recipient devices.

Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be 40 understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope of the invention.

CLA324S 1. A notification service for communicating messages to one or more intended recipient devices associated with at least one user of said 5 notification service,.said notification service comprising:

a notification server, the notification server including one or more databases for storing at least one of administrative information, user preferences, gateway information, directory service information and 10 awareness information; and at least one gateway operatively connected to the notification server, the at least one gateway including at least one of:

15 a message queue for storing messages to be delivered to said one or more recipient devices operatively connected to the at least one gateway; and a transcoder for transforming a message, received from 20 said notification server, from a first format type to a second format type for use by said one or more intended recipient devices operatively connected to the gateway.

Claims

2. A notification service according to Claim 1, further comprising:

a user interface operatively connected to said notification server, the user interface enabling modification of said information stored in said one or more databases.

30 3. A notification service according to Claim 1 or 2, wherein said notification server further comprises a transcoder for transforming a message to be delivered from a first format type to a second format type.

4. In a notification service comprising a notification server 35 operatively communicating with at least one gateway, a method for communicating a message to one or more recipient devices associated with at least one user of said notification service, said one or more devices being operatively connected to said at least one gateway, said method, performed by said notification server, comprising the steps of:

identifying, upon receiving a message from a sender, an intended recipient of said message and determining whether said intended recipient is a user of the notification service; retrieving, if said intended recipient is a user of said notification service, from a storage medium operatively coupled to the notification server, at least one of:

5 information relating to said intended recipient; and information relating to said one or more devices associated with said intended recipient; 10 determining, on the basis of said information retrieved from said storage medium, whether said message is to be delivered; identifying one or more devices, and characteristics corresponding thereto, associated with said intended recipient; is determining the availability of said one or more devices, associated with said intended recipient, for receiving said message; and transmitting said message to one or more gateways associated with at 20 least one available device from said one or more devices associated with said intended recipient.

5. A method according to Claim 4, further comprising the step of:

25 returning an error indication to the sender of said message if said intended recipient is not a user of the notification service.

6. A method according to Claim 4 or 5, further comprising the step of:

30 determining if the sender of said message has requested a return receipt, said return receipt indicating that said message has been delivered to said at least one available device; and transmitting information relating to whether said return receipt has 35 been requested by the sender to said one or more gateways associated with said at least one available device.

7. A method according to any of Claims 4 to 6, further comprising the step of:

transforming, for each device of said at least one available device, said message from a first format type to a second format type adapted for use by said available device, said transforming step being performed prior to said transmitting step.

8. A method according to any of Claims 4 to 7, further comprising the steps of:

generating a response, based on said information retrieved from said 5 storage medium, said response indicating that said message is undeliverable to said intended recipient; and transmitting said response to the sender.

10 9. In a notification service comprising a notification server operatively communicating with at least one gateway, said at least one gateway including a message queue for storing one or more messages, a method for communicating a message to one or more recipient devices associated with at least one user of said notification service, said one or 15 more devices being operatively connected to said at least one gateway, said method, performed by said at least one gateway, comprising the steps of:

receiving a message from said notification server; 20 storing said message in said message queue; retrieving a message to be delivered from said message queue; determining whether said message retrieved from said message queue 25 has already been delivered to said one or more recipient devices; transmitting said message retrieved from said message queue to said one or more recipient devices if said message has not already been delivered; determining whether said transmitting of said message was successful; and removing said message from said message queue if said transmitting 35 step was successful.

10. A method according to Claim 9, further comprising the steps of:

determining whether said message received from the notification 40 server requires a return receipt; storing a return receipt request if said notification server requires said return receipt; and transmitting, if said return receipt is requested, a delivery confirmation to at least one of said notification server and a sender of the message, said delivery confirmation indicating that said message was successfully transmitted to said one or more recipient devices.

11. A method according to Claim 9 or 10, further comprising the steps of:

determining whether an intended device to which said message is to be delivered is available for receiving messages; and determining, if said intended device is not available, whether to proceed with message delivery.

12. A method to any of Claims 9 to 11, wherein said at least one gateway 15 further includes a transcoder, said method further comprising the step of:

transforming, for each device of said one or more recipient devices, said message from a first format type received from said notification server to a second format type adapted for use by said recipient device, 20 said transforming step being performed prior to said transmitting step.

13. In a notification service comprising a notification server operatively communicating with at least one gateway, said at least one gateway including a transcoder, a method for communicating a message to one 25 or more recipient devices associated with at least one user of said notification service, said one or more devices being operatively connected to said at least one gateway, said method, performed by said at least one gateway, comprising the steps of:

30 receiving a message from said notification server; transforming, for each device of said one or more recipient devices, said message from a first format type received from said notification server to a second format type adapted for use by said recipient device; 35 and transmitting said message retrieved from said message queue to said one or more recipient devices if said message has not already been delivered.

14. A method according to Claim 13, further comprising the steps of:

determining whether said message received from the notification server requires a return receipt; storing a return receipt request if said notification server requires said return receipt; and transmitting, if said return receipt is requested, a delivery 5 confirmation to said notification server, said delivery confirmation indicating that said message was successfully transmitted to said one or more recipient devices.

15. A method to Claim 13 or 14, further comprising the steps of:

determining whether an intended device to which said message is to be delivered is available for receiving messages; and determining, if said intended device is not available, whether to 15 proceed with message delivery.

16. A notification service substantially as hereinbefore described with reference to the accompanying drawings.

20 17. In a notification service, a method of communicating messages to one or more recipient devices substantially as hereinbefore described with reference to the accompanying drawings.