System and method for data synronization between remote devices

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 60/259,528, filed on Jan. 3, 2001, and entitled “READYSYNCGO”, which is incorporated by reference herein in its entirety.

FIELD OF THE INVENTION

[0002] The present invention relates to a method and system for updating files, and more particularly, relates to a method and system for efficiently synchronizing data on remote devices.

BACKGROUND OF THE INVENTION

[0003] In many business environments, a server is used to store data that is pertinent to many employees or remote users of a business. The server is typically accessible by remote computer devices (“clients”) to increase the availability of information to the remote users. By providing files on a server, which may be accessed by remote computer devices, dissemination of information through the company is increased. Remote access to data is more critical in environments where a sales force or many employees operate away from the office. As an example, the remote employees rely on the information to be up-to-date to be informed about inventory changes, pricing data, and company events. Rather than remain connected to the server indefinitely and collect telecommunication charges or tie up phone lines, the remote users only intermittently connect their computers to a server for access to data on the server. In these environments, the remote computer devices typically store the server data locally to support the remote application even when the client is not connected to the server. The intermittent connection is then used to send only changes made by the client application to the server and a pertinent set of changes from the server to the client. This type of remote computer system environment is called an Intermittently Connected (IC) environment. ICs have a wide variety of applications in sales force automation, insurance claim processing, and mobile work forces in general anywhere there are mobile users.

[0004] An important communication issue for this type of computer environment is the timely and efficient exchange of information between the clients and the server. The term “data transfer” is often used to describe the process of maintaining data consistency and integrity among server files and client files. There are many synchronization schemes for maintaining consistency. In some known file transfer schemes, various protocols and methods, for example compression to efficiently transfer files, are used.

[0005] Thus, heretofore an unaddressed need exists in the industry to address the aforementioned deficiencies in synchronization of data downloaded to a remote computer device quickly and efficiently.

SUMMARY OF THE INVENTION

[0006] The invention provides a system and method for efficiently synchronizing the data downloaded to remote devices. The invention may be conceptualized as a remote device data synchronization system includes a remote device with a device data, and a server device containing an original data and a revision data of the original data, and a delta data that identifies only the changes between the original data and the revision data.

[0007] The invention may also be conceptualized as a method for efficiently synchronizing the data downloaded to remote devices, the method comprising the steps of: (1) providing an original data; (2) creating update data of the original data; and (3) generating a delta data that identifies only the changes between the original data and the updated data; and (4) transmitting the delta data to a remote device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present invention, as defined in the claims, can be better understood with reference to the following drawings. The components within the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the present invention.

[0009]FIG. 1 is a block diagram illustrating an example of the network environment for a server computer system and the remote devices utilizing the remote device data synchronization system of the present invention.

[0010]FIG. 2 is a block diagram illustrating an example of a server utilizing the remote device data synchronization system of the present invention.

[0011]FIG. 3 is a block diagram illustrating an example of a remote device utilizing the remote device data synchronization system of the present invention.

[0012]FIG. 4 is a flow chart illustrating an example of the process flow of the remote device data synchronization system of the present invention, as shown in FIGS. <b>1</b>-<b>3</b>.

[0013]FIG. 5 is an example of flowchart illustrating the operation of the remote data synchronization system process, as shown in FIGS. <b>1</b>-<b>3</b>.

[0014]FIG. 6 is an example of the flowchart for the process to generate the appointment personalized information that is utilized in the remote device data synchronization system of the present invention, as shown in FIG. 5.

[0015]FIG. 7 is an example of the itinerary personalized information process operating with the remote device data synchronization system of the present invention, as shown in FIG. 5.

[0016]FIG. 8 is an example of the weather agent operating with the remote device data synchronization system of the present invention, as shown in FIG. 5.

[0017]FIG. 9 is an example of flowchart illustrating the itinerary agent operating with the remote device data synchronization system of the present invention, as shown in FIG. 5.

[0018]FIGS. 10A through 10C<b>10</b>A through <b>10</b>C are flowcharts illustrating the process to synchronize a contact from the remote device data synchronization server to a remote device as utilized in the remote device data synchronization system of the present invention, as shown in FIG. 2-<b>5</b>.

DETAILED DESCRIPTION OF THE INVENTION

[0019] The invention to be described hereafter is applicable to all data transfer systems using a remote device data synchronization system in the present invention to maintain current data on remote devices. While described below with respect to a single computer, the system and method for a remote device data synchronization system is typically implemented in a networked computing arrangement in which a number of computing devices communicate over a local area network (LAN), over a wide area network (WAN), or over a combination of both LAN and WAN.

[0020] The remote device data synchronization system of the present invention accomplishes two primary goals: (1) Keeps vital personal information synchronized between a user's personal computing devices; and (2) Delivers information to mobile users that is particularly relevant and personalized while mobile (generally, this is information associated with a particular time and/or place).

[0021] Mobile professionals will carry multiple mobile computing devices, all of which have specific usage and connection characteristics, making each device uniquely appropriate for certain mobile usage situations. Given this diversity of devices, an obvious user problem is the synchronization of information of these remote devices. The remote device data synchronization system of the present invention provides universal synchronization of a user's contacts, calendar, to do items and memos across remote devices. These types of information are synchronized to the best capability of the particular device. For example, the remote device data synchronization system of the present invention will support:

[0022] Office PC (Outlook, other personal information managers (PIMs), etc.)

[0023] Home PC (Outlook, +other PIMs, etc.)

[0024] Palm OS devices (native PIM apps, etc.)

[0025] Win CE OS devices (Pocket Outlook, etc.)

[0026] WAP-based phones (full PIM info, etc.)

[0027] Non-WAP phones (SMS support, etc.)

[0028] The remote device data synchronization system of the present invention also delivers relevant mobile information to user's devices. Three broad guidelines serve to illustrate the type of information delivered:

[0029] Information defined by particular appointments the user has;

[0030] Information defined by particular trips the user has;

[0031] General information that the user needs whenever, wherever they are.

[0032] Calendar-based information, working in conjunction with a user's contact database, drives the intelligent delivery of mobile information. Through wizard-type interfaces for creating appointment and trip entries, a user can specify certain relevant types of time/place information. Based on this information, the remote device data synchronization system of the present invention can assemble and monitor important relevant data from a variety of content providers and deliver it to the user's remote devices. For example, if a user is making a trip to Seattle, beginning a few weeks in advance of the trip, the user's remote device can be delivered information about the weather, flight information, directions, hotel information, car rental information, taxi, etc. After the trip, this Seattle-specific information can be removed from the devices. Likewise, based on appointments in the calendar, users can receive directions, company information, etc. useful in successfully conducting that appointment. All content is intelligently delivered to a user's different devices based on the device capacities and different user configuration settings. Information like stock ticker information and competitive company information can be configured to be synchronized to a user's mobile devices. Alert conditions can be set to monitor relevant items like flight status, stock price, appointment information, daily trip information, etc.

[0033] The remote device data synchronization system of the present invention can but is not limited to a tiered architecture (i.e. separate tiers for client, business logic services, and data storage), which provides scalability as well as multiple ways of synchronizing and interacting with the data in the central database. The application can reside on a single server, or on a cluster of servers for scalability and reliability.

[0034] Each device either browses the central data store directly, or synchronizes its local data store with the central data store via the remote device data synchronization system of the present invention.

[0035] Content is piped in from 3^rdparty vendors, stored in the central database and formatted by the remote device data synchronization system of the present invention. Content for a particular user is available directly, such as on a Web site, and is also synchronized to the user's devices during the same session as for personal information data, for offline viewing.

[0036] To provide the synchronization, software is installed on each synchronized remote device. This software serves to translate and map the superset personal information manager (PIM) format of the server database to the specific format of the specific PIM being synchronized. In addition, the client handles synchronization of content from the server and purging of outdated offline content from the device once it is no longer needed. The client/server communication during the synchronization session can be performed via HTTP to eliminate firewall issues. The remote device data synchronization system of the present invention may also support HTTPS (SSL), for users that synchronize via their ISP or other non-secure connection to the Internet.

[0037] The remote device data synchronization system of the present invention includes a repository, such as a central database <b>12</b>. This repository is can be scalable, such as but not limited to Microsoft SQL Server 7.0. All access to the repository can be performed via a set of data access APIs, which serve to decouple the remote device data synchronization system components and services from the database. This architecture enhances scalability and robustness by controlling and pooling database access, and gives the flexibility to port the repository to other RDBMS platforms without making modifications to core components or services.

