WO2004001588A2

WO2004001588A2 - A system and method to re-synchronize client devices while refreshing them from a server

Info

Publication number: WO2004001588A2
Application number: PCT/EP2003/006215
Authority: WO
Inventors: Gérard Marmigere; Joaquin Picon; Pierre Secondo
Original assignee: International Business Machines Corporation; Compagnie Ibm France
Priority date: 2002-06-20
Filing date: 2003-05-13
Publication date: 2003-12-31
Also published as: CN1653420A; AU2003246419A1; CN100342334C; WO2004001588A3; JP2005530258A; WO2004001588A8; AU2003246419A8; EP1550034A2

Abstract

A method and computing systems for refreshing, from a server, objects locally stored by a client device remotely connected through a communicating means to said server. The client device send a request for refresh message and a list of object identifiers and the digest of the object itself stored in its local storage. The server, after checking the deals the client device has subscribed to, sends back a refresh answer message with the objects stored locally in the client device and which needs to be refreshed. According to the deals to which the client device has subscribed, the server will also send new objects and will send a special code to specify to the client device to delete objects which are no more part of the deals.

Description

A SYSTEM AND METHOD TO RE-SYNCHRONIZE CLIENT DEVICES WHILE REFRESHING THEM FROM A SERVER

Field of the Invention

The present invention generally relates to consumer electronic devices including computing capabilities and using the services of a server; more particularly, the present invention concerns the operation of refreshing those devices from the server with an updated set of objects.

Background of the Invention New home client devices, mobile phones or other consumer electronic devices including computing capabilities use web browsers to download information locally from web servers providing Internet services. Contrary to professional equipment, these widely spread devices browse local information in disconnection mode. When they reconnect, the devices need to be refreshed with the updated information hold by the web server according to the services the device has subscribed to in the server.

One other characteristic of these low cost consumer devices is that while in disconnection mode these devices may be re-initialized for reason of maintenance or even replacement. In this case, a re-synchronization must be done at re-connection time between the server and the device, such a re-synchronization having also to take into account the services the device has subscribed to .

Typically, for this kind of devices a scheduled refresh every night plus refresh on user's request is considered as appropriate .

A first problem with the operation of refreshing devices from servers is the amount of information to be downloaded. As the information may be refreshed once or more a day (this is the case of stock value information) , the server is not aware of the level of information requested by the device and, in case of reconnection, will send to each client device its own complete information set. This method is acceptable as long as the volume of information downloaded in each device is low in term of transmission time and transmission cost. The constant increase of locally kept data in the devices quickly leads to unmanageable situations. As an example, a 10 Mbyte update will generally require more than half an hour of transmission time for each device, and if the server has 100 K devices to update, it will require a huge and costly pipe to serve the required volume which reaches 1 Terabyte in this case . A first solution exists to reduce the amount of information downloaded to refresh an on-line client device with a new level of information. This solution applying to containers is disclosed in the US patent US6148340 assigned to International Business Machines Corporation. It consists in keeping track, at the server side, of the last level of containers downloaded to the devices . To refresh a device with a new level container, the server sends only the containers having been modified since the last downloading. Furthermore, the refresh operation is oriented to on-line client devices because the level of refresh is maintained by the server and is reevaluated at each request of the client device.

The solution of the prior art reduces efficiently the amount of information downloaded by a web server to the client device during a refresh operation. However, it does not answer the need for re-synchronization of a device which has been re-initialized during the time where it was disconnected. Thus, at re-connection time, there is a discrepancy between the real information the client device has in its local storage and what the web server knows as being the information stored locally by that client device which is the information it has already downloaded.

Furthermore, with the solution of the prior art, there is no consideration of the current subscriptions taken by the client device to the web server. Since the last level of containers has been downloaded to a given client device, this client device may have changed the subscriptions to the server services for one service and may be supposed to access a set of information different from the containers the server has kept track for this device according to this solution.

Summary of the Invention

It is therefore an object of the present invention to provide a method and system to send to client devices the correct level of information they need when requesting to the server to be refreshed on the information corresponding to the service they have subscribed to.

It is another object of the invention to only send updated information.

It is a further object of the invention to re-synchronize at reconnection time a client device a level of information in accordance with the current subscription to the server services .

