WO2017060706A1 - Synchronisation of communications contacts between devices - Google Patents

Synchronisation of communications contacts between devices Download PDF

Info

Publication number
WO2017060706A1
WO2017060706A1 PCT/GB2016/053109 GB2016053109W WO2017060706A1 WO 2017060706 A1 WO2017060706 A1 WO 2017060706A1 GB 2016053109 W GB2016053109 W GB 2016053109W WO 2017060706 A1 WO2017060706 A1 WO 2017060706A1
Authority
WO
WIPO (PCT)
Prior art keywords
contact information
format
devices
data objects
message store
Prior art date
Application number
PCT/GB2016/053109
Other languages
French (fr)
Inventor
Phillip Carter
James Irwin
Oscar Gallego
Ioanna CHATZICHARISTOU
Original Assignee
Vodafone Ip Licensing Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone Ip Licensing Limited filed Critical Vodafone Ip Licensing Limited
Publication of WO2017060706A1 publication Critical patent/WO2017060706A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • IP Internet Protocol
  • contact information is synchronized across a plurality of devices using a message synchronization system.
  • the contact information is transformed or encapsulated into a data object format used by the message synchronization system, and then sent to the message synchronization system for storage in the message store.
  • the message synchronization system is then used to synchronize the contact information data objects stored in the message store across the plurality of devices.
  • a first aspect provides a method of synchronizing contact information for use in Internet Protocol "IP" communications across a plurality of devices, the method comprising: providing contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices.
  • IP Internet Protocol
  • a second aspect provides a contact synchronization system arranged to synchronize contact information in Internet Protocol "IP" communications across a plurality of devices, the system comprising a message store, and the system being arranged to: provide contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; store the contact information data objects in the message store; and synchronize the contact information data objects stored in the message store across the plurality of devices.
  • IP Internet Protocol
  • a third aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising: receiving contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices by sending the contact information data objects to the plurality of devices.
  • IP Internet Protocol
  • a fourth aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising, at one of the plurality of devices: producing contact information as a plurality of data objects in a second format, and converting the data objects in the second format into contact information data objects in a first format; and sending the plurality of contact information data objects to a message store of a message synchronization system.
  • IP Internet Protocol
  • a fifth aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising, at one of the plurality of devices: receiving a contact information data object from a message store, the contact information data object being in a first format of a data object of the message store; and converting the contact information data object in the first format into at least one data object in a second format.
  • IP Internet Protocol
  • a sixth aspect provides computer software comprising a series of instructions which , when executed on a processor, will cause the processor to carry out the method according to any one of the third to fifth aspects.
  • a seventh aspect provides tangible computer-readable storage comprising computer- readable instructions which, when executed on a processor of a computer will cause the computer to carry out the method according to any one of the third to fifth aspects.
  • the methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium.
  • tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals.
  • the software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
  • firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
  • HDL hardware description language
  • Figure 1 is a schematic diagram of a communications system according to a first embodiment
  • Figure 2 is a schematic diagram of a central message store of the system of figure 1 ;
  • Figure 3 is a flow diagram of a method for synchronizing contacts which may be used by the system of figure 1 ;
  • Figure 4 is a flow diagram of a further method for synchronizing contacts which may be used by the system of figure 1 ;
  • Figure 5 is a flow diagram of a still further method for synchronizing contacts which may be used by the system of figure 1 .
  • Common reference numerals are used throughout the figures to indicate similar features.
  • Figure 1 illustrates a communications system providing synchronization of messages and contacts between different devices according to a first embodiment of the present invention.
  • a telecommunications network 1 is shown.
  • the telecommunications network 1 supports IP communications, in the illustrated example Rich Communications Services (RCS) telecommunications services, and is operated by a network operator.
  • the telecommunications network 1 can be accessed by user devices 2, which may include multiple user devices 2 associated with the same user.
  • user devices 2a-2c associated with a common single user are shown, specifically a mobile phone 2a, a tablet 2b and a laptop computer 2c.
  • the telecommunications network 1 is shown schematically in figure 1 and only parts of the telecommunications network 1 which are required to allow the present invention to be understood are shown. It will be understood that the telecommunications network 1 will in practice comprise a very large number of other components, but these are not described or shown to improve clarity and to avoid obscuring the scope of the present invention.
  • the telecommunications network 1 comprises a message synchronization system 3 arranged to synchronize messages between and across the different user devices 2a-2c of the user.
  • the message synchronization system 3 comprises a central message store 4 in which all of the user's messages are stored.
  • the message synchronization system 3 may be a Converged IP Messaging (CPM) system operating according to the Internet Mail Access Protocol V4 (IMAP4).
  • CCM Converged IP Messaging
  • IMAP4 Internet Mail Access Protocol
  • the CPM message synchronization system 3 provides copies of user messages stored in the central message store 4 to the user devices 2a-2c as necessary to maintain message synchronization between the different user devices 2a-2c.
  • the messages are stored in the central message store 4 acting as a server, and the messages can be accessed from any of the user devices 2a-2c, which act as clients.
  • the central message store 4 is also used to store contact information relating to user contacts.
  • An example of a central message store 4 arranged to store contact information relating to user contacts is shown in FIG. 2.
  • the central message store 4 is structured to comprise a number of separate storage regions or areas 4a to 4e.
  • the central message store 4 comprises three top level storage regions 4a to 4c, comprising an RCS message store 4a, a system default, or "Inbox" message store 4b, and a deleted message store 4c.
  • the central message store 4 further comprises two mid-level storage regions 4d and 4e, comprising a favorites message store 4d and an address book store 4e.
  • the mid-level storage regions of the favorites message store 4d and the address book store 4e are arranged in a hierarchical manner as sub-regions of the RCS message store 4a.
  • the central message store 4 further comprises two low level storage regions 4f and 4g, comprising a jSon store 4f and a contact store 4g.
  • the low level storage regions of the jSon store 4f and the contact store 4g are arranged in a hierarchical manner as sub-regions of the address book store 4e
  • the storage regions 4a to 4d according to the illustrated first embodiment correspond to the arrangement of a central message store of a CPM system.
  • the address book store 4e, jSon store 4f and contact store 4g are added by the present disclosure.
  • one of the user's different user devices 2a-2c is identified as a primary user device.
  • the user's mobile phone 2a is identified as the primary user device.
  • the identification of a particular user communication device 2a-2c as the primary user device may be carried out automatically by the telecommunications network 1 .
  • this identification may be based on a comparison of the characteristics or parameters of the different user communication devices 2a-2c associated with the user for connection to the telecommunications network 1 .
  • this identification may be based upon the order in which the different user communication devices 2a-2c are registered for access to the telecommunications network 1 , for example the first communications device 2a-2c registered for access to the telecommunications network 1 may be regarded as the primary user device.
  • the user may select which user communication device 2a-2c is to be the primary user device.
  • the primary user device 2a executes a contact synchronization method 300 which will now be described with reference to figure 3.
  • the contact synchronization method 300 starts with the primary user device 2a identifying a new contact in a step 301 .
  • the primary user device 2a transforms the contact information of the identified contact into a stand-alone media object in a step 302.
  • This transformation step 302 transforms or converts the contact information into an object matching the format for a standalone media object specified by CPM.
  • This transformation step may be regarded as encapsulating the contact information within a stand-alone media object or a stand-alone media object shell.
  • the primary user device 2a sends the stand-alone media object comprising the contact information of the new identified contact to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the contact store 4g, and updates a master file to identify the location of the stand-alone media object comprising the contact data of the new identified contact, in a step 303.
  • the primary user device 2a checks whether there are further new contacts awaiting processing in a step 304. If there are further new contacts the method 300 returns to step 301 . Alternatively, if there are no further new contacts, the method 300 proceeds to step 305. [0042] When there are no further new contacts the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact data into a stand-alone media object in a step 305. This transformation step 305 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM, in a similar manner to the transformation step 302. This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell.
  • the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 306.
  • the method 300 ends in a step 307.
  • the central message store 4 When the central message store 4 receives a stand-alone media object comprising contact information from the primary user device 2a, the central message store 4 stores this stand-alone media object in the contact store 4g of the address book store 4e, as instructed by the primary user device 2a.
  • the central message store 4 receives a stand-alone media object comprising the master file from the primary user device 2a, the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a.
  • the stand-alone media object comprising contact information or the master file matches the format for a stand-alone media object specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media object comprising contact information or the master file using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects.
  • the stand-alone media object comprises contact information comprising the contact information itself and when stand-alone media object comprises contact information comprising the master file.
  • a method similar to that described above for new contacts with reference to figure 3 may also be used when the contact information relating to a contact is changed, for example when the contact information is updated or edited.
  • the primary user device 2a executes a contact synchronization method 400 which will now be described with reference to figure 4.
  • the contact synchronization method 400 starts with the primary user device 2a identifying a changed contact including changed information in a step 401 .
  • the primary user device 2a transforms the contact information of the identified changed contact into a stand-alone media object in a step 402.
  • This transformation step 402 transforms or converts the changed contact information into an object matching the format for a stand-alone media object specified by CPM.
  • This transformation step may be regarded as encapsulating the changed contact information within a stand-alone media object or a stand- alone media object shell.
  • the primary user device 2a sends the stand-alone media object comprising the changed contact information of the identified changed contact to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the contact store 4g, and updates the master file to identify the location of the stand- alone media object comprising the changed contact information of the identified changed contact, in a step 403.
  • the primary user device 2a checks whether there are further changed contacts awaiting processing in a step 404. If there are further new contacts the method 400 returns to step 401 . Alternatively, if there are no further new contacts, the method 400 proceeds to step 405.
  • the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact information into a stand-alone media object in a step 405.
  • This transformation step 405 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM, in a similar manner to the transformation step 402.
  • This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell.
  • the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 406.
  • the method 400 ends in a step 407.
  • the central message store 4 receives a stand-alone media object comprising changed contact information from the primary user device 2a
  • the central message store 4 stores this received stand-alone media object in the contact store 4g of the address book store 4e, as instructed by the primary user device 2a.
  • the central message store 4 receives a stand-alone media object comprising the master file from the primary user device 2a
  • the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a.
  • the stand-alone media objects comprising contact information or the master file match the format for stand-alone media objects specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media objects comprising contact information or the master file using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects. This is the case both when the stand-alone media object comprises contact information comprising the contact information itself and when stand-alone media object comprises contact information comprising the master file.
  • the primary user device 2a executes a contact synchronization method 500 which will now be described with reference to figure 5.
  • the contact synchronization method 500 starts with the primary user device 2a identifying that a contact has been deleted in a step 501 .
  • the primary user device 2a updates the master file to delete the location of the stand-alone media object comprising the deleted contact information from the master file in a step 502.
  • the primary user device 2a checks whether there are further contacts which have been deleted in a step 503. If there are further contacts which have been deleted the method 500 returns to step 501 . Alternatively, if there are no further new contacts, the method 500 proceeds to step 504. [0059] When there are no further deleted contacts the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact information into a stand-alone media object in a step 504.
  • This transformation step 504 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM.
  • This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell.
  • the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 505.
  • the method 500 ends in a step 506.
  • the central message store 4 When the central message store 4 receives a stand-alone media object comprising the master file as contact information from the primary user device 2a, the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a.
  • the stand-alone media object comprising the master file as contact information matches the format for a stand-alone media object specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media object comprising the master file as contact information using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects.
  • the user devices which are not the primary user device may be referred to as secondary user devices.
  • the secondary user device 2b or 2c may be synchronized with the contact information stored in the address book store 4e of the central message store 4 from time to time.
  • the secondary user device 2b or 2c may be synchronized with the contact information stored in the address book store 4e of the central message store 4 by retrieving the master file, and then using the contents of the master file to identify the contact information.
  • the secondary user device 2b or 2c may request from the central message store 4 the most recent standalone media object stored in the jSon store 4f of the address book store 4e of the central message store 4. This most recent stand-alone media object will comprise the most recently updated version of the master file.
  • the central message store 4 provides the most recent standalone media object stored in the jSon store 4f to the requesting secondary user device 2b or 2c.
  • the secondary user device 2b and 2c can reverse transform the stand-alone media object comprising the master file to extract or dis-encapsulate the master file in a format used by that secondary user device 2b or 2c.
  • the secondary user device 2b or 2c can then use the master file to synchronize the contact information currently stored on the secondary user device 2b or 2c with the updated contact information stored in the central message store 4.
  • the secondary user device 2b or 2c can use the information in the master file to synchronize, i.e identify and retrieve, any stand-alone media objects comprising contact information not already known to the secondary user device 2b and 2c, either because the contact information is new, or has been changed, from the contact store 4g of the address book store 4e of the central message store 4.
  • the new contact information can be stored in the secondary user device 2b or 2c, any contact information stored in the secondary user device 2b or 2c which has been changed can be overwritten with the new version contact information, and any contacts which have been deleted can be removed from the secondary user device 2b or 2c.
  • each secondary user device 2b and 2c can reverse transform the stand-alone media object comprising the contact information to extract or dis-encapsulate the contact information of the identified contact in a format used by that secondary user device 2b or 2c.
  • the master file and the contact information for each contact are stored as stand-alone media objects matching the format for stand-alone media objects specified by CPM, and accordingly the central message store 4 is able to synchronize these stand-alone media objects comprising the master file and other contact information stored in the jSon store 4f and the contact store 4g of the address book store 4e of the central message store 4 with the secondary user devices 2b and 2c as required using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process, store and synchronize media objects to maintain message synchronization between the different user devices 2a-2c.
  • the stand-alone media objects comprising the contact information and the master file are stored in the central message store 4 acting as a server, and these stand-alone media objects can be accessed from any of the user devices 2a-2c, which act as clients.
  • the secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 based on selected synchronization trigger events. In some examples the secondary user devices 2b and 2c may synchronize their contact information when message synchronization is carried out, either in response to the message
  • the secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 periodically based on a time trigger event. Alternatively, or additionally, the secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 based on a communications trigger event when the secondary user device 2b or 2c requires access to contact information.
  • a secondary user device 2b or 2c may, for example, require access to contact information of a contact if a user attempts to send a message to a contact, or to reply to a message from a contact.
  • the primary user device 2a generates new and changed or edited contact information in the form of vcards according to the vcard 3.0 standard. These vcards comprising the contact information are than transformed into data objects matching the stand-alone media object format specified by CPM.
  • Vcard 3.0 is a file format standard for contact information, and need not be described in detail herein.
  • the primary user device 2a maintains a master file of contacts. The primary user device 2a maintains the master file for the contacts in the form of a jcard that contains pointers to the vcards containing the actual contact information.
  • the jcard and the vcards are then transformed or encapsulated as stand-alone media objects by the primary user device 2a, and stored as stand-alone media objects in the jSon store 4f and the contact store 4g respectively of the address book store 4e of the central message store 4.
  • the secondary user devices 2b and 2c synchronize their contact information with the central message store 4
  • the most recently stored stand-alone media object in the jSon store 4f comprising the jcard with the up to date master file for the contacts is the first file to be sent to the secondary user device 2b or 2c.
  • the links in the jcard are then used to detect the stand-alone media objects comprising the vcards for the contacts in the central message store 4 so that these stand-alone media objects comprising the vcards can be fetched by the secondary user device 2b or 2c.
  • the stand-alone media objects can be reverse transformed or dis-encapsulated by the secondary user devices 2b or 2c to recover the jcard and vcards as necessary so that the jcard and vcards can be used by the secondary user devices 2b or 2c.
  • one user device associated with a user is designated as a primary user device, with other user devices associated with that user being designated as secondary user devices, and only the primary user device can be used to create, change, or delete contacts and the master file.
  • the identity of the user device designated as a primary user device may be changed. This may, for example, be necessary if the user device designated as the primary user device is replaced, for example when a user mobile phone is upgraded and replaced by a new model.
  • one user device associated with a user is designated as a primary user device, with other user devices associated with that user being designated as secondary user devices, and only the primary user device can be used to create, change, or delete contacts and the master file.
  • This approach is preferred in order to eliminate possible race conditions which could result in inconsistencies in the contact information.
  • this distinction between primary and secondary devices may not be made, and any user device may be used to create, change, or delete contacts.
  • the contact information and the master file are initially generated or edited in vcard and jcard formats used by the user devices and then transformed into the stand-alone media object format used by CPM.
  • the contact information may be initially generated or edited in the stand-alone media object format, so that the contact information is in effect created in an encapsulated form so that no subsequent transformation step is required.
  • the contact information is encapsulated within a stand-alone media object for handling and storage by the central message store.
  • the contact information may be encapsulated within other types of items which may be handled and stored by the central message store.
  • the central message store of a CPM system may handle and store other types of items including message objects, session history folders, file transfer history objects, conversation history folders, user folders, session info objects, and group state objects.
  • contact information could be encapsulated within items of other types for handling and storage by the central message store.
  • batches of new, amended, or deleted contacts are recorded in the master file, and the master file is transformed and stored when no further contacts to be respectively added, amended, or deleted remain.
  • the master file may be transformed and stored at other times.
  • the master file may be transformed and stored after each change to the contacts.
  • the master file may be transformed and stored periodically.
  • contacts are synchronized across multiple user devices.
  • contacts may be synchronized across groups of multiple devices defined according to any preferred criteria, and not only groups of devices having a common user.
  • the multiple user devices are all mobile devices.
  • the multiple user devices may include non-mobile elements connected to the telecommunications network through a fixed connection.
  • non-mobile elements may include clients on personal computers (PCs).
  • the telecommunications network supports IP communications using RCS. In other examples other communications approaches may be used.
  • the contact information is stored in a jSon store storage location and a contact store storage location arranged as sub-locations of an address book store storage location arranged as a sub-location of the RCS message store within the central message store.
  • the contract information may be stored at a different location.
  • the contact information may not be stored in a dedicated storage location, but may be stored in a storage location shared with other types of information.
  • the contact information is in the form of vcards, and in particular a combination of jcards and vcards. In other examples the contact information may be in a different form.
  • the user devices and the central message store may be implemented as any suitable form of computing device.
  • Computing devices may comprises one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device.
  • the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware).
  • Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.
  • the computer executable instructions may be provided using any computer-readable media that is accessible by a computing device.
  • Computer-readable media may include, for example, computer storage media such as a memory and communications media.
  • Computer storage media such as a memory, includes volatile and non-volatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.
  • communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media.
  • the term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.
  • a remote computer may store an example of the process described as software.
  • a local or terminal computer may access the remote computer and download a part or all of the software to run the program.
  • the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).
  • the remote computer or computer network.
  • all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
  • Any reference to 'an' item refers to one or more of those items.
  • the term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

