col. 5, ln 4-11: In general design, all synchronization is binary--that is, two logical datasets are synchronized at a time. Any arbitrary synchronization topology will be supported. Here, the system guarantees synchronization stability and the avoidance of undesirable side effects (cascading updates, record duplication, or the like). Datasets do not need to be directly connected but, instead, can be connected via a "store-and-forward" transport, such as electronic mail. col. 6, ln 6-21: When performing synchronization, the system transforms records from one application-usage-schema set to another application-usage-schema set, such as transforming from an Internet Sidekick.RTM. cardfile for business contacts to a corresponding Palm Pilot.TM. dataset. Typically, there is a one-to-one relationship between records in the source and target datasets. If this is not the case, however, the component of the system that interacts with a non-conforming dataset includes logic to handle this non-conformance from the core logic. Record transformations are a combination of field mappings and conversions from a source record to a target record. It is often the case that there are significant differences in the number, size, type and usage of fields between two datasets in a synchronization relationship. The specification of transformations is user configurable, with the system providing defaults. col. 6, ln 61-67: Scheduling Management provides a management component that schedules synchronization activity. This component determines whether synchronization is scheduled or performed only upon demand; whether the user is prompted before the start of synchronization and notified upon completion; and scheduling of SyncSet sending and receiving (for "store-and-forward" transport). col. 11, ln 15-32: The basic flow or propagation of a record change from one dataset to another is as follows. At the outset, the changed record is extracted and looked up in the record map. The addition of the new record is noted in the Transaction Table, so the system can determine whether the record has already been dealt with. A corresponding export record (i.e., record data along with a globally unique ID) is generated for inclusion in the synchronization set or SyncSet being created. The SyncSet contains all of the record actions that need to be transmitted to the other device, including insertions, updates, or deletions. The SyncSet can, at this point, be sent via a variety of transport mechanisms, including e-mail, FTP (file transport protocol), and two-way pagers. The receiving device processes the SyncSet by proceeding to map it, during inbound synchronization. Here, the corresponding import record is mapped into a record form for the target dataset. Once the appropriate records get inserted, updated, or deleted, the inbound Transaction Table is updated.