CN102207957A - Partial item change tracking and synchronization - Google Patents

Abstract

The present invention relates to partial item change tracking and synchronization. Embodiments herein change the way item synchronization is handled and tracked between two devices. Changes to items are tracked according to well-defined sets of properties, and each set is tracked independently of the others. The present invention increases the rate of synchronization between a client and server by only synchronizing selected portions of items that have changed without monitoring every individual attribute within the item for changes. Therefore, if a change is made to a small data attribute (for example, a trace flag) on a relatively large e-mail message, this change will not trigger a large download to a client running in cached mode, nor will the There would be high storage and processing requirements for tracking each individual attribute.

Description

Partial item change tracking and synchronization

This application is a divisional application of a Chinese patent application with an application date of February 14, 2008, application number No. 200680029649.X, and the title of the invention is "tracking and synchronization of partial item changes".

background

Laptop, handheld and other portable computers or computing devices are increasing in popularity as they become smaller in size and less expensive. In addition, improvements in the operating speed and processing power of portable computers have also increased their popularity. Many portable computers are capable of storing multiple applications such as address books, games, calculators, etc. These application programs may be permanently installed in the portable computer (eg, onto read-only memory (ROM)) during manufacture. Alternatively, one or more applications may be installed by the user after purchasing the portable computer.

As the popularity and computing power of these devices increased, people began to use more than a single computing device to store data and applications. For example, many people commonly use laptop computers in addition to conventional desktop computers. Other devices such as cellular phones, personal digital assistants (PDAs), Internet services, etc. are also used to store data and applications.

Each of these computing devices may be part of a distributed computing system, where relevant information may be correlated and stored on multiple such devices. For example, an e-mail client running in cached mode is designed to keep a copy of the mailbox locally on the client. Thus, if a user has a PDA and a desktop work computer, each device will have email items stored locally on it. Ideally, the PDA's email information should match the email information at the desktop work computer.

When the same or related information is stored in two places, data may change in one location but not in another. This problem can be overcome through synchronization, which is an automated process that attempts to ensure that each device within a distributed system has the latest information or data. However, synchronization has its own set of problems. For example, when two devices are synchronized with each other, these systems typically track changes on a per-item basis, eg, per email message, per contact, per appointment, etc. Thus, when two devices or computing systems attempt to synchronize, the entire item is downloaded regardless of the size of the changed attributes (eg, logo, attachments, body, recipients, etc.). While this full item tracking and synchronization process is rarely, if ever, problematic for some high-bandwidth transfer systems, over slower links such as wireless connections, downloading or streaming of entire items can be a serious problem. Limit the transfer rate of data.

For example, consider an email message that includes a traceflag attribute, a recipient attribute, a body attribute, one or more attachment attributes, and so on. If the color of the tracking flag changes, the entire item must be downloaded when syncing with another device. If the attachments and other data within the e-mail are relatively large, this relatively small byte-size change of the trace flag causes the entire item to be downloaded; thereby creating a large data transfer time over a slow data link.

Even with high bandwidth data links, downloading entire items may still be undesirable. For example, when a customer pays for a downloaded item based on the number of bytes downloaded, if only a small amount of data changes on an item, such as the tracking flags described above, the customer must still pay for the entire item to be downloaded. This waste of money can be very frustrating for the user.

Certain replication systems may be a solution to the above-mentioned deficiencies of systems that track and synchronize devices on a per-item basis. Although some replication systems are able to track changes on an attribute basis, these systems have their own inherent problems. For example, tracking of each individual attribute for a large number of items creates both high storage and high processing requirements. As such, these tracking and synchronization systems are not practical for most users.

overview

The above-mentioned deficiencies and shortcomings of existing synchronization systems are overcome by the exemplary embodiments of the present invention. Please note that the following summary is provided to introduce in simplified form a selection of concepts that are further described below in the detailed description. This Summary is not intended, however, to identify key or essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

In one embodiment, a method, system, and computer are provided for increasing the rate of synchronization between a client and server by synchronizing only selected portions of changed items without monitoring changes to every individual attribute within the item program product. In this embodiment, a request to synchronize a data item that has changed since the last synchronization between the server and client is received, wherein the data item represents a complete message with a number of attributes that may be modified or otherwise changed. In response to a request to synchronize data, it is first determined whether a data item has changed since the last synchronization. This data item includes a plurality of attribute groups that are predefined based on common industry knowledge and an understanding of the semantics of how attributes within each of the plurality of attribute groups are related. Next, it is determined whether at least one attribute group of the plurality of attribute groups has changed since the last synchronization. Thus, the at least one attribute group can be synchronized without streaming the entire at least one data item, to reduce the time of data transfer between the client and the server when synchronizing.

In another embodiment, a method, system, and computer program are provided for tracking changes to selected portions of an item to increase the rate of synchronization between a client and a server without monitoring changes to each individual attribute within the item product. In this embodiment, multiple data items are monitored for synchronization purposes, where each of the multiple data items represents a complete message with multiple attributes that may be modified or otherwise changed. During this monitoring period, it is determined whether a data item has changed since the last synchronization between the client and the server, wherein the data item includes a plurality of attribute groups based on industry common sense and knowledge of the plurality of attribute groups The understanding of how the semantics of each of the attributes are related to predefined.

Based on the determination that the data item has changed, an item change identifier associated with the data item is updated, which will be used to identify that the data item has changed for synchronization with the client. Accordingly, it is also determined whether at least one attribute group of the plurality of attribute groups has changed since the last synchronization. Based on a determination that at least one attribute group has changed, updating an attribute group change identifier associated with the at least one attribute group that will be used to identify that the at least one attribute group has changed such that only the at least one attribute group will be associated with Client synchronization to reduce data transfer time between client and server.

In another embodiment, the present invention also provides one or more computer-readable media having item data structures stored thereon. The item data structure includes the following: a number of attributes that can be modified or otherwise changed; an item change identifier; a plurality of attribute groups each comprising one or more of a plurality of attributes, wherein the plurality of attribute groups are based on industry common knowledge and how the one or more attributes within each of the plurality of attribute groups are related and a plurality of attribute group change identifiers to indicate which of the plurality of attribute groups has changed so that only these changed attribute groups are synchronized and not the entire item.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by practice of the invention as described below.

Brief description of the drawings

In order to describe the manner in which the above and other advantages and features of the invention may be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are shown in the appended drawings. With the understanding that these drawings depict only typical embodiments of the invention and are therefore not to be considered as limiting its scope, the invention will be described and explained with additional characteristics and details by using the accompanying drawings, in which:

FIG. 1A shows a distributed system for synchronizing only attribute groups according to an example embodiment;

FIG. 1B illustrates a mapping for attribute groups of items, according to an example embodiment;

Figure 1C illustrates an example synchronization item flow according to an example embodiment;

FIG. 2A shows a flowchart of a method of increasing a synchronization rate between a client and a server according to an example embodiment;

2B shows a flow diagram of a method of tracking changes to a selected portion of an item, according to an example embodiment; and

Figure 3 illustrates an example computing system that provides a suitable operating environment for implementing the features of the invention.

A detailed description

The present invention relates to methods, systems and computer program products for increasing synchronization rates by synchronizing only selected parts of items that have changed. Embodiments of the invention may include special purpose or general purpose computers comprising various computer hardware or modules, as discussed in more detail below.

Before discussing the embodiments herein in detail, it will be useful to define some terms that will be used throughout the application. First, a "data item" or "item" is used herein to mean a complete message with attributes that can be modified or otherwise changed. For example, a data item may be a complete email message, a complete contact, a complete appointment, a complete task, a complete note, or any other type of message that can be synchronized between two computing devices. An "attribute" of an item represents a portion of a message that can be modified or otherwise changed independently of other attributes. Examples of these attributes include things like tracking flags, priority flags, the body of the item, individual attachments, individual recipients, message status, message priority, or any other well-known attribute for a message. Example embodiments provide that attributes may be divided into "attribute groups," which, as will be described in more detail below, are predetermined based on common industry knowledge and an understanding of the semantics of how attributes within each attribute group are related.

Embodiments herein change the way synchronization of items is handled and tracked between two devices, such as a server and a client. Changes to items are placed into the aforementioned well-defined property groups, and each group is tracked independently of the others. For example, one group could contain the item's text, another group could contain the attachments, and yet another group could contain highly volatile attributes such as tracking flags, read status, priority flags, and so on. Note that the embodiments herein trade off the data processing rate versus the storage and/or processing requirements required by typical replication systems since attribute groups are well defined based on industry common sense. In other words, the present invention increases the rate of synchronization between a client and server by synchronizing only selected portions of items that have changed without monitoring each individual attribute within the item for changes. Therefore, if a change is made to a small data attribute (e.g., a trace flag) on a relatively large email message, this change will not trigger a large download to a client running in cached mode, and There are also no high storage and processing requirements for tracking each individual attribute.

Before describing further details of various embodiments of the invention, reference will be made to FIG. 3 to describe one suitable computing architecture that may be used to implement the principles of the invention. In the following description, unless indicated otherwise, embodiments of the invention are described with reference to acts and symbolic representations of operations that are performed by one or more computers. It will thus be appreciated that such acts and operations, which are sometimes referred to as computer-implemented, include the manipulation of electrical signals representing data in a structured form by the processing unit of a computer. This manipulation transforms the data or maintains it at a location in the computer's memory system, which reconfigures or changes the operation of the computer in a manner well understood by those skilled in the art. A data structure that maintains data is a physical location in memory that has specific properties defined by the format of the data. However, although the present invention is described in the above context, it is not meant to be limiting, as those skilled in the art understand, the acts and aspects of operations described hereinafter may also be implemented in hardware.

Turning to the drawings, wherein like reference numerals refer to like elements, the principles of the invention are illustrated as implemented in a suitable computing environment. The following description is based on the described embodiments of the invention and should not be considered as limiting the invention with respect to alternative embodiments not explicitly described herein.

Figure 3 shows a schematic diagram of an example computer architecture that may be used with these devices. The architecture depicted is only one example of a suitable environment for descriptive purposes and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing system be interpreted as having any dependency or requirement relating to any one or combination of components shown in FIG. 3 .

The principles of the invention are operational with other general purpose or special purpose computing or communication environments or configurations. Examples of well-known computing systems, environments, and configurations suitable for use with the present invention include, but are not limited to, mobile phones, pocket computers, personal computers, servers, multiprocessor systems, microprocessor-based systems, minicomputers, mainframe computers, and A distributed computing environment comprising any of the above systems or devices.

In its most basic configuration, computing system 300 generally includes at least one processing unit 302 and memory 304 . Memory 304 may be volatile (eg, RAM), non-volatile (eg, ROM, flash memory, etc.), or some combination of the two. This most basic configuration is shown by dashed line 306 in FIG. 3 . In this specification and claims, a "computing system" is defined as any hardware component or combination of hardware components capable of executing software, firmware, or microcode to implement a function. Computing systems can even be distributed to enable distributed functionality.

The storage media device may have additional features and functions. For example, they may include additional storage (removable and non-removable) including, but not limited to, PCMCIA cards, magnetic and optical disks, and magnetic tape. Such additional storage is illustrated in FIG. 3 by removable storage 308 and non-removable storage 310 . Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 304, removable storage 308, and non-removable storage 310 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, other memory technologies, CD-ROM, digital versatile disk, or other optical storage, magnetic cartridges, tape, magnetic disk storage, other magnetic storage devices, and available Any other medium that stores desired information and that can be accessed by a computing system.

As used herein, the terms "module" or "component" can refer to software objects or routines that execute on a computing system. The various components, modules, engines, and services described herein can be implemented as objects or processes that execute (eg, as separate threads) on a computing system. Although the systems and methods described herein are preferably implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated. In this specification, a "computing entity" may be any computing system previously defined herein, or any module or combination of modules running on a computing system.

Computing system 300 may also contain a communication channel 312 that allows the host to communicate with other systems and devices, such as through network 320 . Communication channel 312 is an example of a communication medium. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer-readable media as used herein includes both storage media and communication media.

Computing system 300 may also have input components 314 such as a keyboard, mouse, pen, voice input components, touch input devices, and the like. Output devices 316 include screen displays, speakers, printers, etc., as well as rendering modules (commonly referred to as "adapters") for driving them. Computing system 300 has power supply 318 . All of these components are well known in the art and need not be discussed in detail here.

FIG. 1A illustrates a distributed system 100 for synchronizing a property set 104 between a client 105 and a server 125 according to an example embodiment. Distributed system 100 may be similar to computing system 300 described above with reference to FIG. 3 , but need not be. As shown in FIG. 1A, the distributed system 100 includes a client 105, which may be any one of a plurality of computing devices 110, 115, and the like. For example, client 105 may be a wireless device such as phone 110, PDA 110, laptop 115, or any other computing device.

Note that the present invention is most advantageous in systems where the data link is slow, such as wireless communications. However, the invention is not limited to such links and can be used in any environment. For example, as described above, the present invention may be used in systems that require users to pay for services based on the amount of data transferred from server 125 to client 105 . Accordingly, any specific reference to a particular data link between server 125 and client 105 is used herein for purposes of illustration only, and is not meant to limit or otherwise narrow the scope of the invention unless is clearly stated.

Also, note that although the invention will be described in terms of server 125 and client 105, the roles of these devices may be reversed in describing embodiments herein. For example, the following description will be described in terms of changes to items 170 that occur on server 125 , where such changes are synchronized by streaming the changes to client 105 . Note, however, that changes on the client 105 may also be tracked and uploaded to the server 125. As such, the following description of events occurring between server 125 and client 105—and any specific device here for either client 105 or server 125—is used herein for purposes of illustration only , and are not intended to limit or otherwise narrow the scope of the invention unless expressly stated otherwise.

As shown in FIG. 1A , server 125 includes multiple folders 165 (eg, folder “A”), where each folder 165 may represent or include items 170 of a particular type. For example, folder 165 may contain or include email item messages, while another folder 165 may include contact item information. Of course, as noted above, there may be a wide variety of item types that may be synchronized in accordance with the example embodiments provided herein. Additionally, other topologies and data configurations besides folders 165 may be used in implementing the present invention. For example, tables or other ways of partitioning or storing different types of items 170 differently may also be used with the present invention. Accordingly, any particular topology, data format, and/or storage hierarchy is used herein for purposes of illustration only, and is not meant to limit or otherwise narrow the scope of the invention.

As noted above, each folder 165 will contain a number of items 170 (eg, item "A"). Associated with each item 170 is an item change identifier (ID) 175, which can be used to identify the item 170 and its attributes since the last synchronization between the server 125 and the client 105, as described in more detail below. when has changed. Also included in each entry 170 is an attribute group 180 (eg, attribute group "A"). As noted above, attribute groups 180 are predefined based on common industry knowledge and an understanding of the semantics of how attributes within each of the plurality of attribute groups 180 are related. For example, attribute groups may be determined based on attribute volatility, typical memory size requirements, and/or other considerations. Additionally, attribute group 180 may include highly volatile attributes such as message status, trace flags, priority flags, or other attributes that are frequently modified and/or changed.

Alternatively, or in combination therewith, attribute groups 180 may be defined based on the relative size of the attribute when compared to other attributes. For example, the size of an attachment is typically larger than other attributes and thus may reside in one attribute group, while smaller data sizes such as the recipient and/or body of the message may reside in another attribute group 180 . There may even be a miscellaneous attribute group 180 for those attributes that do not correlate well with other attributes.

Note that although attribute set 180 is predefined based on existing industry knowledge, such knowledge is subject to change. Accordingly, embodiments provide that the attribute set 180 is extensible, pluggable, and scalable. That is, attribute groups 180 are configured in such a way that attributes in each attribute group 180 may be removed, deleted, added, and/or otherwise modified. Similarly, attribute groups 180 themselves may be redefined, created and/or deleted. Additionally, the definition of attribute group 180 may vary depending on the type of item 170 . For example, the set of attributes 180 defined for an email item 170 may be different than the set of attributes 180 defined for a contact item 170 . Thus, as will be described in more detail below, the client 105 will need to know the appropriate mapping 190 to use for each item 170 within the respective folder 165 .

Regardless of how attribute groups 180 are defined, each attribute group 180 will generally be assigned an attribute group change ID 185, which can be used to identify when a change has occurred to that particular attribute group 180. For example, item/attribute group module 150 may monitor changes to an item 170 as well as changes to each attribute group 180 within that item 170 . Change ID generator 160 may change item change ID 175 and appropriate attribute group change ID 185 when a change occurs.

In some embodiments, item change ID 175 and attribute change ID 185 may be the same identifier indicating, for example, that an item and attribute group were updated at the same time. Note, however, that this is not necessarily the case where, for example, globally unique identifiers (GUIDs) are used. It should also be noted that the change ID 175, 185 may be any well-known alphanumeric or other identifying data object. For example, change ID 175, 185 may be a hash of item 170 and/or attribute group 185, respectively. Of course, as mentioned above, the change identifier 175, 185 could be generated based on a simple GUID count. Note also that other mechanisms for identifying changes to items 170 and attribute groups 180 may also be used with the present invention. Accordingly, any particular type of change identifier 175, 185 and/or use thereof described herein for identifying a change is for illustrative purposes only and is not meant to limit or otherwise narrow the scope of the invention unless Clear statement.

Regardless of the type of identification 175, 185, and regardless of how a change to an attribute group is identified, when the item/attribute module 150 within the server 125 identifies a change to one or more items 170, a notification 120 of this item change may be sent The client 105 is given an attempt to prompt the client 105 to synchronize with the server 125 . Of course, other mechanisms for prompting the client 105 to synchronize with the server 125 may also be used with the present invention. For example, the client 105 may periodically, ie, at certain predetermined intervals, query the server 125 to synchronize with it. Accordingly, any specific initiation of a synchronization process between client 105 and server 125 is used here for purposes of illustration only, and is not meant to limit or otherwise narrow the scope of the present invention.

Nevertheless, after initiating the synchronization process, the server 125 should receive a synchronization request 130 from the client 105 . The exemplary embodiment provides that the synchronization request 130 may include one or more item tokens 125 (e.g., item token "A" ). Before discussing item token 135 in detail, note that item token 135 need not be included within synchronization request 130 . For example, other handshake mechanisms may additionally prompt the client 105 to send the item token 135 to the server 125 . Alternatively, item token 135 may already be stored on server 125 . Accordingly, the inclusion of item token 135 within synchronization request 130 is used here for illustrative purposes only, and is not meant to limit or otherwise narrow the scope of the invention unless expressly stated.

Associated with each item token 135 is an item change ID 140. For each item change ID 140 or item token 135, there are also multiple attribute group change IDs 145 (e.g., attribute group "A" change ID). Item Change ID 145 and Attribute Group Change ID 145 represent those identifiers associated with the item 169 and corresponding attribute group 180 for the last change between client 105 and server 125. In other words, item token 135 may have been passed to client 105 as a blob for storage during the last synchronization with server 125 . This data blob 135 can then be used by the change identifier comparator 155 to determine which items 170 have changed since the last synchronization, particularly those attribute groups 180 within each item 170 .

For example, each item token 135 may be compared to each item 170 . More specifically, the change ID 175, 140 and attribute group ID 185, 145 in the item token 135 and the actual item 170 may be compared using the change identifier comparator 155. If the values are different, i.e. the item change ID 140 and the attribute group ID 145 for the item token 135 do not match the item change ID 175 and the attribute group ID 185, then a change to the item 170 and attribute group 180 has occurred. As mentioned above, although the change ID for item token 135 is compared with item 170 and attribute set 180 on server 125 to determine when item 170 and attribute set 180 have changed since the last sync, it is determined that the change ID for item 170 Other methods of when or whether changes to attribute groups 180 occur may also be used with the present invention. For example, the server 125 can store all the information needed to determine what changes are needed on the client side 105 without changing the IDs 140, 145, 175, 185. Accordingly, the specific use of change IDs 140, 145, 175, 185 as described herein is for illustrative purposes only and is not meant to limit or otherwise narrow the scope of the invention unless expressly stated.

Regardless of how a changed property set 104 is identified, this changed property set 104 may be included in a synchronized item stream 102, which may be sent to a client 105 according to example embodiments described below. In addition, as described above, the map 190 identified by the specific versioned ID 195 may also be sent before, during, or after the synchronization item stream 102. As will be discussed in more detail below, a property group 104 within a synchronized item stream 102 should identify a specific mapping 190 for a version 195 of this property group 104 .

FIG. 1B shows an example block diagram of a map 190 for a specific version identifier 195 . As shown, the map 190 includes a plurality of items 106 and for each item 106 an attribute set 108 , 114 . Of course, there may be any number of attribute groups 108 , 114 that can be identified within any particular item 106 . In addition, for each particular attribute group 108,114, attributes 112,116 are also mapped. For example, attribute group "A" 108 may include attributes 112 "C" and "E," while attribute group "B" 114 may include attribute "A" 106 .

Consider an example where map 190 identifies email item 106 with attribute set "A" 108 for relatively small, volatile data attributes, while the map for attribute set "B" 114 includes larger attributes. As such, attribute "C" 112 and attribute "E" 112 within attribute group "A" 108 may be trace flags and priority flags, respectively. On the other hand, attribute "A" 116 to attribute group "B" 114 may be an attachment file. Of course, other known ways of providing the mapping 190 can also be used in the present invention. Accordingly, the mapping configuration provided within FIG. 1B is used here for purposes of illustration only, and is not meant to limit or otherwise narrow the scope of the present invention unless expressly stated.

Note that current and previous attribute group maps 190 can be persisted on the server database and can be accessed via version ID 195. If an item 170 is encountered with an unknown version identifier 195, or the item has no group identifier, then the item should be treated as if it does not have any attribute grouping 180 and should be treated as a whole. Thus, if an item 170 such as this needs to be downloaded to the client 105, the entire item 170 is streamed 102.

One embodiment provides synchronization through a streaming mechanism hereinafter referred to as fast transfer. This process allows the server 125 to respond to the synchronization request 130 by decomposing and serializing the changed property set 104 into a raw binary bit stream. The server 125 packs as many messages 102 as it can into a fixed-size response buffer and returns the data 102 to the client 105. Client 105 then parses the data and reconstructs attribute set 104 by deserializing byte stream 102 . An example format of the byte stream 102 is shown below with reference to FIG. 1C , which shows an example of a sync item stream 102 , a wired (or wireless) data representation of what the sync item stream 102 might look like.

The first part of the sync item stream 102 is an IncrSyncProgressItem (item's incremental sync progress) 118 that is added to the beginning of the stream 102 to provide information about the total size of all subsequent items in the response stream 102 . Next, IncrSyncProgressPerItem (incremental synchronization progress per item) 122 indicates the total size of the next item in the synchronized item stream 102 . The next packet 124 within the sync stream 102 is a map as indicated by the tag IncrSyncPropGroupMap (incremental sync property group map), which tells the client 105 what property group map is to be used for the next item or items in stream 102 . Accordingly, the various property groups 180 may be identified using the IncrSyncPropGroup (incremental synchronization property group) tag and an array or list of property IDs within each property group 180 . In other words, the synchronized item stream 102 may include a map 190 or a set of maps 190 for various version IDs 195 as described herein. Note, however, that map 190 need not be included within synchronization item stream 102, but may follow or precede synchronization stream 102, as described above.

The next set of tags 126, the IncrSynPropGroup ID (incremental synchronization property group ID), indicates what property group mapping is used for the next one or more items in the stream. That is, the version ID within the group 126 identifies the mapping 190 for the version identification 195 of the next item. Next, IncrSynChgItem (incremental sync changed item) 128 is a marker indicating the beginning of the changed item, followed by an array of attribute groups to be changed within the item. For example, individual property groups that have changed may be identified, as indicated by tags in IncrSynChgPropGroup (incremental sync changed property group) 132 . For example, as shown in flow 134, IncrSnyChgPropGroup deletes the current ItemRecipients (item recipients) by first having the DelProp (delete property) element, and then uses the StartRecip (start recipient) and EndRecip (end recipient) tags to Replace the recipient property to change the recipient property. As another example, elements in stream 136 include an IncrSyncChgPropGroup for item attachments, such that the current ItemAttachments (item attachments) will be deleted using DelProp and replaced with NewAttach (new attachments) and EndAttach (end attachments) tags. Of course, other attribute groups may be included within the stream as indicated by the ellipses provided thereafter.

Other exemplary embodiments can combine existing methods of synchronizing items with the current embodiments provided herein. For example, in conventional systems that do not provide any mapping, entire items may be downloaded within the synchronized item stream 102 . For example, as shown in element 138, IncrSyncProgressPerItem indicates the total size of the next item, while IncrSyncChgItem marks the beginning of the changing item. The next marks, the marks 142 for IncrSyncDel (incremental synchronization delete), IncrSyncRead (incremental synchronization read) and IncrSyncEnd (incremental synchronization end) represent respectively: (1) the item to be deleted from the client 105 list; (2) read state transitions as follows; and (3) a flag indicating the end of the sync session. Finally, IncrSyncStateBegin (incremental synchronization state start) represents the next final synchronization state in the byte stream, and IncrySyncStateEnd (incremental synchronization state end) is a marker representing the completion of the synchronization state.

The invention may also be described in terms of methods including functional steps and/or non-functional acts. The following is a description of acts and steps that may be performed in implementing the invention. Generally, functional steps describe the invention in terms of results being achieved, whereas non-functional acts describe more specific actions for achieving a particular result. Although functional steps or non-functional actions may be described or claimed in a particular order, the invention is not limited to any particular order or combination of actions and/or steps. Furthermore, the use of steps and/or actions is the recitation of the claims and is used in the following description of the flowcharts of FIGS. 2A and 2B to indicate the specific use of these terms intended.

2A and 2B show flowcharts for various exemplary embodiments of the present invention. The following description of FIGS. 2A and 2B will occasionally refer to corresponding elements in FIGS. 1A-C . Although reference may be made to specific elements in these figures, these elements are used for purposes of illustration only and are not intended to limit or otherwise narrow the scope of the invention unless expressly stated otherwise.

FIG. 2A shows a flowchart of a method 200 of increasing the rate of synchronization between a client and a server by synchronizing only selected portions of items that have changed, without monitoring changes to every individual attribute within the item. Method 200 includes an act of receiving 205 a request to synchronize a data item. For example, server 125 may receive a request 130 to synchronize data items 170 that have changed since the last synchronization between server 125 and client 105, wherein data items 170 represent items with various attributes that may be modified or otherwise changed. full message. For example, data items 170 may be email messages, contacts, appointments, calendar information, tasks, notes, and the like. Attributes may include recipients, addresses, body, attachments, flags, status identifiers, or any other variety of attributes for a message. Also note that the data link between server 125 and client 105 for synchronizing data items 170 can be a wireless connection or a wired connection, where the customer on client 105 is synchronizing data items based on the number of bytes downloaded from server 125. Item 170 paid.

The method 200 may also include steps for reducing 225 the data transfer time between the client and the server. More specifically, the step for 225 includes the act of determining 210 that a data item has changed since the last synchronization. For example, server 125 may determine (using change ID comparator 155 or other methods described herein) that data item 170 has changed since the last synchronization between client 105 and server 125 . As noted above, data items 170 include attribute groups 170 that are predefined based on common industry knowledge and an understanding of the semantics of how one or more attributes within each attribute group are related. For example, in an email message, attribute groups may include a body attribute, a recipient attribute group, a subject attribute group, an attachment attribute group, a priority flag attribute group, a read status attribute group, a miscellaneous attribute group, and/or other any combination. Of course, other property groups may be defined, and other property groups are extensible, pluggable, and scalable, such that properties within property groups may be added, deleted, or otherwise redefined within them, and such that each property Groups may be added, deleted, or otherwise redefined based on changes in industry knowledge.

The step for 225 may also include determining 215 which attribute group within the data item has changed since the last synchronization. For example, item/attribute group module 155 and change ID comparator 155 can be used to determine which attribute groups 180 have changed since the last synchronization. Accordingly, the step for 225 includes an act of synchronizing 220 the changed one or more groups without streaming the entire data item. In particular, the synchronized item stream 102 can be streamed to the client 105 along with the attribute groups 104 that have changed since the last synchronization, without streaming the entire data item 170, in order to reduce the time spent between the client and the server during synchronization. data transmission time.

The determination of changes in data items 170 and attribute groups 180 may be based on change identifiers 140 , 145 , 175 , 185 for data items and attribute groups. Furthermore, the change identifiers 141, 145, 175, 185 for the data item 170 and the attribute group 180 may be the same. Furthermore, the change identifiers 140, 145, 175, 185 for the data items 170 and attribute groups 180 may be alphanumeric, globally unique identifiers or hash values.

Other embodiments provide a mapping 190 of data items 170 and attribute groups 180 therein. The mapping may be sent before, during or after sending the stream of synchronized items for the property group 104 that has changed. In any event, client 105 can use map 190 to learn what attributes are included in each attribute group 180 . Additionally, the second data item 170 may be determined to have changed, but without the attribute set 180 . In this case, the entire second data 170 may be streamed to the client 105 .

2B shows a flowchart of a method 250 of tracking changes to selected portions of items to increase the rate of synchronization between the client and server without monitoring changes to every individual attribute within the item. Method 250 includes an act of monitoring 255 a plurality of data items for synchronization purposes. For example, item/attribute group module 150 or other component may monitor data item 170, where data item 170 represents a complete message with multiple attributes that may be modified or otherwise changed. These attributes include, but are not limited to, those previously described herein, such as attachments, flags, body parts, and the like.

The method 250 also includes the act of determining 260 that a data item has changed since the last synchronization between the client and the server. For example, change identifier comparator 155 may be used to determine that data item 170 has changed since the last synchronization between server 125 and client 105 . As noted above, the data item includes a number of attribute groups 180 that are predefined based on common industry knowledge and an understanding of the semantics of how the attributes within each attribute group are related. Based on the determination that the data item has changed, method 250 also includes an act of updating 265 the item change identifier. For example, change identifier generator 160 may be used to update an item change ID 175 associated with data item 170, which will be used to identify that item 170 has changed for synchronization with client 105.

Similarly, method 250 includes an act of determining 270 which attribute set within the data item has changed. That is, change identifier comparator 155 within item/attribute group module 150 may be used to determine which attribute groups 180 have changed since the last synchronization between client 105 and server 125 . Based on a determination that an attribute set has changed, method 250 includes an act of updating 275 the attribute set change identifier. For example, the change identifier generator 160 can be used to update the change ID 185 for the attribute group 180, which will be used to identify that the attribute group 180 has changed, so that only the attribute group 180 will be synchronized with the client 105, so as to reduce the number of clients 105 Data transmission time between server 125. Note also that other alternative embodiments described above may be used for method 250 as well.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects as illustrative only and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes falling within the meaning and range of equivalent technical solutions of the claims are embraced within the scope thereof.

Claims (20)

1. A method of synchronizing data items between a first device and a second device, the method comprising: Cache a data item on the first device, the data item includes a plurality of attribute groups, each of the attribute groups includes one or more attributes of the data item, at least one of the attribute groups includes multiple attributes; and an act of synchronizing, by the first device, a changed set of the data item, the changed set in the attribute set of the data item, the changed set in the data item without streaming the entire said data item One or more properties of have changed since the last sync. 2. The method according to claim 1, wherein the plurality of attribute groups include a tracking attribute group and a read status attribute group. 3. The method of claim 1, further comprising: sending a synchronization request from the first device to the second device; and The changed set is received from the second device in response to the synchronization request. 4. The method of claim 3, further comprising: receiving an item token from the second device during the last synchronization; and storing the item token on the first device; and Wherein the synchronization request includes the item token. 5. The method of claim 4, wherein the item token is operable to determine a set of attributes within the data item that have changed since the last synchronization. 6. The method of claim 1, wherein the changed set includes more than one attribute of the data item. 7. The method of claim 1, further comprising: monitoring a plurality of data items for synchronization purposes, the plurality of data items including the data item; determining that the data item has changed since the last synchronization; and After determining that the data item has changed since the last synchronization, it is determined which attribute group in the data item has changed. 8. The method of claim 7, wherein, determining that the data item has changed since the last synchronization includes using an item change identifier to determine that the data item has changed since the last synchronization; Determining which attribute group in the data item has changed includes: using a change ID of the attribute group to identify the changed group in the data item; and The method also includes: updating said item change identifier after determining that said data item has changed since said last synchronization; and After the changed group is identified using the change ID of the attribute group, the change ID of the changed group is updated. 9. The method of claim 1, wherein, performing the act of synchronizing the changed set includes receiving, at the first device, a stream of synchronized items, the stream of synchronized items including an indication telling the first device what attribute set mapping is used for the data item; and The attribute group mapping maps attributes in the data item to the attribute groups. 10. The method of claim 1, further comprising receiving an item change notification on the first device, the item change notification prompting the first device to synchronize with the second device. 11. The method of claim 1, wherein the set of attributes is determined based on relative sizes of the attributes. 12. A computing device comprising: one or more computer storage media storing instructions and data items, said data items comprising a plurality of attributes divided into a plurality of attribute groups, each of said attribute groups comprising one or more of said attributes, at least one of the attribute groups contains a plurality of attributes; and a processing unit that reads and executes the instructions, execution of the instructions by the processing unit causes the computing device to synchronize changed groups of the data items without streaming the entire data item from another computing device, The changed set is in the set of attributes of the data item, one or more attributes in the changed set have changed since a last synchronization between the computing device and the another computing device. 13. The computing device of claim 12, wherein execution of the instructions by the processing unit causes the computing device to: after the computing device receives notification of an item change from the other computing device, send The other computing device sends a synchronization request, the synchronization request being a request to synchronize data items that have changed since a last synchronization between the computing device and the other computing device. 14. The computing device of claim 12, wherein the set of properties is based on volatility of the properties. 15. The computing device of claim 12, wherein the set of properties is configured in a manner that enables the set of properties to be redefined. 16. The computing device of claim 12 , wherein execution of the instructions by the processing unit causes the computing device to: determine that an attribute in a particular attribute group has changed; updating an attribute group change identifier for the particular attribute group after determining that the attributes in the particular attribute group have changed; and The property group change identifier is used to identify when a change has occurred to a particular property group. 17. The computing device of claim 16 , wherein execution of the instructions by the processing unit causes the computing device to: updating an item change identifier associated with the data item based on a determination that the data item has changed; and The item of data is determined to have changed when the item change identifier is different from the item change identifier received from the other computing device. 18. The computing device of claim 16, wherein the computing device is a client and the other computing device is a server. 19. A computer storage medium storing instructions, execution of the instructions by a processing unit of a client configures the client to: Locally cache data items on the client, the data items include a plurality of attribute groups, each of the attribute groups maps to one or more attributes of the data item, at least one of the attribute groups maps to to a plurality of attributes of the data item, the plurality of attribute groups includes at least a tracking attribute group and a read status attribute group; send a sync request to the server; and receiving a stream of synchronized items from the server in response to the synchronization request, the stream of synchronized items comprising a set of changed attributes in the data item rather than the entire data item, mapped to one or more of the set of changed attributes A number of properties have changed since the last synchronization between the client and the server. 20. The computer storage medium of claim 19, wherein said synchronized item stream specifies a mapping that maps attributes of said data items to said attribute groups; and Execution of the instructions by the processing unit configures the client to use the map to determine what attributes of the data item are included in each of the sets of attributes.

Images