[0038] The remote device data synchronization system manages user synchronization sessions, reconciling data changes between the device being synchronized and the repository. Each remote client device uses client software written for that device for synchronizing. The function of the client is to interface with the unique data format of the client device including, but not limited to Palm, OS, MS-Outlook, etc., and to communicate data changes with the remote device data synchronization system. This communication can be performed via HTTP or HTTPs (user selectable), so it is secure and does not impact firewall configuration. Because interfacing with device data formats is done without server intervention, addition of personal information managers PIM applications or devices is performed through the creation of a new client—with no changes to the server required.

[0039] The WAP and Web Services also connect to the central repository via the data access APIs, allowing users to work directly against the data stored in the central repository. Changes made to the data in the repository while a user is browsing will be queued and sent to all synchronized devices. The wireless application protocol (WAP) services work for users with WAP browsers in their wireless handsets. The remote device data synchronization system does not provide the WAP gateway; this is provided by the user's wireless carrier.

[0040] An alerting engine (Notification Services) monitors user calendar data, and when an alert condition is met, an alert is queued and sent to the user. Currently, the remote device data synchronization system provides alerts for appointments and flights, as well as summaries of each day's appointments and itinerary items. Alerts can be sent as email messages via an SMTP server, and are formatted as Short Message Service (SMS) messages. This enables remote device data synchronization system to send alerts to email-addressable wireless phones and pagers, in addition to standard email clients.

[0041] The remote device data synchronization system of the present invention also provides automatic updating of client software, if a new version is available at the time a user synchronizes. The server sends down the new software and installs it on client devices as part of the synchronization process; there is no intervention required by the user or by the administrator.

[0042] The remote device data synchronization system can employ an n-tier architecture, in which the Data tier (database), Business Logic tier, and Web Server tier to be independently scalable via clustering and load balancing. This allows hardware to be added to only the tiers where it is needed for a given configuration. In addition, it allows for a fairly easy scalability path, as hardware can be added at any time, based on empirical measurements of which tiers appear to be bottlenecking.

[0043] Referring now to the drawings, in which like numerals illustrate like elements throughout the several views, FIG. 1 illustrates the basic components of a system <b>10</b> using the remote device data synchronization system used in connection with the preferred embodiment of the present invention. The system <b>10</b> includes remote client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b>. Each client has applications and can have a local file <b>16</b>. Computer servers <b>11</b> and <b>21</b> contain applications and server <b>11</b> further contains a server database <b>12</b> that is accessed by client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> via intermittent connections <b>14</b>(<i>a</i>-<i>d</i>), respectively, over network <b>13</b>. The server <b>11</b> runs administrative software for a computer network and controls access to part or all of the network and its devices. The client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> share the server data stored on the database <b>12</b> and may access the server <b>11</b> over a network <b>13</b>, such as but not limited to: the Internet, a local area network (LAN), a wide area network (WAN), via a telephone line using a modem or other like networks. The server <b>11</b> may also be connected to the local area network (LAN) within an organization.

[0044] The structure and operation of the remote device data synchronization system <b>10</b> enables the server <b>11</b> and the database <b>12</b> associated therewith to handle clients more efficiently than previously known systems. Particularly, the remote device data synchronization system of the present invention provides a manner of organizing data of the server file into updates that enable a remote client system to update its remote file more efficiently. Periodically, a modification (“delta” or “update”) file is created for each client with all relevant changes since the last modification file creation. When the clients systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> connect to the server <b>11</b>, the modification files associated with the client are transmitted to the client to be used for updating each client's individual files.

[0045] The client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> may each be located at remote sites. Client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> include but are not limited to, PCs, workstations, laptops, PDAs, pagers, WAP devices, non-WAP devices, cell phones, palm devices and the like. Thus, when a user at one of the remote client systems <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> desires to be updated with the current information from the shared file at the server <b>11</b>, the client system <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> communicates over the network <b>13</b>, such as but not limited to WAN, internet, or telephone lines to access the server <b>11</b>. Advantageously, the present invention provides a system and method for updating client systems to most efficiently transfer their remote files on the server <b>11</b>. Periodically, the server determines the data that has changed for each client since the last evaluation, and records those changes in a modification file. When a client connects to the server, it requests the modification files for the client, creates the downloaded modification files, and updates its local file.

[0046] Third party vendors computer systems <b>21</b> and databases <b>22</b> can be accessed by the remote device data synchronization system server <b>11</b> in order to obtain updated information for dissemination to the remote devices. Data that is obtained from third party vendors computer system <b>22</b> and database <b>23</b> can be stored on the remote device data synchronization system server <b>11</b> in order to provide later access to the user remote devices <b>15</b>, <b>17</b>, <b>18</b> and <b>21</b>. It is also contemplated that for certain types of data that the remote user devices <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> can access the third party vendors data directly using the network <b>13</b>.

[0047] Generally, in terms of hardware architecture, as shown in FIG. 2, the computer and devices <b>11</b>, <b>21</b> and <b>23</b> include a processor <b>41</b>, storage <b>42</b> memory <b>42</b>, and one or more input and/or output (I/O) devices (or peripherals) that are communicatively coupled via a local interface <b>43</b>. The local interface <b>43</b> can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface <b>43</b> may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface <b>43</b> may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

[0048] The processor <b>41</b> is a hardware device for executing software that can be stored in memory <b>42</b>. The processor <b>41</b> can be virtually any custom made or commercially available processor, a central processing unit (CPU) or an auxiliary processor among several processors associated with the computer <b>11</b> and <b>21</b>, and a semiconductor based microprocessor (in the form of a microchip) or a macroprocessor. Examples of suitable commercially available microprocessors are as follows: an 80×86 or Pentium series microprocessor from Intel Corporation, U.S.A., a PowerPC microprocessor from IBM, U.S.A., a Sparc microprocessor from Sun Microsystems, Inc, a PA-RISC series microprocessor from Hewlett-Packard Company, U.S.A., or a 68xxx series microprocessor from Motorola Corporation, U.S.A.

[0049] The memory <b>42</b> can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.)) and nonvolatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory <b>42</b> may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory <b>42</b> can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor <b>41</b>.

[0050] The software in memory <b>42</b> may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 2, the software in the memory <b>42</b> includes a suitable operating system (O/S) <b>51</b> and the remote device data synchronization system <b>100</b> of the present invention.

[0051] A non-exhaustive list of examples of suitable commercially available operating systems <b>51</b> is as follows: a Windows operating system from Microsoft Corporation, U.S.A., a Netware operating system available from Novell, Inc., U.S.A., an operating system available from IBM, Inc., U.S.A., any LINUX operating system available from many vendors or a UNIX operating system, which is available for purchase from many vendors, such as Hewlett-Packard Company, U.S.A., Sun Microsystems, Inc. and AT&amp;T Corporation, U.S.A. The operating system <b>51</b> essentially controls the execution of other computer programs, such as the remote device data synchronization system <b>100</b>, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. However, it is contemplated by the inventors that the remote device data synchronization system <b>100</b> of the present invention is applicable on all other commercially available operating systems.

[0052] The remote device data synchronization system <b>100</b> may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory <b>42</b>, so as to operate properly in connection with the O/S <b>51</b>. Furthermore, the remote device data synchronization system <b>100</b> can be written as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedure programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, Pascal, BASIC, FORTRAN, COBOL, Perl, Java, and Ada.

[0053] The I/O devices may include input devices, for example but not limited to, a keyboard <b>45</b>, mouse <b>44</b>, scanner (not shown), microphone (not shown), etc. Furthermore, the I/O devices may also include output devices, for example but not limited to, a printer (not shown), display <b>46</b>, etc. Finally, the I/O devices may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator/demodulator <b>47</b> (for accessing other files, devices, systems, or a network), a radio frequency (RF) or other transceiver (not shown), a telephonic interface (not shown), a bridge (not shown), a router (not shown), etc.

[0054] If the computers <b>11</b> and <b>21</b> are a PC, workstation, intelligent device or the like, the software in the memory <b>42</b> may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of essential software routines that initialize and test hardware at startup, start the O/S <b>52</b>, and support the transfer of data among the hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when the computer <b>11</b>, <b>15</b>, <b>16</b>, <b>18</b><b>21</b> and <b>23</b> is activated.

[0055] When the computers <b>11</b>, <b>15</b>, <b>16</b>, <b>18</b><b>21</b> and <b>23</b> is in operation, the processor <b>41</b> is configured to execute software stored within the memory <b>42</b>, to communicate data to and from the memory <b>42</b>, and to generally control operations of the computer <b>11</b>, <b>15</b>, <b>16</b>, <b>18</b><b>21</b> and <b>23</b> pursuant to the software. The remote device data synchronization system <b>100</b> and the O/S <b>52</b> are read, in whole or in part, by the processor <b>41</b>, perhaps buffered within the processor <b>41</b>, and then executed.

[0056] When the remote device data synchronization system <b>100</b> is implemented in software, as is shown in FIG. 3A and 3B, it should be noted that the remote device data synchronization system <b>100</b> can be stored on virtually any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. The remote device data synchronization system <b>100</b> can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

[0057] In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

[0058] In an alternative embodiment, where the remote device data synchronization system <b>100</b> is implemented in hardware, the remote device data synchronization system <b>100</b> can be implemented with any one or a combination of the following technologies, which are each well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

[0059] Illustrated in FIG. 3B is an example of a remote device utilizing the remote device data synchronization system <b>100</b> of the present invention. Remote devices <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> include, but are not limited to, PCs, workstations, laptops, PDAs, pagers, WAP devices, non-WAP devices, cell phones, palm devices and the like. The components of the remote device <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> are substantially similar to that of the description for the server <b>11</b> (FIG. 2). However, it is contemplated that many of the components in the user's remote device <b>15</b>, <b>17</b>, <b>18</b> and <b>23</b> can be more limited.

[0060] Illustrated in FIG. 4 is an example of a flowchart of the process flow that a user performs in interaction with the remote device and synchronization system <b>100</b> of the present invention on server <b>11</b>. First at step <b>81</b>, user navigates to a page containing personalized information. This page of information can be accessed using any known network including, but not limited to, a web page.

[0061] At step <b>82</b>, the user utilizes the web browser to request a page from the remote device synchronization server <b>100</b> of the present invention. At step <b>83</b>, the remote device due to synchronization server <b>100</b> computes and formats the requested personalized information. The flow diagram for computing and formatting the personalized information is herein defined in further detail with regard to FIGS. 6 and 7.

[0062] At step <b>84</b>, the formatted personalized information requested at step <b>82</b> is returned to the web browser utilized by the user at step <b>84</b>. At step <b>85</b>, the process determines if the user has more personalized information to be requested from the server. If this determines that step <b>85</b> that there is no more information to be requested at the user, then the process then exits at step <b>89</b>. However, if it is determined at step <b>85</b> that the user is not done, then the process returns to repeat steps <b>82</b> through <b>85</b>.

[0063] Illustrated in FIG. 5 is an example of flowchart illustrating the operation of the remote data synchronization system process <b>100</b>. First, the remote device data synchronization <b>100</b> is initialized at step <b>101</b>.

[0064] At step <b>102</b>, the remote device data synchronization system <b>100</b> accepts input from the user when the user strikes the synchronization button on the user's remote device. At step <b>103</b>, the remote device data synchronization system <b>100</b> of the present invention requests personalized information changes from the central server <b>11</b>.

[0065] At step <b>104</b>, the remote device data synchronization server <b>11</b> computes and formats personalized information for the device type for present and upcoming appointment and itinerary information. The appointment and itinerary information is herein defined in further detail with regard to FIGS. 6 and 7. At step <b>105</b>, the server then computes the differences between the new personalized information and the information that is currently residing on the remote user device.

[0066] At step <b>106</b>, the differences are returned to the client to the remote user device for updating the data on the user's remote device. The remote device data synchronization system <b>100</b> of the present invention residing on the remote device, then apply the differences and updates the personalized appointment and itinerary information as requested in step <b>107</b>. The process then exits at step <b>109</b>.

[0067] Illustrated in FIG. 6 is an example of the flowchart for the process to generate the appointment personalized information that is utilized in the remote device data synchronization system <b>100</b> of the present invention.

[0068] At step <b>121</b>, the server <b>11</b> receives a request for appointment personalized information. At step <b>122</b>, remote device data synchronization server <b>11</b> then calculates the user location prior to the prior appointment based upon either appointments or itineraries within their calendar at step <b>122</b>.

[0069] At step <b>123</b>, the synchronization server <b>11</b> then retrieves the directions for the appointments from a map contents service provider. The map service provider can be for example but is not limited to MapQuest. At step <b>124</b>, the personalized appointment information is formatted for the appropriate remote device type. The appointment personalized information process <b>120</b> then exits at step <b>129</b>.

[0070] Illustrated in FIG. 7 is an example of the itinerary personalized information process <b>140</b>. First, the personalized itinerary information process <b>140</b> receives a request for itinerary personalized information at step <b>141</b>.

[0071] At step <b>142</b>, the personalized itinerary information process <b>140</b> then determines the user's location prior to that segment based upon other appointments and itineraries in the user's component accessories. These component accessories include, but are not limited to, a calendar, scheduler, Outlook, Email or other email based system. At step <b>143</b>, the personalized itinerary information process <b>140</b> then retrieves directions for each of the locations determined at step <b>142</b>. The directions may be obtained from any type map service including, but not limited to, MapQuest. At step <b>144</b>, the personalized itinerary information process <b>140</b> then retrieves the weather for each city included in the itinerary. This weather data can be obtained from either the synchronization server <b>11</b> or centralized database <b>12</b> or may be directly requested from a third party vendor <b>23</b>. Third party vendors include, but are not limited to, Accuweather, Map Quest, the National Weather Service, Weather.com, The Weather Channel, Intellicast, or other like services. At step <b>145</b>, the personalized itinerary information process <b>140</b> then formats the itinerary personalized data in the appropriate format for the user's remote device <b>15</b>, <b>17</b>, <b>18</b> or <b>23</b>. Next, the personalized itinerary information process exits at step <b>149</b>.

[0072] Illustrated in FIG. 8 is an example of the weather agent <b>160</b> utilized by the remote device synchronization system <b>100</b> of the present invention. First, the weather agent is initialized at step <b>161</b>. At step <b>162</b>, the weather agent determines whether it is time for the weather update to occur. This weather update can be a scheduled process or may be on any predetermined time schedule as set by the user and/or the server system administrator. If it is determined at step <b>162</b> that it is not yet time for the update, the weather agent then checks whether is time to update the weather conditions for the cities selected in user itineraries. If it is determined in step <b>161</b> that it is not time to update the weather itinerary, then the weather agent <b>162</b> returns then waits for an appropriate time. Wait time period is executed at step <b>162</b>. The weather agent then returns to step <b>162</b> to check whether it is time for the weather update to occur.

[0073] However, if it is determined at step <b>162</b> it is time for a weather update to occur, the weather agent then retrieves the weather text files containing the weather data for the thousands of cities worldwide currently being utilized. For example, the weather agent can retrieve text files for worldwide major cities or in an alternative embodiment can scan the itinerary data on database <b>12</b> (FIG. 1) to determine which cities currently are in need of updated weather information. After retrieving the weather text at step <b>164</b>, the weather agent <b>160</b> then parses the weather data files in step <b>165</b> and updates the weather data in the database <b>12</b> (FIG. 1) or later availability to remote users at step <b>166</b>. The weather agent then returns to step <b>162</b> to check it is time for the next weather update to occur.

[0074] Illustrated in FIG. 9 is an example of flowchart illustrating the itinerary agent <b>180</b> utilized in the remote device data synchronization system <b>100</b> of the present invention. First, the itinerary agent <b>180</b> is initialized at step <b>181</b>. At step <b>182</b>, the itinerary agent <b>180</b> checks to see if it's time to update the itinerary processes at step <b>182</b>. If it is determined in step <b>182</b> that it is not time to update the itineraries, the itinerary agent <b>180</b> then waits a pre-determined period at step <b>183</b> before returning to step <b>182</b> to check if it's time to update the itineraries.

[0075] If it is determined in step <b>182</b> that it is time to perform the update of the itineraries then the itinerary agent <b>180</b> receives an itinerary in XML format at step <b>184</b>. At step <b>185</b>, the itinerary agent <b>180</b> processes the itinerary and converts the information into the itinerary agents internal itinerary format.

[0076] In step <b>186</b>, the itinerary agent then updates the itinerary in the remote user's calendar within the remote device data synchronization system database <b>12</b> (FIG. 1) for later access by the user. The itinerary agent then returns to repeat steps <b>182</b> through <b>186</b>.

[0077] Illustrated in FIGS. 10A through 10C are flowcharts illustrating the process to synchronize a contact from the remote device data synchronization server to a remote device as utilized in the remote device data synchronization system <b>100</b> of the present invention.

[0078] First in step <b>201</b>, the remote device data synchronization server <b>11</b> synchronizes a contact to a user remote device address book. In step <b>202</b>, the remote device data synchronization server <b>11</b> then inspects the contact with a total number of phone field types at step <b>203</b>

[0079] At step <b>204</b>, the synchronization server <b>11</b> then determines if there are more than 5 phone field types. It is determined in step <b>204</b> that there are not more than 5 phone field types then the synchronization contact process <b>200</b> then performs the minimized synchronization process to <b>200</b> hereindefined in further detail with regard to FIG. 11B. After performing the minimized contact synchronization process <b>220</b>, the contact synchronization process <b>200</b> then exits at step <b>209</b>.

[0080] However, if it's determined at step <b>204</b> that there are more than 5 phone field types, then the contact process <b>200</b> performs the maximum contact synchronization process <b>240</b> that is hereindefined in further detail with regard to FIG. 11C. After performing the maximum contact synchronization process <b>240</b>, the contact synchronization process <b>200</b> then exits to step <b>209</b>.

[0081] Illustrated in figure 10B is the minimal contact synchronization process <b>220</b>. First, the minimal contact synchronization process <b>220</b> acquires a slot for each field type in step <b>221</b>.

[0082] In step <b>222</b>, the minimized contact synchronization process <b>220</b> then assigns for each field type the phone field to the appropriate field type. At step <b>223</b>, the minimized contact synchronization process <b>220</b> then determines if there are additional phone fields for the current field type. If it is determined in step <b>223</b> that there are additional phone fields for the current field type, then the minimized contact synchronization process <b>200</b> then appends a carriage return to the current field type and at step <b>223</b> and the next phone field of the same type at step <b>225</b>. After getting the next phone field of the same type at step <b>225</b>, the minimized contact synchronization process <b>220</b> then returns to step <b>222</b> to assign the next phone field to the appropriate field type.

[0083] However, if it is determined that step <b>223</b> that there are no more additional phone fields for the current field type then the minimized contact synchronization process <b>220</b> then determines if there are any other field types remaining at step <b>226</b>. It is determined that step <b>226</b> that there are other field types remaining then the minimized contact synchronization process <b>220</b> then returns to repeat steps <b>222</b> through <b>226</b>. However, if it's determined that step <b>226</b> that there are no other field types remaining then the minimized contact synchronization process <b>220</b> then exits at step <b>229</b>.

[0084] Illustrated in FIG. 10C, it is an example of the maximized contact synchronization process <b>240</b>. First, the maximized contact synchronization process assigns the first 4 slots with their own field type at step <b>241</b>. At step <b>242</b>, the maximized contact synchronization process <b>240</b> then assigns the phone field to the appropriate field type.

[0085] At step <b>243</b>, the maximized contact synchronization process <b>240</b> then determines if there are additional phone fields for the current field type. If it is determined that step <b>243</b> that there are additional phone fields for the current field type, then the maximized contact synchronization process <b>240</b> then perform step <b>244</b> to append the carriage return delimiter to the current field type and gets the next phone field of the same type. After appending the carriage return delimiter and getting the next phone field of the same type at step <b>244</b> the maximized contact synchronization process <b>240</b> then returns to repeat step <b>242</b>.

[0086] However, at step <b>243</b> that there are no additional phone fields for the current field type then the maximized contact synchronization process <b>240</b> then determines if there are other field types remaining at step <b>245</b>. If it is determined at step <b>245</b> that there are other field types remaining, then the maximized contact synchronization process <b>240</b> then determines if the remaining field type is the 5^thfield type at step <b>246</b>. If it is determined that step <b>246</b> that the next field type is not the 5^thfield type, then the maximized contact synchronization process <b>240</b> then returns to repeat step <b>242</b>. However, if it is determined that step <b>246</b> that the next field type is the 5^thfield type, then the maximized contact synchronization process <b>240</b> assign the 5^thslot as other at step <b>251</b>.

[0087] At step <b>252</b>, the label tag based upon the field type of the current slot. At step <b>253</b>, the maximized contact synchronization process <b>240</b> assigns the phone field to the “other” slot and determines that step <b>254</b> if there are other remaining phone fields to be processed. If it is determined that step <b>254</b> that there are other phone fields remaining, then the maximized contact synchronization process <b>240</b> then appends a carriage return delimiter and gets the next phone field at step <b>255</b>. The maximized contact synchronization process <b>240</b> then returns to repeat steps <b>252</b> through <b>254</b>.

[0088] However, if it is determined that step <b>254</b> that there are no other field types remaining, then the maximized contact synchronization process <b>240</b> then exits at step <b>259</b>.

[0089] It will be apparent to those skilled in the art that many modifications and variations may be made to embodiments of the present invention, as set forth above, without departing substantially from the principles of the present invention. All such modifications and variations are intended to be included herein within the scope of the present invention, as defined in the claims that follow.