Browse Prior Art Database

Mechanism for Over-the-Air (OTA) Archiving and Restoring of Multiple Revisions of Data on a Mobile Device

IP.com Disclosure Number: IPCOM000131189D
Publication Date: 2005-Nov-09
Document File: 2 page(s) / 28K

Publishing Venue

The IP.com Prior Art Database

Abstract

The current over-the-air PIM sync protocol on mobile devices supports the saving of only the most recently modified data for a backup/restore database. Every time data is updated on the device, it is synced to the server and overwrites what it had previously stored. Therefore the user can only retrieve the most recently saved settings. While restoring the latest device state it is helpful in the event of significant data loss but is lacking in other respects. If the user makes a mistake, the unfortunate change will also be backed up and will overwrite the previous setting. If the user then wishes to retrieve an earlier setting that was known to be correct, he will be unable to do so. There is no mechanism to allow the user to backup a database at a known good point in time and to recover this state later. This amounts to less flexibility than the traditional serial backup/restore mechanism, in which any number of revisions can be saved for later retrieval. In addition, the user cannot manually control when databases are backed up or restored. Data is automatically backed up when records are added, updated, or deleted while the database is in the synced state, and automatically restored as part of the database initialization process occurring during activation. It is not possible to specify which databases are enabled for automatic backup/restore, and which ones are not, and the frequency of the updates sent to the server. This can result in unnecessary cost in transferring records that are not considered important enough for backup. Other mobile devices provide no facility for automatically and wirelessly backing up user data and configurations at all. Our invention allows multiple revisions of backups for each registered database to be stored on the server. Each backup is identified by a timestamp and the database version at the time of the backup. The server has a configurable limit to the number of revisions that it maintains, following a first-in-first-out order. Revisions can also be cleaned based on their age. A new backup/restore screen will be added to the UI that displays a list of all backup/restore databases. The user will have the option of viewing the backup/restore points for each database that resides on the server, the points being identified by timestamp. This information will be transmitted to the device at the time of initialization of the database, or when the user invokes a request to begin a restore process (as the information may not need to be permanently cached). The user will have the option of manually invoking a restore operation for the selected backup/restore point. In addition, the user will be able to invoke a full backup of any database at any time even if no portion of the data has been modified since the last time it was synced. This may be accomplished from the backup/restore screen, or in the application context (e.g. a menu item invoked from the same location as where the data is modified, such as an application's options screen). The user will also be able to create a backup/restore checkpoint. This involves backing up all databases at the same time, and saving the operation with a checkpoint number and a comment entered by the user to identify it. In addition to independently saved revisions, the user will be able to view all checkpoints stored on the server, and the comment associated with each. Each revision stored on the server may or may not be associated with a particular checkpoint. A checkpoint can be manually restored as a whole by the user at any time. This mechanism provides a convenient way for the user to create a collection of backed up data at a known time and easily identified for later retrieval, similar to a serial backup/restore file. The user will not be required to restore data one database at a time. As an optimization, the system checkpoint can be implemented such that only data that has changed since the last checkpoint request will be transmitted. If the data on the device matches the data present on the server, then the only information sent to the server will be the request for the checkpoint and the description. The storage on the server could also be optimized such that it would only store the change deltas between each checkpoint, rather than replicating all of the data for each checkpoint. A rollback mechanism could be used to obtain the full state at a particular checkpoint.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

OTA BACKUP/RESTORE ON

MOBILE

DEVICE

Mechanism for Over-the-Air (OTA) Archiving and Restoring of Multiple Revisions of Data on a

Mobile

Device

Disclosed Anonymously

The current over-the-air PIM sync protocol on mobile devices supports the saving of only the most recently modified data for a backup/restore database. Every time data is updated on the device, it is synced to the server and overwrites what it had previously stored. Therefore the user can only retrieve the most recently saved settings.

While restoring the latest device state it is helpful in the event of significant data loss but is lacking in other respects. If the user makes a mistake, the unfortunate change will also be backed up and will overwrite the previous setting. If the user then wishes to retrieve an earlier setting that was known to be correct, he will be unable to do so. There is no mechanism to allow the user to backup a database at a known good point in time and to recover this state later. This amounts to less flexibility than the traditional serial backup/restore mechanism, in which any number of revisions can be saved for later retrieval.

In addition, the user cannot manually control when databases are backed up or restored. Data is automatically backed up when records are added, updated, or deleted while the database is in the synced state, and automatically restored as part of the database initialization process occurring during activation. It is not possible to specify which databases are enabled for automatic backup/restore, and which ones are not, and the frequency of the updates sent to the server. This can result in unnecessary cost in transferring records that are not considered important enough for backup.

Other mobile devices provide no facility for automatically and wirelessly backing up user data and configurations at all.

Our invention allows multiple revisions of backups for each registered database to be stored on the server. Each backup is identified by a timestamp and the database version at the time of the backup. The server has a configurable limit to the number of revisions that it maintains, following a first-in-first-out order. Revisions can also be cleaned based on their age.

A new backup/restore screen will be added to the UI that displays a list of all backup/restore databases. The user will have the option of viewing the back...