Abstract

A method of synchronizing contact information for use in Internet Protocol "IP" communications across a plurality of devices. The method comprising providing contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store, storing the contact information data objects in the message store,and synchronizing the contact information data objects stored in the message store across the plurality of devices.

Description

SYNCHRONISATION OF COMMUNICATIONS CONTACTS BETWEEN DEVICES
Background
[0001] When providing communications services to users having access to multiple communications devices it is common to attempt to provide a seamless or transparent communications experience to the user across their different communications devices by synchronizing messages sent and received by the user with the different communications service across the different user devices. This may be desirable, for example, allow a user to participate in an ongoing conversation or message thread from different ones of the user's devices, such as a mobile phone and a tablet. [0002] In Internet Protocol communications such as Rich Communications Services (RCS), methods of carrying out message synchronization are available. For example, in RCS, Converged IP Messaging (CPM) provides a central message store which is used to store and synchronize message traffic.
[0003] However, in order to allow users to switch seamlessly between using different communications devices it is also desirable to synchronize a user's contacts between their different user devices.
[0004] It has been proposed to provide user contact synchronization between different user devices by providing dedicated contact synchronizing infrastructure. For example in RCS the Open Mobile Alliance (OMA) provides a Converged Address Book (CAB) contact synchronizing solution using a dedicated CAB server.
[0005] However, approaches of this type have the disadvantage of requiring the expense and complexity of providing dedicated infrastructure to support the contact synchronization and adding the necessary interfaces and reference points for the communications service to interact with the dedicated infrastructure. [0006] The discussion above relates to RCS communications services. However, similar problems will apply to other Internet Protocol communications.
[0007] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of the known approaches described above.
Summary [0008] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
[0009] In Internet Protocol "IP" communications, contact information is synchronized across a plurality of devices using a message synchronization system. The contact information is transformed or encapsulated into a data object format used by the message synchronization system, and then sent to the message synchronization system for storage in the message store. The message synchronization system is then used to synchronize the contact information data objects stored in the message store across the plurality of devices.
[0010] A first aspect provides a method of synchronizing contact information for use in Internet Protocol "IP" communications across a plurality of devices, the method comprising: providing contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices. [0011] A second aspect provides a contact synchronization system arranged to synchronize contact information in Internet Protocol "IP" communications across a plurality of devices, the system comprising a message store, and the system being arranged to: provide contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; store the contact information data objects in the message store; and synchronize the contact information data objects stored in the message store across the plurality of devices.
[0012] A third aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising: receiving contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store; storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices by sending the contact information data objects to the plurality of devices.
[0013] A fourth aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising, at one of the plurality of devices: producing contact information as a plurality of data objects in a second format, and converting the data objects in the second format into contact information data objects in a first format; and sending the plurality of contact information data objects to a message store of a message synchronization system. [0014] A fifth aspect provides a method of synchronizing contact information in Internet Protocol "IP" communications across a plurality of devices, the method comprising, at one of the plurality of devices: receiving a contact information data object from a message store, the contact information data object being in a first format of a data object of the message store; and converting the contact information data object in the first format into at least one data object in a second format.
[0015] A sixth aspect provides computer software comprising a series of instructions which , when executed on a processor, will cause the processor to carry out the method according to any one of the third to fifth aspects. [0016] A seventh aspect provides tangible computer-readable storage comprising computer- readable instructions which, when executed on a processor of a computer will cause the computer to carry out the method according to any one of the third to fifth aspects.
[0017] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
[0018] This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
[0019] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention. Brief Description of the Drawings
[0020] Embodiments of the present invention will be described, by way of example, with reference to the following drawings, in which: [0021] Figure 1 is a schematic diagram of a communications system according to a first embodiment;
[0022] Figure 2 is a schematic diagram of a central message store of the system of figure 1 ;
[0023] Figure 3 is a flow diagram of a method for synchronizing contacts which may be used by the system of figure 1 ;
[0024] Figure 4 is a flow diagram of a further method for synchronizing contacts which may be used by the system of figure 1 ; and
[0025] Figure 5 is a flow diagram of a still further method for synchronizing contacts which may be used by the system of figure 1 . [0026] Common reference numerals are used throughout the figures to indicate similar features.
Detailed Description
[0027] Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
[0028] Figure 1 illustrates a communications system providing synchronization of messages and contacts between different devices according to a first embodiment of the present invention.
[0029] In the following description the invention is described in terms of the synchronization of contacts between different devices which are different devices which are associated with a single user, for example devices which may be used by a common user. This is an example selected for illustrative and explanatory purposes. Although this is a situation where the present invention may be used, the present invention may be applied to any situation where it is desired to synchronize contact information between a number of devices.
[0030] In figure 1 , a telecommunications network 1 is shown. The telecommunications network 1 supports IP communications, in the illustrated example Rich Communications Services (RCS) telecommunications services, and is operated by a network operator. The telecommunications network 1 can be accessed by user devices 2, which may include multiple user devices 2 associated with the same user. In the illustrated example a number of different user devices 2a-2c associated with a common single user are shown, specifically a mobile phone 2a, a tablet 2b and a laptop computer 2c. The telecommunications network 1 is shown schematically in figure 1 and only parts of the telecommunications network 1 which are required to allow the present invention to be understood are shown. It will be understood that the telecommunications network 1 will in practice comprise a very large number of other components, but these are not described or shown to improve clarity and to avoid obscuring the scope of the present invention.
[0031] The telecommunications network 1 comprises a message synchronization system 3 arranged to synchronize messages between and across the different user devices 2a-2c of the user. The message synchronization system 3 comprises a central message store 4 in which all of the user's messages are stored. In the illustrated example where the
telecommunications network 1 supports RCS telecommunications services the message synchronization system 3 may be a Converged IP Messaging (CPM) system operating according to the Internet Mail Access Protocol V4 (IMAP4).
[0032] In operation of the telecommunications network 1 , when the user accesses the network using different ones of the user devices 2a-2c the CPM message synchronization system 3 provides copies of user messages stored in the central message store 4 to the user devices 2a-2c as necessary to maintain message synchronization between the different user devices 2a-2c. In the illustrated example using IMAP4 the messages are stored in the central message store 4 acting as a server, and the messages can be accessed from any of the user devices 2a-2c, which act as clients.
[0033] In the first embodiment as illustrated in figure 1 , in addition to messages the central message store 4 is also used to store contact information relating to user contacts. An example of a central message store 4 arranged to store contact information relating to user contacts is shown in FIG. 2.
[0034] As shown in figure 2, according to the illustrated first embodiment the central message store 4 is structured to comprise a number of separate storage regions or areas 4a to 4e. The central message store 4 comprises three top level storage regions 4a to 4c, comprising an RCS message store 4a, a system default, or "Inbox" message store 4b, and a deleted message store 4c. The central message store 4 further comprises two mid-level storage regions 4d and 4e, comprising a favorites message store 4d and an address book store 4e. The mid-level storage regions of the favorites message store 4d and the address book store 4e are arranged in a hierarchical manner as sub-regions of the RCS message store 4a. The central message store 4 further comprises two low level storage regions 4f and 4g, comprising a jSon store 4f and a contact store 4g. The low level storage regions of the jSon store 4f and the contact store 4g are arranged in a hierarchical manner as sub-regions of the address book store 4e The storage regions 4a to 4d according to the illustrated first embodiment correspond to the arrangement of a central message store of a CPM system. The address book store 4e, jSon store 4f and contact store 4g are added by the present disclosure.
[0035] In order to populate the jSon store 4f and contact store 4g of the address book store 4e of the central message store 4 with contact information relating to user contacts, one of the user's different user devices 2a-2c is identified as a primary user device. In the illustrated first embodiment the user's mobile phone 2a is identified as the primary user device.
[0036] In some examples the identification of a particular user communication device 2a-2c as the primary user device may be carried out automatically by the telecommunications network 1 . In one example this identification may be based on a comparison of the characteristics or parameters of the different user communication devices 2a-2c associated with the user for connection to the telecommunications network 1 . In another example this identification may be based upon the order in which the different user communication devices 2a-2c are registered for access to the telecommunications network 1 , for example the first communications device 2a-2c registered for access to the telecommunications network 1 may be regarded as the primary user device. In other examples the user may select which user communication device 2a-2c is to be the primary user device.
[0037] According to the first embodiment, when the primary user device 2a is connected to the telecommunications network 1 and the primary user device 2a contains one or more new contacts which are not already stored in the central message store 4, the primary user device 2a executes a contact synchronization method 300 which will now be described with reference to figure 3.
[0038] As shown in figure 3, the contact synchronization method 300 starts with the primary user device 2a identifying a new contact in a step 301 .
[0039] Next, the primary user device 2a transforms the contact information of the identified contact into a stand-alone media object in a step 302. This transformation step 302 transforms or converts the contact information into an object matching the format for a standalone media object specified by CPM. This transformation step may be regarded as encapsulating the contact information within a stand-alone media object or a stand-alone media object shell. [0040] Then, the primary user device 2a sends the stand-alone media object comprising the contact information of the new identified contact to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the contact store 4g, and updates a master file to identify the location of the stand-alone media object comprising the contact data of the new identified contact, in a step 303.
[0041] Then, the primary user device 2a checks whether there are further new contacts awaiting processing in a step 304. If there are further new contacts the method 300 returns to step 301 . Alternatively, if there are no further new contacts, the method 300 proceeds to step 305. [0042] When there are no further new contacts the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact data into a stand-alone media object in a step 305. This transformation step 305 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM, in a similar manner to the transformation step 302. This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell.
[0043] Then, the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 306. [0044] Then, the method 300 ends in a step 307.
[0045] When the central message store 4 receives a stand-alone media object comprising contact information from the primary user device 2a, the central message store 4 stores this stand-alone media object in the contact store 4g of the address book store 4e, as instructed by the primary user device 2a. When the central message store 4 receives a stand-alone media object comprising the master file from the primary user device 2a, the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a. As discussed above, the stand-alone media object comprising contact information or the master file matches the format for a stand-alone media object specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media object comprising contact information or the master file using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects. This is the case both when the stand-alone media object comprises contact information comprising the contact information itself and when stand-alone media object comprises contact information comprising the master file. [0046] In the first embodiment a method similar to that described above for new contacts with reference to figure 3 may also be used when the contact information relating to a contact is changed, for example when the contact information is updated or edited. When the primary user device 2a is connected to the telecommunications network 1 and the primary user device 2a contains one or more changed contacts comprising contact information different from that which has been stored in the central message store 4, the primary user device 2a executes a contact synchronization method 400 which will now be described with reference to figure 4.
[0047] As shown in figure 4, the contact synchronization method 400 starts with the primary user device 2a identifying a changed contact including changed information in a step 401 . [0048] Next, the primary user device 2a transforms the contact information of the identified changed contact into a stand-alone media object in a step 402. This transformation step 402 transforms or converts the changed contact information into an object matching the format for a stand-alone media object specified by CPM. This transformation step may be regarded as encapsulating the changed contact information within a stand-alone media object or a stand- alone media object shell.
[0049] Then, the primary user device 2a sends the stand-alone media object comprising the changed contact information of the identified changed contact to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the contact store 4g, and updates the master file to identify the location of the stand- alone media object comprising the changed contact information of the identified changed contact, in a step 403.
[0050] Then, the primary user device 2a checks whether there are further changed contacts awaiting processing in a step 404. If there are further new contacts the method 400 returns to step 401 . Alternatively, if there are no further new contacts, the method 400 proceeds to step 405.
[0051] When there are no further changed contacts the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact information into a stand-alone media object in a step 405. This transformation step 405 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM, in a similar manner to the transformation step 402. This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell. [0052] Then, the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 406.
[0053] Then, the method 400 ends in a step 407. [0054] When the central message store 4 receives a stand-alone media object comprising changed contact information from the primary user device 2a, the central message store 4 stores this received stand-alone media object in the contact store 4g of the address book store 4e, as instructed by the primary user device 2a. When the central message store 4 receives a stand-alone media object comprising the master file from the primary user device 2a, the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a. As discussed above, the stand-alone media objects comprising contact information or the master file match the format for stand-alone media objects specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media objects comprising contact information or the master file using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects. This is the case both when the stand-alone media object comprises contact information comprising the contact information itself and when stand-alone media object comprises contact information comprising the master file. [0055] In the first embodiment, when the primary user device 2a is connected to the telecommunications network 1 and the primary user device 2a one or more contacts have been deleted which were previously stored in the central message store 4, the primary user device 2a executes a contact synchronization method 500 which will now be described with reference to figure 5. [0056] As shown in figure 5, the contact synchronization method 500 starts with the primary user device 2a identifying that a contact has been deleted in a step 501 .
[0057] Then, the primary user device 2a updates the master file to delete the location of the stand-alone media object comprising the deleted contact information from the master file in a step 502. [0058] Then, the primary user device 2a checks whether there are further contacts which have been deleted in a step 503. If there are further contacts which have been deleted the method 500 returns to step 501 . Alternatively, if there are no further new contacts, the method 500 proceeds to step 504. [0059] When there are no further deleted contacts the primary user device 2a transforms the master file identifying the locations of the media objects comprising the contact information into a stand-alone media object in a step 504. This transformation step 504 transforms or converts the master file into an object matching the format for a stand-alone media object specified by CPM. This transformation step may be regarded as encapsulating the master file within a stand-alone media object or a stand-alone media object shell.
[0060] Then, the primary user device 2a sends the stand-alone media object comprising the master file to the central message store 4, together with instructions for the central message store 4 to store the stand-alone media object in the jSon store 4f, in a step 505. [0061] Then, the method 500 ends in a step 506.
[0062] When the central message store 4 receives a stand-alone media object comprising the master file as contact information from the primary user device 2a, the central message store 4 stores this stand-alone media object in the jSon store 4f of the address book store 4e, as instructed by the primary user device 2a. As discussed above, the stand-alone media object comprising the master file as contact information matches the format for a stand-alone media object specified by CPM, and accordingly the central message store 4 is able to process and store the stand-alone media object comprising the master file as contact information using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process and store media objects.
[0063] The user devices which are not the primary user device may be referred to as secondary user devices. In operation of the telecommunications network 1 , when a secondary user device 2b or 2c is connected to the telecommunications network 1 the secondary user device 2b or 2c may be synchronized with the contact information stored in the address book store 4e of the central message store 4 from time to time.
[0064] The secondary user device 2b or 2c may be synchronized with the contact information stored in the address book store 4e of the central message store 4 by retrieving the master file, and then using the contents of the master file to identify the contact information. [0065] In order to carry out the synchronization the secondary user device 2b or 2c may request from the central message store 4 the most recent standalone media object stored in the jSon store 4f of the address book store 4e of the central message store 4. This most recent stand-alone media object will comprise the most recently updated version of the master file. In response to this request, the central message store 4 provides the most recent standalone media object stored in the jSon store 4f to the requesting secondary user device 2b or 2c.
[0066] When a stand-alone media object comprising the most recently updated version of the master file has been received from the central message store 4 by the secondary user device 2b or 2c the secondary user device 2b and 2c can reverse transform the stand-alone media object comprising the master file to extract or dis-encapsulate the master file in a format used by that secondary user device 2b or 2c.
[0067] The secondary user device 2b or 2c can then use the master file to synchronize the contact information currently stored on the secondary user device 2b or 2c with the updated contact information stored in the central message store 4. The secondary user device 2b or 2c can use the information in the master file to synchronize, i.e identify and retrieve, any stand-alone media objects comprising contact information not already known to the secondary user device 2b and 2c, either because the contact information is new, or has been changed, from the contact store 4g of the address book store 4e of the central message store 4. The new contact information can be stored in the secondary user device 2b or 2c, any contact information stored in the secondary user device 2b or 2c which has been changed can be overwritten with the new version contact information, and any contacts which have been deleted can be removed from the secondary user device 2b or 2c.
[0068] When a stand-alone media object comprising contact information has been synchronized across the secondary user devices 2b and 2c from the central message store 4, each secondary user device 2b and 2c can reverse transform the stand-alone media object comprising the contact information to extract or dis-encapsulate the contact information of the identified contact in a format used by that secondary user device 2b or 2c.
[0069] As is explained above, the master file and the contact information for each contact are stored as stand-alone media objects matching the format for stand-alone media objects specified by CPM, and accordingly the central message store 4 is able to synchronize these stand-alone media objects comprising the master file and other contact information stored in the jSon store 4f and the contact store 4g of the address book store 4e of the central message store 4 with the secondary user devices 2b and 2c as required using the already defined storing components and procedures already present in the central message store 4 and used by the central message store 4 to process, store and synchronize media objects to maintain message synchronization between the different user devices 2a-2c.
[0070] In the illustrated example using IMAP4 the stand-alone media objects comprising the contact information and the master file are stored in the central message store 4 acting as a server, and these stand-alone media objects can be accessed from any of the user devices 2a-2c, which act as clients.
[0071] The secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 based on selected synchronization trigger events. In some examples the secondary user devices 2b and 2c may synchronize their contact information when message synchronization is carried out, either in response to the message
synchronization, or based on a message synchronization trigger. In some examples the secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 periodically based on a time trigger event. Alternatively, or additionally, the secondary user devices 2b and 2c may synchronize their contact information with the central message store 4 based on a communications trigger event when the secondary user device 2b or 2c requires access to contact information. A secondary user device 2b or 2c may, for example, require access to contact information of a contact if a user attempts to send a message to a contact, or to reply to a message from a contact. [0072] In the illustrated first embodiment the primary user device 2a generates new and changed or edited contact information in the form of vcards according to the vcard 3.0 standard. These vcards comprising the contact information are than transformed into data objects matching the stand-alone media object format specified by CPM. Vcard 3.0 is a file format standard for contact information, and need not be described in detail herein. [0073] In the illustrated first embodiment, the primary user device 2a maintains a master file of contacts. The primary user device 2a maintains the master file for the contacts in the form of a jcard that contains pointers to the vcards containing the actual contact information. The jcard and the vcards are then transformed or encapsulated as stand-alone media objects by the primary user device 2a, and stored as stand-alone media objects in the jSon store 4f and the contact store 4g respectively of the address book store 4e of the central message store 4.
[0074] When the secondary user devices 2b and 2c synchronize their contact information with the central message store 4, the most recently stored stand-alone media object in the jSon store 4f comprising the jcard with the up to date master file for the contacts is the first file to be sent to the secondary user device 2b or 2c. The links in the jcard are then used to detect the stand-alone media objects comprising the vcards for the contacts in the central message store 4 so that these stand-alone media objects comprising the vcards can be fetched by the secondary user device 2b or 2c. The stand-alone media objects can be reverse transformed or dis-encapsulated by the secondary user devices 2b or 2c to recover the jcard and vcards as necessary so that the jcard and vcards can be used by the secondary user devices 2b or 2c. [0075] In the illustrated embodiment described above one user device associated with a user is designated as a primary user device, with other user devices associated with that user being designated as secondary user devices, and only the primary user device can be used to create, change, or delete contacts and the master file. The identity of the user device designated as a primary user device may be changed. This may, for example, be necessary if the user device designated as the primary user device is replaced, for example when a user mobile phone is upgraded and replaced by a new model.
[0076] In the illustrated embodiment described above one user device associated with a user is designated as a primary user device, with other user devices associated with that user being designated as secondary user devices, and only the primary user device can be used to create, change, or delete contacts and the master file. This approach is preferred in order to eliminate possible race conditions which could result in inconsistencies in the contact information. However, in alternative embodiments this distinction between primary and secondary devices may not be made, and any user device may be used to create, change, or delete contacts.
[0077] In the embodiments described above the contact information and the master file are initially generated or edited in vcard and jcard formats used by the user devices and then transformed into the stand-alone media object format used by CPM. In alternative embodiments the contact information may be initially generated or edited in the stand-alone media object format, so that the contact information is in effect created in an encapsulated form so that no subsequent transformation step is required.
[0078] In the embodiments described above the contact information is encapsulated within a stand-alone media object for handling and storage by the central message store. In other examples the contact information may be encapsulated within other types of items which may be handled and stored by the central message store. In addition to stand-alone media objects the central message store of a CPM system may handle and store other types of items including message objects, session history folders, file transfer history objects, conversation history folders, user folders, session info objects, and group state objects. In principle, contact information could be encapsulated within items of other types for handling and storage by the central message store.
[0079] In the embodiments described above batches of new, amended, or deleted contacts are recorded in the master file, and the master file is transformed and stored when no further contacts to be respectively added, amended, or deleted remain. In other examples the master file may be transformed and stored at other times. In some examples the master file may be transformed and stored after each change to the contacts. In some examples the master file may be transformed and stored periodically.
[0080] In the embodiments described above contacts are synchronized across multiple user devices. In other examples contacts may be synchronized across groups of multiple devices defined according to any preferred criteria, and not only groups of devices having a common user.
[0081] In the embodiments described above the multiple user devices are all mobile devices. In other examples the multiple user devices may include non-mobile elements connected to the telecommunications network through a fixed connection. In one example such non-mobile elements may include clients on personal computers (PCs).
[0082] In the embodiments described above a CPM message synchronization system and central message store is used. In other examples different message synchronization systems and central message stores may be used.
[0083] In the embodiments described above a CPM system using IMAP4 is used. In other examples different messaging protocols may be used.
[0084] In the embodiments described above the telecommunications network supports IP communications using RCS. In other examples other communications approaches may be used.
[0085] In the embodiments described above the contact information is stored in a jSon store storage location and a contact store storage location arranged as sub-locations of an address book store storage location arranged as a sub-location of the RCS message store within the central message store. In other examples the contract information may be stored at a different location. In some examples the contact information may not be stored in a dedicated storage location, but may be stored in a storage location shared with other types of information. [0086] In the embodiments described above the contact information is in the form of vcards, and in particular a combination of jcards and vcards. In other examples the contact information may be in a different form.
[0087] In the illustrated embodiments of the invention the user devices and the central message store may be implemented as any suitable form of computing device. Computing devices may comprises one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device. [0088] The computer executable instructions may be provided using any computer-readable media that is accessible by a computing device. Computer-readable media may include, for example, computer storage media such as a memory and communications media. Computer storage media, such as a memory, includes volatile and non-volatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media.
[0089] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.
[0090] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program.
Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
[0091] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.
[0092] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.
[0093] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.
[0094] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims

Claims:
A method of synchronizing contact information in Internet Protocol "IP"
communications across a plurality of devices, the method comprising:
providing contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store;
storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices.
The method according to claim 1 wherein the providing the contact information comprises producing the contact information as a plurality of data objects in a second format, and converting the data objects in the second format into contact information data objects in the first format.
The method according to claim 2 wherein the providing the contact information is carried out by one of the plurality of devices.
4. The method according to claim 3 wherein one of the plurality of devices is designated as a primary device, and the providing the contact information is carried out by the primary device.
5. The method according to any one of claims 2 to 4 and further comprising, after synchronizing the contact information data objects across the plurality of devices, converting at least one contact information data object in the first format into at least one data object in the second format by at least one of the plurality of devices.
6. The method of claim 4 wherein the synchronizing the contact information data objects stored in the message store across the plurality of devices brings the contact information on the ones of the plurality of devices which are not the primary device into agreement with the contact information on the primary device.
7. The method according to any one of claims 2 to 6 wherein the second format is a contact information data format used by the plurality of devices. 8. The method according to any one of claims 2 to 7 wherein the second format is a vcard format.
9. The method according to any preceding claim wherein the IP communications are Rich Communications Services "RCS" services.
10. The method according to claim 9 wherein the message store is a Converged IP Messaging "CPM" message store.
1 1 . The method according to claim 10 wherein the first format is a stand-alone media object format. 12. The method according to claim 10 or claim 1 1 wherein the synchronizing is carried out using Internet Mail Access Protocol V4 ΊΜΑΡ4".
13. The method according to any preceding claim wherein the contact information data objects are stored in a dedicated storage region within the message store.
14. The method according to any preceding claim wherein at least one of the contact information data objects comprises information identifying the other contact information data objects. 15. A contact synchronization system arranged to synchronize contact information in
Internet Protocol "IP" communications across a plurality of devices, the system comprising a message store, and the system being arranged to:
provide contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store;
store the contact information data objects in the message store; and synchronize the contact information data objects stored in the message store across the plurality of devices.
16. The system according to claim 15 wherein the system is further arranged to provide the contact information by producing the contact information as a plurality of data objects in a second format, and converting the data objects in the second format into contact information data objects in the first format.
17. The system according to claim 16 wherein the system further comprises the plurality of devices and the providing the contact information is carried out by one of the plurality of devices.
18. The system according to claim 17 wherein one of the plurality of devices is designated as a primary device, and the providing the contact information is carried out by the primary device.
19. The system according to one of claims 17 or 18, wherein at least one of the plurality of devices is arranged to convert at least one contact information data object in the first format into at least one data object in the second format after the contact information data objects have been synchronized across the plurality of devices.
20. The system of claim 18, wherein synchronizing the contact information data objects stored in the message store across the plurality of devices brings the contact information on the ones of the plurality of devices which are not the primary device into agreement with the contact information on the primary device.
21 . The system according to any one of claims 15 to 20 wherein the second format is a contact information data format used by the plurality of devices.
22. The system according to any one of claims 15 to 21 wherein the second format is a vcard format.
23. The system according to any one of claims 15 to 22 wherein the IP communications are Rich Communications Services "RCS" services.
24. The system according to claim 23 wherein the message store is a Converged IP Messaging "CPM" message store.
25. The system according to claim 24 wherein the first format is a stand-alone media object format.
26. The system according to claim 24 or claim 25 wherein the synchronizing is carried out using Internet Mail Access Protocol V4 ΊΜΑΡ4".
27. The system according to any one of claims 15 to 26 wherein the message store
comprises a dedicated storage region to store the contact information data objects.
28. The system according to any one of claims 15 to 27 wherein at least one of the
contact information data objects comprises information identifying the other contact information data objects.
29. A method of synchronizing contact information in Internet Protocol "IP"
communications across a plurality of devices, the method comprising:
receiving contact information in the form of a plurality of contact information data objects each in a first format of a data object of a message store;
storing the contact information data objects in the message store; and synchronizing the contact information data objects stored in the message store across the plurality of devices by sending the contact information data objects to the plurality of devices.
30. The method according to claim 29 wherein one of the plurality of devices is
designated as a primary device, and the contact information is received from the primary device.
31 . The method of claim 30 wherein the synchronizing the contact information data objects stored in the message store across the plurality of devices brings the contact information on the ones of the plurality of devices which are not the primary device into agreement with the contact information on the primary device.
32. The method according to any one of claims 29 to 31 wherein the IP communications are Rich Communications Services "RCS" services.
33. The method according to claim 32 wherein the message store is a Converged IP Messaging "CPM" message store.
34. The method according to claim 33 wherein the first format is a stand-alone media object format.
35. The method according to claim 33 or claim 34 wherein the synchronizing is carried out using Internet Mail Access Protocol V4 ΊΜΑΡ4".
36. The method according to any one of claims 29 to 35 wherein the contact information data objects are stored in a dedicated storage region within the message store.
37. The method according to any one of claims 29 to 36 wherein at least one of the contact information data objects comprises information identifying the other contact information data objects.
38. A method of synchronizing contact information in Internet Protocol "IP"
communications across a plurality of devices, the method comprising, at one of the plurality of devices:
producing contact information as a plurality of data objects in a second format, and converting the data objects in the second format into contact information data objects in a first format;
and sending the plurality of contact information data objects to a message store of a message synchronization system.
39. The method according to claim 38 wherein the second format is a contact information data format used by the plurality of devices.
40. The method according to claim 38 or claim 39 wherein the second format is a vcard format.
41 . The method according to any one of claims 38 to 40 wherein the IP communications are Rich Communications Services "RCS" services.
42. The method according to claim 41 wherein the message store is a Converged IP Messaging "CPM" message store.
43. The method according to claim 42 wherein the first format is a stand-alone media object format.
44. The method according to any one of claims 38 to 43 wherein at least one of the
contact information data objects comprises information identifying the other contact information data objects.
45. A method of synchronizing contact information in Internet Protocol "IP"
communications across a plurality of devices, the method comprising, at one of the plurality of devices:
receiving a contact information data object from a message store, the contact information data object being in a first format of a data object of the message store; and
converting the contact information data object in the first format into at least one data object in a second format.
46. The method according to acclaim 45 wherein the second format is a contact information data format used by said one of the plurality of devices.
47. The method according to claim 46 wherein the second format is a vcard format.
48. The method according to any one of claims 45 to 47 wherein the IP communications are Rich Communications Services "RCS" services.
49. The method according to claim 48 wherein the message store is a Converged IP Messaging "CPM" message store.
50. The method according to claim 49 wherein the first format is a stand-alone media object format.
51 . The method according to claim 49 or claim 50 wherein the synchronizing is carried out using Internet Mail Access Protocol V4 ΊΜΑΡ4".
52. The method according to any one of claims 45 to 51 wherein at least one of the contact information data objects comprises information identifying the other contact information data objects
53. Computer software comprising a series of instructions which, when executed on a processor, will cause the processor to carry out the method according to any one of claims 29 to 37, or claims 38 to 44, or claims 45 to 52.
54. A tangible computer-readable storage comprising computer-readable instructions which, when executed on a processor of a computer will cause the computer to carry out the method according to any one of claims 29 to 37, or claims 38 to 44, or claims 45 to 52.
PCT/GB2016/053109 2015-10-06 2016-10-06 Synchronisation of communications contacts between devices WO2017060706A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1517662.1A GB2543067A (en) 2015-10-06 2015-10-06 Synchronisation of communications contacts between devices
GB1517662.1 2015-10-06

Publications (1)

Publication Number Publication Date
WO2017060706A1 true WO2017060706A1 (en) 2017-04-13

Family

ID=54606179

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2016/053109 WO2017060706A1 (en) 2015-10-06 2016-10-06 Synchronisation of communications contacts between devices

Country Status (2)

Country Link
GB (1) GB2543067A (en)
WO (1) WO2017060706A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111586235A (en) * 2019-02-15 2020-08-25 三星电子株式会社 Electronic device, method, and computer-readable medium for dynamically laying out messages

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006066413A1 (en) * 2004-12-23 2006-06-29 Research In Motion Limited Systems and methods for continuous pim synchronization between a host computer and a client handheld device
US20090143052A1 (en) * 2007-11-29 2009-06-04 Michael Bates Systems and methods for personal information management and contact picture synchronization and distribution
US20110145320A1 (en) * 2009-12-15 2011-06-16 Rich Megginson Message bus based replication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006066413A1 (en) * 2004-12-23 2006-06-29 Research In Motion Limited Systems and methods for continuous pim synchronization between a host computer and a client handheld device
US20090143052A1 (en) * 2007-11-29 2009-06-04 Michael Bates Systems and methods for personal information management and contact picture synchronization and distribution
US20110145320A1 (en) * 2009-12-15 2011-06-16 Rich Megginson Message bus based replication

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111586235A (en) * 2019-02-15 2020-08-25 三星电子株式会社 Electronic device, method, and computer-readable medium for dynamically laying out messages

Also Published As

Publication number Publication date
GB201517662D0 (en) 2015-11-18
GB2543067A (en) 2017-04-12

Similar Documents

Publication Publication Date Title
EP2783501B1 (en) Contact information synchronization system and method
US10826859B1 (en) Techniques for ephemeral messaging with a message queue
CN103825950B (en) A kind of method and system based on the synchronous contact person of cloud platform
CN107172169A (en) Method of data synchronization, device, server and storage medium
US20150229598A1 (en) Method and system of synchroning an unread message in instant communication
KR20130020732A (en) Persistent personal messaging in a distributed system
CN107391758A (en) Database switching method, device and equipment
CN106570097B (en) Sequence generation method and device
US20150256504A1 (en) Distributed synchronization data in a message management service
CN105049631B (en) Enter the method and mobile terminal of row information transmission in address list program
US9185148B1 (en) Methods and systems for efficient discovery of devices in a peer-to-peer network
EP3506599B1 (en) Method for synchronizing contact information, apparatus and medium
WO2016123034A1 (en) Methods and devices for processing information card
CN112929257B (en) Multi-scene message sending method, device, server and storage medium
CN108549586B (en) Information processing method and device
WO2017060706A1 (en) Synchronisation of communications contacts between devices
CN108476163B (en) Archiving messages without message duplication
CN111090789A (en) Session window awakening method and device based on two-dimensional code and storage medium
CN104735643A (en) Information processing method and data server
CN112836201A (en) Method, device, equipment and computer readable medium for multi-platform information intercommunication
CA2895921C (en) System and method for obtaining a portion of an archived email message
CN113037844B (en) Identification updating method and device
EP4132037A1 (en) Udsf record retrieval and deletion
TWI531910B (en) Data management method, computer program product and managing server
CN113836875B (en) Text processing method, system, device and storage medium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16781173

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16781173

Country of ref document: EP

Kind code of ref document: A1