MXPA05007092A - Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system. - Google Patents

Abstract

Several embodiments of the present invention employ synchronization adapters for synchronizing information between "WinFS" and non-"WinFS" data sources (Figure 36, 3622/3666). Examples of adapters include an adapter that synchronizes address book information between a "WinFS" contacts folder and a non-WinFS mailbox (Figure 36, 3642). In these instances, adapter developers might use the "WinFS" synchronization core services API described herein for accessing services provided by the "WinFS" (Figure 36, 3612) synchronization platform in order to develop schema transformation code between the "WinFS" (Figure 36, 3612) schema and the non-"WinFS" data source schema (Figure 36, 3624). Additionally, the adapter developer provides protocol support for communicating changes with the non-"WinFS" data source. A synchronization adapter (Figure 36, 3662) is invoked and controlled by using the synchronization controller API and reports progress and errors using this API (Figure 36, 3652).

Description

SYSTEMS AND METHODS TO PROVIDE SYNCHRONIZATION SERVICE FOR MANUFACTURABLE INFORMATION UNITS THROUGH A HARDWARE / SOFTWARE INTERFACE SYSTEM CROSS REFERENCE The present application claims priority over US Patent Application No. 10 / 692,515 (Legal File No. MSFT-2844), filed on October 24, 2004, entitled "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR INFORMATION UNITS HANDLED BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "; US Patent Application No. 10 / 646,575 (Legal File No. MSFT-2733), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR MAKING INTERFACE OF APPLICATION PROGRAMS WITH A STORAGE PLATFORM BASED ON THE ITEMS"; and International Application No. PCT / US03 / 26150 (Legal File No. 2777), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR MAKING APPLICATION PROGRAM INTERFACES WITH A PARTY-BASED STORAGE PLATFORM"; whose descriptions are incorporated in their entirety to the present description as a reference.

This application is related to the subject matter of the inventions described in the following generally assigned applications, the contents of which are incorporated in their entirety in the present application (and partially summarized in the present application for reasons of convenience): US Patent Application No 10 / 647,058 (Legal File No. MSFT-1748), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR REPRESENTING MANAGEABLE INFORMATION UNITS FOR AN INTERFACE SYSTEM HARDWARE / SOFTWARE BUT INDEPENDENT OF PHYSICAL REPRESENTATION "; US Patent Application No. 10 / 646,941 (Legal File No. MSFT-1749), filed on August 21, 2003, entitled" SYSTEMS AND METHODS TO SEPARATE MANAGEABLE INFORMATION UNITS BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM YOUR PHYSICAL ORGANIZATION "; US Patent Application No. 10 / 646,940 (Legal File No. MSFT-1750), filed on August 21, 2003, entitled" SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASIC SCHEME FOR INFORMATION ORGANIZATION UNITS HANDLED BY A HARDWARE / SOFTWARE INTERFACE SYSTEM; US Patent Application No. 10 / 646,632 (Legal File No. MSFT-1751), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR IMPLEMENTING A NUCLEUS SCHEME TO PROVIDE A HIGH-LEVEL STRUCTURE FOR ORGANIZATIONAL UNITS OF INFORMATION HANDLED BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "; US Patent Application No. 10 / 646,645 (Legal File No. MSFT-1752), filed on August 21, 2003, entitled "SYSTEMS AND METHOD FOR REPRESENTING RELATIONS BETWEEN INFORMATION HANDLING UNITS FOR A HARDWARE / SOFTWARE INTERFACE SYSTEM "; US Patent Application No. 10 / 646,646 (Legal File No. MSFT-2734), filed on August 21, 2003, entitled "STORAGE PLATFORM FOR THE ORGANIZATION, SEARCH AND PARTICIPATION OF DATA"; US Patent Application No. 10 / 646,580 (Legal File No. MSFT-2735), filed on August 21, 2003, entitled "SYSTEMS AND METHODS FOR THE DESIGN OF DATA IN A STORAGE PLATFORM BASED ON THE ITEMS"; US Patent Application No. 10 / 692,779 (Legal File No. MSFT-2829), filed on October 24, 2003, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGE DIAGRAM FOR INFORMATION ORGANIZATION UNITS MANAGED BY A SYSTEM OF I HARDWARE / SOFTWARE TERAPE "; US Patent Application No. 10 / 692,508 (Legal File No. MSFT-2845), filed on October 24, 2003, entitled "SYSTEMS AND METHODS FOR PROVIDING RELATED AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR INFORMATION UNITS MANAGEABLE BY A SYSTEM OF I NTERPHASE OF HARDWARE / SOFTWARE "; US Patent Application No. 10 / 693,362 (Legal File No. MSFT-2846), filed on October 24, 2003, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF AN ORGANIZATIONAL SCHEME FOR INFORMATION UNITS MANAGEABLE BY AN INTERFACE SYSTEM OF HARDWARE / SOFTWARE "; and US Patent Application No. 10 / 693,574 (Legal File No. MSFT-2847), filed on October 24, 2003, entitled "SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR MANUFACTURABLE INFORMATION UNITS FOR A HARDWARE INTERFACE SYSTEM /SOFTWARE". Field of the Invention The present invention relates generally to the field of information storage and retrieval, and more particularly, to an active storage platform for organizing, searching and sharing different types of data in a computerized system. Background of the Invention The individual capacity of the disks has been growing by approximately seventy percent (70%) per year during the last decade. Moore's law accurately predicted the tremendous gains in the power of the central processing unit (CPU) that has occurred over the years. Wired and wireless technologies have provided tremendous connection capacity and bandwidth. Assuming that current trends continue, within several years, average laptops will own approximately one terabyte (TB) of storage and contain millions of files and 500 gigabyte (GB) drives will become commonplace. Consumers generally use their computers for the communication and organization of personal information, either in a traditional personal information management (PIM) style, or media such as music or digital photographs. The amount of digital content and the ability to store simple bytes has increased tremendously; However, the methods available to consumers to organize and unify these data have remained calm. Knowledge workers spend huge amounts of their time managing and sharing information and some studies estimate that knowledge workers spend 15% to 25% of their time in activities related to non-productive information. Other studies estimate that a typical knowledge worker spends approximately 2.5 hours a day searching for information. The developers and information technology (IT) departments invest significant amounts of time and money in building their own data warehouses for common storage abstractions to represent things such as people, places, times and events. This not only results in duplicate work, but also creates islands of common data without mechanisms for the common search or participation of that data. Only if you consider how many address books can exist today on a computer running on a Microsoft Windows operating system. Many applications, such as email clients and personal financial programs, store individual address files and there is not much participation among the free address data applications that individually maintain such programs. Therefore, a financial program (such as Microsoft Money) does not share addresses for debtors with addresses maintained in an email contact folder (such as Microsoft Outlook). Undoubtedly, many users have multiple devices and must logically synchronize their personal data with each other, and by a wide variety of additional sources, including cell phones for commercial services, such as MSN and AOL; however, the collaboration of shared documents is achieved largely by attaching documents to email messages - that is, in a manual and inefficient way. One reason for this lack of collaboration is that traditional methods for the organization of computer system information have focused on the use of directory-based systems and file folders ("file systems") to organize pluralities of files in directory folder hierarchies based on an abstraction of the physical organization of the storage medium used to store the files. The Multics operating system, developed during the 1960s, can be credited as a pioneer in the use of files, folders and directories to manage data units that can be stored at the operating system level. Specifically, the Multics system used for symbolic addresses within a file hierarchy (thus introducing the idea of a file path), where the physical addresses of the files were not transparent to the user (applications and end users) . This file system was not at all concerned with the file format of an individual file and the relationships between the files was considered irrelevant at the operating system level (ie, unlike the location of the files within the hierarchy). ). Since the arrival of the Multics system, storage data has been organized into files, folders and directories at the operating system level. These files generally include the file hierarchy itself (the "directory"), incorporated into a special file maintained by the file system. This directory, at the same time, maintains a list of entries corresponding to all the other files in the directory and the location of the nodes of those files in the hierarchy (which we refer to in this application as the folders). Such has been the condition of the technique for approximately forty years. However, although a reasonable representation of the information that resides in the physical storage system of the computer is provided, a filing system is, however, an abstraction of that physical storage system and, therefore, the use of the Files requires a level of lack of direction (interpretation) between what the user manipulates (units that have context, characteristics and relationships with other units) and what the operating system provides (files, folders and directories). Therefore, users (applications and / or end users) have no choice, but force units of information within the file structure even when doing so is inefficient, inconsistent or otherwise undesirable. In addition, existing file systems know little about the data structure stored in individual files and because of this, most of the information remains closed to files that can only be accessed (and are extensible) to the applications that wrote them. Consequently, this lack of a schematic description of the information and the mechanisms to manage the information lead to the creation of data silos with little data sharing between the individual silos. For example, many personal computer (PC) users have more than five different stores that contain information about the people they interact with at some level - for example, Outlook Contacts, online account addresses, Windows Address Book, Quicken Payees, and great lists of instant messaging (IM) - because the organization of the files presents an important challenge for these users of the PC. Because most of the existing file systems use the metaphor of the nested folder to organize files and folders, as the number of files increases, the effort required to maintain an organizational scheme that is flexible and efficient becomes increasingly overwhelming . In such situations, it would be very useful to have multiple classifications in a single file; however, using permanent or temporary links in existing file systems is a bit problematic and difficult to maintain. Unsuccessful attempts have been made in the past to solve the disadvantages of archival systems. Some of these previous attempts have included the use of a memory that can be directed to the content to provide a mechanism through which the data could be accessed through the content, rather than through the physical address. However, these efforts have approved not being successful because, while the memory that can be directed to the content has proved useful for small-scale use by devices such as flash drives and memory management units, the use in Large scale devices, such as physical storage media has not yet been possible for a variety of reasons and therefore, such a solution simply does not exist. Other attempts have been made using object-oriented database systems (OODB), but these attempts, while characterizing strong database features and good non-file representations, were not effective in handling file representations, and they could not duplicate the speed, efficiency and simplicity of the file and folder based on the hierarchical structure at the level of the hardware / software interface system. Other efforts, such as those that have tried to use SmallTalk (and other derivatives), proved to be quite effective for handling files and non-file representations, but lacked the database features needed to use efficient the relationships that exist between the different data files, and in this way, the overall efficiency of such systems was unacceptable. Still other attempts to use the BeOS (and other operating system searches) proved inadequate in the handling of non-archive representations - the same central disadvantage of traditional file systems - despite being able to adequately represent the archives while some necessary features of the database are provided. The technology of the database in another area in the art in which similar challenges exist. For example, although the traditional database model has been a great commercial success, in actual independence the software vendors (ISV) generally exercise a small portion of the functionality available in the database program products of the software. relationship (such as, Microsoft SQL Server). Instead, most of the interaction of the application of said product is in the form of a simple "get" and "paste". Although there are a number of readily apparent reasons for this - such as being on platforms or database agnostics - a key reason that is generally not noticed is that the database does not necessarily provide the exact abstractions a vendor really needs. of a major commercial application. For example, although the real world has the notion of "heading", such as "customer" or "order" (along with an embedded order "line items" such as items and themselves), relationship databases only they speak in terms of tables and rows. Accordingly, although the application may wish to have consistency, closure, security and / or detonator aspects at the item level (to name a few), the database generally provides those features only at a table / row level. Although this may work well if each item comes to map to a single row in a table in the database, in the case of an order with multiple line items there may be reasons why a line item usually forms a map for the multiple tables and, when this is the case, the simple relationship database system does not provide the correct abstractions. Therefore, an application must build the logic in the database header to provide these basic abstractions. In other words, the basic relationship model does not provide a sufficient platform for data storage in which higher level applications can be easily developed, because the basic relationship model requires a level of directional mismatch between the application and the storage system - where the semantic structure of the data could only be visible in the application in some specific objects. Although some database vendors are building higher level functionality in their products - such as providing object relationship capabilities, new organizational models, and the like - none have yet provided the kind of extensive solution needed, where a completely extensive solution is one, which provides both the abstractions of the useful data model (such as "Start", "Extensions", "Relationships" and so on), for the abstractions of a useful field (such as "People", Locations "," Events ", etc.) In view of the previous shortcomings in database technologies and existing database storage, there is a need for a new storage platform that provides improved capacity to organize, search and share all types of data in a computer system - a storage platform that extends and expands the data platform more beyond existing file systems and database systems, and that it is designed to be the storehouse for all types of data. The present invention, together with the related inventions incorporated herein by reference, satisfy this need. Summary of the Invention The following summary provides an overview of various aspects of the invention described in the context of the related inventions incorporated by reference above (the "related inventions"). This summary is not intended to provide an exhaustive description of all the important aspects of the present invention, nor to define the scope of the invention. Instead, this summary is intended to serve as an introduction to the detailed description and the following figures. The present invention, as well as the related inventions, collectively refer to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file systems and database systems, and is designed to be the storehouse of all types of data including data. structured, unstructured, or semi-structured. The storage platform of the present invention comprises a data warehouse implemented in a database machine. The database machine comprises a database machine relating to object relationship extensions. The data warehouse implements a data model that supports the organization, search, participation, synchronization and security of the data. Specific types of data are described in schemas and the platform provides a mechanism to extend the set of schemas to define new data types (essentially subtypes of the basic types provided by the schema). A synchronization capability facilitates the participation of data between users or systems. Similar capabilities of the archiving systems are provided, so that they allow the interoperability of the data stores with the existing file systems but without the limitation of such traditional filing systems. A change tracking mechanism provides the ability to track changes to the data store. The storage platform further comprises a set of application program interfaces that enables applications to access all of the above capabilities of the storage platform and access the data described in the schemes. The data model implemented by the data warehouse defines data storage units in terms of items, elements and relationships. A game is a unit of data that can be stored in a data warehouse and can comprise one or more elements and relationships. An element is an example of a type that comprises one or more fields (also referred to in this description as a property). A relationship is a link between two parties. (As used in the present description, these and other specific terms may be capitalized in order to differentiate them from other terms used in close proximity.; however, there is no intention whatsoever to distinguish between a heading written in capital letters, for example "Item", and the same term when it is not capitalized, that is, "item", and should not be presumed or implied said distinction). The computation system further comprises a plurality of Matches where each Matched constitutes a separate information unit that can be stored which can be manipulated by a hardware / software interface system; a plurality of Match Folders, which constitute a structure for the organization of said Matches and a hardware / software interface system for manipulating a plurality of Matches and in which each Match belongs to at least one Match Folder and may belong to more than one Match Folder. A departure in some of the property values of the items can be computed dynamically, as opposed to being derived from a persistent store. In other words, the hardware / software interface system does not require that the item be stored and certain operations are supported, such as the ability to list the set of current items or the ability to retrieve a particular item due to its identifier (the which is described more fully in the sections describing the application programming interface or API) of the storage platform - for example, a departure can be the current location of a cell phone or the temperature reading or a temperature sensor . The hardware / software interface system may manipulate a plurality of items and may further comprise interconnected items by a plurality of relations handled by a hardware / software interface system.

A hardware / software interface system for the computer system also comprises a kernel scheme to define a set of kernel items, which it understands and can directly process the hardware / software interface system in a previously determined manner or that it can be predicted. To manipulate a plurality of Matches the computer system interconnects the Matches with a plurality of Relationships and handles said Relationships at the level of the hardware / software interface system. The storage platform API provides databases for each batch, extension of items and the relationship defined in the set of storage platform schemas. In addition, the application programming interface provides a set of system classes that define a common set of behavior for the data classes and that, together with the data classes, provide the basic programming model for the API storage platform. The API storage platform provides a simplified request model that allows application programmers to formulate questions based on different item properties in the data warehouse, in a way that isolates the application programmer from the language details of the application. the question on the underlying database machine. The API storage platform also collects changes to a game made by an application program and then organizes them into the correct updates required by the database machine (or any type of storage machine), on which the application is implemented. data warehouse. This makes it possible for application programmers to make changes to a game in memory, while leaving the complexity of data storage updates to the API. Through these fundamentals and common storage schematics, the storage platform to the present invention enables a more efficient application development for consumers, knowledge workers and businesses. It offers a rich and extensible application programming interface that not only makes available the capabilities inherent in the data model, but also understands and extends existing file systems and access methods to the databases of data. As part of the structure forming an arc of the interrelated inventions (described in detail in Section II of the Detailed Description), the present invention is specifically focused on the Synchronization APIs (described in detail in Section III of the Detailed Description). ). Some other features and advantages of the present invention will be apparent from the following detailed description of the invention and the accompanying drawings. Brief Description of the Drawings The above summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the accompanying drawings. For the purpose of illustrating the invention, exemplary embodiments of the various aspects of the present invention are shown in the drawings; however, the present invention is not limited to the specific methods and instrumentalities described. In the drawings: Figure 1 is a block diagram representing a computer system in which aspects of the present invention can be incorporated; Figure 2 is a block diagram illustrating a computer system divided into three groups of components: the hardware component, the hardware / software interface system component and the application program component; Figure 2A illustrates a hierarchical structure based on a traditional tree for files grouped into folders in a directory on a file-based operating system; Figure 3 is a block diagram illustrating a storage platform; Figure 4 illustrates the structural relationship between the Games, Folder of Games and Categories; Figure 5A is a block diagram illustrating the structure of a Departure; Figure 5B is a block diagram illustrating the complex types of properties of a heading of Figure 5A; Figure 5C is a block diagram illustrating the "Location" item where its complex types are further described (in an explicit list); Figure 6A illustrates a Departure of a Subtype of Departure found in the Basic Scheme; Figure 6B is a block diagram illustrating the subtype of the heading of Figure 6a, where its inherited types are in an explicit list (in addition to its immediate properties); Figure 7 is a block diagram illustrating the Basic Scheme that includes its two types of high-level class, Part and Basic Property and the additional Basic Scheme types derived therefrom; Figure 8A is a block diagram illustrating the Items in the Core Scheme; Figure 8B is a block diagram illustrating the types of properties in the Core Scheme; Figure 9 is a block diagram illustrating a Match Folder and its member Parties and the Relationships that interconnect it between the File Folder and its member Parties; Figure 10 is a block diagram illustrating a Category (which, again, is a Party itself) and its members of the Parties and the Relationships that interconnect them between the Category and its members of the Parties; Figure 11 is a diagram illustrating a type of reference hierarchy of the database model of the storage platform; Figure 12 is a diagram illustrating how the relationships are classified; Figure 13 is a diagram illustrating a notification mechanism; Figure 14 is a diagram illustrating an example in which two transactions are both crossing a new record within the same B-Tree; Figure 15 illustrates the process of detecting data change; Figure 16 illustrates a sample directory tree; Figure 17 shows an example in which an existing folder of a file system based on the directory is moved inside the data warehouse of the storage platform; Figure 18 illustrates the concept of Containment Folders; Figure 19 illustrates the basic architecture of the storage platform API; Figure 20 schematically represents the different components of the stack of the API of the storage platform; Fig. 21A is an illustrative representation of a sample Contact Set scheme; Figure 21B is an illustrative representation of the Elements for the scheme of Contact Items of Figure 21A; Figure 22 illustrates the runtime system of the storage platform API; Figure 23 illustrates the execution of an operation "FindAII"; Figure 24 illustrates the process by which the storage platform API classes are generated from the Storage Platform Schema; Figure 25 illustrates the schema on which the File API is based; Figure 26 is a diagram illustrating an access mask format used for data security purposes; Figure 27 (parts a, b and c) illustrates a new security region protected in an identical manner being separated from an existing security region; Figure 28 is a diagram illustrating the concept of a heading search vision; Fig. 29 is a diagram illustrating a hierarchy of Example games; Figure 30A illustrates an interface Interface 1 as a conduit through which the first and second segments of the code communicate; Figure 30B illustrates an interface comprising the interface objects 11 and 12 which make it possible for the first and second code elements of a system to be communicated by means of the; Figure 31A illustrates the way in which the function is provided by the Interfasel which can be subdivided to convert the interface communications in the multiple interfaces InterfacelA, Interface 1B, Interface 1C; Figure 31B illustrates how the provided interface 11 operates which can be subdivided into multiple interfaces 11a, 11b, 11c; Figure 32A illustrates a scenario in which the accuracy of the meaningless parameters can be ignored or replaced by an arbitrary parameter; Figure 32B illustrates a scenario in which an interface is replaced by a substitute interface that is defined to ignore or add parameters to an interface; Figure 33A illustrates a scenario in which the 1st and 2nd Code Segments are merged into a module that contains both; Figure 33B illustrates a scenario in which part of, or an entire interface can be written online at another interface to form a merged interface; Figure 34A illustrates how one or more parts of the middle part of the program can convert the communications of the first interface to adapt them to one or more different interfaces; Figure 34B illustrates how a segment code with an interface for receiving communications from an interface can be introduced, but transmitting the functionality to the second and third interfaces; Figure 35A illustrates how a fair-to-time collector (JIT) could convert communications from one code segment to another code segment; Figure 35B illustrates the JIT method of dynamic rewriting of one or more interfaces that can be applied to dynamically factor or otherwise alter said interface; Figure 36 illustrates three examples of the common data store and the components to synchronize them; and Figure 37 illustrates an embodiment of the present invention that presumes a simple adapter that does not know the condition in which a condition is calculated or its associated metadata are exchanged. Detailed Description of the Invention INDEX I. INTRODUCTION 31 A. EXAMPLE COMPUTATION ENVIRONMENT 31 B. STORAGE BASED ON A TRADITIONAL ARCHIVE 41 II. WINFS STORAGE PLATFORM FOR THE ORGANIZATION, SEARCH AND PARTICIPATION OF DATA 44 A. GLOSSARY 44 B. GENERAL REVIEW OF THE STORAGE PLATFORM 46 C. THE DATA MODEL 50 1. Games 53 2. Identification of Matches 61 3. Folders of Matches and Categories 63 4. Schemes 67 a) Basic Schematic 67 b) Scheme of the Core 68 . Relations 72 a) Declaration of Relationship 74 b) Relationship of Possession 77 c) Relations of Encrustation 79 d) Relationships of Reference 80 e) Rules and Restrictions 82 f) Ordering of Relationships 83 6. Capacity of Extension 94 a) Extensions of Items 96 b) Extension of types NestedElement 103 D. DATABASE MACHINE 105 1. Implementation of the Data Warehouse Using UDTs 108 2. Mapping of Games 110 3. Extension Mapping 112 4. Mapping of the Nesting Element 113 5. Identity of the Object 113 6. Denomination of the SQL Object 114 7. Name of Column 115 8. Search Visions 116 a) Item 118 (1) Master Item Search View 118 (2) Search Vision of Classified Items 119 b) Game Extensions 120 (1) Master Extension Search Vision 120 (2) Typically Extended Search Vision 121 c) Nested Elements 121 d) Relationships 122 (1) Master Relationship Search Vision 122 (2) Search for Specific Object Relationships 122 e) -123- ualizations 123 shifting of Security Changes and Emissions 125 a) Tracking Changes 125 (1) Tracking Change in "Master Search" Visions 126 (2) Tracking Changes in "Typified" Search Visions 128 b) Security Issue 129 (1) Safety Issuance of Items 129 (2) Security Issuance of Extensions 130 (3) Security Issuance of Relationships 130 (4) Deletion of Security Emission 131 Help PIs and Functions 131 a) Function [System. Storage] .Getltem 132 b) Function [System. Storage] .GetExtension 132 c) Function [System. Storage] .GetRelationship 132 12. Metadata 132 a) Metadata of Scheme 132 b) Specific Object Metadata 132 E. SECURITY 133 F. TRACKING OF NOTIFICATIONS AND CHANGES 134 G. I NTEROPERABILITY OF THE TRADITIONAL ARCHIVE SYSTEM 136 H. STORAGE PLATFORM API 138 III. SYNCHRONIZATION API A. SYNCHRONIZATION VIEW 153 1. Storage Synchronization - Platform to Storage-Platform 155 a) Synchronization Control Applications (Sync) 156 b) Schema Annotations 157 c) Synchronization Configuration 159 (1) Community Folder - Mapping 161 (2) Profiles 163 (3) Programs 165 d) Conflict Management 165 (1) Conflict Detection 166 (a) Conflicts Based on Knowledge 166 (b) Conflicts Based - on Restrictions 167 (2) Conflict Processing 167 (a) Automatic Conflict Resolution 168 (b) Conflict Record 170 (c) Conflict Inspection and Resolution 171 (d) Replica Convergence and Propagation of Conflict Solutions 171 2. Synchronization for non-storage platform data warehouses 173 a) Synchronization service 174 (1) Enumeration of changes 174 (2) Application of Changes 177 (3) Resolution of conflicts 178 b) Implementation of the adapter 178 3. Security 179 4. Handling capacity 180 B. GENERAL REVIEW - SYNCHRONIZATION API 181 1. General terminology 182 2. Main concepts of the synchronization API 186 C. SYNCHRONIZATION API SERVICES 190 1. Enumeration of changes 190 2. Application of changes 192 3. Sample code 194 4. API synchronization methods 199 D. ADDITIONAL ASPECTS OF THE SYNCHRONIZATION SCHEME 202 IV. CONCLUSION 205 1. INTRODUCTION The subject matter of the present invention is described with specificity to cover the requirements of the bylaws. However, the description itself is not intended to limit the scope of this patent. Instead, the inventors have contemplated that the subject matter claimed may also be incorporated in other ways, to include steps or combinations of different steps similar to those described herein, in conjunction with other current or future technologies. Furthermore, although the term "step" can be used in the present description to indicate different elements of methods employed, the term should not be interpreted as implying any particular order among several steps described herein, at least and except when the order of The individual steps are described explicitly. A. EXAMPLE COMPUTATION ENVIRONMENT Numerous embodiments of the present invention can be executed on a computer. Figure 1 and the following description are intended to provide a brief general description of a suitable computing environment in which the present invention can be implemented. Although not required, various aspects of the present invention may be described in the general context of computer executable instructions, such as program modules, being executed by a computer, such as a client workstation or server. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. Furthermore, the present invention can be practiced with other configurations of the computer system, including portable devices, multiple processor systems, microprocessors based on electronic components that can be programmed by the consumer, network PCs, minicomputers, computer systems and the like. The present invention can also be practiced in distributed computing environments where tasks are performed by remote processing apparatuses that are linked through a communications network. In a distributed computing environment, the program modules can be located in both local and remote memory storage devices. As shown in Figure 1, a general purpose example computing system includes a conventional personal computer 20 or the like which includes a processing unit 21, a system memory 22, a system bus 23 that connects various components of the system including the system memory to the processing unit 21. The system bus 23 can be any of several types of bus structures, including, a memory bus or memory controller, a peripheral bus, a local bus that uses any of a variety of bus architectures. The system memory includes a read-only memory, (ROM) 24, and a random access memory (RAM) 25. A basic input / output system 26 (BIOS), which contains the basic routines to help transfer the information between the elements within the personal computer, such as during startup, is stored in the ROM memory 24. The personal computer 20 may further include a hard disk drive 27 for reading and writing to the hard disk, not shown, a unit of magnetic disk 28 for reading and writing on a removable magnetic disk 29, an optical disk unit 30 for reading and writing on a removable optical disk 31, such as a CD ROM or other optical media. The hard disk drive 27, the magnetic disk drive 28 and the optical disk unit 30 are connected to the system bus 23 via the interface of the hard disk drive 32, a magnetic disk drive interface 33 and a optical disk unit interface 34, respectively. The units and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the personal computer 20. Although the example environment described employs a hard disk drive , those skilled in the art should appreciate that a removable magnetic disk 29 and a removable optical disk 21 and other types of computer readable media which can store data and that can be accessed by computer, such as cassettes magnetic, instant memory cards, digital video discs, Bernoulli cartridges, random access memories (RAMs), read only memory (ROMs) and the like, can also be used in the example operating environment. Similarly, the example environment may also include many types of monitoring devices such as heat and safety sensors and fire alarm systems and other sources of information. A program module number can be stored on the hard disk, the magnetic disk 29, the optical disk 31, and the RAM 24 or RAM 25, including an operating system 35, one or more application programs 36, other modules thereof program 37 and program data 38. A user can enter commands and information into the personal computer 20 through the input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) can include a microphone, a lever, a game pad, a satellite disk, a scanner, or the like. These and other input devices are often connected to the processing unit 21 via a serial port 46, which is connected to the system bus, but which can be connected by other interfaces, such as a parallel port. , port for games or a universal serial bus (USB). A monitor 47 or other type of display device may be connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, the personal computer generally includes other peripheral output devices (not shown) ), such as speakers and printers. The example system of Figure 1 also includes a central adapter 55, a small computer system interface bus 56, an external storage device 62 connected to the SCSI bus 56. The personal computer 20 can operate in a network environment using logical connections to one or more remote computers, such as the remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a similar device or other common network nodes and generally includes many or all the elements described above related to the personal computer 20, although only a memory storage device 50 is illustrated in FIG. 1. The logical connections illustrated in FIG. 1 include a local area network (LAN) 51 and a network. Wide area (WAN) 52. Such network environments are commonplace in offices, corporate computing networks, the intranet and the Internet. When used in a LAN environment, the personal computer 20 is connected to the LAN 51 through an interface or network adapter 53. When used in a WAN network environment, the personal computer 20 generally includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet. The modem 54 which can be internal or external, is connected to the system bus 23 by means of the interface of the serial port 46. In a network environment, the program modules illustrated in relation to the personal computer 20, or portions thereof, can be stored in the device of remote memory storage. It should be appreciated that the network connections shown are exemplary, that other means can also be used to establish a communication link between the computers. As illustrated in the block diagram of Figure 2, a computer system 200 can be simply divided into three groups of components: the hardware component 202, the component of the hardware / software interface system 204 and the hardware component. application program program 206 (which we also refer to as the "user component" or "software component" in certain contexts in the present description). In various embodiments of a computer system 200 and referring again to FIG. 1, the hardware component 202 may comprise the central processing unit (CPU) 21, the memory (both ROM 24 and RAM 25), the input system / basic output (BIOS) 26 and various input / output (l / O) devices, such as a keyboard 40, a mouse 42, a monitor 47 and / or a printer (not shown), among other things. The hardware component 202 comprises the basic physical infrastructure for the computer system 200. The application program component 206 comprises several software programs including but not limited to compilers, database systems, word processors, commercial programs, video games and so on. Application programs provide the means by which computer resources are used to solve problems, provide solutions and process data for various users (machines, other computer systems and / or end users). In the component of the hardware / software interface system 204 it comprises (and in some embodiments, it can consist only of an operating system comprising the same, in most specific objects, a shell and a kernel.) An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware.The component of the hardware / software interface system 204 may also comprise a virtual machine manager (VMM), an operating time of Common Language (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent or other software components instead of or in addition to the operating system in a computer system The purpose of the hardware / software interface system is provide an environment in which a user can run the application programs.The goal of any hardware / software interface system is to make use the computer system conveniently, as well as use the computer hardware in an efficient manner. The hardware / software interface system is usually loaded into a computer system at startup and then manages all application programs in a computer system. Application programs interact with the hardware / software interface system by requesting services through the interface of the application program (API). Some application programs make it possible for end users to interact with the hardware / software interface system through a user interface such as a command language or a graphical user interface (GUI). A hardware / software interface system traditionally performs a variety of services for applications. In a multi-task hardware / software interface system where multiple programs can be executed at the same time, the hardware / software interface system determines which applications should be executed in what order and how much time should be allowed for each application before switching to another application for a shift. The hardware / software interface system also manages the internal memory share between multiple applications and handles the input and output to and from the attached hardware devices, such as hard drives, printers and dial ports. The hardware / software interface system also sends messages to each application (and in certain specific objects, to the end user), with respect to the operating conditions and any errors that may have occurred. The hardware / software interface system can also download the administration of batch tasks (for example, printing), so that by starting an application it is released from this job and can resume other processing and / or operations. In computers that can provide parallel processing, a hardware / software interface system also manages the division of a program, so that it operates on more than one processor at a time. The shell of the hardware / software interface system (here referred to simply as "the shell"), is an interactive end-user interface for a hardware / software interface system. (We can also refer to a shell as a "command interpreter" or an operating system, such as an "operating system shell"). The shell is the outer layer of the hardware / software interface system that can be accessed directly through the application programs and / or end users. In contrast to the shell, a kernel is a more internal layer of the hardware / software interface systems that directly interacts with the hardware components. Although it is envisaged that numerous embodiments of the present invention are particularly well suited for computerized systems, nothing in this document is intended to limit the present invention to such embodiments. On the contrary, as used in the present description, the term "computer system" is intended to comprise any and all devices with the capacity to store and process information and / or capacity to use the stored information to control the behavior or execution of the information. device itself, regardless of whether said apparatuses are electronic, mechanical, logical or virtual in nature. B. TRADITIONAL FILE-BASED STORAGE In most computers today, "archives" are units of information that can be stored, which can include the hardware / software interface system, as well as application programs, data sets and so on. In all modem hardware / software interface systems (Windows, Unix, Linux, Mac OS, virtual machine systems and so on), the files are the basic separate information units (which can be stored and retrieved) (for example, example, data, programs and so on), which can be manipulated by the hardware / software interface system. File groups are usually organized in "folders". In the Microsoft Windows or Macintosh OS system, and other hardware / software interface systems, a folder is a collection of files that can be retrieved, moved, or manipulated in other ways as simple units of information. These folders, at the same time, are organized in a hierarchical adaptation based on a tree called a "directory" (explained in more detail below). In certain other hardware / software interface systems, such as DOS, z / OS, and most Unix-based operating systems, the terms "directory" and / or "folder" are interchangeable, and the first computer systems are interchangeable. Apple (that is, the Apple Me), used the term "catalog" instead of directory; however, as used in the present description, all of these terms are considered to be synonymous and interchangeable and are intended to further include all other equivalent terms and references for hierarchical information storage structures and their file folders and components. Traditionally, a directory (aka a folder directory), is a hierarchical structure based on a tree where the files are grouped into folders and a folder, at the same time, is adapted according to the relative locations of the node comprising the tree of directories. For example, as illustrated in Figure 2A, a basic file system folder based on the DOS operating system (or "root directory") 212 may comprise a plurality of folders 214, and each of them may comprise also traditional folders (in the form of "subfolders" of that particular folder) 216 and each of these can also comprise additional folders 218 ad infinitum. Each of these folders can have one or more files 220 although, at the hardware / software interface level, the individual files of a folder have nothing in common with others, only the location in the hierarchy of the tree. Therefore, it is not surprising that this method of organizing files in the folder hierarchy indirectly reflects the physical organization of the typical storage media used to store these files (ie hard disks, floppy disks, CD-ROMs, etc.) . In addition to the above, each folder is a container for subfolders and their files - that is, each folder has subfolders and files. For example, when a folder is deleted by the hardware / software interface system, subfolders and files in the folder are also deleted (which in the case of each subfolder, also includes its own subfolders and files repeatedly). In a similar way, each file is generally owned by a single folder and although the file can be copied and the copy located in a different folder, a copy of a file itself is a separate and distinct unit that does not have an address connection with the file. original (for example, the changes in the original file are not mirror-monitored in the copy of the file at the hardware / software interface system level.) In this respect, the files and folders are, therefore, characteristically of nature "physical" because the folders are treated as physical containers and the files are treated as separate physical elements, inside these containers .. WINFS STORAGE PLATFORM, TO ORGANIZE, SEARCH AND SHARE DATA The present invention, in combination with the related inventions incorporated by reference as will be explained below, refers to a storage platform for organizing, searching and share data The storage platform of the present invention extends and extends the data platform beyond the types of existing file system and data systems that were explained above, is designed to be the store of all types of data, including a new form of data called Matches. A. GLOSSARY As used in the present description and the claims, the following terms have the following meaning: • A "Departure" is a unit of information that can be stored which can have access to a system of the hardware interface / software that, unlike a simple file, is an object that has a basic set of properties that are commonly supported on all objects exposed to an end user by the shell of the hardware / software interface system. Parties also have properties and relationships that are commonly supported in all types of "Items" including features that allow new properties and relationships to be introduced (and which will be explained in more detail later). An "operating system" (OS), is a special program that acts as an intermediary between application programs and computer hardware. An operating system comprises, in most of the specific objects, a shell and a kernel. A "hardware / software interface system" is software or a combination of hardware and software, which serves as the interface between the underlying hardware components of a computer system and the applications running in the computer system. A hardware / software interface system generally comprises (and in some embodiments, may consist only of one operating system). A hardware / software interface system may also comprise a virtual machine manager (VMM), a common language operation time (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent, or other software components instead of or in addition to the operating system in a computer system. The purpose of a hardware / software interface system is to provide an environment in which a user can execute application programs. The goal of any hardware / software interface system is to make the computer system convenient for using it, as well as computing hardware in an efficient manner. B. GENERAL REVIEW OF THE STORAGE PLATFORM Referring to FIG. 3, a storage platform 300 comprises a data store 302 implemented in a database machine 314. In one embodiment, a database machine comprises a database machine. database of relation with extensions of relation of objects. In one embodiment, the relationship database machine 314 comprises a Microsoft SQL Server relational database machine. The data store 302 implements a data model 304 that supports the organization, search, participation, synchronization, and data security. Specific types of data are described in the schemes, such as schemes 340, and storage platform 300 provides tools 346 for displaying those schemes on the screen as well as for extending those schemes, as will be described in more detail below. A change tracking mechanism 306 implemented within the data store 302 provides the ability to track changes to the data store. The data store 302 also provides security capabilities 308 and promotion / degradation capability 310, both of which will be discussed in more detail below. The data store 302 also provides application programming interface sets 312 to expose the capacities of the data store 302 to other components of the storage platform and application programs (e.g., application programs 350a, 350b and 350c) who use the storage platform. The storage platform of the present invention further comprises the application programming interfaces (APIs) 322, which make it possible for application programs, such as application programs 350a, 350b and 350c, to access all of the above capabilities of the storage platform, and access the data described in the schemes. The API 322 storage platform can be used by application programs and in combination with other APIs, such as API 324 OLE DB and API 326 Microsoft Windows Win 32. Storage platform 300 of the present invention can provide a variety of services 328 to application programs, including a synchronization service 330 that facilitates the participation of data between users or systems. For example, the synchronization service 330 can enable interoperability with other data stores 340 that have the same format as the data store 302, as well as access the data stores 342 that have different formats. The storage platform 300 also provides file system capabilities that allow the interoperability of the data warehouse 302 with the existing file systems, such as the Windows NTFS file system 318. In at least some embodiments, the storage platform 320 may also provide application programs with additional capabilities to enable the data to be activated and to enable interaction with other systems. These capabilities can be incorporated in the form of additional services 328, such as the Info Agent 334 service and a notification service 332, as well as in the form of other utilities 336. In at least some embodiments, the storage platform is incorporated in, or forms an integral part of, the hardware / software interface system of a computer system. For example, and without limitation, the storage platform of the present invention can be incorporated into, or form an integral part of, an operating system, a virtual machine administrator (VMM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent. Through its common storage principles and the schematized data, the storage platform of the present invention enables more efficient application developments for consumers, knowledge workers and businesses. It offers a rich and expandable programming surface area, which not only makes available the inherent capabilities in the data model, but also understands and extends the methods of accessing the existing database and file systems . In the following description and several of the figures, we can refer to the storage platform 300 of the present invention as "WinFS". However, the use of this name to refer to the storage form is only for reasons of convenience of the description and is not intended to be limiting in any way. C. THE DATA MODEL The data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, search, participation, synchronization and security of data residing in the warehouse. In the data model of the present invention, a "Start" is the fundamental unit of the storage information. The data model provides a mechanism to declare Matches and extensions of Matches and to establish the relationships between the Matches and to organize Matches into Folders of Matches into Categories, as will be described more fully below. The data model depends on two primitive mechanisms, Types and Relationships. The Types are structures which provide a format which governs the form of an example of the Type. The format is expressed as a set of ordered property. A Property is a name for a value or set of values of a certain Type, for example, a type USPostal Address could have the properties street, city, postal code, state, in which street, city and state are a Type of chain and the zip code is an Int32 Type. The street can be multi-valued (for example, with a set of values) that allow the address to have more than one value for the Street property. The system defines certain primitive systems that can be used in the construction of other Types - these include, strings, binary Boolean Int16, Int32, Int34, single, double, Byte, date time, decimals and GUID. The Properties of a Type can be defined using any of the Types of primitives (or with some restrictions that will be observed later) of any of the built types. For example, a Location Type could be defined to have a Coordinate of Properties and Direction, where the Address Property is of the USPostal Address Type, as described above. Properties can also be required or optional. Relationships can be declared and represent a mapping between sets of specific objects of two types. For example, there may be a declared relationship between the Type of Person and the Type of Location, called Lives At which defines which people live in which locations. The Relationship has a name, two endpoints, that is, a source endpoint and an objective endpoint. Relationships can also have an ordered set of properties. Both the Source and Objective endpoints have a Name and a Type. For example, the Lives At relationship has a source called a Person-type Occupant, and a named goal that lives from the Type location and also has and also has the StartDate and EndDate properties that indicate the period of time by which the occupant lived in that location. accommodation. Note that a person can live in multiple shelters over time, and a shelter can have multiple occupants so that the most likely place to place the StartDate and EndDate information is in the relationship itself. Relationships define a mapping between specific objects that are constrained by the types provided as the endpoint types. For example, the LivesAt relationship can not be a relationship in which an automobile is the occupant because the automobile is not a person. The data model does not allow the definition of a subtype-subtype subtype-supertype between the types. The subtype-supertype relationship also known as the BaseType relationship is defined in such a way that if Type A is a BaseType for Type B, it must be the case that each specific object of B is also a specific object of A. Another way of expressing this is that each specific object adapts to B must also be adapted to A. If, for example, A has a property name of a Type string while B has an age of ownership of Type Int16, it follows that any specific object of B must have, both a name and an age. The type hierarchy can be viewed as a tree with a single supertype at the root. The branches of the root provide the first level subtypes, the branches at this level provide the subtypes of the second level and so on, up to the subtypes of most of the leaves, which themselves have no subtypes. The tree is not restricted to being of a uniform depth, but it can not contain any cycles. A certain type can have zero or many subtypes, and zero or a supertype. A given specific object can be adapted to at most one type along with the supertypes of the type. To put it another way, for a specific object determined at any level of the tree the specific object must be adapted for the most part to a subtype at that level. A type is said to be Abstract and type-specific objects must also have a specific object of a type subtype. 1. Items A Item is an information unit that can be stored that, unlike a simple file, is an object that has a basic set of properties that are commonly supported on all objects exposed to an end user or application program for the storage platform. Parties also have properties and relationships that are commonly supported in all types of items that include features that allow new properties and relationships to be introduced, as will be explained later. Items are the objects for common operations such as copy, delete, move, open, print, backup, restore, copy and so on. The Items are the units that can be stored and retrieved, and all forms of information that can be stored manipulated by the storage platform, exist in the form of Items, Item properties or Relations between Items, and each of which it will be explained in more detail later. The Games aim to represent easily understandable and real-world data units, such as contacts, people, services, locations, documents (of all different types) and so on. Figure 5 A is a block diagram illustrating the structure of a Start. The unqualified name of the Party is "location". The qualified name of the Start is "Core.Location" which indicates that this Start structure is defined as a specific type of Start in the kernel scheme (the kernel scheme will be explained in more detail later).

The Location Match has a plurality of properties including EAdress, MetrpolitanRegion, Neighborhood, and Postal Addresses. The specific type of property for each is indicated immediately after the name of the property and is separated from the name of the property by: (":"). To the right of the type name, the number of values allowed for that property type is indicated in parentheses ("[]") where an asterisk ("*") to the right of the colon (":") indicates an unspecified and / or unlimited number ("many") a "1" to the right of the colon indicates that there may be a value at most. A zero ("0") to the left of the two points indicates that the property is optional (which may have no value at all). A "1" to the left of the colon indicates that there must be at least one value (property is required). Neighborhood and Metropoltan Region both are of the "nvarchar" type (or equivalent) which is a previously defined type of data or "simple type" (and here indicated by the lack of capital letters). However, EAddresses and Postal Addresses are properties of defined types or "complex types" (as indicated in this document by means of capital letters) of the EAddress and Postal Address types, respectively. A complex type is the type that is derived from one or more types of simple data and / or other complex types. The complex types for the properties of a game also constitute (nested elements) since the details of the complex type are nested in an immediate game to define their properties and the information that belongs to that complex type is maintained with the Game that has these properties (within the limit of the Parties, as will be explained in more detail later). These typing concepts are well known and can be readily appreciated by those skilled in the art. Figure 5B is a block diagram illustrating a complex property type Postal Address and EAddress. The Postal Address property type defines that a Departure of the Postal Address property type can be expected to have City values, zero or one CountryCode values, zero or one, MailStop values, and any number (from zero to many) of PostalAddressTypes and so on. In this way, the form of the data for a particular property in a Departure is defined in this way. The EAddress property is defined in a similar way to the one shown. Although optionally used in this application, another means to represent the complex types in the Location Match, is to draw the Start with individual properties of each type of complex that is in the list. Figure 5C is a block diagram illustrating the Location Match where the complex types are further described. However, it should be understood that this alternative representation of the Location Match in this Figure 5C, is for the exact Match illustrated in Figure 5 A. The storage platform of the present invention also allows subtyping where a type of property can be a subtype of another (where one type of property inherits the properties of another, of another type of property of origin). In a similar but different way to the properties and subtypes of ownership, the items inherently represent their own types of departure that can be subtyped. In other words, the storage platform in various embodiments of the present invention allows a Match to be a subtype of another Item (where Item 1 inherits the properties of another, Original Item). In addition, in the different modalities of the present invention, each Start is a subtype of a type of "Departure" Game which is the first and type of fundamental Item found in the basic scheme (the basic scheme will also be described in more detail more ahead). Figure 6 A illustrates a Departure, the Location Match in this specific object, as it is a subtype of the type of Match found in the basic scheme. In this drawing, the arrow indicates that the Location Match (like all other Items), is a subtype of the Type of Departure. The type of Item is a fundamental Item from which the other Items are derived, and has a number of important properties, such as Itemld and different timestamps, and therefore, defines the Standard Properties of all the Items of a system operative In the present figure, these Part type properties are inherited by location, and therefore, they become properties of the location. Another way to represent the properties in the Location Part inherited from another type of Start is to draw the location with the individual properties of each type of property of the Origin Item of the list contained here. Figure 6B is a block diagram illustrating the Location Match where its additionally described inherited types are described in addition to their immediate properties. It should be noted and understood that this Item is the same as illustrated in Figure 5A, although in the current figure the location is illustrated with all its properties, both immediate - shown in both of these figures, and Figure 5 A as inherited - shown in this figure but not in Figure 5 A (while in Figure 5 A we refer to these properties by showing them with an arrow of this Location Item that is a subtype of the type of Item). The Games are independent objects; therefore, if you delete a Match, all Immediate Items and inherited properties are also deleted. In a similar way, when a Game is retrieved, what is received is the Game and all its immediate and inherited properties (including the information pertaining to its complex property types). Certain embodiments of the present invention may make it possible for a subset of properties to be requested when a specific Match is retrieved; however, the default options for many of these modalities is to provide the Start, with all its immediate and inherited properties when they are retrieved. In addition, the properties of the items can be extended by adding new properties to the existing properties of that type of items. These "extensions" are therefore good faith properties of the Game, and subtypes of the Game type can automatically include the extension of properties. The "limit" of the Item is represented by its properties (including complex property types, extensions, and so on). A limit of the Start also represents the limit of an operation performed in a Part such as copy, delete, move, create and so on. For example, in various embodiments of the present invention, when a Game is copied, everything within that limit of the Game is also copied. For each Game, the limit includes the following: • The Type of Game of the Game and if the Game is a subtype of another Game (as it is the case in several modalities of the present invention, in which all the Games are derived from a single Item and Type of Item in the Basic Scheme), any applicable subtype information (that is, the information that belongs to the Origin Type of Item). If the original Item being copied is a subtype of another Item, the copy may also be a subtype of that same Item. • The properties and extensions of the complex type of the Parties, if any. If the original Part has properties of complex types (natural or extended), the copy can also have the same complex types. • The records of Items in the "property relations", that is, the List itself of the Game of any other Items (the "Objective Items") are owned by the current Item (the "Owner Item"). This is particularly important with respect to the Match Folders, which will be explained in more detail later, and the rule stated later that all the Matches must belong to at least one Match Folder. Furthermore, with respect to the Embedded Sets - which are described more fully below - a Embedded part is considered to be part of the Part in which it is embedded for operations such as copy, delete and the like. 2. Identification of Matches Matches are uniquely identified within the global game space with an ItemID. The Base type. Item defines an ItemID field of type GUID that stores the identity of the Game. A Match must have exactly one identity in the data store 302.

A reference of the items in a data structure containing information to locate and identify a Item. In the data model, an abstract type called from which all types of Reference Item are derived is defined. The ItemReference type defines a virtual method called Resolver. The Solve method solves the ItemReference and returns a Start. This method is ignored by the specific subtypes of the ItemReference, which implements a function that retrieves a given Part as a reference. The Resolver method is invoked as part of the API 322 storage platform. The ItemIDReference is a subtype of the ItemReference. Defines a Locator and an ItemID field. The Locator field names (that is, identifies) a starting field. This is processed by a localizer resolution method that can resolve the Locator value for a starting field. The ItemID field is a type of ItemID. The ItemPathReference is a specialization of the ItemReference that defines a Locator, and a Path field. The Locator field identifies a starting field. It is processed by a locator resolution method that can resolve the Locator value for a starting field. The Path field contains a (relative) path in the name of the storage platform space that is at the root of a starting field provided by the Locator. This type of reference can not be used in an adjustment operation. The reference must usually be solved through a path resolution process. The Resolver method of the AP1322 storage platform provides this functionality. The reference forms explained above are represented through the hierarchy of the reference type illustrated in Figure 11. Additional reference types that are inherited from these types can be defined in the schemes. They can be used in a relationship statement as the type of the target field. 3. Items and Categories Folders As will be explained in more detail later, the groups of Matches can be organized into special Items called Party Folders (which should not be confused with file folders). Unlike most file systems, however, a Game may belong to more than one Game Folder, so that when a Game is accessed in a Game Folder and revised, this revised Game may have Access directly from another Game Folder. In essence, although access to a Game can occur from different Game Folders, what is actually being accessed is indeed the same Game. However, the Match Folder does not necessarily have all of its Member Parties, or may simply co-own Items in conjunction with other folders, so that the removal of a Match Folder does not necessarily result in the elimination of a Match. However, in several embodiments of the present invention, a Match must belong to at least one Match Folder so that if the Match Folder alone for a particular Match is eliminated then, for some modes, the Match is automatically eliminated or, in alternative modes, the Game automatically becomes a member of a Default Game Folder (that is, a Game Folder can be "Deleted" in a conceptually similar way to the folders named in a similar way used in different systems based on files and folders). As will also be explained in more detail later, Items must also belong to Categories based on the common characteristics described, such as (a) a Type of Item (or Types), (b) an immediate or inherited specific property (or properties), or (c) a specific value (or values) corresponding to a Start property. For example, a Game that comprises specific properties for personal contact information could automatically belong to a Contact Category and any Game that has contact information properties, in a similar way it would automatically belong to this Category. In a similar way, any Game that has a location property with a value of "New York City", could automatically belong to the NewYorkCity Category. The Categories are conceptually different from the Match Folders because, while the Match Folders may comprise Items that are not interrelated (that is, without common features described), each Item of a Category has a common type, property or value ( a "similarity") that is described for that Category, and this similarity that forms the basis for its relationship with and among the other Category Items. In addition, while a membership of Paridas in a particular Folder is not mandatory based on any particular aspect of that Match, for certain modalities, all Matches that have a similarity categorically related to a Category could automatically become a member of the Category in the system level of the hardware / software interface. Conceptually, the Categories can also be considered to be Virtual Match Folders whose membership is based on the results of a specific request (such as in the context of a database) and the Items that meet these conditions of this request (defined by the similarities of the Category) would thus comprise a Category membership. Figure 4 illustrates the structural relationship between the Games, Game Folders and Categories. A plurality of Items 402, 404, 406, 408, 410, 412, 414, 416, 418 and 420 are members of several Match Folders 422, 424, 426, 428 and 430. Some Items may belong to more than one Match Folder. Items, that is, Item 402 belongs to the Folders of Items 422 and 424. Some Items, for example, Items 402, 404, 406, 408, 410 and 412 are also members of one or more Categories 432, 434 and 436 , while other times, for example, Items 414, 416, 418 and 420 may belong to any Category (although this is highly unlikely in certain modalities where the possession of any property automatically implies membership in a Category, and therefore both, a Game would have to be completely without characteristics in order that it was not a member of any category in that modality). In contrast to the hierarchical structure of the folders, both the Categories and the Match Folders have similar structures for the directed graphs, as shown here. In any case, the Matches, Match Folders and Categories are all Matches (independently of the different Types of Matches). In contrast to the archives, folders and directories, the Matches, Folders of Matches and Categories of the present invention are not characteristically "physical" because they do not have the conceptual equivalents of the physical containers, and therefore, can Exist Parties in more than one of these locations. The ability of the Matches to exist in more than one Match Folder location, as well as being organized into Categories provides an enhanced and enriched degree of data manipulation and storage structure capabilities at the same level. hardware / software, beyond what is currently available in the art. 4. Schemes a) Basic Scheme In order to provide the universal principle for the creation and use of the Items, various modalities of the storage platform of the present invention comprise a Basic Scheme that establishes a conceptual system for creating and organizing Items and properties. The Basic Scheme defines certain special types of Items and properties and the characteristics of these special fundamental types from which additional subtypes can be derived. The system of this Basic Scheme allows a programmer to distinguish conceptually the Items (or their respective types) of the properties (and their respective types). In addition, the Basic Scheme establishes the foundations of the set of properties that may be possessed as all the Items (and their corresponding Type of Item) are derived from this fundamental Item in the Basic Scheme (or its corresponding Type of Item). As illustrated in Figure 7 and with respect to various embodiments of the present invention, the Basic Scheme defines three types of upper level; Departure, Extension and Base of Property. As shown, the Start Type is defined by the properties of this fundamental "Start" Item Type. In contrast, the property of the top-level type "PropertyBase" has no previously defined properties, and is only the anchor from which all types of properties are derived and through which all derivative property types are interrelated (being derivatives commonly of a single type of property). The type of Extension properties, defines that Part comprises the extensions as well as the identification to distinguish one extension of the other, since a Departure can have multiple extensions. The ItemFolder is a subtype of the type of Item that, in addition to the inherited properties of the Item, is characterized by a Relationship to establish links for its members (if any), while IdentityKey and Property are subtypes of the PropertyBase. The CategoryRef, at the same time, it is a subtype of IdentityKey. b) Kernel Scheme Various embodiments of the storage platform of the present invention further comprise a Kernel Scheme that provides a conceptual system for the type of higher level Matches. Figure 8A is a block diagram illustrating the Items in the Core Scheme, and Figure 8B is a block diagram illustrating the types of properties in the Core Scheme. The distinction made between files with different extensions (* .com, * .exe, * .bat, * .sys, etc.). and other such criteria in systems based on folders and files are analogous to the function of the Kernel Scheme. In the hardware / software interface system based on the Items, the Core Scheme defines a set of types of Core Items that, directly (by Type of Item) or indirectly (by Subtype of Item), characterize all the Items in one or more types of Core Scheme Items which understand the hardware / software interface system based on the Items and can process directly in a previously determined and predictable manner. The predefined game types reflect the most common items in the hardware / software interface system based on the games and, therefore, a level of efficiency is gained from the understanding of the hardware / software interface system based on the Items of these previously defined types of Game that comprise the Core Scheme. In certain modalities, the Kernel Scheme can not be extended - that is, additional types of Matches can not be directly subtyped directly from the Start type in the Basic Scheme, except for the specific types of previously defined Derived Matches that are part of the Scheme of the Nucleus. By avoiding extensions to the Kernel Scheme (ie, avoiding the addition of new Matches to the Kernel Scheme), the storage platform commands the use of Kernel Scheme Scheme types, since each type of Subsequent Matched is necessarily a subtype of the type of the Nuclear Scheme Item. This structure allows a reasonable degree of flexibility to define the additional game types while also retaining the benefits of having a previously determined set of kernel game types. For different embodiments of the present invention, and with reference to Figure 8A, the specific Party types supported by the Core Scheme may include one or more of the following: • Categories: Matches of this Type of Item (and derived subtypes) of the same) represent valid Categories in the hardware / software interface system based on the Items. • Basic Products: Items that are valuable things that can be identified. • Devices: Items that have a logical structure that supports information processing capabilities.

• Documents: Items with a content that is not interpreted by the hardware / software interface system based on the Items, but instead is interpreted by an application program corresponding to the type of document. • Events: Items that record certain occurrences in the environment. • Locations: Items that represent physical locations (for example, geographic locations). • Messages: Communication items between two or more main ones (defined below). • Main: Items that have at least a definitely probable identity apart from any Itemld (ie, the identification of a person, organization, group, possession, authority, service, etc.). • Manifestations: Items that have special information regarding the environment that includes, without limitation, policies, subscriptions, credentials, and so on. In a similar manner and referring to Figure 8B, the specific property types supported by the Core Scheme may include one or more of the following: • Certificates (derived from the fundamental PropertyBase type in the Basic Scheme) • Identity Keys Main (derived from the IdentityKey type in the Basic Scheme) • Postal Address (derived from the type of Property in the Basic Scheme) • Rich Text (derived from the type of Property in the Basic Scheme) • EAddress Electronic Address (derived from the type of Property in the Basic Scheme) • IdentitySecurityPackage (derived from the type of Relationship in the Basic Scheme) • RoleOccupancy (derived from the type of Relationship in the Basic Scheme) • BasicPresence (derived from the type of Relationship in the Basic Scheme) These Items and Properties are further described by their respective properties set forth in Figures 8A and 8B. 5. Relationships Relationships are binary relationships in which one Part is designated as the source and the other Part as the target. The source item and the target item are related by the relation. The Source item generally controls the lifetime of the relationship. That is, when the source item is eliminated, the relation between the items is also eliminated. Relationships are classified into: Content and Reference Relationships. Content relationships control the lifetime of the target Parties, while the reference relationships do not provide any semantics of management of the time of life. Figure 12 illustrates the way in which the relationships are classified. The types of content relationship are classified additionally, in Possession and Embedding relationships. When all possession relationships for a Game are eliminated, the Game is eliminated. The possession relationship controls the lifetime of the target through the reference account mechanism. Embedding relationships make it possible to design the Compound Items and can be considered as exclusive possession relationships. A game can be an objective of one or more of the possession relationships, but a game can be the goal of exactly an inlay relationship. A Game that is an objective of an inlay relationship can not be an objective of any other possession or encrustation relationship. The reference relationships do not control the lifetime of the target Parties. They may be hanging - the target game may not exist. The reference relationships can be used to design references in the Matches anywhere in the namespace of the Global Match (for example, including remote data stores). The recovery of a game does not automatically recover its relationships. The applications must explicitly request the relationships of a Game. In addition, the modification of a relation does not modify the source item or the objective, in a similar way, adding a relation does not affect the source / objective item, a) Declaration of Relationship Explicit relationship types are defined with the following elements: • A relationship name is specified in the Name attribute. • Type of relationship, one of the following: Possession, Embedding, Reference. This is specified in the Type attribute. • Final points of source and objective. Each endpoint specifies a name and the type of the Reference Item. • Source end point field, is generally the ItemID of the type (not declared), and must reference a Start in the same data store as the specific object of the relationship. • For the Possession and Embedding relationships, the end point field of the objective must be of the ItemlDReference type and must be the one that we should refer to as a Departure in the same warehouse as the specific object of the relation. For the Reference relations, the endpoint of the objective can be of the ItemReference type and can refer to the Items in other data stores of the storage platform. • Optionally, one or more fields of the scale type or PropertyBase can be declared. These fields may contain data associated with the relationship. • The specific objects of the relationship are stored in the global relations table. • Each specific object of the relationship is uniquely identified by the combination (ItemID, ID of the relationship). The relationship ID is unique within a given source ItemID for all source relationships in a given match regardless of its type. The source item is the owner of the relation. Although a Party designated as the owner controls the life of the relationship, the relationship itself is separated from the Matches to which it relates. The API 322 storage platform provides mechanisms to expose relationships associated with a Start. Here is an example of a relationship statement: <; Name of Relationship = "Employment" B a seType = "Refere nce" > < Source Name = "Employee" ltemType = "Contact.Person" / > < Objective Name = "Employer" ltemType = "Contact.Organization" Reference Type = "ltemlDReference" / > < Property Name = "StartDate" Type = "the storage platform Types.DateTime'7> <Property Name =" EndDate "Type =" the storage platform Types.DateTime "/ <> Property = "Office" Type = "the Types.DateTime storage platform'7 > < / Relationship > This is an example of a Reference relationship. The relationship can not be created if the Party of the person referred to by the source reference does not exist. Also, if the Person Match is eliminated, the specific objects of relationship between the person and the organization are eliminated. However, if the Organization Item is deleted, the relationship is not deleted and is hanging. b) Possession Relationship Possession relationships are used to design the reference account based on the administration of the time of life of the target Parties. A Game can be a source endpoint for zero or more relations for the Games. A Game that is not an embedded Game can be an objective if it supports one or more relationships. The reference type of the final target type must be ItemlDReference and must refer to a Start in the same store as the specific object of the relationship. Possession relationships must enforce the management of the lifetime of the target end point. The creation of the relationship of possession and the Game that is the objective is an atomic operation. The additional specific objects of possession relationships can be created so that they are directed to the objective of the same Game. When the last specific object of the possession relationship is eliminated with a Game named as an objective end point, the Target Game is also eliminated. The types of Endpoint Items specified in the relationship statement will generally be enforced when a specific object of the relationship is created. The types of Endpoint Items can not be changed after the relationship is established.

Possession relationships play a key role in forming the name space of the game. They contain the property "Name" that defines the name of the game ^ objective related to the source game. This relative name is unique for all possession relationships that are originated from a particular item. The ordered list of these relative names that starts from the Root Game to a specific Part, forms the complete name of the Part. Possession relationships form a directed acyclic graph (DAG). When a possession relationship is created, the system makes sure that a cycle has not been created, thus ensuring that the name space of the Match forms a DAG. Although the possession relationship controls the lifetime of the target Item, it does not control the operational consistency of the target Endpoint item. The target party is operationally independent of the party that owns it through a possession relationship. The Copy, Move, Backup and other operations in a Match that is a source of a possession relationship do not affect the Item that is an objective of the same relationship - for example, that the backup of a Folder Item does not support automatically all the Games in the folder (the objectives of the FolderMember relationship).

The following is an example of the possession relationship: < Relationship Name = "FolderMembers" BaseType = "Holding" > < Name of the Source = "Folder" ltemType = "Base.Folder'7> <Objective Name =" ltem "ltemType =" Base. Item "Reference Type =" item I DReference "/ < / Relation> The FolderMembers relationship makes possible the concept of a Folder as a generic collection of Items, c) Encrustation Relationships Engraving relationships design the concept of the exclusive control of the lifetime of an objective Game. They make possible the concept of the composite games. The creation of an embedding relationship and the Part that is an objective is an atomic operation. A Departure can originate from zero or more embedding relationships. However, a Match can be an objective of one and only one embedding relationship. A Match that is an objective of an embedding relationship can not be an objective of a possession relationship. The target endpoint reference type must be an ItemIDReference and must refer to a Start from the same data store as a specific object in the relationship.

The types of Endpoint Items specified in the relationship statement will generally be enforced when a specific object of the relationship is created. The types of Endpoint Items can not be changed after the relationship is established. Embedding relationships control the operational consistency of the target endpoint. For example, the signaling operation of a game can include the serialization of all the embedding relationships that originate from that Game, as well as all its objectives; by copying a Start, all the Embedded Items are also copied. The following is an example statement: < Relationship Name = "ArchiveMembers" BaseType = "Embedding" > < Name of the Source = "Archive" ltemType = "Zip.Archive" / > < Objective Name = "Member" ltemType = "Base Item" Reference Type = "ltemlDReference" / > < Property Name = "ZipSize" Type = "Types.bigint of the storage platform" / > < Property Name = "SizeReduction" Type = "the Types.float storage platform" / > < / Relationship > d) Relationships of Reference The reference relation does not control the time of life to the Departure to which it refers. Moreover, reference relationships do not guarantee the existence of the objective, nor guarantee the type of objective specified in the relationship statement. This means that the reference relationships may be hanging. Also, the reference relationship can refer to Items from other data stores. It can be considered that the reference relationships are a similar concept for the links in the web pages.

An example of a reference relationship statement is as follows: < Relationship Name = "DocumentAuthor" BaseType = "Reference" > < Type of Source Source = "Document" Type of Departure = "Base.Document" / > Target Type = "Author" ltemTy e = "Base.Author" Reference Type = "ltemlDReference" / > < Property Type = "Role" Type = "Core.CategoryRef > < Property Type = "DisplayName" Type = "Types.nvarchar (256)" the warehouse platform / > < / Relationship > Any type of reference is allowed at the end point of the objective. The Matches that participate in a reference relation can be of any type of Game. The reference relationships are used to design most of the management relationships that are not for the life time between the Items. Because the existence of the objective is not enforced, the reference relationship is convenient for designing coupled-loose relationships. The reference relationship can be used to direct to the target Items in other data warehouses including warehouses of other computers. e) Rules and Restrictions The following additional rules and restrictions are applicable for relationships: A Match must be an objective (exactly an embedding relationship) or more possession relationships). An exception is the Root Game. A Game can be an objective of zero or more reference relations. A match that is an objective of an inlay relationship can not be the source of a possession relationship. It can be a source of reference relationships. A Departure can not be a source of possession relationships if it is promoted from the archive. This can be a source of embedding relationships and reference relationships.

• A Part that is promoted from a file can not be an objective of an embedding relation, f) Ordering of Relationships In at least one modality, the storage platform of the present invention supports the ordering of the relations. The ordering is achieved through a property called "Sort" in the basic definition of the relationship. There is no exclusivity restriction in the Ordering field. The ordering of relationships with the same property value of "order" is not guaranteed, however, it is guaranteed that they can be ordered after relations with lower "order" values and before relationships with values of a higher "order" field. Applications can obtain the relationships in the default order by ordering them in the combination (Sourcelteml D, Relationshipl D, Order). All the specific objects of relation originated from a given Part are ordered as a simple collection regardless of the type of relations of the collection. This, however, guarantees that all relationships of a given type (for example, FolderMembers) are an ordered subset of the relationship collection for a given Part.

API 312 of the data warehouse to manipulate relationships implements a set of operations that support the ordering of relationships. The following terms are introduced to help explain the operations: • RelFirst is the first relation of the sorted collection with the order value OrdFirst; • RelLast is the last relation in the collection ordered with the order value OrdLast; · RelX is a determined relation in a collection with an OrdX order value; • RelPrev is the closest relationship in the collection to RelX with an OrdPrev order value smaller than OrdX; and · ReINext is a closer relationship in the collection to RelX with the OrdNext order value greater than OrdX. Operations include, but are not limited to: • \ nsertBeforeFirst (SourceltemID, Relatlonship) inserts the relationship as the first relation in the collection. The value of the "Order" property of a new relation can be smaller than OrdFirst. • InsertAfterLast (SourceltemID, Relationship) inserts the relationship as the last relation in the collection. The value of the "Order" property of the new relation can be greater than OrdLast. InsertAt (SourceltemID, ord, Relationship) inserts a relation with the value specified for the "Order" property. InsertBefore (SourceltemID, ord, Relationship) inserts the relation before the relation with the determined order value. The new relationship can be assigned a value of "Order" that is between OrdPrev and ord, not inclusive. InsertAfter (SourceltemID, ord, Relationship) inserts the relation after the relation with a certain order value. The new relationship can be assigned a value of "Order" that is between ord and OrdNext, not inclusive. MoveBefore (SourceltemID, ord, RelationshipID) moves the relationship with the relationship ID determined before the relationship with a specified "Order" value. The relationship can be assigned a new value of "Order" that is between OrdPrev and ord, not inclusive. MoveAfter (SourceltemID, ord, RelationshipID) moves the relationship with the relationship ID determined after the relationship with a specified "Order" value. The relationship can be assigned a new value of "Order" that is between ord and OrdNext, not inclusive. As mentioned above, each Game must be a member of a Match Folder. In terms of Relationships, each Game must have a relation with a Game Folder. In various embodiments of the present invention, certain relationships are represented by the relationships between the Parties. As implemented by various embodiments of the present invention, a Relationship provides a directed binary relationship that is "extended" by a Game (the source) to another Game (the goal). A Relationship is owned by the Source Party (the Party that extended it) and therefore, the Relationship is eliminated if the source is eliminated (ie, the Relationship is eliminated when the Source Item is deleted). In addition, in certain specific cases, a Relationship may share ownership of an Objective Item (co-ownership), and such property may be reflected in the IsOwned property (or its equivalent) of the Relationship (as shown in Figure 7 for the type of Property of Relationship). In these modalities, the creation of a new IsOwned Ratio automatically increases the reference account of the Target Item, and the elimination of said Ratio may decrease the reference account in the Target Item. For these specific modalities, the Items continue to exist if they have a reference account greater than zero, and are automatically deleted if and when the account reaches zero. Again, a Match Folder is a Match that has (or has the ability to have) a set of Relationships with other Matches, these other Matches comprising the Membership of the Match Folder. Other actual implementations of the Relationships are possible and anticipated by the present invention, to achieve the functionality described herein. Regardless of the current implementation, a Relationship is a collection that can be selected from one object to another. The ability of a Match to belong to more than one Match Folder, as well as to one or more Categories and if these Items, Folders and Categories are public or private, is determined by the meanings provided to the existence (or lack thereof). ) in a structure based on the Games. These logical relations are the meanings assigned to a set of relations, independently of the physical implementation, which is used specifically to achieve the functionality described here. The Logical Relationships are established between the Game and its Game Folder or Categories (and vice versa) because, in essence, the Game Folders and the Categories are each a special type of Game. Accordingly, the Match and Category Folders can be triggered in the same manner as any other Match - copied, added to an email message, embedded in a document, and so on, without limitation - and the Match Folders and Categories they can be serialized and de-serialized (imported and exported) using the same mechanisms as for other Items. (For example, in the XML all the Games could have a serialization format, and this format is equally applicable to the Items, Categories and Games Folders). The aforementioned relationships, which represent the relationship between a game and its game folder can be extended logically from the game to the game folder, from the game folder to the game, or both. A Relationship that extends logically from a Match to a Match Folder indicates that the Match Folder is public for that Match and shares its membership information with that Match; on the contrary, the lack of a logical Relationship of a Game to a Game Folder indicates that the Game Folder is private for that Game, and does not share its membership information with that Game. In a similar way, a Logically extending Relationship from a Match Folder to a Match indicates that the Match is public and can be shared for that Match Folder, while the lack of a Logical Relationship of a Match Folder for a Match. Item indicates that the game is private and can not be shared. Therefore, when a Match Folder is exported to another system, these are the "public" Matches that are shared in the new context, and when a Match searches for its Match Folder for other Matches that can be shared, they are Match Folders "public" that provide the Game with information corresponding to the Games that can be shared that belong to it. Figure 9 is a block diagram illustrating a Match Folder (which, again, is a Match itself) or its member Parties and the relationships that interconnect them between the Match Folders and their member Parties. The Match Folder 900 has as members a plurality of Items 902, 904 and 906. The Match Folder 900 has a 912 Relationship of itself to Item 902 which indicates that Item 902 is public and can be shared for the Folder of Item 900, its members 904 and 906, and any other Match, Category or Match Folders (not shown), which may have access to the Match Folder 900. However, there is no list of Item 902 with the Folder of Items 900 which indicates that the Game Folder 900 is private for Game 902, and does not share its membership information with Game 902. Game 904, on the other hand, does not have a 924 relationship of itself with the Game Folder. of Partidas 900, which indicates that the Partidas 900 Folder is public and shares its membership information with Part 904. However, there is no relation between the Partidas 900 Folder and Part 904, which indicates that Game 904 is private and can not be shared for Game Folder 900, or its members 902 and 906 or any other Game, Category or Game Folders (not shown), which may have access to the Folder of Items 900. In contrast to its relations (or lack of them), with Items 902 and 904, the Departures Folder 900 has a 916 relation of itself with the Departure 906 and the Departure 906 has a 926 return relation to the 900 Match Folder, which together indicate that Game 906 is public and can be shared for Match Folder 900, its members 902 and 904, and any other Match, Category or Match Folders (not shown), which they could have access to the Game Folder 900, and that the Game Folder 900 is public and shares their membership information with Game 906. As explained above, the Matches of a Game Folder do not need to share a game. imilitude because the Match Folders are not "described". The Categories, on the other hand, are described by a similarity that is common to all member Parties. Therefore, the membership of a category is inherently limited to the Items that have the similarity described and, in certain modalities, all the Items that cover the description of a Category are automatically made members of the Category. Therefore, while the Match Folders allow trivial type structures to be represented by their members, the Categories allow membership based on the defined similarity. Of course, the descriptions of the Category are logical in nature, and therefore, a Category can be described by any logical representation of types, properties and / or values. For example, the logical representation for a Category can be its membership to understand the Items that have 1 of 2 properties or both. If these properties described for the Category are "A" and "B", then the membership of the Categories can comprise Items that have property A but not property B, Items that have property B but not property A and items that has both properties A and B. This logical representation of the properties is described by an "OR" logical operator, where the set of members described by the Category are items that have property A or property B. You can also use commands similar logics (including limitation "AND", "XOR", and "NOT" alone or in combination), to describe a Category as may be appreciated by those skilled in the art. Notwithstanding the distinction between the Departmental Folders (not described) and the Categories (described), the Relationship of the Matches with the Categories are essentially in the same way as described here above for the Departures and Departures Folders in many modalities of the present invention. Figure 10 is a block diagram illustrating a Category (which, again, is a Party itself) or its member Parties and the Relationships that interconnect between the Category and its member Parties. Category 1000 has as members a plurality of Items 1002, 1004, and 1006 and all of them share some combination of common properties, values or types 1008 as described (description of similarity 1008 ') by Category 1000. Category 1000 has a 1012 Relationship with Game 1002, which indicates that Game 1002 is public and can be shared for Category 1000, its members 1004 1006, and any other Categories, Game or Match Folders (not shown) that could have access to Category 1000. However, there is no Relation of Item 1002 to Category 1000, which indicates that Category 1000 is private for Game 1002 and does not share its membership information with Game 1002. Game 1004 , on the other hand, does not have a 1024 relationship of itself with Category 1000, which indicates that Category 1000 is public and shares its membership information with Item 1004 However, there is no Extended Relationship from Category 1000 to Item 1004, which indicates that Item 1004 is private and can not be shared for Category 1000, its other members 1002 and 1006, and any other Categories, Items, or Items (not shown), that may have access to Category 1000. In contrast to their Relationships (or lack thereof) with Items 1002 or 1004, Category 1000 has a Relationship 1016 of itself with the Game 1006, Item 1006 has a 1026 Ratio back to Item 1000, which all together indicate that Item 1006 is public and can be shared for Category 1000, its members of Items 1002 and 1004, and any other Categories, Folders of Items or Items (not shown) that could have access to Category 1000, and that Category 1000 is public and shares its membership information with Item 1006. Finally, because the Categories as and the Match Folders are themselves Matches, and the Matches must have relation between them, the Categories can have relation with the Folders of Matches and vice versa, and the Categories, Folders of Matches and Matches can have relation with other categories, Folders of Matches and Matches respectively, in certain alternative modalities. However, in several modalities, the structures of the Game Folder and / or the Category structures are forbidden, at the level of hardware / software interface systems, of the cycles that contain it, where the structures of the Folder of Matches and Categories are similar to directed graphs, the modalities that prohibit the cycles are similar for the directed graphical acíciicos (DAGs) which can be a mathematical definition in the technique of the theory of graphs and are directed graphs where no trajectory start and end at the same vertex. 6.- Extension Capability The storage platform is intended to be provided with an initial set of schemes 340, as described above. However, in addition to at least some of the modalities, the storage platform allows customers, including independent software providers (ISVs), to create new 344 schemes (for example, new types of nested items and elements). This section refers to a mechanism for creating such schemes by extending the types of Matches and the types of Nested Elements (or simply types of "elements") defined by the initial set of schemas 340. Preferably, the extension of the initial set of types of Nested Items and Elements is restricted as follows: · An ISV is allowed to introduce new types of Items, that is, the Base subtype. Item; • An ISV is allowed to introduce new types of Nested Elements, that is, the Base.NestedElement subtype; · An ISV is allowed to introduce new extensions, for example, the Base.NestedElement subtype; but, • The ISV can not form subtypes of any types (Items, Nested Items or Extension types) defined by the initial set of the storage platform schemas 340. Because of the type of Item, or the type of Item Nested defined by the initial set of schemas of the storage platform may not exactly match the need of the ISV application, it is necessary to allow the ISVs to customize the type. This is allowed with the notion of extensions. Extensions are highly-typed specific objects but (a) they can not exist independently (b) they must be attached to a Nominated Item or Element. In addition to solving the need for the extension capacity of the schemes, the extensions also aim to solve the problems of "multiple typing". As in some modalities, the storage platform can not support multiple inheritance, or its subtypes that overlap, applications can use extensions as a means to design specific objects of overlapping types (that is, the document is a legal document). and it is also a secure document). Party Extensions To provide the extension capacity of the Games, the data model also defines an abstract type called Base. Extension. This is a root type for the hierarchy of extension types. Applications can have the Base subtype. Extension to create specific extension types. The Base type. Extension is defined by the basic scheme in the following way: < Type name = Base.Extension "lsAbstract =" True "> < Property name = ItemID ", type = uniqueidentified types of storage platform Which can be overridden false from multiple values = "false Property name =" ExtensionID Type = "Types.uniqueidentified from the platform Storage "That can be overridden =" false "Multivalued ==" false "< / Type> The ItemID field contains the identification of the game to which the extension is associated There must be a Departure with this ItemID. can be created if there is no Departure with the given ItemID.When the Game is deleted all the extensions with the same ItemID are deleted.The record (ItemID, ExtensionID) uniquely identifies a specific object of extension.The structure of some type Extension is similar to a starting type: • Extension types have fields, • Fields can be of primitive types or nested element types, and • Extension types can be sub-typified. Applicable for extension types • Extensions can not be sources and objectives of relationships • Specific objects of extension type can not exist independently of a game; and • Extension types can not be used as field types in storage platform type definitions. There are no restrictions on the types of extensions that may be associated with a certain type of game. Any type of extension is allowed to be extended to any type of game. When specific objects of multiple extension are attached to a Party, they are independent of each other, both in the structure and in their behavior. Specific extension objects are stored and accessed separately from the game. All objects specific to the extension type are accessible from the global extension view. You can compose an efficient request, so that it will return all the specific objects of a certain type of extension regardless of what type of game is associated with them. The storage platform APIs provide a programming model that can store, retrieve and modify the extensions in the games. The extension types can be a sub-typified type that uses a single inheritance model of the storage platform. By deriving it from the extension type a new type of extension is created. The structure or behavior of an extension can not ignore or replace the structure or behavior of the heading type hierarchy. Similar to the types of games, objects specific to the type of extension can be displayed directly through the vision associated with the type of extension. The ItemID of the extension indicates which item it belongs to and can be used to retrieve the corresponding Item item from the Item view, the extensions are considered part of the item for purposes of consistency of operation. The Copy / Move, Backup / Restore commands and other common operations that define the storage platform can operate in the extensions as part of the game. Consider the following example. A type of contact is defined in the Windows type set. < Type name = "Contact" BaseType = "Base Item" > < Property name = "Name" Type =: "String Can be overridden =" false "/> MultiValued =" false "/>, <Property name =" Address Type = "Address Can be canceled r = "true» MultiValued = "false" / > < / Type > A developer of a CRM application would like to attach CRM application extensions to contacts stored on the storage platform. The developer of the application would define a CRM extension that would contain a structure of additional data that can be manipulated by the application. < Type Name = "CRMExtension" BaseType = "Base.Extension" > < Property name = "CusomerlD" Type = "String" You can override r = "false" MultiValued = "false" / > < / Type > A developer of an HR application may also want to attach additional data with the contact. This data is independent of the data of the CRM application. Again the developer of the application can create an extension. < Type Name = HRExtension "EBaseTYPE =" Base.Extension "> <Property Name =" EmployeeID "Type =" String "Can be overridden =" false "MultiValued =" false'7 > < / Type > The extensions CRMExtension and HRExtension are two independent extensions that can be attached to Contacts items. These are created and you have access to them independently between them. In the previous example, fields and methods of the CRMExtension type can not ignore the fields or methods of the Contact hierarchy. It should be noted that objects specific to the CRMExtension extension type can be attached to the Start types, instead of the Contacts. When the Contact item is retrieved, its game extensions are not automatically retrieved. Because a Contact item is related to extensions of items that can be accessed by requesting the global extension vision for extensions with the same ItemID. All CRMExtension extensions in the system can be displayed through the CRMExtension type view, regardless of what item they belong to. All starting extensions of a game share the same game ID. In the previous example, the specific object of the Contact heading and the specific objects of the attached extensions, have the same CRMExtension and HRExtension Itemld The following is a note that summarizes the militudes and differences between the types of Departure, Extension and N ect Element: Partakes vs Departure Extension vs. N Element Item Item Extension Nested Item ID of the game It has its own id It shares the ID of the It does not have its own id of the game starting game. The nested element is part of the game Storage The hierarchy of the Storage hierarchy with the departure is the extension of the departure is stored in stored in its own tables tables Request / Search You can request the tables You can request tables from the game You can usually be tables from the game extension of the games requested only within the context that contains the game Scope You can search in You can search in all You can search Search / Search all cases of specific objects of generally within a heading type a type of extension of the specific objects heading of the type of nested element of a single heading (that the contains) Relationship semantics can have no relations with the ones There are no relationships with relations with the game extensions the nested items split Association with the Can be Generally only can It is related to the games related to being related by fields by means of the other games by means of the games. The middle elements of the extensions. The nested are part of the semantic relationships of the possession item, extension is similar to the embedded and semantic of the embedded time line b) Extension of the NestedElement types The NestedElement types are not extended with the same mechanism as the types of Matches. The Nested Elements Extensions are stored and accessed with the same mechanisms as the Nested Type types fields. The data model defines a root for Nested element types named Element: < Type name = "Element" IsAbstract = "True" > < Property name = "ElementlD" Type = "Types.uniqueidentifier storage platform" Can be overridden = "false" MultiValued = "false" / > < / Type > The NestedElement type is inherited from this type. The NestedElement additionally defines a field that is a multiple set of Elements. < Type name = "NestedElement" BaseType = "Base.Element IsAbstract =" True "> <Property name =" Extensions "Type =" Base.Element "Can be overridden =" false "MultiValued =" true'7 > < / Type The extensions of the NestedElement are different from the extensions of the items in the following ways: • The extensions of the nested element are not extension types. They do not belong to the hierarchy of the extension type that is rooted in the Base type. Extension. • Nested Element extensions are stored together with the other fields of the game and can not be accessed globally - you can not compose a request that retrieves all specific objects of a certain type of extension. • These extensions are stored in the same way as the other nested elements (of the game) that are stored. As with other nested sets, the NestedElement extensions are stored in a UDT. There you can already access through the Extensions field of the nested element type. • The collection interfaces used to access multiple-valued properties are also used to access and interact with the extension type set.

The following table summarizes and compares the extensions I te Extensi o ns a nd Nested E iement. Parallel Extensions vs Extensions of N ement Eiement.

Extension of the Game Extension of Nested Elements Storage The hierarchy of the extension of Stored as elements the game is stored in nested its own tables Application / Search You can request the tables of Generally only the extension of the game can be requested within the context of the game that contains it Scope / Request You can search in all Usually you can only search for specific objects of a type to be searched within the specific extension objects of the nested element of a single heading (which contains them) Ability to Need Special APIs The extensions of extension programming elements and the nested request are like any other special in the multi-valued field tables of the nested elements extension; APIs of the nested element type are used Behavior You can associate the behavior not allowed (?) Behavior Relationship semantics Does not have Relationship with the Does not exist Relationship with the extensions of the departures extensions of the nested elements Match ID Share the game id You do not have your own game id. The nested elements are part of the game D. DATABASE MACHINE As mentioned above, the data warehouse is implemented in a database machine. In the present embodiment, the database machine comprises a relationship database machine that implements an SQL request language, such as the Microsoft SQL server machine, with extensions that are related to the object. This section describes the mapping of the data model that implements the data warehouse to the relationship store, information about the logical API consumed by the storage platform's clients is provided, according to the present modality. However, it should be understood that a different mapping can be employed when a different database machine is employed. Undoubtedly, in addition to implementing the data model of the concept of the storage platform in the relational database machine, it can also be implemented in other types of database, for example, object-oriented databases and XML. An object-oriented database (OO) system provides persistence and transactions for programming language objects, for example, (e.g.C + +, Java). The notion of the storage platform of one (game), maps well to one (Object), in the object-oriented systems through embedded collections that would have to be added to the Objects. Other concepts of the storage platform type, such as inheritance and nested element types, also map the systems of the object-oriented type. Object-oriented systems generally already support the identity of the object; so, the identity of the game can be mapped to the identity of the object. The behavior of the game (operations) is well mapped to object-oriented methods. However, object-oriented systems generally lack organizational capabilities and are deficient in the search. Object-oriented systems also do not provide support for unstructured and semi-structured data. To support the data model of the complete storage platform described here, you would need to add concepts such as relationships, folders and extensions to the object data model. In addition, mechanisms such as promotions, synchronization, notifications and security would need to be implemented. Similar to object-oriented systems, XML databases are based on the XSD (XML Schema definition) and support a single system-based inheritance of the type. The system of the heading type of the present invention could be mapped in the XSD type model. The XSDs also do not provide support for the behaviors. The XSDs for the Games would have to be augmented with Match behaviors. XML databases deal with simple XSD documents and lack broad search organization and capabilities. As with object-oriented databases, in order to support the data model described here, other concepts such as relationships and folders in said X-L databases would need to be incorporated; Also, other mechanisms such as synchronization, notifications and security would need to be implemented. With respect to the following sub-sections, a few illustrations are provided to facilitate the general information described: Figure 13 is a diagram illustrating a notification mechanism. Figure 14 is a diagram illustrating an example in which there are two transactions inserting both a new record into the same tree B. Figure 15 illustrates a data change detection process. Figure 16 illustrates a sample directory tree. Figure 17 shows an example in which an existing folder of a file system based on the directory is moved to the warehouse of the storage platform data. 1. Implementation of the Data Warehouse Using UDTs In the present invention, the relationship database machine 314, which in one embodiment comprises the Microsoft SQL server machine, supports integrated scale types. The integrated scale types are "of origin" and "simple". These are of origin in the sense that the user can not define their own types, and they are simple because they can not encapsulate a complex structure. The user-defined types (hereinafter: UDTs) provide a mechanism for type extension capability above and beyond the source scale type system, making it possible for users to extend the type system by defining complex structured types. Once it is defined by the user, a UDT can be used anywhere in the system of the type in which an integrated scale type could be used. In accordance with one aspect of the present invention, the storage platform schemes are mapped to the UDT classes in the store of the database machine. The data warehouse items are mapped to the UDT classes, deriving them from the Base type. Item. Like the Games, the Extensions are also mapped to the UDT classes and use the inheritance. The type of Root Extension is Base. Extension, from which all types of Extension are derived. A UDT is a CLR class - it has manifestations (ie data fields) and behavior (ie routine). The UDTs are defined using any of the managed languages-C #, VB.NET, etc. UDT methods and operators can be invoked in the T-SQL against a specific object of that type. A UDT can be: the type of a column in a row, the type of a parameter in a routine in T-SQL, and the type of a variable in T-SQL. The mapping of the storage platform schemas to the UDT classes, works directly quite well at a high level. Generally, a storage platform scheme is mapped to a space for CLR name. A type of Storage Platform is mapped to a CLR class. The inheritance of the CLR class has a mirror effect with the inheritance of the storage platform type, and a storage platform property is mapped to a property of the CLR class. 2. Mapping of Matches Due to the desirability that it is possible that the Matches can be searched globally and the support in the relational database of the present modality for the inheritance and the adaptability of the type, a possible implementation for the storage of Matches in the database store would store all the Items in a single table with a column of the Base type. Item. Using the adaptability, Items of all types could be stored and searches could be filtered by the type of item and subtypes using the operator that "is from the (Type)" of Yukon. However, due to concerns about the expenses associated with this method, in this modality, the Items are divided by the higher type level, so that the Items of each type of "family" are stored in a separate table. . Under this division scheme, a table is created for each type of item that is inherited directly from Base. Item. The types of inheritance below these are stored in the family table of the appropriate type using the adaptability of the type, as described above. Only the first level of the Base's inheritance. Item is treated in a special way. A "shaded" table is used to store copies of the globally searchable properties of all the Games. This table can be maintained by the UpdateQ API method of the storage platform, through which all data changes are made. Unlike the family tables of the type, this global Table of Items contains only the top-level scaling properties of the Item and not the object of the complete UDT Item. The global table of Matches allows navigation to the object of the stored item in a type family table, exposing an ItemID and a TypelD. The ItemID will generally uniquely identify the Item within the data warehouse. The TypelD can be mapped using metadata, which is not described in this application to a type name and vision that contains the heading. Because the discovery of a Game by its ItemID can be a common operation, both in the context of the global Table of Games and otherwise. A Getltem () function is provided to retrieve a Start object that has an ItemID granted for the Matches. For convenient access, and to conceal the implementation details to a point where possible, all requests from the Parties may be against the views constructed in the tables of the Parties described above. Specifically, visions can be created for each type of game against the family table of the appropriate type. These type visions can select all the Items of the associated type, including the subtypes. For reasons of convenience, in addition to the UDT object, views can expose columns for all fields of the higher level of that type, including legacy fields. 3. Mapping of Extensions The extensions are very similar to the Games and have some of the same requirements. As in other inheritances of the root type support, Extensions are subject to many of the same considerations and transactions in storage. Because of this, a family mapping of a type similar to that applied to the Extensions is applied, instead of a single table method. Of course, in other modalities, a single table method could be used. In the present modality, an Extension is associated exactly with a Departure by means of the ItemID, and contains an ExtensionID that is unique in the context of the Departure. As with the Parties, a function could be provided to retrieve an Extension due to its identity, which consists of a pair of ItemID and ExtensionID. A Vision is created for each type of Extension, similar to the views of the type of Departure. 4. Nested Element Mapping Nested elements are types that can be embedded in Extensions, Relationships, and nested elements to form deeply nested structures. Like the Games and the Extensions, the Nested Elements are implemented as UDTs, but they are stored within the Games or Extensions. Therefore, the nested elements do not have storage mapping beyond their Start and Extension containers. In other words, there are no tables in the system which directly store specific objects of Nested Elements types, and there are no visions specifically dedicated to the Nested Elements. 5. Identity of the object Each entity in the data model, that is, each Item, Extension and Relationship, has a unique key value. A Departure is uniquely identified by its Itemld. An Extension is uniquely identified by the key composed of (Itemld, Extensionld). A Relationship is identified by the compound key (Item, Relationshipld). Itemld, Extensionld and Relationship are GUID values. 6. Name of the SQL object All objects created in the data store can be stored in a name of the SQL schema derived from the name of the storage platform schema. For example, the Basic schema of the storage platform (often called "Base") can produce types in the SQL schema "(System. Storage)", such as "(System. Storage). Item." The names generated have a prefix through a qualifier to eliminate conflicts in the denomination. Where appropriate, an exclamation character (!) Is used as a separator for each logical part of the name. The following table highlights the naming convention used for objects in the data store. Each element of the scheme (Item, Extension, Relationship and Vision) is in a list along with the convention of the name of the decorated denomination used to have access passes to the data store. 7. Column Denomination When any object model is mapped to a store, naming collisions may occur to the additional information stored together with the application object. In order to avoid collisions in the denomination, all columns of non-specific type (columns which do not directly map to the property named in a type declaration) will have a prefix with a character (_) with a lower mark . In the present mode the lower mark characters (_) are not allowed as the character of the start of any identifier property. Furthermore, in order to unify the denomination between the CLR and the data store, all the properties of a storage platform type or schema element (relation, etc) must have a first character in upper case. 8. Search Visions Visions are provided by the storage platform to search the stored content. An SQL view is provided by each Type of Start and Extension. In addition, visions are provided to support Relationships and Views (as defined by the Data Model). All SQL views and the underlying tables on the storage platform are read-only. The data can be stored or changed using the UpdateQ API method of the storage platform, as will be described in more detail below. You can have access to each of the visions explicitly defined in the schema of the storage platform (defined by the schema designer, and not generated automatically by the storage platform), by means of SQL vision [< schema-name > ] [Víew! < view-name < ] For example, you could have access to a view called "Boc-Sales" in the "AcmePublisher.Books" schema using the name "[AcmePublisher.Books]. [View! BookSales]". Because the output format of a vision is customized on a per view basis (defined by an arbitrary request provided by the part that defines the vision) the columns are mapped directly based on the definition of the schema vision. All SQL search views of the storage platform data store use the following sort convention for the columns: · Logical "key" column of the views results as Itemld, Elementld, Relationshipld, ... • Metadata information about the type of the result such as Typeld. • Change column tracking such as CreateVersion, UpdateVersion, ... • Specific type of columns (s) (Properties of the declared type). • Type of specific visions (family visions) that also contain an object column which returns the object.

The members of each type of family that can be searched using a series of Partition views, being a view by a type of Item in the data warehouse. Figure 28, is a diagram that illustrates the concept of a game search view, a) Game Each game search screen contains a row for each case of a game of the specific type or its subtypes. For example, the vision for Document could return specific objects of Documents, LegalDocument and ReviewDocument. Due to this example, the departure visions can be conceptualized, as shown in figure 29. (1) Master Item Search Vision Each specific object of the storage platform data store defines a vision of Special Item called Master Partition Vision. This view provides summary information about each Item in each data store. The vision provides a column by property of the heading type, a column in which the type of the heading was described and several columns which are used to provide the tracking of changes and synchronization information. The Master Game view is identified by the data store using the name "[System. Storage]. [Aster! Item]" (2) Search of Typified Items Search Each type of Game also has a search view. Although it is similar to the vision of Root Game, this view also provides access to the object of the game by means of the column "_ltem". Each typed departure search view is identified in a data warehouse using the name [schemaName]. [ItemTypeNarne]. For example [AcmeCorp.Doc]. [OfficeDoc].

Column Type Description itemld Itemld Identity of the storage platform of the Item < type change Type of tracking information of change tracking > < parent props > < property specifio One column per source property < item props > < property specifio A column for exclusive property of this type Jtern Type of item CLR object - type of item declared CL b) Item extensions All of the item extensions in a WinFS store are also accessible using the search views. (1) Master Extension Search Vision Each specific object of a data store defines a special Extension view called the Master Extension View. This view provides summary information about each Extension in the data warehouse. The view has a column by property of the Extension, a column in which the type of the Extension is described and several columns that are used to provide the tracking of changes and the synchronization information. The master extension view is identified in a data warehouse using the name "[System. Storage]. [M áster! Extension]".

Column Type Description Itemld Itemld The storage platform identity of the Match with which this extension is associated Extensionld Extensionld Id of this extension specific object (GUID) JTypeld Typeld The Extension Type Id - identifies the exact type of the extension and can be used to retrieve information about the extension using the Metadata catalog. < global change Global tracking information for tracking tracking > < ext properties > < property A column by property of the Extension type specific > (2) Search for Typically Extended Search Each type of Extension has a search vision. Although similar to the master extension view, this view also provides access to the object of the Departure, by means of the co-umn_Extension. Each typified extension search view is identified in a data warehouse using the name [schemaName]. [Extension! extensionTypeN ame]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt]. c) Nested Elements All nested elements are stored within the specific objects of Start, Extensions or Relationships. As such, you have access to them by requesting the search vision of Match, Extension or appropriate Relationship. d) Relationships As explained above, the relationships form the fundamental unit of link between the Matches in a storage platform data warehouse. (1) Master Relationship Search View Each data store provides a Master Relationship Vision. This view provides information about all the relationship-specific objects in the data store. The master relationship vision is identified in a data warehouse using the name "[System. Storage]. [Mas te r! Relationship]". (2) Vision of Search of Specific Objects of Relationship Each declared Relationship also has a search vision which returns all the specific objects of the particular relationship. Although similar to the view of the master relationship, this view also provides columns named for each property of the relationship data. Each search view of the specific object of the relationship is identified in a data store using the name [schemaName]. [Relationship! RelationshipName]. For example, [Acmé Corp. Doc]. [Relationship! DocumentAuthor], e) 9. Updates All views of the storage platform data store are read-only. In order to create a new specific object of a data model element (heading, extension or relationship) or to update an existing specific object, the ProcessOperation or ProcessUpdategram methods of the storage platform API must be used. The ProcessOperation method is a single stored procedure defined by the data store, which consumes an "operation" that details an action that is going to be carried out. The ProcessUpdategram method is a stored procedure which takes an ordered set of operations, known as an "updategram", which collectively details a set of actions that are to be performed. The operation format can be extended and provides several operations on the elements of the scheme. Some common operations include: 1. Operations of Items: a. Createltem (creates a new game in the context of an embeg or possession relationship). b. Updateltem (update an existing item). 2. Relationship Operations: a. CreateRelationship (create a specific object of a reference or possession relationship) b. UpdateRelationship (update a specific object of relationship) c. DeleteRelationship (deletes a specific object from relation). 3.- Extension Operations: a. CreateExtension (adds an extension to an existing Game). b. UpdateExtension (update an existing extension). c. DeleteExtension (deletes an extension). 10 Tracking Changes and Emissions of Security The change tracking and security issuance services are provided by the data warehouse, as will be explained in more detail later. This section provides an overview of the change tracking information exposed in a data warehouse, a) Change Tracking Each search view provided by the data store contains columns used to provide change tracking information; the columns are common in all the games, the visions of Departure, Extension and Relationship. Visions of the storage platform scheme, explicitly defined by the designers of the schema, do not automatically provide the change tracking information-said information is provided indirectly through the search views on which the views themselves are constructed. For each item in the data warehouse, the change tracking information is available from two places - the "master" element view and the "typified" element view. For example, the tracking information for changes in the AcmeCorp type. Document Documentltem is available from the Master Partition View "[System. Storage]. [Master! Ltem]" and the search vision of the Typically Identified Item [AcmeCorp]. Document] - [Document]. (1) Tracking Changes in "Master Search" Visions Change tracking information in the master search view provides information on the creation and update versions of an item, information about which the sync partner created the item, whose associated sync finally updated the item and the version numbers of each partner for creation and update. The associates in the sync relationships (described below) are defined by the partner key. A single UDT object named _ChangeTrackinglnfo of type [System. Storage. Store]. ChangeTrackingl nfo contains all this information. The type is defined in the System schema. Storage, is available _ChangeTrackinglnfo, in all the global search visions for the Start, Extension and Relationship and the type definition of ChangeTrackinglnfo is: < Type Name = "ChangeTrackinglnfo BaseType = "Base.NestedElement" > < Name of FieldProperty = "CreationLocalTS Type = "SqlTypes.Sqllnt64" Can be overridden = "False" / > < Name of FieldProperty = "CreatingPartnerKey" Type = "SqlTypes.Sqllnt32" Can be overridden = "False" / > < Name of FieldProperty = "CreatingPartnerTS" Type = "SqlTypes.Sqllnt64" Can be overridden = "False" / > < Name of FieldProperty = "LastUpdateLocalTS" Type = "SqlTypes.Sqllnt64" Can be overridden = "False" / > FieldProperty name = "l_astUpdatingPartnerKey" Type = "SqlTypes.SqIInt32" Can be overridden = "False" / > < Name of FieldProperty = "LastUpdatingPartnerTS Type = "SqlTypes.Sqllnt64" Can be overridden = "False" / > < / Type > These properties contain the following information: Column Description _CreafionLocalTS Creation of the time stamp by the local machine _Creat¡ngPartnerKey PartnerKey of the partner who created this entity. If the entity was created locally, this is the PartnerKey of the local machine. _Creat¡ngPartnerTS Timestamp the time in which this entity was created in the associated corresponding to _CreatingPartnerKey.

J-astUpdateLocalTS Timestamp local corresponding to the update date on the partner machine _LastUpdatingPartnerKey PartnerKey who last updated this entity. If the last update to the entity was made locally, this is the PartnerKey of the local machine. _LastUpdatingPartnerTS Timestamp of the time in which this entity was updated in the associated corresponding to _LastUpdatingPartnerKey. (2) Tracking Changes in "Typified" Search Visions In addition to providing the same information as the global search view, each typed search view provides additional information by recording the sync condition of each element in the sync topology.

Column Type Description < gIobaI change Global tracking information of change tracking > _ChangeUnitVers¡ons ultiSet < ChangeUnitVersion > Description of the version numbers of the Units of Change within the particular element _EIementSyncMetada ElementSync has additional independent statutes of the version about this item that are of Interest only for the Synchronization runtime. _VersionSyncMetada VersionSyncMetada Additional version-specific metadata about this version that are only of interest for the Synchronization runtime. (b) Security Issuance The data warehouse provides security release information for the Parties, Extensions and Relationships. The security emission visions provide information about live entities and security issues (items, extensions and relationship) in one place. The extension security departure and release views do not provide access to the corresponding object, while the relationship security emission view provides access to the relationship object (the relationship object is NULL in the case of an emission relationship of security). (1) Issuance of Security of Parties Security Issues of Departure are recovered from the system by means of vision [System. S tora ge]. [Tombstone! Item], Column Type Description Itemld Itemld Identity of the Departure _TypeID Typeld Type of the Part < ltem properties > Properties defined for all items _Rootltemld Itemld Itemld of the first non-enclosing game which contains this heading _ChangeTrackinglnfo Specific object CLR Change tracking information for this ChangeTrackinglnfo game JsDeleted BIT This is a signal that is 0 for the games of life, and 1 for the items Included in the security issues. _DeletionWallclock UTCDATETIME Date and time of the UTC wall clock according to the partner who deleted the game. This is NULL if the game is still alive. (2) Security Issuance of Extensions The security Emissions of extensions are recovered from the system using the vision [System. Storage]. [Tombstone! Extension]. The Extension change trace information is similar to that provided for the Items with the addition of the Property. Extensionld. (3) Relationship Security Issuance Relationship Security Emissions are retrieved from the system through vision [System. Storage]. [TombstoneRelationship]. The information on Relationship Security Emissions is similar to that provided by the Extensions. However, the additional information is provided in the ObjectRef objective of the specific object of the relationship. In addition, the object of the relationship is also selected. (4) Elimination of Security Issuance In order to avoid the unlimited growth of security issuance information, the data warehouse provides the security issuance cleanup task. This task determines when a security release information can be discarded. The task computes a limit in the local create / update version and then truncates the security release information by discarding all previous versions of the security release. 11.- Help APIs and Functions The basic mapping also provides a number of help functions. These functions are provided to assist in common operations on the data model. a) Function [System. Storage] .Getltem Returns a Start object with a provided Itemld // Item Getltem (Itemld Itemid) b) Function [System. Storage] .GetExtension // Returns an extension object that has Itemld and Extensionld // Extension GetExtension (Itemid Itemid, Extensionld Extensionld c) Function [System. Storagej.GetRelationship // Returns a relationship object that has been provided with an Itemld and Relationshipid // Relationship GetRelationship (Itemid Itemid, Relationshipid Relationshipid) 12. Metadata There are two types of metadata represented in the Store: metadata of specific objects (the type of a Departure, etc.) and type metadata. a) Schema metadata Schema metadata is stored in the data warehouse as object-specific meta types of the Meta schema. b) Specific Object Metadata Specific object metadata is used by an application to request the type of a Start and finds the extensions associated with a Start. Due to the Itemld for a Departure, an application can request the global departure view to return the type of the Item and use this value to request the Meta-Type vision to return information about the declared type of the Item. For example, // Return the object of the metadata heading for a specific object of determined item // SELECTm. Item as metadatal nfoObj DE [System. Storage]. [Ltem] ¡INNER JOIN [Meta]. [Type] m ON i. _Typeld = m. Itemld WHERE i. itemld = © Itemld E. SECURITY In general, all the objects that can be secured accommodate their access rights using the access mask format shown in Figure 26. In this format, 16 bits of low order are for access rights specific objects, the following 7 bits are standard access rights, which are applicable to most types of objects, and the 4 high order bits are used to specify generic access rights that can map each type of object to a set of standard and object-specific rights. The bit ACCESS_SYSTEM_SECURITY corresponds to the right to access an object SACL. In the access concealment structure of figure 26, the specific rights of the game are placed in the section of Specific Rights of the Object (16 bits of low order), because in the present modality, the storage platform exposes two sets of APIs to manage security - Win32 and the storage platform API, the specific rights of the object of the file must be considered, in order to motivate the design of the specific rights of the object of the storage platform. The security model for the storage platform of the present invention is fully described in the related applications incorporated by reference above. In this regard, Figure 27 (parts a, b and c) illustrates the new protected security region in an identical manner that is being separated from an existing security region, according to one mode of the security model. F. TRACKING NOTIFICATIONS AND CHANGES In accordance with another object of the present invention, the storage platform provides notifications capabilities that allow applications to track data changes. This feature is intended primarily for applications which maintain a volatile condition, or execute business logic in data change events. The registration of applications for notifications about the games, extensions of the games and relations of the games. Notifications are delivered in an asynchronous manner after the data changes have been made. Applications can filter notifications by item, extension and type of relationship, as well as the type of operation. According to one modality, the API 322 storage platform provides two types of interfaces for notifications. First, the registration of applications for simple data exchange events detonated by the changes to the games, game extensions and game relations. Second, applications create "observer" objects to monitor the sets of games, game extensions, and relationships between games. The condition of an observer object can be saved and re-created after a system failure or after a system has gone offline for a long period of time. A single notification can reflect multiple updates. Additional details regarding this functionality can be found in the related requests incorporated as reference above. G. INTEROPERABILITY OF THE TRADITIONAL ARCHIVE SYSTEM As mentioned above, the storage platform of the present invention, in at least some of its modes, is intended to be incorporated as an integral part of the hardware / software interface system of a computer system. For example, the storage platform of the present invention can be incorporated as an integral part of an operating system, such as the Microsoft Windows family of operating systems. In that capacity, the API of the storage platform becomes part of the APIs of the operating system through which the application programs interact with the operating system. In this way, the storage platform becomes the means through which the application programs store the information in the operating system, and the data model based on the storage platform items, therefore, replaces the traditional file system of said operating system. For example, as it is built into the Microsoft Windows family of operating systems, the storage platform could replace the NTFS file system implemented in that operating system. Currently, application programs have access to the services of NTFS file systems through the Win32 APIs exposed by the Windows family of operating systems. However, recognizing that completely replacing the NTFS file system with the storage platform of the present invention would require re-coding existing Win32-based application programs and that such decoding could be undesirable, it would be beneficial if the storage platform of the present invention, will provide some interoperability with existing file systems, such as NTFS. Therefore, in one embodiment of the present invention, the storage platform makes it possible for the application programs depending on the Win32 programming model to have access to the content, both of the data store of the storage platform, and to the system of storage. Traditional NTFS file. To this end, the storage platform uses a naming convention that is a super set of Win32 naming conventions to facilitate easy interoperability. In addition, the storage platform supports access to files and directories stored in the volume of the storage platform through the Win32 API. Additional details regarding this functionality can be found in the related requests incorporated as reference above. H. PLATFORM API OF STORAGE The storage platform comprises an API that allows application programs to access the features and capabilities of the storage platform explained above, and access the items stored in the data warehouse. This section describes an embodiment of an API of the storage platform of the present invention. Details regarding this functionality can be found in the related applications incorporated as reference above, with some of this information summarized below for reasons of convenience. Referring to figure 18, the Folder of Containment, is a heading which contains Possession Relationships for other Items and is the equivalent of the concept as a file system folder. Each Game is "contained" within at least one contention folder. Figure 19 illustrates the basic architecture of the storage platform API according to the following embodiment. The storage platform API uses SQLCIientl 900 to talk to the local data store 302, and you can also use it to talk to the remote data stores (that is, the data store 340). The local store 302 may speak to the remote data store 340 using either the DQP (Distributed Request Processor) or through the storage platform synchronization service ("Sync"), which will be described later. The API 322 of the storage platform also acts as the bridge API for the data warehouse notifications, passing the subscriptions of the application to the notification machine 332, and routing the notifications to the application (ie the application 350a , 350b or 350c), as also described above. In one mode, API 332 of the storage platform can also define a limited "provider" architecture, so that it can access data on Microsoft Exchange and AD systems. Figure 20 schematically represents the different components of the API of the storage platform. The storage platform API consists of the following components: (1) data classes 2002, which represent the element of the storage platform and the data types, (2) the 2004 execution time system, which manages object persistence and provides support class 2006; and (3) the 2008 tools, which are used to generate CLR classes of the storage platform schemes. The hierarchy of the resulting classes of a given schema directly reflects the hierarchy of the types of that schema. As an example, consider the Start types defined in the Contacts scheme as shown in Figures 21A and 21B. Figure 22 illustrates the runtime system in operation. The runtime system operates as follows: 1. An application 350a, 350b, or 350c is linked to a game on the storage platform. 2. The 2004 system creates an ItemContext object 2202 corresponding to the limit item and returns it to the application. 3. The application submits a Find command on this ItemContext to obtain a collection of Matches; the returned collection is conceptually a graphic of objects 2204 (due to relationships). 4. The application of changes, deletes and inserts data.

. The application saves the changes by invoking the UpdateQ method. Figure 23 illustrates the execution of a "FindAII" operation.

Figure 24 illustrates the process by which the API classes of the storage platform are generated from the storage platform schema. Figure 25 illustrates the scheme on which the File API is based. The storage platform API includes a name space to handle file objects. The name space is called System. Storage. Files. The data members of the classes in System. Storage. Files directly reflect the information stored in the storage platform store; this information is "promoted" from the objects of the file system or it can be created using the Win32 API. The space of the name System. Storage. Files has two classes: Fileltem and Directoryltem. The members of these classes and their methods can be easily found by looking for a diagram of the schema in Figure 25. Fileltem and Directoryltem are just read from the API of the storage platform. In order to modify them, you have to use the Win32 API or the classes in System.10. With respect to the APIs, the programming interface (or more simply, the infrase) can be seen as a mechanism, process, protocol to enable one or more segments of the code to communicate with or access the functionality provided by the API. one or more other segments of the code. Alternatively, a programming interface can be viewed as one or more mechanisms, methods, function invocations, modules, objects, etc., of a component of a system capable of coupling communication with one or more mechanisms, methods, invocations of function, modules, etc., of other components. The term "code segment" in the preceding sentence is intended to include one or more instructions or lines of code, and includes for example, code modules, objects, subroutines, functions, etc., regardless of the terminology applied, or whether the Code segments are collected separately, or if the code segments are provided as source, brokers or object codes, if the code segments are used in a system or runtime process, or if they are located on the same machine or different machines or distributed in multiple machines, or if the functionality represented by the code segments is impiemented in its entirety in the software, in its entirety in the hardware, or a combination of hardware and software. As a notion, a programming interface can be viewed generically as shown in Figure 30A or Figure 30B. Figure 30A illustrates an Intefacel interface as the conduit through which the first and second code segments communicate. Figure 30B illustrates an interface comprising the interface objects 11 and 12 (which may or may not be part of the first and second code segments) and which make it possible for the first and second code segments of a system to communicate by a medium . In the view of FIG. 30B, objects 11 and 12 of the interface may be considered as separate interfaces of the same system, or objects 11 and 12 plus medium M may also be considered to comprise the interface. Although Figures 30A and 30B show a bidirectional flow and the interfaces of each side of the flow, certain implementations may have only information in the flow in one direction (or no information flow as will be described later) or may have only one object in the flow. interface on one side. By way of example, and not limitation, terms such as application programming interface (API), entry point, method, function, subroutine, invocation of remote processing and interface of the component object model (COM), are included within the definition of the programming interface. The aspects of said programming interface may include the method by means of which the first segment of the code transmits information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) to second segment of code; the method by means of which the second code segment receives the information and the structure, sequence, syntax, organization, scheme, timing and content of the information. In this regard, the underlying transport medium itself may not be important for the operation of the interface, the medium may be either wired or wireless or a combination of both., provided that the information is transported in the manner defined by the interface. In certain situations, the information may not be passed in one or both directions in the conventional sense, since the transfer of information may be, either by means of another mechanism (ie information placed in a buffer, file, etc.). , separated from the information flow between the code segments) or non-existent, as it is in the case when a code segment simply has access to the functionality performed by a second code segment. Any and all of these aspects may be important in a given situation, that is, depending on whether the code segments are part of a system or in a loosely or tightly coupled configuration, and so this list should be considered illustrative and not limiting. This notion of the programming interface is known to those skilled in the art and is clear from the above detailed description of the present invention. However, there are other means to implement a programming interface and unless expressly excluded, they also intend to be comprised by the claims set forth at the end of this description. Said other means may seem more sophisticated or complex than the simple view of Figures 30A and 30B, but they nevertheless perform a similar function to achieve the same general result. Now we will briefly describe some illustrative alternative implementations of the programming interface. Factoring: A communication from one code segment to another can be achieved indirectly, breaking the communication between multiple separate communications. This is illustrated schematically in Figures 31A and 31B. As illustrated, some interfaces can be described in terms of divisible functionality sets. Therefore, the functionality of the interface of Figs. 30A and 30B can be factored to achieve the same result, just as mathematically can be provided 24, 0 2 x 2 x 3 x 2. Therefore, as illustrated in the figure 31A, the function provided by the interface Interfacel can be subdivided to convert the interface communications in multiple interfaces Interfacel A, InterfacelB, Interfacel C, etc., while achieving the same result.

As illustrated in FIG. 31B, the function provided by the interface 11 can be subdivided into multiple interfaces 11a, 11b, 11c, etc., so long as the same result is achieved. In a similar way, the interface 12 of the second code segment, which receives the information of the first code segment, can be factored into multiple interfaces 12a, 12b, 12c, etc. When factored, the number of interfaces included in the first segment of the code does not need to match the number of interfaces included in the second code segment. In any of the cases of FIGS. 31A and 31B, the functional spirit at interfaces Interfacel and 11 remain the same as in FIGS. 30A and 30B, respectively. The factorization of the interfaces can also follow associative, commutative, and other mathematical properties, so that the factorization can be difficult to recognize. For example, the ordering of operations may not be important, and therefore, a function performed by an interface may also be carried out in advance to reach the interface, by another piece of code or interface, or performed by a separate component. of the system. Furthermore, in one aspect of the programming technique it can be seen that there is a variety of means to make the same function invocations that achieve the same result.

Redefinition: In some cases, it may be possible to ignore, add or redefine certain aspects (for example, parameters) of a programming interface while still achieving the intended result. This is illustrated in Figures 32A and 32B. For example, suppose that the Interface interface of Figure 30A includes a function invocation box (input, precision, output), an invocation that includes three parameters, input, precision, and output, and which is issued from the first Segment of Code to the second Code Segment. In the parameter precision of in-between if it is not of concern in a given scenario, as shown in Figure 32A it could justly be either ignored or even replaced by a parameter with no meaning (in this situation). You can also add an additional parameter, if there is no concern. In any case, the functionality of the square can be achieved, provided that the output is returned after the entry and is squared by the second code segment. Precision can very well be a parameter without meaning for some downstream or other type of computer system. However, once that precision is recognized it is not necessary for the narrow purpose of calculating the square, it can be replaced or ignored. For example, instead of passing a valid precision value, you could pass a value without meaning such as a date of birth, without adversely affecting the result. In a similar manner, as shown in Figure 32B, interface 11 is replaced by interface 11 ', it is redefined to ignore or add parameters to the interface. The interface 12 can be refined in a manner similar to that of the newly defined interface 12 'to ignore unnecessary parameters or parameters that can be processed elsewhere. Here the point is that in some cases the programming interface may include aspects, such as parameters, that are not necessary for some purpose, so that they can be ignored or redefined, or processed elsewhere for other purposes. Online Coding: It is also possible to merge some or all of the functionalities into two separate code modules, so that the "interface" between them changes shape. For example, the functionality of Figures 30A and 30B can be converted into the functionality of Figures 33A and 33B, respectively. In Figure 33A, the first and second previous code segments of Figure 30a, they are fused in a module that contains both. In this case, the code segments can still be communicating with each other, but the interface can be adapted to a form, which is more suitable for a single module. Thus, for example, formal Invocation and Return manifestations may no longer be necessary, but processing or similar response in accordance with interface 1 may still be in effect. In a similar manner, as shown in Figure 33B, part (or all) 12 of Figure 30B can be written online within interface 11 to form interface 11. "As illustrated, interface 12 is divided at I2a and I2b, and the interface portion i2b has been coded in line with interface 11 to form interface 11". For a concrete example, consider that the interface 11 of Figure 30B realizes a square of the function invocation (input, output), which is received by the interface 12, which after processing the value passed with the input (high when the second segment of code is squared, the result squared with the output is passed again, in which case the processing performed by the second code segment (entry to square it) can be performed by the first code segment without an invocation to the interface Separation: A communication from one code segment to another can be performed indirectly, breaking the communication into separate multiple communications This is illustrated schematically in Figures 34A and 34B, as shown in Figure 34A , one or more intermediate pieces (separation interfaces, since they separate the functionality and / or functions of the interface of the original interface) are provided to convert the communications of the first interface Interfacel, to adapt them to a different interface, in this case, the interfaces lnterface2A, lnterface2B and lnterface2C. This could be done, for example, where there is an application base installed and designed to communicate with an operating system according to an interface protocol, but then the operating system is »changed to use a different interface, in this case Interfaces lnterface2A, lnterface2B, and lnterface2C. The point is that the original interface used by the Second Code Segment is changed, so that it is no longer compatible with the interface used by the First Code Segment, and in this way, an intermediary is used to make the interphase compatible old and new. In a similar manner, as shown in Figure 34B, a third Code Segment can be introduced by the separation interface D11 to receive the communications of the interface 11 and with the separation interface DI2 to transmit the interface functionality to , for example, the interfaces I2a and I2b, and redesign them to operate with the DI2 but to provide the same functional result. In a similar way, interfaces DI1 and DI2 can function together to translate the functionality of interfaces 11 and 12 of FIGS. 30B into a new operating system, while providing an equal or similar functional result. New Script: A variant is still possible to dynamically rewrite the code to replace the interface functionality with something else, but which achieves the same general result. For example, it can be a system in which the code segment presented in an intermediate language (for example, Microsoft IL, JavaByteCode, etc.) is provided to a Just in Time collector (JIT) or interpreter in an execution environment ( such as the one provided by the .Net system, the Java runtime environment or other environments of a similar runtime type). The JIT compiler can be written so that it dynamically converts the communications of the 1st. Segment of the Code to 2nd. Segment of the Code, that is, that adapts them to a different interface as may be required by the 2nd. Code Segment (either the original or a 2nd Segment of a different Code). This is illustrated in Figure 35A and 35B. It can be appreciated in Figure 35A, that the method is similar to the Preparation scenario described above. This can be done, for example, where an installed application base is designed to communicate with an operating system, according to the Interphase 1 protocol, but then the operating system is changed to use a different interface. The JIT compiler could be used to adapt flight communications from an installed base application to the new interface of the operating system. As illustrated in Figure 35B, this method for dynamically rewriting the interfaces can be applied to dynamically factor, or otherwise alter the interfaces as well. It should also be understood that the scenarios described above for achieving the same or similar results as an interface by means of alternative modalities may also be combined in different ways, in series and / or in parallel, or with other intervention codes. Therefore, the alternative embodiments presented above are not mutually exclusive and can be mixed, coupled and combined to produce the same scenario or scenarios equivalent to the generic scenarios presented in Figures 30A and 30B. It should also be noted that, as in most programming constructions, there are other similar means to achieve equal or similar functionality of an interface, which may not be described in this document, but which nevertheless are represented by the spirit and scope of the present invention, ie, it should be noted that it is at least partially the functionality represented by, and the advantageous results made possible by, an interface underlying the value of an interface. III. SYNCHRONIZATION API Several methods are possible for synchronization in a hardware / software interface system based on the Games. Section A describes various embodiments of the present invention, while Section B focuses on various embodiments of an API for synchronization. A. SYNCHRONIZATION GENERAL REVIEW For various embodiments of the present invention, and with respect to Figure 3, the storage platform provides a synchronization service 330 that (i) allows multiple instances of the storage platform (each with its own data store 302) to synchronize parts of its content according to a set of flexible rules and (ii) provides a structure for third parties to synchronize the data store of the storage platform of the present invention with other data sources that implement proprietary protocols. Platform-to-storage-platform synchronization occurs between a group of participating "replicas". For example, referring to Figure 3, it may be desirable to provide synchronization between the data store 302 and the storage platform 300 with another remote data store 338 under the control of another storage platform specific object, which perhaps operates in a different computing system. The total membership of this group is not necessarily known for any given replica at any given time. Different replicas can make changes independently (that is, simultaneously). The synchronization process is defined as making each replica aware of the changes made by other replicas. This synchronization capability is inherently multi-master. The synchronization capability of the present invention allows replicas to: • determine which changes the other replica is informed of; · Request information about the changes for which this reply is not informed; • convey information about the changes for which the other reply is not informed; • determine when two changes are in conflict between them; • apply the changes locally; • transport conflict resolutions to other replicas to ensure convergence; and • resolve conflicts based on specified policies for conflict resolution. 1. Synchronization Storage-Platform to Storage-Platform The main application of the synchronization service 330 of the storage platform of the present invention is to synchronize multiple cases of storage platforms (each with its own data store). The synchronization service operates at the level of the storage platform schemas (instead of the underlying tables of the database machine 214). Therefore, for example, the "Scopes" are used to define the synchronization sets, as will be described later. The synchronization service operates under the principle of "net changes". Instead of recording and sending individual operations (such as with duplication of transactions) the synchronization service sends the final result of these operations, therefore, it often consolidates the results of multiple operations into a single resulting change. The synchronization service in general does not respect the limits of the transaction. In other words, if two changes are made to a data warehouse of a storage platform in a single transaction, there is no guarantee that these changes are applied to all replicas atomically - one could be shown without the other changes.

The exception to the principle is that if two changes are made to the same Game in the same transaction, then these changes are guaranteed to be sent and applied to other replicas atomically. Therefore, the Matches are consistency units of the synchronization service. a) Synchronization Control Applications (Sync) Any application can be connected to the synchronization service and start a sync operation. This application provides all the necessary parameters to perform the synchronization (see sync profile below). We refer to these applications in the present description as Control Sync Applications (SCAs). When two storage platform cases are being synchronized, the synchronization is initialized on one side by an SCA. The SCA informs the local synchronization service to synchronize with the remote partner. On the other hand, the synchronization service is awakened by the messages sent by the synchronization service of the machine that requests it. It responds based on the persistent configuration information (see map below) present on the target machine. The synchronization service can be executed in a program or in response to events. In these cases, the synchronization service that implements the program becomes an SCA. To make synchronization possible, you need to take two steps. First, the schema designer must write down the schema of the storage platform with appropriate synchronization semantics (designing Units of Change, as described later). Second, the synchronization must be configured correctly in all the machines that have a case of storage platform that will participate in the synchronization (as described below). b) Scheme Annotations A fundamental concept of the synchronization service is that of the unit of change. A unit of change is the smallest piece of the scheme that is tracked individually by the storage platform. For each Change Unit, the synchronization service can determine whether or not it has changed since the last synchronization. The designation of the Units of Change in the scheme serves several purposes. First, it determines the vibration that the synchronization service has on the cable. When a change is made within a Change Unit, the complete Change Unit is sent to the other replicates, since the synchronization service does not know which part of the Change Unit was changed. Second, it determines the granularity of conflict detection. When two simultaneous changes are made (these terms are defined in detail in later sections), the same Change Unit synchronization service causes a conflict; On the other hand, if simultaneous changes are made to different Units of Change, then no conflict arises and the changes are automatically merged. Third, it strongly affects the amount of metadata maintained by the system. Many of the metadata of the synchronization service are maintained by the Change Unit; therefore, making the Change Units smaller increases the load of synchronization. The definition of Units of Change requires finding the right negotiations. For this reason, the synchronization service allows scheme designers to participate more in the process. In one mode, the synchronization service does not support Change Units that are larger than one element. However, it supports the ability for schema designers to specify smaller Change Units - - - that is, they group multiple attributes of an element into a separate Change Unit. In this mode, this is achieved using the following syntax: < Type Name = "Appointment" MajorVersion = "1" MinorVersion = "0" Extends the Type = "Base Item" Extends the Version < Field Name eetingStatus "Type =" Types.uniqueidentifier of the storage platform can be overridden = "False'7> <Field Name = OrganizerName" Type = "Types.nvarchar (512) of the storage platform can be annular = "False" < <FieldName = OrganizerEmail "Type =" Types.nvarchar (512) of the storage platform "TypeMajorVersion =" 1"MultiValued =" True "/ > < Change Unit Name = "CU_Status <Field Name =" eetingStatus "> <ChangeUnit> <Change Unit Name =" Organizer "<Field Name =" OrganizerName'7 > < Field Name = "OrganizerEmail'7> <ChangeUnit> < / Type > c) Synchronization Configuration A group of storage platform associates that want to keep certain parts of their data in synchronization is what we refer to as a synchronization community. Although members of the community want to stay in sync, they necessarily represent the data in exactly the same way, in other words, synchronization partners can transform the data they are synchronizing. In a similar-to-similar scenario, it is practical for peers to keep mappings of the transformation of all their associates. Instead, the synchronization service takes the path of defining "Community Folders". A community folder is an abstraction that represents a hypothetical "shared folder" with which all members of the community are synchronizing. This notion is best illustrated by an example. If Joe wants to keep the My Documents folders of his different computers in sync, Joe defines a community folder, called, say, Joe's Documents. Then, on each computer, Joe configures a mapping between the hypothetical Joe Document folder, and the local My Documents folder. From this point forward, when Joe's computers are synchronized with each other, they speak in terms of Joe's documents, rather than their local games. In this way, all of Joe's computers understand each other without having to know who they are from - the Community Folder becomes the lingua franca of the synchronization community. The configuration of the synchronization service consists of three steps: (1) define the mappings between the local folders and the community folders, (2) define the synchronization profiles that determine what will be synchronized (for example, to whom to synchronize with which subsets should be sent and what received) and (3) define the programs on which the different synchronization profiles should operate or operate them manually. (1) Community Folder - Mapping Community Folder mappings are stored as XLM configuration files on individual machines. Each mapping has the following scheme: / mappings / communityFolder This element designates the folder of the community for which it is mapping. The name follows the syntax rules of the Folders. / mappings / LocalFolder This element designates the local folder in which you are transforming the mapping. The name follows syntax rules of the Folders. The folder must already exist for the mapping to be valid. The items within this folder are considered for synchronization according to this mapping. / mappi'ngs / transformations This element defines how to transform the items in the community folder into a local folder and vice versa. If it is absent or empty, no transformations are made. In particular, this means that no ID is mapped. This configuration is mainly useful to create an instant memory of a Folder. / mappings / transformations / mapIDs This element requests that newly generated local IDs be assigned to all the mapped items in the community folder, instead of reissuing the IDs of the community. The synchronization operation time will maintain the ID mappings to convert the games forward and backward. / mappings / transformations / localRoot This element requests that all the root games of the community folder become descendants of the specified root. / mappings / runAs This element controls the authorization of who is requested to process this mapping. If it is absent, a sender is assumed. / mappings / runAs / sender The presence of this element indicates that the sender of the messages for this mapping must be personified, and requests that it be processed under his credentials. (2) Profiles A synchronization profile is a total set of parameters needed to start synchronization. It must be supplied by an SCA at the time of Synchronization Operation to initiate synchronization. The synchronization profiles for the platform-storage-to-storage-platform synchronization contain the following information: Local Folder, to serve as the source and destination for the changes; Name of the Remote Folder to synchronize it with - this folder must be published from the remote partner by means of a mapping, as defined above; Address - the synchronization service supports a synchronization only of sending, only of receiving and of sending and receiving; Local Filter - selects what information to send to the remote partner. Expressed as the request of the storage platform over the local folder; Remote Filter - selects which remote information to retrieve from the remote partner - expressed as the request of the storage platform over the community folder; Transformations - define how to transform the games into, from the remote format; Local security - specific if the changes retrieved from the remote endpoint are to be applied under the permissions of the remote endpoint (personified), or the user initiating the synchronization locally; and Conflict resolution policy - - - specifies if conflicts should be rejected, registered or resolved automatically - in this last case, specific what conflicts the solver will use, as well as the configuration parameters for it. The synchronization service provides a CLR class of runtime that allows simple construction of the synchronization profiles. Profiles can also be serialized from the XML files for easy storage (often the programs together). However, there is no standard place in the storage platform where all the profiles have been stored; SCAs are welcome to build the profile at the point without making it persist. Note that there is no need to have a local mapping to initiate synchronization. All the synchronization information can be specified in the profile. However, mapping is required in order to resolve the synchronization requests initiated by the remote side. (3) Programs In one modality, the synchronization service does not provide its own programming structure. Instead, it depends on another component to perform this task - the Windows programmer available with the Microsoft Windows operating system. The synchronization service includes a command-line utility that acts as an SCA or triggers synchronization based on a synchronization profile stored in an XML file. This utility makes it very easy to configure the Windows Scheduler to execute synchronization, either in the program or in response to events such as registrations or user registration cancellations. d) Conflict Management Conflict management in the synchronization service is divided into three stages: (1) conflict detection, which occurs at the time of application of the change - this step determines whether a change can be applied safe; (2) the automatic resolution and recording of the conflict- during this step (which takes place immediately after the conflict is detected), the automatic conflict solvers are consulted to see if the conflict can be solved - if not, the conflict can be registered optionally; and (3) inspection and conflict resolution this step occurs if some conflicts have been recorded and occur outside the context of the synchronization session - at this time, registered conflicts can be resolved and removed from the registry. (1) Conflict Detection In this modality, the synchronization service detects two types of conflict: based on knowledge and based on restriction. (a) Knowledge-Based Conflicts A knowledge-based conflict occurs when two replicas make independent changes to a Change Unit. It is said that two changes are independent if they are made without the knowledge of the other - in other words, the version of a first is not recovered by the knowledge of the second and vice versa. The synchronization service automatically detects all such conflicts based on the knowledge of the replicas, as described above. Sometimes it is useful to consider conflicts as confluences of the history of the version of a Change Unit. If conflicts do not occur in the life of a Change Unit. Its version history is a simple chain - every change that occurs after a previous one. In the case of a conflict based on knowledge, two changes occur in parallel, causing the chain to split and become a version tree. (b) Conflicts Based on Restrictions There are cases where independent changes violate an integrity constraint when applied together. For example, two replicas that create a file with the same name in the same directory would cause that conflict to occur. A conflict based on restrictions comprises two independent changes (just as one based on knowledge), but they do not affect the same Unit of Change. Instead, they affect different Units of Change, but with an insistent restriction between them. The synchronization service detects violations of restrictions at the time of the application of changes, and automatically originates conflicts based on restrictions. The resolution of conflicts based on restrictions usually requires a personalization code that modifies the change in a way that does not violate the restrictions; the synchronization service does not provide a mechanism for general use to do it in this way. (2) Conflict Processing When a conflict is detected, the synchronization service can take one of three actions (selected by the synchronization initiator in the synchronization profile): (1) reject the change, returning it to the sender; (2) register a conflict in a conflict log; or (3) solve the conflict automatically. If the change is rejected, then the synchronization service acts as if the change had not arrived in the replica. A negative knowledge is sent back to the originator. This resolution policy is mainly useful in headless replicas (such as file servers) where the recording of conflicts is not possible. Instead, these rules force others to deal with conflicts by rejecting them. The synchronization initiators configure the conflict resolution in their synchronization profiles. The synchronization service supports the combination of multiple conflict solvers in a single profile in the following ways - first, by specifying a list of conflict solvers to be tested after others, until one of them succeeds; and second, associating conflict solvers with the types of conflict; that is, directing conflicts based on the knowledge of update to update to a solver, but all other conflicts to the record, (a) Automatic Conflict Solution The synchronization service provides a number of default conflict solvers (default). This list includes: • local winners: ignore incoming changes if they conflict with locally stored data; • remote winners: ignore local data if they conflict with the incoming changes; • winners of the last writer. Select either local winners or remote winners per Change Unit based on the time stamp of change (note that the synchronization service in general does not depend on clock values, this conflict solver is the only exception to that rule); • Determinants: they select a winner in a way that is guaranteed to be the same in all replicas, but is otherwise unimportant - a modality of synchronization services uses lexicographic comparisons in the IDs of the associates to implement this feature . In addition, ISVs can implement and install their own conflict solver. Custom conflict solvers can accept configuration parameters; these parameters must be specified by SCA, in the conflict resolution section of the synchronization profile.

When a conflict solver handles a conflict, it returns to the list of operations that need to be performed (instead of the change in conflict) back to the execution time. The synchronization service then applies these operations, having correctly adjusted the remote knowledge to include which conflict handler has been considered. It is possible that other conflicts are detected while the solution is applied. In such a case, a new conflict must be resolved before the original processing is reassigned. When conflicts are thought of as ramifications of the version history of a game, conflict solutions can be seen as unions - - - combining two branches to form a single point. Therefore, conflict solutions become version stories within the DAGs. (b) Conflict Record A very particular type of a conflict solver is ConflictLogger. The synchronization service records the conflicts as items of the ConflictRecord type. These records are re-related to the items that are in conflict (unless the items themselves have been eliminated). Each conflict record contains: the incoming change that caused the conflict; the type of conflict: update-update, update-delete, delete-update, insert-insert, or restriction; and the version of the incoming change and the knowledge of the reply that sent it. Registered conflicts are available for inspection and resolution, as described below. (c) Conflict Inspection and Resolution The synchronization service provides an API for applications to examine the registry of conflicts and suggest solutions to the conflicts that are found in it. The API allows the application to list all conflicts or conflicts related to a particular item. It also allows these applications to resolve registered conflicts in one of three ways: (1) remote winners - - - accepting the registered change and rewriting the local change in conflict; (2) local winners - - ignoring parties to conflict registered change; (3) suggests new changes - - - where the application proposes a merger that, in your opinion, resolves the conflict. Once conflicts are resolved by an application, the synchronization service removes them from the registry. (d) Replica Convergence and Propagation of Conflict Solutions In complex synchronization scenarios, the same conflict can be detected in multiple replicas. If this happens, several things can happen: (1) the conflict can be solved in a replica and the solution will be sent to the other; (2) the conflict is solved in both replicas automatically or (3) the conflict is solved in both replicas manually (through the conflict inspection API). To ensure convergence, the synchronization service sends conflict solutions to the other replicas. When a change resolving a conflict arrives at a replica, the synchronization service automatically finds in the registry any records of the conflict that are fixed by this update and removes them. In this sense, a conflict solution in a replica is being linked to all other replicas. If different winners are selected for different replicas for the same conflict, the synchronization service applies the link principle of the conflict resolution and collects one of the two solutions so that it wins over the other automatically. The winner is collected in a determinant way that is guaranteed to produce the same results at all times (one modality uses lexicographic comparisons of the replica ID). If "different changes" are suggested for different replicas for the same conflict, the synchronization service treats this new conflict as a special conflict, and uses the Conflict Recorder to prevent it from spreading to other replicas. This situation usually originates with the manual solution of conflicts. 2. Synchronization for Non-Storage Platform Data Warehouses According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for the ISVs to implement the Synchronization Adapters that allow the Storage platform synchronize legacy systems, such as Microsoft Exchange, AD, Hotmail. The Synchronization Adapters benefit from many synchronization services provided by the synchronization service, as described below. Despite the name, the Synchronization Adapters do not need to be implemented as auxiliary programs in the architecture of any storage platform. If desired, a "synchronization adapter" can simply be any application that uses synchronization service runtime interfaces to obtain services, such as the enumeration and application of changes. In order to make it easier for others to configure and execute the synchronization to an end for a specific purpose, the writers of the Synchronization Adapter are encouraged to expose the standard interface of the Synchronization Adapter, which executes the synchronization determined by the Profile of the Synchronization Adapter. Synchronization, as described above. The profile provides configuration information to the adapter and some of those adapters pass the Synchronization Execution Time to the control runtime services (that is, the folder to be synchronized). a) Synchronization Service The synchronization service provides a number of synchronization services for the writers of an adapter. For the rest of this section, it is convenient to refer to the machine on which the storage platform is synchronizing as the "client", and the back end of the non-storage platform that the adapter is talking to as the server". (1) Enumeration of Changes Based on the change tracking data maintained by the synchronization service, the Change Enumeration allows synchronization adapters to easily list changes that have occurred to a data store folder since the last time the synchronization with this associate was attempted.

The changes are listed based on the concept of an "anchor" - - - an opaque structure representing the information about the last synchronization. The anchor takes the form of knowledge of the storage platform as described in the previous sections. Synchronization adapters that use the change enumeration service fall into two broad categories. Those who use "stored anchors" against those who use "supplied anchors". The distinction is based on where the information about the last synchronization - - - is stored in the client or in the server. It is often easier for adapters to store this information in the client - - - the back end often does not have the ability to conveniently store this information. On the other hand, if multiple clients are synchronized with the same endpoint, the storage of this information in the client is deficient and in some cases incorrect - - -makes a client not aware of the changes that the other client has already driven for the server. If an adapter wants to use an anchor stored on the server, the adapter needs to re-supply it to the storage platform at the time of the change enumeration.

In order for the storage platform to maintain the anchor (either for local or remote storage), the storage platform needs to be aware of the changes that were successfully applied to the server. These and only these changes can be included in the anchor. During the enumeration of the change, the Synchronization Adapters use the Acknowledgment interface to report which changes were applied successfully. At the synchronization end, the adapters that use the supplied anchors must read the new anchor (which incorporates all the changes applied successfully) and send them to their back end. Frequently, Adapters need to store specific data of the adapter together with the items that are inserted into the data warehouse of the storage platform. Common examples of such data are remote IDs and remote versions (time stamps). The synchronization service provides a mechanism for storing this data and the Change Enumeration provides a mechanism for receiving this extra data together with the changes that are being returned. In most cases, this eliminates the need for adapters to re-apply to the database. (2) Change Application The Change Application allows the Synchronization Adapters to apply changes received from their subsequent ends to the local storage platform. The adapters are expected to transform the changes to the storage platform scheme. Figure 24 illustrates the process by which the API classes of the storage platform of the storage platform schema are generated. The main function of the change application is to automatically detect conflicts. As in the case of Platform-Storage-to-Storage-Platform synchronization, a conflict is defined as two changes that are being made, which overlap without the knowledge between them. When the adapters use the Change Application they must specify the anchor with respect to which the conflict detection was made. The Change Application causes a conflict if the local change that overlaps is not covered by the knowledge of the adapter in which it is detected. In a way similar to Change Enumeration, adapters can use either stored or supplied anchors. The Change Application supports the efficient storage of adapter-specific metadata. This data they can be attached by the adapter to the changes that are being applied and could be stored by the synchronization service. The data could be returned in the following change enumeration. (3) Conflict Resolution The Conflict Resolution mechanism described above (registration options and automatic solution) is also available for synchronization adapters. Synchronization adapters can specify the policy for conflict resolution when the changes are applied. If it is specified, conflicts can be passed to the specified conflict handler and solved (if possible). Conflicts can be registered. It is possible that the adapter can detect a conflict when you try to apply a local change to the back end. In such a case, the adapter can still pass the conflict to the synchronization runtime to be solved according to the policy. In addition, the Synchronization Adapters may request that any conflicts detected by the synchronization service be sent back to them for processing. This is particularly convenient in the case where the back end has the ability to store and resolve conflicts. (b) Adapter Implementation Although some "adapters" are applications that simply use runtime interfaces, adapters are encouraged to implement adapter standard interfaces. These interfaces allow the applications that control the synchronization: request that the adapter synchronize according to the given synchronization profile, cancel the synchronization in progress, and receive a progress report (percentage completed) in a synchronization in progress. 3. Security The synchronization service endeavors to introduce as few security models as possible implemented by the storage platform. Instead of defining new rights for synchronization, existing rights are used. Specifically, • anyone who can read a Data Warehouse Game can list the changes to that item; • anyone who can write to a data warehouse item can apply changes to that item; and • anyone who can extend a data warehouse item can associate synchronization metadata with that item. The synchronization service does not maintain secure information about authorship. When a change is made in replica A by user U and is sent to replica B, the fact that the change was originally made in A (or by U) is lost. If B sends this change to replica C, this is done under the authorization of the Bs, and not of the A. This leads to the following limitation: if a replica is not entrusted to make its own changes to a game, it can not send the changes made by others. When the synchronization service is started, this is done through the application of synchronization control. The synchronization service embodies the identity of SCA and performs all operations (both locally and remotely) under this identity. To illustrate, note that user U can cause the local synchronization service to retrieve changes from a remote storage platform for the games to which the user U can read them. 4. Management Capacity Monitoring a distributed replication community is a complex problem. The synchronization service can use a "sweep" algorithm to collect and distribute the information closest to the conditions of the replicas. The properties of the sweep algorithm ensure that the information about all the configured replicas is finally collected and that the replicas that are failing are detected (those that do not have the capacity to respond).

This monitoring information throughout the community becomes available in each replica. Monitoring tools can be executed on an arbitrarily selected replica to examine that monitoring information, and make administrative decisions. Any changes to the configuration must be made directly in the affected replicas. B. OVERVIEW OF THE IF CROOZING API In an increasingly distributed digital world, individuals and work groups often store information and data in a variety of different devices and locations. This has driven the development of data synchronization services that can maintain information in these separate data stores, often disparate, synchronized at all times, with minimal user intervention. The synchronization platform of the present invention, which is part of a rich storage platform described in Section 11 in this description (a.k.a., "WinFS"), addresses three main objectives. • Allows applications and services to synchronize data efficiently between different "WinFS" stores. · It makes it possible for developers to build rich solutions for the synchronization data between the "WinFS" stores and those that are not "WinFS". • Provides appropriate interface flayers to customize the user's synchronization experience. 1. General Terminology In the following some refined additional definitions and important key concepts are presented for the later explanations of this section III. B: Synchronization Replication: Most applications are interested only in the tracking, enumeration and synchronization of changes for a particular subset of items within the WinFS store. The starting set that is part of a synchronization operation is referred to as a synchronization replica. A replica is defined in terms of items contained within a given WinFS contention hierarchy (usually rooted in a folder heading). All synchronization services are carried out within the context of a given replica. WinFS synchronization provides a mechanism for defining, managing and deleting replicas. Each replica has a GU1D identifier that uniquely identifies it within a given WinFS store.

Synchronization Associate: A synchronization partner is defined as an entity that has the ability to make changes to WinFS games, extensions and relationships. Therefore, each WinFS store can be named as a synchronization partner. When synchronizing with a non-WinFS store, the external data source (EDS) is also referred to as a synchronization partner. Each partner has an identifier GUID that identifies it exclusively. Synchronization Community: A synchronization community is defined as a collection of replicas that are maintained in synchronization by means of similar-to-similar synchronization operations. These replicas can all be in the same WinFS store, or in different WinFS stores, or they can be manifested as virtual replicas in non-WinFS stores. WinFS synchronization does not prescribe or command any specific topology for the community, especially if only the synchronization operations of the community are through the WinFS synchronization service (WinFS adapter). Synchronization adapters (defined later) can enter their own topology restrictions. Tracking Changes, Units of Change and Versions: Each WinFS store tracks changes for all WinFS, Extensions and Local Relations. The changes are tracked at the granularity level of the change unit defined in the scheme. The high level changes of any Game, Extension and Type of Relationship can be subdivided by the designer of the scheme into units of change, with the smallest granularity being one in the higher level field. For change tracking purposes, each change unit is assigned a Version, where one version is a pair of synchronization partner IDs and a version number (the version number is a monotonically specific number of the partner). The versions are updated as changes occur in the warehouse locally, or as they are obtained from other replicas. Knowledge of Synchronization: Knowledge represents the condition of a synchronization replica determined at any time, that is, it encapsulates the metadata about all the changes that a particular replica is aware of, whether local or from other replicas. WinFS synchronization maintains and updates knowledge for synchronization replicas in synchronization operations. One important thing that must be observed is that the representation of knowledge allows it to be interpreted with respect to the whole community and not only in relation to the particular replica where the knowledge is stored. Synchronization Adapters: A synchronization adapter is a managed code application that has access to the WinFS Synchronization services through the Synchronization Execution Time API and makes it possible to tune the WinFS data, in data warehouses that do not They are WinFS. Depending on the requirements of the scenario, the adapter developer decides which subset of WinFS data and what types of WinFS data to synchronize. The adapter is responsible for communicating with the EDS, transforming the WinFS schemas to and for schemas supported by EDS, and defining and managing its own configuration and metadata. The adapters are strongly encouraged to implement the WinFS synchronization adapter API to take advantage of the common configuration and control infrastructure for the adapters, provided by the WinFS synchronization computer. For more details, please refer to the specification of the WinFS Synchronization Adapter API [SADP], and to the Synchronization Driver API specification [SCT L]. For adapters that synchronize WinFS data for external stores that are not WinFS and can not produce or maintain knowledge in the WinFS format, WinFS synchronization provides services to obtain remote knowledge that can be used for the enumeration of changes or subsequent operations of the application. Depending on the capabilities of the back end storage, the adapter may wish to store this remote knowledge at the back end or at the local WinFS store. For reasons of simplicity, a synchronization "replica" is a structure that represents the data set in a "WinFS" store that exists in a single logical location, while the data in a store that is not "WinFS" is named a "data source" and generally requires the use of an adapter. Remote Knowledge: When a particular synchronization replica wants to have changes from another replica, it provides its own knowledge as a baseline against which the other replicates the changes. Similarly, when a particular replica wants to send changes to another replica, it provides its own knowledge as a baseline, which can be used by the remote replica to detect conflicts. This knowledge about the other replica that is provided during the synchronization change enumeration and the application is called a remote knowledge. 2. Main Concepts of the Synchronization API For certain modalities, the synchronization API is separated into two parts: the synchronization configuration API and the synchronization controller API. The synchronization configuration API makes it possible for applications to configure synchronization, and that specify parameters for a particular synchronization session between two replicas. For a given synchronization session, the configuration parameters include the set of Matches to be synchronized, the type of synchronization (one way or two way), the information about the remote data source and the solution policy of conflicts. The synchronization driver API initiates a synchronization session, cancels synchronization, and receives progress and error information about ongoing synchronization. Furthermore, for specific modalities in which synchronization needs to be performed in a previously determined program, said systems may include a programming mechanism to personalize the programming. Various embodiments of the present invention employ synchronization adapters to synchronize the information between the "WinFS" data sources and those that are not "WinFS". Examples of adapters include an adapter that synchronizes address book information between a "WinFS" contact folder and a non-WinFS mailbox. In these cases, the adapters of the adapter could use the services API of the synchronization core "WinFS" described here, to have access to the services provided by the synchronization platform "WinFS", in order to develop the transformation code of schema between the "WinFS" schema and the schema of the data source that is not "WinFS". Additionally, the adapter developer provides protocol support to communicate changes to the non-WinFS data source. "A synchronization adapter is invoked and controlled by using the synchronization controller API and reports the progress and errors using this API However, for certain embodiments of the present invention, when synchronizing the synchronization data store "WinFS" with another data store "WinFS", a synchronization adapter may be unnecessary, if the services Synchronization of "WinFS" to "WinFS" are integrated into the hardware / software interface system In any case, several of these modes provide a set of synchronization services, both for the synchronization of "WinFS" to "WinFS" , as for the synchronization adapter solutions that include: • The tracking of changes for games, extensions and relationships. WinFS ".

• The support for the enumeration of increasingly incremental changes efficient from a certain past condition. • The application of external changes to "WinFS". · The handling of conflicts during the application of the change. Referring to figure 36, which illustrates three cases of a common data store and the components to synchronize them. A first system 3602 has a WinFS 3612 data store comprising synchronization services from WinFS to WinFS 3622 and Kernel Synchronization Service 3624, for synchronization of WinFS with non-WinFS, which exposes 3646 a Synchronization API 3652 for its use. Similar to the first system 3602, the second system 3604 has a WinFS 3614 data store comprising synchronization services from WinFS to WinFS 3632, and Kernel Synchronization Service 3634, for synchronization of WinFS to one other than WinFS, which exposes 3646, a Synchronization API 3652 for use. The first system 3602 and the second system 3604 synchronize 3642 by means of their synchronization services from WinFS to respective WinFS 3622 and 3632. A third system 3606, which is not a WinFS system has an application to use WinFS 3666 synchronization to maintain the data source in a synchronization community with the WinFS replica. This application can use either the WinFS 3664 Synchronization Control / Configuration service to interface directly with the 3644 with the WinFS 3612 data store through the synchronization services from WinFS to WinFS 3622, (if it has the ability to virtualize itself as a WinFS data store) or through a sync adapter 3662 that interfaces 3648 with the synchronization API 3652. As illustrated in this figure, the first system 3602 is aware of and synchronizes directly with both the second system 3604 and the third system 3606. However, neither the second system 3604 nor the third system 3606 are warned among themselves, and therefore, they do not synchronize their changes directly between them, but rather, the changes that occur in a system must be propagated through the first system 3602. C. SERVICES OF THE SYNCHRONIZATION API Several modalities of the present invention are focused to the synchronization services that comprise two fundamental services: the enumeration of changes and the application of changes. 1. Enumeration of Changes As described earlier in this document, the enumeration of changes allows synchronization adapters to easily list changes that have occurred to the Data Warehouse Folder since the last time synchronization with this partner was attempted, based on the tracking data of changes maintained by the synchronization service. With respect to the enumeration of changes, several embodiments of the present invention are focused on: • the efficient enumeration of changes to the Items, Extensions and Relationships in a given replica, in relation to a specified knowledge case. • the enumeration of changes in the granularity level of the change unit specified in the WinFS schemas. • the grouping of changes listed in terms of compound items. A compound game consists of a game, all its extensions, all its possession relations for the games and all the composite games that correspond to its embedded games. Changes to the reference relationships between the items are listed separately. • the formation of lots in the change list. The granularity of the lot is a compound item or a change of relation (for reference ratios). • the specification of filters on the items in the replicas during the enumeration of changes, that is, the replica consists of all the items of a given folder, but for this enumeration of particular change, the application would like to not only list the changes to all the Contact items where the first name starts with an 'A' (this support must be added after the important event B). • the use of remote knowledge for the enumerated changes, with the ability to record individual change units (for complete items, extensions or relationships), such as the synchronization that has failed in knowledge, such as to have them re-enumerated in the next opportunity. • the use of advanced adapters that may have the ability to understand the WinFS synchronization metadata, returning the metadata together with the changes during the enumeration of the change. 2. Application of Changes As explained earlier in this document, the application of changes allows the Synchronization Adapters to apply the changes received from their posterior end to the local storage platform, since the adapters are expected to transform the changes in the Scheme of the storage platform. With respect to the application of changes, several embodiments of the present invention are focused on: • the application of incremental changes of other replicas (or non-WinFS stores), with updates corresponding to the WinFS change metadata. • the detection of conflicts in the application of changes in the granularity of the unit of change. • the report of success, failure and conflict at the unit level of individual change in the application of changes, so that applications (including adapters and synchronization control applications) can use this information to report progress, error and condition and to update its back end condition, if it exists. • the remote knowledge update during the change application as to prevent "mirroring" in the application that provided the changes during the next change enumeration operation. • the use of advanced adapters that have the ability to understand and provide WinFS Synchronization metadata along with the changes. 3. Sample Code The following is a sample code of how a FOO synchronization adapter might interact with the synchronization runtime (where all the specific functions of the adapter are prefixed with FOO): ItemContext ctx = new ItemContext (\\ Svstem \ UserData \ dshah \ Mv Contacts ". True); // Get the id of the replication match and the id of the remote partner of the profile. // Most of the adapters would obtain this information from the synchronization profile. Guid replicaltemld = FOO_GetReplicald (); Guid remotePartnerld = FOO_Get_RemotePartnerld (); // // Query the knowledge stored in the warehouse using storedKnowledgeld as in the previous one // ReplicaKnowledge remoteKnowledge =. ...; // // Initialize ReplicaSynchronizer; // ctx.RepIicaSynchronizer = new ReplicaSynchronizer (applies Item Id, remotePartnerld; ctx.RepIicaSynchronizer.) RemoteKnowledge = remoteKnowledge; ChangeRander reader = ctx. ReplicaSynchronizer.GetChangeReader (); // // Lists changes and processes them. // bool bChangesToRead = true; while (bChangesToRead) ... {Changes in the Collection <object> changes = nulls; bChangesToRead = reader; ReadChanges (10 changes out); for each (object change in the changes). {// // The enumerated object is processed, the The adapter makes its own transformation scheme // and the ID is mapped, and additional // Ctx objects can still be retrieved for this purpose and the adapter modifies the metadata after a // change has been applied to the remote store.

Condition ChangeStatus status = FOOProcessAndApplyToRemoteStore (change); // Update the knowledge learned by the condition reader.AcknowledgeChange (changeStatus); } } remoteKnowledge -ctx. Repl i caSynchronizer. GetUpdateRemoteKnowledgeO; reader.Close (); // // Save the updated knowledge and the metadata of the adapter, if there are // they exist // //ctx.Update (); // // Sample of the change application, first the remote knowledge is initialized using // storedKnowledgeld as before. // remoteKnowledge =. . .; ctx.ReplicaSynchronizer.ConflictPolicy = conflictPolicy; ctx.ReplicaSynchronizer. RemotePartnerld = remotePartnerld; ctx. Repl i caSynchronizer. RemoteKnowledge = remoteKnowledge; ctx.ReplicaSynchronizer.C ha ng eStatusEvent + = FOO_OnCh to ng eStatusEvent; // // Get the changes from the remote store. The adapter is responsible for retrieving // the specific metadata from the back end of the store. This can be an extension // in the replica. // object remoteAnchor = FOO_GetRemoteAnchorFromStore (); FOOD_RemoteChangeCollection remcteChanges = FOO_GetRemoteChanges (RemoteAnchor); // // It is filled in the change collection // foreach (FOO_RemoteChange change in remoteChanges { // The adapter is responsible for mapping the ID Guide localld = FOO_MapRemoteld (change); // let's say we are synchronizing People objects search ItemSearcher = Person.GetSearcher (ctx); searcher.Filters.Add (Personald = (5) localld '); searcher.Parameters ["Personld"] = localld; Person to Person = searcher.FindOneQ; // // Adapter transforms remote changes into modifications in a Person object // As part of this adapter you can also make changes to the back end of the starting level // the specific metadata for the remote object. // FOO__TransformRemoteToLocaI (remoteChange, person); } ctx.Update (); // // Save the new remote anchor (this can be an extension of the replica) // FOO_SaveRemoteAnchor (); // // This is a save of the regular WinFS API since the remote knowledge is not synchronized. // remoteKnowledge = ctx.Repl¡caSynchronizer.GetUpdateRemoteKnowledge (); ctx.UpdateQ; // // Reminder of the adapter for the reminders of the application condition in processing // void FOO_OnEntitySaved (object sender, ChangeStatusEventArgs args). { remoteAn chor.AcceptCh a n ge (args. Cha ng status); } 4. API Synchronization Method In one embodiment of the present invention, it is possible to perform synchronization between a WinFS store and a non-WinFS store, by means of the Synchronization APIs exposed by the hardware interface system / software based on WinFS. In one embodiment, all synchronization adapters are required to implement the synchronization adapter API, a managed API (CLR) of the common language runtime, so that they can be displayed on the screen, initialized and controlled in a consistent manner. The adapter API provides: • A standard mechanism for registering adapters with the hardware / software interface system's synchronization system. • A standard mechanism for adapters to declare their capabilities and the type of configuration information needed to initialize the adapter.

• A standard mechanism for passing the initialization information to the adapter. • A mechanism for adapters to report back the progress condition to applications that invoke synchronization. • A mechanism to report any errors that occur during synchronization. • A mechanism to request the cancellation of a synchronization operation in progress. There are two potential process models for the adapters, depending on the requirements of the scenario. The adapter can run in the same process space as applications are invoked or processed separately by themselves. To run its own separate process, the adapter defines its own factory class, which is used to exemplify the adapter. The factory can return an adapter field in the same process as the application being invoked, or return a remote case of the adapter in a common language runtime application field or process different from Microsoft's. A default factory implementation is provided (default), which exemplifies the adapter of the same process. In practice, many adapters will run in the same process as the application being invoked. The out-of-process model is usually required for one or both of the following reasons: • Security purposes. The adapter must run in the process space of a certain process or service. • The adapter has to process requests from other sources - for example, incoming network requests - in addition to processing the requests of the applications that are invoked. Referring to Figure 37, one embodiment of the present invention assumes a simple adapter that is not aware of the way in which the condition is calculated, or that its associated metadata are exchanged. In this mode, the synchronization is achieved by the replica, with respect to the data source with which it is desired to synchronize, first, in step 3702, determining what changes have occurred since the last time it was synchronized with said data sources , and then the replica transmits the incremental changes that have occurred since this last synchronization based on its current condition information, and this current condition information and incremental changes are sent to the data source via the adapter. In step 3704 the adapter, upon receiving the change data from the replica in the previous step, implements as many changes as possible to the data source, tracks which changes are successful and which failed, and transmits the information of success and failure back to WinFS (of the replica). The replication hardware / software infer system (WinFS), in step 3706, upon receiving the success and failure information from the replica, then calculates the new information condition for the data source, stores this information for use future by its replication and transmits this new condition information back to the data source, that is, the adapter for storage and subsequent use by the adapter. D. ADDITIONAL ASPECTS OF THE SYNCHRONIZATION SCHEME The following are additional (or more specific) aspects of the synchronization scheme for various embodiments of the present invention. • Each replica is a defined data subset of synchronization of the entire data warehouse - a data division that has multiple instances. • A conflict resolution policy is handled by each replica (a combination of adapter / data source) individually - that is, each replica can resolve conflicts based on its own criteria and the conflict resolution scheme. In addition, although the differences in each case of the data warehouse may result and lead to additional future conflicts, the consecutive and incremental enumeration of the conflicts is reflected in the updated condition information and is invisible to the other replicas that receive that condition information. updated. At the root of the synchronization system is the replica which has a basic type to define a root folder (in fact, a root game), which has a unique ID, an ID for the synchronization community of which it is a member, and what filters or other elements are necessary or desirable for the specific replication. Each "mapping" of the replica is maintained within the replica, and as such, the mapping for any particular replica is limited to other such replicas that it knows. Although this mapping may comprise only a subset of the entire synchronization community, changes to that replication will still be propagated to the entire synchronization community by means of commonly shared replicas (even if any particular replica is not aware of which other replicas it is sharing). usually with an unknown replica). The synchronization scheme includes both a plurality of previously defined conflict handlers available for all replicas, as well as the customization capability for the user / developer defined conflict handlers. This scheme can also include three special "conflict solvers": (a) a conflict "filter" which solves different conflicts in different ways based, for example on, (i) how to handle them with the same unit of change changed in two places, (ii) the way to handle them when a unit of change is changed in one place but eliminated in another; and (iii) how to handle it when two different units of change have the same name in two different locations; (b) a conflict "handler list" where each item in the list specifies a series of actions to try in order until the conflict is successfully resolved; and (c) a "do nothing" record that tracks the conflict but does not take an additional action without user intervention.

• The scheme of the synchronization and the use of the replicas are made possible in a synchronization community of multiple masters distributed from similar-to-similar. In addition, there is no synchronization community type, but the synchronization community exists simply as a value in the community field of the replicas themselves. • Each replica has its own metadata for tracking the incremental enumeration of changes and storage of condition information for the other replicas that are known in the synchronization community. • The change units have their own metadata that include: a version that includes an associated key plus a partner change number; an elaboration of the Start / Extension / Relationship version for each unit of change; Knowledge of the changes that a replica has seen / received from the synchronization community; a Local ID configuration; a GUID stored in the reference relation for the deletion. CONCLUSION As illustrated by the above, the present invention relates to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and extends the data storage aspect beyond existing file systems and database systems, is designed to be the storage of all types of data, including structured data, unstructured or semi-structured such as relationship data (tabular), XML or a new form of data called Matches. Through the foundation of common storage and the schematized data, the storage platform of the present invention makes possible a more efficient application development for consumers, knowledge workers and businesses. It offers a rich and extensible application programming interface that not only makes available the inherent capabilities in your data model, but also understands and extends to existing file systems and access methods of databases. It should be understood that changes can be made to the modalities described herein, without departing from the broad concepts of the invention thereof. Accordingly, the present invention is not limited to the particular embodiments described, but is intended to cover all modifications that are within the spirit and scope of the present invention, as defined by the appended claims. As can be seen from the foregoing, all or portions of the different systems, methods and aspects of the present invention may be incorporated in the form of program codes (ie, instructions). This program code may be stored in a computer-readable medium, such as magnetic, electrical and optical media, including without limitation, a floppy disk, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape , instant memory, hard disk drive or any other means of storage readable by the machine, wherein when the program code is loaded and executed by a machine such as a server computer, the machine becomes an apparatus for practicing the present invention. The present invention can also be incorporated in the form of a program code that is transmitted by a transmission medium, such as by an electrical wiring, through optical fibers, by a network, including the Internet or an intranet, or by means of any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the present invention. When implemented in a general-purpose processor, the program code is combined with the processor to provide a single device that operates in a manner analogous to specific logic circuits.

Claims (30)

1. CLAIMS 1. - A storage platform system for a hardware / software interface system (for example, WinFS), the storage system comprising: multiple cases of a storage platform; a source synchronization subsystem for the hardware / software interface system that makes it possible for the system to synchronize multiple instances of the storage platform.
2. 2. - The system as described in claim 1, characterized in that the synchronization subsystem synchronizes only a subset of data, from all the data in the data store, during a synchronization operation.
3. 3. The system as described in claim 1, characterized in that a first case of the storage platform is a replica, that is, it is executed in a hardware / software interface system that has in its system synchronization (for example WinFS) and a second case of the storage platform is a data source, that is, it runs on a hardware / software interface system that does not have in its synchronization system (for example, a system that is not WinFS).
4. 4. - The system as described in claim 3, wherein the synchronization between the replica and the data source is facilitated by a synchronization adapter that virtualizes the data source by inferring it with an application programming interface (API) of the replication hardware / software system.
5. 5. - The system as described in claim 1, characterized in that the first pair of specific objects synchronizes the changes independently of the second pair of specific objects, and wherein both the first pair of specific objects and the second pair of Specific objects are part of the common synchronization community.
6. 6. The system as described in claim 1, characterized in that conflicts in synchronization are detected and resolved automatically based on criteria that can be determined previously defined.
7. 7. The system as described in claim 6, characterized in that certain of said conflicts are solved by being registered for the manual solution by the end user.
8. 8. The system as described in claim 1, characterized in that the synchronization subsystem tracks the condition of the previous synchronizations with a synchronization partner, by means of which it only synchronizes the change units with that partner that has changed since the last synchronization (ie, "net changes").
9. 9. - A method for synchronizing multiple specific objects of a storage platform for a hardware / software interface system (for example, WinFS), said method comprising: dividing the storage platform into basic units of granularity (e.g. , units of change); list the changes consecutively and track the changes based on one unit per unit of change; for each specific object, to track the condition of the changes for those specific objects, as well as the condition of the changes for a plurality of other specific objects known in the synchronization unit (synchronization partners); and for synchronization, identify new changes by comparing the changes listed for a particular specific object with the condition of the changes for that specific object.
10. 10. - The method as described in claim 9, characterized in that in the first specific object, a replica is exemplified in a hardware / software interface system that directly supports synchronization based on the Items (WinFS), and wherein the second specific object, a data source, is exemplified in a hardware / software interface system that does not directly support synchronization based on the Matches (which is not WinFS), the method further comprising the use of an adapter to virtualize the specific object that is not WinFS by means of a synchronization application programming interface.
11. 11. - The method as described in claim 10, which further comprises detecting synchronization conflicts at the granularity level of the change unit.
12. 12. - The method as described in claim 10, which further comprises: specific objects for reporting success, failure and / or conflicts at the unit level of individual change in the application of changes (synchronization data); and applications (including but not limited to adapters and other synchronization control applications) that use the synchronization data for the update of the back end condition.
13. 13. A method for synchronizing a replica with a data source (each a data partner), wherein both the replica and the data source have change condition information that is maintained by each synchronization partner, and in where the data source (which is not WinFS) uses an adapter to infer with a hardware / software replication (WinFS) system comprising such a method: a replica that sends the adapter an updated information condition for the replica which, based on the last condition information for the data source, reflects the changes that have been made since the last synchronization as reflected in the information of the last condition for the data source ("new changes"); and said adapter receiving updated condition information for replication and new changes, implementing as many changes as possible to the data source, and tracking success or failure for each change in a unit of change based on the unit of change.
14. 14. The method as described in claim 13, which further comprises: that the adapter calculates the new condition of the data source based on the success or failure of each change in a unit of change on a basis of change unit, storing this new new condition information, and transmitting this new condition information to the replication hardware / software interface system (WinFS), the hardware / software interface system of the replication (WinFS), stores the new condition information for that data source for future use by the replica.
15. 15. The method as described in claim 13, which further comprises: transmitting the adapter to the hardware / software interface system of the replica (WinFS) the success or failure of each change to the data source in a unit of change based on the unit of change; calculating the replication hardware / software interface system (WinFS) the new condition information for the data source based on the success or failure of each change for the data source in a unit of change based on the unit of change; transmitting the hardware / software interface interface of the replica (WinFS) the new condition information to the adapter and storing the new new condition information for future use by the replica; and receiving and storing the adapter the new condition information.
16. 16. - A computer readable medium comprising computer-readable instructions for a storage platform system in a hardware / software interface system (eg, WinFS), said instruction storage system comprising for synchronization of the specific local object of between multiple objects specific to a storage platform.
17. 17. - The system as described in claim 16, characterized in that the synchronization subsystem synchronizes only a subset of data, from all data in the data store during a synchronization operation.
18. 18. - The computer readable instructions as described in claim 16, characterized in that the first specific object of the storage platform is a replica, that is, that it is executed in a hardware / software interface system that has the synchronization subsystem (for example, WinFS), and a second storage platform specific object is a data source, that is, it runs on a hardware / software interface system that does not have the synchronization subsystem (for example, which is not WinFS).
19. 19. - The computer-readable instructions as described in claim 18, characterized in that the synchronization between the replica and the data source is facilitated by a synchronization adapter that virtualizes the second specific object by interfacing with a programming interface Application (API) of the hardware / software interface system of the first specific object.
20. 20. - The computer-readable instructions as described in claim 16, characterized in that the first pair of specific objects synchronizes the changes independently of the second pair of specific objects, and wherein both the first pair of specific objects and the second Pair of specific objects are part of a common synchronization community.
21. 21. The computer-readable instructions as described in claim 16, characterized in that synchronization conflicts are detected and resolved automatically based on previously defined criteria that can be determined.
22. 22. - The computer readable instructions as described in claim 21, characterized in that certain of said conflicts are solved by being registered for the manual solution by an end user.
23. 23. - The computer-readable instructions as described in claim 16, characterized in that the synchronization subsystem traces the condition of the preconditions with a synchronization partner, and thus, only synchronizes the units of change with that associated that have changed since the last synchronization (for example, "net changes").
24. 24. - A computer-readable medium comprising computer-readable instructions for synchronizing multiple specific objects of a storage platform for hardware / software interface systems (eg, WinFS), comprising the computer-readable instructions for: dividing the storage platform in basic units of granularity (for example, units of change); list the changes consecutively and track the changes on a base per unit of change; for each specific object, to track the condition of the changes for those specific objects, as well as the condition of the changes for a plurality of other specific objects known in the synchronization community (synchronization partners); and for synchronization, identify new changes by comparing the changes listed for a particular specific object with the condition of the changes for that specific object.
25. 25. - The computer-readable instructions as described in claim 24, characterized in that they also comprise instructions by means of which a first specific object, a replica, is exemplified in a hardware / software interface system that directly supports synchronization based on the Matches (WinFS), and where the second specific object , a data source, is exemplified in a hardware / software interface system that does not directly support synchronization based on the Matches (which is not WinFS), said method comprising the use of an adapter to virtualize specific objects that are not WinFS through a synchronization application programming interface.
26. 26. - The computer-readable instructions as described in claim 25, which further comprise detecting synchronization conflicts at the granularity level of the change unit.
27. 27. - The legible instructions, by computer as described in claim 25, which also include: specific objects for reporting success, failure and / or conflicts at the unit level of individual changes in the application of changes ( synchronization data); and applications (including but not limited to, adapters and other synchronization control applications) that use the synchronization data to update the condition of the trailing end.
28. 28. - A computer-readable medium comprising computer-readable instructions for synchronizing a replica with a data source (each a synchronization partner) characterized in that both the replica and the data source have change condition information that is maintained by each synchronization partner, and where the data source (which is not WinFS), uses an adapter to interface with a hardware / software interface interface of the replica (WinFS), comprising the computer-readable instructions, instructions so that said replica sends to the adapter the updated condition information for the replica which, based on the last condition information for the data source, reflects the changes that have been made since the last synchronization as reflected in said last condition information for the data source ("new changes"), so that the adapter that receives that information of updated condition for replication and new changes, you can implement as many changes to the data source as possible and track the success or failure for each change in a unit of change based on the units of change.
29. 29. - The computer-readable instructions as described in claim 28, which further comprise instructions for the replication hardware / software interface system (WinFS), which stores the new condition information for the source of data for future use by the replica, provided that the adapter has calculated the new condition of the data source based on the success or failure of each change in a base per unit of change and has this information of new condition and is transmitted this new condition information to the hardware / software interface system of the replica (WinFS).
30. 30. The computer-readable instructions as described in claim 28, characterized in that the adapter transmits to the hardware / software interface system of the replica (WinFS) the success or failure for each change of the change unit in a base per unit of change, also comprising instructions for; that the replication hardware / software interface system (WinFS) calculates a new condition information for the data source based on success or failure for each change to the data source in a unit of change, on a basis of unit of change; that the hardware / software interface interface of the replication (WinFS) transmits the new condition information to the adapter and stores the new condition information for future use by said replica so that the adapter can receive and store the condition information new.