The objects are reached by a method, according to claim 1, for re-synchronizing a client device while refreshing, from a server, objects locally stored by said client device remotely connected through a communicating means to said server which keeps track of deals subscribed by said client device, said method comprising the steps of: reading, in the client device, a list of data comprising an object identifier and a digest identifying an object content stored in the client device local storage; sending from said client device a request for refresh message to said server comprising a client device identifier and the list of read data; reading in the server a list of objects identifiers corresponding to the deals subscribed by said client device identified by the received client device identifier; comparing at said server the list of data received in the request for refresh with a list of data stored by said server comprising an object identifier and a digest identifying the object content which is also stored by said server; sending from the server a refresh answer message to the client device with a list of objects comprising, for the objects corresponding to the deals subscribed by said client device and for which the digest received is different from the digest read in the server, an object identifier, its corresponding digest and its content read in the server; receiving in the client device the refresh answer message and replacing the content of objects locally stored and the digest in the list of data of the corresponding object identifier for the objects belonging to the list of objects.

According to claim 2, if new objects belong to the deals the client device has subscribed to, the server adds in the list of objects, the information corresponding to these new objects. According to claim 3, the server sends in the list of objects an object identifier with the specific code when the corresponding object no more belongs to a deal the client device has subscribed to. The client device will cancel in its local storage the object itself and any information referencing this object. The method is implemented by a program product operating in the server and a program product operating in the client device .

The main advantage of the invention is that it applies to widely spread client devices which are often used in disconnection mode.

Brief Description of the Drawings

Fig. 1 illustrates the environment of the preferred embodiment ;

Fig. 2 illustrate the three tables stored on the server side to manage the device objects which are the Subscription_table, the Deal_Object_table and the Object_table;

Fig. 3 illustrates how are chosen the objects to be updated in the client device;

Fig. 4 shows the format of object lists downloaded to the client device; Fig. 5 illustrates the subscriber current object table located in the client device before and after refresh;

Fig. 6 is an illustration of the exchange of information between the client device and the web server; Fig. 7 is the flow chart of the method of the preferred embodiment to refresh and synchronize the client devices.

Detailed Description of the preferred embodiment

Fig.l is a description of the environment of the invention. A web server (100) provides services to client devices (110, 120) through a network (130) which could be Internet and which may include mobile communications. An Internet client device uses a web browser to ask the send request to the server for accessing information which could be any type of object such as a HTML page or an image file (JPG, GIF etc... ) or an audio file (WAV, MP3 etc... ) , forming what is generally called a web document (150) . The server keeps track of the client device identity using for instance for a mobile phone, its IMEI (International Mobile Equipment Identity) . The screen phone client devices may send their Internet appliance for identification standardized with ISRF. More generally, all the client devices send an identification similar to a serial number which is a unique identifier.

The server keeps track also of the service subscribed by the client device and more than that, the client device may be interested in certain information provided by the service and described in its profile. In the description of the preferred embodiment one simple example of service subscribed without a profile but the man skilled in the art may adapt the preferred embodiment easily with client profiles . The information may be static such as recipes for a cooking information service, or may be refreshed once a day such as newspapers or several time a day such as with the weather sites. According to the preferred embodiment, the server will only send the information which is new compared to the last level previously sent. In Fig. 1, the client device has been disconnected and needs to be refreshed by the web server. The client device sends an explicit request for refresh with re-synchronization information it stores locally in the device which will help the server to re-synchronize the client device with the correct level of information needed. The web documents (150) are initially stored by the Origin server' (140) which sends them on request to the remote web server (100) providing services to the subscriber client devices (110, 120). The remote web server refreshes the client devices only with the updated objects of the web documents. The client devices, once refreshed, can reconstitute the web documents (150) locally with the refreshed objects according to the preferred embodiment.

