Abstract:
A server routes one&#39;s incoming messages to his/her communication devices according to his/her routing preferences, and modifies the messages as needed. For example, the server can route an incoming page to one&#39;s email account and, if necessary, modify the page so that it is compatible with the email client. Thus, the server enables a number of diverse features such as: selection of routing topology (direct or indirect), translation of network restrictions, conditioning a synchronous communication for reception by an asynchronous device, message encryption, and callback or “buddy list” services.

Description:
TECHNICAL FIELD  
         [0001]    The invention relates generally to communication networks that include computer hardware and software, and more particularly to a server, software run by the server, and a method implemented by the software for routing messages according to the message recipient&#39;s preferences.  
         BACKGROUND OF THE INVENTION  
         [0002]    Today, a person may have more than one personal message device such as a wireless pager (e.g. a Skytel pager) or an e-mail client (e.g. Microsoft Outlook) that provides access to the person&#39;s e-mail account. Often, these devices communicate to other message devices via a computer network such as a local intranet or the Internet.  
           [0003]    [0003]FIG. 1 is a block diagram of a conventional computer network  10 , which allows communication between message devices. The network  10  includes a sender&#39;s computer  12   s , which has an input device  13   s  (e.g. a keyboard or a mouse) coupled thereto and which includes a processor  14   s  coupled to a storage device  16   s . The network  10  also includes a recipient&#39;s computer  12   r , which has an input device  13   r  and which includes a processor  14   r  and a storage device  16   r . For example, the storage devices  16   s  and  16   r  may include a hard drive, volatile electronic memory, or both. The computers  12   s  and  12   r  are connected to a communication path  18  by networking circuitry that is omitted for clarity. For example, the path  18  may represent the communication lines that tie into and form the Internet. The processor  14   s  can run messaging devices such as a desktop pager  20   s , a web browser  22   s  (e.g. Netscape Navigator), and an e-mail client  24   s , which allows the sender to send and receive e-mail messages via an e-mail server  26   s . Although the processor  14   s  executes the software that runs these devices, it is common to state that the computer  12   s  runs these devices. The sender may also have a wireless pager  28   s  and a voicemail server  30   s , which are also connected to the path  18 . The voicemail server  30   s  may allow the sender to send and receive voice messages via the computer  12   s  or via a telephone system (not shown). Similarly, the recipient&#39;s computer  12   r  can run a desktop pager  20   r , a web browser  22   r , and an e-mail client  24   r , which allows the recipient to view e-mail received on an e-mail server  26   r . Also, the recipient may have a wireless pager  28   r  and a voicemail server  30   r . Although the computers and message devices are labeled as sending or receiving devices for description purposes, it is understood that these labels are arbitrary such that the sending computer and message devices can be used to receive messages and the receiving computer and message devices can be used to send messages.  
           [0004]    The system  10  may also include a file server  32 , which is connected to the path  18  and which can assist with the transfer of messages between the sender&#39;s messaging devices and the recipient&#39;s messaging devices. For example, the server  32  may be a server of an internet service provider (ISP), which facilitates the transfer of messages between ISP account holders and between an account holder and a non-account holder. Or, the server  32  may be a paging company&#39;s server that transfers messages between the wireless pagers  28   s  and  28   r.    
           [0005]    In operation, the network  10  typically allows two topologies for transferring messages from one device to another: the point-to-point (PTP) topology, and the star topology. With the PTP topology, a message is routed directly between the sending and receiving devices. For example, using a PTP topology, the desktop pager  20   s sends a message directly to the desktop pager  20   r  via the computer  12   s , the path  18 , and the computer  12   r . In some applications, such as where it is an ISP server, the server  32  may open this direct path between the pagers  20   s  and  20   r . Conversely, with a star topology, the message is routed through an intermediate node or device such as the server  32 . For example, using a star topology, the pager  28   s  sends a message intended for the pager  28   r  to the server  32 , which may be the paging company&#39;s server. The server  32  then processes the message and sends it to the pager  28   r . This may occur for security or other reasons. Therefore, because the PTP topology eliminates the overhead of having the server receive and send the message, it is often faster and ties up fewer network resources than the star topology.  
           [0006]    Unfortunately, if the environment of the network  10  does not allow all messages to be sent with a PTP topology, then the server  32  may be programmed to route all messages with a star topology to prevent messaging failure. This may create an unnecessary bottleneck at the server  32 , thus significantly increasing access times and aggravation for users of the server  32 . Alternatively, if the same type of server  32  is to be installed in a network  10  having an environment that does allow all messages to be sent with a PTP topology, then the server software will have to be modified to allow this. Thus, if the server  32  can be used in both network environments, then the server manufacturer will have to develop and offer two respective software packages, one for PTP and another for star. Furthermore, the customer will have to install new software if the network environment changes, or if he wishes to install the server  32  in another network  10  having a different environment.  
           [0007]    Furthermore, a recipient is often unable to retrieve messages from some of his message devices for extended periods of time, and if a message device is unavailable to receive a message, the message may be lost. For example, suppose the sender sends an e-mail message from his e-mail client  24   s  to the recipient&#39;s email server  26   r . If the recipient is out of town and has no access to the server  26   r  other than through the e-mail client  24   r , then he must wait until he returns before he learns of and can read the sender&#39;s e-mail message. Alternatively, if the sender sends a desktop page from his pager  20   s  and the recipient&#39;s desktop pager  20   r  is not running, then the message has nowhere to go and may be lost.  
           [0008]    Additionally, a message transfer may be unsuccessful if the sending device is of a different type than the receiving device. For example, if the recipient&#39;s e-mail client  24   r  is Microsoft Outlook, it may be unable to read an e-mail message from e-mail clients other than those sold by Microsoft.  
           [0009]    Moreover, in applications where the server  32  is common to the sending and receiving devices, such as when it is an ISP server, the server  32  may use polling to allow a sender to determine if an intended recipient&#39;s message device is available to receive a message. For example, if the sender wants to send a desktop page, he may first want to determine if the intended recipient&#39;s computer is logged onto the server  32 , and thus if the recipient is “online” and able to receive the page. To make this determination, the sender requests, via his computer  12   s , the server  32  to poll all of the computers that are logged onto the server  32  and to notify the sender if one of these computer&#39;s is the recipient&#39;s computer  12   r . Unfortunately, because the server  32  must communicate with each logged on computer, such polling requires a significant amount of processing time, and thus can significantly increase user access times, particularly during hours of peak use. For example, it is common during peak hours for the number of logged-on computers to exceed one million! Furthermore, if the computer  12   r  is not logged onto the server  32  at the time that it performs the polling, then the only way for the sender to determine if the computer  12   r  subsequently logs on is to subsequently request the server  32  to repeat the polling. Thus, this significantly burdens the sender, because he may have to request several polls before he either gives up or the computer  12   r  logs onto the server  32 .  
         SUMMARY OF THE INVENTION  
         [0010]    In one aspect of the invention, a server is provided for facilitating communication between a sending device and a receiving device. The server includes a storage device for storing a program, and a processor for executing the program and having first and second states. The processor allows the sending device to send a message past the processor to the receiving device if the processor is in the first state, and the processor receives the message from the sending device and sends the message to the receiving device if the processor is in the second state.  
           [0011]    Thus, such a server can automatically select and implement the best network routing topology, star or PTP, on a message-by-message basis. In one embodiment, the server selects and implements the PTP topology unless it cannot be implemented, in which case the server selects and implements the star topology. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0012]    [0012]FIG. 1 is a block diagram of a communications network according to the prior art.  
         [0013]    [0013]FIG. 2 is a block diagram of one embodiment of a communications network according to the invention.  
         [0014]    [0014]FIG. 3 is a block diagram of another embodiment of a communications network according to the invention.  
         [0015]    [0015]FIG. 4 is a flow chart of one embodiment of a procedure that the routing servers of FIGS. 2 and 3 implement to automatically set the network routing topology for transmission of a message.  
         [0016]    [0016]FIG. 5 is a computer screen generated by an embodiment of the message routing clients of FIGS. 2 and 3 for showing a message sender the available message devices of an intended message recipient.  
         [0017]    [0017]FIG. 6 is a web home page generated by an embodiment of the message routing server of FIGS. 2 and 3 for showing the available message devices of an account holder.  
         [0018]    [0018]FIG. 7 is a web page generated by an embodiment of the routing servers of FIGS. 2 and 3 for prompting a sender who is not logged onto the server for a message and other related information.  
         [0019]    [0019]FIG. 8 is a web page generated by an embodiment of the routing servers of FIGS. 2 and 3 for prompting a sender who is logged onto the server for a message and other related information.  
         [0020]    [0020]FIG. 9 is a flow chart of a message routing procedure that an embodiment of the routing servers and clients of FIGS. 2 and 3 implement.  
         [0021]    [0021]FIG. 10 is a computer screen generated by an embodiment of the routing clients of FIGS. 2 and 3 for prompting a recipient for his off-line routing preferences.  
         [0022]    [0022]FIG. 11 is a computer screen generated by an embodiment of the routing clients of FIGS. 2 and 3 for prompting a recipient for his on-line-but-unavailable routing preferences.  
         [0023]    [0023]FIG. 12 is a flow chart of a procedure implemented by an embodiment of the routing clients of FIGS. 2 and 3 for finding all of the message devices installed on the computers that respectively run the routing clients.  
         [0024]    [0024]FIG. 13 is a device-listing screen generated by the embodiment of the routing clients that implement the procedure of FIG. 12.  
         [0025]    [0025]FIG. 14 is flow chart of a call-back procedure implemented by an embodiment of the servers and clients of FIGS. 2 and 3.  
         [0026]    [0026]FIG. 15 is a call-back-notification screen generated by the embodiment of the routing clients that implement the client portion of the call-back procedure of FIG. 14.  
         [0027]    [0027]FIG. 16 is a flow chart of procedure implemented by an embodiment of the routing clients of FIGS. 2 and 3 for learning a recipient&#39;s messaging patterns and generating a routing preference based on these patterns.  
         [0028]    [0028]FIG. 17 is a redial screen generated by the embodiment of the routing clients that implement the procedure of FIG. 16.  
         [0029]    [0029]FIG. 18 is a flow chart of a procedure implemented by one embodiment of the servers or clients of FIGS. 2 and 3 for setting client priority at log in if multiple clients of the same user are logged onto the server.  
         [0030]    [0030]FIG. 19 is a flow chart of a procedure implemented by one embodiment of the servers or clients of FIGS. 2 and 3 for setting client priority based on user activity if multiple clients of the same user are logged on to the server. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0031]    [0031]FIG. 2 is a block diagram of an embodiment of a communication network  40  according to the invention, where elements that are common to FIG. 1 have the same reference numerals. The network  40  includes a routing server  42 , which includes a conventional processor  44  and a conventional storage device  46 . In one embodiment, the device  46  includes a volatile memory such as dynamic random access memory (DRAM), a non-volatile memory such as a hard disk, or a combination of both volatile and nonvolatile memory. The processor  14   r  of the computer  12   r  runs a routing client  48   r , which, as discussed below, works with the server  42  to route the recipient&#39;s messages according to the recipient&#39;s message routing preferences. The processor  14   s  of the sender&#39;s computer  12   s  may also run a routing client  48   s , which in one embodiment is the same as the routing client  48   r . In one embodiment, the server  42  runs My Agent server software from Active Voice Corporation, and the clients  48   s  and  48   r  are My Agent software clients from Active Voice.  
         [0032]    Still referring to FIG. 2, and as discussed in more detail below in conjunction with FIGS.  4 - 19 , the general operation of the network  40  is discussed according to one embodiment of the invention.  
         [0033]    In operation, the server  42  routes the recipient&#39;s incoming messages to the recipient&#39;s message device specified by the recipient&#39;s routing preferences. For example, the routing preferences may specify that the server  42  route all messages directed to the desktop pager  20   r  to the e-mail server  26   r.    
         [0034]    To allow the server  42  to perform such rerouting, the recipient gives the sender access to one or more of the recipient&#39;s message devices via the server  42 .  
         [0035]    In one embodiment, this access is through the sender&#39;s routing client  48   s , the recipient&#39;s web page set up on the server  42 , or the recipient&#39;s address with respect to the server  42 .  
         [0036]    The server  42  automatically determines the best network topology for routing a message from the sending device to the receiving device specified by the recipient&#39;s routing rules based on criteria including the sender&#39;s identity, the identity of the recipient&#39;s message device to which the sender has directed the message, the priority of the message (e.g., urgent, normal, or low), the receiver&#39;s availability, and the size of the message. In one embodiment, the server  42  routes the message using a PTP topology unless this topology is unavailable with respect to the message.  
         [0037]    In one embodiment, if the format, such as the protocol, size, or encryption, of the sent message is incompatible with the receiving device specified by the recipient&#39;s routing preferences, then the server  42  reformats the message before sending it to the receiving device. Thus, the server  42  allows one type of message device, such as the web browser  22   s , to send a message to another type of message device, such as a desktop pager  20   r.    
         [0038]    In another embodiment, the server  42  eliminates the problems with conventional polling by maintaining a list of the users that are currently logged onto the server  42 . This allows a user to request a “callback” from the server  42  when another user logs onto the server  42 .  
         [0039]    In yet another embodiment, the client  48   r  monitors the recipient&#39;s patterns with respect to his received messages, and based on these patterns, automatically suggests, develops, or maintains the routing preferences that best fit the recipient&#39;s lifestyle.  
         [0040]    In still another embodiment, the server  42  allows a user to have multiple computers  12   r  simultaneously logged onto the server  42 , where each computer  12   r  is running a respective routing client  48   r . For example, it is common for a user to have a work computer and a home computer. Thus, the server  42  allows both of these computers to be simultaneously logged on and running respective routing clients  48   r . To prevent conflicts if the clients  48   r  have different routing preferences, the clients  48   r  determine which of them is the primary client whose routing rules the server  42  will follow.  
         [0041]    [0041]FIG. 3 is a block diagram of a communications network  60  according to another embodiment of the invention, where like elements have like reference numerals with respect to FIGS. 1 and 2. In the network  60 , the computers  12   s   1  and  12   r   1  are part of local area networks  62   s  and  62   r , respectively. Each of the networks  62   s  and  62   r  is protected by a respective conventional firewall, represented by the dashed lines  63   s  and  63   r , respectively, and includes a respective server  64   s  and  64   r . In one embodiment, the communication path  18  represents the Internet, the computer  12   s  and the server  64   s  communicate with each other over an intranet, and the computer  12   r  and the server  64   r  communicate with each other over another intranet. Furthermore, each of the networks  62   s  and  62   r  is similar to the network  40  of FIG. 2, where the servers  64   s  and  64   r  each correspond to the server  42  of FIG. 2. Thus, in this embodiment, the server  64   s  routes messages between the message devices of the network  62   s  in a manner similar to that described for the server  42  of FIG. 2. Likewise, the server  64   r  routes messages between the message devices of the network  63   r  in a similar manner.  
         [0042]    Still referring to FIG. 3, despite the firewalls  63   s  and  63   r , the server  42  allows a sending device in the network  62   s  to send a message to a receiving device in the network  62   r  and routes the message according to the recipient&#39;s routing rules. Typically, the firewalls  63   s  and  63   r  prevent the server  42  from implementing a PTP topology for such a message. But because the server  42  can automatically select the proper topology, the same server  42  that is used in the network  40  of FIG. 2 can also be used in the network  60 . That is, neither the server hardware nor server software need be modified, so manufacturing and installation expenses are reduced compared to prior-art communication servers.  
         [0043]    [0043]FIG. 4 is a flow chart that details one embodiment of the general topology selection and message routing procedure used by the networks  40  and  60  of FIGS. 2 and 3, respectively. For clarity, reference will be made to the elements of FIG. 2 unless otherwise specified.  
         [0044]    Referring to step  70 , the sending device, for example the desktop pager  20   s , initiates the sending of a message to a receiving device by sending a conventional message-initiation header to and requesting the IP address and dynamic encryption key of the receiving device (or of the computer, such as the computer  12   s , running the device) from the routing server  42  via the path  18 . With respect to the network  60  of FIG. 3, however, the pager  20   s  typically sends this information to the path  18  via the server  64   s . The message-initiation header typically includes information such as the identities of the sender and recipient and the length and priority of the message. Furthermore, in one embodiment, the server  42  determines the identities of the sending and intended receiving devices from the format of the message header. For example, a header from the desktop pager  20   s  often has a different number of bytes or is otherwise different than a header from the web browser  22   s.    
         [0045]    Next, referring to steps  72  and  73 , the server  42  examines the message-initiation header and, based on the header, the network environment, and the recipient&#39;s routing rules, determines the appropriate receiving device and whether or not PTP communication between the sending and receiving devices is possible.  
         [0046]    For example, suppose the sender desires to send a message from his desktop pager  20   s  to the recipient&#39;s desktop pager  20   r . Furthermore, suppose that the recipient&#39;s routing rules indicate that the desktop pager  20   r  is to receive this message. If the server  42  determines that there are no firewalls or other network environment conditions that prevent a PTP topology, it implements a PTP topology.  
         [0047]    Alternatively, suppose the sender desires to send a message from his e-mail client  24   s  to the recipient&#39;s e-mail account on the e-mail server  26   r , and that the recipient&#39;s routing rules instruct the server  42  to route all messages directed to the email server  26   r  to the desktop pager  20   r . If the format of the message from the email client  24   s  in incompatible with the desktop pager  20   r , then the server  42  determines that a star topology is appropriate so that the server  42  can receive and reformat the message from the e-mail client  24   s  and then send the reformatted message to the desktop pager  20   r . For example, desktop pagers such as the desktop pager  20   r  often limit the size of a received message to 100-200 bytes. Therefore, if the message from the e-mail client  24   s  is longer than this, the server  42  will decide on a star topology so that it can receive and truncate the message before sending it to the desktop pager  20   r.    
         [0048]    Or, if the message is so large or has so many recipients that a PTP topology would be unable to efficiently handle the message, the server  42  may implement the star topology. For example, suppose the sender wishes to send an e-mail message having a one-megabyte attachment to ten recipients, and that all of the recipients&#39; routing rules indicate that the server  42  is to route such an e-mail message to their respective e-mail servers  26   r . In one embodiment, because of the file length and the relatively large number of recipients, the server  42  determines that multicasting is more efficient than setting up direct PTP paths between the sender&#39;s e-mail server  26   s  and the respective e-mail servers  26   r . Therefore, the server  42  implements a star topology by instructing the e-mail server  26   s  to send the message to the server  42  only once, and then sending the received message to each of the e-mail servers  26   r  of the respective recipients. Alternatively, the server  42  may forward the message to a conventional multicasting server (not shown), which sends the message to each of the e-mail servers  26   r.    
         [0049]    Moreover, the server  42  may allow the sending device, such as the desktop pager  20   s , to first try to send a message with a PTP topology, and if this attempt fails, the server  42  instructs the sending device to retry with a star topology.  
         [0050]    Referring to FIG. 3, the server  42  may implement variations of the star topology in the network  60  if one or both of the firewalls  63   s  and  63   r  prevent the server  42  from opening a PTP path between a message device of the network  62   s  and a message device of the network  62   r . In one embodiment, after determining that it cannot implement a PTP topology, the server  42  first tries to implement a version of the star topology in which the server  42  bypasses the servers  64   s  and  64   r  and communicates directly with the sending and receiving devices. This is significantly faster and causes less traffic on the networks  62   s  and  62   r  than if the message were routed through the servers  64   s  and  64   r . For example, if the desktop pagers  20   s  and  20   r  are the sending and receiving devices respectively, then the server  42  receives the message from the pager  20   s  and sends it to the pager  20   r  in a manner similar to that described above with respect to a star topology in the network  40  of FIG. 2. If the server  42  cannot implement this version of the star topology, then, as a last resort, the server  42  routes the message through one or both of the servers  64   s  and  64   r.    
         [0051]    Next, referring to step  75 , if a PTP topology is possible, then the server  42  sends the IP address and the dynamic encryption key of the receiving device specified by the routing preferences (or of the computer  12   r  if it is running the receiving device) to the sending device.  
         [0052]    Then, referring to step  77 , the sending device sends the message directly to the receiving device—thus bypassing the server  42 , and with respect to the network  60  of FIG. 3, bypassing the servers  64   s  and  64   r —and, after it sends the message, conventionally closes the direct PTP communication path over which the sending device sent the message.  
         [0053]    Alternatively, referring to step  79 , if the server  42  cannot implement a PTP topology, the server  42  implements a star topology. Specifically, the server  42  opens a communication path between itself and the sending device and notifies the receiving device specified by the recipient&#39;s routing rules of the incoming data steam that forms the message. For example, as discussed above, if the e-mail client  24   s  is the sending device and the desktop pager  20   r  is the receiving device, then the server  42  opens a path between the e-mail client  24   s  and itself via the e-mail server  26   s , and notifies the desktop pager  20   r  that a message is forthcoming.  
         [0054]    Next, referring to step  81 , the sending device transfers the message to the server  42 .  
         [0055]    Then, referring to step  83 , the server  42  reformats the message if necessary and then sends the message to the specified receiving device. For example, if the email client  24   s  is the sending device and uses a first message format and desktop pager  20   r  is the receiving device and uses a second message format, the server  42  converts the message from the e-mail client  24   s  into the second format, and then transfers the reformatted message to the desktop pager  20   r.    
         [0056]    Next, referring to step  85 , when the sending device finishes sending the message, it notifies the routing server  42 , which conventionally closes the communication path between itself and the sending device.  
         [0057]    Then, referring to step  87 , the server  42  conventionally closes the communication path between itself and the receiving device.  
         [0058]    Thus, the servers  42  of the networks  40  and  60  of FIGS. 2 and 3, respectively, can facilitate more efficient communication between message-sending and message-receiving devices by automatically selecting the best network communication topology. Also, the servers  42  allow a recipient to redirect a message from one receiving device to another receiving device, and allow a message device of one type to communicate with a message device of another type.  
         [0059]    FIGS.  5 - 8  disclose embodiments of techniques that allow a sender to send a message to the recipient such that the server  42  can route the message according to the recipient&#39;s routing preferences. FIGS.  5 - 8  are discussed in conjunction with the network  40  of FIG. 2, it being understood that the discussion is also applicable to the network  60  of FIG. 3 unless otherwise noted.  
         [0060]    [0060]FIG. 5 is a computer screen  90  that allows a sender who is a registered user of the routing server  42  to send messages to a recipient who is also a registered user of the server  42 . Using the routing client  48   s , the sender creates one or more groups of recipients, and adds the recipient to one of these groups. For example, a sender may have a group for work colleagues and another group for personal friends. The client  48   r  for each designated recipient prompts the respective recipient for messaging information, receives the information from the recipient, and makes this information available to the sender via the server  42 . Based on this information, the routing client  48   s  generates the screen  90  on the sender&#39;s computer  12   s.    
         [0061]    The screen  90  includes a list field  92 , which includes a list of messaging devices that the recipient has made available to receive messages from the sender. In one embodiment, the routing client  48   s  is run in a Microsoft Windows® environment so that the sender can select the desired messaging device by pointing and clicking with a mouse. For example, if the sender points and clicks on the “Page” icon, then the routing client  48   s  will prompt the sender to enter a message to the desktop pager  20   s , which will send the message to the recipient&#39;s desktop pager  20   r  (or other message device specified by the recipient&#39;s routing rules) with the help of the server  42  as discussed above in conjunction with FIG. 4. In one embodiment, some messaging devices such as the desktop pager  20   s  and a chat device (activated by clicking on the “Chat” icon) actually run as part of the routing client  48   s . But the routing client  48   s  operates in a similar manner for other message devices as well. For example, the field  92  allows the sender to send messages to the recipient&#39;s e-mail server  26   r , fax, or telephone. In response to the sender&#39;s selection of these devices, the routing client  48   s  respectively activates the sender&#39;s e-mail client  24   s  or modem (not shown) so that the sender can proceed to send the message to the respective receiving devices. Furthermore, although icons are shown for certain messaging devices, the field  92  may include icons for other messaging devices such as but not limited to a wireless pager (e.g. Skytel®) or a personal digital assistant (PDA).  
         [0062]    Other features of the screen  90  include an image field  98 , which can include the recipient&#39;s photo or a live picture, a greeting field  100 , which can include the recipient&#39;s greeting, and a log-in status field  102 , which indicates whether the recipient—or more accurately the computer  12   r  running the client  48   r —is logged onto the server  42 . The screen  90  may also include other fields such as a schedule field that includes the recipient&#39;s current calendar.  
         [0063]    [0063]FIGS. 6 and 7 are web pages that allow a sender who is not registered user of the routing server  42  to send messages via the web browser  22   s  to a recipient who is a registered user of the server  42 .  
         [0064]    [0064]FIG. 6 is a recipient&#39;s home page  104  on the server  42 . The sender accesses the home page  104  by using his web browser  22   s  to access the URL for the home page  104 . Like the screen  90  of FIG. 5, the page  104  includes a device field  106 , a greeting field  108 , a log-in status field  110 , and an image field  114 , and may include other fields such as a schedule field. Like the screen  90 , although icons for certain messaging devices are shown, the device field  106  may include icons for other messaging devices such as but not limited to a wireless pager (e.g. Skytel®) or a personal digital assistant (PDA).  
         [0065]    The sender uses the web browser  22   s  to send a message to a receiving device selected from the field  106 , and as discussed above in conjunction with FIG. 4, the server  42  reformats the message if necessary and routes the message to the receiving device specified by the recipient&#39;s routing preference. In one embodiment, the page  104  also includes an option field  116 . The “My Groups” option allows the sender to view the groups to which the recipient belongs. The “My Profile” option allows the sender to view the recipient&#39;s profile, which includes additional information about the recipient. The “Search My Agent” option allows the sender to access the web pages of other registered users of the server  42  without knowing their URLs. This option is also available from the general home page (not shown) of the server  42 . A user, however, may instruct the server  42  to prohibit others from accessing his web page through the “Search My Agent” option for security or privacy reasons.  
         [0066]    [0066]FIG. 7 is a page  120 , when the server  42  sends the web browser  22   s  if the sender clicks on the “My Email” icon on the page  104  of FIG. 6. The screen  120  prompts the sender for information and allows the sender to send an e-mail message to the recipient via the web browser  22   s . As discussed above in conjunction with FIG. 4, the server  42  routes this e-mail message to the recipient&#39;s e-mail server  26   s  or to another of the recipient&#39;s message devices according to the recipient&#39;s routing preferences.  
         [0067]    [0067]FIG. 8 is a screen  122 , which allows a registered user of the server  42  to send a message from the user&#39;s own web site to a registered or unregistered recipient. The screen  122  prompts the sender for the necessary information, such as the recipient&#39;s user name or e-email address. The screen  122  also includes a “Group Options” field, which allows the user to form and join user groups, to invite other registered users to join a group, and to unjoin groups.  
         [0068]    Referring to FIGS. 9 through 11, embodiments of the techniques for setting a recipient&#39;s routing preferences and routing messages according these routing preferences are discussed.  
         [0069]    [0069]FIG. 9 is a flow chart showing how the server  42  and the receiving client  48   r  route messages according to an embodiment of the invention. The flow chart of FIG. 9 is similar to the flow chart of FIG. 4, except that it focuses on message routing instead of on the determination of the network topology.  
         [0070]    Referring to step  130 , the server  42  receives the message-initiation leader from the sending device. Next, referring to step  132 , the server  42  determines whether or not the recipient&#39;s computer  12   r , which runs the client  48   r , is logged onto the server. If not, the server  42  routes the message according to the recipient&#39;s off-line routing preferences. For example, in one embodiment, if the recipient&#39;s device to which the sender directed the message is unavailable, then referring to step  134 , the server  42  notifies the sender that the intended receiving device is unavailable. The server  42  may give the sender the option of sending the message to the receiving device specified by the off-line routing preferences or of canceling the message. Next, referring to step  136 , if the sender elects to send the message, then the server  42  routes the message to the receiving device specified by the recipient&#39;s off-line routing preferences. For example, suppose that the sender wants to send a message from the desktop pager  20   s  to the desktop pager  20   r  but the computer  12   r  is not logged onto the server  42  via the client  48   r . Furthermore, suppose that the recipient&#39;s routing preferences instruct the server  42  to route desktop pages to the e-mail server  26   r  if the computer  12   r  is off line. Thus, the server  42  informs the sender that any page he sends will be routed to the recipient&#39;s e-mail server  26   r  and asks the sender if he still wants to send the page or if he wants to cancel and wait until later. If the sender decides to go ahead and send the page, the server  42  will route the page to the email server  26   r . In another embodiment, however, the server  42  routes the message to the preferred off-line device without informing the sender.  
         [0071]    Referring to step  138 , if the computer  12   r  is logged onto the server  42 , then the server  42  routes the message to the receiving device specified by the recipient&#39;s online routing preferences. For example, the on-line routing preferences may instruct the server  42  to route a page from the desktop pager  20   s  to the desktop pager  20   r.    
         [0072]    Next, referring to step  140 , after the server  42  routes the message, the receiving client  48   r  determines if the specified receiving device has a rerouting condition, such as a user-activity rerouting condition, associated with it. If there is no condition, then referring to step  142 , the server  42  and the client  48   r  take no further action with respect to the message. If there is a rerouting condition, however, then referring to step  144 , the client determines if the condition is met. If the condition is met, then referring to step  146 , the client causes the server to reroute the message to the device specified by the routing preferences. For example, as discussed below in conjunction with FIG. 11, the routing preferences may specify that if a recipient does not “pick up” a message to the desktop pager  20   r  within a certain amount of time, then the client  48   r  is to cause the server  42  to reroute the message to another receiving device such as the e-mail server  26   r . Thus, if the recipient does not pick up the page within the allotted time, then the client  48   r  causes the server  42  to reroute the page to the e-mail server  26   r . Referring again to steps  144  and  146 , in one embodiment, the client  48   r  monitors the receiving device to determine if the condition is met. This embodiment is useful when the receiving device, for example the desktop pager  20   r , is part of the client  48   r . In another embodiment, the receiving device notifies the client when the condition has been met.  
         [0073]    [0073]FIG. 10 is a screen  147 , which is generated by the routing client  48   r  and which prompts a recipient to enter his off-line routing preferences. Specifically, a prompt  148  prompts the recipient to select the preferred device or devices for receiving a message intended for the desktop pager  20   r  if the computer  12   r  is not logged onto the server  42  when the message is sent. In the embodiment shown, the recipient enters the preferred device or devices, here the e-mail server  26   r , in a field  149 . Thus, if the recipient is out of town and is not running his computer  12   r , then the server  42  will forward all desktop pages to his e-mail server  26   r . If the recipient has remote access to his e-mail server  26   r , then he can access these desktop pages before he returns from his trip.  
         [0074]    [0074]FIG. 11 is a screen  150 , which is generated by the routing client  48   r  and which prompts the recipient to enter a rerouting condition. Specifically, a prompt  151  prompts the recipient to check a box  152  if he would like the server  42  to reroute desktop pages if the recipient does not pick up the message within a time period specified in a box  154 . The device to which the page will be rerouted is specified in a box  156 .  
         [0075]    The server  42  or the client  48   r  can determine if the recipient has picked up the desktop page from the desktop pager  20   r  in a number of ways. In one embodiment, the client  48   r  or the server  42  monitors the input device  13   r  to determine if it has provided any data to the computer  12   r  within the time period specified in the box  154 . The idea is that if the input device  13   r  provides data during the specified time period, then the recipient was sitting at the computer  12   r  during this period and thus has read the desktop page. Conversely, if the input device  13   r  has not provided data, then the recipient was not sitting at the computer  12   r  during the specified period and thus has not read the desktop page. The input device  13   r  may be any conventional input device such as a keyboard or mouse. Alternatively, the device  13   r  may be a device such as a video camera or a microphone that the server  42  or client  48   r  monitors for movement or sound, respectively.  
         [0076]    [0076]FIG. 12 is a flow chart of an automatic-message-device-recognition procedure implemented by one embodiment of the routing client  48   r.    
         [0077]    First, referring to the step  160 , the recipient boots the routing client  48 . The recipient may do this by a special command after the computer  12   r  has booted up, or the client  48   r  may boot automatically during the boot sequence of the computer  12   r.    
         [0078]    Next, referring to step  162 , the booted client  48   r  searches the storage area  16   r  of the computer  12   r  for message devices that are installed on the computer  12   r  such as the desktop pager  20   r , the web browser  22   s , and the e-mail viewer  24   s.    
         [0079]    Then, referring to step  164 , the routing client  48   r  determines which of these installed message devices the recipient wants to make available to senders. In one embodiment, these available message devices are included in the device fields  92  and  106  as discussed above in conjunction with FIGS. 5 and 6, respectively. More specifically, on its first boot, the client  48   r  includes all such devices in the fields  92  and  106 . The recipient, however, can remove one or more of these devices from the fields  92  and  106 . On subsequent boots, the client  48   r  will omit from the fields  92  and  106  any message devices previously removed therefrom, unless the recipient subsequently adds these devices back to the fields  92  and  106 .  
         [0080]    Next, referring to the step  166 , the booted client  48  sends to the server  42  the identifies, addresses, and other information for the message devices that are listed in the fields  92  and  106 , and also sends the server  42  the recipient&#39;s routing preferences as discussed above.  
         [0081]    Therefore, the recipient does not have to perform a tedious installation of the message devices into the client  48   r  or the server  42 . Furthermore, the client  48   r  may even identify and list message devices that the recipient didn&#39;t even know were installed on the computer  12   r!   
         [0082]    [0082]FIG. 13 is a display screen  170 , which one embodiment of the client  48   r  generates according to the flow chart of FIG. 12 to allow a recipient to remove and add message devices that are available to senders. The available devices are listed in a field  172 , and can be deleted or added by clicking on the “Delete Device” and “Add Device” icons, respectively. When the “Add Device” icon is selected, the client  48   r  lists for the recipient&#39;s selection all message devices installed on the computer  12   r  but not currently available to senders, ie., not listed in the fields  92  or  106 .  
         [0083]    [0083]FIG. 14 is a flow chart of a callback procedure executed by the server  42  and the routing client  48   s  according to an embodiment of the invention.  
         [0084]    Referring to step  180 , the server  42  maintains a list of the users that are currently logged onto the server  42  via their respective clients  48 , and also maintains a list of undelivered callback requests.  
         [0085]    Next, referring to steps  182 ,  184  and  186 , in one embodiment, the server  42  provides to a sender the log-on status of the recipients in the sender&#39;s groups, such as provided in the field  102  of the screen  90  in FIG. 5. More specifically, referring to step  182 , the sender logs onto the server  42  via the computer  12   s  and the client  48   s . Next, referring to step  184 , the server  42  determines the log-on status of each user in the sender&#39;s groups by checking the logged-on list. In one embodiment, the server  42  stores the membership data for the sender&#39;s groups so that the client  48   s  need not send this data to the server every time the sender logs onto the server. Then, referring to step  186 , the server  42  sends the log-on status of each of these users to the sending client  48   s . In one embodiment, the sending client  48   s  can also request the log-on status of a user even after the sending client  48   s  has logged onto the server  42 .  
         [0086]    Next, referring to step  188 , the sender requests a callback. That is, the sender requests the server  42  to deliver a callback request to the client  48   r  of a recipient. The callback request notifies the recipient that the sender wishes to contact him/her. For example, in one embodiment, referring to the field  92  in the screen  90  of FIG. 5, the sender can request a callback by clicking on the “Set A Callback” icon.  
         [0087]    Then, referring to steps  190  and  192 , the server  42  checks the logged-on list and determines whether the recipient is logged onto the server.  
         [0088]    Next, referring to step  194 , if the recipient is logged on, then the server delivers the callback request to the recipient&#39;s client  48   r.    
         [0089]    But, referring to step  196 , if the recipient is not logged on, then the server adds the callback request to the callback list. Referring to step  198 , when the recipient logs on, the server  42  checks the callback list to determine if the recipient has any outstanding callback requests. If, as in this example, the recipient does have an outstanding callback request, then the server  42  delivers the callback request to the recipient&#39;s client  48   r.    
         [0090]    Thus, the callback procedure eliminates the problems associated with conventional polling as discussed above in conjunction with FIG. 1.  
         [0091]    Referring to FIG. 15, in one embodiment of the callback procedure described in the flow chart of FIG. 14, the client  48   r  generates a screen  200  in response to the callback request delivered by the server  42 . The screen  200  identifies the sender and allows the recipient, via the client  48   r , to either allow or cancel the callback. That is, the recipient has the option of allowing the server  42  to notify the sender that the recipient is now available or of preventing the server  42  from doing so. Thus, the recipient can cancel the callback request if he/she does not want to be bothered by the sender.  
         [0092]    [0092]FIG. 16 is a flow chart of a message-routing learning procedure implemented by one embodiment of the routing client  48   r . Implementing this procedure allows the client  48   r  to automatically suggest, generate, or maintain the recipient&#39;s routing preferences.  
         [0093]    Referring to step  201 , the client  48   r  periodically or continually monitors the recipient&#39;s actions with respect to his received messages. Next, referring to step  202 , the client  48   r  automatically suggests changes to, sets, or updates the routing preferences based on patterns that the client  48   r  has detected with respect to the received messages and the recipient&#39;s related actions. Then, referring to step  204 , the client  48   r  sends these new routing preferences to the server  42  (with the recipient&#39;s permission if the client  48   r  has only suggested new routing preferences).  
         [0094]    Still referring to steps  201 ,  202 , and  204 , in one embodiment, the client  48   r  implements a statistical correlation matrix, such as a conventional Baysian network, to correlate message characteristics (e.g., sender&#39;s identity, time of day message received) with the recipient&#39;s actions (e.g., forward or ignore message) for a group of messages such as the last one thousand received messages.  
         [0095]    For example, suppose that using this technique, the client  48   r  determines that out of fifty phone calls to the recipient&#39;s work phone on weekends and after 5:00 p.m. on weekdays, the recipient has answered two, and the rest have been routed to the recipient&#39;s voicemail server  30   r . (In one embodiment, the client  48   r  can determine whether a call is answered or sent to voice mail by communicating with the voicemail server  30   r  using conventional techniques.) Therefore, in response to this pattern, the client  48   r  may suggest that the recipient adopt a routing preference that causes the server  42  to route all work phone calls received on weekends and after 5:00 p.m. and on weekdays directly to the voicemail server  30   r , and thus reduce the chances that the caller will be aggravated by the phone ringing a number of times before he is transferred to voicemail.  
         [0096]    Or, suppose that the client  48   r  determines that out of twenty five e-mail messages from a particular sender when the e-mail client  24   r  also displays unread e-mail messages from other senders, the recipient has opened this particular sender&#39;s messages first twenty four times. (In one embodiment, the client  48   r  can determine the order in which unread e-mail messages are opened by communicating with the e-mail client  24   r  or e-mail server  26   r  using conventional techniques.) In response to this pattern, the client  48   r  may suggest that the recipient adopt a routing preference that causes the server  42  to route all e-mails from this particular sender with high priority or in another manner such that they are always at the top of the unread e-mail list when the e-mail client  24   r  displays unread e-mail messages.  
         [0097]    [0097]FIG. 17 is a screen  206  and a redial list  208  generated by one embodiment of the routing client  48   s  according to a procedure similar to that discussed above in conjunction with FIG. 16. Unlike the FIG. 16 procedure, however, this procedure learns a senders message-sending patterns. More specifically, the client  48   s  keeps track of the most popular message-sending actions that the sender has taken. In this embodiment, the client  48   s  retains ten actions, and updates the list  208  to include the last action taken. But when the client  48   s  updates the list  208  with the most recent action, it removes the least popular action on the list  208  and not necessarily the least recent action taken. Thus, the list  208  is not merely a list of the last ten actions taken, but is a combination of the last actions taken and the actions that the sender takes most frequently. For example, the list  208  may include the last five actions taken, and five of the most frequently taken actions.  
         [0098]    [0098]FIGS. 18 and 19 are flow charts showing embodiments of respective procedures that allow a user to have multiple routing clients  48  simultaneously logged onto the server  42 . For example purposes, referring to FIG. 2, assume that the recipient owns the computers  12   s  (work) and  12   r  (home) and runs the routing clients  48   s  and  48   r  simultaneously. As discussed above, the labels of sending and receiving for the clients  48   s  and  48   r  are arbitrary as these clients can perform both message-sending and message-receiving functions. Therefore, this is an accurate example.  
         [0099]    The flow chart of FIG. 18 is an embodiment of a procedure to designate a newly logged-on client  48  as the primary client and the other client or clients that are already logged on as passive clients. The significance of the primary client  48  is that the server  42  follows the routing preferences of the primary client. For example purposes, the client  48   s  is the newly logged-on client, and the client  48   r  is already logged on to the server  42  at the time the client  48   s  logs on. It is understood, however, that in some embodiments there may be more than one client  48  already logged onto the server  42 .  
         [0100]    More specifically, referring to step  220 , the “new” client  48   s  logs onto the server  42  via the computer  12   s  and determines whether or not the client  48   r  is logged onto the server  42 . The new client  48   s  may make this determination in a variety of ways. In one embodiment, the server  42  automatically provides the new client  48   s  with the log-in status of the client  48   r  in a manner similar to that discussed above in conjunction with FIG. 14. In another embodiment, the new client  48   s  requests the log-in status of the client  48   r  from the server  42  also in a manner similar to that discussed above in conjunction with FIG. 14.  
         [0101]    Next, referring to step  222 , if the client  48   r  is not logged onto the server  42 , then, referring to step  224 , the new client  48   s  transfers its message-routing preferences to the server  42 , and referring to step  226 , the server  42  proceeds to route messages according to these routing preferences as discussed above in conjunction with FIG. 4.  
         [0102]    On the other hand, if the client  48   r  is logged onto the server, then the client  48   s  instructs the client  48   r  to become passive. The client  48   s  may provide these instructions to the client  48   r  in a number of ways. In one embodiment, the new client  48   s  requests the server  42  to set up a PTP communication path between it and the client  48   r  as discussed above in conjunction with FIG. 4. In other embodiments, the new client  48   r  requests a communication path to the client  48   r  through the server  42  (star topology) also as discussed above in conjunction with FIG. 4, or the server  42  instructs the client  48   r  to become passive.  
         [0103]    Referring again to steps  224  and  226 , after the client  48   r  is instructed to become passive, then the new client  48   s  transfers its routing preferences to the server  42 , which routes messages according to these preferences.  
         [0104]    The flow chart of FIG. 19 shows an embodiment of a procedure to select a new primary client among multiple clients that are all already logged onto the server  42 .  
         [0105]    Referring to step  230 , multiple clients  48  are logged onto the server  42 , and one of these clients is the primary client and the others are passive clients. For example purposes, suppose that the user went home from work and left his work client  48   s  running. Then suppose he logs the home client  48   r  onto the server  42 , and according to the procedure described in conjunction with FIG. 18, the client  48   r  becomes the primary client and the client  48   s  becomes the passive client.  
         [0106]    Referring to step  232  and using the above example, the passive client  48   s  detects a condition, such as user activity, that indicates it should now be the primary client For example, this situation occurs if the user goes back to work without logging off the client  48   r  and starts using the computer  12   s . The theory here is that the user wants the client on the computer he is using, here the client  48   s , to be the primary client so that his messages are routed accordingly. In one embodiment, the client  48   s  detects the user activity by monitoring the input device  13   s  as discussed above in conjunction with FIG. 9.  
         [0107]    Next, referring to step  234 , the passive client  48   s  instructs the primary client  48   r  to become passive. In one embodiment, the passive client  48   s  communicates with the client  48   r  as discussed above in conjunction with FIG. 18.  
         [0108]    Then, referring to the step  236 , the passive client  48   s  transfers its message routing preferences and other information to the server  42  and becomes the new primary client.  
         [0109]    Referring to step  238 , the server  42  then routes subsequent incoming messages according to the routing preferences provided by the new primary client  48   s.    
         [0110]    From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention.