US6324544B1 - File object synchronization between a desktop computer and a mobile device - Google Patents

Abstract

First and second computing devices each contain an object store which store objects indicative of file data. Synchronization components are provided to synchronize the objects while efficiently overcoming problems associated with synchronizing files.

Description

REFERENCE TO CO-PENDING PATENT APPLICATION

Reference is hereby made to the following co-pending U.S. patent applications:

Ser. No. 08/944,948 filed on Jul. 2, 1997, entitled “OBJECT SYNCHRONIZATION BETWEEN OBJECT STORES ON DIFFERENT COMPUTERS”;

Ser. No. 08/953,655 filed on Oct. 27, 1997, entitled “CONTINUOUS OBJECT SYNCHRONIZATION BETWEEN OBJECT STORES ON DIFFERENT COMPUTERS”;

Ser. No. 09/058,613, filed on Apr. 10, 1998, entitled ELECTRONIC MAIL OBJECT SYNCHRONIZATION BETWEEN A DESKTOP COMPUTER AND MOBILE DEVICE;

All of which are assigned to the same assignee as the present invention.

BACKGROUND OF THE INVENTION

The present invention relates to synchronization of objects between object stores on two different computing devices. More particularly, the present invention relates to synchronization of objects which represent file data between an object store on a desktop-type computer and an object store on a mobile device.

Mobile devices are small electronic computing devices often referred to as personal digital assistants. Many such mobile devices are pagers, hand held devices, or palm size devices, which comfortably fit within the hand. One commercially available device is sold under the mark “HANDHELD PC” (or “H/PC”), another is sold under the mark “PALM-SIZE PC” (or “P/PC”), both having software provided by Microsoft Corporation of Redmond, Wash.

Generally, the mobile device includes a processor, random access memory (RAM), and an input device such as a keyboard, touchpad or input buttons and a display. The keyboard can be integrated with the display, such as when the keyboard is incorporated as a touch sensitive display. A communication interface is optionally provided and is commonly used to communicate with the desktop computer. A replaceable or rechargeable battery powers the mobile device. optionally, the mobile device can receive power from an external power source that overrides or recharges the built-in battery.

In some prior applications, the mobile device is used in conjunction with the desktop computer. For example, the user of the mobile device may also have access to, and use, a desktop computer at work or at home or both. The user may typically run the same types of applications on both the desktop computer and on the mobile device. Thus, it is quite advantageous for such mobile devices to be designed to be coupled to the desktop computer to exchange information with, and share information with, the desktop computer.

While a wide variety of computing tasks and applications can be performed by such mobile devices, personal information managers (PIMs) are particularly well suited to mobile devices. PIMs typically comprise applications which enable the user of the mobile device to better manage scheduling and communications, and other such tasks. Some commonly available PIMs include scheduling and calendar programs, task lists, address books, and electronic mail (e-mail) programs. Some commonly commercially available PIMs are sold under the trademarks “MICROSOFT SCHEDULE+” and “MICROSOFT OUTLOOK” and are commercially available from Microsoft Corporation of Redmond, Wash. In addition to PIMs, however, such mobile devices may also run different types of applications, such as word processors, spread sheets, etc. Some such applications include those sold under the trademarks “POCKET WORD” and “POCKET EXCEL”, both of which are commercially available from Microsoft Corporation of Redmond, Wash.

The user may also typically make changes to the PIMs and other applications both on the mobile device and at the desktop. Therefore, it is advantageous for data stores associated with the PIMs and applications on both the mobile device and the desktop to contain the most up-to-date information, regardless of whether recent changes to the PIMs and other applications have been made on the mobile device or on the desktop computer. The process of coupling the mobile device with the desktop computer, and integrating the information stored by the PIMs on the mobile device and the desktop computer such that the two contain the same updated information is referred to as synchronization.

Synchronization of information in object stores in general, and synchronization of electronic mail objects are discussed at length in the above-identified patent applications. However, a number of problems present themselves when attempting to synchronize data files across diverse functional systems (e.g., across two different and normally incompatible computer architectures). For example, data files lack a unique, persistent object identifier associated with a file. The file name is typically used as the object identifier, and as such is very susceptible to identity loss simply by renaming the file. This affects many core data base operations, such as object copy, object move, and object compare operations, rendering all such operations suspect.

Another problem is presented during conversion of the file content based on the target device. In other words, in many cases, the programs on the different devices utilizing the object may not have a one-to-one correspondence. Thus, the form of the object must be converted before it is transferred from one object store (such as the desktop object store) to another object store (such as the device object store). Inherent in this conversion is the potential loss of fidelity from the original data file. In addition, conversion can also contribute to the problem of having no unique, persistent object identifier. For example, it may be desirable to provide the user with multiple conversion choices. However, the multiple conversion choices can result in different file extensions, thus resulting in another file name change.

In addition, some conversion engines provide a user interface, during conversion, which requests or requires user input. In the event that the mobile device is being remotely synchronized to the desktop computer, this presents a problem in that the user may not be present at the desktop to interact with the user interface generated by the conversion engine.

In addition, many conventional data files can be locked. In other words, files can be rendered read only files which cannot be written for any number of reasons. For example, where a word processing document is being used by one user at a different station, and a second user accesses the word processing document, the word processing document may be locked to the second user, rendering it read only, until the first user relinquishes control of the file.

Therefore, attempted synchronization of this document would be impossible, since the document cannot be written to and thus cannot be updated during the synchronization process. This problem can be exacerbated in a synchronization architecture which provides a continuous synchronization mode while the desktop and mobile device are connected to one another.

Similarly, if a continuous synchronization mode is provided between the desktop and mobile device, the bandwidth of the devices can be taken up by continuous synchronization of non-relevant files, such as temporary files and shortcuts. This deteriorates the performance of the system.

SUMMARY OF THE INVENTION

First and second computing devices each contain an object store which store objects indicative of file data. Synchronization components are provided to synchronize the objects while efficiently overcoming problems associated with synchronizing files.

In one embodiment, file renames are detected to avoid unnecessary duplication of files. In another embodiment, file conversions are performed while suppressing UI during a remote synchronization. Further, registered converters are identified to avoid unwanted loss of data when synchronizing a converted file. Also, locked files are identified and an error message is generated so synchronization of the locked file can be performed during a subsequent synchronization operation. In yet another embodiment, non-relevant files are not synchronized to avoid undesirable consumption of bandwidth during a continuous synchronization process.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a basic environment of the present invention.

FIG. 2 is a block diagram of one embodiment of a conventional desktop computer used in conjunction with a mobile device in accordance with the present invention.

FIG. 3 is a simplified pictorial illustration of one embodiment of a mobile device in accordance with the present invention.

FIG. 4 is a simplified block diagram of one embodiment of the mobile device shown in FIG.3.

FIG. 5 is a simplified pictorial illustration of another embodiment of a mobile device in accordance with the present invention.

FIG. 6 is an architectural block diagram illustrating one embodiment of portions of the desktop computer shown in FIG.2 and the mobile device shown in FIGS. 3-5 to illustrate synchronization of information stored in object stores on the desktop computer and the mobile device in accordance with one embodiment of the present invention.

FIGS. 7A and 7B are flow diagrams illustrating a normal synchronization operation in accordance with one embodiment of the present invention.

FIG. 8 illustrates a data structure which describes a packet transmitted during a synchronization operation in accordance with one embodiment of the present invention.

FIGS. 9A-9C are flow diagrams illustrating one embodiment of formulating packets on the desktop computer shown in FIG. 2 in accordance with the present invention.

FIGS. 10A-10C are flow diagrams illustrating receipt of packets during synchronization from a mobile device in accordance with one embodiment of the present invention.

FIG. 10D is a flow diagram illustrating renaming of a file in the context of a synchronization operation.

