Mobile data distribution

[0001] 1. Field of the Invention

[0002] The present invention relates generally to the field of data distribution, and more particularly to a system and method for synchronizing data to mobile devices.

[0003] 2. Description of the Prior Art

[0004] In networked computer systems data is commonly stored in a central location such as a collection of disk drives connected to a network server. In networked computer systems such as those commonly found in business offices, a network server includes a primary data storage system for the network, and the networked computers access files and other data from the network server to cache locally. Increasingly, mobile devices such as laptop computers, handheld computers, and Personal Digital Assistants (PDAs) are being linked to networked computer systems. Typically, a mobile device is only connected to a network server for a short periods of time. During these times it is usually desirable to synchronize data between the network server and the mobile device.

[0005] Perhaps the simplest implementation of a method for synchronizing data between a network server and a mobile device is to replicate to the mobile device all of the data stored on the network server. While this method is simple to implement, it is generally impractical. A significant problem is that most network servers store a quantity of data that exceeds the storage capacity of the mobile device. Accordingly, any practical method for synchronizing data between a network server and a mobile device must limit the quantity of data that will be synchronized.

[0006] Ideally, a method for synchronizing data between a network server and a mobile device will limit the quantity of synchronized data to only that which is necessary for the operation of the mobile device. Limiting the quantity of synchronized data serves at least two important goals. First, it lessens the length of time necessary to perform a synchronization. Second, it allows the mobile device to devote less memory capacity to data storage, which makes more capacity available to be used by software applications. Since insufficient free memory will typically cause applications on a mobile device to execute slowly, limiting the quantity of synchronized data will tend to improve the operation of software applications running on the mobile device.

[0007] Accordingly, what is needed is an efficient way to identify an appropriate subset of the data on a network server during a synchronization.

[0008] The present invention provides a method for selectively replicating data from a network server to a mobile device during a synchronization. The method associates roles to mobile device users, where a role contains a collection of rules for data distribution. All users assigned the same role will receive data during a synchronization according to the rules specified by that role. A user having more than one role will receive data during a synchronization according to each of the roles.

[0009] Each role includes at least one rule, but not every rule of the role is necessarily followed during a synchronization. In some embodiments rules can be enabled or disabled depending on a device type of the receiving mobile device. Enabling rules for some device types but not for others can be advantageous to tailor the quantity of replicated data to the memory capacity of the mobile device. Fewer rules can be enabled for mobile devices with more restricted memory capacities.

[0010] In some embodiments rules can also be excluded where a user lacks the proper authorization. For example, a permission list can be used to indicate whether the user is authorized to access certain types of data. If the user is not authorized to access a type of data, any rule that selects data of that data type will also be excluded from the synchronization, even though a role associated with the user may allow the rule. In some embodiments, each rule is associated with a data type by a component interface. In these embodiments the permission list can indicate user authorizations according to each component interface.

[0011] Each rule includes at least one condition. When a rule is applied to data, only the data that satisfies the conditions of the rule is replicated to the mobile device. Conditions can be either static or dynamic. A static condition stays the same while a dynamic condition will depend on some factor, such as the identity of the user or the device type of the mobile device. Dynamic conditions allow, for example, two users with the same type of mobile device and the same user authorizations to synchronize different data by applying the same rules. In this way a synchronization can be tailored to an individual, the mobile device the individual is using, and the individual's particular circumstances.

[0012] FIG. 1 is a schematic diagram of a system including a network server in communication with a mobile device across a network;

[0013] FIG. 2 is a chart depicting meta-data relationships between a user profile, a role, a rule, and a condition according to an embodiment of the invention;

[0014] FIG. 3 is a chart depicting further meta-data relationships between a user profile, a role, and a permission list according to an embodiment of the invention;

[0015] FIG. 4 is a flow chart of a method of the invention according to one embodiment thereof; and

[0016] FIG. 5 is a flow chart of a method of applying a condition according to one embodiment of the invention.

[0017] The present invention provides a method for selectively replicating data to a mobile device during a synchronization. The method employs a set of data distribution rules that are associated with a user of the mobile device. Each of the rules includes one or more conditions. Only the specific instances of data that satisfy the conditions are transferred to the mobile device. The data distribution rules can be made dependent on a device type of the mobile device so that, for example, data that would be replicated to a laptop computer would not be replicated to a PDA. Further, the invention can exclude an entire set of data from replication where the user lacks the authorization to access the set, even though the rules would otherwise permit the data to be synchronized.

