Abstract:
A method and system is disclosed for starting a server-initiated synchronization session between a mobile device and a server system. The server system and the mobile device communicate through a first communication channel for the synchronization session. After detecting that a predetermined set of data items are ready to be synchronized with the mobile device, the server system sends a notification message informing the mobile device to start a synchronization session through a second communication channel. Once receiving an initiation message from the mobile device to start the synchronization session, the server system starts to send the data items to the mobile device through the first communication channel.

Description:
BACKGROUND OF THE INVENTION 
     The present invention relates generally to computer software, and more particularly, to server initiated synchronization or communications between a wireless mobile device such as handheld PDAs and a data server. 
     The synchronization server is the intermediary between wireless clients such as the mobile devices and the Enterprise server used by a company hosting various enterprise content (e.g., email). In general the Enterprise end is equipped with servers having fast processors, enormous storage and will have little to be concerned about the memory and hardware capabilities. The clients on the other hand need to operate on limited processing power and generally have storage and efficiency constraints. 
     The synchronization server&#39;s primary responsibilities include keeping the clients in sync with the Enterprise content. It serves the clients with changes at the Enterprise server end when the client&#39;s request a synchronization operation. As such, temporarily warehousing (or storing) data items at a server system and then “synchronizing” the mobile device with the server system is a common setup for using many handheld devices. 
     Present systems and methods for replicating information from a server system to a user&#39;s mobile device are typically “synchronization” systems in which the user&#39;s data items are “pulled” from the server system in a batch each time the user desires to retrieve the information. There is another method referred to as “push” method in which the server system initiates the transfer of the data items without having any user-initiated command that causes the mobile device to receive the data items. The information is thus “pushed” onto the mobile device. In general, from the perspective of the server system, the push paradigm is a more automated, continuous, efficient and reliable system while the pull paradigm is a more passive way to provide information to the users. 
     What is needed is an efficient method for enabling a synchronization server to initiate a synchronization with a wireless device when the primary synchronization data channel does not support a mechanism for such. In the case where such a mechanism does not exist, a synchronization must always be initiated by the client. As such, the mobile client will not be aware nor updated with server-side changes until the client explicitly elects to perform a synchronization. 
     SUMMARY OF THE INVENTION 
     A method and system is disclosed for starting a server-initiated synchronization session between a mobile device and a server system. The server system and the mobile device communicate through a first communication channel for the synchronization session. After detecting that a predetermined set of data items are ready to be synchronized with the mobile device, the server system sends a notification message informing the mobile device to start a synchronization session through a second communication channel. Once receiving an initiation message from the mobile device to start the synchronization session, the server system starts to send the data items to the mobile device through the first communication channel. 
     The method and system provided by the present disclosure is extremely useful where the server system cannot notify the mobile device through its regular synchronization transport channel. 
     The server system also conveys detailed information of which database, record, and fields require synchronization in the notification message so that the client can determine whether it is in his or her interest at the time of receiving the notification message to initiate the synchronization session with the sync server. Only the modified data is then synchronized with the mobile device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a network configuration of a Sync Server operable with a message gateway and a mobile device through both a primary and secondary communication channels. 
         FIG. 2  is a flow diagram for completing a server initiated synchronization process. 
         FIG. 3  illustrates a network configuration of a Sync Server operable with other components and a mobile device for implementing a sub-record level synchronization process. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
       FIG. 1  illustrates communications between a Synchronization Server (or “Sync Server”)  100  and a mobile device  102  which is equipped with a special task agent referred to as a Sync Agent. The Sync Server  100  further includes a Database Connector  104  which provides an access channel to one or more predetermined databases (e.g. Database  106 ) which contain data items (or, Enterprise content) that is desired to be synchronized with the mobile device  102 . The Sync Server further includes a Sync Engine  108 . For a typical synchronization session, the Sync Agent residing on the mobile device  102  must initiate the synchronization session with the Sync Engine  108  over a selected Synchronization Channel  110 , which is a primary wireless communication channel. The transport type of the communications between the Sync Engine  108  and the mobile device is a “Request-Response” based form. That is, when the mobile device (or, the client) wishes to upload its data items with the Sync Server  100  or wishes to download server-side data to itself, it will have to initiate a request to the Sync Server  100 , and then through responses from the Sync Server, the synchronization process proceeds. In some situations, only the mobile device is capable of initiating message communications over the primary channel, and the Sync Server needs to find a way to ask the mobile device to start the synchronization session. In the present disclosure, a secondary communication channel is used for the Sync Server to inform the mobile device that a synchronization session can be initiated if the user so desires. 
     In one example, the Sync Server  100  is constantly aware of changes made to the Database  106 , and it is possible to further notify the mobile device  102  about the changes. Through a notification mechanism referred to as the Notification Engine  112 , the Sync Server  100  can compose and send a message to a Messaging Gateway  114 . According to one example of the present invention, the Messaging Gateway  114  uses a secondary or separate communication channel  116  which is dedicated to provide delivery of messages to the wireless mobile device  102 . 
       FIG. 2  illustrates a flow diagram  200  demonstrating the message communication between the Sync Server  100  and the mobile device  102 . In this embodiment, when the Sync Server detects that new data items are modified (added to or deleted from the database, or changed) pertaining to a particular user in step  202 , the Notification Engine  112  composes and submits a notification message conforming to the Short Messaging Service (SMS) protocol in step  204  to a gateway module such as the SMS Messaging Gateway  114 . The contents of this special SMS message contains a unique key identifying that its content is different from that of a typical SMS message. This unique key indicates that this SMS message is a notification message to “wake up” the mobile device to start the synchronization session with the Sync Server. Furthermore the notification message contains an indication of which database that the new data item has been added or modified. In addition, it may further specify exactly which record and which field of the database has been changed. One sample format of the special SMS message is shown below: 
     Notification:=&lt;uniquekey&gt;1*&lt;databaseFlag&gt; 
     UniqueKey:=“U0J9g8o3W2Jq8o::” 
     DatabaseFlag:=“a”|“m”|“d”|“t” 
     wherein the message indicates that it is a notification message, and databases identified by “a”, “m”, “d”, and “t” are ready to be synchronized. 
     In step  206 , the gateway module  114  sends out the SMS message destined for the mobile device through the secondary wireless communication channel  116 . The mobile device, having an SMS Notification Listener, may screen each incoming SMS message and look for the unique key (step  208 ). Once the SMS message arrives, it will submit to a Sync Agent in the mobile device (step  210 ). The SMS message contains more details about the changes of pertinent data items. For example, the message may include information about which data items have been added or modified, or which data items have been eliminated from the synchronization session. It is understood that this special SMS message is limited in its capacity, and a summary of details may be provided instead of all the details. It is also understood what level of detail needs to be included can be programmed by the user. 
     The Sync Agent reviews the relevant database, record, and field that the Sync Server wishes to synchronize. At this time, based on preferences of the user or the rules set forth by the user, the Sync Agent may elect or not elect to synchronize with the Sync Server the data items the message has indicated (step  212 ). The user has a dominant right to appropriately configure the interaction between the Sync Server and the mobile device so that the Sync Server will only contact the mobile device if certain selected data items have been altered. If the Sync Agent elects to proceed with the synchronization, it initiates a synchronization session with the Sync Server in step  214  by making a request over the Synchronization Channel  110  to the Sync Engine, and thereby continuing synchronization as it would normally. 
     Furthermore, the present disclosure allows one to inherit beneficial features of existing messaging channels. For example, the above described server initiated synchronization can be combined with other messaging mechanisms such as those providing for acknowledgement of message receipt or message retries to guarantee data delivery for wireless mobile devices when they are out of range or turned off. It is also understood that although an SMS message is used as one illustrative example above, other notification mechanism using a secondary channel is fully contemplated. 
     In a typical database hierarchy, the database contains multiple records, and each record contains multiple fields and their sub-fields. In order to further increase the efficiency of the synchronization, it is important to allow the clients to select only a subset of the available fields from the Enterprise content. The selected fields or sub-fields will then be the only items to be synchronized by the synchronization server, thereby avoiding synchronizing the entire record. This reduces the amount of data transferred during synchronization at any point of time, and does not swamp the client devices with unwanted or unchanged fields of the selected records. This further enables the user to specify his choice of fields to be selected from the available set of fields in the Enterprise content. 
       FIG. 3  illustrates two different users with clients/mobile devices ( 300  and  302 ) trying to synchronize with the Enterprise content at an Enterprise server  304  through an intermediate Sync Server  306 . The Enterprise server  304  may contain large data items that are quantifiable into a record identified as a Fieldset  308 . A record is essentially the field and value representation of any Enterprise content. The user however may want to synchronize only a set of fields of a record (e.g., Fieldset 1  and Fieldset 2 ) due to various considerations such as personal convenience, personal preference, ease of use, download/upload efficiency, reduction in air-time costs, or the memory constraints on wireless devices, etc. These considerations can be represented by programmed preferences stored as mapping tables  310  (e.g., Client mapping 1 /Client mapping 2 ) and maintained by the Sync Server  306 . Subsequently, when a synchronization session is requested by the client, the Sync Server  306  retrieves the mapping information for that particular user and synchronizes only the selected fields as chosen by that particular client. 
     The following sample mapping table shows contents representing the users&#39; selection of different fields for an email record. 
                                         UserID   ClientTag   ServerTag   Database Type                   D2LJSDFDF3323LJSDFF   T   TO   MAIL       D2LJSDFDF3323LJSDFF   F   FROM   MAIL       D2LJSDFDF3323LJSDFF   S   SUBJECT   MAIL       D2LJSDFDF3323LJSDFF   B   BODY   MAIL       D2LJSDFDF3323LJSDFF   I   TIME   MAIL       YLJWQEDFDF3323LJSD   T   TO   MAIL       YLJWQEDFDF3323LJSD   F   FROM   MAIL       YLJWQEDFDF3323LJSD   S   SUBJECT   MAIL       TRTWQEDFDF3323LJSD   F   FROM   MAIL       . . .                    
As shown, the user is identified by an identification code (i.e., UserID), the database for the email record is identified as a Mail database type, and each field of the mail record is represented by a single character tag such as a “F” for the field “From.” It is also understood that each user can maintain a separate field-mapping table for different mobile devices if needed.
 
     The Sync Server only communicates with the mobile devices in terms of the client tags, which are often small to save and transfer, thus saving bandwidth over the air. On the other hand, the Sync Server can communicate with Enterprise servers using server tags since there are no capacity restraints. Because of the small size of the field tags, it becomes possible to implement another filtering mechanism at the mobile device end to allow the user to reject certain data items. Other than the primary synchronization preferences selection made at the Sync Server end, a simple program can be installed on the mobile device as a secondary synchronization preference selection mechanism to allow the mobile user further accept or reject synchronization initiated by the Sync Server. For example, for an address record in the user&#39;s phone book, the user may decide through the primary synchronization preference selection that a synchronization may be initiated if the phone number field in the address record is changed. However, for various reasons, the user at a particular day, he does not want to synchronize with the address record if only the phone number is changed. If so, he can invoke the secondary synchronization preference selection mechanism on the mobile device to change this so that when the Sync Server pushes a notification message over (e.g., SMS message), the mobile device will stay dormant and will not initiate a synchronization session. 
     While sending information back and forth between the Sync Server  306  and the mobile device  300  or  302 , it is important that minimum data is transferred so that the bandwidth is not wasted. Synchronization protocols such as SyncML specifies the protocol and specification for the data to be synchronized between clients and a SyncML compliant server such as the Sync Server in  FIG. 1  or  3 . Although the present disclosure uses SyncML as one example, it is understood that the other similar protocols can be applied with the method and system disclosed here. The SyncML may specify that the data to be synchronized is a VCAL, VCARD or of other formal types. The formal definition of data works well for the Enterprise content. For example, AddressBook data can be in VCARD format. But often the Enterprise data cannot be put into a particular format. It thus lacks an efficient and consistent method for embedding any type of data into an easily constructable and easily readable format such as name and value pairs separated by a delimiter. 
     The present disclosure implements a generic data format (referred to as a “name tag”) constructed as a continuous stream of name value pairs (e.g., name1=value1;name2=value2), which is embedded in SyncML messages exchanged between the Sync Server and mobile device. The name tag definitions can be saved in a memory space  310  ( FIG. 3 ) operable with the Sync Server. A typical SyncML message may look like the following: 
                                                                                                                                                                                                                                               &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;       &lt;SyncML&gt;                &lt;SyncHdr&gt;                &lt;VerDTD&gt;1.0&lt;/VerDTD&gt;           &lt;VerProto&gt;SyncML/1.0&lt;/VerProto&gt;           &lt;SessionID&gt;1&lt;/SessionID&gt;           &lt;MsgID&gt;1&lt;/MsgID&gt;           &lt;Target&gt;                &lt;LocURI&gt;15733843&lt;/LocURI&gt;                &lt;/Target&gt;           &lt;Source&gt;                &lt;LocURI&gt;15733843&lt;/LocURI&gt;                &lt;/Source&gt;           &lt;Cred&gt;                &lt;Meta&gt;&lt;Type&gt;auth-basic&lt;/Type&gt;&lt;/Meta&gt;           &lt;Data&gt;amtlbGxlcjpqa2VsbGVyOjE1NzMzODQz&lt;/Data&gt;                &lt;/Cred&gt;           &lt;Meta&gt;&lt;MaxMsgSize&gt;32764&lt;/MaxMsgSize&gt;&lt;/Meta&gt;                &lt;/SyncHdr&gt;           &lt;SyncBody&gt;                &lt;Status&gt;                &lt;CmdID&gt;1234&lt;/CmdID&gt;           &lt;MsgRef&gt;1&lt;/MsgRef&gt;           &lt;CmdRef&gt;1234&lt;/CmdRef&gt;           &lt;Cmd&gt;Sync&lt;/Cmd&gt;           &lt;Data&gt;200&lt;/Data&gt;                &lt;/Status&gt;           &lt;Sync&gt;                &lt;CmdID&gt;123456&lt;/CmdID&gt;           &lt;Add&gt;&lt;CmdID&gt;1234&lt;/CmdID&gt;                &lt;Item&gt;                &lt;Source&gt;&lt;LocURI&gt;1$$1013179568492&lt;/LocURI&gt;&lt;/Source&gt;                &lt;Data&gt;&lt;/Data&gt;                &lt;/Item&gt;                &lt;/Add&gt;                &lt;/Sync&gt;           &lt;Final /&gt;                &lt;/SyncBody&gt;            &lt;/SyncML&gt;                    
The actual data is embedded in between &lt;Data&gt; and &lt;/Data&gt; and within the &lt;Item&gt; and &lt;/Item&gt; tag. For example, the data is stored in the following way:
 
     
       
         
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
             
           
               
                   
               
             
             
               
                 &lt;Item&gt; 
               
             
          
           
               
                   
                 &lt;Source&gt;&lt;LocURI&gt;1$$1013179568492&lt;/LocURI&gt;&lt;/Source&gt; 
               
             
          
           
               
                   
                 &lt;Data&gt;T=someone@somewhere.com;S=Subject 
               
             
          
           
               
                   
                 line;R=F;P=2;L=I;F=fromaddress@someotherplace.com;Y=here is 
               
               
                   
                 the body of the 
               
               
                   
                 mail 
               
               
                   
                 containing no delimiters 
               
             
          
           
               
                   
                 &lt;/Data&gt; 
               
             
          
           
               
                 &lt;/Item&gt; 
               
               
                   
               
             
          
         
       
     
     The name-value pair is delimited in the above example with a semicolon (;) although the Sync Server and the mobile device can determine other delimiters to use. The conventional method for determining on a delimiter is through searching the data portion and finding the least possible symbol to be chosen. This asks for a data searching process which is further clogging the use of processing power and bandwidth. Another alternative is to use a predetermined escape symbol such as a forward or back slash to indicate the occurrence of the delimiter is actually not functioning as a delimiter in the particular context. This also requires multiple entries of these predetermined symbol to be transmitted between the Sync Server and the mobile device, consequently adding considerable overhead to the data. According to the present disclosure, a prefix or delimiter indicator is added indicating the number of delimiters the data portion has to skip to reach the end of the value part with a true delimiter. Therefore, the only addition is the number of delimiters and thus reduces the overhead to the data transmitted in the air. An example is shown below to illustrate one embodiment of adding a delimiter indicator “[ ]”: 
     &lt;Item&gt; 
     
         
         
           
             &lt;Source&gt;&lt;LocURI&gt;1$$1013179568492&lt;/LocURI&gt;&lt;/Source&gt;
           &lt;Data&gt;T=someone@somewhere.com;S=Subject   
         
             line;R=F;P=2;L=I;F=fromaddress@someotherplace.com;[2]Y=here is the body of the mail;with;two semicolons;
           &lt;/Data&gt;
 
&lt;/Item&gt;
 
wherein “[2]” indicates that there are two semi-colons need to be ignored and the third one is the true delimiter.
   
         
           
         
       
    
     The main advantage of this generic format for recognizing delimiters is that it obviates the need for any specific requirement for reading and writing different formats of data. Any data at the Enterprise end can be fit into the name-value pairs, making the format disclosed herein a compelling and comprehensive means for exchanging data in the SyncML messages. It is also understood that this method for recognizing delimiters can be applied in any information exchange session, and is not limited to a server-initiated synchronization session. 
     While the method and system has been particularly shown and described with reference to the preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention, as set forth in the following claims.