GB2452534A

GB2452534A - Database updates in mobile radio communications device stored in a removable memory device

Info

Publication number: GB2452534A
Application number: GB0717406A
Authority: GB
Inventors: Olivier Dong
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2007-09-07
Filing date: 2007-09-07
Publication date: 2009-03-11
Also published as: GB0717406D0

Abstract

The present invention provides a method of updating a database within a mobile radio communications device and including the steps of inputting data to alter the database, generating a database identifier to distinguish uniquely the altered version of the database independently of the number of database records altered by the input data, generating records, referenced by record identifiers and stored in an update history entity, which include database record numbers altered for each respective database version and generating status data comprising the current database identifier and its associated record identifier in the update history entity; such that the said identifiers can be employed in subsequent database synchronisation. The data serving to alter the database and the identified status data are stored in a removable memory device such as a memory card or UICC. Furthermore, partial synchronization can be performed.

Description

I)ATABASE UPDATES IN MOBILE RADIO

COMMUNICATIONS DEVICE

The present invention relates to a method of updating a database within a mobile radio communications device and to such a mobile radio communications device having the functionality for such updating.

Mobile radio communications devices such as cell phone handsets can commonly include a variety of database arrangements one of which is commonly referred to as its "phonebook" or address book"; such terminology being used interchangeably throughout this application. I lere, contact information is stored so as to ease the manner in which the handset user can contact a target individual and/or identify which of its known targets listed in the address book might be responsible for an incoming call.

Since such an address book commonly comprises a database of personal contact details, such details are prone to change with time such that the address book database will require revision so as to keep up to date.

Also, as and when new entries are required for the address book, or indeed current cntries are to be deleted, the address book database can likewise require updating.

While the procedure in'volved in updating the address book. of a particular handset does not in itself present any particular problems and/or performance Umitations, this may not be the case in situations where a user owns a variety of handsets and/or communication terminals such that a plurality of those devices will require updating so that the address book entries of all the devices remain up to date and the same.

A known procedure of address-book-synchronisation has been developed whereby different address books of respective different devices can effectively be synchronised such that their content remains the same. In this manner, it is then necessary for the user only to update one of the address book databases, and the updated address book can then be copied to the each of the other devices owned by that user by way of a wired, or wireless, connection as appropriate.

For example, and within the 3G environment, the 3G USIM phonebook as defined and in accordance with 3GPP TS 31.102. includes a data synchronisation mechanism which provides for so-called "au or nothing" data synchronisation. That is, a USIM phonebook which is synchronised to a first handset, and which is then modified with any appropriate number of changes by way of a second handset, can then be fully copied into the first handset when a Universal Integrated Circuit Card (UICC) on which the phonebook stored is next reintroduced into the first handset.

Thus, while the revised entries of the USIM phonebook arc copied into the first handset, those entries which have not changed and which effectively do not need updating within the first handset are also replaced by the entries found in the UICC.

Such an aIl or nothing" approach to the synchronisation of known USIM phonebook databases exhibit potential disadvantages and limitations insothr as copying of the complete phonebook database is required.

With the ongoing development and functionality of mobile radio communication device databases having ever larger potential capacities, phonebook/address book databases with a significantly increased potential for data storage will be available.

However the cmployment olan "all or nothing" synchronisation mechanism is likely to be considered unacceptable due, in particular. to the time that might be required for synchronisation of the database details. That is, full synchronisation of such larger databases can prove disadvantageously time-consuming. While this can prove problematic in itself, it can also lead to operation limitations insofar as the phonebookladdrcss book will not be available during such periods of synchronisation.

Also. some of the currently defined Elementary Files (EF) which are provided for LISIM phonebook synchronisation purposes will only prove efficient for full synchronisation and this further prevents the current "all or nothing approach" being simply adapted to a partial synchronisation approach.

Also, to ensure accurate and full synchronisation. earlier 3G specifications such as. for example, 1'S 31.102, explicitly require that a full synchronisation procedure should be performed upon insertion of an UICC into a 3G terminal and that had previously been updated by way of a 20 terminal.

The present invention therefore seeks to provide for a method of updating database information within a mobile radio communications device, and to such a mobile radio communications device, having advantages over known such methods and devices.

According to a first aspect of the present invention there is provided a method of updating a database within a mobile radio communications device and including the steps of: inputting data to alter the database; generating a database identifier to distinguish uniquely the altered version of the database independently of the number of database records altered by the input data; generating a record, referenced by a record identifier, identifying the database records altered for each respective database version: generating status data comprising the current database identifier and the associated record identifier: such that the said identifiers can be employed in subsequent database synchronisation.

The invention advantageously allows for reliable and efficient partial synchronisation so that only the amended entries. i.e. those entries that are not consistent between two versions of the database, are updated within the database requiring alteration.

Then the time taken to fully synchronise the databases is dependent only upon the number of database records requiring updating, and so is independent of the overall size of the database.

The method can further include the step of storing, in an update history entity. the record as referenced by the record identifier.

The partial-synchronisation of the present invention therefore serves to enhance the efficiency within which database synchronisation can be achieved.

Through the various identifiers employed within the present invention, the terminal having a database requiring updating can readily be arranged to retrieve only the modified database entries within the database from which the data is being copied.

In accordance with OflC aspect of the present invention, a database identifier is generated for each database session defined between each power-up and power-down and independent of the nature of any amendments made during that session.

Advantageously, the data serving to alter the database, and the aforesaid identified status data can be stored to a movable memory device.

In particular the movable memory device can be imparted with a specific identifier so as to differentiate between separate such devices.

Of course, it will be appreciated that the movable memory device can comprise a memory' card or a UICC.

It will be appreciated that the database can comprise a phonebook, or address book. for use in relation to the mobile radio communications device.

According to another aspect of the present invention there is provided a method of synchronising databases in a mobile radio communications device by way of a database updated in accordance with the method defined above, and including the steps of updating the database on the basis only of the said altered records.

The invention advantageously allows for reliable and efficient partial synchronisation so that only the amended entries, i.e. those entries that are not consistent between two versions of the database, are updated within the database requiring alteration.

Again, the time taken to fully synchronise the databases is then advantageously dependent only upon the number of database records requiring updating, rather than the overall size of the database.

Again, it should be appreciated that the database can comprise a phonebook, or address book, for use in relation to the mobile radio communications device.

According to a further aspect of the present invention, there is provided a mobile radio communications device having an updatable database therein and including means for inputing data to alter the said database, means for generating a database identifier serving to distinguish uniquely the altered version of the database independently of the number of database records altered by the input data, means for producing a record, as referenced by a record identifier, identifying the database records altered for each respective database version, means for generating status data comprising the current database identifier and its associated record identifier, and arranged to employ the said identifiers for database synchronisation.

The partial-synchronisation available in the device of the present invention therefore serves to enhance the efficiency within which database synchronisation can be achieved.

Through the various identifiers employed within the present invention, the device having a database requiring updating can readily be arranged to retrieve only the modified database entries within the database from which the data is being copied.

The device can also include an update history entity in which the records as referenced by the record identifier are stored.

Within one aspect of the present invention, a database identifier is generated for each database session extending from power-up for use and power-down of the device and independent of the nature of any amendments made during that session.

The device can be provided with a movable memory device within which the data serving to alter the database, and the aforesaid identified status data can be stored.

As with the method defined above, it will be appreciated that the movable memory device can comprise a memory card or a UICC.

According to yet another aspect of the present invention there is provided a mobile radio communications device having an updatable database and arranged for synchronisation with a revised version of the database, the device including means for comparing database identifiers of both databases wherein each database identifier serves to distinguish uniquely the altered version of the database independently of the number of database records altered within the said revised version, means for reading a record serving to identify altered records of each database version, means for reading status data serving to identify the current database identifier and its associated record identifier, and the device being further arranged to partially update the database only on the basis of altered records in the said revised version of the database and as determined by the said means for comparing the database identifiers and the means for reading the record and status data.

Again, the invention advantageously allows for reliable and efficient partial synchronisation so that only the amended entries, i.e. those entries that are not consistent between two versions of the database, are updated within the database requiring alteration.

Efficient synchronisation can then be achieved within the device since the time taken to fully synchronise the database is dependent only upon the number of database records requiring updating, and so is independent of the overall size of the database.

Also, the device can include an update history entity in which the said associated record identifier is stored.

The partial-synchronisation of the present invention therefore serves to enhance the efficiency within which database synchronisation can be achieved and which is particularly useful for cell phone address/phone-books.

Through the various identifiers employed within the present invention, the device having a database requiring updating can readily be arranged to only retrieve the modified database entries within the database from which the data is being copied.

Advantageously, the device can be arranged to receive a movable memory device carrying the data serving to alter the database, and the aforesaid identified status data.

According to still another aspect of the present invention, there is provided a mobile radio communication device memory device arranged for removable insertion therein and adapted to store an updatable database and also to store: a database identifier serving to distinguish uniquely an altered version of the database independently of the number of database records altered; a record identifier of the database records altered for each respective database version; and status data comprising identification of the current database identifier and its associated record identifier.

Of course, it ill be appreciated that the removable memory device can comprise a memory card such as that provided by way of a U ICC.

The invention is described further hereinafter, by way example only, with reference to the accompanying drawings in which: Fig I is a schematic representation of a cell phone handset adapted for use in accordance with a method embodying the present invention; Fig. 2 is a similar view to that of Fig. I of a further handset used in relation to an embodiment of the method of the present invention; Fig. 3 is a further view of the handset of Fig. 1 and as nearing the end of database synchronisation procedure according to an embodiment of the present invention; Fig. 4 is a signalling diagram illustrative of an embodiment of the present invention in relation to two cell phone handsets both supporting partial synchronisation; and Fig. 5 is a similar signalling diagram to that of Fig. 4 but for a scenario in which one of the handset terminals does not support partial synchronisation.

Under usual operating conditions, a mobile radio communications device such as a cell phone handset, will make a local copy of the USIM phonebook data downloaded from the UICC in its own non-volatile memory in order to speed-up user operation.

Since the relevant data can be retrieved far quicker from such non-volatile memory than it can from the UECC.

Each time a phonebook entry is updated by the user. the handset is arranged to update the entry data both in its own non-volatile memory and in the VICC inserted therein and in order to keep the data consistent.

However, once we remove the UICC from the first handset, and update one or more of the phonebook entries using a second handset, the phonebook data in the UICC and in the non-volatile memory of the first handset are then no longer the same.

When the first handset is then again required for use, the UICC is again inserted into the first handset. However, since the data on the UICC and within the first handset are no longer consistent, a mechanism is required that allows the first handset to re-establish data consistency with the UICC. This is the currently known mechanism of phonebook synchronisation.

From current 3GPP TS 31.102 specifications, the IJICC may contain a global phonebook, or application specific phonebooks. or both in parallel. A global phonebook can be commonly used by several applications (GSM, USIM,...) whereas the application specific phonehook can he only used by the associated application (LISIM, ISIM,...). Whilst most of the currently available 3G UICC comprise "dual" cards, i.e. supporting both GSM/USIM applications, and therefore, the global phonebook is used in these cards, the term "phonebook" or "address book" is employed herein to apply primarily to a global phonebook although it should be appreciated that the present invention is equally applicable to an application specific phonebook.

The limitations of the current art, and as addressed by the present invention, are best illustrated by the following example. the operation of two cell phone handsets, at least a first of which is a 3G handset, and a UICC including a USIM phonebook and user data.

Initially, the first handset powers-up with the UICC loaded therein and it is assumed that this is the first time that the UICC has been inserted in this handset.

Next, the content of the USIM phonebook is fully copied into the first handset.

The UICC is then removed from the first handset and is inserted into the second handset.

One or several phonebook entries are then modified by the user by way of the second handset, and the UICC is removed from the second handset and inserted back into the first handset.

The first handset detects that the phonebook has been updated and therefore that the phonebook data previously saved in the first handset is no longer consistent with the data in the current phonebook (in the UICC) now.

In accordance with the current art, the first handset will re-synchronise fully the USIM phonebook data, i.e. the first handset will make a full copy of the phonebook data contained in the UICC into its non-volatile memory.

Such full synchronisation is potentially time-consuming, and is likely to become increasingly so and access to the phonebook is not available during that time, which can prove particular problematic for the user.

Also, it is known from TS 31.102. of the 3GPP that some currently defined Elementary Files (EF), such as EF CC. EF IJID, EF PBC. EF PSC, which are dedicated to the USIM phonebook synchronisation purpose, are only efficient for a full synchronisation.

Accurate partial-synchronisation based on the data contained in these EFs is therefore not currently available.

Although such currently defined EFs in the USIM phonebook could partially allow tbr partial synchronisation in some very specific-use cases interoperability between different UICCs/MEs can not be guaranteed if such partial synchronisation were to be attempted and so. for certainty, handsets simply support the current full synchronisation mechanism.

Yet further, in a scenario in which the phonebook is updated using a 2G Terminal.

which could be the second handset in the above example the requirements of the Ts 3 1.102 specification explicitly state that a full synchronisation should be performed when the UICC is inserted back into a 3G Terminal supporting the phonebook synchronisation.

Since future phonebooks will be designed to support a larger amount of data, such as aIl or nothing" approach to synchronisation will become increasingly inefficient.

In addressing such limitations, an important aspect of the invention is that each phonebook entry is identified using a unique identifier (e.g. a record identifier) although the manner in which such entries are stored in the UICC handset is not relevant to the present invention.

As will he described further below with reference to the accompanying drawings. the invention employs a unique Phonebook Version Identifier (PVI) per session (a session is the time period between the application (e.g. 3G USIM) activation and deactivation).

The handset will generate a unique identifier (e.g. an integer) if there is any update on any phonebook entry during a session. I his unique identifier is then also saved in the UICC and is independent of the number of phonebook entries.

At power-up. the handset reads from the UICC that the current PVI is, for example, 20.

During the application session, the phonebook is updated with amended, new or deleted entries and the handset then generates a new PVI 21 for example, and saves this identifier in both the UICC and within its non-volatile memory. As noted above, only one new identifier is needed irrespective of the number of changes made during the session.

The invention also provides for an entity to store the update history for each PVI.

In particular, this entity could be made up of records, each of which contains the following information: -a number which uniquely identify the record -the PVI -the identifiers of phonebook entries which have been amended between the current and the previous phonebook versions.

Further, a separate entity for the storage of the current phonebook status information and which can comprise: -PvI -the associated record number in the update history storage entity.

This further entity serves to indicate the current phonebook version and the location from where the handset could retrieve the changed entries numbers (changes made between the current and previous versions of the phonebook).

There now follows a function description to illustrate one embodiment of the present invention in relation to two 30 handsets.

It is based on a UICC including a phonebook with 10 entries, a current PVI of 5.

an update history storage entity including 30 records, and with the updating information for the current phonebook version stored in record 20.

En this example, it is assumed that the user then inserts this UICC in a newly bought handset A. The handset A first copies the full contents of the phonebook from the UICC into its own non-volatile memory, and then reads data from the current phonebook status entity and saves this in its memory.

At this stage, the phonebook data is fully synchronised between the handset A and the UICC.

The user then removes the UICC from handset A and inserts it into a handset B. Handset B could start a synchronisation process, but this is not relevant to the current

example.

The user updates entry numbers 2 and 5 of the phonebook using handset B and in turn handset B updates the update history storage entity by adding in record 21 the new PVI which is 6, and the updated entries numbers, i.e. 2 and 5. Also, the current phonebook status storage entity is updated by adding the PVI, which is 6, and the corresponding record number in the update history storage entity which is 21.

The user removes the UICC from handset B and re-inserts it into handset A, which handset tirst checks whether the inserted UICC is the same as the previously used one in this handset by checking the ICCID (which is unique to each UICC), then reads data from the current phonebook status storage entity and so determines that the PVI, which is now 6, is different from the earlier saved value, i.e. 5.

Through use of the information read from the current phonebook status storage entity, i.e. the record number 21 in the update history storage entity associated to the current PVI. the handset A is able to retrieve the updated entry numbers between the version 5 and 6, that is, entries 2 and 5.

Handset A can then read then entries 2 and 5 in the UICC and save the data in its non-volatile memory. It also updates the PVE found in its memory.

In an alternative scenario with handset B comprising a 2G handset, the changes in the update history storage entity and the current phonebook status storage entity must be carried out internally by the UICC. The UICC arranged to support this partial synchronisation feature can determine whether or not the handset supports partial synchronisation, e.g. by checking the access to the relevant EFs for example or through a Handset Capability" command sent by the handset to the 131CC during the power-on sequences.

Turning now to Figs. 1-3, an example of the operation of the present invention is provided in relation to two cell phone handsets illustrated.

Turning first therefore to Fig. 1 there is provided a schematic representation of a ccli phone handset 10 having a 131CC 12 inserted therein, and which includes an initial tJSIM phonebook data set 14.

This data set is transferred by way of data synchronisation signalling 16 to a memory area 18 of the handset 10 so as to effectively load the initial USIM phonebook data set into a fast-access memory portion of the handset 10.

Within the illustration of Fig. 1, the handset 10 also includes a ME phonebook application/data 20 and although this does not necessarily impinge on the present invention.

The owner/user of handset 10 also comprises the owner/user of another cell phone handset 22 which is illustrated with reference to Fig. 2.

In order to employ the initial USIM phonebook data set of the UICC 12 of handset 10 of Fig. I. within the handset 22 of Fig. 2. the 111CC 12 is removed from handset 10 and inserted into handset 22 as illustrated in Fig. 2. It is then assumed that some form of updating is conducted in relation to the phonebook data set such as through the amendment of an entry or the addition of new entry or the removal of a current entry and so updated data, is loaded both as new data 24 within the UICC 12 and, through data transfer 26, as new data set 28 within the fast-access memory of the handset 22.

1-landset 22 can optionally include ME phonebook application/data 30.

Flaying updated the phonebook data within the handset 22, the user may then require that the updated phonebook be employed within their original handset 10 and so the U ICC 12 is removed from the handset 22 and returned the handset 10 as illustrated in Fig. 3.

By means of the present invention, only the amended/updated parts of the database will be copied from the UICC 12 into the handset 10 such that, with reference to Fig. 3.

only the updated data of new data set 24 found within the 111CC 12 is by way of partial synchronisation data transfer 32, delivery to the fast-access memory region 18 of the handset 10.

Such functionality of the present invention is illustrated further with reference to the signalling diagrams of Figs. 4 and 5.

Turning first to Fig. 4. there is provided a illustration of signalling and data exchanges arising between the handsets 10, 22 of Figs. 1-3 and on the assumption that both terminals support the partial synchronisation of the present invention.

Fig. 4 also illustrates the UICC 12 which again supporting partial synchronisation, is transferred between the two handsets 10, 22.

The signalling commences at power-up 34 with the handset 10 conducting its power-up sequence and it is assumed that this is the first time that the UICC 12 has been employed within handset 10. On this basis, the handset 10 will read all of the phonebook data from the UICC 12.

The handset 10 then sends commands 36 to read the USIM phonebook data, elementary file by elementary file, and record by record, for each elementary file. As illustrated by the signalling 38, the UICC 12 then sends the USIM phonebook data to the handset 10 and, with the power-up completed at 40, handset 10 has read and saved the USIM phonebook in its non-volatile memory and it is assumed that UICC is now removed from the handset 10 and inserted into handset 22.

The handset 22 can then send signalling 42 to the UICC 12 indicating that the partial synchronisation of the present invention is supported and, if the handset 22 is not already synchronised with the UICC 12, then a signalling exchange 44, 46 occurs between the handset 22 and the UICC 12 requesting, and subsequently receiving, the USIM phonebook data.

As illustrated in Fig. 4, if the handset is already synchronised with the UICC 12 then this latter data exchange 44, 46 is not required.

Handset 22 is employed to update one or more entries within the USIM phonebook by way of signalling 48. and, by the signalling 50 the handset 22 serves to upda te the relevant elementary files containing the change history data as discussed further below.

It is then assumed that the UICC 12 might be removed from the handset 22 and reinserted back into handset 10 at step 52.

At step 54. handset 10 is arranged to check the identification of the LJJCC 12 so as to identify that is the one previously used. It then embarks on a signalling exchange 56, 58 with the [11CC 12 so as to retrieve the phonebook change-history data and through consideration of which at 60 the handset 10 can determine that the version has changed so as to then initiate a signalling exchange 62. 64 so as to retrieve the changed data.

Turning now to Fig. 5. there is illustrated a signalling diagram similar to that of Fig. 4 for exchanges between handset 10. handset 22 and related UICC 12 but in this example, the handset 22 does not support partial synchronisation of the present invention.

The handset 10 conducts a power-up sequence as indicated at step 34 on the signalling exchange 36, 38 which sequence is completed at step 72 and with the handset 10 having read and saved the USIM phonebook data in its non-volatile memory.

With the UICC 12 now removed from handset 10 and inserted into handset 22 as illustrated at 72. the handset 22 enters a signalling exchange 74, 76 with the UICC 12 for the reading and receipt of the IJSIM phonebook data.

Again, and as illustrated in Fig. 5, the signalling exchange 74. 76 can be omitted in the situation at handset 22 comprising a 3G Terminal already synchronised with the UICC 12.

Then, by way of signalling 78 the handset 22 updates one or several records within the USIM phonebook of the UICC 12. However, since it has been identified that the handset 22 does not support the partial synchronisation of the present invention, the UICC 12 will update directly the relevant elementary files relating to the change in history data internally each time a record is updated.

At the next stage 82. the UICC 12 is removed from the handset 22 and returned to handset 10.

At step 84 it is recognised that the UICC 12 inserted into the handset 10 is the same as previously inserted and a signalling exchange 86, 88 commences with the UICC 12 by which the handset 10 can determined whether or not the phonebook comprises an updated version.

If, at step 90, it is determined that the phonebook does in fact comprise an updated version, then the signalling exchange 92, 94 is executed between the handset 10 and the UICC 12 so as to allow for partial synchronisation in relation to the changed records only.

A further detailed example of implementation of the invention follows and with initial condition as illustrated below in Table 1.

Table 1

Record number (this is Phonebook version -Updated entries Identifier UICC internal field) identifier _________________________ 8;9;15; 2 2 5;7;12 3 3 8 4 4 5;6;9;10;12;15;30: For the UICC, data will be saved in Elementary Files (EF) of which the following will be provided.

EF PbkUpd: This EF is made up with cyclic records (the current innovation does not put any constraint on the number of records in this EF).

Referring back to Table 1, the current phonebook version is 5. The changed entries between versions 4 and 5 are: 8. 9 and 15.

Also, there is a total of four records in this EF and if the latest update data are stored in the last record (record 4), the next one would be stored in the first record by way of a cyclic storage mechanism.

EF PbkMgt: This EF will include the current Phonebook version number and the associated record number in the EF PbkUpd, i.e.: current version being 5. record number being 1 in the

example above.

Also, both handsets should have in their context/memory the Iccld of the last user UICC. and the associated latest PVE.

If the Iccld currently saved in the handset and the Iccld of the inserted UICC are different (i.e. the current UECC is different from the previous one used in this handset), then a full synchronisation is required.

With handset A powered-up with the UICC including the phonebook data described above, the following is a scenario in which the inserted UICC is different from the previous UICC used in that handset. So, at this stage, the handset A will just perform a full synchronization, i.e.: - read all phonebook data (e.g. using "READ RECORD" APDU command) from the [JICC and store them into handset A (into the non-volatile memory) -update the current PVE (5) in handset A (saved in the non-volatile memory) -store the Iccid of this new UICC in handset A. The UICC is then removed from handset A and inserted into handset B and it can be assumed that handset B will also initially perform a full synchronisation (e.g. first time the UICC is inserted in handset B. Once completed, the user can update phonebook entry numbers 7, 8 and 10.

As will he appreciated, handset B will then: -update data in the entries indicated above in both handset B (update the non-volatile memory) and UICC (e.g. using the "UPDATE RECORD" APDU command) -update the current PVI in handset B, e.g. previous version + 1. which in this example will be 6.

-update the EF PbkUpd by adding the updated entry numbers and the current PVI in record 2 in this example. This record data could be coded in the TLV (Tag, Length, Value) format (the values are given as

examples):

Tag Phonebook Version Identifier = OxA 1.

Length 0x0002 (i.e. the following Value parameter is coded on 2 bytes) Value = 0x0006.

Tag Updated Entries = OxA2 Length: 0x0006 Value: 073B083B0A3B (we consider that 7;8; 10 are coded as a text string with a separator between each number. 3B is the ASCII code of";") From this example, record 2 in EF PbkUpd will contain: Al 00020006073B83 BOA3B -update the EF PbkMgt in the UICC (e.g. using "UPDATE BINARY" APDU command): Phonebook Version Identifier = 6, record number in EF PbkUpd =2.

Afier these updates, the UICC is removed from handset B. The UICC is then re-inserted back into handset A. and upon power-up, handset A will detect that the UICC is the same as that previously used (by reading the EF Iccid). It will also read the EF PbkMgt (using READ RECORD" APDU command) which contain 6 as PVI and 2 as the associated record number in EF PbkUpd.

Since the previous PVI saved in handset A was 5, this handset A will read the corresponding record (2) in EF PbkUpd (using "READ RECORD" APDU command) and retrieve the numbers of the entries which have been updated.

Thus it will be appreciated that handset A has successfully re-synchronised the phonebook data by selecting only the updated phonebook entries.

Claims

CLAIMS: 1. A method of updating a database within a mobile radio communications device and including the steps of: inputting data to alter the database; generating a database identifier to distinguish uniquely the altered version of the database independently of the number of database records altered by the input data: generating a record, referenced by a record identifier, identifying the database records altered for each respective database version: generating status data comprising the current database identifier and the associated record identifier; such that the said identifiers can be employed in subsequent database synchronisation.
2. A method as claimed in Claim 1, wherein a database identifier is generated for each database session between each power-up and power-down, and independent of the nature of any amendments made during that session.
3. A method as claimed in Claim 1 or 2, wherein the data serving to alter the database, and the said identified status data, are stored in a removable memory device.
4. A method as claimed in Claim 3, wherein the memory device is provided with a specific identifier so as to differentiate between separate such devices.
5. A method as claimed in Claim 3 or 4, wherein the memory device comprises a memory card or a UICC.
6. A method as claimed in any one or more of the preceding claims, and including the step of storing, in an update history entity, the record as referenced by the record identifier.
7. A method of synchronising databases in a mobile radio communications device by way of a database updated in accordance with the method of any one or more of the preceding claims and including the steps of updating the database on the basis only of the said altered records and as identified by reference to the said database identifier, record identifier and said status data.
8. A mobile radio communications device having an updatable database therein and including means for inputing data to alter the said database, means for generating a database identifier serving to distinguish uniquely the altered version of the database independently of the number of database records altered by the input data, means for producing a record, as referenced by a record identifier, identifying the database records altered for each respective database version, means for generating status data comprising the current database identifier and its associated record identifier, and arranged to employ the said identifiers for database synchronisation.
9. A mobile radio communications device having an updatable database and arranged for synchronisation with a revised version of the database, the device including means for comparing database identifiers of both databases wherein each database identifier serves to distinguish uniquely the altered version of the database independently of the number of database records altered within the said revised version, means for reading a record identifier serving to identify altered records of each database version, means for reading status data serving to identify the current database identifier and its associated record identifier, and the device being further arranged to partially update the database only on the basis of altered records in the said revised version of the database and as determined by the said means for comparing the database identifiers and the means for reading the record identifier and status data.
10. A mobile radio communications device as claimed in Claim 8 or 9, wherein the data serving to alter the database, and the said identified status data are stored in a removable memory device.
11. A mobile radio communications device as claimed in Claim 10, wherein the removable memory device is provided with a specific identifier so as to differentiate between separate such devices.
12. A mobile radio communications device as claimed in Claim 8. 9. 10 or 11, and including an update history entity in which the said associated record identifier is stored.
13. A mobile radio communications device as claimed in Claim 12 wherein each record in the update history entity includes a record number so as to differentiate it from other records.
14. A mobile radio communications device as claimed in Claim 13. wherein the said status data comprises the current database identifier and the said record identifier in the update history entity.
15. A mobile radio communication device memory device adapted for removable insertion within a communications device and adapted to store an updatable database and a database identifier serving to distinguish uniquely an altered version of the database independently of the number of database records altered; a record identifier of the database records altered for each respective database version; and status data comprising identification of the current database identifier and its associated record identifier.
16. A memory device as claimed in Claim 15 and comprising a memory card or a UICC.
17. A method of updating a database within a mobile radio communications device substantially as hereinbefore described with reference to, and as illustrated in. the accompanying drawings.
18. A method of synchronising databases herein a mobile radio communications device substantially as hereinbefore described with reference to, and as illustrated in, the accompanying drawings.
19. A mobile radio communications device substantially as hereinbefore described with reference to the accompanying drawings.
20. A removable memory device for a mobile radio communications device and substantially as hereinbefore described with reference to the accompanying drawings.