Abstract:
This method relates to efficient message server database synchronization specifically including synchronization of databases containing email and short text messages. Client and server devices which support this message synchronization are also described.

Description:
FIELD OF THE INVENTION 
       [0001]    This relates to Electronic Message server database synchronization including email and cellular short text messages, cellular multi-media messages, as well as to mobile and other wireless client devices which support this novel message synchronization process to multiple message servers. 
       BACKGROUND OF THE INVENTION 
       [0002]    The POP protocol, well known to those in the art, provides a synchronization method of electronic messages between a single server and a client device. 
         [0003]    In addition, in RFC3501 and RFC 4551, the Internet Engineering Task Force (IETF) published the  Internet Message Access Protocol  ( IMAP ) as well as the  IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization  that addresses synchronization between multiple clients and a single messaging server. Most of the current art addresses the problem of synchronization of a single or multiple client devices to a single common server. In order to ensure high network availability, however, it is necessary in many networks, especially, but not limited to financial and telecommunications networks, to have multiple replicated database servers stored at separate physical locations in “Active-Active” configuration where multiple servers are in concurrent use, but they are synchronized via data replication. In an asynchronous multi-server environment, multiple servers can receive different message updates simultaneously or updates to one server while one or more of the other servers are not accessible. In order to maintain a high availability network, changes require asynchronous replication to at least one mirrored server. (If synchronous replication were used by the network, an outage of a mirrored server would imply an outage of the entire network, thus an asynchronous replication method between mirrored servers is required to maintain high availability.) A typical use case in such a configuration is, in the absence of failures, to have one geographic location serve a portion of clients based on subscriber mobile directory numbers and another location providing service to the remainder of the clients. Each location has a collection of servers, but the locations may not necessarily be geographically separate. The servers synchronize data amongst themselves using asynchronous replication methods. Once one or more servers at a location fails, the client can fail-over to the other group of servers and not have a service interruption. The fail-over to the other set of servers is done transparently to the client by using common methods, such as DNS or load balancers. An inherent problem of asynchronously replicated data on servers is that contents may not be exactly identical between (nearly) replicated servers at any given point of time. 
         [0004]    These database differences could be due to complete server failure, incomplete restoral of one of the servers after a server failure , timing of the replication, or other reasons which result in data which may not be exactly equivalent as intended between two or more active database servers. This synchronization problem is not adequately addressed by the existing arts. Under the current IETF published art for a multi-server scenario, the UIDValidity is not necessarily the same between the servers. Because of this, clients often detect a mailbox difference between the servers and have to repeatedly resynchronize a large amount of data (e.g. the entire mailbox stored on the server for that particular client). This inefficiency results in higher transaction costs for both the client and server, higher network traffic than necessary, as well as additional power consumption for messaging clients. In many cases, such as for cellular operators, the messaging clients are mobile phones or tablet devices where conserving battery life is a paramount concern. 
         [0005]    Other published art, US application 2012/0005283 by Nathan Provo, et al, addresses a multi-server email environment by use of additional network components, including a synchronization server and a synchronization proxy which has been found to add complexity to the network which is an important issue for network operators. In addition, the Provo method specifically does not store synchronization information on the email servers as stated in the independent claims of the Provo publication. 
       SUMMARY OF INVENTION 
       [0006]    This method uses a set of sequence numbers, labeled HIGHESTMCR by the inventor, comprising at least two server sequence numbers S 1  and S 2  to synchronize a multi-site message server database between multiple servers and one or more clients in an efficient method 
         [0007]    This method has the advantage of preventing expensive resynchronization present in the prior art IMAP conditional store process, thereby conserving power on mobile and other client devices and reducing network bandwidth usage as compared to prior art. This also represents a simpler network configuration requiring fewer network components than is taught by prior art to perform synchronization. 
       DRAWINGS—LIST OF REFERENCE NUMBERS 
       [0008]      101  Primary Server 
         [0009]      102  Client device 
         [0010]      110  HIGHESTMCR values stored on primary server 
         [0011]      121  UID database field stored on primary server 
         [0012]      122  FLAGS database field on primary server 
         [0013]      123  XMCR database field on primary server 
         [0014]      151  Secondary Server 
         [0015]      160  HIGHESTMCR values stored on secondary server 
         [0016]      171  UID database field stored on secondary server 
         [0017]      172  FLAGS database field on primary server 
         [0018]      173  XMCR database field on secondary server 
         [0019]      190  HIGHESTMCR values stored on Client device 
         [0020]      291  Copy of UID  102  on secondary server 
         [0021]      202  Copy of recently changed FLAGS record for UID  102  on secondary server only 
         [0022]      203  Copy of MCR values for UID  102  which is now the highest MCR value for secondary server 
         [0023]      260  Copy of HIGHESTMCR on secondary server 
         [0024]      290  Copy of HIGHESTMCR on client 
         [0025]      312  New value of HIGHESTMCR on primary server after restoral of primary server and replication with secondary server. 
         [0026]      341  Updated UID on primary server after replication with secondary server 
         [0027]      342  Updated FLAGS value on primary server after replication with secondary server 
         [0028]      343  Updated MCR sequence numbers on primary server after replication with secondary server 
         [0029]      410  New value of HIGHESTMCR on primary server after append to primary. Not yet replicated. 
         [0030]      441  New UID appended on primary server 
         [0031]      442  New FLAGS data appended on primary server 
         [0032]      443  MCR value for appended data 
         [0033]      460  New value of HIGHESTMCR on secondary server after update to secondary. Not yet replicated. 
         [0034]      491  New UID appended on secondary server 
         [0035]      492  New FLAGS data appended on secondary server 
         [0036]      493  MCR value for appended data 
         [0037]      510  New value of HIGHESTMCR on primary server after replication complete 
         [0038]      541  New UID copied to Primary Server after replication with secondary 
         [0039]      542  New FLAGs data copied to Primary after replication with secondary 
         [0040]      543  MCR value for appended data 
         [0041]      560  New value of HIGHESTMCR on secondary server after replication complete 
         [0042]      591  New UID copied to secondary Server after replication with primary 
         [0043]      592  New Flags data copied to secondary server after replication with primary 
         [0044]      593  MCR value for appended data 
       GLOSSARY 
       [0045]    CHANGESINCEMCR Directive that synchronizes a client with most recent changes on a given server 
         [0046]    CLIENT Used to accesses a remote service on another computer. In preferred embodiment it is an wireless message user agent used to access and manage a user&#39;s messages stored on multiple remote servers. 
         [0047]    FLAGS A set of indicators for each message which show, for example if the message was Answered , Deleted, Read, etc. Changes to Flags or other message data are a modification which will increment one of the sequence numbers. 
         [0048]    HIGHESTMCR A set of sequence numbers which indicate the most recently modified message on each of server. 
         [0049]    IETF Internet Engineering Task Force 
         [0050]    IMAP Internet Message Access Protocol 
         [0051]    IP Internet Protocol 
         [0052]    MCR Multi Client Resynchronization 
         [0053]    POP Post Office Protocol 
         [0054]    RFC IETF Request for Comments Document 
         [0055]    S 1  Sequence number corresponding to Server  1  (Primary Server) 
         [0056]    S 2  Sequence number corresponding to Server  2  (Secondary Server) 
         [0057]    UID Unique Identifier for each message, assigned in a strictly ascending fashion but not necessarily contiguous. 
         [0058]    UIDVALIDITY Unique identifier validity value as defined in RFC 3501. The unique identifier validity value is sent in a UIDVALIDITY response code in an OK untagged response at mailbox selection time. If unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session. 
         [0059]    XMCR an IMAP compatible field that holds MCR values for each message 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0060]      FIG. 1  shows the preferred embodiment, two message storage servers with a message client in normal configuration. The mailbox contents are perfectly synchronized between servers and client. Client and both servers have the same HIGHESTMCR values.  FIG. 2  shows the case where the primary server is unavailable with replication suspended between servers. A client can access only the secondary server and receive HIGHESTMCR from secondary server and other data which matches secondary site. HIGHESTMCR on primary server is out of date. 
           [0061]      FIG. 3  shows restoration of the primary server with data replicated from secondary server. Clients can receive the same information from both servers 
           [0062]      FIG. 4  shows both servers available, but a difference in data with different appends being made to both sites. HIGHESTMCR differs between servers. 
           [0063]      FIG. 5  shows both servers available and restored and appends made to both sites in  FIG. 4  have now been replicated across sites. 
       
    
    
     DETAILED DESCRIPTION 
       [0064]    This invention uses a set of sequence numbers, labeled HIGHESTMCR by the inventor, comprising at least two server sequence numbers S 1  and S 2  to synchronize a multi-site message server database between multiple servers and one or more clients. In the preferred embodiment SI. corresponds to a sequence number for the primary server and S 2  corresponds to a sequence number for the Secondary server. HIGHESTMCR is stored on all the servers as well as the clients, which indicates when the last known change occurred for each client mailbox stored on each server. The client also stores it&#39;s copy of HIGHESTMCR. HIGHESTMCR is returned by the server when the database is accessed by the client and can be compared to the client version of HIGHESTMCR. When a server receives a change to any of the information stored for a client, it increments the sequence number stored on the server associated with data stored on that server while maintaining the sequence number stored on the server for changes associated with the other servers. 
         [0065]    To verify and synchronize the client data with one of the servers, the client performs a command to determine the server&#39;s HIGHESTMCR values and compares to the HIGHESTMCR stored on the client. If all the values are the same, no further action is required, the client is verified to be synchronized. If the client has a lower value of any sequence number that comprises HIGHESTMCR, the client issues a fetch with a new directive, referred to as CHANGESINCEMCR by the inventor, to request the HIGHESTMCR as well as the changed values from the server. The client updates its HIGHESTMCR values while processing fetch responses for the unsynchronized data from the server. 
         [0066]    In the case of the client having a higher S 1 . or higher S 2  value than the server, no further action is needed by the client as the client has at that point in time a more recent version of the database. The server will eventually synchronize when replication between server sites is restored. 
         [0067]    In the method used in RFC 4551, the modsequence value used to track changes must be semantically identical between servers for the UIDValidity value to be kept same between servers. Since this is not possible in an environment where there is asynchronous replication, the UIDValidity value must be kept different between servers to ensure that the client can update its mailbox correctly. Using the method described here, the IMAP UIDValidity value remains synchronized between servers at all time which implies that client synchronization with multiple servers is not necessary. This method is an improvement over the existing IMAP conditional store process because , when the client detects a UIDValidity difference under the IMAP conditional store process, it requires additional client synchronization to other servers at added cost of network traffic and additional power depletion on the mobile client. 
         [0068]    The method requires a Server apparatus to store the Multi-client Resynchronization (MCR) sequence numbers. (MCR is labeled XMCR in the message server database by the inventor in order to be compatible with the IMAP naming conventions for proprietary extensions.) The HIGHESTMCR sequence numbers associated with each client must also be stored on each server, and a comparison of those HIGHESTMCR values with the client device is necessary The servers must also support a new CHANGESINCEMCR directive to update the client with only the unsynchronized information. 
         [0069]    This method also requires a client which will compare HIGHESTMCR with the server and also needs to support the CHANGESINCEMCR directive in order to fetch unsynchronized information. 
         [0070]    Those skilled in the art will realize this method is not limited to IMAP message servers and can be extended to other multiple server/client configurations. Those skilled in the art will further realize this method can be extended to more than just two concurrent replicated servers and is also compatible with multiple concurrent clients.