US20070118577A1 - Method of Replicating Data Between Computing Devices - Google Patents

Method of Replicating Data Between Computing Devices Download PDF

Info

Publication number
US20070118577A1
US20070118577A1 US11/627,416 US62741607A US2007118577A1 US 20070118577 A1 US20070118577 A1 US 20070118577A1 US 62741607 A US62741607 A US 62741607A US 2007118577 A1 US2007118577 A1 US 2007118577A1
Authority
US
United States
Prior art keywords
computing device
data
change
cognima
wireless
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US11/627,416
Inventor
Simon East
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Synchronoss Technologies Data Centre Ltd
Original Assignee
Cognima Ltd
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 Cognima Ltd filed Critical Cognima Ltd
Priority to US11/627,416 priority Critical patent/US20070118577A1/en
Publication of US20070118577A1 publication Critical patent/US20070118577A1/en
Assigned to SHOZU LIMITED reassignment SHOZU LIMITED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: COGNIMA LIMITED
Assigned to CRITICAL PATH DATA CENTRE LIMITED reassignment CRITICAL PATH DATA CENTRE LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SHOZU LIMITED (FKA COGNIMA LIMITED)
Abandoned legal-status Critical Current

Links

Images

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
    • G06F16/275Synchronous replication
    • 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
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • This invention relates to a method of replicating data between computing devices, particularly data from resource constrained wireless devices (i.e. devices with limited processing power and limited battery life) such as mobile telephones and personal organisers that are synchronising to and from a server over a wireless network.
  • resource constrained wireless devices i.e. devices with limited processing power and limited battery life
  • mobile telephones and personal organisers that are synchronising to and from a server over a wireless network.
  • Data replication between computing devices occurs in many different contexts, such as synchronising documents, e-mails, contacts and calendar entries across different computing devices used by the same person.
  • data replication In order for data replication to be accurate, there must be some system for deciding which of two or more inconsistent data replication requests should be acted on. Take for example the situation where, at time 1 , a user enters a change to his e-mail details for person X on his mobile telephone. Some time later, at time 2 , the user realises that those changes were in fact wrong. He makes a further change to those person X email detail, but does so on a PC. At time 3 , he synchronises his PC to a master server, updating the master record of person X's e-mail to the correct address. But suppose later still, at time 4 , he synchronises his mobile telephone with the master server—this would potentially over-write the correct person X email details (entered at time 2 ) with the incorrect details entered originally at time 1 .
  • synchronisation systems typically employ time based arbitration rules, such as giving priority to the latest recorded change (time 2 as compared to time 1 in the example above).
  • time 2 as compared to time 1 in the example above.
  • the device logs that change as part of the record and time stamps it (again, as an entry forming part of the record) with the time established by a quartz clock running locally on the device.
  • Changes to data e.g. the new e-mail contact details for the individual
  • a central server an entire replacement record is usually sent (e.g. all existing contact details for the individual, plus the new e-mail address, plus the time stamp)—the central server then updates its master copy of the information and sends updating information to any devices so that all maintain the same information.
  • the central server typically applies arbitration rules using the time stamp to resolve conflicts between competing and inconsistent synchronisation requests.
  • time stamps are made by a local quartz clock running on the device into which the changed data was first input.
  • This device could be a client device, server or peer.
  • a first computing device 12 is given responsibility for determining whether data received from a wireless, portable computing device 14 over a wireless network 16 is replicated or not; wherein the method comprises the steps of the wireless, portable computing device:
  • the method further comprises the step of the wireless, portable computing device 14 registering 26 new metadata definitions 28 with the first computing device 12 to define how change logs relating to a new application 24 will be presented by the wireless computing device 14 .
  • This approach enables resource constrained wireless, portable computing devices (e.g. mobile telephones) to provide a data replication capability (e.g. backing up databases, such as contacts, e-mails, photographs onto a remote device—a server or peer storing a master copy of the database) without undue processing burden, using low bandwidth unreliable wireless connections. It does this by de-coupling the change log from the database which has been changed; this in turn means that far less data has to be sent to the remote device—typically only the field which has changed, how it was be changed and when it was changed on the wireless computing device. Prior art systems typically send an entire record, even though that will contain data that has not changed.
  • the wireless computing device and the first computing device (which is not necessarily a portable device, but more usually a large server) share metadata that defines the proper interpretation of the change log.
  • the wireless computing device may register new metadata definitions with the first computing device to define how change logs relating to a new application will be presented by the wireless computing device.
  • the change logs are automatically sent by the wireless computing device to the first computing device without any user intervention. This may be (a) at pre-defined periodic intervals, (b) at pre-defined times or (c) continuously whenever a change log is created. In any event, because the master database on the first computing device is kept up to date, the problems that can arise with a user manually synchronising the same data from several different devices (as explained in the prior art section) are far less likely to arise.
  • Multiple change logs can be batched up; these may be sent at times which depend on the importance of the change log being rapidly processed by the first computing device, with low priority change logs being sent at times of lower network traffic (hence incurring lower charges).
  • individual records in a change log can be sent at times which depend on the importance of the records being rapidly processed by the first computing device, with low priority records again being sent at times of lower network traffic.
  • a wireless, portable computing device programmed to send data to a first computing device over a wireless network, in order for the first computing device to replicate that data; wherein the wireless computing device is programmed to:
  • FIG. 1 is a schematic drawing of one embodiment of the present invention.
  • FIG. 2 is a flow diagram detailing steps in one embodiment of the present invention.
  • Cognima has developed a data replication technology that directly addresses the need for Mobile Service Providers (MSPs) and Network Operators to increase consumer adoption of data services, encourage greater loyalty from their valuable customers, and differentiate their services from the competition.
  • MSPs Mobile Service Providers
  • Network Operators to increase consumer adoption of data services, encourage greater loyalty from their valuable customers, and differentiate their services from the competition.
  • the Cognima's data replication framework enables a Mobile Service Provider to build compelling services for consumer markets.
  • the MSP hosts a Cognima Server at its data centre.
  • the server comprises an Oracle database plus Cognima's multi-threaded Java communications server, hosted on a standards-based J2EE application server and carrier-grade Unix hardware. Section 4 and later sections describe the technical implementation in detail.
  • the Cognima framework replicates data entered in a mobile phone automatically (without any user intervention) to other phones via the Cognima Server. Similarly, data from external systems connected to the Cognima Server is automatically kept up-to-date on mobile phones.
  • Cognima keeps Jill's Before making an personalised content expensive purchase, (including her bank account she needs to know if details) up-to-date her salary has been paid automatically on her mobile into her bank account. phone by periodically (or at a However, she is in the predefined time or even basement of a immediately a change occurs) department store, and sending any changed data to has no network Jill's mobile. The latest data coverage, is there on Jill's phone even before she knows she needs it. She can access it instantly, even if there is no network coverage.
  • Matthew Matthew likes to keep Cognima shares Matthew's his friends informed presence profile with his about his current friends. When he changes availability and his profile (e.g. selects an ‘mood’.
  • Juha Juha also has two With Cognima, SMS, e-mail mobile devices - a and other types of messages phone and a wireless- can be read and sent from enabled PDA. He any device, and also using a needs to read and reply ‘Virtual Phone’ web to e-mail and SMS interface. Messages are messages on both received on all devices used devices, but he gets by the subscriber, and sent confused and messages appear in the frustrated, and loses Outbox on all devices. Any productivity, when his message read on one device Inbox gets out of sync. is instantly marked as read on all other devices. Messages deleted from a mobile phone can be stored and retrieved via the Cognima Server. 1.1 Example Cognima Applications 2. Benefits to the Mobile Subscriber
  • Cognima provides an ideal framework for implementing mass-market consumer data services based on the following key benefits:
  • Cognima presents a MSP with a means to generate new data revenues, reduce churn, and to differentiate its services from those of its competitors.
  • Cognima services act as a significant barrier to churn. For example, a subscriber who stores their personal information securely at their MSP's Cognima Server can buy a new phone and immediately retrieve all personal information to their new device. All this personal information may be lost if they decide to take out a subscription with a different service provider.
  • Cognima gives MSPs the ability to implement services on the handset, and thereby to regain control of their subscribers' user experience. Most importantly, Cognima allows this without sacrificing interoperability; support for industry standards is achieved through straightforward integration with the Cognima Server. The net result is that the MSP's position in the value chain is strengthened versus the powerful brands of handset manufacturers and content providers.
  • Client device A phone, PDA or other machine running the Cognima client software.
  • Cognima A server accessible by client devices which runs the server Cognima server software to replicate data.
  • Replication The process of copying data from a client device up to the Cognima Server and then down to other client devices belonging to the same user.
  • User A human being who owns and uses at least one Cognima client device
  • User data The set of information (contacts, messages, ringtones, pictures etc) that a user might want to store and manipulate on a client device.
  • the objectives of the Cognima software are:
  • Client devices hold a copy of the user's data in a database on the client device. The user can access this data whether or not he has a network connection and therefore always has instant access.
  • the client device connects periodically to a Cognima Server on the wireless network, to send up the changes from the Change-Log and receive new data. This separates the act of changing data from the need to connect to the network (i.e. push is not continuous in a preferred implementation).
  • the Cognima Server updates its own database with data changes received from the client device, and populates Change-Logs for any other devices the user owns. When these devices next connect, they will receive the changes and thus the devices are kept in sync, each with a copy of the same data.
  • the Cognima Server contains a web server which allows the user to examine directly using a web browser the copy of the data held in the Cognima Server database, and make changes to it as he would on a client device.
  • the Cognima Server also acts as a gateway for the user to communicate with other servers on the network/internet.
  • the client device can effectively ask the Cognima Server to send a message as an SMS or an email or a fax by setting a few flags in a message object and the Cognima Server contains the functionality to communicate with email servers, SMS servers and fax machines. This can be extended to servers holding ringtones, banking details, games etc. It is easier and cheaper to build the software on the Cognima Server to talk to these other servers, than it would be to build the software on the client device.
  • All users in a Cognima network are assigned a user id. This id is unique to the network—i.e. provided by a given network operator. All users have a Cognima address which is a combination of their user id and Cognima Server URL. This is unique in the world. Each device which belongs to a user is assigned a device id. The device id is unique to the user. This is only 8 bits so a user can have a maximum of 253 devices (id 254 is reserved for the web, id 255 is spare, id 0 is invalid). All user data is classified into classes (contacts class, messages class, bank transactions class etc) and the classes are assigned a class id which is unique in the world. Class id ‘12’ refers to a contact, for example.
  • An instance of a class is an object, which is assigned an object id unique to the user, e.g. a contacts class object might be the contact for “John Smith”.
  • the object id is generated by concatenating the device id of the device which created the object with a monotonic increasing count which increases over the life of the device. So each device can create a maximum of 16777215 objects (if we encountered this limit we could reset the device id).
  • Classes are defined by the properties which constitute them.
  • a class is essentially an array of properties. Each property in the class has a property id which is unique to the class (and is actually just the array position of the property in the property array, starting from zero). 5.1.2 Creating Objects
  • An object is created on a device. It is assigned an object id and saved to the device database. A copy is also saved into a Change-Log. When the device next connects to the Cognima Server the entry in the Change-Log is sent up. The Cognima Server saves the object to its database (recording the system time), does any class specific processing that may be required (such as generating and sending an email) and adds entries to Change-Logs for any other devices that the user may own which have declared interest in the class. (The entries should be for the correct version of the class on the device).
  • An object may also be created on the web portal.
  • the object id is generated (using device id of 254 as described above) and processed identically to the device. There is no Change-Log for the web portal, it gets selections directly from the Cognima Server database.
  • An object may also be created by a server application (e.g. a messaging module might receive an email from which it creates a message object).
  • the object id is generated (using device id of 254 as described above) and processed identically to the device.
  • One or more properties of an existing object are modified on a device.
  • the changes are saved to the device database.
  • Each changed property is used to generate an entry in the device Change-Log. These are sent up to the Cognima Server.
  • the Cognima Server saves the changes to its database (recording the new ‘last changed’ time for the property), does any required class specific processing and adds entries to Change-Logs for other devices which belong to the user, have declared the class and have a version of the class which contains the property.
  • the update is also placed on the Change-Log for the device that originated the change. This may seem strange but is required to cope with the following scenario:
  • An object is deleted on the device. It is removed from the device database and an entry is put on the Change-Log listing the class id and object id. The entry is sent up to the Cognima Server.
  • the Cognima Server marks the object as deleted in its database, does any class specific processing and adds the entry to other devices that belong to the user and have declared the class.
  • the deleted object is viewable in the web portal a manner that makes its deleted status clear.
  • the user can select the object for un-deletion.
  • the deletion mark is removed from the object in the Cognima Server database and entries to refresh the object are placed on the Change-Logs for all devices that belong to the user and have declared the class.
  • Each property has a type. There are currently 9 permitted property types: Type Type name value Type description KcogTypeRef 0 4 byte object id of another object KcogTypeInt 1 signed 4 byte integer value KcogTypeUInt 2 unsigned 4 byte integer value KcogTypeFloat 3 signed 4 byte floating value KcogTypeStr 4 a CogString (a 4 byte unsigned integer holding the number of characters in the string, followed by the character bytes) KcogTypeTime 5 unsigned 4 byte integer value indicating the number of seconds since midnight 1st Jan 1990 KcogTypeTypedStr 6 unsigned 4 byte integer value followed by a CogString KcogTypeBlob 7 a stream of bytes preceded by a 4 byte unsigned integer which holds the number of bytes KcogTypeArray 8 a blob structure which can hold an array of any kind of data
  • a CogString is a character count followed by the characters. If the string is ASCII then the space taken up by the string will be (4+char count) bytes. If the string is Unicode then the space taken up will be (4+(char count * 2)) bytes.
  • a CogTypedString is a CogString preceded by a type (4 byte unsigned integer).
  • the only use of a typed string so far is a Contact Point.
  • the type identifies the type of contact point (e.g. email address, home phone) and the string holds the address (e.g. bob@xxx.yyy, 01233556677).
  • a CogBlob is a length in bytes followed by that number of bytes. It can be used to store any binary data.
  • a CogArray is passed around as a 4 byte unsigned integer ‘type’ followed by two blobs.
  • the ‘type’ indicates the type of elements held in the array.
  • the first blob is an index blob: it holds a sequence of offsets (4 byte unsigned integers) into the second blob.
  • the second blob is the data blob which holds the elements of the array as a sequence of binary lumps. Elements can be extracted from the data blob by counting along the index blob to get the offset of the start of the element in the data blob.
  • This is the stream structure of the CogArray as it is passed around. Inside a particular system it may appear as a conventional vector (i.e. already parsed).
  • CogArray The only implemented example of a CogArray is the MessageAddress. Each element of the MessageAddress is an AddressPair.
  • An AddressPair is a contact id (object id of a contact object) followed by a Contact Point.
  • Some of the properties can be made “smart”. This means they can be parameterised for a specific device to sculpt the data in the property for the characteristics of the device.
  • the parameters are two 4 byte unsigned integers, one is a smart type and the other is a max size.
  • the property which holds the body text of a message might be parameterised to smart type kCogPlainText and max size 100 on a cheap phone with limited memory, but parameterised to be smart type kCogRichText and max size 1000 on a PDA with more memory.
  • the parameters are stored by the Cognima Server when the application is added to the device.
  • new objects or updates for that class are placed in the Cognima Server Change-Log for that device they are processed according to the smart parameters. This might involve, for example, truncating text, converting Unicode text to narrow text or converting image formats.
  • a new class version may add properties to the end of the old class, but it may not change or remove existing properties, or insert new properties between existing properties. This should allow interoperability between versions. Class definitions with different smart property parameters are not different versions.
  • Class metadata is essentially an array of property metadata.
  • Property metadata is a property id, a property type, a smart type and a max size.
  • User data is transferred as a stream with no formatting information other than a class id. This stream is parsed by looking up the class metadata. So if a stream is received for class 6 and the class metadata for class 6 says that property 0 is a KcogTypeUInt and property 1 is a KcogTypeStr, then you know that the first 4 bytes of the stream should be interpreted as an unsigned integer, the next 4 bytes should be interpreted as an unsigned integer holding the number of characters n in the succeeding string, the next n (times 2 if Unicode) bytes hold the characters in the string etc.
  • Client devices declare to the Cognima Server the classes that they support. This enables the device to subsequently send up only raw user data (with a header containing class id, object id and a few other things) and hence minimises bandwidth requirements. This can be contrasted with, for example, XML reliant systems that are far more bandwidth hungry.
  • the client device class declarations also contain the smart property parameters so that the Cognima Server can sculpt the data for the device. It is worth emphasising that the meaning of a property is hard coded into an application.
  • the class metadata states that property 2 in class 7 is a string with max length 30 characters. It is the code in the application that interprets property 2 in class 7 as the name of a football team.
  • Class Metadata definition tells the CRE (Cognima recognition engine) what type a given property is and allows it to pack and unpack an object or a property for transmission over a data link.
  • CRE Recognition Engine
  • the purpose of the ChangeLog is to record any changes that have occurred since the client device last connected to the Cognima Server (or the Cognima Server to the client device).
  • Cognima APIs applications connect to the CRE and can cause objects to be created or deleted, or a property in an object to be changed. These changes are added to a Change-Log on the local device as they are made together with the time the change was made. Objects are given unique identifiers when they are created so that a given object can always be identified.
  • a Cognima Server receives ChangeLog items from a client device:
  • a device When a device first connects to a Cognima Server it will be sent all class metadata definitions and then all the objects in the database for that user.
  • the Deletion messages generally just mark an Object for deletion. Actual removal of the object from the database may occur later on once all objects referring to that object have also been deleted.
  • Operating systems are fundamentally little endian or big endian which is a choice of the byte order in which numbers and strings are stored. If two computers which have different endian-ness have to communicate then one of the computers will have to switch the endian-ness of its data packets.
  • the Cognima client software uses the same endian-ness as the host client device.
  • the Cognima Server has to determine the endian-ness of the client device (it uses a reference value in the first packet of data from the client) and then convert the subsequent incoming data if necessary to maintain consistent endian-ness in the Cognima Server.
  • the Cognima Server also has to convert any outgoing data it sends back to the client device.
  • the logon of a device contains the current device time.
  • the Cognima Server should be able to compensate for the latency of the network and compare the login time with its own system time. This will give it a delta between the device time and the Cognima Server time. This delta can be applied to further times sent up by the device in that session.
  • the Cognima Server can compare deltas in successive sessions from a device to determine clock ‘creep’ on the device or changes of time zone: it cannot be assumed that all the client devices in the system have clocks that are well synchronised to each other:
  • the server will be responsible for adjusting times used by the client device to GMT when comparisons are made on the Server, and from GMT to the equivalent time for the client device when messages are sent from the Cognima Server to the client device.
  • the client device will tag all the items in the ChangeLog with times obtained from the local clock—as far as the client device is concerned it only ever deals in time based on the client device's own clock.
  • the table below shows a pattern of events with a client device connecting to a Cognima Server.
  • the Client device's time is 5 minutes slower that the Cognima Server and is loosing a minute every hour (an extreme case to show the point).
  • Client Cognima Device Server time Action Time Client device connects to Cognima 09:00 09:05 Server A change is made to property A 10:00 X A change is made to property B 11:00 Y
  • Client device connects to Cognima 12:00 12:08 Server
  • the Cognima Server In order to work out if the property changes were made before or after the time stored on the Cognima Server the times X and Y need to be worked out. From the information above the Cognima Server knows that when the client last connected it was around 3 hours ago and at that point the time difference was 5 minutes whereas now it is 8 minutes. Thus, assuming the clock drift happens linearly, the Cognima Server can work out that the device is 5 minutes behind GMT and that the clock is drifting back a minute every hour.
  • Property B needs to be adjusted to 11:07—the 5 minutes initial drift plus 2 minutes since two hours elapsed from 09:00 to 11:00 when the property was changed.
  • the delta to the time between the client device time and GMT may be minutes, but the drift will be in the order of fractions of seconds per hour.
  • users can also change the time on the client device. They may do this to reset the time to the correct local time (we can give the user the option to have this happen automatically but some users may want to keep their own control of their client device time—e.g. they like to have the clock set 5 minutes fast). They may also make adjustments to reflect a change of local time (i.e. daylight savings or changing timezone). The goal is that the user can change the clock on the device to any time that suits the user and the device simply takes account of this.
  • the client device When the user makes a change to the client device time most operating systems will report this change (for systems that don't do this the time can be polled say every minute to check for such a change). On detecting a change in time the client device will work out the delta between the new time and the time as it was before the change. For example this may be a change of plus one hour as a user moves timezone. The client device stores this time difference as the Adjust Time which it saves for the next connection to the Cognima Server. The client device also goes through every entry in the ChangeLog and updates all times in the log by Adjust Time. This ensures that the entries in the ChangeLog are always relative to the local time on the client device.
  • the client device When the client device next connects to the Cognima Server the client device sends at logon the stored Adjust Time—i.e. the amount by which the client device clock has been adjusted backwards or forwards since the last connection.
  • the Cognima Server can then remove this amount from the time from the delta to GMT and drift calculation.
  • the same set of calculations can be made in reverse to convert the GMT times of changes made on the Cognima Server to the correct local time for a given client device.
  • An application will use one or more classes to hold user data.
  • the definition of the class is hard coded into the application.
  • the version of the class is coordinated by releases of the application.
  • a statistics application uses a Footballer class to hold data about footballers.
  • the application starts on a client device for the first time, it inquires from the device what version of the Footballer class the device already holds. If the version on the device is the same as the version that the application has been hard coded to use then nothing more need be done.
  • the Cognima Server therefore maintains a list of versions of classes used on all devices.
  • the web portal pages will be the equivalent of the hard-coded device application.
  • the web can extract objects from the database according to the latest version of the class, and if there are more properties than it was hard coded to expect it can ignore them. Therefore the web does not need to declare class versions.
  • the Cognima Server maintains Change-Logs for all devices listing changes that will be sent to the devices when the devices next connect. There will be optimisations that can be made to the Change-Logs, for example:
  • the space available on a client device to hold user data will typically be orders of magnitude less than the space available on the server.
  • the device needs to hold a subset of data and the user should have to do as little work as possible to maintain this subset. ghosting and withdrawal are tools to aid this.
  • a class definition may include flagging certain properties as ‘ghostable’. This means that if the object is ghosted those properties will be nulled, freeing room on the client device. Ghosting is done automatically on the device.
  • the decision about which objects to ghost is made by following a ‘ghosting rule’ and applying the rule whenever an object is created or updated.
  • the rule defines the maximum number of a selection of objects. When the maximum is exceeded the objects in the selection at the bottom of a sort order are ghosted.
  • the class might be messages
  • the selection might be messages in the inbox
  • the sort order might be by date/time
  • the maximum number might be 50. If there are 50 messages in the inbox and a new message arrives, the oldest message in the inbox is ghosted. ghosting may remove the message body but leave enough header information for the message to be recognised.
  • Withdrawal also known in the past as auto-deletion and removal
  • Withdrawal is similar to ghosting but works by removing the entire object, not just part of it.
  • a request is passed from the client to the Cognima Server for the object to be resurrected.
  • a refresh of the object is sent down to the device and the object is put back to normal.
  • a pinned object is never ghosted or removed.
  • Pinning can be chosen by the user, or it can happen automatically. For example, an object that is resurrected is automatically pinned.
  • a set of one or more Cognima addresses is attached to the object which is to be shared.
  • the object can be set to read-only (so the people you share it with cannot modify it).
  • the Cognima Server receives the new object (or receives an update to it) from the web or a client device it replicates it as normal.
  • the Cognima Server of the sharee receives the object. If it is a new object it assigns a new object id (keeping note of the originator id). If it is an update it finds the object using the originator id.
  • the update can be replicated back to the object owner using the originator id.
  • This approach is similar to the screen re-paint approach used to redraw graphics screens on Windowing systems.
  • the application that is responsible for that bit of screen is called to repaint the screen.
  • a client device may have a contacts application running on it—this device replicates data with a Cognima Server connected to other client devices also running contacts applications.
  • a class of object is defined for a Contact that contains names and phone numbers and these are replicated to all the devices of a given user.
  • An application on one device may have a display that shows all contacts by beginning letter—for example the interface allows the user to press a D button to show all the names beginning with D.
  • This application will set up a selection that contains objects:
  • the application also defines code to be called by the CRE when objects are added, deleted or updated.
  • Sorting order can be specified: the properties to sort on, in what order and what sorting algorithms to use.
  • a view provides this functionality by specifying the number of items of data the selection wants to deal with and the number of the first item of data out of the complete list of data the application wants to appear in the selection.
  • Views are important because they allow an application to limit the amount of data it stores locally to be limited to just the amount needed to display on the screen this reducing unnecessary duplication of data.
  • Cognima has made some efficiency optimisations in how the data is transferred between the Cognima server and client application—when multiple data changes are made the data is sent in blocks and then the application informed that the changes are complete so that the application only needs to update its user interface once.
  • ContactSelection This is the code that the framework will call back whenever a change is made to any of the selected objects. In the Cognima framework this is implemented as an object which you derive from the COdbSelect templated class—specifiying the type of object you want to have in the selection as the template argument.
  • class CContactSelect public COdbSelect ⁇ CContact> ⁇ public: CContactSelect(COdb *aOdb); void ObjectAdded(CContact *aObject); void ObjectUpdated(CContact *aObject); void ObjectRemoved(const TOdbObjectId aObjectId); private: bool ListContacts( ); ⁇ ;
  • the methods ObjectAdded( ), ObjectUpdated( ) and ObjectRemoved( ) are called by the framework whenever respectively an object is added, updated or removed.
  • you don't need to implement all these methods if you do not want to take instance action on any of these events—in some cases you may set up a selection to keep a list of a certain set of objects but only check that list on some other event and so the above methods would not be required.
  • CContactSelect::CContactSelect(COdb *aOdb) COdbSelect ⁇ CContact>(aOdb) ⁇ ⁇ void CContactSelect::ObjectAdded(CTestContact *aContact) ⁇ OdbLog(OdbLogApp,L“New contact added: ” ⁇ aContact->GetName( )); ListContacts( ); ⁇ void CContactSelect::ObjectUpdated(CTestContact *aContact) ⁇ OdbLog(OdbLogApp,L“Contact updated: ” ⁇ aContact->GetName( )); ListContacts( ); ⁇ void CContactSelect::ObjectRemoved(const TOdbObjectId aObjectId) ⁇ OdbLog(OdbLogApp,L“Contact deleted - Id: ” ⁇ aObjectId); ListContacts( ); ⁇ void CContactSelect::ListContacts( ) ⁇
  • the constructor simply calls the default COdbSelect constructor.
  • the ObjectAdded( ), Updated( ) and Removed( ) methods print out what change was made and then call ListContacts( ) to show what the current contents of the list is.
  • the ListContacts( ) shows how the current list of object held by the selection can be accessed.
  • the current list of pointers to objects is held in a container class called iResult—this can then be accessed by normal container class integrators. In this case we simply go through the list and print all the objects in the list.

Abstract

A system and method of replicating database records for use in resource constrained wireless computing devices. The replication method has a low processing burden and is well suited to low-bandwidth, unreliable connections found in many wireless networks. To reduce the amount of memory used on the wireless device only a change log record is time-stamped, not every database record. The change log defines what data is to be replicated and needs to sent to a main server that hosts a master copy of the database. The change log is made compact to reduce the amount of data that needs to be sent for data replication by only requiring the field that has changed in a record and a timestamp to be sent, not the entire record in which the change was made.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This is a continuation of U.S. application Ser. No. 10/496,898, filed May 25, 2004, which is the U.S. National Stage of International Application No. PCT/GB02/05308, filed Nov. 26, 2002, which is based on and claims priority to British Application No. GB 01282433, filed Nov. 26, 2001, the contents of which are incorporated fully herein by reference.
  • FIELD OF THE INVENTION
  • This invention relates to a method of replicating data between computing devices, particularly data from resource constrained wireless devices (i.e. devices with limited processing power and limited battery life) such as mobile telephones and personal organisers that are synchronising to and from a server over a wireless network.
  • Description of the Prior Art
  • Data replication between computing devices occurs in many different contexts, such as synchronising documents, e-mails, contacts and calendar entries across different computing devices used by the same person. In order for data replication to be accurate, there must be some system for deciding which of two or more inconsistent data replication requests should be acted on. Take for example the situation where, at time 1, a user enters a change to his e-mail details for person X on his mobile telephone. Some time later, at time 2, the user realises that those changes were in fact wrong. He makes a further change to those person X email detail, but does so on a PC. At time 3, he synchronises his PC to a master server, updating the master record of person X's e-mail to the correct address. But suppose later still, at time 4, he synchronises his mobile telephone with the master server—this would potentially over-write the correct person X email details (entered at time 2) with the incorrect details entered originally at time 1.
  • To address this problem, synchronisation systems typically employ time based arbitration rules, such as giving priority to the latest recorded change (time 2 as compared to time 1 in the example above). This requires a device to be able to associate a time stamp with data to indicate when that data was changed on the device; this is commonly done for wire-line based devices (as opposed to devices communicating over a wireless network) by providing a database on a computing device which stores data of a given type (e.g. a database for all contacts details for an individual—name, e-mail, telephone, mobile etc; these form a single contact record. There would typically be another database for e-mail, another for calendar entries etc.). Whenever anything in a given record is changed (e.g. a new e-mail address for an individual), then the device logs that change as part of the record and time stamps it (again, as an entry forming part of the record) with the time established by a quartz clock running locally on the device. Changes to data (e.g. the new e-mail contact details for the individual) are then sent to a central server; an entire replacement record is usually sent (e.g. all existing contact details for the individual, plus the new e-mail address, plus the time stamp)—the central server then updates its master copy of the information and sends updating information to any devices so that all maintain the same information. The central server typically applies arbitration rules using the time stamp to resolve conflicts between competing and inconsistent synchronisation requests.
  • Conventional wire based data replication systems are therefore reliant on time stamps applied to database records. The time stamps are made by a local quartz clock running on the device into which the changed data was first input. This device could be a client device, server or peer.
  • For resource constrained wireless devices, essentially the same approach is used, although it is normal for the database record itself to be a fixed length record; this facilitates indexing since the boundaries between records can be readily determined. However, this results in records including a ‘null’ entry in the time stamp field to indicate that no change has been made to those records or in keeping the last time stamp even though it pre-dates a synchronisation to a server keeping a master database and is hence superfluous. Both approaches occupy unnecessary memory space. Further, when synchronisation takes place, a synchronisation engine on the device has to analyse all records in a database (usually in a logical sequence), copying the entirety of any records that has a time stamp post-dating the last synchronisation time and then sending that to the server. The process of analysing all database records can be slow on a resource constrained wireless device, uses up valuable processor capacity and drains power.
  • SUMMARY OF THE PRESENT INVENTION
  • In accordance with a first aspect of the present invention, there is a method of replicating data between computing devices, in which a first computing device 12 is given responsibility for determining whether data received from a wireless, portable computing device 14 over a wireless network 16 is replicated or not; wherein the method comprises the steps of the wireless, portable computing device:
  • (a) generating and storing 28 time stamps in a change log 18, the change log 18 including data only for records 20 that have changed; and
  • (b) sending 30 those change logs 18 to the first computing device 12 in order to replicate 32 data in the change log in a master copy database 22 running on the first computing device 12
  • wherein the method further comprises the step of the wireless, portable computing device 14 registering 26 new metadata definitions 28 with the first computing device 12 to define how change logs relating to a new application 24 will be presented by the wireless computing device 14.
  • This approach enables resource constrained wireless, portable computing devices (e.g. mobile telephones) to provide a data replication capability (e.g. backing up databases, such as contacts, e-mails, photographs onto a remote device—a server or peer storing a master copy of the database) without undue processing burden, using low bandwidth unreliable wireless connections. It does this by de-coupling the change log from the database which has been changed; this in turn means that far less data has to be sent to the remote device—typically only the field which has changed, how it was be changed and when it was changed on the wireless computing device. Prior art systems typically send an entire record, even though that will contain data that has not changed. Further, by not including a time stamp in the database itself, but instead time stamping only the change log records, this approach saves considerable memory space on the wireless device since there is no need to time stamp every database record, as is usually done in the prior art. Typically, the change log records only changes that have occurred since the last data replication between the wireless computing device and the first computing device; prior art systems often waste valuable memory by recording time stamps that pre-date synchronisations.
  • The wireless computing device and the first computing device (which is not necessarily a portable device, but more usually a large server) share metadata that defines the proper interpretation of the change log. The wireless computing device may register new metadata definitions with the first computing device to define how change logs relating to a new application will be presented by the wireless computing device.
  • Another feature is that the change logs are automatically sent by the wireless computing device to the first computing device without any user intervention. This may be (a) at pre-defined periodic intervals, (b) at pre-defined times or (c) continuously whenever a change log is created. In any event, because the master database on the first computing device is kept up to date, the problems that can arise with a user manually synchronising the same data from several different devices (as explained in the prior art section) are far less likely to arise.
  • Multiple change logs can be batched up; these may be sent at times which depend on the importance of the change log being rapidly processed by the first computing device, with low priority change logs being sent at times of lower network traffic (hence incurring lower charges). Similarly, individual records in a change log can be sent at times which depend on the importance of the records being rapidly processed by the first computing device, with low priority records again being sent at times of lower network traffic.
  • In a second aspect, there is a wireless, portable computing device programmed to send data to a first computing device over a wireless network, in order for the first computing device to replicate that data; wherein the wireless computing device is programmed to:
  • (a) run a database with records that do not include a time stamp field to indicate when a field entry in the database has altered, and
  • (b) generate and store time stamps in a change log, separate from the database, the change log including data only for records that have changed; and
  • (c) send those change logs to the first computing device in order to replicate data in the change log in a database running on the first computing device.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a schematic drawing of one embodiment of the present invention; and
  • FIG. 2 is a flow diagram detailing steps in one embodiment of the present invention.
  • DETAILED DESCRIPTION
  • The present invention will be described with reference to an implementation from Cognima Limited of London, United Kingdom. Cognima has developed a data replication technology that directly addresses the need for Mobile Service Providers (MSPs) and Network Operators to increase consumer adoption of data services, encourage greater loyalty from their valuable customers, and differentiate their services from the competition.
  • Cognima's data replication solution addresses these issues by:
      • Increasing adoption by making data services compelling and effortless to use.
      • Establishing a high barrier to churn by securely backing up subscribers' personal data on servers controlled by those subscribers' MSP.
      • Enabling the MSP to create differentiated services by controlling the customer experience.
        1. Overview of uses for the Cognima Data Replication Framework
  • Cognima's data replication framework enables a Mobile Service Provider to build compelling services for consumer markets. The MSP hosts a Cognima Server at its data centre. The server comprises an Oracle database plus Cognima's multi-threaded Java communications server, hosted on a standards-based J2EE application server and carrier-grade Unix hardware. Section 4 and later sections describe the technical implementation in detail.
  • The Cognima framework replicates data entered in a mobile phone automatically (without any user intervention) to other phones via the Cognima Server. Similarly, data from external systems connected to the Cognima Server is automatically kept up-to-date on mobile phones.
  • Mobile subscribers using Cognima-enabled applications experience an always-available, instant connection to their personal information and friends.
      • Personal information can include the subscriber's address book, messages, bank account details, stock prices, pizza orders, calendar, current traffic on a route to work, or any other personalised content. The data is always kept securely backed-up on the Cognima Server and automatically replicated on all relevant client devices.
      • Always-available means that the personal information is accessible on whichever device or handset the subscriber is carrying, whether currently connected to the network or not since the user can always access personal information stored locally on the device). Users can also edit and manage their personal data directly on the server via a web interface—the Virtual Phone.
      • Instant means that subscribers do not have to wait for data to download from a server; the latest information is on their handsets even before they know they need it since that data is automatically sent to the handset (e.g. polling by the handset may occur; this can be regular periodic—such as every 30 minutes or at pre-defined times (4 pm, 5 pm etc). Pushing to the handset may also occur).
  • Subscribers can share their data across multiple devices and with their friends since the Cognima Server can replicate this data to any defined device or defined individual.
    Customer Need Cognima Application
    Sarah Sarah's phone has been Whenever Sarah enters data
    stolen, including some in her phone, Cognima
    important contact automatically backs it up on a
    numbers and messages central server at the MSP's
    for which she has made data centre. Sarah can buy a
    no manual back-up new mobile phone, and
    copy. retrieve all her contacts and
    messages instantly from the
    central server, as long as she
    remains with the same MSP.
    She can also delete her data
    from the stolen phone via the
    MSP's portal.
    Jill Jill is out shopping. Cognima keeps Jill's
    Before making an personalised content
    expensive purchase, (including her bank account
    she needs to know if details) up-to-date
    her salary has been paid automatically on her mobile
    into her bank account. phone by periodically (or at a
    However, she is in the predefined time or even
    basement of a immediately a change occurs)
    department store, and sending any changed data to
    has no network Jill's mobile. The latest data
    coverage, is there on Jill's phone even
    before she knows she needs
    it. She can access it
    instantly, even if there is no
    network coverage.
    Matthew Matthew likes to keep Cognima shares Matthew's
    his friends informed presence profile with his
    about his current friends. When he changes
    availability and his profile (e.g. selects an
    ‘mood’. He also likes icon to indicate he's feeling
    to see what his friends sociable) the icon updates
    are up to. He's mainly automatically in Matthew's
    interested in keeping address book entry on his
    track of what's friends' phones. Matthew
    happening in his social can see presence information
    group, and he wants to for all his friends at a glance
    do this at a glance, on his own phone. He can
    without having to go even ask his phone to alert
    ‘on-line’ or send lots of him when a friend is feeling
    expensive messages. sociable or bored, so that he
    can immediately call.
    Laura Laura has two mobile Cognima automatically keeps
    phones - one she uses all the data in Laura's phones
    at work, and a fashion- in step. Whenever she edits
    phone she takes out in data on one handset, it is
    the evenings. She immediately (or periodically
    wants to keep the same or at a predefined time)
    address book on both replicated onto the Cognima
    devices, but she hates server which then updates her
    entering data twice, and other phone as well. She
    she's never figured out never has to remember to
    how to use the sync press a ‘sync button’ - it just
    software that came with happens. Jill even shares
    her phone. Swapping some of the contacts in her
    the SIM card over is phone with her husband,
    cumbersome, and Geoff. When Geoff enters
    leaves behind data in his mother's new mobile
    the phone memory. number, it is automatically
    updated in Jill's phones as
    well.
    Juha Juha also has two With Cognima, SMS, e-mail
    mobile devices - a and other types of messages
    phone and a wireless- can be read and sent from
    enabled PDA. He any device, and also using a
    needs to read and reply ‘Virtual Phone’ web
    to e-mail and SMS interface. Messages are
    messages on both received on all devices used
    devices, but he gets by the subscriber, and sent
    confused and messages appear in the
    frustrated, and loses Outbox on all devices. Any
    productivity, when his message read on one device
    Inbox gets out of sync. is instantly marked as read on
    all other devices. Messages
    deleted from a mobile phone
    can be stored and retrieved
    via the Cognima Server.

    1.1 Example Cognima Applications
    2. Benefits to the Mobile Subscriber
  • Cognima provides an ideal framework for implementing mass-market consumer data services based on the following key benefits:
      • Friendliness: no user intervention is required. Subscribers never need to press a ‘sync’ or ‘download’ button to access their data. System configuration and secure data transfer are completely transparent to the end user.
      • Instant availability: the user is always able to interact instantly with local data (even when off-line), whilst any updates take place silently in the background. For example, users can read their personalised content whilst on an underground train. The user experience is separated from the data transport.
      • affordability: The MSP can control when replication takes place, and the Quality of Service (QoS) delivered. However, because the user experience is separated from the data transport, lower QoS does not affect the user's perception of the service. Crucially, this allows the MSP to offer low-cost, subscription-based services with relatively poor QoS without sacrificing user experience—e.g. data replication can happen overnight for non-urgent data services such as bank statements, yet still be satisfactory to users. Overnight data replication uses otherwise underused bandwidth and is hence far cheaper than peak time data replication. Urgent data replication (e.g. presence information) can happen at any time on a periodic or (optionally) continuous (push) basis and attract a higher charging rate. Furthermore, efficient use of phone memory & processor power allows Cognima client software to be cost-effectively installed in even the cheapest mass-market phones.
        3. Benefits to the Mobile Service Provider
  • Cognima presents a MSP with a means to generate new data revenues, reduce churn, and to differentiate its services from those of its competitors.
  • 3.1 Increased Usage of Existing Mobile Services
  • Cognima increases usage of existing mobile services:
      • Messaging and content-based services become much more convenient and immediate, and will therefore be used more.
      • The enhanced immediacy of presence information increases the use of chat and Instant Messaging, and an alert when free capability will boost voice calls.
      • Effortless management of multiple devices allows users to carry an appropriate phone on any occasion, and therefore make more calls and send more messages.
        3.2 Compelling New Services
  • Cognima enables rapid introduction of compelling and affordable new mobile data services.
      • Cognima delivers a compelling user experience for new services in low-end phones using only spare network capacity. This is affordable and scalable for the network operator, allowing the MSP to offer understandable and predictable pricing for mass-market subscribers.
      • Most of the application development for new Cognima services takes place on the server side, allowing the MSP to bring new services to market quickly.
      • Cognima's client software can be installed as a flash memory upgrade, endowing today's mass-market handsets with smart-phone-like capabilities. New software applications can be downloaded over the air to existing Cognima-enabled handsets, allowing MSPs to roll out new data services without waiting for new devices to support them.
      • Third party application developers can leverage the MSP's Cognima infrastructure to develop new applications for the MSP's network.
        3.3 Churn Reduction
  • Cognima services act as a significant barrier to churn. For example, a subscriber who stores their personal information securely at their MSP's Cognima Server can buy a new phone and immediately retrieve all personal information to their new device. All this personal information may be lost if they decide to take out a subscription with a different service provider.
  • 3.4 Differentiation
  • Today, subscribers have the same basic experience of using mobile data services on all networks. For example, the experience of using WAP services is defined by the WAP protocols, the browser in the phone, and the content accessed. Many MSPs have realised that they must differentiate themselves by giving their subscribers a unique user experience, but are hindered from doing so by severe constraints to customising the services in mobile handsets.
  • Cognima gives MSPs the ability to implement services on the handset, and thereby to regain control of their subscribers' user experience. Most importantly, Cognima allows this without sacrificing interoperability; support for industry standards is achieved through straightforward integration with the Cognima Server. The net result is that the MSP's position in the value chain is strengthened versus the powerful brands of handset manufacturers and content providers.
  • 4. Cognima Data Replication Framework Functional Design
  • 4.1 Introduction
  • This and subsequent sections of the Detailed Description are intended to describe how the Cognima data replication system actually works. It covers the behaviour of client devices, the Cognima Server and the web client, without going into details of specific hardware, programming language, software class design or environment. It does describe the basic data structures and algorithms used.
  • Terms
    Client device A phone, PDA or other machine running the Cognima
    client software.
    Cognima A server accessible by client devices which runs the
    server Cognima server software to replicate data.
    Replication The process of copying data from a client device up to
    the Cognima Server and then down to other client
    devices belonging to the same user.
    User A human being who owns and uses at least one Cognima
    client device
    User data The set of information (contacts, messages, ringtones,
    pictures etc) that a user might want to store and
    manipulate on a client device.

    4.2 Purpose
  • The objectives of the Cognima software are:
      • To allow a user instant access to view and modify an ‘up to date’ copy of their data on multiple handheld devices capable of wireless data connectivity.
      • To allow a user to view and modify the same data using a conventional web browser.
      • To effortlessly provide secure backup of a user's data.
      • To give a user powerful data functionality on a cheap handset by displacing complicated and expensive processing to a server.
        4.3 Highest Level Description
  • Client devices hold a copy of the user's data in a database on the client device. The user can access this data whether or not he has a network connection and therefore always has instant access. When a user changes the data on his device, the changes are copied to a Change-Log. The client device connects periodically to a Cognima Server on the wireless network, to send up the changes from the Change-Log and receive new data. This separates the act of changing data from the need to connect to the network (i.e. push is not continuous in a preferred implementation). The Cognima Server updates its own database with data changes received from the client device, and populates Change-Logs for any other devices the user owns. When these devices next connect, they will receive the changes and thus the devices are kept in sync, each with a copy of the same data.
  • The Cognima Server contains a web server which allows the user to examine directly using a web browser the copy of the data held in the Cognima Server database, and make changes to it as he would on a client device. The Cognima Server also acts as a gateway for the user to communicate with other servers on the network/internet. For example, the client device can effectively ask the Cognima Server to send a message as an SMS or an email or a fax by setting a few flags in a message object and the Cognima Server contains the functionality to communicate with email servers, SMS servers and fax machines. This can be extended to servers holding ringtones, banking details, games etc. It is easier and cheaper to build the software on the Cognima Server to talk to these other servers, than it would be to build the software on the client device.
  • 5. Lower Level Concepts
  • 5.1 Data Structures
  • 5.1.1 Ids
  • Cognima user data is described using the terminology of object databases: classes and objects. Unfortunately, there is room for confusion with similarly named OO programming concepts and care therefore needs to be taken.
  • All users in a Cognima network are assigned a user id. This id is unique to the network—i.e. provided by a given network operator. All users have a Cognima address which is a combination of their user id and Cognima Server URL. This is unique in the world. Each device which belongs to a user is assigned a device id. The device id is unique to the user. This is only 8 bits so a user can have a maximum of 253 devices (id 254 is reserved for the web, id 255 is spare, id 0 is invalid). All user data is classified into classes (contacts class, messages class, bank transactions class etc) and the classes are assigned a class id which is unique in the world. Class id ‘12’ refers to a contact, for example.
  • An instance of a class is an object, which is assigned an object id unique to the user, e.g. a contacts class object might be the contact for “John Smith”. The object id is generated by concatenating the device id of the device which created the object with a monotonic increasing count which increases over the life of the device. So each device can create a maximum of 16777215 objects (if we encountered this limit we could reset the device id). Classes are defined by the properties which constitute them. A class is essentially an array of properties. Each property in the class has a property id which is unique to the class (and is actually just the array position of the property in the property array, starting from zero). 5.1.2 Creating Objects
  • An object is created on a device. It is assigned an object id and saved to the device database. A copy is also saved into a Change-Log. When the device next connects to the Cognima Server the entry in the Change-Log is sent up. The Cognima Server saves the object to its database (recording the system time), does any class specific processing that may be required (such as generating and sending an email) and adds entries to Change-Logs for any other devices that the user may own which have declared interest in the class. (The entries should be for the correct version of the class on the device).
  • An object may also be created on the web portal. The object id is generated (using device id of 254 as described above) and processed identically to the device. There is no Change-Log for the web portal, it gets selections directly from the Cognima Server database.
  • An object may also be created by a server application (e.g. a messaging module might receive an email from which it creates a message object). The object id is generated (using device id of 254 as described above) and processed identically to the device.
  • 5.1.3 Updating Objects
  • One or more properties of an existing object are modified on a device. The changes are saved to the device database. Each changed property is used to generate an entry in the device Change-Log. These are sent up to the Cognima Server.
  • If the time of the update is later than the ‘last changed’ time for the property in the Cognima Server database then the Cognima Server saves the changes to its database (recording the new ‘last changed’ time for the property), does any required class specific processing and adds entries to Change-Logs for other devices which belong to the user, have declared the class and have a version of the class which contains the property. The update is also placed on the Change-Log for the device that originated the change. This may seem strange but is required to cope with the following scenario:
      • A user has 2 devices A and B. He updates property 7 on A offline at 5 pm and updates it on B offline at 6 pm. He connects to the network with A first. The value of 7 on A gets put in the Change-Log to be sent to B. Later B connects. Its value of 7 is more recent so the value of 7 on B is sent to A, but B gets A's value. Replicating the value of 7 back to B fixes this.
  • If an update is received by the Cognima Server for an object which is marked as deleted and the update is later than the deletion, then this is interpreted as an un-deletion. The object is undeleted, updated and then a refresh of the object in placed on the Change-Logs for all appropriate devices. Updates from the web portal or server applications work in the same way.
  • 5.1.4 Deleting Objects
  • An object is deleted on the device. It is removed from the device database and an entry is put on the Change-Log listing the class id and object id. The entry is sent up to the Cognima Server.
  • If the time of the deletion is later than the last updated time of the object, then the Cognima Server marks the object as deleted in its database, does any class specific processing and adds the entry to other devices that belong to the user and have declared the class.
  • If the time of deletion is earlier than the last updated time then this indicates that the deletion is invalid and a refresh of the object is put on the Change-Log for the device which originated the deletion.
  • The deleted object is viewable in the web portal a manner that makes its deleted status clear. The user can select the object for un-deletion. The deletion mark is removed from the object in the Cognima Server database and entries to refresh the object are placed on the Change-Logs for all devices that belong to the user and have declared the class.
  • 5.1.5 Property Types
  • Each property has a type. There are currently 9 permitted property types:
    Type
    Type name value Type description
    KcogTypeRef 0 4 byte object id of another
    object
    KcogTypeInt 1 signed 4 byte integer value
    KcogTypeUInt 2 unsigned 4 byte integer value
    KcogTypeFloat 3 signed 4 byte floating value
    KcogTypeStr 4 a CogString (a 4 byte unsigned
    integer holding the number of
    characters in the string,
    followed by the character
    bytes)
    KcogTypeTime 5 unsigned 4 byte integer value
    indicating the number of
    seconds since midnight 1st Jan
    1990
    KcogTypeTypedStr 6 unsigned 4 byte integer value
    followed by a CogString
    KcogTypeBlob 7 a stream of bytes preceded by a
    4 byte unsigned integer which
    holds the number of bytes
    KcogTypeArray 8 a blob structure which can hold
    an array of any kind of data
  • A CogString is a character count followed by the characters. If the string is ASCII then the space taken up by the string will be (4+char count) bytes. If the string is Unicode then the space taken up will be (4+(char count * 2)) bytes.
  • A CogTypedString is a CogString preceded by a type (4 byte unsigned integer). The only use of a typed string so far is a Contact Point. The type identifies the type of contact point (e.g. email address, home phone) and the string holds the address (e.g. bob@xxx.yyy, 01233556677).
  • A CogBlob is a length in bytes followed by that number of bytes. It can be used to store any binary data.
  • A CogArray is passed around as a 4 byte unsigned integer ‘type’ followed by two blobs. The ‘type’ indicates the type of elements held in the array. The first blob is an index blob: it holds a sequence of offsets (4 byte unsigned integers) into the second blob. The second blob is the data blob which holds the elements of the array as a sequence of binary lumps. Elements can be extracted from the data blob by counting along the index blob to get the offset of the start of the element in the data blob. This is the stream structure of the CogArray as it is passed around. Inside a particular system it may appear as a conventional vector (i.e. already parsed).
  • The only implemented example of a CogArray is the MessageAddress. Each element of the MessageAddress is an AddressPair. An AddressPair is a contact id (object id of a contact object) followed by a Contact Point.
  • 5.1.6 Smart Property Parameters
  • Some of the properties can be made “smart”. This means they can be parameterised for a specific device to sculpt the data in the property for the characteristics of the device. In practice the parameters are two 4 byte unsigned integers, one is a smart type and the other is a max size. For example, the property which holds the body text of a message might be parameterised to smart type kCogPlainText and max size 100 on a cheap phone with limited memory, but parameterised to be smart type kCogRichText and max size 1000 on a PDA with more memory.
  • The parameters are stored by the Cognima Server when the application is added to the device. When new objects or updates for that class are placed in the Cognima Server Change-Log for that device they are processed according to the smart parameters. This might involve, for example, truncating text, converting Unicode text to narrow text or converting image formats.
  • It is important for data integrity that the object held in the Cognima Server database be a copy of the object as it was generated. Even if you see a cut down version on a device you can effectively manipulate the complete version on the Cognima Server.
  • 5.1.7 Class Versions
  • We have the concept of a class version which is defined by a 4 byte unsigned integer. A new class version may add properties to the end of the old class, but it may not change or remove existing properties, or insert new properties between existing properties. This should allow interoperability between versions. Class definitions with different smart property parameters are not different versions.
  • 5.2 Passing User Data Around
  • Cognima utilises the idea of class metadata to minimise the data that needs to be copied around between databases. Class metadata is essentially an array of property metadata. Property metadata is a property id, a property type, a smart type and a max size.
  • User data is transferred as a stream with no formatting information other than a class id. This stream is parsed by looking up the class metadata. So if a stream is received for class 6 and the class metadata for class 6 says that property 0 is a KcogTypeUInt and property 1 is a KcogTypeStr, then you know that the first 4 bytes of the stream should be interpreted as an unsigned integer, the next 4 bytes should be interpreted as an unsigned integer holding the number of characters n in the succeeding string, the next n (times 2 if Unicode) bytes hold the characters in the string etc.
  • Client devices declare to the Cognima Server the classes that they support. This enables the device to subsequently send up only raw user data (with a header containing class id, object id and a few other things) and hence minimises bandwidth requirements. This can be contrasted with, for example, XML reliant systems that are far more bandwidth hungry.
  • The client device class declarations also contain the smart property parameters so that the Cognima Server can sculpt the data for the device. It is worth emphasising that the meaning of a property is hard coded into an application. The class metadata states that property 2 in class 7 is a string with max length 30 characters. It is the code in the application that interprets property 2 in class 7 as the name of a football team.
  • 5.2.1 Data Replication Issues in More Depth
  • Data is held in Objects that are created on client devices and the server these devices connect to (known as the Cognima Server). These objects and any changes made to them are replicated between the client devices and the Cognima Server.
  • The design of the replication process allows:
      • A set of objects to be defined that will be replicated so that the same set of objects will be held on a Cognima Server and all the client devices that are logged on to that server for a given user. New objects created on any device or the server will be replicated to all other devices. Changes in any property of an object will be replicated to all devices.
      • Only the minimum data to be transmitted across the network for a given update since only changes in data are sent from clients to the Cognima Server or vice versa.
      • A key part of the design was to not require times of modification to be kept for each property of an object on the client device as updating these on constrained client devices is slow and keeping a last modified time for each property in an object would take a lot of space.
      • On the Cognima Server storing modification times for all properties of an object is fine as the server has enough storage space and processing power to deal with this.
        5.2.2 Metadata
  • In order for the system to work it needs a clear idea of what properties are defined for a given class of objects. This is done by providing the programmer with a few C++ compiler macros that allow definition of the class metadata.
  • The definition of the properties to be used in a class result in a Class Metadata definition. This definition tells the CRE (Cognima recognition engine) what type a given property is and allows it to pack and unpack an object or a property for transmission over a data link. In order for the CRE system to work all clients and the server must have the same class metadata definition. Thus the following occurs:
      • When a new Metadata definition is declared on a client device it is sent to the Cognima Server and from there the Cognima Server will send it to all other clients.
      • When a new Metadata definition is declared on a Cognima Server the definition is sent to all client devices.
      • When a new client device logs on to a Cognima Server for the first time all of the metadata definitions are sent to that device before any objects are sent.
      • In all of the above cases a future optimisation may be made so that the Cognima Server only sends the metadata definition to clients who access the class (and the specific properties) the metadata refers to.
        5.2.3 ChangeLog
  • The purpose of the ChangeLog is to record any changes that have occurred since the client device last connected to the Cognima Server (or the Cognima Server to the client device). Using Cognima APIs, applications connect to the CRE and can cause objects to be created or deleted, or a property in an object to be changed. These changes are added to a Change-Log on the local device as they are made together with the time the change was made. Objects are given unique identifiers when they are created so that a given object can always be identified.
  • In the same way, creation and deletion of objects and changes to object properties by applications running on the Cognima Server result in the changes being added to all the Change-Logs of all the client devices registered to that user on the Cognima Server. The time of changes are recorded for each object or property.
  • ChangeLogs can be built in two ways:
      • As the new objects are created and properties are changed (this is normally the case for client devices)
      • Or they can be built on demand when they are needed by using the last modified times of objects and properties if these are stored on the system (in some circumstances, this method may be used on the Cognima Server instead of the above method).
        5.2.4 Replication
  • When a client device has items in its ChangeLog to send it will connect to the Cognima Server (and likewise for the Cognima Server connecting to the client device). By default, the items in the ChangeLog are sent in the order in which they were added to the ChangeLog, however they may be re-prioritised immediately before sending to provide for premium services, urgent data and so on. Items transferred are:
      • A metadata definition including the type of each property of a given class of objects.
      • A new object that has been created—with the contents of the properties of that object.
      • A property has been changed—with the new value of the property.
      • An object has been deleted.
  • In all the above cases the appropriate IDs are sent to identify the object, class and properties involved. All ChangeLog items are marked with the time the item was added to the ChangeLog. These times are always local machine times and are resolved into GMT by the Time Management approach described in Section 6.2.
  • When a client device receives ChangeLog items from a Cognima Server:
      • When a client device receives a new object message from a Cognima Server it adds this new object to its local database.
      • When a client device receives an object deletion message from a Cognima Server it marks the object as deleted in its local database.
      • When a client device receives a property change it is always assumed that the Cognima Server is authoritative on the current state of the database and so the change is always made to the value of the property held in the local database.
  • A Cognima Server receives ChangeLog items from a client device:
      • When a Cognima Server receives a new object from a client device it is added to the Cognima Server database and also added to all the Change-Logs of the client devices registered to that user, apart from the Change-Log of the machine that sent the new object in the first place.
      • When a Cognima Server receives an object deletion from a client device the object is marked for deletion and an object deletion message is added to all the Change-Logs of the devices registered to that user apart from the Change-Log of the machine that sent the object deletion in the first place.
      • When a Cognima Server receives a property change it compares the time of the change to the current time held for that property on the Cognima Server. If the time of the property change is later than that held on the Cognima Server the property value is changed in the server database and this change is also added all the Change-Logs of the client devices registered to that user—including the one of the machine that sent in property change (in case another object update has been sent to that machine in the meantime). If the property change was not later than the one held on the Cognima Server no change is made as the stored property value is more recent—but the value is added to the list of old property values on the Cognima Server so that a user can retrieve it later if required. When times are compared the Time Management approach described in Section 6.2.below is used.
  • When a device first connects to a Cognima Server it will be sent all class metadata definitions and then all the objects in the database for that user. The Deletion messages generally just mark an Object for deletion. Actual removal of the object from the database may occur later on once all objects referring to that object have also been deleted.
  • 5.2.5 Optimisations
  • An optimised version of the above replication protocol allows for aggregation of the entries in the ChangeLog. If a ChangeLog (in the Cognima Server or on a client device) has not yet been replicated, and a subsequent entry is added, then existing entries can be scanned to potentially reduce the number of entries that need to be replicated during the next connection:
      • if the new entry is an update to a property that is already scheduled for update then only the later entry need be retained
      • if the new entry is an object deletion then all property updates for that object can be removed from the ChangeLog
      • if the new entry is an ‘undelete’ command and the original deletion is still in the ChangeLog then the two entries can both be removed from the ChangeLog
        6. Core Algorithms
        6.1 Handling Endian-ness
  • Operating systems are fundamentally little endian or big endian which is a choice of the byte order in which numbers and strings are stored. If two computers which have different endian-ness have to communicate then one of the computers will have to switch the endian-ness of its data packets. In the Cognima environment the Cognima client software uses the same endian-ness as the host client device. The Cognima Server has to determine the endian-ness of the client device (it uses a reference value in the first packet of data from the client) and then convert the subsequent incoming data if necessary to maintain consistent endian-ness in the Cognima Server. The Cognima Server also has to convert any outgoing data it sends back to the client device.
  • 6.2 Synchronising System Times
  • Different devices will inevitably have slightly different system times. Changes that are sent from client devices to the Cognima Server are stamped with the device system time at the time of the change. It is up to the Cognima Server to resolve the times on different devices so that it can judge the order in which changes took place and record the correct update.
  • The logon of a device contains the current device time. The Cognima Server should be able to compensate for the latency of the network and compare the login time with its own system time. This will give it a delta between the device time and the Cognima Server time. This delta can be applied to further times sent up by the device in that session.
  • The Cognima Server can compare deltas in successive sessions from a device to determine clock ‘creep’ on the device or changes of time zone: it cannot be assumed that all the client devices in the system have clocks that are well synchronised to each other:
      • Clock times drift on devices depending on the device's clock accuracy.
      • Some users like to set clocks 5 minutes early for example.
      • Some users will make changes to clocks to account for daylight saving rather than adjusting the locale settings (and some OSes may not provide locale features anyway forcing the user to change the clock directly).
  • To get round this problem, the server will be responsible for adjusting times used by the client device to GMT when comparisons are made on the Server, and from GMT to the equivalent time for the client device when messages are sent from the Cognima Server to the client device.
  • The client device will tag all the items in the ChangeLog with times obtained from the local clock—as far as the client device is concerned it only ever deals in time based on the client device's own clock.
  • Each time the client device connects to the Cognima Server it sends its view of the current time as given by the clock on the client device. From this the Server can work out:
      • What the delta to GMT is
      • If there has been any drift in the mobile device clock since the last time it logged on since the server keeps a record of the last delta to GMT and when the last connection was made and therefore can compare these. If there is drift the server can adjust all times sent by the mobile device pro-rata.
  • For example the table below shows a pattern of events with a client device connecting to a Cognima Server. The Client device's time is 5 minutes slower that the Cognima Server and is loosing a minute every hour (an extreme case to show the point). Also to show the point we will assume that from 09:00 to 12:00 the user is on a plane and out of contact with the Cognima Server so it does not connect during this time:
    Client Cognima
    Device Server time
    Action Time (GMT)
    Client device connects to Cognima 09:00 09:05
    Server
    A change is made to property A 10:00 X
    A change is made to property B 11:00 Y
    Client device connects to Cognima 12:00 12:08
    Server
  • In order to work out if the property changes were made before or after the time stored on the Cognima Server the times X and Y need to be worked out. From the information above the Cognima Server knows that when the client last connected it was around 3 hours ago and at that point the time difference was 5 minutes whereas now it is 8 minutes. Thus, assuming the clock drift happens linearly, the Cognima Server can work out that the device is 5 minutes behind GMT and that the clock is drifting back a minute every hour.
  • From this is it possible to work out that the time the client device knows as 10:00 for the property A change needs to have 5 minutes added to it for the initial drift, plus one minute for the extra drift that occurred in the hour till that property was changed.
  • Likewise Property B needs to be adjusted to 11:07—the 5 minutes initial drift plus 2 minutes since two hours elapsed from 09:00 to 11:00 when the property was changed.
  • In practice the delta to the time between the client device time and GMT may be minutes, but the drift will be in the order of fractions of seconds per hour.
  • 6.2.1 Time Adjustments
  • As well as the delta to GMT and any drift in the client device clock, users can also change the time on the client device. They may do this to reset the time to the correct local time (we can give the user the option to have this happen automatically but some users may want to keep their own control of their client device time—e.g. they like to have the clock set 5 minutes fast). They may also make adjustments to reflect a change of local time (i.e. daylight savings or changing timezone). The goal is that the user can change the clock on the device to any time that suits the user and the device simply takes account of this.
  • When the user makes a change to the client device time most operating systems will report this change (for systems that don't do this the time can be polled say every minute to check for such a change). On detecting a change in time the client device will work out the delta between the new time and the time as it was before the change. For example this may be a change of plus one hour as a user moves timezone. The client device stores this time difference as the Adjust Time which it saves for the next connection to the Cognima Server. The client device also goes through every entry in the ChangeLog and updates all times in the log by Adjust Time. This ensures that the entries in the ChangeLog are always relative to the local time on the client device.
  • Several such adjustments could be made between connections to the Cognima Server—each time the amount of the time change is summed with the Adjust Time and the ChangeLog updated so that the times in the log are all relative to the local time on the client device.
  • When the client device next connects to the Cognima Server the client device sends at logon the stored Adjust Time—i.e. the amount by which the client device clock has been adjusted backwards or forwards since the last connection. The Cognima Server can then remove this amount from the time from the delta to GMT and drift calculation.
  • 6.2.2 GMT to Client Device
  • The same set of calculations can be made in reverse to convert the GMT times of changes made on the Cognima Server to the correct local time for a given client device.
  • 6.3 Adding an Application
  • An application will use one or more classes to hold user data. The definition of the class is hard coded into the application. The version of the class is coordinated by releases of the application.
  • Say that a statistics application uses a Footballer class to hold data about footballers. When the application starts on a client device for the first time, it inquires from the device what version of the Footballer class the device already holds. If the version on the device is the same as the version that the application has been hard coded to use then nothing more need be done.
  • If the device holds a newer version of the Footballer class, then the application needs to be robust enough to cope with more properties than it expected. (This situation would arise if you had a class being used by multiple apps and for some reason you installed an older version of one of the apps. This should be rare: ideally interdependent apps should be upgraded together.)
  • If the device holds an older version of the Footballer class (or no version at all) then the application's version of the Footballer class should replace it. The new version is sent up to the Cognima Server. The Cognima Server therefore maintains a list of versions of classes used on all devices.
  • The web portal pages will be the equivalent of the hard-coded device application. The web can extract objects from the database according to the latest version of the class, and if there are more properties than it was hard coded to expect it can ignore them. Therefore the web does not need to declare class versions.
  • 6.4 Change-Log Optimisation
  • The Cognima Server maintains Change-Logs for all devices listing changes that will be sent to the devices when the devices next connect. There will be optimisations that can be made to the Change-Logs, for example:
      • If >2 updates to the same property are queued in the Change-Log then only the last need be kept.
      • If a deletion is queued for an object then any updates ahead in the queue may be removed.
      • If an update is queued for an object then any delete ahead in the queue should be removed.
      • If a device registers a new application there could potentially be very many objects to send down to it (e.g. message history). The Change-Log should only have a sensible number of objects added to it (e.g. the 20 most recent messages).
        7. Ghosting, Resurrection, Pinning and Withdrawal
  • The space available on a client device to hold user data will typically be orders of magnitude less than the space available on the server. The device needs to hold a subset of data and the user should have to do as little work as possible to maintain this subset. Ghosting and withdrawal are tools to aid this.
  • A class definition may include flagging certain properties as ‘ghostable’. This means that if the object is ghosted those properties will be nulled, freeing room on the client device. Ghosting is done automatically on the device. The decision about which objects to ghost is made by following a ‘ghosting rule’ and applying the rule whenever an object is created or updated. The rule defines the maximum number of a selection of objects. When the maximum is exceeded the objects in the selection at the bottom of a sort order are ghosted.
  • For example, the class might be messages, the selection might be messages in the inbox, the sort order might be by date/time and the maximum number might be 50. If there are 50 messages in the inbox and a new message arrives, the oldest message in the inbox is ghosted. Ghosting may remove the message body but leave enough header information for the message to be recognised.
  • Withdrawal (also known in the past as auto-deletion and removal) is similar to ghosting but works by removing the entire object, not just part of it.
  • Neither ghosting nor withdrawal are notified to the Cognima Server. They are purely local to the client device. Therefore different devices may have different numbers of objects. The data on the devices is still fundamentally in sync, but the devices hold different data subsets.
  • If the user wants to resurrect a ghost then a request is passed from the client to the Cognima Server for the object to be resurrected. A refresh of the object is sent down to the device and the object is put back to normal.
  • Individual objects can be pinned. A pinned object is never ghosted or removed. Pinning can be chosen by the user, or it can happen automatically. For example, an object that is resurrected is automatically pinned.
  • 8. User Replication—Sharing Objects
  • There are many applications for which we envisage it will be useful for users to be able to share objects. The general way that this will work is: A user needs to know the Cognima address of users that he may want to share objects with. It is more appropriate to discuss the retrieval of these addresses in detail in the Cognima Server architecture. Here we assume that such a list is available.
  • A set of one or more Cognima addresses is attached to the object which is to be shared. The object can be set to read-only (so the people you share it with cannot modify it). When the Cognima Server receives the new object (or receives an update to it) from the web or a client device it replicates it as normal.
  • It also looks up the list of ‘sharees’ Cognima addresses. It marks the object with an originator id (i.e. the Cognima address of the object owner + the object id) and sends it to the sharees. The sharee users may exist on the same Cognima Server or be on different Cognima Servers. The Cognima Server of the sharee receives the object. If it is a new object it assigns a new object id (keeping note of the originator id). If it is an update it finds the object using the originator id.
  • If the sharee is allowed to update the object, the update can be replicated back to the object owner using the originator id.
  • 9. Displaying Data
  • Conventional small devices like PDA tend to have simple filing systems that allow applications to read and write data to some kind of storage that will keep the data when the application is not running. Generally these programs will tend to read in the available set of data and then provide a user interface to display the data on the screen. This has some disadvantages:
      • Reading in the data when the program starts takes time
      • The application needs to store all or some of the data in memory meaning it is now occupying more memory on the client device
      • Allowing more than one application to access the same set of data becomes non-trivial
      • Similar code to read and manipulate the data appears in several applications that run on the device.
  • The Cognima approach is different:
      • Data is stored in an Object Database that can be accessed by several applications
      • A Cognima application does not read in all the data it deals with from a database. Instead it creates a selection—a subset of the data which it is currently interested in. In general this selection matches the data that is currently being displayed on the devices screen. Thus only the data currently being used by the application is held in memory—saving a lot of memory space.
      • All of the work of storing, sorting and indexing the data is done by the Object Database and so this functionality does not need to be repeated in each application.
      • When changes need to be made to data in an application, the application never directly updates its own display of the data. Changes will update the properties in an object or create or delete an object. A change to the data could be made by another application or an update received from a Cognima Server due to the data being changed on another machine.
      • When an application sets up a selection it gives a list of criteria by which data is either included or excluded from the selection—because of this the Cognima Replication Engine can tell which applications to notify when a object is created, deleted or updated.
      • When an update needs to be sent to the application, code in the application linked to the selection that contains this data is called and in this way the application can respond to the changes that have been made.
      • When selections are set up, the application can also specify how the data is sorted and if only a small window on the sorted list of data is required (known as a view).
  • This approach is similar to the screen re-paint approach used to redraw graphics screens on Windowing systems. When an area of the screen needs repainting the application that is responsible for that bit of screen is called to repaint the screen.
  • 9.1 Example
  • A client device may have a contacts application running on it—this device replicates data with a Cognima Server connected to other client devices also running contacts applications. A class of object is defined for a Contact that contains names and phone numbers and these are replicated to all the devices of a given user.
  • An application on one device may have a display that shows all contacts by beginning letter—for example the interface allows the user to press a D button to show all the names beginning with D. This application will set up a selection that contains objects:
      • Where the class is defined as Contacts
      • Where the name begins with the selected letter (e.g. D)
  • When the selection is defined the application also defines code to be called by the CRE when objects are added, deleted or updated.
  • When the selection is first set up this code will be called back with the first set of objects that fulfil the above criteria.
  • If the application was asked to create a new contact with a name beginning with D the application would create the object but do nothing else. The CRE would detect the new object and call back the selection code to notify it of the new object.
  • Likewise is a new Contact object was created on another device and was replicated to the client device—if the name of that Contact began with D the application would be notified.
  • 9.2 Sorting
  • Data in selections generally needs to be sorted—often so that when displayed users can see data in a logical format. When a selection is defined the sorting order can be specified: the properties to sort on, in what order and what sorting algorithms to use.
  • 9.3 Views
  • There may be many items of data in a selection. Commonly when the data is being displayed it may not all fit on the screen and so the user will need to scroll up and down the data. A view provides this functionality by specifying the number of items of data the selection wants to deal with and the number of the first item of data out of the complete list of data the application wants to appear in the selection.
  • Views are important because they allow an application to limit the amount of data it stores locally to be limited to just the amount needed to display on the screen this reducing unnecessary duplication of data.
  • 9.4 Efficiency
  • Cognima has made some efficiency optimisations in how the data is transferred between the Cognima server and client application—when multiple data changes are made the data is sent in blocks and then the application informed that the changes are complete so that the application only needs to update its user interface once.
  • 9.5 Example
  • As an example we will define a selection called ContactSelection. This is the code that the framework will call back whenever a change is made to any of the selected objects. In the Cognima framework this is implemented as an object which you derive from the COdbSelect templated class—specifiying the type of object you want to have in the selection as the template argument.
    class CContactSelect : public COdbSelect<CContact>
    {
    public:
     CContactSelect(COdb *aOdb);
     void ObjectAdded(CContact *aObject);
     void ObjectUpdated(CContact *aObject);
     void ObjectRemoved(const TOdbObjectId aObjectId);
    private:
     bool ListContacts( );
    };
  • The methods ObjectAdded( ), ObjectUpdated( ) and ObjectRemoved( ) are called by the framework whenever respectively an object is added, updated or removed. When you implement the Selection class you don't need to implement all these methods if you do not want to take instance action on any of these events—in some cases you may set up a selection to keep a list of a certain set of objects but only check that list on some other event and so the above methods would not be required.
  • We have defined one extra private method called ListContacts( )—this will list all the current contacts held by the selection.
  • Here is the implementation of this class:
    CContactSelect::CContactSelect(COdb *aOdb)
    : COdbSelect<CContact>(aOdb)
    {
    }
    void CContactSelect::ObjectAdded(CTestContact *aContact)
    {
     OdbLog(OdbLogApp,L“New contact added: ”
     << aContact->GetName( ));
     ListContacts( );
    }
    void CContactSelect::ObjectUpdated(CTestContact *aContact)
    {
     OdbLog(OdbLogApp,L“Contact updated: ” << aContact->GetName( ));
     ListContacts( );
    }
    void CContactSelect::ObjectRemoved(const TOdbObjectId aObjectId)
    {
     OdbLog(OdbLogApp,L“Contact deleted - Id: ” << aObjectId);
     ListContacts( );
    }
    void CContactSelect::ListContacts( )
    {
     OdbLog(OdbLogApp,L“Contacts list:”);
     for (unsigned long Index=0; Index<iResult.size( ); Index++)
     {
       CTestContact *Contact=iResult[Index];
       OdbLog(OdbLogApp,Contact->GetName( ) << “, ”
         << Contact->GetPhone( ) << “, ”
         << Contact->GetEmail( ));
     }
    }
  • The constructor simply calls the default COdbSelect constructor. The ObjectAdded( ), Updated( ) and Removed( ) methods print out what change was made and then call ListContacts( ) to show what the current contents of the list is.
  • The ListContacts( ) shows how the current list of object held by the selection can be accessed. The current list of pointers to objects is held in a container class called iResult—this can then be accessed by normal container class integrators. In this case we simply go through the list and print all the objects in the list.

Claims (12)

1. A method of replicating data from computing devices, in which a first computing device is given responsibility for determining whether data received from a wireless, portable computing device over a wireless network is replicated or not; wherein the method comprises the steps of the wireless, portable computing device:
(a) generating a change log, the change log including data only for records that have changed;
(b) sending those change logs to the first computing device in order to replicate data in the change log in a master copy database running on the first computing device; and
(c) registering one or more metadata definitions with the first computing device said metadata definition defining how change logs relating to a new application will be presented by the wireless computing device, said metadata definition comprising a description of a property type used by said new application.
2. The method of claim 1 in which the change log comprises a time stamp that indicates the time a change to a record was made, the time being measured using a real time clock on the wireless computing device.
3. The method of claim 1 in which the change log only records changes to the field of a given record that has changed and not the entire record.
4. The method of claim 1 comprising the step of the change log recording only changes that have occurred since the last data replication between the wireless computing device and the first computing device.
5. The method of claim 1 comprising the step of the wireless computing device and the first computing device sharing metadata that defines the proper interpretation of the change log.
6. The method of claim 1 comprising the step of the change log being populated with data identifying the data that has been changed, how it was changed and when it was changed on the wireless computing device.
7. The method of claim 1 comprising the step of the change log being automatically sent by the wireless computing device to the first computing device without any user intervention.
8. The method of claim 1 comprising the step of the wireless computing device sending the change log automatically (a) at pre-defined periodic intervals, (b) at pre-defined times or (c) continuously whenever a change log is created.
9. The method of claim 1 comprising the step of the wireless computing device batching up multiple change logs.
10. The method of claim 9 comprising the step of the wireless computing device sending batched change logs at times which depend on the importance of the change log being rapidly processed by the first computing device, with low priority change logs being sent at times of lower network traffic.
11. The method of claim 1 comprising the step of the wireless computing device sending records in a change log at times which depend on the importance of the records being rapidly processed by the first computing device, with low priority records being sent at times of lower network traffic.
12. A wireless, portable computing device programmed to send data to a first computing device over a wireless network, in order for the first computing device to replicate that data; wherein the device is programmed to:
(a) generate and store time stamps in a change log, the change log including data only for records that have changed;
(b) send those change logs to the first computing device in order to replicate data in the change log in a master copy database running on the first computing device; and
(c) register new metadata definitions with the first computing device to define how change logs relating to a new application will be presented by the wireless computing device, said metadata definitions comprising a description of a property type used by said new application.
US11/627,416 2001-11-26 2007-01-26 Method of Replicating Data Between Computing Devices Abandoned US20070118577A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/627,416 US20070118577A1 (en) 2001-11-26 2007-01-26 Method of Replicating Data Between Computing Devices

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GBGB0128243.3A GB0128243D0 (en) 2001-11-26 2001-11-26 Cognima patent
GBGB01282433 2001-11-26
PCT/GB2002/005308 WO2003046759A2 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices
US10/496,898 US20050021571A1 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices
US11/627,416 US20070118577A1 (en) 2001-11-26 2007-01-26 Method of Replicating Data Between Computing Devices

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US10/496,898 Continuation US20050021571A1 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices
PCT/GB2002/005308 Continuation WO2003046759A2 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices

Publications (1)

Publication Number Publication Date
US20070118577A1 true US20070118577A1 (en) 2007-05-24

Family

ID=9926432

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/496,557 Expired - Fee Related US7836264B2 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices which each use local clocks
US10/496,898 Abandoned US20050021571A1 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices
US10/496,540 Abandoned US20050108185A1 (en) 2001-11-26 2002-11-26 Method of updating a display screen on a battery powered mobile computing device
US11/627,416 Abandoned US20070118577A1 (en) 2001-11-26 2007-01-26 Method of Replicating Data Between Computing Devices

Family Applications Before (3)

Application Number Title Priority Date Filing Date
US10/496,557 Expired - Fee Related US7836264B2 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices which each use local clocks
US10/496,898 Abandoned US20050021571A1 (en) 2001-11-26 2002-11-26 Method of replicating data between computing devices
US10/496,540 Abandoned US20050108185A1 (en) 2001-11-26 2002-11-26 Method of updating a display screen on a battery powered mobile computing device

Country Status (8)

Country Link
US (4) US7836264B2 (en)
EP (3) EP1497725A2 (en)
JP (3) JP2005527883A (en)
AT (2) ATE399342T1 (en)
AU (3) AU2002343088A1 (en)
DE (2) DE60227280D1 (en)
GB (3) GB0128243D0 (en)
WO (3) WO2003046723A2 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060129578A1 (en) * 2004-12-15 2006-06-15 Samsung Electronics Co., Ltd. Method and system for globally sharing and transacting contents in local area
US20060171523A1 (en) * 2002-12-19 2006-08-03 Cognima Ltd. Method of automatically replicating data objects between a mobile device and a server
US20070088724A1 (en) * 2003-08-21 2007-04-19 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US20070260751A1 (en) * 2006-03-28 2007-11-08 Scott Meesseman System and method for synchronizing personal data among a plurality of devices storing such data
US20070271317A1 (en) * 2004-08-16 2007-11-22 Beinsync Ltd. System and Method for the Synchronization of Data Across Multiple Computing Devices
US20070283036A1 (en) * 2004-11-17 2007-12-06 Sujit Dey System And Method For Providing A Web Page
US7523213B1 (en) * 2008-05-20 2009-04-21 International Business Machines Corporation Efficient approach with the toleration of stale data to dynamically transform and unify data quality in client and server with continuous transaction flows
US20090119351A1 (en) * 2007-11-07 2009-05-07 International Business Machines Corporation Methods and Computer Program Products for Transaction Consistent Content Replication
US20110029891A1 (en) * 2009-06-16 2011-02-03 Lg Electronics Inc. Mobile terminal and method of controlling operation of the mobile terminal
US7899783B1 (en) * 2006-05-30 2011-03-01 Cisco Technology, Inc Monitoring data integrity
US8166101B2 (en) 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US8510404B2 (en) 2006-04-03 2013-08-13 Kinglite Holdings Inc. Peer to peer Synchronization system and method
US9170891B1 (en) * 2012-09-10 2015-10-27 Amazon Technologies, Inc. Predictive upload of snapshot data
US9251008B2 (en) 2013-03-14 2016-02-02 International Business Machines Corporation Client object replication between a first backup server and a second backup server
US20170149883A1 (en) * 2015-11-20 2017-05-25 Datadirect Networks, Inc. Data replication in a data storage system having a disjointed network
US10311082B2 (en) * 2015-12-21 2019-06-04 Sap Se Synchronization of offline instances

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8326361B2 (en) 1998-10-01 2012-12-04 Lupine Investments Llc Phone to phone data exchange
US20080015998A1 (en) * 1998-10-01 2008-01-17 Feyzi Celik Method and Apparatus for Storing and Retrieving Business Contact Information in a Computer System
US7349907B2 (en) * 1998-10-01 2008-03-25 Onepin, Inc. Method and apparatus for storing and retrieving business contact information in a computer system
US6374259B1 (en) 1998-10-01 2002-04-16 Onepin, Llc Method and apparatus for storing and retreiving business contact information in computer system
US7970792B2 (en) * 1998-10-01 2011-06-28 Onepin, Inc. Phone to phone data exchange
US7836011B2 (en) * 1998-10-01 2010-11-16 Onepin, Inc. Phone to phone data exchange
US7509349B2 (en) * 1998-10-01 2009-03-24 Onepin, Inc. Method and apparatus for storing and retrieving business contact information in a computer system
US7813725B2 (en) * 1998-10-01 2010-10-12 Onepin, Llc Wireless data exchange
US8620286B2 (en) * 2004-02-27 2013-12-31 Synchronoss Technologies, Inc. Method and system for promoting and transferring licensed content and applications
US8156074B1 (en) * 2000-01-26 2012-04-10 Synchronoss Technologies, Inc. Data transfer and synchronization system
US6671757B1 (en) 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US6925156B2 (en) * 2002-12-20 2005-08-02 International Business Machines Corporation Pre-connection telephony data synchronization
WO2005010715A2 (en) 2003-07-21 2005-02-03 Fusionone, Inc. Device message management system
US8032593B2 (en) * 2003-08-07 2011-10-04 Teamon Systems, Inc. Communications system providing reduced access latency and related methods
US7305233B2 (en) * 2004-05-27 2007-12-04 Exclaim, Inc. Method and apparatus for image distribution using a cellular phone
WO2005024665A1 (en) * 2003-08-21 2005-03-17 Microsoft Corporation Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system
US7483923B2 (en) * 2003-08-21 2009-01-27 Microsoft Corporation Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
CN1739093B (en) * 2003-08-21 2010-05-12 微软公司 Systems for the implementation of a synchronization schemas
US7895247B2 (en) 2003-10-29 2011-02-22 Oracle International Corporation Tracking space usage in a database
FI20035235A0 (en) * 2003-12-12 2003-12-12 Nokia Corp Arrangement for processing files at a terminal
US7720801B2 (en) 2003-12-19 2010-05-18 Netapp, Inc. System and method for supporting asynchronous data replication with very short update intervals
US7257583B2 (en) * 2004-01-09 2007-08-14 Microsoft Corporation System and method for updating an on-device application catalog in a mobile device receiving a push message from a catalog server indicating availability of an application for download
EP1564657A1 (en) * 2004-02-10 2005-08-17 Research In Motion Limited Apparatus and method for data communication and synchronisation
US7274931B2 (en) * 2004-02-23 2007-09-25 Harris Arlene J Systems and methods for enhancing the provisioning and functionality of wireless instruments
US20050262166A1 (en) * 2004-05-05 2005-11-24 Microsoft Corporation Method and system for synchronizing data between electronic devices
US9542076B1 (en) 2004-05-12 2017-01-10 Synchronoss Technologies, Inc. System for and method of updating a personal profile
US20080082421A1 (en) * 2004-05-12 2008-04-03 Richard Onyon Monetization of an advanced contact identification system
EP1759521B1 (en) * 2004-05-12 2016-06-29 Synchronoss Technologies, Inc. Advanced contact identification system
US7412371B2 (en) * 2004-06-08 2008-08-12 Northrop Grumman Corporation Time synchronized playback and control of dissimilar data files
US20060026198A1 (en) * 2004-07-30 2006-02-02 Research In Motion Ltd. Method and apparatus for synchronizing contact data stores
WO2006054340A1 (en) * 2004-11-17 2006-05-26 Fujitsu Limited Portable wireless terminal and its security system
US20060160529A1 (en) * 2005-01-14 2006-07-20 Holger Glass Systems and methods for the automatic customization or configuration of mobile devices
KR20080017313A (en) * 2005-05-19 2008-02-26 퓨전원 인코포레이티드 Remote cell phone auto destruct
EP1889169A4 (en) * 2005-05-19 2011-12-28 Fusionone Inc Mobile device address book builder
GB0510549D0 (en) * 2005-05-24 2005-06-29 Cognima Ltd Battery power saving
US7631045B2 (en) * 2005-07-14 2009-12-08 Yahoo! Inc. Content router asynchronous exchange
US20070016636A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Methods and systems for data transfer and notification mechanisms
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US7623515B2 (en) * 2005-07-14 2009-11-24 Yahoo! Inc. Content router notification
US7849199B2 (en) * 2005-07-14 2010-12-07 Yahoo ! Inc. Content router
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US8024290B2 (en) 2005-11-14 2011-09-20 Yahoo! Inc. Data synchronization and device handling
US8065680B2 (en) * 2005-11-15 2011-11-22 Yahoo! Inc. Data gateway for jobs management based on a persistent job table and a server table
US7574460B2 (en) * 2005-12-01 2009-08-11 International Business Machines Corporation Journaling database changes using minimized journal entries that may be output in human-readable form
US7917487B2 (en) * 2005-12-13 2011-03-29 Microsoft Corporation Portable application registry
US9367832B2 (en) * 2006-01-04 2016-06-14 Yahoo! Inc. Synchronizing image data among applications and devices
GB0601917D0 (en) * 2006-01-31 2006-03-15 Cognima Ltd A method of configuring a mobile telephone to interact with external services
US20070271515A1 (en) * 2006-05-19 2007-11-22 Sharp Laboratories Of America, Inc. Algorithm used to maintain the relative position of the online contact that has focus in the screen when new presence data requires an update of the online contacts screen
US8064956B2 (en) * 2006-08-02 2011-11-22 Onepin, Inc. Event sharing
US20080034008A1 (en) * 2006-08-03 2008-02-07 Yahoo! Inc. User side database
US20080090597A1 (en) * 2006-10-17 2008-04-17 Feyzi Celik Short message formatting for information exchange
US7447510B2 (en) * 2006-10-22 2008-11-04 Onepin, Inc. Short message service network plug-in
US20080140802A1 (en) * 2006-12-08 2008-06-12 Microsoft Corporation Offsite centralized data center providing client functionality
CN101606144A (en) * 2007-01-26 2009-12-16 富盛旺公司 Be used to back up the system and method that content is used for mobile device
US8761744B2 (en) * 2007-04-20 2014-06-24 Lupine Investments Llc Mobile virtual communication invitations
US20080270629A1 (en) * 2007-04-27 2008-10-30 Yahoo! Inc. Data snychronization and device handling using sequence numbers
US7778974B2 (en) * 2007-10-14 2010-08-17 International Business Machines Corporation Apparatus and method to archive log entries formed by a data storage system
US8458727B2 (en) * 2007-11-05 2013-06-04 Microsoft Corporation Asynchronous client to server updates
US8181111B1 (en) 2007-12-31 2012-05-15 Synchronoss Technologies, Inc. System and method for providing social context to digital activity
US8135670B2 (en) * 2008-07-22 2012-03-13 International Business Machines Corporation Embedded change logging for data synchronization
JP4725622B2 (en) * 2008-09-22 2011-07-13 日本電気株式会社 Log management apparatus, system, method, and program
US8359568B2 (en) * 2008-12-22 2013-01-22 International Business Machines Corporation Method and system for automatically adding generic change log to legacy application
US8374930B2 (en) * 2009-02-02 2013-02-12 Trustifi Corporation Certified email system and method
GB0906004D0 (en) 2009-04-07 2009-05-20 Omnifone Ltd MusicStation desktop
US9065868B2 (en) * 2009-04-08 2015-06-23 Blackberry Limited System and method for sharing data in a group of mobile devices
US8341023B2 (en) * 2009-06-17 2012-12-25 Trustifi Corporation Certified email system and method
US8255006B1 (en) 2009-11-10 2012-08-28 Fusionone, Inc. Event dependent notification system and method
US8732479B1 (en) * 2010-03-12 2014-05-20 Carbonite, Inc. Methods, apparatus and systems for remote file storage using local client status files
US8924348B2 (en) * 2010-04-05 2014-12-30 Tata Consultancy Services Limited System and method for sharing data between occasionally connected devices and remote global database
US8943428B2 (en) 2010-11-01 2015-01-27 Synchronoss Technologies, Inc. System for and method of field mapping
US8732462B2 (en) * 2011-07-07 2014-05-20 Ziptr, Inc. Methods and apparatus for secure data sharing
US8601121B2 (en) 2012-01-09 2013-12-03 International Business Machines Corporation Tracking changes to data within various data repositories
JP2013178685A (en) * 2012-02-29 2013-09-09 Nec Corp Data processing system with asynchronous backup function, front system, backup method and program therefor
US20130238552A1 (en) * 2012-03-12 2013-09-12 Joseph Saib Systems and methods for synchronizing files in a networked communication system
EP2693586B1 (en) * 2012-07-31 2016-04-06 ABB Research Ltd. Clock synchronization for line differential protection
US10635638B2 (en) 2013-03-13 2020-04-28 Ivanti Us Llc Systems, methods and media for deferred synchronization of files in cloud storage client device
JP6508894B2 (en) * 2014-07-28 2019-05-08 キヤノン株式会社 Server apparatus, control method of server apparatus and program
US20160042097A1 (en) * 2014-08-07 2016-02-11 Brigham Young University System and method for concurrent multi-user analysis of design models
WO2017147045A1 (en) * 2016-02-22 2017-08-31 Hubbell Incorporated Auto-adjusting data log record timestamps
EP3236383A1 (en) 2016-04-20 2017-10-25 Gemalto Sa Method for managing a real-time clock in a portable tamper-resistant device
DE102017120032A1 (en) * 2017-08-31 2019-02-28 Vega Grieshaber Kg Method for the time-synchronized processing of data of a field device of process automation
US20220398217A1 (en) * 2021-06-10 2022-12-15 EMC IP Holding Company, LLC System and Method for Snapshot Rule Time Zone Value

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870759A (en) * 1996-10-09 1999-02-09 Oracle Corporation System for synchronizing data between computers using a before-image of data
US6389423B1 (en) * 1999-04-13 2002-05-14 Mitsubishi Denki Kabushiki Kaisha Data synchronization method for maintaining and controlling a replicated data
US20020107920A1 (en) * 2001-02-08 2002-08-08 Timo Hotti Method and system for data management
US20020143791A1 (en) * 2001-03-19 2002-10-03 Dov Levanon Content deployment system, method and network
US6493720B1 (en) * 1998-01-26 2002-12-10 International Business Machines Corporation Method and system for synchronization of metadata in an information catalog
US6633924B1 (en) * 1997-10-02 2003-10-14 Charles Wu Object synchronization between objects stores on different computers
US6718348B1 (en) * 2000-08-25 2004-04-06 Telefonaktiebolaget Lm Ericsson (Publ) Non-time dependent synchronization of databases
US20070198743A1 (en) * 2001-03-28 2007-08-23 Xiaofei Huang Method and system for server synchronization with a computing device via a companion device

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4142069A (en) * 1977-06-20 1979-02-27 The United States Of America As Represented By The Secretary Of The Army Time reference distribution technique
CA1225653A (en) * 1983-07-07 1987-08-18 Thomas D. Thompson, Iii Organoclay-antiozonant complex
US5592664A (en) * 1991-07-29 1997-01-07 Borland International Inc. Database server system with methods for alerting clients of occurrence of database server events of interest to the clients
US5420968A (en) * 1993-09-30 1995-05-30 International Business Machines Corporation Data processing system and method for displaying dynamic images having visual appearances indicative of real world status
US5966387A (en) * 1995-09-25 1999-10-12 Bell Atlantic Network Services, Inc. Apparatus and method for correcting jitter in data packets
US5884325A (en) * 1996-10-09 1999-03-16 Oracle Corporation System for synchronizing shared data between computers
US5924094A (en) * 1996-11-01 1999-07-13 Current Network Technologies Corporation Independent distributed database system
US6446092B1 (en) * 1996-11-01 2002-09-03 Peerdirect Company Independent distributed database system
US5921938A (en) * 1997-10-09 1999-07-13 Physio-Control Manufacturing Corporation System and method for adjusting time associated with medical event data
JP4575591B2 (en) * 1997-10-24 2010-11-04 マイクロソフト コーポレーション Meeting requests and group scheduling generation from mobile devices
US6170063B1 (en) * 1998-03-07 2001-01-02 Hewlett-Packard Company Method for performing atomic, concurrent read and write operations on multiple storage devices
US6219694B1 (en) * 1998-05-29 2001-04-17 Research In Motion Limited System and method for pushing information from a host system to a mobile data communication device having a shared electronic address
US6243702B1 (en) * 1998-06-22 2001-06-05 Oracle Corporation Method and apparatus for propagating commit times between a plurality of database servers
FR2782226B1 (en) * 1998-08-04 2000-09-08 Sagem METHOD FOR LOCATING A MOBILE TELEPHONE
US6128699A (en) * 1998-10-27 2000-10-03 Hewlett-Packard Company Method for providing read/write access while copying data between shared storage devices
US6516314B1 (en) * 1998-11-17 2003-02-04 Telefonaktiebolaget L M Ericsson (Publ) Optimization of change log handling
JP2000276394A (en) * 1999-03-22 2000-10-06 Sharp Corp System and method for repeating web page information
US6587875B1 (en) * 1999-04-30 2003-07-01 Microsoft Corporation Network protocol and associated methods for optimizing use of available bandwidth
US6535926B1 (en) * 1999-09-30 2003-03-18 Rockwell Automation Technologies, Inc. Time synchronization system for industrial control network using global reference pulses
US6959425B1 (en) * 1999-12-15 2005-10-25 Sun Microsystems, Inc. System and method for managing a scalable list of items for display
US20030130786A1 (en) * 1999-12-30 2003-07-10 Ilkin Hakan M. Patient tracking system and method
EP1130512A3 (en) * 2000-01-25 2004-04-07 FusionOne, Inc. Data transfer and synchronization system
DE60142556D1 (en) * 2000-04-10 2010-08-26 Research In Motion Ltd SYSTEM AND METHOD FOR BUNDLING INFORMATION
US6802019B1 (en) * 2000-06-15 2004-10-05 Genesys Conferencing, Ltd. Method and system for synchronizing data
AU2001278873A1 (en) * 2000-07-06 2002-01-21 Broadbeam Corporation System and method for the remote creation of notification agents for wireless devices
US6826416B2 (en) * 2001-02-16 2004-11-30 Microsoft Corporation Automated cellular telephone clock setting
US6975618B1 (en) * 2001-06-26 2005-12-13 Hewlett-Packard Development Company, L.P. Receiver and correlator used to determine position of wireless device
JP3932452B2 (en) * 2001-09-27 2007-06-20 ソニー株式会社 Communication apparatus and method, and program
US6938045B2 (en) * 2002-01-18 2005-08-30 Seiko Epson Corporation Image server synchronization
US20030144006A1 (en) * 2002-01-25 2003-07-31 Mikael Johansson Methods, systems, and computer program products for determining the location of a mobile terminal based on delays in receiving data packets from transmitters having known locations
US7602744B2 (en) * 2004-09-09 2009-10-13 Nokia Corporation Detection of a simultaneous occurrence of an event at a plurality of devices

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870759A (en) * 1996-10-09 1999-02-09 Oracle Corporation System for synchronizing data between computers using a before-image of data
US6633924B1 (en) * 1997-10-02 2003-10-14 Charles Wu Object synchronization between objects stores on different computers
US6493720B1 (en) * 1998-01-26 2002-12-10 International Business Machines Corporation Method and system for synchronization of metadata in an information catalog
US6389423B1 (en) * 1999-04-13 2002-05-14 Mitsubishi Denki Kabushiki Kaisha Data synchronization method for maintaining and controlling a replicated data
US6718348B1 (en) * 2000-08-25 2004-04-06 Telefonaktiebolaget Lm Ericsson (Publ) Non-time dependent synchronization of databases
US20020107920A1 (en) * 2001-02-08 2002-08-08 Timo Hotti Method and system for data management
US20020143791A1 (en) * 2001-03-19 2002-10-03 Dov Levanon Content deployment system, method and network
US20070198743A1 (en) * 2001-03-28 2007-08-23 Xiaofei Huang Method and system for server synchronization with a computing device via a companion device

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156075B2 (en) * 2002-12-19 2012-04-10 Critical Path Data Centre Limited Method of automatically replicating data objects between a mobile device and a server
US20060171523A1 (en) * 2002-12-19 2006-08-03 Cognima Ltd. Method of automatically replicating data objects between a mobile device and a server
US8166101B2 (en) 2003-08-21 2012-04-24 Microsoft Corporation Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system
US20070088724A1 (en) * 2003-08-21 2007-04-19 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US8238696B2 (en) 2003-08-21 2012-08-07 Microsoft Corporation Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system
US7917534B2 (en) 2003-08-21 2011-03-29 Microsoft Corporation Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system
US20070271317A1 (en) * 2004-08-16 2007-11-22 Beinsync Ltd. System and Method for the Synchronization of Data Across Multiple Computing Devices
US20070283036A1 (en) * 2004-11-17 2007-12-06 Sujit Dey System And Method For Providing A Web Page
US20060129578A1 (en) * 2004-12-15 2006-06-15 Samsung Electronics Co., Ltd. Method and system for globally sharing and transacting contents in local area
US7966339B2 (en) * 2004-12-15 2011-06-21 Samsung Electronics Co., Ltd. Method and system for globally sharing and transacting contents in local area
US20070260751A1 (en) * 2006-03-28 2007-11-08 Scott Meesseman System and method for synchronizing personal data among a plurality of devices storing such data
US7974946B2 (en) * 2006-03-28 2011-07-05 Alps Electric (North America), Inc. System and method for synchronizing personal data among a plurality of devices storing such data
US8510404B2 (en) 2006-04-03 2013-08-13 Kinglite Holdings Inc. Peer to peer Synchronization system and method
US7899783B1 (en) * 2006-05-30 2011-03-01 Cisco Technology, Inc Monitoring data integrity
US8086566B2 (en) * 2007-11-07 2011-12-27 International Business Machines Corporation Transaction consistent content replication
US20090119351A1 (en) * 2007-11-07 2009-05-07 International Business Machines Corporation Methods and Computer Program Products for Transaction Consistent Content Replication
US7523213B1 (en) * 2008-05-20 2009-04-21 International Business Machines Corporation Efficient approach with the toleration of stale data to dynamically transform and unify data quality in client and server with continuous transaction flows
US20110029891A1 (en) * 2009-06-16 2011-02-03 Lg Electronics Inc. Mobile terminal and method of controlling operation of the mobile terminal
US8661350B2 (en) * 2009-06-16 2014-02-25 Lg Electronics Inc. Mobile terminal and method of controlling operation of the mobile terminal
US9170891B1 (en) * 2012-09-10 2015-10-27 Amazon Technologies, Inc. Predictive upload of snapshot data
US9251008B2 (en) 2013-03-14 2016-02-02 International Business Machines Corporation Client object replication between a first backup server and a second backup server
US20170149883A1 (en) * 2015-11-20 2017-05-25 Datadirect Networks, Inc. Data replication in a data storage system having a disjointed network
US10311082B2 (en) * 2015-12-21 2019-06-04 Sap Se Synchronization of offline instances

Also Published As

Publication number Publication date
AU2002343093A1 (en) 2003-06-10
GB0227537D0 (en) 2002-12-31
GB2384589A (en) 2003-07-30
US20050108289A1 (en) 2005-05-19
JP2005510805A (en) 2005-04-21
EP1451684A2 (en) 2004-09-01
WO2003047217A2 (en) 2003-06-05
GB0128243D0 (en) 2002-01-16
GB0227567D0 (en) 2002-12-31
US20050021571A1 (en) 2005-01-27
WO2003046723A2 (en) 2003-06-05
WO2003047217A3 (en) 2004-10-28
AU2002343088A1 (en) 2003-06-10
JP2005510796A (en) 2005-04-21
GB2386988B (en) 2004-05-05
AU2002343090A8 (en) 2003-06-10
EP1451720A2 (en) 2004-09-01
EP1451684B1 (en) 2008-06-25
GB2384589B (en) 2004-07-28
ATE375562T1 (en) 2007-10-15
DE60222924T2 (en) 2008-07-24
EP1451720B1 (en) 2007-10-10
US7836264B2 (en) 2010-11-16
ATE399342T1 (en) 2008-07-15
JP2005527883A (en) 2005-09-15
GB2386988A (en) 2003-10-01
EP1497725A2 (en) 2005-01-19
US20050108185A1 (en) 2005-05-19
WO2003046759A3 (en) 2004-03-04
AU2002343093A8 (en) 2003-06-10
DE60222924D1 (en) 2007-11-22
WO2003046723A3 (en) 2004-03-04
DE60227280D1 (en) 2008-08-07
AU2002343090A1 (en) 2003-06-10
WO2003046759A2 (en) 2003-06-05

Similar Documents

Publication Publication Date Title
US7836264B2 (en) Method of replicating data between computing devices which each use local clocks
US7894783B2 (en) Method of power management in a data replication process deployed in a wireless device
US8156075B2 (en) Method of automatically replicating data objects between a mobile device and a server
CN102207957B (en) Partial item change tracking and synchronization
US8949420B2 (en) Content pre-fetching and preparation
US7796779B1 (en) Efficient synchronization of changes to images
CN101454988B (en) Method and system of user-interests driven launching pad of mobile applications
JP2009545815A (en) Bidirectional multi-master synchronization via web syndication
US7428543B2 (en) Methods and systems for allowing third party client applications to influence implementation of high-level document commands
US20050215236A1 (en) Providing information for mobile users
GB2387687A (en) Method of replicating data between computing devices which use local clocks
US7680838B1 (en) Maintaining data synchronization in a file-sharing environment
US6876995B1 (en) Web store events
WO2005098628A1 (en) Overflow preventing method, device, and program

Legal Events

Date Code Title Description
AS Assignment

Owner name: SHOZU LIMITED, UNITED KINGDOM

Free format text: CHANGE OF NAME;ASSIGNOR:COGNIMA LIMITED;REEL/FRAME:021842/0665

Effective date: 20071018

AS Assignment

Owner name: CRITICAL PATH DATA CENTRE LIMITED,UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHOZU LIMITED (FKA COGNIMA LIMITED);REEL/FRAME:024404/0130

Effective date: 20100104

Owner name: CRITICAL PATH DATA CENTRE LIMITED, UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHOZU LIMITED (FKA COGNIMA LIMITED);REEL/FRAME:024404/0130

Effective date: 20100104

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION