TW200907720A - Bi-directional data modification with synchronization - Google Patents

Abstract

Systems and methods for synchronizing data between endpoints, including the modification of data on an endpoint without necessarily modifying data that is communicated between endpoints are disclosed. In such systems and methods the representation of data on an endpoint may be modified so that constraints on that particular endpoint are enforced, without requiring a similar or the same modification to the data when it is synchronized to other endpoints.

Description

200907720 IX. Description of the invention: [Technical field to which the invention pertains] The present invention relates to a two-way data modification with synchronization. [Prior Art] Various synchronization system systems exist to synchronize data between different endpoints, for example, between different computer systems. In some cases, in at least some of the representations, the synchronized material may be associated and limited by a particular limit. In some examples of this limitation, a computer file system may require a file name to use only a particular character, and files in the same directory have unique names that are in a directory. To represent and enforce the limitations, in some cases, a synchronization system itself can be designed or expanded to have knowledge and implementation of consistency-specific restrictions across all synchronization endpoints. In other cases, additional logic may be provided or defined in addition to or in the "above" of a synchronization system, so that when the data is synchronized with the synchronization system, the restrictions may be enforced consistently. Extending a synchronization system implementation limit (which may be specific or only about a certain type of material or a particular endpoint) may complicate the different aspects of the synchronization system, including making it more difficult to change or update the synchronization system operation. the way. For example, when a new endpoint requires data to comply with new restrictions, in some cases it may be difficult or even impossible to add a new type of endpoint to an existing system of synchronized endpoints. In addition, consistent application restrictions, such that each endpoint applies the same restrictions to the synchronization of the data will also cause potential problems, including the need to limit the synchronization of data limited to the low loyalty expressed by each endpoint 5 200907720 aid, Even when some of the endpoints can provide additional functionality or operate with more complex and potentially more useful representations of the same material, the following summary is provided to provide a basic understanding of the disclosure. This Summary is not an extensive overview of the disclosure and is not to be considered as a Its sole purpose is to provide some of the concepts disclosed herein in the form of a The description here is for data modification on the synchronization endpoint, and it is inevitable to modify the different techniques and techniques of synchronizing data. In the case of s, the representation of the data at one endpoint can be modified so that the restrictions on a particular endpoint can be implemented, and when it is synchronized with other endpoints, no similar or identical modifications are required. [Embodiment] The description herein is directed to different techniques and techniques for data synchronization. The data is modified on a synchronized endpoint, or permits to ensure that the data is enforced, and it is not necessary to modify the synchronized data. That is, and in at least some implementations, the data on an endpoint represents a limit that can be modified to be enforceable on that particular endpoint, when it is synchronized, or when accessed or used on other endpoints, It is necessary to modify similar or identical materials. In some implementations, a synchronization system includes multiple endpoints, which are primarily simple and detailed, but not actual.

, its endpoints , for example , the information between the resources 6 200907720

The execution code of the communication material is, for example, between a plurality of computing devices of various types. In an example, a synchronization system can synchronize the directories and files implemented by the computer between different computers. By using this system, a user can maintain a directory, synchronize all files (and perhaps subdirectories) in the directory, and between multiple computers. When a user changes a profile in the synchronization directory, the modified or altered profile can be synchronized and transmitted via various components from the computing device, wherein the change can be made in one or more other computing devices. When a user adds a new file, the new file can be similar to communication. The same or one or more other synchronization systems can also synchronize any of a variety of other types of data. In at least some implementations, there may be one or more restrictions associated with synchronizing data. If this restriction is not accompanied or attached, the synchronization data cannot be used, it is impossible to use it, and it can only be used. For example, continuing with an exemplary directory and file synchronization implementation, it is possible that at least some of the endpoints, the synchronization directory and archive must adhere to various specific restrictions. In one of many possible examples, a file may need to be a "child" of a directory or may need to be associated with a directory. In addition, the directory may need to be valid, cannot be deleted, cannot have invalid names, and so on. Another exemplary limitation may require that a particular directory does not contain two files with the same name. In a further exemplary limitation, two directories are not allowed to be children of each other (which may form a "loop"). That is, if "directory B" is a child of "directory A", "directory A" cannot be a child of "directory B". In still another example, the directory name and file name may need to use only characters selected from a particular set of characters. That is, perhaps, similar to "A", "B", "c", "d", "1", "5" 7

The alphanumeric characters such as 200907720 may be allowed in a directory or file name; and certain other characters such as "!", "%" or others may not be allowed. Other restrictions are also possible, both of which are suitable for an exemplary directory and file synchronization implementation, as well as any other type of material. In some environments, such as in a single computing device, it is considered fairly simple to ensure that at least some of the limitations are followed. However, in at least some other environments, including when data is synchronized between multiple endpoints and can be modified or changed on more than one endpoint, it may be more difficult to ensure that all restrictions are followed. As shown in an example, ensuring that a directory only maintains a file with a specific name can be implemented on a single system by, for example, an executable code associated with a file system" when the new file has an existing one in the same directory When the file has the same name, the executable code does not allow a new file to be created, and it is not allowed to rename a file to have the same name as an existing file, and so on. However, in a directory where the files in a directory can be synchronized between computing devices, and the files can be added, modified, or deleted on more than one computing device, the requirements (eg, need not be duplicated) are in at least some implementations. The system cannot be implemented only by a file system on a particular computing device. In the example where multiple files can be created, a new file can be created on a computing device. At the same time (or at another time prior to data synchronization), another file with the same name can be created on a second computing device. In this example, until the two computing devices synchronize their data, they cannot violate the need for duplicate files. However, fully synchronizing the data will require the file created on the second computing device to be created on the first computing device. Performing this action will create two files with the same name in the same directory of the first computing device, which will be 8

200907720 Violation of the restriction that duplicate files are not allowed in the same directory (the same problem will exist when the file created on the first computing device is synchronized with the second computing device). Another example of following a potential problem that may be difficult to limit may occur with characters that are allowed to be part of a directory or file name. For example, two or more endpoints that may use the same file system may have the same restrictions on the allowed characters in a directory or file name. That is, again, for the purposes of the example, it is assumed that both ends perform the same computer operating system with storage using the same file system. A file created on one of the endpoints (e.g., by the file system used on the endpoint or some file system implementation) has a valid file name. If the file is then subject to synchronization with another endpoint whose directory is the same as the file name, again (for example, and without limitation), the file name will remain valid. However, if it is synchronized with an endpoint or computing device, e.g., using some other operating system or file system (with different rules or restrictions for the file name), the file name may not be valid. Thus, for example, a building name like "F i 1 e ! · t X t" may be valid on one end, but may be invalid on the other end. In some cases, this file can be created without problems on one endpoint, but it is not possible to synchronize with another exemplary endpoint without violating at least some of the limitations associated with the synchronization material. In at least some instances where synchronization may be violated as a means of synchronizing data, various implementations or solutions may be used, for example, to attempt to resolve a potential problem by ensuring that the limitation is not violated or the violation is resolved. For example, in some implementations, you can decide whether to violate the restrictions, and perhaps 9

200907720 Automatically (or involves a similar user or some other executable code) to resolve this violation limit. Continuing with the previously cited directories and files, in some implementations, it is possible to automatically rename a directory or file that is a valid character at a particular location. For example, and the file created on a first endpoint has a file name on the first endpoint, and then the file name is not valid, the file name may be changed on the second endpoint, in some Dynamically changed, so the file name is used on the second endpoint. If the file is synchronized between the two ends, the file name can also be changed to the same new file name when the file is re-synchronized with the first endpoint. As a result, the file name may be slightly the same and valid at both ends. However, in this case, it is said that the current limit is no longer included as a valid element on the first endpoint, so there is no limit at all that is only related to the second endpoint. In some cases, different endpoints may have mutual Rejection is not a part of the data that can be represented at both ends, with restrictions on at least one of the endpoints. For example, a name for a character used in a language in India does not share any character with a name that uses one of the characters used in Chinese. In some cases, violations of restrictions may result in flagging or marking with some program items. The violation of this flag or tagged material and then by a user of the synchronised material, or by some other entity, may be resolved by some means, including through the action of the physical component. For example, some real-time synchronization endpoints that use directory and file synchronization are not restricted. If the valid one-two endpoints are the same as the case name, the file name of the first endpoint * _h is changed. . Restrictions, without violating H i n d i (Northern English, etc. will be estimated together, and then the user will be the same 10

Another special and non-limiting example of 200907720 shows that if the synchronization of files causes the same name to be used to create a file in the same directory, one of the two files can be placed in a "reserved area", such as a specific directory, or There is some way to distinguish it from another file, so it does not violate the restrictions. This action can then be tagged using "conflict" or other similar components of the synchronization system, and the user (perhaps the user of the sync file) can be notified through some of the components of the conflict. For example, a user can see a dialog box, receive a "conflict email", and the like. The user can then resolve the conflict through one or more actions, such as renaming one of the two files, moving one of the two files to a different directory, deleting one of the two files, and the like. When the user changes a renamed file, a mobile file, a deleted file, etc., it is then re-synchronized with the first endpoint, and then both ends point and then have the same group with the same name in the same directory or the like. The file does not violate the relevant restrictions. While such previously cited techniques allow for data synchronization without compromising limitations, the technology may have its own limits. A potentially problematic limitation may be to change the data to ensure that the accompanying restrictions result in the synchronization data only utilizing or using the functionality that is generally available at all endpoints. For example, even if one or more endpoints support directory or file names that use various characters, if the directory or file is synchronized with another endpoint that only supports a more limited set of characters, these endpoints cannot use these words. A directory or file of many characters in the meta. In another example, when the archive is in a single file system, although the need for duplicate files may be common, this requirement cannot be applied to other representations of the same directory and archives. As shown in a specific example of this situation, if a directory structure is to use a web page (for example, 11

200907720 HTML) is a "net projection", and the user has the ability to download the file by clicking on the link of the page, allowing files with duplicate names, because in this representation, a "file" can only be HTML is composed of a link, and there is no reason why HTML and links cannot include some repetition. These types of limitations can also be problematic when improving, developing, or otherwise changing the endpoints of synchronized data (or data synchronization). Similar restrictions can reduce the way to improve or change a synchronization system, or reduce the number of endpoints that join data synchronization. For example, when the initial endpoint of the synchronization material may have the same or similar restrictions - perhaps the first implementation of a system is only executed on a computing device executing a particular version of an operating system, assuming that later, it may be desirable to delay the synchronization The system is executed on one or more of a variety of other operating systems, or a genre type device. For example, you want to enable perhaps less computing power, while also supporting computing devices that may be less functional (such as mobile phones) to join data synchronization, rather than just "desktop" or "laptop" computing devices. Execute on. However, following the new restrictions required for this endpoint, the data that needs to be synchronized is more limited in scope, functionality, and so on. (Or, new extra endpoints are not included in the synchronization system until the new endpoint includes the functionality required to interpret and synchronize the entire or raw breadth of data synchronized between the endpoints.) In addition, except In addition to reducing the loyalty or ability of synchronized data, this change also requires modifying all of the added endpoints to support new needs "simultaneously" or before synchronizing with other endpoints. This may require, for example, an older endpoint not attempting to synchronize data to a new endpoint that does not support or use the material. In some synchronization systems, it is not practical or possible to use this method.

200907720 Change or update all endpoints, and as such, in some cases, a wide range of updates may not be performed, or in other ways it may be more frequent than in some implementations, by "implementing" "synchronized data" The processing of "information" to illustrate at least some of these questions is yes. As described herein, in general, synchronization information is implemented on the domain data to map the synchronization of data (e.g., between endpoints) to the use of data representations on the endpoints. The "synchronized data" will then contain at least a portion of the data communicated between them, and the "domain data" will contain a representation of the synchronized data placed on an endpoint. As an example, it is considered to communicate between the endpoints by communicating files: 乂 synchronizing directories and archival material implementation. In at least one example, the XML file can be considered to contain the synchronized material. In a non-limiting manner, perhaps the directory and file intermediate data (e.g., a directory or file name related to the time and time of a directory or file, etc.) may be an XML file table. In some cases, the actual archive may be referenced from the XML, but not converted to the portion of the XML itself. In the case, the archive material can be included in the XML file. In this example, an XML file and any referenced archives contain the synchronized material and can be implemented on the actual file system object or file component, such as the actual directory containing the domain data. Part of the implementation of a synchronized XML can be implemented by modifying (including creating, updating, and deleting) the actual directories and files in a file. That is, in at least some implementations, the executable program interprets the contents of a synchronized XML file and then creates, updates, and deletes useful lines. The field may be a special endpoint or XML, νμ example, the next file, the other system and the file system can be deleted, 13 200907720 or one or more directories and files. (It should be noted that the use of this, such as the term "modification of domain information", should be interpreted to include modifications to existing field information, as well as other actions taken in the field, including the creation of new domain data and the deletion of existing domain data. In this example, and in many other implementations and examples that include unsynchronized directories and files, or otherwise different, at least some of the previously cited questions, as well as other issues, may be at least partially synchronized by the data to the domain data. The way of implementation is explained. As shown in the example, in order to resolve the inconsistency in the difference of the support characters from the directory or file name, the directory or the file itself (when it is represented in the synchronized data) is not modified, when used with the -file system, The synchronization resource can be implemented on a directory or file having a name, and when used with another file system, can be implemented in a directory or file using a different name. That is, in a non-limiting example, the directory or file name included in the synchronization material can be implemented in a directory or file, and can be treated as if the directory or file name is valid for a particular file system. Part of the use of material in this field. However, when the directory or file name included in the synchronization material is not valid for a particular endpoint, the directory or file name can be implemented in a directory or file using a different name that is valid for the particular endpoint. Moreover, in at least some implementations, when the domain data changes, ie in the previous example, when the actual directory or archive changes and the change is synchronized with other endpoints, in at least some instances, The change of data carried out in the part of the data in the field of synchronization data is not transmitted, synchronized, or visible to other endpoints.

200907720 Shoot back to the synchronized data. For example, suppose that due to the processing of the synchronized domain data, and a file having a name is different from the name specified in the step data. Changes to the file (or the content of the file) need to be synchronized with other endpoints. However, changes to the file name (i.e., changes made during the implementation process) cannot be synchronized with the updated file data. Conversely, as part of the synchronization data that produces the file, it is decided whether the name of the file is different because of the processing. Here, for example (and without limitation), the original name specified in the synchronization material is used as part of the generated synchronization data, not the file name on a particular endpoint disk (or in memory). Various similar or other mechanisms for mapping domain-synchronized data may also be implemented, as described in more detail. Often (and differently stated), a difficulty in implementing a synchronization system ensures that the synchronized data between the endpoints can be "unified" in the same state as the endpoints. That is, although evolution on a particular endpoint may result in different data on one or more endpoints, the change should be synchronized in such a way that eventually all endpoints will have the same change and be unified into phase. Communication between endpoints. Restrictions that exist at one or more endpoints make it difficult to unify to a common state. For example, as in the example described above, one of the endpoints can synchronize the file of the other endpoint (having the same name as the file already existing on the endpoint j. If you use a file system endpoint that does not allow the same name file to exist in the same location, you can try to borrow Renamed by one of the files to solve the problem. Then, the renamed file can synchronize with other endpoints. However, the change to the same is that when it is together with the situation, th appears in Not changing, but the same shape is more difficult from I) °, —— potential, 15

200907720 If more than one endpoint independently changes the name of the same file, a situation in which the name of the file is repeated on multiple endpoints may occur, and the changes may be divergent and do not reach a common state, rather than being unified into a common state. . In some implementations, this problem can be addressed, at least in part, by separating the synchronized data from the domain data and then implementing the synchronized data in the domain data (as described herein). In this implementation, the synchronized material does not need to comply with the same restrictions that are defined or required for the data in the field. Second, it makes it easier to synchronize the data to unify the common state across all endpoints. The processing of the synchronized data to the domain data is then used as part of the application to be limited by the data in the field, and as part of the use of updated synchronized data for at least some of the changes in the field of material . Finally, it is understood that in at least some implementations, at least some of the problems, including those previously described and described herein, are the same as the "generalized" synchronization techniques of design, in that the synchronization techniques are designed in a variety of different types. Operation on the data. That is, in some cases, specific processing including restrictions related to particular types of information in the synchronization system (which only synchronizes certain types of data in operation) is possible. However, it may be more difficult or undesirable to include this specific processing using a general synchronization technique that synchronizes various types of data. As a result, techniques such as those described herein, including mapping between synchronized data and domain data, can provide particularly useful benefits when used with general synchronization techniques. Please refer to Fig. 1, which shows an exemplary system 1 0 0 in which data can be synchronized and shared. The exemplary system 100 includes an endpoint A 1 1 0, an endpoint B 1 2 0, an endpoint C 1 300, and an exemplary communication component 1 15 . Figure 16 of Figure 1

200907720 Description is about other schemas. However, it should be understood that the elements depicted in Figure 1 are not intended to be limiting for use with the elements described with respect to other figures. Further, while the exemplary figures of Figure 1 represent particular elements, in some implementations, not all of these elements may be present, and in some implementations, some additional elements may be present. In general, a shared or synchronized relationship can exist between two or more endpoints. A particular sharing relationship is typically associated with a set of materials that contain one or more data items, or just projects. When the project makes at least some kind of change, the changed project or just the change itself can be synchronized to another endpoint (or some endpoint) in the synchronized relationship. Although the synchronization of data can be implemented using various techniques and techniques, in at least some implementations, the synchronization of the data can be at least partially achieved by adding specific data to the use of similar RSS (Simplified Joint Organization "Really Simple Syndication" Or "Rich Site Summary" or feed information provided by Atom's potentially widely accepted agreement. For example, in an exemplary implementation of a technique consisting of only two endpoints communicating with each other, in at least one example, for example, (or perhaps) the publisher of endpoint A 11 0 may publish an RSS or Atom feed containing some type of information. give. In an (and perhaps) example, the feed may include information representative of the catalog and the archive. In still another example, the feed can represent, contain, or reference any other material. In an example, a publisher, such as (perhaps) endpoint C 1 3 0, may subscribe to the feed provided by the first endpoint, and when, for example, the first endpoint adds a new file, modifies an existing profile, etc. The publisher can be notified when. In addition, a pre-17

200907720 The approximate endpoint can publish its own using the same capital and the changes or additions made by the subscriber in the original publisher feed. The original publisher then reserves this second feed. Through this appointment, the changes made at either endpoint can be reflected at the ends. In addition, multiple endpoints may participate in the same material by making reservations to at least one of the other endpoints, and similarly publishing their own feeds. In at least some implementations, the synchronization information in a feed, when the data is exchanged, the processing followed by at least a particular endpoint may be similar to, for example, a simple shared extension (Simple Sharing Extensions). SSE It is usually defined as a feed agreement with the cheek and Atom, or other feed agreements or documents that extend or additional information about the information used when using a feed or sync data. In the case, an Atom, or other type of feed including SSE information, may be referred to as a "give." A protocol (such as SSE or another synchronization protocol) may also define a procedure followed by the end, so synchronization in a feed The information is compliant, and as a result, in a synchronous relationship, read by other endpoints and shown in an example, the SSE specifies specific synchronization information, which may exist in a SSE feed. When a new one is created At the time of the project, one end is responsible for ensuring that the appropriate SSE information is related to the new project, and that the message is provided in the correct location of the feed, using the correct knowledge, etc. when, for example, an endpoint Modify an existing project, delete an existing item, and feed it. Some of the information in each other is for feeding and sharing and when it is the same or class, SSE) /.'f T? <? Q, a. Send RSS and SSE feed points to a specific group. For example, it can be used as a negative SSE name in the point.

200907720 When changes are made from other endpoints, an agreement similar to S S E can also define other procedures that require specific information to be included. In a shared relationship where both ends are posted and reserved, each endpoint can make a "partial" change to the project, where for some reason a "local" change can be a change made at a particular endpoint, including for example Changes made by entities such as users and automated processes. Then, the shared item remains the same on both endpoints, and local changes can be issued as part of the feed. The other endpoint can maintain the same project in its own group, and (because its subscription feed) can "merge" the changes exposed by the feed with the project group it maintains. The other endpoint can also make its own local changes, and then, after the wei wei, can be combined or merged by the first endpoint. As shown in a particular example, endpoint A 1 1 0 (or endpoint B 1 2 0, or some other endpoints not shown in the figure) may join a shared or synchronized relationship with endpoint C 130. Endpoint A allows an Atom feed to be available, including project data and feed synchronization data. Endpoint C can access this feed, merge or combine the changes in the feed into its own store of the project, and then make its own feed available. Endpoint A then subscribes to the feed provided by Endpoint C and merges the changes produced by Endpoint C. In some implementations, an endpoint in a shared or synchronized relationship may itself generate or update a feed used in a synchronized relationship. For example, a user may use an application associated with endpoint A 1 10 to modify some of the material that is then shared and synchronized by endpoint A (perhaps endpoint C 130). In order for the user to make changes for Endpoint C, Endpoint A may need to update the feed using the changed project information and the changed feed synchronization information. 19

200907720 In an implementation using SSE, the feed synchronization information in the feed can be updated, for example, by modifying an XML file, in particular by updating a particular "version" attribute using a new version number. The feed is specifically implemented by modifying an update history related to the project, by creating a new XML component, and the like. As used herein, synchronized data can typically include data exchange, transmission, or communication between endpoints. In a non-limiting example, when a protocol like S S E is used to synchronize information between endpoints, the synchronization profile can include a feed that includes SSE information. This feed may itself contain one or more feed items (or some feed data items), which in some cases may be referred to as "synchronized data items." In other implementations, the synchronized data item (with the usual synchronization data) can be represented by a variety of other methods including the use of s S E . In some implementations, not all endpoints must establish a feed and reserve a corresponding feed. For example, some endpoints may only publish (but not make reservations) feeds that are related to some specific group of materials. This endpoint can publish information about local changes made by the endpoint, but does not incorporate changes made by any other endpoint. Any other configuration of hair accessories and appointment actions may be considered or implemented depending on the particular circumstances or circumstances. Also note that in some implementations, if more than one data set is shared, the end points of a particular group may have more than one sharing relationship. In other implementations, a shared relationship can be defined to include all of the material shared between the two ends, even if it includes more than one single group type of material. Moreover, in some implementations, although a common relationship may exist between the two ends, a particular set of items and any number 20

200907720 Volume endpoint sharing and synchronization is also possible. This can be achieved through various offices of the endpoint. As shown in an example, some of the number of endpoints are synchronized with a particular endpoint, which is then synchronized with one or more additional endpoints that are not directly related to the original step information. In at least some instances of this situation, information can be synchronized throughout the synchronization endpoint. Endpoint A 1 1 0 and endpoint C 1 3 0 are shown in system 100 connected by an exemplary communication component 11 5 . This exemplary communication is translated into any component that includes transmissible material, including any other type of transmission of any type, including the transmission of physical media, a class (CD) or flash memory drive. The endpoints may also be directly connected, e.g., by a connection between the endpoint 10 and the endpoint B 1 2 0. The information shared and synchronized between the endpoints may be stored in various ways. In at least one implementation, an endpoint may be stored in the same computing device or in one or more other computing devices at the remote end, the storage may be by one or more disk drives or magnetic or devices, or by Any organization that can store data can access some or all of the synchronized data in a specific real-time manner, for example, using a network communication component to access the data. In some implementations, an endpoint may use a data store such as a computer 'library, or other storage facility, to store a shared dynamic or generate a feed on a particular time. In the same or medium, an endpoint can store itself in a file system to store itself, perhaps in the case of an RSS feed, by storing a configuration or placement point with a set of endpoints or otherwise The group is represented by the network to be solved by the component or as shown in the CD-ROM Ik AI. The location is added to the data. In other storage applications, when the remote or other implementation data is 'and other implementations are saved Give XML file 21

200907720 case, etc. Each endpoint displayed on this system can represent some general purpose or proprietary computers, including desktop computers, server computers, notebook computers, workstation computers, mobile or cellular phones, and connected personal digital assistants (PDA, person digital Assistant). In at least some implementations, an endpoint can be implemented by a computing environment, including the exemplary computing environment discussed with respect to Figure 5 below. Referring now to Figure 2, there is shown an exemplary generalized operational flow 200 that includes performing different operations when merging synchronized data at an endpoint, including implementing synchronized data to domain data. The description of Figure 2 below is based on other drawings. However, it should be understood that the process of the Panther Marking in Figure 2 is not limited to use with the elements described in relation to these other figures. Moreover, while the exemplary operational flow of Figure 2 represents a particular order of execution, in one or more alternative embodiments, the operations may be in a different order. Moreover, while the exemplary operational flow includes multiple steps, it should be understood that in some implementations, at least some of these operations may be performed in combination or concurrently, and in the same or other implementations, some steps may not be performed. In an exemplary implementation of operation 210, the synchronized material may be obtained from a variety of locations, including another endpoint, through various components. For example, in an implementation of one or more feeds that use synchronized data (eg, an implementation using SS )), at least a portion of an implementation of operation 210 includes a feed of a feed file, including items Information, as well as feeds to synchronize data components. This feed file can be retrieved from an end point that performs at least some of the operations of the exemplary operational flow 200, such as by performing an HTTP GET request, or by a 22

200907720 Some other network or other data retrieval operations. In the same or other specific examples, the synchronized material can be delivered or provided to the endpoint. In some of these, the synchronization data can be represented by a feed 422 or an input feed N 424 similar to that described in relation to Figure 4 below. In at least one implementation of operation 215, the obtained synchronized material (the material that has been obtained by performing operation 210) may combine or merge the synchronized data maintained by the terminal. In at least some implementations, the combination of the obtained external synchronization data and the region synchronization material can be performed using one or more techniques. In some implementations, this technique can identify at least one synchronization issue. For example, when multiple endpoints modify an item 3 independently, a type of problem that can be identified may occur, and may need to be checked or processed in one step, so for example, when stored on another endpoint, at an endpoint Changes made will not be overwritten or lost. In some cases, a merge operation may be performed by or with respect to a sync module (which is the same or a sync module 410), and causes the input to synchronize data and save, or use a synchronized data storage module 4 30 0 produces a combination or combination of the same data available, both of which are referred to below with reference to Figure 4 | For example, in an implementation using SSE, at least the operation of Operation 2 1 5 may include the use of SSE as a combined feed Technology to combine one loss with an area feed. For example, in some exemplary implementations, the synchronized data obtained as part of the 210 may be an "external feed", and the executed project update may be performed using something similar to a synchronized data storage module. The maintained area feeds the store for operation. For example, in at least one implementation, a region-maintained feed file may be implemented in an implementation input including a point or a different potential specific φ -*s change as implemented in a stored procedure. A real feed operation area 430 is not limited to operation 23 200907720 Ο 2 1 5 is more innovative during the execution, so the input or external feed of the area is represented or concretely: In some implementations, although in operation 215 Merging and executing at least one of the links *3 external processing (similar to identifying the conflicts that can be determined by using the synchronization data), but at least the other operations cannot be used as part of the 2 1 5 At least one of the operations of step 215 of the operation 215 is performed to the domain resource M + only the process of barrenness, which in this implementation may be performed by other extreme operations in the exemplary operational process 200 230. # After completing the implementation of operation 215, changes or modifications implemented in the alternative data may be considered to synchronize the data in the area. That is, I, Example #, in another, and the synchronized data communication obtained in operation 2 1 0 have been merged into the corresponding region synchronization data. For example, the synchronization data obtained in operation 2 1 0 represents that the directory and the file change are in the obtained synchronization data, and the area indicating the execution of the mergeable change to the synchronization data indicates a synchronization agreement or is used to merge data. The use of technology. For example, if the merging process can determine that the s s E is held in at least some of the cases, the identities are identified or marked. For example, using a Me j can be considered a SSE conflict. The at least step-by-step funding of the document is fed to the implementation. Including the audio end of the term has been merged in the implementation of more than one capability, and the feeds in the middle, especially in the same implementation line, the same as the transmission and reflect the changes achieved, if A 215-day land, the possible end of the 'this item' item 24

200907720 However, although the area synchronization data has been updated, this is not implemented, mapped, or used to update the corresponding domain data. The sample is typically used by a user, processing or other entity. In the case that the directory and the archive area synchronization data representation may have been updated, the existing file is previously represented in the domain synchronization data, but these changes can be implemented in the field of actual file system objects or file system components. For example, directories and files. Thus, in at least one implementation of operation 220, it is determined how the synchronized data item is to be processed as part of implementing the synchronized data item to the lead item. If there is an item 3 to be processed, the following: Operation 225 can be performed as follows: 3⁄4 200. If there are no more projects, the process can be ended. In at least some implementations, during the first execution of the operation, the item represented in the area synchronization material may still have not been processed. For example, in an implementation where S S E is used and where the item is represented in the area synchronization material, when operation 220, there may be 10 items to process. In other implementations, various filters or other components are used, and only specific items selected from this area are considered to be processed. In some implementations, during subsequent iterations of the operation, the previously processed items are deemed to no longer need to be in the same or in other implementations, and it may be determined whether the processed items are in need of care, ie, for example, in some cases, an item may be It is processed more than once. For various reasons, it may be decided to synchronize the data items for external processing, including the possibility of implementing the same or other synchronized data items. In the case of a change in the same information, there is still no data*. If there is any data in the process, the data in the 220 is displayed in the first instance, and the data is transmitted in the middle. In the extra place, more than one, the required amount of information, 25

200907720 Part or result of the project. In at least one exemplary implementation of operation 2 2 5, one or more items in a region synchronization profile may be considered to be subsequently processed for further processing at operation 230. In some implementations, only a single item is identified at a time. In other implementations, including the ability to implement multiple synchronized data items in a field data item, more than one assimilated data item can be identified when operation 2 2 5 is performed. As shown in an example, each time an operation 2 2 5 is performed in an implementation of the synchronization directory and file information, a new directory file in the area synchronization data can be identified. In the same or other directory and file implementations, multiple 曰 can be identified in some implementations of Operation 2 2 5; For example, when identifying a item, an implementation of operation 2 2 5 may also identify or attempt to identify a file in the directory. When the upper directory of the file is also implemented to the domain data, this allows for the implementation of the file to the domain data. Finally, in one or more implementations of operation 230, one or more of the leader items may be implemented at operation 225 with other synchronized data items (or items). Typically, one or more synchronized data items can be implemented in one or more domain data items by using less information contained in the synchronized data items to create or modify the relevant domain data items. The specific way in which the implementation of Operations 230 is related to the establishment or modification of a data item in a field, how or how the usage data relates to a synchronized data item is usually dependent in part on the characteristics of the synchronized data item and the domain data item. In addition, in at least some implementations, operation 230 may be performed at least in part by a current module (eg, exemplary implementation module 440 or implementation module 442, which may be a single step j or an entry description) The domain is at most or less. This is actually implemented by 26 200907720 as described below in relation to Figure 4. As shown in an example, consider a case where a synchronized data item represents a file, the synchronized data item includes text describing the intermediate data of the file, and is located in an XML feed file (which may also include SSE information). And the content of the file is also located in the XML file (perhaps when the content is text), or in binary data, and in some other location referenced by the data in the feed file. In this case, in at least some of the implementations, the domain data item corresponding to the synchronized data item can be an actual file in an archive system. In this example, implementing a synchronized data item in a domain data item may include (or perhaps) using a program interface ('m'', a programming interface provided by a file system or operating system to create a new standard. The file has intermediate data and content provided in the synchronized data item or referenced by the synchronized data item. If the file already exists, implementing the synchronized data item may include updating the information related to the file, including the file intermediate material or file content, so it is consistent with the synchronized data item. For other types of data, other synchronized data representations, other field data items, etc., the implementation of a synchronized data item to a domain data item can be handled differently. While this implementation is sufficient in at least some cases, in other environments additional processing may be required to implement a synchronized data item to a domain data item. This other case may include some environments (including those in at least some of the examples previously introduced or discussed), where the functionality, support or representation of the data in the relevant field is functional, and support.

200907720 There is a difference between aid or representation. For example, an example of this difference (again as previously introduced) may be when the set of valid characters allowed in the synchronized material is different or greater than the set of valid characters allowed in the corresponding domain material. When this difference exists, it may be necessary to exceed the transmission or copying of a component of a synchronized data item to a corresponding domain data item. For example, in some cases, information from the synchronized data item may need to be modified, so the corresponding domain data item is valid. In addition, this modification of the material may need to be performed in this manner without modifying the synchronized data item, and will not be modified when changes to the domain data item are later used to update or generate a new synchronized data item. In order to use when synchronizing other endpoints, the method of changing the domain data item S can, for example, enable other endpoints to fully use the synchronized data, even when a particular endpoint can only support, for example, a more limited representation, Limited features, etc. When the domain data is modified or later when the synchronization data is generated for communication with another endpoint, modifying the domain material without modifying one of the synchronization materials may use the recording to modify or change the data item of the domain. The data structure is used for a specific synchronization data project or some projects. Later, when synchronizing data is generated, this data structure can then be used, (perhaps) to identify the original synchronized data item (or some items), or "reverse" the changes made as part of implementing the synchronized data to the domain data. Or some changes. As shown in the example, again consider the case where the synchronized data represents a directory and a file, and there are one or more various restrictions or inconsistencies on a particular endpoint. In this example, the implementation of the directory and file synchronization data to a field 28 200907720 data representation may include determining whether the synchronization data is inconsistent or inconsistent with the required limits of a domain data representation in some methods, and if Confirm, modify the data project or some projects in the field, and record the changes or some modifications. Specifically, for example, assume that the file being communicated in the synchronized material has a name that uses characters that are not supported on a particular file system. Portions of implementing this synchronized data item may include, for example, creating an actual file with a different name, and again recording how to change the field data item (e.g., file). This recorded material is then used, for example, later, and as described in more detail below with respect to Figure 3, as part of a synchronized data item that determines how to generate or update communications with other endpoints. As introduced by the Emirates, when synchronizing data to the domain. The data can be used to determine various modifications of the required domain data, depending on the synchronization data, the domain data, the executable implementation endpoint or some end. Points are related. When one or more modifications are required, implementing the portion of the synchronized data to the domain data may include modifying the domain data to resolve the inconsistency, implementing restrictions, and the like. In the example of directory and file synchronization data, and in various other examples, additional situations may arise during the implementation of the material in need of modification. At least three of these situations may occur when the domain material contains information that is composed in one or more classes, but wherein, in at least some implementations (including those using some of the SSE formats), the synchronization data It consists of only a "monotonous" list of materials, without the inherent concept of hierarchy. In this environment, or in other environments, a hierarchical representation can use one or more additional fields of information on each synchronized data item.

200907720 Save the "upper layer" of the project. With this implementation, the step data of the standard located in a directory may have data in a particular data field, including, for example, a record name, a directory ID, or some layer structure that allows for inference from a non-hierarchical data representation. Other information. Although this implementation allows for the representation of class information, it may also create contradictions, inconsistencies, or other circumstances that require domain information to be modified when synchronizing data to the leader. These issues can include orphans, collection loops, or other issues. In general, these problems can be at least some of the specific parameters that may occur when the underlying synchronization (eg, as in Operation 215, Merging Synchronous Data) independently synchronizes the components or use of the data. . That is, when the underlying synchronization technique does not necessarily support or have knowledge of domain-specific relationships that exist in the domain data, these questions may exist in at least some implementations. As explained earlier, in general, when real-time synchronization of data to domain data, at least some of these types of questions can be resolved by modifying domain data. For example, in some implementations, at least one file in the file system may need to be in a directory, and thus may need to have a "father." The file (or directory) without the upper layer can be considered as an orphan j. Although an operating system can avoid the construction of isolated files or directories when a user directly interacts with the file system object, when synchronizing the directory and file information, An orphan can be established. For example, suppose a user adds a slot to a directory, and another user (on the other endpoint, and synchronizes the newly added files to delete the same directory. If the second user then synchronizes, And so to receive the most newly added files, the newly added files will be orphans, because the upper layer and the a-level domain Λ 存 有 有 有 现 现 现 现 现 现 近 近 近 近 近 近 近

200907720 Record no longer exists at the second endpoint. The problem of isolated file system objects can be solved in various ways. In an example, when the synchronized data is implemented to the domain data, the isolated file can be moved, and the domain data item (actual file) is placed or located in the "reserved area" or some specific of the file system. Location, such as a specific directory. This change can only be achieved from the point of view of the endpoint that implements the synchronized data. That is, the synchronization of the material itself is immutable, and from the point of view of other endpoints that use the same synchronization data, the directory may still be deleted, and recently added files may still exist. In addition, a different implementation process (perhaps an implementation processing system is used with a network projection, and its storage file is in a non-hierarchical list of data sequences, see only using the directory as a money file name) There is no upper-level directory that is considered to be a matter of debate or problem at all. In some examples (for example, the field data contains an actual file system, or other types of domain data), the user may also be notified that the particular file is orphaned. The user can then take some specific actions, such as moving the file to a directory that has not been deleted, deleting the file, etc., which may decisively resolve the inconsistency. This action taken by a user typically makes local changes in the domain data, and as such, the change (or the changed domain data) is then included in the updated synchronization data and synchronized with other endpoints (as described below) A more detailed explanation of Figure 3). Another potential problem may arise when, for example, a file with the same name located in the same directory is created on multiple endpoints. When this file is synchronized, the synchronized material then indicates that the file with the same name exists in the same directory, which is not allowed by many file systems. (However, just as isolated files 31

In the example of 200907720, an archive with the same name cannot be a problem with some type of collar. In the case of a file system implementation, copying files can be resolved in a variety of ways. In one example, one of the copies is selected in some manner, perhaps by selecting an item with a higher SSE identification code and then moving to a reserved area, similar to a particular directory. As a result, the file contains a file in the original directory and another directory with the same name. In addition, as described above, a user, processing or other post-evaluable file, and deciding whether to take any further action may include renaming one or two files, moving one or two file locations, deleting a file, and the like. And finally, similar to the foregoing, this uses the domain data and then generates at least some implementations of corresponding synchronization changes, and synchronization of other endpoint changes or changes. However, another potential file system problem is "looping" when (for example, "directory A") is a child of "directory B" on an endpoint, although at the same time or at least at both ends, the data is synchronized, "directory B" The child of "Directory A" on the other endpoint. A file system may require all file system objects or file systems in the file system hierarchy to come from an object or component, and a loop is in violation of this need to resolve this inconsistency and may include a loop file system object transfer area. Or a specific directory. As before, a user can be notified of this change to be able to resolve the problem decisively, perhaps by re-arranging the file. In another file system example, some file systems may allow for multiple or alternating data streams or data sets, rather than just for domain data problems, and then the case is in the entity. This is a sub-catalog of different revisions, which can be used in a unified component. Single to one guarantee, and then in the archives. A data 32 200907720

Stream or data set. A synchronization system can be implemented without the use of a file operation including an exchange of data streams, so that it only supports files with a single data stream, and does not allow files that also exchange data streams. However, in an implementation of synchronized data implementation to domain data, files with exchanged data streams can be supported or even synchronized with endpoints that do not support this file. For example, on an endpoint supporting a file with an exchange stream, only a single file (including an exchange stream) can be created. However, on an endpoint using a file system that does not support the exchange of data streams, the exchange of stream information in the synchronized data can be implemented in additional and separate files. (In addition, as described below in relation to Figure 3, when synchronizing data is generated, additional and separate files are available. t. Peaks represent the synchronization of a single file with an exchange of data streams). It should be noted again that while many of the previous (and subsequent) operations and other elements have been explained with reference to specific examples of directory and file synchronization discussed between endpoints, the techniques described herein are not limited to this implementation and are suitable for Different other uses, including synchronization as various other types of data. As shown in another example of synchronized data and domain data, a content management or blogging system can synchronize high-level objects or files, as well as comments about each object or file. In this example, the text of the file or comment may be assumed, assuming an item in an RS S feed using S SE. In addition, various restrictions may exist between, for example, a clause and a comment. For example, at least when represented by a user interface, each comment may need to be associated with a top-level article or file. When synchronizing data is implemented, comments that are not related to the highest-order article or file may be flagged for further review and may not be displayed. 33 200907720 Another example of a synchronization system in which synchronization of data is available is useful, including one exemplary system in one or more specific languages. In this implementation, information is converted from one language to another by using some of the synchronized data to the domain data on the endpoint. Similarly, the information provided in the words can be converted into a message during the implementation process. As shown in a particular example of such implementation, a user can create a file in the Indian language. This file synchronizes some of the other endpoints that are manipulated by the reading user. As with the implementation of the file in the processing of the endpoint, the information in the file is available from Hindi. Perhaps, in the same implementation, the second user created file can synchronize the first user. Then, as part of the implementation of the file on the endpoint of the user who reads it, the file is converted to English in Hindi. Please refer to Figure 3 for a list of different operations. The generalized operational flow 300 0, when generating synchronized data feeds, can perform these different operations, including the use of prior material to produce synchronized data. Figure 3 below describes what is and is. However, it should be understood that the operational limitations described in relation to Figure 3 are used in conjunction with the elements described in relation to these other figures. The exemplary operational flow of Figure 3 is representative of a particular one or more alternative implementations that may be performed in a different order. Although the exemplary operational flow includes multiple steps, in some implementations, at least some of these operations Combinable or same-domain data may be used to synchronize information in other languages, including the use of information in other languages and languages. Hindi (the second user language of the Northern English language is converted into English-speaking neighbors. Hindi language information is available from Other areas of the exemplary other endpoints are available in other schemas. The process is not to be added, although it is in the order, but in the process. In addition, it is understood that it is executed at the time, and 34

200907720 And in the same or other implementations, some steps are not executable. The previously described operation of Figure 2 illustrates how the synchronized material, for example, can be merged into the region-synchronized data from another endpoint, and then implemented into the domain data item. This action allows it to use changes made at the other endpoint at a particular zone endpoint. However, the operations described in relation to Figure 2 are not such that they can update their data at other endpoints using changes to the domain data items made at the endpoints of the region. For example, again using the unrestricted directory and file examples, assume that a user updates a file, perhaps by opening a file in an area application, making changes, and then saving the file. At some subsequent point in time, an updated feed is generated to reflect the file change, so K can then merge and change to its own zone file. The use of the exemplary operational flow 300 can assist in accomplishing this by generating synchronized data that is then synchronized with other endpoints. In an exemplary implementation of operation 310, synchronization information suitable for communication or available to other endpoints can be initiated for one or more of various reasons. In some implementations, new synchronized data may be generated periodically after some time interval has elapsed. In the same or other implementations, new synchronized data may begin to be generated when one (or more) domain data items are locally changed; or, for some other reason, new synchronized data may be generated. In at least one exemplary implementation of operation 315, it may be determined whether any domain material items are to be processed. If there is a domain data item to be processed, the exemplary operation flow 300 can perform the following operations 3 2 0. The example operational process can end if there are no more projects to process. In some implementations, all domain data items can be processed by the exemplary operational flow 300, while at

200907720 In his implementation, he can handle only some of the domain data items (for example, perhaps only those that have changed, or only those that have changed or have changed). In an exemplary implementation of operation 320, one or more domain data items may be validated for use when generating updated synchronization information. In some implementations, each domain data item may be considered individually; thus, only a single domain material item may be identified during each execution of operation 315, while in other implementations, more than one domain data item may be identified, and then Can be considered together with other identified domain data items. In at least one implementation of operation 325, it may be determined whether any synchronized data items that are the domain data items identified in operation 320 may need to be generated. If required (or may be required, but cannot be determined during this time) to generate one or more synchronized data items, the operational flow can be operated 3 3 0. If you do not need to synchronize the data items, the operation flow can be operated 3 1 5. Whether or not a need for one or more synchronized data items can be determined in a variety of ways. For example, in the implementation of all domain data item processing, this decision can be achieved, at least in part, by determining whether the identified domain data item has been modified, since it is the last synchronization. If confirmed, a synchronized data item or some items need to be generated, so other endpoints can make local modifications. For example, if a domain data item (e.g., an actual file) has been updated or changed, this operation may determine whether a synchronized data item, or multiple synchronized data items, should be generated as a data item in the field. In some implementations, a modification made as part of implementing a synchronized data item on a domain data item (e.g., the exemplary operation 230 described above with reference to Figure 2) does not include a change that produces new synchronization data. 36

200907720 More. That is, for example, a new synchronized data item may be needed only when a user or other entity makes a change in a domain data item. From another expectation, it should be understood that, in some cases, modifications to a domain data item that is part of the synchronization of data on a data item in a field sometimes only result in changes in the data item itself in the field. This change may not be visible to other endpoints; or it may be synchronized with other endpoints so that no new synchronization data is needed. Finally, in at least some example implementations of operation 330, one or more synchronized data items may be generated for, for example, a domain data item or some items that have been identified in operation 320. For example, when the identified domain data item 3 has not been modified to implement the bucketing time on the domain data item 2, the operation can be implemented by using the data related to the domain data item to generate A corresponding synchronized data item. Local changes made on the data item in the field are then reflected in the generated synchronization data and synchronized or communicated with other endpoints. For example, when an actual file implementation implements a domain data item that has been updated by a file user at a regional endpoint, this change may reflect the newly generated or updated synchronized data item. In an implementation using SSE and a feed file, the synchronized data item can be generated, at least in part, by performing an SSE update, which can include, for example, updating project information in the synchronized data item, including file changes. And updating a version identifier associated with the synchronized data item. When the domain data item or the item under consideration is modified to implement a portion of the synchronized data on the domain data item, at least some exemplary implementations of operation 330 also determine how the generated synchronized data should reflect the original receipt 37 200907720 Synchronize data, and perhaps not necessarily include information in the field data project. That is, changes made as part of the implementation of synchronized data on the domain data can only be seen on a particular endpoint and are not synchronized to its point. Conversely, synchronizing data from other endpoints may be data that was originally received from other sources (except for changes made locally after implementing the domain material). In some implementations, when data is synchronized on the domain data, the data recorded can be used to determine whether a particular local change should be generated in the synchronized data. The information in this record may also be used as part of the production of a data item, for example, in lieu of or in lieu of information relating to the achievement of a data item in the field as a synchronized item 3. For example, consider again that a file name is modified during implementation, and that the file has a file name that meets the needs of a particular file system. In this example, the field data item may be considered when generating a synchronized data item having a name that is different from the original received or stored profile of the synchronized material. If the different file name is changed by a user, process, or some other entity's domain data (the file itself), the change may require synchronization of other endpoints as part of the generated synchronized data item. However, when the profile change is implemented as part of the synchronized data item on the domain data item, the change may not be part of the synchronized data item generated. Conversely, for example, the original file name communicated in the area synchronization data can be used as part of updating the synchronization data item, including any other end points, including step by step. The actual situation file name of the project and a storage of the name of the case 38

200907720 Please refer to FIG. 4, which shows an exemplary embodiment of an exemplary embodiment in which an endpoint joins a synchronization relationship and includes functions for updating data in the domain data. The description of Figure 4 is related to the formula. However, it should be understood that the elements described with respect to Figure 4 are limited to use with elements described in relation to other figures. The exemplary figures in Figure 4 represent particular elements, but not all of them may be present, and in some implementations the elements may be present. In addition, for example, although an exemplary drawing illustrates a particular endpoint or portion of a computing device, one or more modules that should be closed to a particular endpoint can also be implemented by one or more or computing devices. And by connecting to any of the necessary components to connect to the endpoint of the exemplary description. The exemplary system 400 can include a synchronization endpoint 4 1 0, a 420, a synchronous data storage module 430, an implementation module 440 group N 442, a domain data storage module 450, and domain data N 452, and An input feed 422' inputs feeds N 424, 426, and an output feeds N 428. In general, in at least some implementations, the exemplary sync end is similar or identical to one of the endpoints A 1 1 0, end 1 or endpoint C 1 3 0 previously described with respect to FIG. The exemplary synchronous endpoint module includes some or all of the illustrated modules as implemented to allow the shared and synchronized data, synchronization on the domain data, and domain data generation synchronization data. In addition, in some implementation points, it can be implemented by a computing environment, which includes the following about 400 > its implementation of synchronization with other graphics is not out of the way, although some implementations, additional components are noted, there are other endpoints ^ Ά /X- VI II · ' V ·-- Synchronous module and implementation of the mode storage module output feed point 410 can be ^ B 120 > contains multiple parts to materialize, in the end, Figure 5

200907720 An exemplary computing environment. In at least some implementations, a synchronization module 420 can synchronize or transmit synchronized data between one or more other endpoints. A synchronization module can use a variety of communication mechanisms, including regional communication components of a particular computing device, one or more networks, or other communication components to allow for communication with other endpoints or computing devices and the like. In addition, a synchronization module can use any of a variety of synchronization techniques, protocols, and the like, and any of a variety of components to represent communication or transmission of synchronized data. In just one particular example, a synchronization module 420 can use techniques such as those described in the previously described S S E to synchronize information. In this implementation, the exemplary synchronization module may obtain one or more ports, including perhaps example sleeve input feed 422 and input feed N 424. In at least some implementations, an input feed can be represented using an XML file, similar to an RSS or Atom feed document. The exemplary output feed 426 and the output feed N 428 can also be represented. If there is a feed, the sync module can merge the changes represented by the feed to a data store. In some implementations, this data store can include storage represented by the exemplary synchronized data storage module 430. In some implementations, the operations 2 1 5 described in relation to the previous Figure 2 can be implemented by an exemplary synchronization module as part of the merge change represented by the feed. In an implementation using a technology similar to S S E, the synchronization module can merge the synchronization information by performing operations such as the S S E merge portion. In some implementations, when the synchronization data 40 Ο Ο 200907720 or domain data maintained by the synchronization endpoint 410 is changed, the synchronization group 420 can also generate a more feed to include a possible exemplary round-trip feed 426 or The output feeds each of the implementations in relation to the portion of the operation described in the previous FIG. 3, which can be used to update the output feed. As described above, the synchronization module 42 can use a synchronization. Data storage q to store synchronized data. The synchronized data storage module stores the synchronization data through any one of the methods or formats, and uses a SSE-like synchronization protocol in various ways of using multiple databases and one or more files. In the example, the synchronization module can store the actual feed file, and the upper piece includes a feed file similar to the input feed-forward feed 426. Send -',] in a file system, store it as a file, for example, in a library, or use any other data storage module to be synchronized 41_. ..., the same Fang I θ "% point 0 control, maintenance, or modification, for the "regional" data storage, but the data storage trend: 4 = · In case, the Beckham storage module can be used away from the synchronization Store information. In the + luxury start Φ j storage? In this implementation, the remote storage device - or multiple components are accessed. Using < an exemplary incense, 442) ^ . ^ implementation module (such as implementation module 440 ^ - 442) can achieve synchronization of data in the field 440 or the guest poor, added from the implementation or in a Cui, In the field of coarse b shell material. In the implementation of the synchronization of the data can be 5, step by step data to lead the trial, at least part of the package of other implementation orders, in the material modification (including the establishment and deletion). Synchronization on the field data New output N 428. It is implemented as a production. The F module 4 3 0 can be implemented in various ways. In the data storage 422 or the ϋ Η 或 or multiple statistic data stores, it can be recognized that the synchronization - the organization to implement the communication configuration module 情况 in the case, some implementations include the same or contain mapping 41

200907720 Synchronize data to one or more of the specific implementations in the implementation domain data, where "alternating" means that the same data in the domain data representation cannot be used in the synchronized data. The processing for synchronizing data on the field is described in more detail in the previous section 2. In addition, when the synchronization data is implemented on the domain data and the alternate method has been used, the implementation module also generates or updates the synchronization data after the domain data is changed. One such paradigm for synchronizing data generation is described in more detail in the previous related FIG. An implementation module (eg, (or perhaps) an exemplary implementation module 44 0 or a sexual implementation module 442) can operate in a variety of ways, depending on other specialities, depending on the synchronization data processed by the implementation module With the type or type of picking. For example, an implementation module can interpret and define a type of synchronization data, and can interact with a specific type of domain data. In some implementations, a domain data storage module exists on the domain data on which the synchronized data is implemented, such as an example. Sexual domain data storage 4500 or exemplary domain data storage module 4 5 2 . For example, in the case of synchronizing a directory and a file, the domain data storage module 4500 contains one or more file systems, and the domain data can contain the actual file. In this example, a "file system implementation module" can synchronize information such as file intermediate data and file content to create or modify one of the specific implementation systems of a domain data storage module. The actual file in multiple locations. A file system implementation module also includes logic, executable code or class substitution table. The data can be described in the example SJ; the imaginary domain special storage module data can be recorded and packaged. Like, 42

200907720 It can be used to confirm and take different actions when the synchronized data processed by the module should or must be modified to include valid domain data. As an example, an implementation module can confirm that the directory or file in the synchronized data has invalid or no name in a file system associated with the implementation module. In this case, the implementation module may also include logic or executable to take some action to resolve the problem or incompatibility, such as using an alternate name in the real domain material, and if the domain material is later Synchronization data that is synchronized with other endpoints may also be mapped back to the original name. In some implementations, more than one implementation module can exist and cause the same synchronized data to work. For example, when #using the same same material, for example (perhaps) when using the same feed with catalog and file information, more than one implementation module may exist and each implementation module may operate in the same place. For example, different implementation modules may exist to implement the synchronized data on the domain data in different ways. For example, an implementation module can record and archive synchronization information to a file and record using a particular type of file system. Another implementation module can implement (possibly the same) directory and file synchronization to use files and directories of different types of file systems. In another example, a file system may allow a specific set of characters in a name, another system may allow different sets of characters, and synchronized data communicated between endpoints may still support another set of characters. . In this example, different implementation groups may have the ability to generate domain data that meets those particular needs; and domain data limitations, which in this case are file systems, supported by the real module, and may be mapped or Fix this limitation. ϊ 档 档 档 档 档 档 档 档 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43

200907720 In some implementations, this design allows existing implementation modules to be changed without the need to synchronize data or other implementation module changes, and enables new implementation modules, perhaps supporting new endpoints or methods that represent synchronization information. It can be added without necessarily changing the synchronization data, the synchronization technique, or other endpoints. As mentioned above, in some implementations, it is possible for different endpoints to include different implementation modules that can accept and generate synchronization information that can be read and interpreted by each endpoint. In some implementations, different implementation modules that use the same synchronization material can operate on the same endpoint. In this example, a computer system can have different storage devices using different file systems. In this environment, different implementation modules for some computer systems can modify the domain data in different fields, perhaps files and directories, and use the same synchronized data. That is, the same synchronized data can result in two different sets of directories and files, one for each file system. Moreover, the changes made by one implementation module of a file system are not necessarily performed by another implementation module of another file system. In the same or other examples, an endpoint may have one or more other implementation modules that operate on the same directory and profile synchronization data, but modify different types of domain data (i.e., in addition to the actual files and directories). An example of a different type of domain data and corresponding implementation module can implement a module for one of the following capabilities: modifying a ZIP, or other compressed file, or having the ability to represent multiple files and possible directory classes in a single file. The file type of the structure. With this implementation module, implementing synchronization data can include establishing one or more ZIP archives that contain portions of the same synchronization data that can be communicated 44

200907720 directory and archive, and in some cases, can be used to modify non-contiguous and directory. Another example of a different type of domain data and implementation module can be an implementation module used by "net projection." In this environment, a web page interface containing, for example, one or more M T M L pages can be used to catalog and archive. In one example, an HTML page can display a cut of the file and allow a user to click on the file below one of the display links. While an implementation of the user interface may re-create directories and archives on a network server (and thus may be implemented using a file system group), another implementation may use an implementation module that may, for example, synchronize The data is implanted into a database, and then the HTMT is generated. In turn, the contents of the archive from the database are supplied. In this example, the asset may be considered to contain at least some of the materials established or modified by the implementation module. Although this implementation module performs synchronization data on behalf of directories and files, its essence cannot establish actual directories or files. It should also be noted again that while many of the previous examples have described both directory and file synchronization data, the elements of Figure 4 can also be used to synchronize, store, and implement various other types of data. Example Computing Environment Referring now to Figure 5, this figure and related discussion is intended to provide a brief and general description of a one-dimensional computing environment in which various techniques can be implemented. Although not required, the techniques described herein are at least in the general content of computer-executable instructions, for example, a control file can be accessed by a user for a node, and the first-only model is used. On the part of the device shown or modified, 45

200907720 A program module executed by a processor, personal computer, or other computing device (e.g., computing device 500 in FIG. 5). Generally, program modules include routines, programs, objects, components, interfaces, data structures, etc., which perform specific tasks, display specific resources, or implement specific abstract data types. The operations performed by the program modules have been described with the aid of one or more block diagrams and operational flowcharts. Those skilled in the art will be able to exemplify, block, and operate in the form of computer-executable instructions which may be embodied in a computer readable medium or in a plurality of forms. As used herein, a computer readable medium, any medium that stores or embodys encoded information that is accessible and understandable by a computer. Typical forms of computer readable media include (ie, both non-volatile and non-volatile memory, data storage devices, including and/or non-removable media, and communication media. Communication media may be embodied in a Computer information in a variable data signal, such as a carrier or other transmission mechanism, and including any information medium. The term "modulated data signal" means that a signal has one or more characteristics, or can be changed in this manner to The code is encoded in the signal. By way of example (and not limitation), the communication medium includes connected media, a wired network or direct wiring connection, and wireless media such as acoustic RF (radio frequency), infrared, and other wireless media. The computing device 500 depicted in the figures (in its most basic configuration: includes at least one processing unit 502 and memory 504. In some implementations, the computing device 500 can implement at least a portion of the endpoints such as those previously described in relation to FIG. 1, For example, the endpoint A 1 10, the endpoint B 12 0, etc. In the explicit use of the message, the previously described one may be a form of fat: In the sound, t), one of the same 46 Ο Ο 200907720 or other implementations, the calculation _ ^ Λ , the implementation of the synchronization end previously described with reference to Figure 4, the point 410 of at least the garden τ ^ • a β « μ In some implementations, the processing unit 502 can be a general purpose central processing unit (Cp.+, a central processing unit, such as various desktop computers, notes, etc.) Computer. Memory 504 can be inserted into i α ^ ώ ^

4 is a volatility (such as RAM ROM, flash memory, etc.) P zen (such as M. ^ W if ^ ^ some combinations, depending on the correct configuration and type of the device. 506 袅 - The most basic configuration is shown in Figure 5 by dashed line 506. In addition, functionality is taken into account. For example, computing device 5 〇 0 also has additional features and / or non-removable), including Π θ is It can also include additional storage (removable state says 5 Figure 2: Ϊ is limited to) magnetic or optical disc or tape. In this figure, the removable storage 5() teaching team 510 is explained. "νν...π u The computing device 5〇〇 may also include - ^ W ^ w 5〇 η ^ or a communication connection 512 to enable the computing device 500 to communicate with other devices, devices, and services. Various communication components or. Ten different devices One or more connections of the different devices, including, for example, endpoint connections as previously described with reference to the sequel. In this case, the connection may include a connection to the communication component, which was previously described with reference to Figure 1. The 50-inch device can also have - or a plurality of input devices 5 14, for example, a shadow makeup for A, a set (similar to a camera or scanner), a keyboard, a mouse, a stylus pen, Voices are wheeled into hard devices, including microphone arrays, touch input devices, and the like. One or more outputs A device 5 16 (e.g., a display, a pad, a printer, etc.) may also be included in the computing device 5 . Those skilled in the art will appreciate that the techniques described herein can be implemented in computing devices other than computing device 500 illustrated in FIG. Example 47

200907720 As (and without limitation), the techniques described herein can also be implemented in handheld devices, including mobile phones and PDAs, multi-processor systems, microprocessor-based or programmable consumer electronics, and network individuals. Computers, mini computers, mainframe computers and the like. Each of these computing devices is described in detail or differently by the system of Figure 5. The techniques described herein can also be implemented in a distributed computing environment where operations are performed by remote processing devices and are linked through a communications network. In a distributed computing environment, the program module can be located both in the zone and the remote device. Although the description herein is embodied in software, it is further contemplated that the garlic described herein can be implemented in various combinations of all or part of t =, 弍 soft, hard and/or fused. Although some specific implementations of the methods and systems have been described in the drawings and described above, it should be understood that the methods and systems shown and described are not limited to the specific implementations described, but many different reconfigurations are possible. Modifications and substitutions do not detract from the spirit of the publication and definition of the scope of the patent application below. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates an exemplary system in which data can be synchronized and shared. Figure 2 illustrates an exemplary generalized operational flow, including the different operations performed when merging the synchronized data to an endpoint (including synchronizing data on the domain data). Figure 3 illustrates an exemplary generalized operational flow including the different operations that may be performed when generating synchronized data for communication with other endpoints (including the use of previously implemented domain data to produce synchronized data). Figure 4 illustrates an exemplary system showing one embodiment of an endpoint joining a synchronization relationship and including functionality for implementing synchronized data to domain data. Figure 5 illustrates an exemplary computer device that can implement the different techniques described herein. Ο [Main component symbol description] 100 system I i W ^rfij II 5 communication component 1 2 0 endpoint 1 3 0 endpoint 400 system 4 1 0 synchronization endpoint 420 synchronization module 422 input feed 424 input feed Ν 426 Output feed 428 output feed Ν 430 synchronization data storage module 4 40 implementation module 442 implementation module & Ν 450 domain data storage module 452 domain data storage module Ν 500 computing device 502 processing unit 504 memory Body 5 0 6 basic configuration 5 0 8 removable storage 5 1 0 non-removable storage 5 1 2 communication connection 514 input device 516 output device 49

Claims (1)

200907720 X. Patent application scope: 1. A method comprising the steps of: obtaining synchronization data, comprising a synchronization data item; merging the synchronization data item with a second synchronization data item, and data in a field On the project, the second synchronized data project is implemented, including: Modifying the data item in the field by using information related to the second synchronized data item, thereby causing a change in the data item in the field without changing the second synchronized data item; The change is not merged into a third synchronized data item associated with the second synchronized data item; and a description of how the field data item is modified. 2. The method of claim 1, wherein the synchronization data further comprises a feed represented by SSE. 3. The method of claim 1, wherein the implementing step resolves an inconsistency caused by a character, wherein the characters are supported in the synchronized material but are not supported in the domain data item, And the modification step further includes replacing a unsupported character in the data item in the field with a supported character in the domain data item. 4. The method of claim 1, wherein the second synchronized data item comprises: file system information related to a file system component, and the domain data item is a second file system component. 5. The method of claim 4, wherein the implementing step 50 200907720 addresses an inconsistency caused by one of: a duplicate file system component; a cycle comprising a third file system component, And a fourth file system component; and an isolated file system component. 6. The method of claim 1, wherein the modifying step further comprises: The field data item in a location is found, the location being different from the location of a synchronized data item specified in the second synchronized data item. 7. The method of claim 1, wherein the storing step further comprises: recording, by a form data structure, an identification code associated with the second synchronized data item; and related to the identification code, A description of how the field data is modified. 8. The method of claim 1, wherein the merging step further comprises the step of: by evaluating whether the synchronized data item and the second synchronized data item are associated with the same identification code, Determining whether the synchronized data item is related to the second synchronized data item; selecting one of the synchronized data item and the second synchronized data item by comparing the synchronized data item with the second synchronized data item a winning project and a failed project to determine whether the second synchronized data item should be further when the synchronized data item is related to the second synchronized data item; and when the second synchronized data item should be When updating, at least information related to a project data element is updated to update the second synchronized data item, wherein the project data element is related to the second synchronized data item. 9. The method of claim 8, wherein the comparing step further comprises at least one of the following comparisons: comparing a synchronized data item version attribute with a second synchronized data item version attribute, wherein a larger one The version value is related to the winning item; comparing a synchronized data item modification time attribute with a second synchronization data item modification time attribute, wherein a larger modification time value is related to the winning item; and comparing one The synchronized data item modifying entity and a second synchronized data item modifying entity, wherein a larger modified entity value is associated with the winning item. 10. The method of claim 1, further comprising: using a description of how to modify the data item in the field to generate a generated synchronized data item, wherein the generated synchronized data item includes at least a portion of the information It is used as part of the implementation of the second synchronized data item on the data item in the field, and the generated synchronized data item does not include the change in the data item in the field. 1 1. The method of claim 1, further comprising: 52 200907720 providing a notice to an entity notifying that the collar has been modified, wherein the modification includes at least some modification information about how to repair the item . 1 2 · A method comprising the steps of: identifying a field data item; determining whether the data item in the field has been previously modified to implement a synchronized data item on the data item; the data item in the field has been previously modified to be in the target When the part of the synchronized data item is implemented, the description of the data item in the field is generated to generate a second peer, and the second synchronized data item includes the same item, which is provided by the synchronized data item, and The project is used as part of the implementation of the same purpose in the data project in the field. 1 3 • The method described in claim 12, wherein the item is a feed represented by SSE. 14. The method of claim 12, wherein at least a portion of the data is not by the method of the field of information 1 5 · the method of claim 12, wherein the item is a file system component, And the second synchronization includes file system information about the file system component. 1 6. If the method described in item 12 of the patent application is applied, another step: before the production operation, update the data field data item in the field to change the field of resources in the field; and how to modify the field data item The data item step data item synchronization data step data item is synchronized and the synchronization item is stored. The field data package includes the following steps to include new information in the package 2009 200920; and new information included in the second synchronized data project. The method of claim 16, wherein the second synchronized data item further comprises a second feed item comprising a feed to the synchronized data component and a project data component, and Include: modifying project data related to the project data component such that the project material includes at least a portion of the new information; Incrementing a version value associated with the feed to the synchronized data element; establishing a new update element associated with the feed synchronization data element, and further relating to at least one of: a previous recent modification time and a previous The recently modified entity; and updating at least one of: a recently modified time history attribute associated with the feed synchronization data element, and a recently modified entity history attribute associated with the feed synchronization data element. A system comprising: a synchronized data storage module configured to store a feed item; a domain data storage module configured to store a data item; Configuring to: modify the domain data item by using information related to the feed item to implement the feed item on the field data item without changing the feed item; and a synchronization module Configured as: 54 200907720 merges a second feed item with the feed item, wherein the second feed item includes a feed to the synchronized data component and a project data component, and is associated with a feed; and 19. 20. How to use the field data item to modify a description of one of the parts of the feed item in the field data item to generate a generated feed item related to a generated feed and including a second Feeding the synchronization data element and a second item data element, wherein the second item data element includes at least a portion of the information, which is used as part of implementing the feed item on the domain data item. The system of claim 18, wherein the second domain data storage module is configured to store a second domain data item; and a second implementation module is configured to : modifying the second domain data item by using the second information about the feed item to implement the feed item on the second field data item without changing the feed item, and the The revision of the second-domain data project is different from the data project in this field. The system of claim 18, further comprising: modifying the implementation module by modifying the domain data item differently, so that the implementation module implements the feed item on the domain data item, There is no need to change the feed item. 55