FIGS. 11A-11C are flow diagrams illustrating formulation of a packet on a mobile device in accordance with one embodiment of the present invention.

FIGS. 12A-12C are flow diagrams illustrating receipt of packets on a mobile device from a desktop computer in accordance with one embodiment of the present invention.

FIG. 13 is a flow diagram illustrating the creation of an exclusion list in accordance with one embodiment of the present invention.

FIG. 14 is a flow diagram illustrating the utilization of the exclusion list created in FIG. 13 on a desktop computer in accordance with one embodiment of the present invention.

FIG. 15 is a flow diagram illustrating the utilization of the exclusion list created in FIG. 13 on a mobile device in accordance with one embodiment of the present invention.

FIG. 16 is a flow diagram illustrating the suppression of a user interface during a remote convert operation in accordance with one embodiment of the present invention.

FIG. 17 is a flow diagram illustrating attempted synchronization of a file, which is locked, in accordance with embodiment of the present invention.

DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

Overview

FIG. 1 is a block diagram of a typical system or environment10 in which the present invention operates. System10 includesmobile device12 anddesktop computer14.Mobile device12 includesfirst application program16,second application program18, corresponding first and second object stores20 and22,synchronization engine24 andcommunication link26.Desktop computer14 includes first andsecond application programs28 and30, corresponding first and second object stores32 and34,synchronization engine36 andcommunication link38. It will be appreciated that bothdevice12 anddesktop computer14 include a number of other components, which are discussed in greater detail below. However, for the purposes of the overview discussion presented with respect to FIG. 1, the items set out above are sufficient.

In one illustrative embodiment of the present invention,application programs16 and28 are personal information manager (PIM) programs which support, for example, electronic mail messaging, scheduling, calendering, etc. Hereinafter, programs16 and28 will simply be referred to asPIMs16 and28. Of course,PIMs16 and28 can be configured to support a wide variety of other features, such as task lists and personalized address books, to name a few.

Object stores20 and32 are implemented in memory configured to store a plurality of individual records or objects, each comprising a plurality of fields or properties related toPIMs16 and28. In one illustrative embodiment,PIMs16 and28 are programs, such as that available under the commercial designation “POCKET OUTLOOK 97” and “MICROSOFT OUTLOOK 97”, respectively and objectstores20 and23 are configured to store objects, each of which having a plurality of attributes or properties associated with electronic mail messaging, such as a sender's name, the recipient's name, text messages, etc.Desktop computer14 executesPIM28 to maintain objects stored instore32, anddevice12 executesprogram16 to maintain objects stored inobject store20. In one illustrative embodiment, each object inobject store20 comprises the same set of properties or attributes stored inobject store32, or a subset of those properties or attributes.

Similarly,application programs18 and30 maintain objects on associatedobject stores22 and34, respectively. In one illustrative embodiment,application programs18 and30 are file system applications, such as those available under the commercial designations “MICROSOFT POCKET WORD” and “MICROSOFT WORD”, respectively. It should also be noted that any suitable number of other application programs, and associated object stores, can be provided ondevice12 anddesktop14. However, for the sake of simplicity, only programs16,18,28 and30, and their associated object stores, are described herein.

In one illustrative embodiment, the user desires to synchronizeobject stores20 and32 andobject stores22 and34. Thus, there are two instance of each object associated with the pair ofobject stores20 and32 (one instance inobject store20 and one instance in object store32) and two instances of each object associated with the pair ofobject stores22 and34 (one instance inobject store22 and one instance in object store34). When a user changes one instance of the object stored in eitherobject store22 or34, the second instance of that object in the other ofstores22 and34 is out of date and is desirably updated the next timemobile device12 is connected todesktop computer14, so that both instances of the same object contain up-to-date data. The same is true for instances of objects stored inobject stores20 and32. The process by which the out of date instance is updated is referred to as synchronization.

In order to accomplish synchronization,synchronization components24 and36 run onmobile device12 anddesktop computer14, respectively. The synchronization components communicate withapplication programs16,18,28 and30 (or directly with the associated object stores) through well defined interfaces (discussed in greater detail below) to manage communication and synchronization.

Synchronization components24 and36 communicate with each other throughcommunication links26 and38 which are disposed ondevice12 anddesktop computer14, respectively. Communication links24 and38 are illustratively commercially available communication links using a suitable communications protocol. For instance, in one illustrative embodiment,mobile device12 is connected todesktop computer14 with a physical cable which communicates using a serial communications protocol. Other communication mechanisms are also contemplated by the present invention, such as infra-red (IR) communication, direct modem communication, remote dial-up-networking communication, communication through commercially available network cards (i.e., using TCP/IP), remote access services (RAS), wireless modem, wireless cellular digital packet data (CDPD), or other suitable communication mechanisms.

Prior to discussing the synchronization process and associated mechanisms in greater detail, the present discussion proceeds with respect to a more detailed description of the components ofmobile device12 anddesktop computer14 for the sake of clarity.

Desktop Computer14

FIG.2 and the related discussion are intended to provide a brief, general description of asuitable desktop computer14 in which portions of the invention may be implemented. Although not required, the invention will be described, at least in part, in the general context of computer-executable instructions, such as program modules, being executed by apersonal computer14 ormobile device12. Generally, program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate thatdesktop computer14 may be implemented with other computer system configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 2, an exemplary system for implementingdesktop computer14 includes a general purpose computing device in the form of a conventionalpersonal computer14, including processingunit62, asystem memory64, and asystem bus66 that couples various system components including the system memory to theprocessing unit62. Thesystem bus66 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Thesystem memory64 includes read only memory (ROM)68 a random access memory (RAM)70. A basic input/output system (BIOS)72, containing the basic routine that helps to transfer information between elements within thedesktop computer14, such as during start-up, is stored inROM68. Thedesktop computer14 further includes ahard disk drive74 for reading from and writing to a hard disk (not shown) amagnetic disk drive76 for reading from or writing to removablemagnetic disk78, and anoptical disk drive80 for reading from or writing to a removableoptical disk82 such as a CD ROM or other optical media. Thehard disk drive74,magnetic disk drive76, andoptical disk drive80 are connected to thesystem bus66 by a harddisk drive interface84, magneticdisk drive interface86, and anoptical drive interface88, respectively. The drives and the associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for thedesktop computer14.

Although the exemplary environment described herein employs a hard disk, a removablemagnetic disk78 and a removableoptical disk82, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks (DVDs), Bernoulli cartridges, random access memories (RAMs), read only memory (ROM), and the like, may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk,magnetic disk78,optical disk82,ROM68 orRAM70, including anoperating system90, one or more application programs92 (which includePIM28 and program30),other program modules94, andprogram data96. A user may enter commands and information into thedesktop computer14 through input devices such as akeyboard40, pointingdevice42 andmicrophone43. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit62 through aserial port interface46 that is coupled to thesystem bus66, but may be connected by other interfaces, such as a sound card, a parallel port, game port or a universal serial bus (USB) Amonitor47 or other type of display device is also connected to thesystem bus66 via an interface, such as avideo adapter48. In addition to themonitor47, desktop computers may typically include other peripheral output devices such asspeaker45 and printers.

Thedesktop computer14 may operate in a networked environment using logic connections to one or more remote computers (other than mobile device12), such as aremote computer49. Theremote computer49 may be another personal computer, a server, a router, a network PC, a peer device or other network node, and typically includes many or all of the elements described above relative todesktop computer14, although only amemory storage device50 has been illustrated in FIG.2. The logic connections depicted in FIG. 2 include a local area network (LAN)51 and a wide area network (WAN)52. Such networking environments are commonplace in offices, enterprise-wide computer network intranets and the Internet.

When used in a LAN networking environment, thedesktop computer14 is connected to thelocal area network51 through a network interface oradapter53. When used in a WAN networking environment, thedesktop computer14 typically includes amodem54 or other means for establishing communications over thewide area network52, such as the Internet. Themodem54, which may be internal or external, is connected to thesystem bus66 via theserial port interface46. In a network environment, program modules depicted relative todesktop computer14, or portions thereof, may be stored in the remote memory storage devices. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Desktop computer14runs operating system90 that is typically stored innon-volatile memory68 and executes on theprocessor62. One suitable operating system is a “WINDOWS” brand operating system sold by Microsoft Corporation, such as “WINDOWS 95” or “WINDOWS NT”, operating systems, other derivative versions of “WINDOWS” brand operating systems, or another suitable operating system. Other suitable operating systems include systems such as the Macintosh OS sold from Apple Corporation, and the OS/2 Presentation Manager sold by International Business Machines (IBM) of Armonk, N.Y.PIM28 andapplication30 are preferably stored inprogram module94, in volatile memory or non-volatile memory, or can be loaded into any of the components shown in FIG. 2 from afloppy diskette78,CDROM drive80, downloaded from a network vianetwork adapter53, or loaded using another suitable mechanism.

Dynamically linked libraries (DLLs), comprising a plurality of executable functions are associated withPIM28 andapplication30 for execution byprocessor62. Interprocessor and intercomponent calls are facilitated preferably using the component object model (COM) as is common in programs written for Microsoft “WINDOWS” brand operating systems. Briefly, when using COM, a software component such as a DLL has a number of interfaces. Each interface exposes a plurality of methods, which can be called individually to utilize different services offered by the software component. In addition, interfaces are provided such that methods or functions can be called from other software components which optionally receive and return one or more parameter arguments.

In general, the DLLs associated withPIM28 andprogram30 are designed specifically to work in conjunction withPIM28 andprogram30 and to expose desktop synchronization interfaces that function according to a synchronization protocol. The DLLs, in turn, call interfaces exposed byPIM28 andprogram30 in order to access data representing individual properties of objects maintained inobject stores32 and34.Object stores32 and34, of course, can reside in any one of the suitable memory components described with respect to FIG.2.

Mobile Device12

FIG. 3 is a simplified pictorial illustration of one preferred embodiment of amobile device12 which can be used in accordance with the present invention.Mobile device12, as illustrated in FIG. 3, can be a desktop assistant sold under the designation “H/PC” having software provided by the Microsoft Corporation. In one embodiment,mobile device12 includes a miniaturized keyboard100,display102 andstylus104. In the embodiment shown in FIG. 3,display102 is a liquid crystal display (LCD) which uses a contact sensitive display screen in conjunction withstylus104.Stylus104 is used to press or contact thedisplay102 at designated coordinates to accomplish certain user input functions. Miniaturized keyboard100 is illustratively implemented as a miniaturized alpha-numeric keyboard, with any suitable and desired function keys which are also provided for accomplishing certain user input functions.

FIG. 4 is a more detailed block diagram ofmobile device12.Mobile device12 illustratively includesmicroprocessor106,memory108, input/output (I/O)components110,communication link26, wireless receiver112 and antenna114. These components ofmobile device12 can be coupled for communication with one another over asuitable bus116.

Memory108 is preferably implemented as non-volatile electronic memory such as random access memory (RAM) with a battery back-up module (not shown) such that information stored inmemory108 is not lost when the general power tomobile device12 is shut down. A portion ofmemory108 is illustratively allocated as addressable memory for program execution, while another portion ofmemory108 is optionally used for storage, such as to simulate storage on a disc drive.

Memory108 can includeoperating system118, one or more application programs42 (such asPIM16 andfile application18, etc.), as well asobject stores20 and22 andsync engine24. During operation,operating system118 is illustratively executed byprocessor106 frommemory108.Operating system118, in one embodiment, is a “WINDOWS CE” brand operating system commercially available from Microsoft Corporation. Theoperating system118 is designed for mobile devices, and implements features which can be utilized byPIM16 andfile application18 through a set of exposed application programming interfaces and methods. The objects inobject stores20 and22 are illustratively maintained byPIM16,file application18 andoperating system118, at least partially in response to calls to the exposed application programming interfaces and methods.

I/O components110, in one embodiment, are provided to facilitate input and output operations from a user ofmobile device12. I/O components110 for various embodiments ofmobile device12 are described in greater detail with respect to FIGS. 3 and 5.

Communication link26 is optionally provided as any suitable communication interface.Interface26 is illustratively used to communicate withdesktop computer14 as described with respect to FIG.1. Wireless receiver and driver112 and antenna114 are used for communicating wirelessly.

FIG. 5 is another simplified pictorial illustration ofmobile device12 in accordance with another embodiment of the present invention.Mobile device12, as illustrated in FIG. 5, includes some items which are similar to those described with respect to FIG. 3, and are similarly numbered. For instance,mobile device12, as shown in FIG. 5, also includes touchsensitive screen102 which can be used, in conjunction withstylus104, to accomplish certain user input functions. Whenmobile device12 is implemented as a pager,screen102 is not illustratively touch sensitive andstylus104 is not needed.

It should be noted that thedisplay102 for the mobile devices shown in FIGS. 3 and 5 can be the same size as one another, or different sizes from one another, but would typically be much smaller than a conventional display used with a desktop computer. For example, displays102 shown in FIGS. 3 and 5 may be defined by a matrix of only 240X320 coordinates, or 160X160 coordinates, or any other suitable size. Whenmobile device12 is a pager,display102 may be even smaller.

Themobile device12 shown in FIG. 5 also includes a number of user input keys or buttons (such as scroll buttons120) which allow the user to scroll through menu options or other display options which are displayed ondisplay102, or which allow the user to change applications or select user input functions, without contactingdisplay102. In addition, themobile device12 shown in FIG. 5 also illustratively includes apower button122 which can be used to turn on and off the general power to themobile device12.

It should also be noted that, in the embodiment illustrated in FIG. 5,mobile device12 includes ahand writing area124.Hand writing area124 can be used in conjunction withstylus104 such that the user can write messages which are stored inmemory108 for later use by themobile device12. In one illustrative embodiment, the hand written messages are simply stored in hand written form and can be recalled by the user and displayed on thedisplay screen102 such that the user can review the hand written messages entered into themobile device12. In another embodiment,mobile device12 is provided with a character recognition module such that the user can enter alpha-numeric information intomobile device12 by writing that alpha-numeric information onarea124 withstylus104. In that instance, a character recognition module in themobile device12 recognizes the alpha-numeric characters and converts the characters into computer recognizable alpha-numeric characters which can be used by theapplication programs16,18 inmobile device12.

Of course, wheremobile device12 is implemented as a pager,stylus104 andhandwriting area124 are not needed. Instead,mobile device12 can be simply provided withscreen102,user input buttons120,power button122, and a compact physical housing or case.

Overview of Synchronization

FIG. 6 is a more detailed block diagram ofsync engine24 onmobile device12 andsync engine36 ondesktop14.Sync engine24 onmobile device12 includessynchronization manager140 which is coupled to a set of application programs, such asPIM sync provider144 and filesync provider146.PIM sync provider144 is coupled toPIM object store20, and filesync provider146 is coupled to fileobject store122.

Sync engine36 ondesktop14 also includes asynchronization manager148 coupled to an associatedreference store150 and also coupled to application programs, includingPIM sync provider152 and filesync provider154.PIM sync provider152 is coupled toPIM object store32, and filesync provider154 is coupled to fileobject store34. Whileproviders144,146,152 and154 are shown coupled directly to associated object stores, those providers could also be coupled to the object stores through theapplication programs16,18,28 and30 instead. However, for the sake of simplicity, the present discussion proceeds only with respect to the arrangement shown in FIG.6.

Sync providers152 and154 expose application programming interfaces (APIs)156 which can be called bysync manager148 to read and store objects and object properties onobject stores32 and34. The interfaces156 generally allow the creation of data bases for different types of objects, and allow application programs to read and write property names and values to and from respective objects within each data base.

The interfaces are well documented as the IReplStore, and IReplObjHandler interfaces. Each of these interfaces exposes a number of well documented methods. For example, the IReplStore interface exposes22 methods which can be generally classified as methods which are used to manipulate the data store, methods used for object enumeration, methods used to obtain object information, methods used to manipulate handles to objects, methods used for user interface functions, and a number of miscellaneous methods. The IReplObjHandler interface exposes methods which are used to serialize objects by turning an object into a series of bytes, and to deserialize objects by turning the series of bytes back into an object. The methods included in the interface are also used to delete an object from the corresponding object store.

Sync manager148, in turn, exposes a well documented interface known as the IReplNotify interface toproviders152 and154. This interface exposes four well documented methods which are used to notifysync manager148 of any change or deletion made to an object in a corresponding object store, to set text to be displayed in a status bar where synchronization status can be observed by the user, to obtain a window handle which is used as a parent window of any modal dialogue or message box, and to obtain information about a mobile device which has been selected, or which is connected to the desktop.

Each of theproviders152 and154 are implemented to specifically work in conjunction with aparticular application program28 or34, respectively. In general, because the application program interface (API)156 is standardized, it allowssynchronization manager148 to access and synchronize any number of different desktop application programs, as long as the required interface methods are implemented for each application by corresponding providers.

Onmobile device12,providers144 and146 also provide the well documented IReplObjHandler interface such that objects in the associatedobject stores20 and22 can be serialized and deserialized.Providers144 and146 also illustratively implement three additional functions which can be used to initialize and terminate the provider, to handle object identification and change detection, and to retrieve device information about a particular object type. These functions and interfaces are also well documented.

Synchronization manager148 manipulatesreference store150 to maintain a mapping between instances of objects stored inobject stores32 and34 ondesktop14 and instances of the same objects stored inobject stores20 and22 onmobile device12. Objects are identified by handles which are created byproviders152 and154. The handles are opaque tosynchronization manager148, in thatsynchronization manager148 need not be concerned with the actual composition of the handles although the handles are manipulated and stored bysynchronization manager148.

Generally, in order to maintain the mapping,synchronization manager148 maintainsreference store50 so that it contains handles corresponding espectively to a plurality of objects in the object stores32 and34 ondesktop14 which are to be synchronized with instances of the same objects inobject stores20 and22 onmobile device12. The handles inreference store150 will typically correspond to objects that have been previously synchronized between the various object stores. The handles are updated after their corresponding objects have been synchronized.

The list of handles maintained inreference store150 is also used to determine which items need to be synchronized tomobile device12 the next timemobile device12 is connected todesktop computer14. In making this determination,synchronization manager148 also determines whether objects have been added to or deleted from the object stores so that appropriate additions and deletions can be made.

The handles stored inreference store150 should be formatted in accordance with the following criteria so that thedesktop synchronization providers152 and154 can perform the specified functions:

(a) Each handle should contain data that uniquely identifies an object—such as an object identifier, an ID number, a full pathname for a file system object, etc. This data should be persistent (in that it does not change for a particular object) and should not be reused for subsequently created objects. This data can be compared to determine whether two handles actually correspond to the same object. As is discussed below, this can be problematic for file system information, because the object identifier is typically the pathname, and can be changed simply by renaming the file.

(b) It should be possible to derive some object order based on the handle. This is required for efficient searching, as will be described below.

(c) The handle should have some sort of time stamp information, or version number. This information can be compared to determine whether an object has changed since the last handle was recorded inreference store150.

These handles are provided fromproviders152 and154 tosynchronization manager148, for storage inreference store150, during an enumeration process which is described below. This enumeration process is used to detect items which need to by synchronized whenmobile device12 is next coupled todesktop computer14.

FIGS. 7A and 7B are flow diagrams illustrating the enumeration process which is periodically performed bysync engine36 in obtaining and updating the list of handles stored inreference store150 for the purpose of determining which items need to synchronized upon next connection. After an initialization step indicated byblock160,synchronization manager148 constructs two lists of handles. The first list is obtained atstep162 by accessing the handles previously stored inreference store150 which correspond to objects that were previously synchronized. The second list of handles is obtained atstep164 by querying each of the synchronization providers152-154 using interface methods denoted by IReplobjHandler::FindFirstItem and FindNextItem. When successfully called, these interfaces enumerate an ordered list of handles corresponding respectively to a second group of objects, those objects currently in the object stores32 and34 corresponding to theproviders152 and154 which have enumerated the objects.

By comparing the list of handles returned by the current enumeration with the saved list of handles loaded fromreference store150,synchronization manager148 automatically detects changes and deletions. For example, each time a new object is returned during enumeration,synchronization manager148 attempts to find an object in its previously saved list of objects which represents the same object. If no matching handle is found,synchronization manager148 determines that a new object has been created and saved on the object store which enumerated the object under consideration. In order to determine whether matching handles are found, as is indicated byblock166,synchronization manager148 calls the interface method IReplStore::CompareItem.

Based on a comparison of the handles,synchronization manager148 creates any necessary handle-to-object mappings inreference store150 such that objects in the object stores ondesktop14 can be mapped to corresponding instances of the same object ondevice12. This is indicated byblock168.

Synchronization manager148 also determines whether any objects have been added, deleted, or modified in the particular object store from which they were enumerated. This is indicated byblocks170. For example, if the list of objects which were previously synchronized contains a handle that is not found in the newly created list based upon a current enumeration of synchronization providers152-154, that indicates that the object has been deleted from the correspondingdata store32,34. Thus,synchronization manager148 determines that the object must also be deleted from themobile device12 during the next synchronization operation.

Similarly, if the enumeration of objects produces an object handle which does not occur in the list of objects previously synchronized, thensynchronization manager148 determines that an object corresponding to that particular handle has been added to the desktop object store which enumerated the object. Thus, during the next synchronization operation, the object must be added tomobile device12.

Synchronization manager148 also calls the interface method IReplStore::IsItemChanged with matching handles from the first and second lists. Calling this interface causes theappropriate provider152 or154 (whichever enumerated the matching handle) to determine whether the object has changed since its handle was last written toreference store150. In one illustrative embodiment, the provider examines the time stamp information or version number information associated with the object handle. If that information is not identical, that indicates that there has been a change to the object. Thus, during the next synchronization process,synchronization manager148 must update the corresponding object on mobile device12 (assuming there is no conflict as discussed below).

Synchronization manager140 onmobile device12 also interacts withsynchronization providers144 and146 to determine whether any objects onobject stores20 and22 have been added, deleted, or changed since the last synchronization process. Onmobile device14, the “WINDOWS CE” brand operating system posts a message tosynchronization manager140 every time an object onmobile device12, which is to be synchronized, changes, is added, or is deleted.Synchronization manager140 enumerates each object and calls methods in the IreplNotify interface of eachprovider144 and146. Based on this call, the provider determines whether the particular object enumerated is to be synchronized and indicates tosynchronization manager140 how many objects are to be synchronized (for example, a file system object, such as a directory, actually contains more than one object which is to be synchronized).

Based on the notifications posted from the operating system,synchronization manager140 maintains a list, or array, of objects which have changed, deleted, or added since the last synchronization process. Upon connection todesktop computer14, this list is provided tosynchronization manager148. Thus,synchronization manager148 contains the lists which have been constructed for bothdesktop14 andmobile device12 which indicate objects which need to be synchronized. This is indicated byblock172 in FIG.7B.

Synchronization manager148 then determines, as indicated atblock174, whether an object has changed only onmobile device12, only ondesktop14, or on bothmobile device12 anddesktop14. If the object has changed only on one of the desktop object stores, thensynchronization manager148 carries out the necessary activity to update the corresponding object store on the mobile device. This is indicated byblock176. If the object has changed only on one of the mobile device stores, thensynchronization manager148 carries out the necessary activities to update the corresponding desktop object store. This is indicated byblock180.

However, if the same object has changed on bothmobile device12 anddesktop14, then a conflict situation arises. In one illustrative embodiment,synchronization manager148 makes a call to the registry in the operating system ofdesktop computer14 to obtain conflict information which instructssynchronization manager148 how to proceed in the face of a conflict. This is indicated byblock178. For example, the user may have set preferences which indicate that, in the case of a conflict either the desktop computer version, or the mobile device version should take precedence every time. Similarly, the user may have set a preference which indicates that the user is to be notified in the case of a conflict so that the user can actively decide which version will take precedence. In that case,synchronization manager148 generates a user interface allowing the user to resolve the conflict.Synchronization manager148 then takes the necessary steps to resolve the conflict and update the appropriate object store. This continues until all objects in the lists of objects to be synchronized have been dealt with. This is indicated byblock182.

In order to exchange objects withmobile device12,synchronization manager148 continually calls the method IReplObjHandler:GetPacket to have anappropriate provider152 or154 obtain a packet of information to be transmitted tomobile device12. To handle a packet received frommobile device12,synchronization manager148 calls IReplObjHandler::SetPacket. This acts to provide a packet of information received frommobile device12 to asynchronization provider154 for storage on its associated object store. Similar interfaces are called bysynchronization manager140 onmobile device12. These methods are discussed in greater detail below.

EXCHANGING OBJECTS

The present invention primarily deals with problems associated with attempting to synchronize file system data stored infile object store34 and maintained byfile sync provider154. Thus, the remainder of the present discussion proceeds with respect to file system data only.

File object store34 andfile object store22 each hold a synchronized files folder which contains a hierarchical list of objects to by synchronized. In other words, a user will typically place an item in that folder if the user wishes the item to be synchronized betweendesktop computer14 andmobile device12. The objects in the synchronized files folder can include directories, subdirectories, files, etc.

In order to packetize this information for transmission betweenmobile device12 anddesktop14, the information is arranged into a series of serial bytes, such aspacket184 illustrated in FIG. 8. A first packet illustratively includes object attributes186, an object path which provides a file name path relative to the synchronized files folder and which is indicated bynumeral188, andobject file content190. In one illustrative embodiment, theentire packet184 is 4K bytes long. After thefirst packet184 is generated, subsequent packets (if any) corresponding to the object simply contain 4K bytes of file content information until the entire object has been transmitted.

FIGS. 9A-9C comprise a flow chart which illustrates the steps performed whensynchronization manager148 transmits an object tomobile device12. First,synchronization manager148 calls the function IReplObjHandler::GetPacket as indicated byblock192. Based on this call, filesync provider154 determines whether this is the first packet of the specified object being transmitted. This is indicated byblock194. If this is not the first object, filesync provider154 simply fills the packet with the designated amount of file object contents, as indicated byblock196, and returns the packet tosynchronization manager148 for transmission.Provider154 then determines whether there are any additional contents to be transmitted for the specified object. This is indicated byblock198. If there are additional contents, thensynchronization manager148 again calls the GetPacket function to have another packet prepared for transmission. However, if there are no more contents in the present object,provider154 returns a value designated by RWRN_LAST_PACKET. This is indicated byblock200 and indicates to syncmanager148 that the object packetization has been completed.

If, atblock194,provider154 determines that this is the first packet,provider154 determines whether the object is a folder. This is indicated byblock202. If the object is a folder,provider154 adds thefolder attribute information186 to the packet being prepared as well as therelative path information188. The packet is then returned tosynchronization manager148 for transmission tomobile device12. This is indicated byblocks204 and206.

If, atblock202,provider154 determines that this is not the first packet of a folder, but rather is the first packet of a file,provider154 reviews the internal object bits in the object to determine whether this is a new object. In other words,provider154 determines whether this object has been synchronized in the past. This is indicated byblocks208 and210.

If this object is a new object,provider154 causes a user interface dialogue box to be displayed to the user atdesktop computer14 indicating that the object being synchronized is a new object, indicating the location (illustratively by path name) where the new object will reside ondevice12, and also indicating that the new object is being backed up and the location of the backup. In one illustrative embodiment, the user may choose not to see this dialog in the future. This is indicated byblocks212 and214. If, atblock210, it is determined that the current object is not a new object,provider154 does not bring up this dialogue box.

Provider154 then determines whether a conversion is required. For instance, if the file data being synchronized is a word processing document generated using the “MICROSOFT WORD” brand word processor, and they are being synchronized to a device running the “WINDOWS CE” brand operating system and which uses the “MICROSOFT POCKETWORD” brand word processor, the file must undergo conversion to a format suited for the “MICROSOFT POCKETWORD” brand processor. This is indicated byblock216. If no conversion is required, processing simply continues atblock224.

However, if conversion is required,provider154 invokes a conversion engine which makes the necessary conversion and places the converted information in a temporary folder. This is indicated byblock218. The invocation of a converter engine also includes generating and walking an exclusion list based upon converters which do not have registered default import and export keys. This is described in greater detail with respect to FIGS. 13-15.

After the data has been converted,provider154 obtains thefile attribute information186 and therelative path information188 and adds that information to the packet being created. This is indicated byblocks220 and222.

Next, the file is opened such that the first packet being created can be filled to capacity withfile object content190. This is indicated byblocks224 and226. The packet is then returned tosynchronization manager148 for transmission tomobile device12. The GetPacket function is continually called bysynchronization manager148 untilprovider154 returns the value RWRN_LAST_PACKET which indicates that the last packet has been returned.

FIGS. 10A-10C are flow diagrams illustrating the operation ofsync engine36 in performing a set packet operation (i.e., in receiving a packet being synchronized from mobile device12).Synchronization manager148 first receives a packet as indicated byblock228.Synchronization manager148 then calls IReplObjHandler::SetPacket supplying the packet, as indicated byblock230. This supplies the packet to filesync provider154 which, in turn, determines whether this packet is the first packet of a specified object. This is indicated byblock232. If this packet is not the first packet,provider154 simply writes the packet to the file which has been opened to receive these packets, and processing continues atblock246. This is indicated byblock234.

However, if this is the first packet of an object to be synchronized,provider154 opens the packet and checks the internal bits as indicated byblock236 and determines whether this object is a new object (i.e., it is an object which has not previously been synchronized to desktop computer14). This is indicated byblock238. Ifprovider154 determines that this is a new object,provider154 brings up a dialogue to the user indicating that this is a new object and indicating where the object is being stored and backed up.Provider154 also backs up the object at the same time. This is indicated byblock240.

However, if this is not a new object, processing simply continues atblock242 whereprovider154 obtains theattribute information186 and filepath information188 from the packet. Since this is the first packet in the identified object,provider154 then creates a file in the temp directory. This is indicated byblock244.

Provider154 then determines whether there are any additional packets to receive for this object. If so, control continues atblock228 and another packet is received and the function SetPacket is again called bysynchronization manager148. This is indicated byblock246.

However, if there are no more packets to be received for this object,sync provider154 determines whethersynchronization manager148 is in a conflict situation in which both instances of the same object have been changed. This is indicated byblock248. If so,provider154 simply returns a dummy handle tosynchronization manager148, which resolves the conflict situation as described with respect to FIG.7B. This is indicated byblock250.

If, atblock248,provider154 determines that this is not a conflict situation,provider154 creates the destination path for the file conversion, and invokes the converter engine to convert the file to the appropriate form for storage onfile object store34. This is indicated byblocks252 and254.

Atblock252, one of two destination paths are created. Ifprovider154 is to perform a combine operation (described below), then the destination path is created in the temp directory. Otherwise, the destination path is simply the full pathname in the synchronized files folder infile object store34.

A combine/discard operation is required if the mapping between the stores ondesktop14 anddevice12 have been lost, for some reason. This mapping must be re-established using the combine/discard process. A combine operation means combining all the desktop and device objects together. A discard operation means discarding the device objects and replacing them with desktop objects. Therefore, atblock252, ifprovider154 is performing a combine operation, the destination path for the file to be converted is in the temp directory. Otherwise, it is simply in the synchronized files folder.

Provider154 then takes one of two courses of action, depending on whether it is performing a combine operation, as determined inblock256. If the combine operation is being performed,provider154 determines whether the file in the temp folder which has just been synchronized from the mobile device is the same as (i.e., identical to) the original file in the synchronized files folder. In order to do this, in accordance with one embodiment,provider154 simply performs a binary comparison of the two files. If they are the same, and the destination file still exists,provider154 returns a flag referred to as the RSF_DUPLICATED_OBJECT flag tosynchronization manager148 indicating that the file is a duplicate file, so that it does not need to be processed, as it would otherwise be during the synchronization process.

If, atblock260, it is determined that the destination file does not exist, thenprovider154 copies over the file then in the temp directory to the destination folder, as indicated byblock264.

Further, if, atblock258, the binary comparison indicates that the file in the temp folder and the original file are not the same, the original file is renamed to “copy of <file name>” and the file in the temp directory is copied into the original file in the destination folder. This is indicated byblocks26630 and268.

If, atblock256, it is determined that the present operation is not part of a combine operation, processing simply skips to block270. Atblock270,provider154 determines whether the object being synchronized already existed on the desktop, but simply had a different file name. This can occur, for instance, when the sequence illustrated by FIG. 10D is performed. For example, if the user creates a file on the desktop named “meeting.doc”, as indicated byblock273, and places this file into the synchronized files folder, thenext time desktop14 is connected todevice12, “meeting.doc” will be synchronized to the device. This is indicated byblock275. At the same time,synchronization manager148 ondesktop14 will create a mapping between the desktop “meeting.doc” file, and the device “meeting.doc” file. This is indicated byblock277. Then, assume that the user renames “meeting.doc” on the device to “summary.doc”. This is indicated byblock279. That being the case, the “WINDOWS CE” brand operating system will generate a notification that “meeting.doc” has been deleted. The operating system will also generate a notification indicating that a document “summary.doc” has been created immediately thereafter. This is indicated byblock281.

When the synchronization operation is re-started (such as when thedevice12 is reconnected to the desktop14) it will appear that “meeting.doc” has been deleted from themobile device12, which would ordinarily cause the deletion of “meeting.doc” from thedesktop14. This is indicated byblocks283 and285. However, this would be inefficient since the file “meeting.doc” has simply been renamed to “summary.doc”.

Therefore, referring again to FIG. 10C, atblock270 it is determined whether the object already exists on the desktop, but simply has a different file name. There are a number of different ways that this can be accomplished. For example, since the “WINDOWS CE” brand operating system treats a rename ondevice12 as a delete followed by an immediate recreate of a file,synchronization manager148 can simply monitor the change notifications received fromdevice12 to look for situations where a delete has been immediately followed by a recreate. In that instance,synchronization manager148, itself, determines that this is not a deletion and creation of a file and treats it as a normal change. Thefile sync provider154 can determine that this is a rename by cracking the packet open and viewing the contents of the object to determine whether it is identical to another object, except for the file name.

In any case, if, atblock270, it is determined that it has not simply been a rename, then the new object handle is created atblock272.

If, however, atblock270, it is determined that this has been simply a rename,provider154 determines whether the object is a directory. This is indicated byblock274. If it is a directory, the directory is simply renamed atblock276 andprovider154 returns a flag referred to as the RSF_UPDATED_HANDLE flag and also returns the new handle for the renamed directory. This is indicated byblocks278 and280.

If, however, atblock274, it is determined that the object is not a directory (meaning that it is a file) the original file is deleted (since it has been renamed). This is indicated byblock282. Again,provider154 returns the RSF_UPDATED_HANDLE flag and returns the new handle tosynchronization manager148. This is indicated byblocks282,278 and280.

Upon receiving the RSF_UPDATED_HANDLE flag,synchronization manager148 simply maps the newly created “summary.doc” file to the one ondevice12. In other words, the old mapping of the original file is simply updated.

FIGS. 11A and 11B illustrate the operation ofdevice12 when performing a SetPacket operation. This occurs when the desktop sends a file to the device for writing. Initially,synchronization manager140 receives a packet and calls the SetPacket function. This is indicated byblock286.

File sync provider146 then determines whether this is the first packet of the object, as indicated byblock288. If so,provider146 obtains the relative path and attributes from the packet, as indicated byblock290.

Provider146 then determines whether the object is a directory. This is indicated byblock292. If the object is not a directory,provider146 ensures that all appropriate subdirectories in the path are created, as indicated byblock294.Provider146 then ensures that the file is unlocked as indicated byblock296.

Provider146 then determines whether the file name containing the object identifier in the packet which has just been received is different from the file name in the file which has just been opened. If so, the file is renamed to that contained in the packet. This is indicated byblock298. Then, the file is opened for writing, as indicated byblock300, and another packet is received.

If, atblock292,provider146 determines that the path identifies a directory,provider146 determines whether the directory already exists, as indicated byblock302. If not, the directory is created and the new object ID is set in the log which is maintained bysynchronization manager140 which is used in creating the lists of objects to be synchronized. This is indicated byblocks304 and306. The attributes provided in the packet are then set in the directory and the change bit which was set by the operation system notification is cleared. This is indicated byblocks308 and310.

If, atblock288,provider146 determines that this is not the first packet of the object being synchronized,provider146 simply writes the packet to the file which has been opened, as indicated byblock312.Provider146 then determines whether additional packets are to be received as indicated byblock314. If so, additional packets are received and written to the open file. This process continues until all packets in the object being synchronized have been received.

FIG. 12 is a flow diagram illustrating the operation offile sync provider146 ondevice12 in performing a GetPacket operation. This occurs when the desktop requests a file to be sent from the device. First,synchronization manager140 calls the GetPacket function. This is indicated byblock316.Provider146 then determines whether the packet being obtained is the first packet in the identified object. This is indicated byblock318. If it is not the first, processing continues atblock328 andprovider146 simply fills the packet to its capacity with file content. Then,provider146 determines whether any additional packets exist for the object. If so,provider146 simply waits to receive another GetPacket call fromsynchronization manger140. If no additional packets are present,file synchronization provider146 returns an appropriate value tosynchronization manager140 indicating that.

If, atblock318,provider146 determines that the packet is indeed the first packet,provider146 obtains the object identifier for the object and sets an indication that the change bit in the change notification must be cleared once the file has been synchronized to the desktop. This is indicated byblocks320 and322.File sync provider146 then places the relative path and file attributes into the packet, since it is the first packet. This is indicated byblock324.

Next, assuming that the object is a file and is not in a conflicting situation, the file is opened for reading and a remainder of the packet is filled with file content. This is indicated byblocks326 and328. This process continues until the entire object has been packetized and sent tosynchronization manager140 for transmission todesktop12.

CREATING THE EXCLUSION LIST

As discussed above, some files need conversion such that they are in a suitable format for the destination for which they are being synchronized. For example, files which are in a format suitable for the “MICROSOFT WORD” brand word processor which are being synchronized todevice12 must be converted so that they are in a format suitable for the “MICROSOFT POCKETWORD” brand word processor.

If a converter is registered in the operating system ofdesktop14, it may have default import and export keys which are used in performing the conversion. An import key is used in performing a conversion for importing the file tomobile device12. An export key is used in converting the file for exporting it frommobile device12 todesktop14.

If the necessary import or export key does not exist, the file cannot be adequately converted. For example, if an import key exists for a document, the file can be converted from the format ondesktop14 to the format ondevice12. However, if the corresponding export key does not exist, the file cannot be converted back to the format ondesktop14. Therefore, if the synchronization components attempt to synchronize the file back to the desktop, without converting it, the synchronization component would rewrite the document ondesktop14 with the differently formatted document ondevice12, thus possibly losing information in the synchronization back to the desktop. The same is true if the import key does not exist. Therefore, eachtime device12 is connected todesktop14, an exclusion list is created or modified for both the desktop and the device.

FIG. 13 is a flow diagram illustrating the creation of the exclusion lists. First, thedevice12 is connected to thedesktop14 as indicated byblock332. The converter engine ondesktop14 then makes a suitable interface call to enumerate all registered converters. This is indicated byblock334. The converter engine then determines whether the particular converter has a registered default import key as indicated byblock336. If so, processing simply continues atblock340, and the converter is not added to the exclusion list on the desktop. However, if no import key exists, the file extension associated with the converter is added to the desktop exclusion list as indicated byblock338.

The converter engine then determines whether any more converters have been registered. This is indicated byblock340. If so, the converter engine again checks for appropriate default import keys and adds the necessary file extensions to the exclusion list. This continues for each registered converter and object type. Once all converters and object types have been examined, the exclusion list is written to the registry ondesktop computer14. This is indicated byblock342.

The same process is performed to generate an exclusion list formobile device12. However, inblock336, rather than looking for registered default import keys, the converter engine looks for registered default export keys. If the export keys do not exist, the file extension is added to the exclusion list which is written to the registry in a location associated with the particular device then connected todesktop computer14.

UTILIZATION OF THE EXCLUSION LISTS

Once the exclusion lists have been created, they are utilized by the converter engines each time the converter engines are invoked. FIG. 14 is a flow diagram indicating how they are utilized. First,synchronization manager148 makes a call to filesync provider154 indicating that a selected object needs to be packetized for synchronization. This is indicated byblock344. Theprovider154 invokes the converter engine and examines the exclusion list, as indicated byblock346. If the object type to be synchronized does not reside in the exclusion list, as indicated byblock348, the object is simply synchronized tomobile device12 in the normal fashion. This is indicated byblock350.

If, atblock348, it is determined that the object to be synchronized is contained in the exclusion list,provider154 returns a value tosynchronization manager140 causing it to simply ignore the change during the present synchronization process. This is indicated byblock352.

It should be noted that the exclusion list is examined each time a file is to be converted for synchronization. Therefore, a file change may be ignored during one synchronization process because the converter is contained in the exclusion list. However, if the necessary converter is later installed on thedesktop14 and added to the registry, the exclusion list will be updated the next time thedevice12 is connected to thedesktop14, thus removing the file extension associated with the converter from the exclusion list. Therefore, during the next synchronization process, the object will no longer be ignored, but will be synchronized.

FIG. 15 is a flow diagram illustrating utilization of the exclusion list created fordevice12. First, the synchronization components detect that an object needs to be synchronized as discussed above. This is indicated byblock354. The exclusion list is then examined to determine whether the object type (e.g., file extension) is contained in the exclusion list. This is indicated byblock356. If the object type is not contained in the exclusion list, the object is simply synchronized to the desktop device and the change notification ondevice12 is cleared. This is indicated byblocks358 and360.

However, if, atblock356, it is determined that the object type is contained in the exclusion list,synchronization manager140 simply ignores the change and does not attempt to synchronize the object. This is indicated byblock362. Of course, as with the exclusion list fordesktop14, the exclusion list fordevice12 is also updated eachtime device12 is connected todesktop14. Therefore, the object can be synchronized during a later synchronization process, assuming the appropriate converter has been installed and registered indesktop14.

Appendix A illustrates one embodiment of code which can be used to create the exclusion list.

SUPPRESION OF UI DURING REMOTE SYNC

As discussed above, it may desirable to suppress certain user interface and dialogue messages when an object is being synchronized remotely, such as via a modem or wireless link, when the user is not at thedesktop14. When an object is to be synchronized, the object first passes a flag to thedesktop14 indicating that the synchronization process is to be conducted remotely. The present invention takes advantage of this flag to suppress UI.

FIG. 16 is a flow diagram illustrating how the UI is suppressed during a remote sync operation. First, a packet is received as indicated atblock364.Provider154 then checks the packet to determine whether the remote or continuous sync flags have been set. This is indicated byblock366.Provider154 also checks the registry ondesktop14, at a specific location, which is used to store a value indicating that progress messages are to be suppressed. This is indicated atblock368. If any of the suppression indicators inblocks366 or368 are set,provider154 sets a flag referred to as the CONVERT_NO_UI flag when calling the converter engine. This is indicated byblock370. This value causes the converter engine to suppress conversion progress dialogue, as indicated byblock372.

The converter engine then executes a QueryInterface on an interface designated ICeFileFilterOptions. This is indicated byblock374. The ICeFileFilteroptions interface exposes methods which can be used to manipulate converting and other filtering functions and is set out in Appendix B.

If the ICeFileFilter Options interface is not present, as indicated byblock376, the conversion continues simply suppressing conversion progress dialogue. However, if atblock376 it is determined that the ICeFileFilterOptions interface is present, then the converter engine calls a method indicated by SetFilterOptions specifying UI which should be suppressed during the present operation. This is indicated byblock378. Thus, during a remote or continuous sync operation, the suitable UI is suppressed.

LOCKED FILES

As discussed above, certain files may be locked when synchronization is attempted. For example, if another user is currently using a word processing document, and the file is to be synchronized, the file will be locked to the synchronization components so that it cannot be written to. FIG. 17 is a flow diagram illustrating how the present invention deals with such locked files.

Once it is determined that the file needs to be synchronized, the file sync provider attempts to open the file to synchronize it. This is indicated byblock380. The provider will then determine that the file is locked as indicated byblock382. In that instance, the provider returns to the synchronization manager an error message indicating that the file is locked. This is indicated byblock384. Thesynchronization manager148 then simply discontinues the attempted synchronization and indicates that the file for which synchronization has been attempted, is still out of date. This will continue during subsequent synchronization processes until the file is unlocked and synchronized. This is indicated byblock386.

SYNCHRONIZATION OF NON-RELEVANT FILES

In systems which are configured for continuous sync operations, another problem can arise with respect to non-relevant files, such as files stored in the temp directory, shortcuts, etc. For example, if a particular word processing document is contained in the synchronized files folder on the desktop, and the user is editing that document, the word processor typically creates a temporary file in the temp directory and places it in the same folder. As the document is being edited, the temporary file is changed continuously and thus needs to be synchronized continuously to the device. However, this is highly inefficient and takes up an undesirable amount of bandwidth. Therefore, in accordance with one embodiment of the present invention, such non-relevant files are not synchronized, even if they are contained in the synchronized files folder.

File sync provider154 examines the extension of the file in the synchronized files folder to determine whether they are non-relevant. For example, files which have an extension “.tmp” are not synchronized.File sync provider154 simply does not indicate tosynchronization manager148 that these files even exist during the enumeration process. Thus,synchronization manager148 will not even know that such files exist since they have not been enumerated, and they will not be synchronized.

CONCLUSION

Thus, it can be seen that the present invention provides file synchronization in a way that avoids many problems which are otherwise inherent in file synchronization. For example, the present invention deals with files which have been renamed on the device either by the user, or during conversion, in a highly efficient manner. The present invention also identifies duplicate files during a combine operation, prior to the normal sync operation. This also increases efficiency. Further, the present invention provides a user interface message indicating the location of the files being synchronized, backs those files up, and indicates the location of the backup file, when the file is synchronized for the first time. The present invention also creates an exclusion list which is utilized during conversion such that critical information is not lost because proper converter defaults have not been registered. The present invention also suppresses selected user interface messages under appropriate circumstances, deals with file locking problems, and does not synchronize non-relevant files. One or a combination of these features can be implemented in various embodiments of the present invention, to increase efficiency of file synchronization.

Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.

Claims (24)

What is claimed is:

1. A method of synchronizing objects indicative of file data between a first object store associated with a first computing device and a second object store associated with a second computing device, the objects having associated file names, the method comprising:

maintain a mapping table which maps objects to be synchronized on the first object store with corresponding objects on the second object store;

determining whether an object to be synchronized has been added to the second object store since a last synchronization process;

if so, adding a corresponding object to the first object store during a subsequent synchronization process;

determining whether the object added to the first object store during the subsequent synchronization process already exists on the first object store under a different file name;

if so, deleting the already existing object from the first object store; and

updating the mapping table to map the object added to the first object store to the object which was renamed on the second object store.

2. The method of claim1 wherein maintaining the mapping table comprises maintaining a handle associated with each object on the first object store and mapping the handle to a handle associated with a corresponding object on the second object store.

3. The method of claim2 wherein updating the mapping table comprises updating the handle associated with the already existing object to indicate that the object has been renamed.

4. The method of claim3 wherein, when the object added to the second object store is renamed from an original name to a new file name, the second computing device deletes the object under the original file name and subsequently recreates the object under the new file name and provides a notification to the first computing device indicating that the object under the original file name has been deleted and that the object under the new file name has been created.

5. The method of claim4 wherein the first computing device performs the step of determining whether the object added to the first object store during the subsequent synchronization process already exists on the first object store under a different file name based on the notification from the second computing device.

6. The method of claim1 wherein the first computing device comprises a desktop computer and the second computing device comprises a mobile device and wherein the step of maintaining a mapping table is performed by the desktop computer.

7. A method of synchronizing an object indicative of file data from a first object store to a second object store, the method comprising:

determining that the object is to be synchronized;

preparing packets indicative of the object to be transmitted from the first object store to the second object store;

determining whether the object to be synchronized is a new object in the second object store;

if so, displaying a message indicating a file path location where the object is to be placed during synchronization and

transmitting the object from the first object store to the second object store.

8. The method of claim7 and further comprising:

if the object to be synchronized is a new object in the second object store, storing a backup copy of the object.

9. The method of claim8 and further comprising:

providing a display indicating the file path location of the backup copy.

10. A method of synchronizing objects indicative of file data, each object being one of a plurality of object types, between a first object store associated with a first computing device and a second object stare associated with a second computing device, the method comprising:

maintaining a list of available converters for conversion of objects from a first format to a second format, each converter being configured to convert at least one of the object types, wherein the list is maintained based on the object types that the converter is configured to convert;

determining that a selected object is to be synchronized;

determining that the selected object is to be converted prior to synchronization;

examining the list;

generating an exclusion list including object types for which no converter is available;

determining whether the selected object is of an object type included in the exclusion list; and

if not, excluding the selected object from synchronization.

11. The method of claim10 wherein the first computing device comprises a desktop computer and the second computing device comprises a mobile device connectable to the desktop computer and wherein the steps of examining the list, generating an exclusion list including object types for which no converter is available, and determining whether the selected object is of an object type included in the exclusion list, are performed each time the mobile device is connected to the desktop computer.

12. The method of claim11 wherein the step of maintaining the list of available converters is performed each time the mobile device is connected to the desktop computer.

13. The method of claim11 and further comprising:

performing the steps of examining the list, generating an exclusion list including object types for which no converter is available, and determining whether the selected object is of an object type included in the exclusion list for the desktop computer and for the mobile device to create a desktop exclusion list identifying first object types for which no converter is available to convert objects of the first object type to a format suitable for the desktop computer, and a mobile device exclusion list identifying second object types for which no converter is available to convert objects of the second object type to a format suitable for the mobile device.

14. The method of claim13 wherein the list of available converters is maintained in a registry of the desktop computer.

15. The method of claim13 wherein the desktop exclusion list and the mobile device exclusion list are maintained in the registry of the desktop computer.

16. A method of synchronizing objects indicative of file data between a first object store associated with a first computing device and a second object store associated with a second computing device, the first and second computing devices being remotely connectable to one another, the method comprising:

determining that the first and second computing devices are remotely connected to one another;

determining that a selected object is to be synchronized; and

suppressing user interface dialog during synchronization, while allowing other computing operations to take place in the background, based on the determination that the first and second computing devices are remotely connected.

17. The method of claim16 and further comprising:

determining that the selected object is to be converted from a first format to a second format prior to synchronization; and

suppressing conversion progress user interface dialog messages during conversion.

18. The method of claim17 and further comprising:

determining whether a FileFilterOptions application programming interface is present on the first computing device; and

if so, calling a SetFilterOptions method exposed by the FileFilterOptions interface providing a value indicating that the user interface dialog messages are to be suppressed.

19. A method of synchronizing objects indicative of file data between a first object store associated with a first computing device and a second object store associated with a second computing device, one of the first and second computing devices being a mobile device and the other being a non-mobile device, the method comprising:

providing a synchronization manager on the first computing device which determines that a selected object in the second object store is to be synchronized to a corresponding object in the first object store;

providing a file synchronization provider;

indicating to the file synchronization provider that the selected object is to be synchronized;

determining, with the file synchronization provider, that the corresponding object in the first object store is locked;

returning an error message from the file synchronization provider to the synchronization manager indicating that the corresponding object in the first object store is locked;

maintaining, at the synchronization manager, an indication that the selected object is to be synchronized until the corresponding object is unlocked.

20. A method of synchronizing objects indicative of file data between a first object store associated with a first computing device and a second object store associated with a second computing device, the method comprising:

maintaining a folder of objects on the first and second object stores indicative of files to be synchronized; and

excluding from the synchronization process objects indicative of temporary files located in the folder.

21. The method of claim20 wherein the first computing device comprises a desktop computer including a synchronization manager and a file synchronization provider, and further comprising:

providing the file synchronization provider with an enumeration request from the synchronization manager requesting the file synchronization provider to enumerate objects in the folder in order for the synchronization manager to determine which objects in the folder need to be synchronized to corresponding objects in the second object store.

22. The method of claim21 wherein excluding from the synchronization process comprises:

failing to enumerate objects indicative of temporary files in response to the enumeration request.

23. A method of synchronizing objects indicative of file data between a first object store associated with a first computing device and a second object store associated with a second computing device, the method comprising:

providing a synchronization manager configured to provide an enumeration request and maintain a mapping between the objects on the first object store and the objects on the second object store;

providing a file synchronization provider configured to maintain a folder of file objects to be synchronized and to enumerate the file objects in response to the enumeration request such that the synchronization manager can determine which file objects need to be synchronized; and

when the mapping is lost, recovering the mapping by combining the file objects on the second object store with the file objects on the first object store utilizing the file synchronization provider and enumerating the combined files so the synchronization manager can reestablish the mapping, wherein combining includes determining, with the file synchronization provider, which combined file objects are duplicates and deleting one of the duplicates prior to enumerating the file objects.

24. The method of claim23 wherein determining, with the file synchronization provider, which combined file objects are duplicates, comprises:

performing a binary compare of the combined file objects.

Images