The client devices which are subscribers to the web server information services have communication equipement local storage units to store objects constituting the web documents, at least one processor to re-constitute the web documents, to display them and to send requests for refresh according to the preferred embodiment. The server re-synchronizes the devices and refresh them by downloading information. The device can receive the information, modify the locally stored objects and locally stored re-synchronizing information. The refresh and synchronize method may be implemented as programs executed in the server and in the client device their computing resources. Fig.2 illustrates the three tables stored on the server side. The client devices are browsing 'Local web pages' composed of objects. An object is a piece of data handled as a single entity. It is, for the purpose of the preferred embodiment a unit of refresh. The server tables are the Subscription_table (200) , the Deal_Object_table (210) and the Object_table (220) . The Subscription_table is for storing the 'deals' uniquely identified by the the Deal_ID, associated with a given client device uniquely identified by the Device_ID. Each deal corresponds to a subscription taken on the services offered by the server. With this table, the server is able to retrieve all the deals associated to a given client device. The Deal_Object_table stores for each deal identified by the Deal_ID the list of objects associated to this deal and uniquely identified with the Object_ID assigned by the server. This table is used by the server to retrieve all the Object_IDs belonging to the deals associated to a given client device. The Object_table is maintained by the server to associate to each Object_ID an Object signature which is a 'digest', a code identifying the content of a' text which is used for security. MD5 is a one-way hash giving a reduced representation of the object. The MD5 signature allows identification of a large text with a good level of security. Any other 'digest' can be used for the preferred embodiment. The server acts as a 'proxy' function getting objects from local or remote 'origin servers'. At each reception by the server of a new object from an origin server, a signature is computed. The Object_table contains the last value of the object received and the corresponding computed signature. The server stores for each Object ID the computed signature, the object length and the local URI (Universal Resource Identifier) or the remote URL (Universal Resource Locator address) identifying the web address of the Internet or Intranet origin server having provided the web documents containing said objects. The address is not used for the refresh and the re-synchronization of the client devices but used by the server to periodically require to the origin servers the last level of the objects.

Fig. 3 illustrates one example of sets of objects and how the server will choose among all these objects to refresh a client device. The set of objects belonging to deals pertaining to a given client device has been defined by reading the Subscription_table (200) and the Deal_Object_table (210) . As an example, it consists for device T01 in Obj2, Objl, Obj3 and Obj4. The server learns which objects have been resident in the client device before refresh by the request sent by the client device which will be described in reference to Fig. 6 later in the document. These objects form the second set of Fig. 3 comprising: Obj5, Objl, Obj3 and Obj4. The server will look at the intersection between the two sets to define the objects which need to be updated for the client device: Objl, Obj3 and Obj4. The object 0bj5 is no more part of the deals the client device has subscribed to and the server will request the client device to delete it as well as any information stored in the device and referring to this object. The object Obj2 is not an object having been resident in the client device: the server has to refresh the client device with this new object. As for the objects which have been resident in the client device, Objl, Obj3 and Obj4, the server has to refresh the client device with the last version of this object if the version resident in the client device has not the same signature. The server will know the signature of the objects resident in the client device because the signatures will be included in the request sent by the client device which will be described in reference to Fig. 6 later in the document.

Fig. 4 illustrates the format of the object list that the server will download to the client device to refresh it. The example of Fig. 4 shows n objects from Objl to Objn. Each 'Object' of the object list comprises the Object__ID, the Object_Signature which is the last level of signature from the Object_table , the Object length from the Object_table and the Object itself which has been read from the origin server. Fig. 5 illustrates the update of the Current Subscriber Object Set table which is maintained in the client device. The table comprises the Object_ID and the signature of the Object. The Object_ID has been assigned by the server, the signature has been computed by the server and they have both been downloaded in a previous refresh operation. The Current Subscriber Object Set table contains the last level received from the server. Upon a request for refresh sent by the client device the server will select the objects to be downloaded to the client device as illustrated in reference with Fig. 3. When the client device receives the object list sent by the server the local object versions are updated, the client device updates also the table (with the Object_ID and Signature) accordingly. In Fig. 5 the first table is the previous level before refresh (500) and the second table (510) is the last level after refresh. Illustrating the same example than in Fig. 3, the new level (510) no more includes a reference to Obj5, has introduced a new reference to new object Ob 2 and updated the signature of the only objet which has to be changed Obj3 because its signature has changed.

Fig. 6 illustrates the messages exchanged between the client device and the server. The protocol used in the example is HTTP wherein a request is sent using the 'POST' command (600) . The posted message follows the refresh request syntax of the preferred embodiment. The command is 'Refresh', the Terminal_ID is TOl in the example, the list of Object_ID and associated Signatures are the content of the Current Subscriber Object Set table locally stored in the client device. The client device post a request to refresh the objects which are locally stored. The request can be sent once a day for this kind of client devices working while disconnected. The server answers this request by reading the client device identification and identifying all the deals corresponding to this client device and all the objects associated to this deals using the two tables the Subscription_table (200) and the Deal_Object__table (210) . According to the illustration of Fig. 3, the server will decide what are the objects candidate to be updated for this client device (320) . Then, by reading the Object_table the server reads, for each object candidate to be refreshed what is the signature. The signature stored in the Object_table is the signature computed by the server when it has received and stored the last level of the object from the origin server. If the signature of the Object_table is the same than the signature included in the request from the client device, the server will not send this object in its answer. In the example, Objl and Obj4 have not a different signature (respectively S12 and S41) and they will not be sent by the server. Obj3 locally stored by the client device corresponds to a level identified by the signature S32. In the server, the level stored has the signature S31 which is different. The current level of Obj3 must be sent for refresh to the client device. Also the new Obj2 must be sent and the server must advise that the Ob 5 must be deleted from the client device storage as no more belonging to a deal that the client device has subscribed to .

The answer (610) from the server is illustrated as well in Fig. 6. Using HTTP protocol, the server sends a simple message answering the Post message. The command is 'Refresh_response' followed by the 'Object_list ' according to the format described in reference to Fig.4. Obj3 is sent with the updated signature, S32, the new object length and the object content itself. Obj2 is sent with the once computed signature, S21, the object length and the object content itself. Ob 5 as stated before is no more part of the deals of the client device, is not refresh and the identification of 0 for the signature and 0 for the object length in the Refresh-response means that this object must be canceled from the local storage of the client device and the record must be deleted from the Current Subscriber Object Set table.

If the client device is re-initialized after a maintenance or replaced by a new device in case of fatal breakdown, the Current Subscriber Object Set table is empty and the request is for sending all the objects corresponding to the deals the client device has subscribed to. The Refresh command posted by the client device will include no object. This is the way in the preferred embodiment to advise the server that he needs to receive all the last level objects corresponding to all the deals it has subscribed to .

Fig. 7 is the flowchart of the method for re-synchronizing a client device to be refreshed with a set of objects according to the preferred embodiment .

Step 700 is performed by the client device which reads the Current Subscriber Object Set table storing the couples (Object_ID, signature) . The client devices posts a message for instance, under the Http protocol (710) used in the Internet network, the Post message being the client request to the client-server environment. The message comprises the

'Request_refresh' command according to the format described in reference to Fig. 6. It includes the couples read in the

Current Subscriber Object Set table to the server it has subscribed and a client device unique identifier. The server reads the Subscription_table (200) and the Deal_Ob ect_table

(210) and identifies, as described in reference to Fig. 3, the objects candidate to be updated, the objects to be deleted and the objects to be added for this given client device. The server reads the signature of the first object candidate to be updated in the Object_table. If the signature is not the same than in the Request_refresh message from the client device (answer No to test 730) , then, the object is kept (740) for the refresh operation. If the signature is the same (answer Yes to test 730) , the next object is read until there is no more object candidate to be updated (answer yes to test 750), the server prepares the object list. If not (answer No to test 750), the signature of the next object candidate to be updated is checked against the signature received in the

Request_refresh (730) .

The server first builds the object list with the objects to be updated (760) . As described in reference to Fig. 4, the object list comprises for each object the Object_ID, the Object signature, the Object_length read in the Object_table and the

Object content itself as stored in the server. In the Object list, the server adds the Object_ID, the Object signature, the

Object_length read in the Object_table and the Object content for the new objects added with a change of deal or a change in a deal (770) . The triplet comprising the Object_ID, followed by a specific code to indicate an object to be deleted because of a change of deal or a change in a deal. One possibility to specify that one object is to be deleted is to put in the object list the Object_ID, and the zero value for the signature and the object length. Any other identification may be used in conjonction with the Object_ID to notify the client device that the object is to be deleted (770) . The server sends the response to the request for refresh (780) using the client-server Http protocol. The client device receives the object list and is able to read for each object the Object_ID, the Object signature, the Object_length and read the Object content using the object length to identify the end of object. With the information received, the client device updates the Current Subscriber Object Set table with the Object_ID and the corresponding signature. It deletes the object entries to be deleted and add the new object entries. Then, the content of the object themselves are replaced in its local storage with the last level sent. The server has been refreshed and re-synchronized with the objects it needed.

Claims

1. A method for re-synchronizing a client device while refreshing, from a server, objects locally stored by said client device remotely connected through a communicating means to said server which keeps track of deals subscribed by said client device, said method comprising the steps of:

- reading, in the client device, a list of data comprising an object identifier and a digest identifying an object content stored in the client device local storage; - sending from said client device a request for refresh message to said server comprising a client device identifier and the list of read data;

- reading in the server a list of objects identifiers corresponding to the deals subscribed by said client device identified by the received client device identifier;

- comparing at said server the list of data received in the request for refresh with a list of data stored by said server comprising an object identifier and a digest identifying the object content which is also stored by said server; - sending from the server a refresh answer message to the client device with a list of objects comprising, for the objects corresponding to the deals subscribed by said client device and for which the digest received is different from the digest read in the server, an object identifier, its corresponding digest and its content read in the server; receiving in the client device the refresh answer message and replacing the content of objects locally stored and the digest in the list of data of the corresponding object identifier for the objects belonging to the list of objects.

2. The method of claim 1 wherein the step for sending a refresh answer further comprises the step of:

- adding in the list of objects the object identifier, its corresponding diges.t and its content read in the server for the objects corresponding to the deals subscribed by said client device and which do not belong to the list of data of the request for refresh message.

3. The method of claim 1 or 2 wherein the step of sending a refresh answer message further comprises the step of: - for the objects which belong to the list of data of the request for refresh message and which do not correspond to the deals subscribed by said client device, adding in the list of objects the object identifier and a specific code; the step of receiving a refresh answer message further comprises the step of:

- for the objects belonging to the list of objects and having a specific code, suppressing the content of objects locally stored and the object identifier and its digest in the list of data in the client device.

4. The method of anyone of claim 1 or 3 further comprising a step of:

- receiving from at least one other server connected to said server by communication means, a new version of an object content already stored in the server; - replacing the object content already stored by the new version, computing the digest of the new version of the object and updating the digest corresponding to the object identified by the object identifier in the list of data stored in the server.

5. The method of anyone of claim 1 to 4 further comprising the step of :

- maintaining in the server a list of deals associated to a terminal identifier, said terminal identifier identifying a client device having subscribed to said associated deals; said list of deals and associated terminal identifier being used by the server to perform the step of reading a list of objects identifiers corresponding to the deals subscribed by said client device identified by the received client device identifier;

6. The method of anyone of claim 1 to 5 further comprising the step of : - maintaining in the server a list of deals associated to at least one object identifier, the associated object identifier identifying objects which are part of a deal at a given time; said list of deals and associated object identifiers being used by the server to perform the step of reading a list of objects identifiers corresponding to the deals subscribed by said client device identified by the received client device identifier;

7. The method of anyone of claim 1 to 6 further comprising a step of: - adding from the server, for each object of the list of object sent in the refresh answer message, the length of the object content before each object content, the object identifier, the digest, the object length and object content being sequentially written; and - reading, from the client device, for each object of the list of objects, the object length and using the object length to read the sequentially written object content.

8. The method of anyone of claim 1 to 7 wherein the digest is a MD5 signature.

9. The method of anyone of claim 1 to 8 wherein the communicating means are an Internet, the server and the at least one other severs are web servers and the objects form web documents .

10. A computer program product comprising programming code instructions for executing the steps of the method executed by the client device according to anyone of claims 1 to 9 when said program is executed on a computer.

11. A computer program product comprising programming code instructions for executing the steps of the method executed by the server according to anyone of claims 1 to 9 when said program is executed in a computer.

12. A computing system comprising means adapted for executing the computer program of claim 10.

13. A computing system comprising means adapted for executing the computer program of claim 11.