[0018] To better set forth the invention, aspects of the supporting hardware will first be described in greater detail. FIG. 1 illustrates a system 100 including a network server 102 that can communicate with a mobile device 104 across a network 106. Network 106 may be, for example, a public switch telephone network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a public network such as the Internet, a broadband network, a wireless network, or a combination of any of these. In FIG. 1 a solid line is used to represent the communications link between the network server 102 and the network 106 to indicate that the link is continuously maintained. A dashed line is used to represent the communications link between the mobile device 104 and the network 106 to indicate that the link may be temporary.

[0019] The network server 102 includes an access server 108, that in some embodiments is a web server. The access server 108 maintains the connection to the network 106 and can also communicate with one or more application servers 110. More specifically, access server 108 includes a sync gateway servlet (not shown) that is configured to communicate with a sync server 112 of each application server 110 and to specify an address, such as a URL, to the network 106 so that the access server 108 can be located and accessed by the mobile device 104.

[0020] Each application server 110 may be a separate server, or may be a partition of a larger server such as an enterprise server, or may be distributed across several servers. Each application server 110 stores data in a component store 114, that may be, for example, a dedicated storage device within the application server 110, a storage device shared by several application servers 110, a network attached storage device (NAS), a storage area network (SAN) connected to the application server 110, or a database maintained on any of these devices.

[0021] Data is stored in the component store 114 as components 116, where a component 116 is a collection of records and application processing logic. Each component 116 is of a particular component type, for example, any component 116 that represents a particular set of records about a customer (e.g., name, location, type of business, and number of employees) is a component 116 of the “customer” component type. Each component is associated according to its component type with one or more component interfaces 118.

[0022] A component interface 118 serves several functions. One function is to expose components 116 to the access server 108 during a synchronization. In this capacity the component interface 118 specifies which records are replicated to the mobile device 104. For example, the component interface 118 can be configured such that if the mobile device 104 is a PDA fewer records of the component 116 are replicated, whereas if the mobile device 104 is a laptop computer all records are replicated. Another function of the component interface 118 is to aggregate rules that can be applied to components 116 of the associated component type. The use of rules to select components 116 from the component store 114 will be described in more detail below with respect to FIG. 2.

[0023] Mobile device 104 may be any type of remote electronic device, for example, a personal computer, a laptop computer, or a handheld device such as a personal digital assistant (PDA), a mobile telephone, or a text messaging device. Mobile device 104 includes software, such as web browser 120, for displaying information to the user of the mobile device 104 and to provide a user interface. Information displayed to the user can include data stored as objects in object store 122. A mobile agent 124 facilitates the synchronization of the objects in object store 122 with the data stored in component store 114. The interaction of the mobile agent 124 and the sync server 112 during a synchronization are described in more detail in U.S. patent application Ser. No. 10/133,124 “Simplified Application Object Data Synchronization for Optimized Data Storage,” and U.S. patent application Ser. No. 10/133,164 “System and Method for Synchronization of Version Annotated Objects,” both applications filed on Apr. 25, 2002, and both incorporated by reference herein. It should be noted that the term “component” is used to refer to data in the component store 114 while the term “object” is used to refer to data in the object store 122 to denote that components are typically stored in a relational format while objects are typically stored in an object-like format. The invention, however, is independent of the format of the respective stores 114 and 122.

[0024] FIG. 2 is a chart depicting meta-data relationships of the invention. The network server 102 stores in the component store 114 a user profile 200 for each user. Each user profile 200 includes information specific to the user, such as a password. Additionally, each user profile 200 can include roles 202 that define which component types the user will have access to during a synchronization. In some embodiments a user can be excluded from including any roles 202, but in most instances each user will include one or more roles 202, as shown in FIG. 2 for two different user profiles 200. As also shown, more than one user can be associated with the same role 202.

[0025] Each role 202 typically includes one or more rules 204, though the invention can be implemented so that a role 202 includes no rules 204. Each rule 204 associates together a component interface 118 with one or more conditions 206. The conditions 206 can be grouped together, for example, with a rule definition 208. During a synchronization, each condition 206 places a restriction on which components 116 of the particular component type associated with the component interface 118 can be replicated to the mobile device 104. For example, for the rule 204 “My Leads,” the component interface 118 is “Lead” and one of the conditions 206 is “Country=USA.” Here, the “Lead” component interface 118 is associated with components 116 of the “lead” component type. Components 116 of the “lead” component type each include a field for “Country.” During a synchronization, the condition 206 “Country=USA” limits the components 116 that may be replicated to the mobile device 104 to only those for which the “Country” field is USA. When a rule 204 is invoked that includes more than one condition 206, only those components 116 with fields that satisfy all of the conditions 206 may be replicated to the mobile device 104.

[0026] In some embodiments each rule 204 can be selectively invoked depending on the device type of the mobile device 104. For example, a rule 204 may be invoked when the device type is a PDA, while not invoked if the device type is a mobile phone. This allows, for example, the ability to tailor the amount of data that is replicated to a mobile device 104 according to its memory capacity. In some embodiments, a rule definition 208 can be associated with a flag for each recognized device type for mobile device 104, and in some embodiments the association is made by a role 202. The flag, shown in FIG. 2 as “Y” or “N,” indicates whether the device type is authorized to receive data according to the rule 204. A rule 204 can be associated in this way with any number of device types.

[0027] A condition 206 can be either static or dynamic. A static condition 206 is one that does not change. A dynamic condition depends on some factor, such as the identity of the user, the device type of the mobile device, the day of the week that the synchronization is requested, and so forth. For example, in FIG. 2 the condition “Country=USA” is static because it will limit the components 116 of the component type “lead” to those for which the “Country” field is “USA” regardless of the identity of the user, for instance. On the other hand, the condition “User ID=% User ID” is a dynamic condition because it specifies that the only components 116 that are eligible to be replicated are those for which the field “User ID” matches the specific User ID of the user of the mobile device 104. Here, the factor that the dynamic condition “User ID=% User ID” depends upon is the identity of the user. The use of dynamic conditions 206 in rules 204 allows the data that is replicated to a mobile device 104 to be appropriate to an individual user, the user's specific mobile device type, and the user's circumstances.

[0028] FIG. 3 is a chart depicting additional meta-data relationships of the invention that provide a user authorization feature that can be included with the meta-data relationships shown in FIG. 2. The authorization feature associates a user's identity with an authorization to access the various component types. As shown in FIG. 3, in some embodiments a permission list 300 associates a User ID for a user with authorizations to access component types. In the example in FIG. 3, a flag that can be set to either “Y” or “N” is used to indicate whether the user is authorized to receive components 116 of the component type associated with the particular component interface 118. In the example of FIG. 3, the User Profile 200 for Bob Marks includes the Mobile Sales Rep role 202 and is therefore allowed components 116 associated with the “lead” component interface 118 that satisfy both of the rules 204 “My Leads” and “My Leads as Team Member.” However, since permission list 300 does not give Bob Marks authorization to access the component interface 118 for “Lead,” Bob Marks will not be able to synchronize components 116 according to the rules 204 “My Leads” and “My Leads as Team Member.”

[0029] FIG. 4 shows a flow chart 400 of the method of the invention. In some embodiments the steps of flow chart 400 are performed by a sync server 112. In a first step 402 a mobile device 104 is coupled to a network server 102. This step can be performed, for example, by establishing a temporary connection through a network 106 such as the Internet. The necessary duration of this temporary connection can be minimized by limiting the number of components 116 that are replicated during a synchronization according to the method of the invention. Step 402 can include transmitting identifying indicia from the mobile device 104 to the network server 102. The identifying indicia can include a User ID and a password to gain access to the access server 108, for example. The identifying indicia can also include the device type of the mobile device 104. Step 402 can also include establishing a connection between the access server 108 and a particular application server 110. Establishing a connection between the access server 108 and a particular application server 110 can also include establishing a connection to a sync server 112 of the application server 110.

[0030] Once the mobile device 104 is coupled to the network server 102, step 404 provides for selecting a role 202 for the user. A user's User ID can be associated with one or more roles 202, for example, by a user profile 200. According to the method of the invention, a first role 202 is selected and any associated rules 204 are executed. After all of the associated rules 204 have been executed, any additional roles 202 are handled in the same manner. In some embodiments a role 202 is selected by a simple schema such as by the order of listing in the user profile 200, or by a more sophisticated method such as by the order of the number of associated rules 204.

[0031] Once a role 202 has been selected, in step 406 a rule 204 is selected from that role 202. The same schema for selecting a role 202 can also be applied to selecting a rule 204. In some embodiments step 406 includes identifying a device type of the mobile device 104. In some of these embodiments step 406 further includes determining that the device type is authorized to receive data according to the rule 204. For example, meta-data, such as role 202, can associate the device type with the rule 204. In the example shown in FIG. 2, a flag indicates whether the device type is authorized with either a “Y” or a “N.” Accordingly, in step 406 a rule 204 that is not authorized for the particular mobile device 104 can be excluded from the synchronization. It may be desirable to exclude a rule 204 during a synchronization to further limit the amount of data that is replicated where the mobile device 104 has a limited storage capacity.

[0032] Step 406 can also include determining whether a user is authorized to receive data associated with the particular component interface 118 that is identified to the rule 204. A table, such as permission list 300 in FIG. 3, can be used to associate the authorization for the component interface 118 with the user. In those embodiments that include a permission list 300, a rule 204 is only executed in step 406 if the user is authorized to receive data associated with the particular component interface 118. Thus, in step 406 a rule 204 of a role 202 associated with a user may be excluded because the user lacks the authorization to receive data associated with the component interface 118 for the rule 204.

[0033] In some embodiments a user can manually select rules 204 during step 406. In some of these embodiments the user is able to access a screen through the web browser 120 on the mobile device 104 that allows the user to change the authorizations for rules 204 that are associated with different device types. In this way a user, working through the mobile device 104, can reconfigure at each synchronization which rules 204 are invoked for each of the user's roles 202. It will be appreciated that although the manual selection of rules 204 has been described within the context of step 406, this process can also be performed at any time before or after a synchronization. For example, the manual selection of rules 204 can be performed after the mobile device 104 is coupled to the network server 102 in step 402 but before a role 202 is selected in step 404. Alternatively, the user can manually select rules 204 after the synchronization is complete so that the new selections are followed the next time a synchronization is performed.

[0034] In step 408 a condition 206 associated with the rule 204 is applied to identify a component 116. In some embodiments this is accomplished by examining each component 116 associated with the component interface 118 to identify those components 116 that satisfy the condition 206. Where more than one condition 206 is associated with a rule 204, the components 116 identified by applying the first condition 206 can be further filtered by the subsequent conditions 206 until only those components 116 that satisfy all of the conditions 206 remain. For each component 116 that satisfies the conditions 206 of a rule 204, a unique identifier, such as a sync ID, can be written to a synchronization list.

[0035] FIG. 5 is a flow-chart that illustrates how step 408 is performed in some embodiments. In these embodiments a condition 206 is selected from a rule 204 in a step 502. In a step 504, the condition is written to a request string, for example, through the use of Standard Query Language (SQL). In a step 506 a component store 114 is searched with the request string to identify only those components 116 that satisfy the condition 206. In a step 508, a unique identifier, such as a Sync ID, is written to a synchronization list for each identified component 116. Where more than one condition 206 is associated with the rule 204, each condition 206 can be added to the request string in step 504. In this way, only those components 116 that satisfy the conditions 206 that were written to the request string will be identified in step 506. As components 116 are identified, a sync ID for each is written to a synchronization list in step 508.

[0036] In some further embodiments steps 502 and 504 are repeated until all of the conditions 206 associated with all of the rules 204 associated with all of the roles 202 involved in the synchronization have been added to the request string. Then, in step 506 the component store 114 is searched only once by the request string that includes all of the conditions 206 to produce a complete synchronization list. In some of these embodiments, the user can view a summary of the synchronization list that can show, for example, how many components 116 of each component type were identified. In further embodiments the user can change an authorization between a rule 204 and the device type of the mobile device 104 and have the system derive a new synchronization list and display a new summary. By this iterative process a user can customize a synchronization before data is replicated.

[0037] Returning to FIG. 4, in step 410 data satisfying the condition 206 is synchronized to the mobile device 104. In those embodiments in which sync IDs are written to a synchronization list, in step 410 the components 116 corresponding to the sync IDs on the synchronization list are sequentially replicated to the mobile device 104. In some embodiments step 410 includes using the component interface 118 associated with the component 116 to define an object to be sent to the mobile device 104. Step 410 can also include serializing the data to flatten any hierarchical data structure and to format the flattened data for communication across the network 106. Formatting the flattened data can include, for example, the use of a mark-up language such as Hyper-Text Markup Language (HTML) or Extensible Markup Language (XML).

[0038] The invention also includes a computer-readable medium comprising program instructions for synchronizing data from a network server 102 to a mobile device 104. The computer-readable medium can be, for example, a floppy diskette or a CD-ROM. The program instructions contained on the computer-readable medium include computer code for performing the method of the invention described above. By installing the program instructions on a suitable network server 102, the network server 102 can be enabled to synchronize data to a mobile device 104 according to the method of the invention.

[0039] In the foregoing specification, the invention is described with reference to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. Various features and aspects of the above-described invention may be used individually or jointly. Further, the invention can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. For example, the methods described herein can also be used to synchronize data from a network server to a non-mobile device such as a network computer or another network server. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive.